WSO2 Products are based on WSO2 Carbon platform + set of features. (Carbon platform is also a collection of features) So, WSO2 products are released with set of pre-bundled features. For example, WSO2 Identity Server comes with System and User Identity Management feature, Entitlement Management features etc. API Manager comes with API management features, and features related to publishing and managing APIs etc. There can be requirement where the Key management features found in API Manager, need to be handled in the Identity Server itself, without going for a dedicated API Manager (Key manager) node. In such a scenario, you can install key management features into Identity Server.
Feature installation / management can be done via Management console UI [1] or using pom files [2]
In this blog post I'm presenting another way of installing features, that is via a Java based client.
This method can be used in situations where you have an automated setup to provision nodes with required features. You can find the code for that client in github.
[1] https://docs.wso2.com/display/Carbon420/Installing+Features+via+the+UI
[2] https://docs.wso2.com/display/Carbon420/Installing+Features+using+pom+Files
Friday, March 20, 2015
Thursday, December 18, 2014
Puppet configs
Puppet master
server name in /etc/puppet/puppet.conf is not needed
set autosign=true in /etc/puppet/puppet.conf
Obtain the puppet master hostname by executing "hostname -f"
Puppet agent
Set the proper puppet hostname in /etc/puppet/puppet.conf which is obtained in the previous command, if that is resolvable. Otherwise need to add that hostname into /etc/hosts file
agent's hostname can be any value. No need to have master's hostnames init. puppet agents hostname need to be resolvable. for eg, to 127.0.0.1
server name in /etc/puppet/puppet.conf is not needed
set autosign=true in /etc/puppet/puppet.conf
Obtain the puppet master hostname by executing "hostname -f"
Puppet agent
Set the proper puppet hostname in /etc/puppet/puppet.conf which is obtained in the previous command, if that is resolvable. Otherwise need to add that hostname into /etc/hosts file
agent's hostname can be any value. No need to have master's hostnames init. puppet agents hostname need to be resolvable. for eg, to 127.0.0.1
Wednesday, October 8, 2014
Code Analysis with SonarQube Eclipse Plugin
SonarQube is a cool platform which helps to maintain code quality of a project, through integration of several code analysis tools like PMD, FindBugs, Checkstyle etc. Code quality of Apache Stratos
project is also measured and maintained through SonarQube.
Committers and contributors of Apache Stratos project are advised to have their code analysed through SonarQube before committing any new code or sending a PR.
There is an Eclipse plugin which makes developers' life easier, to run an analysis and find out code if there's any code quality issues, and fix without moving away from Eclipse.
I have recently written a wiki entry on how to configure and use SonarQube Eclipse plugin to analyse your code for Apache Stratos, you can find it here
Friday, February 28, 2014
MySQL ERROR 1045 (28000): Access denied for user 'username'@'localhost' (using password: YES)
Answer is, :)
You probably have an anonymous user
refer : http://stackoverflow.com/questions/10299148/mysql-error-1045-28000-access-denied-for-user-billlocalhost-using-passw
Then delete those anonymous users,
mysql> DELETE FROM mysql.user WHERE User='';
mysql> flush privileges;
Done..!
You probably have an anonymous user
''@'localhost'
or ''@'127.0.0.1'
.refer : http://stackoverflow.com/questions/10299148/mysql-error-1045-28000-access-denied-for-user-billlocalhost-using-passw
Then delete those anonymous users,
mysql> DELETE FROM mysql.user WHERE User='';
mysql> flush privileges;
Done..!
Saturday, August 31, 2013
WSO2 ESB - Adding complex SOAP headers to a message
WSO2 ESB comprises of about 40+ mediators, using which you can perform several actions on the the SOAP messages being passed through. One such requirement would be to manipulate SOAP headers of a message.
What if you need to add a complex header structure to the message as follows,
A real use case of this kind of a requirement will be, you have a secured proxy service in ESB with UsernameToken Policy applied, but the backend service is not secured according to WSSE standards, but having its own way of authenticating, hence it requires messages coming to that endpoint having the structure of the headers as above, and username and password header values need to set with the username and password contains in the WSSE usernameToken of the original request.
That can be achieved using a class / custom mediator which involves writing some Java code, but if you need to avoid deploying / maintain a separate package for that you can chose either Header mediator, XSLT mediator or Script mediator.
Here I'm going to show how the script mediator can be used for the above use case.
Since you have enabled WS security in the proxy service, a valid SOAP request needs to contain the WSSE security headers, as follows.
As highlighted in the above request message, you have to extract the username and password values coming in the request and set those in the header structure which is expected by the backend service.
In order to do that your Script Mediator configuration will be as follows,
That's it..! If you do a full log in insequence you will see the message with added complex headers.. In a future post I Will show you how to use Header mediator and XSLT mediator to achieve the same task.
References
[1] http://docs.wso2.org/display/ESB470/Script+Mediator
[2] http://wso2.com/project/mashup/0.2/docs/e4xquickstart.html
What if you need to add a complex header structure to the message as follows,
A real use case of this kind of a requirement will be, you have a secured proxy service in ESB with UsernameToken Policy applied, but the backend service is not secured according to WSSE standards, but having its own way of authenticating, hence it requires messages coming to that endpoint having the structure of the headers as above, and username and password header values need to set with the username and password contains in the WSSE usernameToken of the original request.
That can be achieved using a class / custom mediator which involves writing some Java code, but if you need to avoid deploying / maintain a separate package for that you can chose either Header mediator, XSLT mediator or Script mediator.
Here I'm going to show how the script mediator can be used for the above use case.
Since you have enabled WS security in the proxy service, a valid SOAP request needs to contain the WSSE security headers, as follows.
As highlighted in the above request message, you have to extract the username and password values coming in the request and set those in the header structure which is expected by the backend service.
In order to do that your Script Mediator configuration will be as follows,
That's it..! If you do a full log in insequence you will see the message with added complex headers.. In a future post I Will show you how to use Header mediator and XSLT mediator to achieve the same task.
References
[1] http://docs.wso2.org/display/ESB470/Script+Mediator
[2] http://wso2.com/project/mashup/0.2/docs/e4xquickstart.html
Saturday, March 2, 2013
If your laptop's touchpad suddenly stopped working...
If you are working in Linux (Ubuntu) execute the following command,
gconftool-2 --set --type boolean /desktop/gnome/peripherals/touchpad/touchpad_enabled true
gconftool-2 --set --type boolean /desktop/gnome/peripherals/touchpad/touchpad_enabled true
Thursday, December 27, 2012
WSO2 Stratos 2.0 Alpha - Released !
Its was a great moment, before the year end 2012 we were able to release an Alpha version of long awaited WSO2 Stratos 2.0, and It was a great experience to be in part of the Stratos 2.0 team.
Stratos 2.0 is the next version of Stratos 1.x, and provides features including,
I will explain further on Stratos 2.0 architecture and functionality in future posts.
For more details you can refer to [1]
[1] http://www.mail-archive.com/dev@wso2.org/msg12504.html
Stratos 2.0 is the next version of Stratos 1.x, and provides features including,
- Git / Git-hub integration support
- Pluggable cartridges ( PHP, MySQL and WSO2 carbon cartridges)
- Autoscaling into EC2 or Openstack
- Custom Domain Mapping support
I will explain further on Stratos 2.0 architecture and functionality in future posts.
For more details you can refer to [1]
[1] http://www.mail-archive.com/dev@wso2.org/msg12504.html
Subscribe to:
Posts (Atom)