Skip to main content

WSO2 App Factory - Developing New Application Type


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/dropins

And then you can edit the order of your handler by mentioning the necessary priority in the appfactory configuration which can be found in the following location.

$APPFACTORY_HOME/repository/conf/appfactory/appfactoy.xml

In this configuration file you can find a tag named EventHandlers. You can insert a new tag to this place with the name of your handler class name and set the desired priority value as it is done for other handlers.

Figure 1 : Event Handlers Priority Settings

Maven Archetype creation for App Factory Applications

In WSO2 App Factory when we create an application we generate a sample code for that application. This is done using maven archetypes. We have created a maven archetype for all apptypes. Maven archetypes can be created for non maven applications as well. For an example even for .NET app type we are having a maven archetype even though its built using MS Build.

[5] describes how to create a maven archetype. And you can also take some hints from my previous post [7] for maven archetype creation. When we create an archetype for WSO2 AppFactory we have to add few more resources in to it. That is for the initial deployment. This initial deployment phase was introduced to reduce the time spent to create an application. So what happens there is we include built artifacts in to the maven archetype and we bundle them using assembly plugin and deploy the created artifact[6].

Figure 2 shows the tree structure of web application archetype. I use this to explain since this is the simplest and common structure. Here archetype-resources folder contains the content of the archetype. Apart from the src directory you can see there is a directory named built_artifact. This is the place that we use to keep built artifacts that we are going to keep to create the initial artifact using maven assembly plugin. And the assembly.xml and the bin.xml placed at the same level will be used to run maven assembly plugin and create the initial artifact.

Figure 2 : Tree structure of Web app archetype

You can see the assembly.xml and bin.xml here. When we trigger follwing command on this folder it will create an .war file with the content of the built_artifact folder and will copy it to a folder named  ${artifactId}_deploy_artifact which is located one level outside the application code. And in the initial deployment phase it will pick this artifact to deploy.

mvn clean install -f assembly.xml

Figure 3 : bin.xml

Figure 4 : assembly.xml

Figure 5 is the structure of maven archetype for ESB apptype which is the most complex apptype created in WSO2 AppFactory up to now. Here you can see that there is no assembly.xml and bin.xml and instead of that there is a pom.xml inside built_artifact folder and bin.xml is also there in the same level. So we have run following command inside the built_artifact folder and how this extension can be done will be described in later in this article.

mvn clean install

Figure 5 : Tree structure of ESB maven archetype


Extending the Application Type Processor Interface

Application Type Processor interface can be found at [8]. AbstractApplicationTypeProcessor is an abstract implementation of the interface which is recommended to use[9]. But there could be cases where that it needs to be implemented from the beginning. This processor is triggered in several places which will do something specific to an application type.

When we create an application when the repository get initiated[2], generateApplicationSkeleton method will get invoked. In [9] it is calling a method initialDeployArtifactGeneration which is not mentioned in the interface but anyone extending [9] can override that. The behavior I mentioned in the earlier section about ESB apptype initial artifact generation.

Extending Deployer Interface

The Deployer Interface [10] will be used to deploy the artifacts to the PaaS Artifact repository. Underlying PaaS will be the responsible one to copy it to the actual running server instance. If you need to do something special with your apptype you can use this interface. Anyway again the recommended class to extend is AbstractDeployer [11]. Most common use of this will be changing the artifacts that you choose to deploy. So you can override getArtifact method in [11] so it will select the artifacts to deploy in your algorithm.

And the next thing would be Initial Artifact Deployment. As I explained earlier WSO2 AppFactory will deploy an initial artifact generated directly from the archetype generated code. So this is usually done using the class InitialArtifactDeployer [12]. But if you want to change some behavior of this class then again you can extend this class [12] and add it to WSO2 AppFactory and mention it in apptype (apptype.xml) under a parameter name "InitialDeployerClassName".

References

[1] Adding a new App Type and its Runtime
[2] WSO2 Appfactory LifeCycle Of
[3] ApplicationEventsHandler.java (org.wso2.carbon.appfactory.core.ApplicationEventsHandler)
[4] DSApplicationListener.java
[5] Guide Creating Archetypes
[6] Maven Assembly Plugin
[7] How to include artifactid in folder name or content of a file
[8] ApplicationTypeProcessor.java (org.wso2.carbon.appfactory.core.apptype.ApplicationTypeProcessor)
[9] AbstractApplicationTypeProcessor.java
[10] Deployer.java (org.wso2.carbon.appfactory.core.Deployer)
[11] AbstractDeployer.java (org.wso2.carbon.appfactory.deployers.AbstractDeployer)
[12] InitialArtifactDeployer.java (org.wso2.carbon.appfactory.deployers.InitialArtifactDeployer)
Labels:

Comments

Post a Comment

Popular posts from this blog

Generate JWT access tokens from WSO2 Identity Server

In Identity Server 5.2.0 we have created an interface to generate access tokens. Using that we have developed a sample to generate JWT tokens. You can find that sample under msf4j samples[1][2]. If you are build it as it is you will need to use Java 8 to build since msf4j is developed on Java 8. So you will need to run Identity Server on Java 8 as well. After building the project[2] please copy the jar inside target directory to $IS_HOME/repository/components/dropins/ directory. And then please add the following configuration to Identity.xml which is placed under $IS_HOME/repository/conf/identity/ folder inside tag OAuth . <IdentityOAuthTokenGenerator>com.wso2.jwt.token.builder.JWTAccessTokenBuilder</IdentityOAuthTokenGenerator> Then go to the database you used to store oauth tokens (This is the database pointed from the datasource you mentioned in the $IS_HOME/repository/conf/identity/identity.xml) and then alter the size of the column ACCESS_TOKEN of the tab
6 comments
Read more

Oauth custom basic authenticator with WSO2 IS 5.1.0

WSO2 Identity Server supports Oauth2 authorization code grant type with basic authentication OOTB. But basic authentication is done only with WSO2 user store. So there could be use cases that basic authentication has to be done against some other system. In this case you follow below steps to achieve your requirement. First you need to create an class which extends AbstractApplicationAuthenticator and implements LocalApplicationAuthenticator. Because this class is going to act as your application authenticator so it needs to be an implementation of application authenticator interface and to achieve this it needs to be a local authenticator as well. [2] public class CustomBasicAuthenticator extends AbstractApplicationAuthenticator implements LocalApplicationAuthenticator {   Then you need to override the initiateAuthenticationRequest method so you can redirect to the page to enter user and password. In my sample I redirected to the page that is used by our default basic au
Post a Comment
Read more

Installing gluster in AWS EKS

This article is a continuance of [1] . Purpose of this article is to document the steps, issues and solutions to those issues we have to face when installing gluster in EKS (Elastic Kubernetes Service). For gluster we need a disk to be attached with the K8s node. In EKS easiest way of implementing this is, adding it to the node configuration. So every time a node comes up, it comes up with a disk attached to the defined path. You can use this path in the topology.josn as mentioned in [1] . Next step is to install gluster using the gk-deploy script. The challenge comes here after. To use gluster in pods, you need to define a storage class. The heketi url mentioned in the storage class definition, should be accessible from master node. But the given heketi url is a cluster IP type k8s service. But in EKS deployments masters are managed by AWS and master don't have access to cluster IPs. So how we can solve this? Actually I tried to contact AWS support on this and I didn't got
Post a Comment
Read more