My Tech World

In next version of WSO2 AppFactory (2.2.0), it's going to introduce a new apptype ESB apptype. With this apptype, it's going allow users to develop WSO2 ESB Capps (CAR) with WSO2 AppFactory. In this article I will give you a guide line to follow when you are developing a Capp using WSO2 AppFactory. WSO2 AppFactory ESB apptype is the first multi module apptype supported by it. It will contain 4 modules in the sample project. They are as below. Resources module Resources CAR module Synapse Config (Proxy Service) module Main Car module Development There are several rules that developer should obey when developing an ESB type application. Which are as follows. Developers can add any number of modules to the project. But always there should only be two CAR modules. Which should be resources CAR and main CAR which will contain all synapse configs. All synapse config names should contain the version number. Like  foosequence-1.0.0.  And the synapse config file name a

This post will describe how to use extension points to develop an application type. In [1] you can find step by step guide of adding a new application type and its runtime. In this post I will explain following. Adding new Application Event Handlers Maven Archetype creation for App Factory Applications Extending the Application Type Processor Interface Extending Deployer Interface Adding new Application Event Handlers You can find the interface ApplicationEventsHandler in [3] Lets say you need to do some special stuff for your application type (like create a database when creating an application to support your app type), you can extend methods of this to do that. For example we are creating a datasource using an handler when we create a Data Service type application. You can find that code in [4]. After you develop your handler you can add it to an OSGI bundle and then deploy it to the AppFactory server's following location. $APPFACTORY_HOME/repository/components/dr

This post will try to explain the general life-cycle of an application in WSO2 AppFactory. WSO2 AppFactory is a place where multiple project teams can collaboratively create run and manage enterprise applications[1]. With WSO2 AppFactory users can create an complex application and push it to production within a matter of couple of hours. Figure 1 - App Cloud Create Application Page If you go to WSO2 AppFactory and create an application it will do several operations that generates the resources needed for your application such as Create Repository Generate Sample Code for the Application Create Build Job Create Issue Tracker Project Deploy initial artifact in to PAAS artifact repository etc.. When you hit create application it will create an instance of the application RXT installed in WSO2 AppFactory and then will call a bpel which is hosted in the BPS. Any one can edit this bpel to add their workflow in to it. Currently this will just trigger the AF service to trigger

Today we keep our users and profiles in several forms. Some times they are in a LDAP. Some uses Active Directory (AD). Some uses databases and etc. WSO2 Products are written in a way any of these format could support. If some one have their own way of storing users and any one can easily plug them in to WSO2 products by just writing a custom user store. In this post I will explain how these user stores works and the other components connected to them. When we discuss about user management in WSO2 world, there are several key components. They are User Store Manager Authorization Manger Tenant Manager In simple user management we need to authorize some user to some action / permission. Normally we group these actions / permissions as groups and assign these groups / roles to users. So there are two kind of mappings that we need to consider. They are User to Role Mapping Role to Permission Mapping User to Role Mapping is managed by user store implementation and Role to Perm

When we create maven archetypes, specially the multi module ones, we might need to include the artifact id in to a folder or file name or include it to a content of a file. This can be done very easily. To include artifactid to a folder or file name you just have to add the place holder __rootArtifactId__ . **Note that there are two '_' characters before and after the word rootArtifactId. So for example if  you want a file name like -development.xml, then you can simply name it as __rootArtifactId__-development.xml. When file name is mentioned like this inside the archetype, when you run archetype generate command it will replace with the artifactid provided. Next thing is how to include this inside a file. This was tricky. I couldn't find a way to do it first. So I keep trying things and it works and it's simple. You can simply add the place holder ${rootArtifactId} . In the same pattern you can use other parameters like version as well by using __version