When we creating the C-App and subsequently the CAR file, the registry resource server role was set to WS02 Governance Registry rather than WS02 Enterprise Service Bus. In order to make that setup work it is necessary to set it to WSO2 Enterprise Service Bus for deployment since that is actually the default role of the WSO2 ESB.
C-App’s and CAR files can have different artifacts in them, the server on which it will be deployed will just pick out the artifacts it can handle (i.e. can deploy) and will ignore the other artifacts.
But, as you might know, the WS02 ESB has Governance Registry features installed in the product. That is also the reason it actually works, the WSO2 ESB can handle registry resources when deployed via a CAR file. The only thing that is needed is to set the role to the WSO2 ESB to avoid errors.
But there is also another way, and that is by indicating server roles.
Server roles
A server role is a parameter that is present in the /repository/conf/carbon.xml file of all WSO2 products. It’s use is to determine which artifacts from a CAR file it can deploy.
Each product has a different default server role:
- WSO2 Application Server – “ApplicationServer”
- WSO2 Business Activity Monitor – “BusinessActivityMonitor”
- WSO2 Business Process Server – “BusinessProcessServer”
- WSO2 Business Rules Server – “BusinessRulesServer”
- WSO2 Data Services Server – “DataServicesServer”
- WSO2 Enterprise Service Bus – “EnterpriseServiceBus”
- WSO2 Gadget Server – “GadgetServer”
- WSO2 Governance Registry – “GovernanceRegistry”
- WSO2 Identity Server – “IdentityServer”
- WSO2 Mashup Server – “MashupServer”
Of course you cannot simply add all these roles to your WSO2 ESB since in order to make it actually work it needs the OSGi bundles of the product (installed for instance as a feature). In the case of the WSO2 ESB we can however indicate that the Governance Registry, from the WSO2 Goverance Registry product, role is also valid, allowing the default server role of a Registry Resource to be used.
Making the change
The simplest way is of course to make the change in the carbon.xml file using Notepad++ or your favourite editor. That will look something like this:
In Eclipse (see the blog about securing proxies) we can lease the Server Role as it stands and deploy the CAR file without issues.
Server Roles Manager
But there are more ways to set the Server Roles. Another one is through the Management UI of the WSO2 product.
The Server Roles Manager does what its name implies. The Manager checks the carbon.xml file for any roles defined there as well as the user / tenant specific roles in the configuration registry.
There are two types of Server Roles:
- Default – All the server roles picked from that particular product instance’s carbon.xml.
- Custom – All other server roles added by the users.
You can add any server role name you like. I’ve added the <Role>Bananas</Role> in carbon.xml and behold:
This is of course a custom server role, not a default one. Note that you cannot use underscores (_) in role names. Regular expressions can be used in the role, for example: <Role>.*</Role> means this server can act as any role.
Even more ways to set server roles
So there are three ways to set server roles:
- Using the management console
- Using carbon.xml file
- Using a system property
The third options means that at startup you add a parameter to the startup script. For instance on the command line
|
|
Or from within Developer Studio:
Note however, that in the latter case this seems to override the carbon.xml settings:
And no artifacts will actually be deployed since there are no server roles it understands.
Adding the EnterpriseServiceBus role from the UI does not work.
Adding all roles does allow the CAR to be deployed but the UI only shows the oranges and prunes role.
Caveat Emptor
In this case, playing around with the server roles as parameters screwed up the ESB to the extent that a new copy of the ESB needed to be installed since the server roles were messed up in the registry. So be careful when adding server roles, especially when combining methods.
Once you use the management console to set server roles, you can’t change that configuration using the other two methods. Server roles are stored in the Registry when they are configured through the management console. Values in the Registry are always given priority over others.
If you have any questions about this post contact us via the comments section of this blog. View also our other WSO2 Tutorials, webinars or white papers for more technical information. Need support? We do deliver WSO2 Product Support, WSO2 Development Support, WSO2 Operational Support and WSO2 Training Programs to help you with for instance managing the WSO2 server roles as explained in this post.
| WSO2TORIALS help you to change, update or improve WSO2 products and are based on our experiences with the products. WSO2TORIALS will guide you step by step with minimal knowledge required. |  |
