axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amila Suriarachchi <amilasuriarach...@gmail.com>
Subject Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Date Wed, 07 Apr 2010 05:35:30 GMT
On Tue, Apr 6, 2010 at 10:53 PM, Sagara Gunathunga <
sagara.gunathunga@gmail.com> wrote:

>
>
> On Tue, Apr 6, 2010 at 10:26 PM, Amila Suriarachchi <
> amilasuriarachchi@gmail.com> wrote:
>
>>
>>
>> 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.
>>>
>>
>> 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 Sagara. nice link.

thanks,
Amila.


>
>
> http://javamoods.blogspot.com/2009/09/spring-use-custom-namespaces.html
>
> Thanks ,
>
>
>
>>
>> thanks,
>> Amila.
>>
>>
>> [1]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>>
>>>
>>> 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
>>>
>>>
>>
>>
>> --
>> Amila Suriarachchi
>> WSO2 Inc.
>> blog: http://amilachinthaka.blogspot.com/
>>
>
>
>
> --
> Sagara Gunathunga
>
> Blog - http://ssagara.blogspot.com
> Web - http://people.apache.org/~sagara/<http://people.apache.org/%7Esagara/>
>



-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/

Mime
View raw message