axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kishanthan Thangarajah <>
Subject Re: Deploying multiple spring service axis2 archives(AAR)
Date Tue, 10 Jan 2012 07:13:45 GMT
Hi All,

When considering a custom deployer for the $subject, the following has to
be noted,

   1. Loading the spring applicationContext.xml file – since the spring
   initialization and defining of beans are done in the deployer, we can get
   this file(path of this file) via a service parameter which can be set in
   the services.xml.
   2. When registering the custom deployer in axis2.xml, we have to give an
   extension and a directory. Since we are going to process AAR files we can
   give the extention as “.aar”. For the repository directory, we can name it
   as “spring”.

Please give your feedback on the above suggestions.


On Tue, Jan 10, 2012 at 11:02 AM, Isuru Suriarachchi <>wrote:

> +1
> Requirement to initialize the spring framework by the service author and
> the need to include the spring dependency in each and every spring service
> are two major drawback in our spring services functionality. Therefore, I
> think this will be a very good improvement.
> Thanks,
> ~Isuru
> On Fri, Jan 6, 2012 at 10:35 AM, Kishanthan Thangarajah <
>> wrote:
>> Hi devs,
>> I have been looking at deploying multiple spring services as AAR's within
>> a single axis2 container. Current issue with adding multiple service is
>> that when we add a second service, the first one does not work or rather
>> the deployment of the second service breaks the first. This is because of
>> the static nature of spring ApplicationContext variable in
>> ApplicationContextHolder class. According to documentations [1], the spring
>> framework for a service is initialized via a service class which implements
>> the ServiceLifeCycle interface. So the startUp method of this class will be
>> called by the axis2 service builder. In this method only, the spring
>> application context is created with the applicationContext.xml file. The
>> beans defined in the context file will be defined in this context and the
>> context will be set to the static ApplicationContext variable of the
>> ApplicationContextHolder class [2]. When a second service deployed the same
>> operations mentioned above will happen and finally the spring
>> ApplicationContext of the first service will get replaced by the second
>> service's ApplicationContext. So if you invoke the second service it works,
>> but when invoking the first service, it gives an error as no defined beans
>> are found.
>> We have a workaround for this issue in axis2 by adding the axis2-spring
>> jar and spring framework jars in /lib directory of each service. So for
>> each service, we get a separate spring framework and spring application
>> context loaded. So we will not get into the issue as each service will have
>> its own application context holder. I think that this is not a correct way
>> and I feel that there has to be better solution other than above mentioned.
>> Requirements I see for a better solution are,
>> 1) Currently the users has to initialize spring context via implementing
>> ServiceLifeCyle. But the spring initialization part should be moved to
>> axis2 and let users only deal with the business logic of the service rather
>> than depending on loading spring first.
>> 2) Having separate spring framework loaded for each service is not a good
>> idea if we are deploying a large amount of services. Because we will have
>> to include spring jars and axis2-spring jar in service's classpath for
>> every service.
>> So as a solution, I think we can write a deployer which takes control of
>> spring service (AAR) deployment and in this we can create the spring
>> application context for the spring service and add this as a parameter to
>> the service. So for each service deployed, there will be a new spring
>> context initialized and it will be isolated from other spring service's
>> application context. When the service later invoked we can get the spring
>> application context for this service by getting the parameter and then
>> retrieve the service object(spring beans) from this context. Also we will
>> not have to include spring framework for each service we are deploying.
>> WDYT?
>> Thanks,
>> Kishanthan
>> [1]
>> [2]
> --
> Technical Lead,
> WSO2 Inc.
> Blog :

View raw message