axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sagara Gunathunga <>
Subject Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Date Tue, 06 Apr 2010 17:23:33 GMT
On Tue, Apr 6, 2010 at 10:26 PM, Amila Suriarachchi <> wrote:

> 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.
> I had some time to go through your sample code. I agree with you that
> appropriately usage of FactoryBeans and
> Namespace handlers is a better approach.
> But I think binding Configuration context to spring runtime and mange it
> using configuration files is not a good idea.
> First of all axis2.xml file is used to load the description hierarchical
> things rather than context. And configuration
> context is created after creating the axisConfiguration. If you see the
> ConfigurationContextFactory.createConfigurationContext it does some
> initialisations of modules and transports which should be there at that
> time. And also this would confuse users goes from normal axis2 to spring
> axis2.
>> There are several advantages I see in this second approach:
>> * It is more in line with the general paradigms used in Spring.
> I think this is reated to usage of  Factory beans and namespace handlers
> rather than whether the AxisConfiguration or ConfigurationContext to be
> used.
> * 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].
> please see here[1] where I have done a poc with using axisConfiguration. It
> is also just a matter of creating a
> configuration context and starting the listners.
>> * 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.
> yes. possibly but need to figure out with a working code.
>> * It would make the implementation of the servlet very easy: just
>> extend AxisServlet and look up the ConfigurationContext from the
>> Spring application context.
> If you see the AxisServlet it starts the listener manager in the init
> method. so need to override that method too. Otherwise it is enogh to
> override initConfigContext method.
>> * 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.
> yes. but no relation to whether we use ConfigurationContext or
> AxisConfiguration isn't?
>> 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.
> see the createConfigurationContext I think it assumes axisConfiguration is
> finished by the time configuration context is created. And also I think this
> would make debug the application make difficult.
> And also here are some other things I saw with your code.
> 1. It has developed as an axis2 module. I think we need to decide on this
> at first place since project structure has to change accordingly. I think we
> need to put it as a seperate project.

   +1 , I also have mentioned this idea in a different thread.

>  2. Why there is a namespace handler to
> webServiceAnnotationBeanPostProcessor. I just registered the
> WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this has
> anyside short commings?

 Yes , it is possible to define and use those beans as  in traditional bean
definition , some people prefer to this traditional style and some other
prefer namespace support . There are some advantages with namespace style
over traditional beans definition such as less number of XML codes , self
descriptive tags and also users doesn't aware with internal class names and
their properties of the framework.  When we change the internal
implementation those changes doesn't effect for the users.  [1] this post
provide more details .

Thanks ,

> thanks,
> Amila.
> [1]
>> Andreas
>> [1]
>> [2]
>> [3]
>> [4]
>> [5]
>> [6]
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog:

Sagara Gunathunga

Blog -
Web -

View raw message