axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <>
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
- It is necessary to have support for the servlet environment (i.e.
- 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.


On Fri, Apr 2, 2010 at 07:29, Samisa Abeysinghe
<> 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 <>
> 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]
>> [2]
>> [3]
>> [4]
>> [5]
>> [6]
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> --
> Samisa Abeysinghe
> Director, Engineering - WSO2 Inc.
> - "lean . enterprise . middleware"

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message