List of general rules about artifact.xml

Below is a list of general rules which Harshana (WSO2 Tooling guru) mentioned while he was supporting us with customer queries.

1. artifact.xml files in Dev Studio Projects as well as in Composite Application Archive (CAR) files are to manage Artifact metadata. Hence they should not be manipulated manually by users.

2. artifacts list in the artifacts.xml represents the order of artifacts getting deployed in Carbon 4.2.0 based servers including ESB 4.8.0.

3. If there are ESB Message Stores and Message Processors, then Message Stores will be placed before the Message Processors in the artifacts.xml. This process is automatically happens with Dev Studio 3.5.9 version.

4. If you are using Proxy services with Publish WSDL option where the WSDL itself is included in the CAR file in form of Registry Resource or Local entry, that entry need to appear before the Proxy itself because at the time of the Deployment of the proxy, it will use the wsdl pointed as the Publish WSDL.

5. In general the order of the artifacts in artifacts.xml will be Registry Resources, Local entries, Message Stores, Message Processors, other artifact types.

How to remove these UI bundles from worker node

To remove these UI bundles from worker node, you need to run the following command from [PRODUCT_HOME]/bin:

ant createWorker

The ant task createWorker removes the following set of UI bundles:

org.wso2.carbon.*ui_*
org.wso2.carbon.*stub_*
org.wso2.stratos.*ui_*
org.wso2.stratos.*stub_*
org.jaggeryjs.*ui_*
org.jaggeryjs.*stub_*
org.wso2.carbon.ui.menu.*
org.wso2.*styles_*
org.wso2.carbon.authenticator.proxy_*


A situation where this might not work is;

If you have used -DapplyPatches parameter to start ESB node at some point!! If so it will backup the original jar files in [PRODUCT_HOME]/repository/components/plugins to [PRODUCT_HOME]/repository/components/patches/patch0000 folder. In the next server startup these jars will get replaced in [PRODUCT_HOME]/repository/components/plugins. Hence, the UI bundles could appear again. If this is the case, you need to remove the UI bundles (mentioned in above comment) manually from [PRODUCT_HOME]/repository/components/patches/patch0000 folder.

After you install features from UI ..

When you install the features using the WSO2 management console it will copy the relevant jars to repository/components/plugins directory and will update the bundles.info file which is located in CARBON_HOME/repository/components/configuration/org.eclipse.equinox.simpleconfigurator/. There will not be changes to database with regard to this.

How to read properties file from custom UserStoreManager

Scenario : 

You have developed a XUserStoreManager extending an inbuilt userstoremanager implemetation (i.e. ActiveDirectoryUserStoreManager).

You need to read some configuration files from a property file, which you do not want embed in the XUserStoreManager.jar which is deployed in <IS_HOME>/repository/components/dropins

What is the best approach:

1. You can put your custom properties in <IS_HOME>/repository/conf/user-mgt.xml inside your <CustomUserStoreManager> section as below.

<Property name="customProperty">customValue</Property>

2. Put properties withing your CustomUserStoreManager configuration section. Then you can access your properties as below as in [1]

i.e.

String patterns = realmConfig.getUserStoreProperty(LDAPConstants.USER_DN_PATTERN); 

Applicable : WSO2IS-4.6.0

[1] - https://svn.wso2.org/repos/wso2/carbon/kernel/branches/4.0.0/core/org.wso2.carbon.user.core/4.0.2/src/main/java/org/wso2/carbon/user/core/ldap/ReadOnlyLDAPUserStoreManager.java

How to start CEP server without embedded cassandra

In case you need to start the CEP server without embedded Cassandra which makes is light weight CEP. You can do this, by starting the server with -Ddisable.cassandra.server.startup=true switch.

Eg:

 ./wso2server.sh -Ddisable.cassandra.server.startup=true &

useOriginalwsdl

I learnt a practical example on using 'useOriginalwsdl' parameters in an ESB proxy service which has a wsdl associated to it.  Thanks Charitha - as this was by listening to how Charitha approached and handled an ESB issue.

Firstly, there is a proxy service which is associating a wsdl and we were to access an operation in it via soap-ui. This particular wsdl-operation has a soap header specified. Issue being addressed is that the soap header is not appearing in the soap-request that was generated by soap-ui.

What we were doing to generate this request was generating ?wsdl of the proxy and using it in soap-ui.

When analyzing this auto generated wsdl (?wsdl), we found out that some of the parameters in the original wsdl are not appearing in it. This is because at the auto generation process ESB recreates the wsdl treating it as part of the proxy.

But for us to avoid this and have the wsdl syntax as its original we could use the parameter 'useOriginalwsdl'. After this correction, when the ?wsdl was used in soap-ui project we were able to see the correct request.

So when creating a proxy with a wsdl associated, if we need to make sure original wsdl is available for message invocation, we need to set useOriginalwsdl=true.
 

 Just now I read about enablePublishWSDLSafeMode  parameter in ESb proxies from one of Prabath's blog posts. Will write about it after trying the scenario.

Diagnosing if a bundle is not activated properly

Whe OSGI bundles fail to start, we should check the root cause using the OSGI commands.

• Start the server with OSGi console by using ;

sh wso2server.sh -DosgiConsole

• Once osgiConsole get started execute following command and see whether your bundle is in Active state.

osgi> ss

• Execute the following command to see whether there are any unresolved dependencies for this bundle.

osgi> diag <your_bundle_id>

WSO2 Mashup Server - Service Life Cycle support

The life cycle support in WSO2 Mashup Server uses the following annotations;

1. . init - To be called in deployment
2. .destroy -To be called in un-deployment
3. .undispatched -To get set by the dispatch logic when the operation to deliver the message to cannot be figured out.

The above were designed to support different implementations. Given below are the test cases I used for testing them.

Scenario 1: Checking the constructor\destructor implementation 1
Check if constructor and destructor are called at deployment/un-deployment times using the code below;














Expected Result :
- At the deployment time the function foo is called and the log should print "init".
- If you re-deploy, since the service is first undeployed and then deployed, the function foo1 is called following function foo. Therefore the log should print 'destroy' first and 'init' following it.
- If u check the WSDL2 of the service both constructor & de-structor operations should appear there.


Scenario 2: Checking the constructor\destructor implementation 2
Check if constructor and destructor are called at deployment/un-deployment times when following format is used.












Expected Result :
- At the deployment time the function foo is called and the log should print "init".
- If you re-deploy, since the service is first undeployed and then deployed, the function foo1 is called following function foo. Therefore the log should print 'destroy' first and 'init' following it.
- If u check the WSDL2 of the service both constructor & de-structor operations should appear there.


Scenario 3: Checking the constructor\destructor implementation 3
Check if constructor and destructor are called at deployment /un-deployment times when following format is used.












Expected Result :
- At the deployment time the function foo is called and the log should print "init".
- If you re-deploy, since the service is first undeployed and then deployed, the function foo1 is called following function foo. Therefore the log should print 'destroy' first and 'init' following it.
- If u check the WSDL2 of the service both constructor & de-structor operations should appear there.


Scenario 4: Checking the 'undispatcher' implementation 1
Check if 'undispatched' operation is invoked when a non-existing operation is called when 'undispatched' is given in following manner.










Expected Result :
Access an invalid operation like, https://localhost:7443/services/admin/addNamespace/fooklklllklklklk the 'undispatched should be called.


Scenario 5: Checking the 'undispatcher' implementation 2
Check if 'undispatched' operation is invoked when a non-existing operation is called when 'undispatched' is given in following manner.









Expected Result :
Access an invalid operation like, https://localhost:7443/services/admin/addNamespace/fooklklllklklklk the 'undispatched should be called.