Month: April 2016

Comparison of Java Script Modules and Dependency Managing Frameworks

Comparison of Java Script Modules and Dependency Managing Frameworks

Modular programming is a software design technique that emphasizes separating the functionality of a program into independent, interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired functionality. Module based coding eases the effort for maintenance and increases re-usability.

However, managing dependencies between modules is a major concern Java Script developers faced. Hence there are several module and dependency management frameworks became famous among JS developers to give the responsibility to manage dependencies properly in larger projects.

For Eg:

 

 

But first three are the most popular and most used frameworks.

Choosing the right module loader is an important decision for any high quality web application. Large applications often require a number of JavaScript files. Generally, they are loaded one by one using <script> tags. Additionally, each file can potentially be dependent on other files. You don’t want to add script tags manually into the html because is not scalable (you have to manually order, no deploy minification…).

Following is a comparison listed in webpack documentation.

Feature webpack/webpack jrburke/requirejs substack/node-browserify jspm/jspm-cli
CommonJs require yes only wrapping in define yes yes
CommonJs require.resolve yes no no no
CommonJs exports yes only wrapping in define yes yes
AMD define yes yes deamdify yes
AMD require yes yes no yes
AMD require loads on demand yes with manual configuration no yes
ES2015 import/export no no no yes
Generate a single bundle yes yes♦ yes yes
Load each file separate no yes no yes
Multiple bundles yes with manual configuration with manual configuration yes
Additional chunks are loaded on demand yes yes no System.import
Multi pages build with common bundle with manual configuration yes with manual configuration with bundle arithmetic
Concat in require require(“./fi” + “le”) yes no♦ no no
Indirect require var r = require; r(“./file”) yes no♦ no no
Expressions in require (guided) require(“./templates/” + template) yes (all files matching included) no♦ no no
Expressions in require (free) require(moduleName) with manual configuration no♦ no no
Requirable files file system web file system through plugins
Plugins yes yes yes yes
Preprocessing loaders, transforms loaders transforms plugin translate
Watch mode yes not required yes not needed in dev
Debugging support SourceUrl, SourceMaps not required SourceMaps SourceUrl, SourceMaps
Node.js built-in libs require(“path”) yes no yes yes
Other Node.js stuff process, __dir/filename, global process, __dir/filename, global process, __dir/filename, global for cjs
Replacement for browser web_modules, .web.js, package.json field, alias config option alias option package.json field, alias option package.json, alias option
Minimizing uglify uglify, closure compiler uglifyify yes
Mangle path names yes no partial yes
Runtime overhead 243B + 20B per module + 4B per dependency 14.7kB + 0B per module + (3B + X) per dependency 415B + 25B per module + (6B + 2X) per dependency 5.5kB for self-executing bundles, 38kB for full loader and polyfill, 0 plain modules, 293B CJS, 139B ES6 System.register before gzip
Dependencies 19MB / 127 packages 11MB / 118 packages 1.2MB / 1 package 26MB / 131 packages

Following articles have much detailed comparison of above frameworks.

  1. What are the best client-side JavaScript module loaders?
  2. Module loader comparison: Webpack vs Require.js vs Browserify
  3. Webpack comparison

 

Advertisements
Comparison of Java Script Document Generators

Comparison of Java Script Document Generators

One of your least desirable and least rewarding tasks as a software developer is creating documentation. Whether it’s for code you’re creating, a change you’re contemplating, or a problem that you’re trying to resolve, the actual task of documentation is often dull and unimaginative. Yet detailed, accurate, up-to-date documentation is of enormous value.

  • It helps insure that changes made to the source code don’t create unforeseen problems. It speeds and focuses software peer review efforts.
  • It lowers the likelihood of misunderstandings among developers and quality assurance teams.
  • It alleviates the need to spend time hand-holding new engineers as they get up to speed.

So as documenting is essential in software development, in JavaScript world following are some famous document generator tools for documenting APIs.

  • DoccoLogodoxxDOCCO
  • YUI
  • JSDoc
  • Doxxyui-logo-2xjsdoc_featured

Following table compares the above generator tools each other.

JSDoc

YUIDoc

Doxx

Docco

Syntax

Structured

Structured

Structured

Unstructured

Accessibility
(default theme)

Low

High

High

High

Search feature

Yes, not by default

Yes

No

No

Extra themes

Docstrap

One bundled. Others available.

No.

Bundled

Learning curve

Medium

Medium

Low

None

Source parsing

Yes

No

No

No

Customization

High

Medium

Low

Very low

Extensibility

High

Medium

Low

None

Speed

Medium

Low

N/A

Very High

A more detailed comparison can be found in here.

And a great discussion of the importance of good documentation can be found here.

Sample documentation pages of above tools for the same source are given in below. Take a look of the visual appeal of each. But in JSDoc we could customize it as we wanted.

How to Use WSO2 Data Mapping Mediator in ESB

How to Use WSO2 Data Mapping Mediator in ESB

Please find the updated post from here

https://nuwanpallewela.wordpress.com/2016/07/16/how-to-use-wso2-data-mapping-mediator-in-esb-updated/

INTRODUCTION

WSO2 data mapper is a data mapping solution that convert and transform one format of data to a different format. It provides a WSO2 Developer Studio based tool to create the graphical mapping configuration and generate the files needed to execute the mapping configuration by the WSO2 Data mapper engine as shown in the below diagrams. As the this is really useful feature in message mediation, WSO2 ESB comes with a data mapper mediator which can be integrate into a mediation sequence since WSO2 ESB 5.0.0.

PREREQUISITES

First we need to have the data mapper mediator supported ESB distribution. WSO2 ESB 5.0.0 is the distribution packed with data mapper mediator. You can download alpha pack from here.

And also we need to have a data mapping editor supported Developer Studio ESB Tool. You can follow this article to install the WSO2 Developer Studio ESB Tool 5.0.0.

OVERVIEW

This post will focus on how to create a configuration with Data Mapper mediator. So I will chose a very simple ESB configuration with only a data mapper mediator and respond mediator to check the converted message.

 

employeeToEngineerUserCase.png

Our Employee message will be a xml message and we will send a JSON response to the client. We will use the Postman as out client to send the requests.

Creating Data Mapping Configuration

Lets create a ESB Configuration project named “DataMapperEmployeeToEngineerConfig” from the WSO2 Developer Studio ESB Tool and create a Rest API as follows.

RestAPiWizard.png

Then we can add the Data Mapper Mediator in to the API resource and a Respond mediator to send the converted message back to client.

apiconfig.png

Then double click on the data mapper mediator to configure the mapping. It will open a dialog box asking to create a Registry Resource project. This is to save and deploy the required configuration and schema files in the ESB Server to read at the runtime when message conversion happens. So name the configuration file as “EmployeeToEngineerMapping” and registry resource project as “EmployeeToEngineerRegistryResource”.registryresourcefile.pngIt will open the Data Mapper Diagram Editor where we should do the mapping.

diagrameditor.png

But first we need to complete the API configuration. So go back to ESB Diagram editor with the API Resource and click on the Data Mapper mediator. You will see the configurations of the Data Mapper mediator on the property table.

data mapper configuration.png

As you can see there are five configurations listed. They are

  • Input Type : Expected input message type (xml/json/csv)
  • Output Type: Target Output message type (xml/json/csv)
  • Configuration : This file contain the script file used to execute the mapping
  • Input Schema: JSON schema which represent input message format
  • Output Schema: JSON schema which represent the output message format

As we are going to convert xml message to json message change the output type to json.

propertytable.png

And then click on the API resource and  go to the property table. And change the configurations to following.

  • Url Style : URL_MAPPING
  • URL-Mapping : /employeetoengineer
  • Methods : POST

apiconfigchanges.png

Save the API configuration. Now lets move to data mapper editor to create the mapping from employee message to engineer.

First we need to load the input and output message formats into editor. For the right click on the input box title bar and select load input schema command.

loadschemafromfile.png

Then following dialog box appears and you will have multiple ways to load the input message format.

loadinputclose.png

You can select the resource type as XML, JSON, XSD or JSONSCHEMA.

If you selects XML, you can load a sample xml message you expect and WSO2 Data Mapper Editor will generate the JSON schema to represent the xml accoring to the WSO2 Data Mapper Schema specification.

Same as for XML, if you select  JSON as resource type you can load a sample JSON message.

If you have a xsd schema which defines you xml message format, you can select the resource type as XSD and load the xsd file.

And also if you have the JSON schema for your message according to the WSO2 Data Mapper schema specification you can load it by selecting resource type as JSON schema.

Lets use a sample xml message to load input format to the data mapper editor. Use following xml as the sample input.

<?xml version='1.0' encoding='utf-8'?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body><ns1:employees xmlns:ns1="http://wso2.employee.info" xmlns:ns2="http://wso2.employee.address">
<ns1:employee>
<ns1:firstname>Mike</ns1:firstname>
<ns1:lastname>Jhonson</ns1:lastname>
<ns2:addresses>
<ns2:address location="home" >
<ns2:city postalcode="30000">KS</ns2:city>
<ns2:road>main rd</ns2:road>
</ns2:address>
<ns2:address location="office" >
<ns2:city postalcode="10003">NY</ns2:city>
<ns2:road>cross street</ns2:road>
</ns2:address>
</ns2:addresses>
</ns1:employee>
<ns1:employee>
<ns1:firstname>Patric</ns1:firstname>
<ns1:lastname>Jane</ns1:lastname>
<ns2:addresses>
<ns2:address location="home" >
<ns2:city postalcode="60000" >Melborne</ns2:city>
<ns2:road>park street</ns2:road>
</ns2:address>
<ns2:address location="office" >
<ns2:city postalcode="10003">NY</ns2:city>
<ns2:road>cross street</ns2:road>
</ns2:address>
</ns2:addresses>
</ns1:employee>
<ns1:employee>
<ns1:firstname>Thelesa</ns1:firstname>
<ns1:lastname>Lisbon</ns1:lastname>
<ns2:addresses>
<ns2:address location="home" >
<ns2:city postalcode="60000">Madrid</ns2:city>
<ns2:road>Palace street</ns2:road>
</ns2:address>
<ns2:address location="office" >
<ns2:city postalcode="10003">NY</ns2:city>
<ns2:road>cross street</ns2:road>
</ns2:address>
</ns2:addresses>
</ns1:employee>
</ns1:employees>
</soapenv:Body>
</soapenv:Envelope>

And use following JSON message as the sample output and load output message format to data mapper editor.

{
"engineers":{
"engineerList":[
{
"fullname":"Mike Jhonson",
"addresses":{
"address":[
{
"location":"home",
"city":{
"postalcode":30000,
"text":"AA"
},
"road":"BB"
},
{
"location":"office",
"city":{
"postalcode":10003,
"text":"BB"
},
"road":"CC"
}
]
}
},
{
"fullname":"Mike Jhonson",
"addresses":{
"address":[
{
"location":"home",
"city":{
"postalcode":30000,
"text":"AA"
},
"road":"BB"
},
{
"location":"office",
"city":{
"postalcode":10003,
"text":"BB"
},
"road":"CC"
}
]
}
}
]
}
}

Now the editor will have the input and output message formats as bellow.

operations.png

Now we can specify how the output message should build by using the input message. We have several operations given in the operations pallet in the left side.

Click on the operator and it will come to the editor. Then construct the mapping as the following diagram.

mappingdiagram.png

You can only connect primitive data values such as Strings, numbers, boolean and etc. Array and object values can not be mapped.

  • {}  – represent object elements
  • []   – represent array elements
  • <> – primitive field values
  • A   – xml attribute values

After loading the message formats you have to observe whether the formats are correctly identified by the data mapper diagram editor.

Now save the all configurations. We can now deploy the created REST API in the ESB server and test our mapping.

Deploy the REST API in ESB Server

We can create a CAPP including the WSO2 synapse configurations and the registry resource files as below.

DMCAPP.png

Start ESB server and add it to Developer Studio ESB Tool servers and deploy.

deployment.png

Then go to API’s list from the ESB management console and confirm the REST API invocation URL.

deployedAPIs.png

Invoke Created REST API

Open Postman and create the client message as follows.

postmanxmlmessage.png

Send the message from Postman and you will receive the respond message but in the xml format. This is since though we converted the message to type json in the axis2 level we need to change the property “messageType” to “application/json” too.

messagetypeproperty.png

So add a property mediator and configure the following parameters.

  • Property Name : messageType
  • Value : application/json
  • Property Scope : axis2

Then redeploy the CAPP and send the employee message again from the Postman. Then you will receive the expected json message as follows.

jsonresponse.png

{
"engineerList": [
{
"addresses": {
"address": [
{
"city": {
"postalcode": 30000,
"text": "KS"
},
"location": "home",
"road": "main rd"
},
{
"city": {
"postalcode": 10003,
"text": "NY"
},
"location": "office",
"road": "cross street"
}
]
},
"fullname": "Mike Jhonson"
},
{
"addresses": {
"address": [
{
"city": {
"postalcode": 60000,
"text": "MELBORNE"
},
"location": "home",
"road": "park street"
},
{
"city": {
"postalcode": 10003,
"text": "NY"
},
"location": "office",
"road": "cross street"
}
]
},
"fullname": "Patric Jane"
},
{
"addresses": {
"address": [
{
"city": {
"postalcode": 60000,
"text": "MADRID"
},
"location": "home",
"road": "palace street"
},
{
"city": {
"postalcode": 10003,
"text": "NY"
},
"location": "office",
"road": "cross street"
}
]
},
"fullname": "Thelesa Lisbon"
}
]
}

Now you have the basic end to end knowledge to develop a ESB configuration with a data mapper mediator. So you can try this and report the bugs and suggest improvements from the following link as JIRAs.

I will discuss more advanced discussion about how things work inside and mapping configuration is generated from the diagram which will help to understand the behavior of the data mapper and the limitations.

How to Debug WSO2 ESB Mediation Flow

How to Debug WSO2 ESB Mediation Flow

INTRODUCTION

WSO2 Enterprise Service Bus is a lightweight, high performance, and comprehensive ESB. 100% open source, the WSO2 ESB effectively addresses integration standards and supports all integration patterns, enabling interoperability among various heterogeneous systems and business applications.

And now it also contains message mediation debugging support with the release version 5.0.0. In this post I will deploy a simple proxy on WSO2 ESB and debug the message mediation flow.

PREREQUISITES

First we need to have the mediation debugger supported ESB distribution. WSO2 ESB 5.0.0 is the distribution packed with mediation debugger. You can download latest pack from here.

And also we need to have a debugger supported Developer Studio ESB Tool. You can follow this article to install the WSO2 Developer Studio ESB Tool 4.1.0.

OVERVIEW

Lets create a simple scenario where we have a  client, ESB Server and Service.

ESB Debugger Simple USecase(1)

We can use WSO2 try it tool or SOAP UI to send a request from client side. And as this is just to check the ESB Mediation Debugger functionality we will use WSO2 server inbuilt echo service as our service.

Creating Proxy Service

So first now we have to built a proxy service to WSO2 ESB which will get the client request and do some modifications on the received message and sent it to our echo service and get the response from the echo service and sent it back to client after some modifications.

So start WSO2 Developer Studio ESB Tool and create a proxy service with name “EchoServiceWithName”.

It will simply get the following request from the client.

<login>
<user>
<displayname>Mike</displayname>
</user>
</login>

Modify it to following message before sending it to echo service.

<echoString xmlns:ns1="http://echo.services.core.carbon.wso2.org"><in>Mike</in>
</echoString>

And we will receive a message like below.

<echoStringResponse xmlns:ns="http://echo.services.core.carbon.wso2.org">Mike</ns:echoStringResponse>

 

 

Then we will modify it to following message and send it back to client.

<user>
<message>
<welcome>Welcome</welcome>
<name>Mike</name>
<end>for WSO2 technologies !!!</end>
</message>
</user>

This is done by the following configuration.

<proxy name="EchoServiceWithName" startOnLoad="true" trace="disable" transports="http https" xmlns="http://ws.apache.org/ns/synapse">
<target>
<inSequence>
<log/>
<property expression="/login/user/displayname" name="Name" scope="default" type="STRING"/>
<payloadFactory media-type="xml">
<format>
<ns1:echoString xmlns:ns1="http://echo.services.core.carbon.wso2.org">
<in>$1</in>
</ns1:echoString>
</format>
<args>
<arg evaluator="xml" expression="get-property('Name')"/>
</args>
</payloadFactory>
<send>
<endpoint>
<address trace="disable" uri="http://localhost:8280/services/echo"/>
</endpoint>
</send>
</inSequence>
<outSequence>
<log/>
<property expression="/ns:echoStringResponse" name="EchoName" scope="default" type="STRING" xmlns:ns="http://echo.services.core.carbon.wso2.org"/>
<payloadFactory media-type="xml">
<format>
<user>
<message>
<welcome>Welcome</welcome>
<name>$1</name>
<end>for WSO2 technologies !!!</end>
</message>
</user>
</format>
<args>
<arg evaluator="xml" expression="get-property('EchoName')"/>
</args>
</payloadFactory>
<send/>
</outSequence>
<faultSequence/>
</target>
</proxy>

After creating proxy service with above configuration it should be as follows.

proxyDiagramEditor

Now we are all set to debug. We have all components ready to test out proxy service with debugger.

Starting WSO2 ESB Server with Developer Studio ESB Tool to Debug

There are two ways to start a wso2 esb server.

  • First way is from the terminal we can navigate to server file location bin folder and execute wso2server.sh as follows.startserverterminal
  • Second way is we can start esb server from Developer Studio ESb Tool by adding it from the Servers view.serverTab

 

But to support mediation debugging we need to provide command line arguments as “-Desb.debug=true”.

Then the ESB server will listen on two ports to connect with Developer Studio ESB Mediation Debugger as configured in the [esbserver]/repository/conf/sypanse.properties file.

#configuration for the external debugger channels if server is started in debug mode
synapse.debugger.port.command=9005
synapse.debugger.port.event=9006

Then we have to connect developer studio esb tool with esb server by execution above created debug configuration. We have roughly 1 minute time span to connect, otherwise esb server will stop listening and start the server without connecting with debugger tool.

So we should first build the debug configuration from the WSO2 Developer Studio ESB Tool before starting the ESB Server in the debug mode.

Go to Debug Configurations in the Developer Studio and you will see a type of debug configuration named ESB Mediation Debugger

debugconfigclosemediationdebugger.png

Then double click on ESB Mediation Debugger and you will get configuration dialog as below.

defaultconfig.png

It will contain the default command port and event port as 905 and 9006 with your local host name.

If you want to change the default ports, you should modify both server synapse.properties file and this configuration parameters.

And you can remote debug a server which is running in a different host by modifying the Server host with it’s ip.

Now start the ESB Server in the mediation debug mode with the command “sh wso2server.sh -Desb.debug=true” and click the Debug button when server listing to the ports as bellow.

listining.png

Deploy Created Artifacts in Server

Now we have to deploy the previously created proxy service in ESB Server. For that we can create a CAPP using developer studio.

Capp.png

To deploy it from developer studio we need to have the ESB server in the Servers of developer studio. If you started the ESB server from developer studio you can noe directly add the CAPP. Otherwise add the ESB server by going to Servers view-> Add New Server -> WSO2 -> carbon remote server , and specify the host name as follows.newServer.pngremoteip.png

Now you can add and deploy the capp in the server.

addremoveclose.png
deploy.png
serverdeployment.png

Our use case should work. So go to the ESB Server Management Console and select our proxy service try this service tool.

And send the request message as we discussed above. But we will not get the expected output.

Request.pngresponse

Our response doesn’t contain the name. So lets debug the message flow. Put debug breakpoints by right click on the mediators.

breakpoint.png

And send the request again. ESB Message mediation will stop at the first breakpoint position.

debughitpoint.png

There you can see in the variables table under Synapse Scope Properties “Name” property we defined  is empty. There should be an error of out expression. Oh!! yap, it is wrong the expression should be start with double slashes like this “//login/user/displayname” .

Lets look that do we have more errors. If above expression was correct now we have a the value of property “Name” as Mike. So put the value in the variable table and enter. Now the property  value will be changed to “Mike” in the ESb Server.

mikeedit.png

Lets resume the process. It will stop at send mediator. And we will have the expected message after the payload factory mediator. So we can continue.

Oh then another mistake. The returned message from the Echo service is not what we expected.

returnMessage.png

It contain another element named “return” inside the “echoStringResponse” element. So we need to modify the expression of the  property mediator in the out sequence too. It should be “//ns:echoStringResponse/return”.

Lets again put the property value as “Mike” for the property “EchoName” so that we could check the next steps.

modifyedMessage.png

Now we can see the final message is what we expect. So save the modifications done and redeploy the proxy to the server.

And send the request again. We now get the expected response. Great!!!

You will observe that after we redeploy the proxy ESB didn’t suspended at the breakpoints. That is because when the configuration changed in the ESB Server all breakpoint information will be lost. So if we want to debug it we have to re send the breakpoints. For that you only need to right click on ESB diagram editor and in the context menu you will see command Resend ESb Breakpoints. Thats it.

 

resendclose.png

We will discuss more on other features of WSO2 ESB Mediation Debugger in the next post. Since this covers the how to debug ESB Mediation you can also self observe the other features.

You can try this and report the bugs and suggest improvements from the following link as JIRAs.

 

How to Install Developer Studio ESB Tool

How to Install Developer Studio ESB Tool

As you may already know WSO2 have changed the product strategy to provide a runtime along with tooling and analytics. So now on wso2 each product will come with a runtime, tooling and analytics.

Screen Shot 2015-12-08 at 1.11.43 PM
WSO2 Product Strategy

For example for the latest product ESB you will find three components.

  • Runtime : WSO2 ESB 5.0.0
  • Tooling : WSO2 Developer Studio ESB Tooling 5.0.0
  • Analytics : WSO2 ESB Analytics 5.0.0

This tutorial will guide you install WSO2 Developer Studio ESB Tooling with the new tooling strategy.

New WSO2 Developer Studio Tooling Strategy

WSO2 Developer Studio also moved in to a kernel-based model with its new architecture revamp in version 4.0.0. WSO2 Developer Studio Kernel provides a set of common plug-ins, which can be used to develop Eclipse plug-ins for WSO2 products that are based on WSO2 Carbon platform.  All the product specific plug-ins will use the Developer Studio Kernel as the base for their respective tooling implementation.

If you have used WSO2 Developer Studio you know that previous versions include tooling support for create many WSO2 product artifacts. But actually a user may not need tooling support for all of these products. User may only use few products in the production. So now onwards user can select what he only needs and install those.

So now you can install only the ESB tooling support with developer studio. There are several ways to get this done.

  1. Install on top of Eclipse distribution
  2. Install on top of WSO2 Developer Studio Kernel
  3. Download the WSO2 Developer Studio ESB Tool Installed Distribution

1. Install on top of Eclipse distribution

Lets install WSO2 Developer Studio ESB Tooling 5.0.0.

First we need to have a compatible Eclipse Distribution. WSO2 Developer Studio ESB Tooling 5.0.0 is based on WSO2 Developer Studio Kernel 4.1.0. As WSO2 Developer Studio Kernel based on Eclipse mars ( Eclipse 4.5) we need to have Eclipse Mars distribution. You  can download it from here. Download the respective version according to your OS.

Now you have the Eclipse compatible eclipse distribution to install WSO2 Developer Studio ESB Tooling. You can download the beta2 composite P2 from here. Composite P2 will contain both ESB tooling and Developer Studio kernel features bundled together. So You can directly install the downloaded composite p2 in Eclipse.

Following are the steps to install composite p2 to Eclipse.

  1. Goto Eclipse help->Install New Software… installNewSoftwareClose
  2. Add composite P2 as a repositoryinstallDialogAddRepository
  3. Click Archive button and select the composite p2 form the file system
  4. selectcompositezipThen software installation dialog will show the feature list of the composite p2. Select all features.esbtoolfeatures
  5. Remove the check of Contact all update sites check box and click the next button.untickbutton
  6. Then you will ask to accept license of the software and to restart after installation.

After restating the Eclipse you will have a Eclipse with WSO2 Developer Studio ESB Tooling capabilities.

 

2. Install on top of WSO2 Developer Studio Kernel

If you already have a Eclipse with WSO2 Developer Studio Kernel, you only need to install  ESB Tooling features. You can download the beta2 main p2 of WSO2 Developer Studio ESB Tooling from here.

You can install the downloaded main p2 on WSO2 Developer Studio Kernel by following the above mentioned steps.

3. Download the WSO2 Developer Studio ESB Tool Installed Distribution

If you don’t have a compatible eclipse distribution you can download WSO2 Developer Studio ESB Tooling install distribution which contain Eclipse distribution, developer studio kernel and esb tooling together. You only need to extract and run.

You can see the all beta2 release in here.

Download Links

 

 

How to Change the Default Editor in the WSO2 Developer Studio

How to Change the Default Editor in the WSO2 Developer Studio

WSO2 Developer Studio is an Eclipse-based SOA development environment for develop artifacts and deploy them in WSO2 products. Generally it provides both diagram editor and source editor to create artifacts as shown in the following diagrams.

sourceEditor
Source Editor
diagramEditor
Diagram Editor

Preference can be changed from developer to developer which editor to use. So developer studio now provides the capability to select the preferred editor as the default editor and continue developing as developer’s preference.
Following are the steps to change the default editor.

  1. Go to Eclipse preferencespreferencetabclose
  2. Go to File Associations property viewfileAssociationsclose
  3. Select *.xml file type and it will show associated editors list.associatedEditors
  4. To change it to XML Editor as the default editor select XML Editor from the Associated editors list and select as Default.setXMLasdefualt
  5. Then XML editor will come to the top of the list and then click OK button to close preference dialog.finishclose
  6. After configuring as above when you open an artifact it will open with XML editorxmleditorview

If you want to change the default editor back to ESB diagram editor, you can follow the same steps and set the ESB Editor as the default editor.