Hi All, I think as a better solution for this is to go with the current ServiceDeployer class. Because, while trying to implement the custom deployer, I find that lot of code will be duplicated from ServiceDeployer class since this deployer will also process aar files. So the solution would be to, Let the service be deployed as a normal axis2 service and let's initialize the spring application context and load the beans only when the service is first invoked. For this to work, we have to implement a ServiceObjectSupplier which will call a getSpringContext method. In this method we can check whether the current service holds a context in it and if it doesnot hold we can initialize a new one. Also we can stop the initialization of spring appContext for every service invocation by adding the spring appContext as a parameter at first service call. Since we already have a service object supplier class (SpringAppContextAwareObjectSupplier), we can use that for the above purpose. Im adding a patch for this in the issue[1] created on the $subject. This solution expects a service parameter “SpringContextLocation”, which is the path of the appContext.xml file. This parameter can be set in the services.xml file.
With this solution, the users do not have to initialize spring by implementing ServiceLifeCycle class and running it on start-up. Spring context initialization is moved inside spring module. I have introduced a util class which will supply the applicationContext on when the service in invoked. This will also remove the need for the ApplicationContextHolder class. Also axis2 is depending on old version of spring framework (2.5.1), so migrating this version to the latest (3.1.0.RELEASE). Please review the patch. Thanks, Kishanthan. [1] https://issues.apache.org/jira/browse/AXIS2-5231 On Wed, Jan 11, 2012 at 4:56 PM, Kishanthan Thangarajah < [email protected]> wrote: > Hi Sagara, > > On Wed, Jan 11, 2012 at 12:33 PM, Sagara Gunathunga < > [email protected]> wrote: > >> >> >> On Tue, Jan 10, 2012 at 12:43 PM, Kishanthan Thangarajah < >> [email protected]> 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 > below, > 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, > > >> Thanks ! >> >> >>> >>> >>> Please give your feedback on the above suggestions. >>> >>> Thanks, >>> Kishanthan. >>> >>> >>> On Tue, Jan 10, 2012 at 11:02 AM, Isuru Suriarachchi >>> <[email protected]>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 < >>>> [email protected]> 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] http://axis.apache.org/axis2/java/core/docs/spring.html#a262 >>>>> [2] >>>>> http://svn.apache.org/repos/asf/axis/axis2/java/core/trunk/modules/spring/src/org/apache/axis2/extensions/spring/receivers/ApplicationContextHolder.java >>>>> >>>> >>>> >>>> >>>> -- >>>> Technical Lead, >>>> WSO2 Inc. http://wso2.org/ >>>> Blog : http://isurues.wordpress.com/ >>>> >>> >>> >> >> >> -- >> Sagara Gunathunga >> >> Blog - http://ssagara.blogspot.com >> Web - http://people.apache.org/~sagara/ >> LinkedIn - http://www.linkedin.com/in/ssagara >> > >
