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:25:50 GMT
On Fri, Apr 2, 2010 at 09:40, van Hugten, Stephan
<> wrote:
> I agree with this approach, but want to add that I already added some code for component-scanning
to [1] so it's doesn't hurt to add it to the start.

That is a very valuable contribution, but let's first start with the
most basic stuff.

> If I understand your last point correctly, I don't think this is much of an implication.
In my vision we should make convention leading anyway and in a Spring-managed environment
it shouldn't matter in which order things are configured. Order configuration should be part
of an element as attribute for instance like servlet filters.

With the traditional Axis2 configuration mechanisms, the order in
which things are set up is as follows: items from axis2.xml
(transports, message receivers, etc.), modules, services and finally
the ListenerManager. I don't think that the Axis2 runtime would
appreciate if that order is reversed... So order is important, but the
developer should not have to care about it.

> One questions remains for me; how are non-committers able to contribute? Can we send
sample code somewhere?

I think we should soon put together some initial code. We can then
start to work with patches.

> Stephan van Hugten
> [1]
> -----Oorspronkelijk bericht-----
> Van: Andreas Veithen []
> Verzonden: do 1-4-2010 23:16
> Aan:
> Onderwerp: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
> 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:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message