So we discussed the need to list the objectives of this effort on the other thread. Have we defined those.
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"
