Showing posts from 2016

Java - String intern() Method

String Intern method returns an individual representation for the given String object. When the intern() method get invoked on a String object, it will look up the other interned strings, and if a String object exists in the memory with the same content, it will return the existing reference. Otherwise, it will return a new reference.

Example usage of String intern:

Think about a web application with a caching layer. If cache got missed, it would go to the Database. When the application is running with the high level of concurrency, we should not send all the request to the database. Such a situation we can check whether, multiple calls coming to the same reference by checking String intern.


String name1 = "Value";
String name2 = "Value";
String name3 = new String("Value");
String name4 = new String("Value").intern();

if ( name1 == name2 ){
    System.out.println("name1 and name2 are same");
if ( name1 == name3 ){

Service Discovery with WSO2 Governance Registry

This blog post explains about the service discovery capability of WSO2 Governance Registry. If you have heard about UDDI and WS-Discovery, we used those technologies to discover Services during 2009-2013 time.

What is UDDI:

UDDI stands for Universal Description, Discovery, and Integration. It is seen with SOAP and WSDL as one of the three foundation standards of web services. It uses Web Service Definition Language(WSDL) to describe the services.

What is WS-Discovery:

WS-Discovery is a standard protocol for dynamically discovering service endpoints. Using WS-Discovery, service providers multicast and advertise their endpoints with others.

Since most of the modern services are REST based, above two approaches are considered as dead nowadays. Both UDDI and WS-Discovery target for SOAP based services and they are very bulky. In addition to that, industry is moving from Service Registry concept to Asset Store(Governance Center), and people tend to use REST API and Discovery clients.

How Disc…

Maven Compiler Plugin

The Maven Compiler Plugin is used to compile the java source code of your project. The default compiler is javac and is used to compile Java sources. By modifying pom.xml file, you can customize the default behavior of Maven Compiler Plugin. 

Using Maven Compiler Plugin, you can compile the source code of a certain project to a different version of JVM than what you are currently using. EX: compile using JDK 1.8 and target JVM is 1.7. Default source setting is JDK 1.5, and the default target setting is JDK 1.5

Example configuration is as below:

<build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.5.1</version> <configuration> <source>1.7</source> <target>1.7</target> </configuration> </plugin> </plugins…

G-Reg and ESB integration scenarios for Governance

WSO2 Enterprise Service Bus (ESB) employs WSO2 Governance Registry for storing configuration elements and resources such as WSDLs, policies, service metadata, etc. By default, WSO2 ESB shipped with embedded Registry, which is entirely based on the WSO2 Governance Registry (G-Reg). Further based on the requirements, you can connect to a remotely running WSO2 Governance Registry using a remote JDBC connection which is known as a ‘JDBC registry mount’.

Other than the Registry/Repository aspect of WSO2 G-Reg, its primary use cases are Design time governance and Runtime governance with seamless lifecycle management. It is known as Governance aspect of WSO2 G-Reg. So with this governance aspect of WSO2 G-Reg, more flexibility is provided for integration with WSO2 ESB.

When integrating WSO2 ESB with WSO2 G-Reg in governance aspect, there are three options available. They are:

1). Share Registry space with both ESB and G-Reg
2). Use G-Reg to push artifacts into ESB node
3). ESB pulls artifacts fro…

Lifecycle Management with WSO2 Governance Registry

SOA Lifecycle management is one of the core requirements for the functionality of an Enterprise Governance suite. WSO2 Governance Registry 5.2.0 supports multiple lifecycle management capability out of the box. Also, it gives an opportunity to the asset authors to extend the out of the box lifecycle functionality by providing their own extensions, based on the organization requirements. Further, the WSO2 Governance Registry supports multiple points of extensibility. Handlers, Lifecycles and Customized asset UIs(RXT based) are the key types of extensions available.


A lifecycle is defined with SCXML based XML element and that contains,
A name One or more statesA list of check items with role based access control One or more actions that are made available based on the items that are satisfied 
Adding a Lifecycle
To add a new lifecycle aspect, click on the Lifecycles menu item under the Govern section of the extensions tab in the admin console. It will show you a user interface …

How to disable Registry indexing

Sometimes people complain that they have seen background DB queries executed by some WSO2 products(EX: WSO2 API Manager Gateway profile). These query executions are not harmful, and those correspond to registry indexing task that runs in the background.

It is not required to enable indexing task for APIM 1.10.0 based Gateway or Key Manager nodes. So you can disable the indexing task by setting "startIndexing" parameter as false. This "startIndexing" parameter should be configured in the registry.xml file under "indexingConfiguration" section.

Ex: <indexingConfiguration> <startIndexing>false</startIndexing> ...... </indexingConfiguration>

WSO2 Governance Registry: Support for Notification

With WSO2 Governance Registry 5.x releases, now you can send rich email messages when email notification is triggered in WSO2 Governance Registry with the use of email templating support we have added. In the default implementation, administrator or any privileged user can store email templates in “/_system/governance//repository/components/org.wso2.carbon.governance/templates” collection and the template name must be same as the lower case of the event name.

For an example if you want to customize “PublisherResourceUpdated” event, template file should be as: “/_system/governance/repository/components/org.wso2.carbon.governance/templates/publisherresourceupdated.html”.

If you do not want to define event specific email templates, then you can add a template called “default.html”.

By default, $$message$$ message section in email templates will be replaced with the message generated in the event.

How can I plug my own template mechanism and modify the message?

You can override the def…