axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <>
Subject [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Date Thu, 01 Apr 2010 21:16:34 GMT

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

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

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.



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

View raw message