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 Wed, 11 Jan 2012 11:26:18 GMT
Hi Sagara,

On Wed, Jan 11, 2012 at 12:33 PM, Sagara Gunathunga <> wrote:

> On Tue, Jan 10, 2012 at 12:43 PM, Kishanthan Thangarajah <
>> wrote:
>> Hi All,
>> When considering a custom deployer for the $subject, t he 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”.
>>  I don't like the idea of creating more directories on repository , in
> this case two directories hold .aar files (services and spring). Instead it
> would be great if we can do this based on parameter on service.xml file and
> use same "services" directory. definitely this involve some kind of a
> deployer extension modification.

Yes, according to my previous mail, if we go with “.aar” extension and
“spring” repository directory, we will have two directories having aar
files. If we are to use the same directory(“services”) for the deployer,
then we will have to register the deployer with a new extension. Since we
are using spring to develop the services, how about naming it as “Spring
Archive (SAR)”?. So then the extension would be “.sar”. There won't be any
major difference between an “.aar” file and a “.sar” file. The sar file
will additionally contain the spring application context file. Is there a
better way for doing the above?

> Frankly speaking i don't have any concrete design for above but may be you
> can do more investigation for a better solution.
Well, as I was going through the spring service deployment I had the idea
Let the service be deployed as a normal axis2 service. So
spring framework will not get initialized. Then when the service is first
invoked, let's initialize the spring application context and load the
beans. We can add the spring appContext, which was initialized, as a
parameter at first service call and later retrieve it to get the beans. But
I thought this is not the correct way as the spring context should be
initialized during the service deployment time rather than when the service
is called.


> Thanks !
>> Please give your feedback on the above suggestions.
>> Thanks,
>> Kishanthan.
>> 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
>>>> 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 :
> --
> Sagara Gunathunga
> Blog      -
> Web      -
> LinkedIn -

View raw message