Social Icons

twitterfacebookgoogle pluslinkedinrss feed

Featured Posts

Saturday, January 17, 2015

WSO2 API Manager - Changing the default token expiration time

In WSO2 API Manager, expiration period of all the access tokens is set to 60 minutes (3600 seconds) by default. However, you can modify the default expiration period value using identity.xml file located in <APIM_HOME>/repository/conf/ directory.

In the identity.xml file you can see separate configurations to modify default expirations of User tokens and application access tokens.


If you are planning to modify the validity period of appliccation access token, then you have to modify the default value of the <ApplicationAccessTokenDefaultValidityPeriod> element in identity.xml file. Changing the value of <ApplicationAccessTokenDefaultValidityPeriod> will not affect for existing applications which have alreday generated application tokens. So when you regenerate the application token, it will pick the token validity time from the UI. Therefore, for applications which has already generated tokens, token validity period needs to be changed from the UI as well. However, when you are creating a new application or when you generating the token for the first time, it will pick the token validity period from the identity.xml file.


If you are planning to modify the validity period of user token, then you need to update value of the <UserAccessTokenDefaultValidityPeriod> element in identity.xml file. The User token validity period will get updated when user generating and refreshing the token.

Sunday, December 21, 2014

Configurable Governance Artifacts - CURD Operation

Please refer my previous post which explain about Configurable Governance Artifacts in WSO2 Governance Registry.

Once you have added an RXT, it will generate HTML based List and Add view. Also it will be deployed as an Axis2 based service with CRUD operations. For example, when you upload contact.rxt, there will be a Contact Service exposed with CRUD operations. Using provided CRUD operations, external client applications(php, .net,etc) can perform registry operations.

Below is an example CRUD operations provided for Contact RXT which we created in my previous post(RXT Source).
  • addContact - create an artifact in the type Contact .
  • getContact - retrieve an artifact in the type Contact .
  • updateContact - update an artifact in the type Contact .
  • deleteContact - delete an artifact in the type Contact . 
  • getContactArtifactIDs - get all the artifact ID s of artifacts in the type Contact .

To retrieve WSDL of the above service, we need to disable "HideAdminServiceWSDLs" in "carbon.xml" file. After that, you need to restart WSO2 Governance Registry server. Then Contract(WSDL) will be exposed like this: 


Please refer Service Client Example for more details:

Sunday, December 14, 2014

WSO2 Governance Registry - Configurable Governance Artifacts

Configurable Governance Artifacts is one of many well-defined extension points supported by the WSO2 Governance Registry. This is also known as Registry Extensions Types. This allows you to define own metadata models other than the default metadata model which is shipped with the product. This will support modeling any type of asset according to the user requirements.

When deploying Configurable Governance Artifacts in WSO@ Governance Registry, it creates a web service which supports CURD (Create, Update, Retrieve, Delete) operations. So using external web services, client application users can consume them.

Below are the main elements in RXT configuration.

  • artifactType element
  • artifactKey element
  • storagePath element
  • nameAttribute element
  • namespaceAttribute element
  • menu element
  • ui element
  • relationships element
Using above basic model, you can create/modify RXTs based on your requirement. Let’s go through a sample RXT file and understand requirements of each element one by one. For an example, let’s consider a scenario where we need to store user contact information. There we need to capture and store information such as First Name, Last Name, Birthday, Address, Organization Department, Email address, Mobile Number, etc.

Here is one of the RXT representation which we can create to capture and store above mentioned information. RXT Source

Now let’s go through the main XML elements in the above sample.

artifactType element

The root element of the RXT configuration is artifactType and it has few attributes which need to be defined.

  • type - Defines the mediatype of the artifact. 
  • shortName - Short name for the artifact
  • singularLabel - Singular label of the artifact. This name is shown in the UI to display link to add new artifacts.
  • pluralLabel - Plural label of the artifact. This plural label is used when listing artifacts.
  • hasNamespace - Defines whether the artifact has a namespace (boolean)
  • iconSet - Icon set number is used for the artifact icons(from 1 to 30)
storagePath element

This element is used to define the storage path of the artifact. Users can customize storage path based on the information available. They can use some fixed attributes such as @{name}, @{namespace} and other attribute such as @{overview_version}. Above name and namespace attributes need to be mapped using nameAttribute and namespaceAttribute.

nameAttribute element

This is the identifier for name attribute used in storage path.

namespaceAttribute element

This is the identifier for namespace attribute used in storage path.

lifecycle element

This element is used to define default lifecycle of the given artifact. When creating an artifact, this lifecycle will be automatically assigned to resources.

ui element

This element is used to define list view of the artifact. Using UI element, list view is automatically generated.

relationships element
Using relationship element, we can define the association in between other artifacts and this.

content element

This is the data model of the new artifact and with information available in content element, artifact add view will be automatically generated.

Wednesday, October 08, 2014

Maven excludes all transitive dependencies

"Transitive dependencies are a new feature in Maven 2.0. This allows you to avoid needing to discover and specify the libraries that your own dependencies require, and including them automatically."

I had a problem, where some dependencies were available in the run time, but they weren't available in the public nexus repositories. For an example, Hibernate depends on the Sun JTA API JAR and it is not available in the central Maven repository because it cannot be freely redistributed. So when building the project, it was trying to download transitive dependencies and got failed.

So I looked  a way to ignore all the transitive dependencies, and found that we can ignore all the associated dependencies of a given dependency. There we can exclude all transitive dependencies without specifying groupId and artifactId of the dependencies. So need to use astric(*) character as groupid and artifactid of the dependency.


This wildcard transitive dependencies ignoring is available with maven 3.2.1 release. So it's worth to upgrade into latest maven version.