axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samisa Abeysinghe <samisa.abeysin...@gmail.com>
Subject Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Date Fri, 02 Apr 2010 05:29:13 GMT
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
<andreas.veithen@gmail.com>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: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
> --
Samisa Abeysinghe
Director, Engineering - WSO2 Inc.

http://wso2.com/ - "lean . enterprise . middleware"

Mime
View raw message