axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <andreas.veit...@gmail.com>
Subject Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Date Fri, 02 Apr 2010 11:12:37 GMT
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
<samisa.abeysinghe@gmail.com> 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 <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"
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org


Mime
View raw message