On Fri, Apr 2, 2010 at 10:59 AM, Samisa Abeysinghe < [email protected]> wrote:
> So we discussed the need to list the objectives of this effort on the other > thread. Have we defined those. Are the requirements mentioned in http://wiki.apache.org/axis/Axis2Spring supposed to be the objectives? Samisa... > > I feel like, this mail is more or less the first mail what was in the other > thread. > > We are back to basics??? > > Samisa... > > > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen <[email protected] > > wrote: > >> Devs, >> >> In order to get the Axis2-Spring thing started without getting lost in >> endless discussions, I propose a very simple thing as a starter: >> implement a servlet that deploys a JSR-181 annotated bean from a >> Spring application context. For simplicity let's take the Axis2 >> configuration from a classic axis2.xml file and also don't consider >> component scanning yet. Note that the code that does the second part >> (JSR-181 annotated Spring bean to Axis service) only takes a couple of >> lines and actually already exists [1]. For the first part >> (implementing the servlet that manages the Spring application context >> and the Axis2 configuration context), there is actually an interesting >> design question that I would like to discuss. Indeed, the three >> existing codebases use two different approaches to manage the >> AxisConfiguration/ConfigurationContext, and we need to select the >> better one: >> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain >> type in the application context. In the case of WSF/Spring [2] this is >> a single SpringAxisConfiguration and a single WebServices instance. In >> the case of Axis2M [3] these are the ServiceBean and ModuleBean >> instances present in the context. Note that all these classes are >> framework specific. In both frameworks, the servlet then builds the >> AxisConfiguration and ConfigurationContext instances by translating >> the framework specific beans into Axis2 objects (using patterns >> similar to the traditional axis2.xml, services.xml and/or module.xml >> processing). >> >> In my PoC I've used a different approach (Note that it doesn't have a >> servlet yet; only the standalone case is covered): the >> ConfigurationContext is itself a Spring managed bean. Obviously, since >> ConfigurationContext is not a simple JavaBean, this requires a >> BeanFactory [4]. The servlet would then only have to look up the >> ConfigurationContext which is already completely initialized by >> Spring. >> >> There are several advantages I see in this second approach: >> >> * It is more in line with the general paradigms used in Spring. >> * The standalone (i.e. non servlet) case is easily covered: since the >> ConfigurationContext is part of the application context, it is only >> necessary to instantiate a ListenerManager (the lifecycle of which is >> also managed by Spring via a FactoryBean that gets the >> ConfigurationContext injected): see [5]. >> * This will also make support for the client side easier, since we >> need a ConfigurationContext as well to create the stub or the JAX-WS >> dynamic proxy. >> * It would make the implementation of the servlet very easy: just >> extend AxisServlet and look up the ConfigurationContext from the >> Spring application context. >> * Last but not least, it also implies that the components that deploy >> the services (or modules if we want to support that) are completely >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this >> class is only known by the bean definition parser and (indirectly) the >> namespace handler. On the other hand, the servlet itself doesn't need >> to know anything about it. This fact makes the framework much easier >> to extend: if somebody comes up with new ways to deploy things, there >> is no need to change the core; it is sufficient to add a FactoryBean >> and the corresponding namespace handling stuff. >> >> The only potential issue I see is that compared to WSF/Spring and >> Axis2M, this approach provides less control (at least out of the box) >> about the order in which things are added to the >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the >> possible implications of this. >> >> Andreas >> >> [1] >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java >> [2] >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java >> [3] >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java >> [4] >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java >> [5] >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java >> [6] >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> -- > Samisa Abeysinghe > Director, Engineering - WSO2 Inc. > > http://wso2.com/ - "lean . enterprise . middleware" > > Samisa... -- blog: http://samisa-abeysinghe.blogspot.com/
