Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181

[Tharindu Mathew <th...@wso2.com>]

Hi everyone,

I've added some code to support loading axis2 configuration through an xml
(attached). How can we contribute patches and develop on this code base? I
think Stephen had the same concern.

On Tue, Apr 27, 2010 at 5:36 PM, Tharindu Mathew <th...@wso2.com> wrote:

> Hi everyone,
>
> It's been sometime and it seems like this thread is dying. I'd like to
> contribute to this effort with a few patches. Doesn't the initial code need
> to be committed to the project for us to continue?
>
> 2010/4/25 van Hugten, Stephan <st...@atosorigin.com>
>
> Hello all,
>>
>> Some time has passed and I'm wondering if we're also going to set a target
>> date or dates for some milestones on this subprojects. I really want to
>> contribute to this, but I am a bit new to all of this and don't know where
>> to continue from here. If shown some direction I could focus my effort on
>> that and make something pretty.
>>
>> Regards,
>>
>> Stephan van Hugten
>>
>> -----Original Message-----
>> From: Andreas Veithen [mailto:andreas.veithen@gmail.com]
>> Sent: maandag 12 april 2010 12:48
>> To: java-dev@axis.apache.org
>> Subject: Re: [Axis2-Spring] Let's get started: servlet + axis2.xml +
>> JSR-181
>>
>> On Mon, Apr 12, 2010 at 07:41, Tharindu Mathew <th...@wso2.com> wrote:
>> > Hi Andreas,
>> > I've made some comments inline.
>> >
>> > On Sun, Apr 11, 2010 at 5:36 PM, Andreas Veithen
>> > <an...@gmail.com>
>> > wrote:
>> >>
>> >> After thinking about this a bit more, here is a design that should be
>> >> able to take into account the different concerns:
>> >>
>> >> 1. The ConfigurationContext is stored in the Spring application
>> >> context -> makes it easy to get hold of the ConfigurationContext in
>> >> the servlet, the standalone ListenerManager and/or clients.
>> >> 2. The ConfigurationContext is created by a FactoryBean that relies
>> >> on ConfigurationContextFactory with a custom AxisConfigurator ->
>> >> makes sure that things are set up in the order expected by the Axis2
>> >> runtime and that the Axis2 runtime has a chance to make the necessary
>> >> initializations.
>> >> 3. The custom AxisConfigurator is implemented as follows:
>> >> 3.a. It will first delegate to an existing one
>> >> (FileSystemConfigurator, URLBasedAxisConfigurator or
>> >> WarBasedAxisConfigurator, depending on the runtime environment) to
>> >> load axis2.xml. Once we have support for all-Spring configuration,
>> >> this would become an optional step.
>> >
>> > +1 for this approach. Going according to your notes, this point seems
>> > +to
>> > conform with making axis2 more Spring oriented. Until we can get the
>> > whole configuration into Spring, defaulting to an existing option
>> > seems to be the best option.
>> >
>> >>
>> >> 3.b. It will then scan the Spring application context for beans of
>> >> type AxisService and add those to the AxisConfiguration (at the right
>> >> moment expected by the Axis2 runtime).
>> >> 4. The Spring components that are used to deploy services
>> >> (services.xml like, JSR-181, etc.) are implemented as bean
>> >> definitions that contribute AxisService instances to the application
>> >> context (so that they are found in 3.b.). This still makes these
>> >> components self-contained, because the custom AxisConfigurator only
>> >> looks up AxisService instances from the application context, but
>> >> doesn't need to have any knowledge about how they are created.
>> >>
>> >> Notes:
>> >> - Point 1 does not imply that the Spring configuration will have an
>> >> element representing the ConfigurationContext bean. The necessary
>> >> bean definition could be added by a bean factory post processor.
>> >> Also, by giving a well defined name to the ConfigurationContext bean,
>> >> there is no need for explicit references to it in the configuration
>> >> file; they would be automatically added by the namespace support.
>> >> Thus the existence of the ConfigurationContext as a bean in the
>> >> application context would be transparent to the developer.
>> >> - Point 3.b. would later be generalized/extended to support modules,
>> >> as well as transport declarations and other things appearing in
>> >> axis2.xml.
>> >> - Stephan's code for automatic deployment of JSR-181 annotated beans
>> >> would become inconsistent with the strategy described in points 3.b.
>> >> and 4, because it takes already initialized JSR-181 annotated beans,
>> >> build AxisService descriptions and adds them to an already
>> >> initialized AxisConfiguration. Although this should still work, it is
>> >> probably better to make this consistent again by replacing the bean
>> >> postprocessor by a bean factory postprocessor that scans the bean
>> >> factory for bean definitions that produce JSR-181 annotated beans and
>> >> that adds the necessary bean definitions to contribute the
>> >> AxisService instances to the application context.
>> >
>> > I thought Stephen's idea was interesting. Any reason as to why you are
>> > going back on this idea? I'm still a bit unsure about what exactly the
>> > requirement is for this section to choose which approach is better.
>>
>> Stephan's idea is interesting and I want to have this feature. What I'm
>> saying is that we should make sure that explicit deployment (pojoService
>> element in the current code) and automatic deployment (as per Stephan's
>> suggestion) should work in the same way behind the scenes, so that we can
>> avoid subtle differences.
>>
>> >>
>> >> I will try to translate this design into code to check if it works in
>> >> practice.
>> >>
>> >> Andreas
>> >>
>> >> On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
>> >> <am...@gmail.com> wrote:
>> >> >
>> >> >
>> >> > On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen
>> >> > <an...@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>> >> >> <am...@gmail.com> wrote:
>> >> >> >
>> >> >> >
>> >> >> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>> >> >> > <an...@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.
>> >> >>
>> >> >> There are indeed three different approaches:
>> >> >>
>> >> >> * Manage both AxisConfiguration and ConfigurationContext outside
>> >> >> of Spring. This is what Axis2M and WSF/Spring do. This will
>> >> >> definitely cause the issues I described.
>> >> >> * Let Spring manage AxisConfiguration, but create the
>> >> >> ConfigurationContext outside of Spring (in the servlet and by the
>> >> >> component that creates the ListenerManager in the standalone
>> >> >> scenario).
>> >> >> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>> >> >> This is what I've chosen in my PoC.
>> >> >>
>> >> >> Since using the servlet and using ListenerManager are mutually
>> >> >> exclusive, you are right that as long as the ListenerManager is
>> >> >> the only component that requires a ConfigurationContext, the
>> >> >> second approach works well. Since the components that deploy
>> >> >> services only need access to the AxisConfiguration, but not the
>> >> >> ConfigurationContext, we indeed need to check what exactly is
>> >> >> required to create a client proxy.
>> >> >
>> >> > Any message sending requires a configuration context. But I think
>> >> > even for that case it is possible to register configuration context
>> >> > pragmatically after initialisation and use it at the message
>> >> > sending time.
>> >> >
>> >> > Axis2 specifies axis configuration details in axis2.xml and it
>> >> > creates the configuration context after creating the
>> >> > AxisConfiguration. When creating the configuration it initialise
>> >> > all the services and modules. There is no point in changing that if
>> >> > there are no problems could not solve in this method.
>> >> >
>> >> >>
>> >> >> > 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.
>> >> >>
>> >> >> Personally, I'm unsure about the right answer to this question. I
>> >> >> think someone argued that creating this as a separate project
>> >> >> would allow us to have more frequent releases. However, one can
>> >> >> also argue that instead of spending our energy in managing the
>> >> >> releases of different projects, we should spend that energy to do
>> >> >> more frequent releases of the Axis2 core project. Of course we
>> >> >> would have to overcome the problem of upstream releases (Axiom,
>> Woden, etc.)...
>> >> >
>> >> > I think you have missed what Saranga has pointed out. It is not
>> >> > only about having frequent releases.
>> >> > Axis2 spring will supposed to have a spring based axis2
>> >> > configuration and a service deployment. So it is worth to have it
>> >> > as a different project.
>> >> >
>> >> > thanks,
>> >> > Amila.
>> >> >
>> >> >>
>> >> >> > 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?
>> >> >>
>> >> >> There are several advantages of using namespace handlers even for
>> >> >> beans that are fairly simple:
>> >> >> * More flexibility to change the implementation, since backward
>> >> >> compatibility only needs to be handled at the namespace handler
>> level.
>> >> >> * Using an appropriate XML editor (e.g. the one in Eclipse), you
>> >> >> get autocompletion for free. Also, with the appropriate
>> >> >> xsd:annotation/xsd:documentation elements in the schema, the
>> >> >> Eclipse editor will show the documentation for each tag.
>> >> >>
>> >> >> > thanks,
>> >> >> > Amila.
>> >> >> >
>> >> >> >
>> >> >> > [1]
>> >> >> >
>> >> >> >
>> >> >> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/ja
>> >> >> > va/amila/axis2-spring
>> >> >> >>
>> >> >> >> Andreas
>> >> >> >>
>> >> >> >> [1]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> >> xis2/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/SpringAxi
>> >> >> >> s2Servlet.java
>> >> >> >> [4]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> >> xis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> >> >> >> [5]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> >> xis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> >> >> >> [6]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> >> xis2/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/
>> >> >> >
>> >> >>
>> >> >> ------------------------------------------------------------------
>> >> >> --- 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/
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Regards,
>> >
>> > Tharindu
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Regards,
>
> Tharindu
>



-- 
Regards,

Tharindu