I think that it helps to keep the discussions more focused if we actually start to have some code. Even if the discussion about the overall goals is still ongoing, I think that there is a consensus around the following points:
- Start from scratch (and select the best parts from the existing frameworks/PoCs). - It is necessary to have support for the servlet environment (i.e. AxisServlet). - We are not doing a rewrite of Axis2, but just adding Spring support on top of it. Thus, we need somehow to manage the ConfigurationContext and AxisConfiguration objects. I suggested as a first step to use a traditional axis2.xml configuration file and JSR-181 deployment because that is extremely simple, not because these are the priorities. The third item above implies that the design question I raised in my post will arise anyway, whatever the final goals are. Andreas On Fri, Apr 2, 2010 at 07:29, 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. > 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" > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
