ws-savan-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <andreas.veit...@gmail.com>
Subject Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Date Tue, 20 Apr 2010 11:43:07 GMT
It is still at the same place:

https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/spring/

Andreas

On Tue, Apr 20, 2010 at 12:45, Tharindu Mathew <tharindu@wso2.com> wrote:
> Hi Andreas,
>
> Is your code committed to a new project/sub-project?
>
> On Thu, Apr 15, 2010 at 6:07 PM, Amila Suriarachchi
> <amilasuriarachchi@gmail.com> wrote:
>>
>>
>> On Sun, Apr 11, 2010 at 7:42 PM, Andreas Veithen
>> <andreas.veithen@gmail.com> wrote:
>>>
>>> All,
>>>
>>> I've committed the code that implements the proposed design to [1]. I
>>> had to do a slight change to points 3.b. and 4, because construction
>>> of an AxisService in general requires an existing AxisConfiguration.
>>> To get around this problem, I've introduced a factory interface
>>> (AxisServiceFactory) and these points now become:
>>>
>>> 3.b. It will then scan the Spring application context for beans of
>>> type AxisServiceFactory, invoke these factories to create AxisService
>>> instances 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 AxisServiceFactory implementations 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 AxisServiceFactory instances from the application context,
>>> but doesn't need to have any knowledge about how they are created.
>>>
>>> You can use WeatherServiceServletRunner to run a sample context in an
>>> embedded Jetty instance.
>>>
>>> Please review and let me know if you think that the code is suitable
>>> as a baseline for further development. In particular I would like
>>> Sagara as well as the people who worked on WSF/Spring to check if the
>>> code is OK as a foundation to build the features that these two
>>> frameworks provide.
>>
>> +1. this looks good.
>>
>> Does spring runtime guarantees that all the namespace handlers get invoked
>> before the FactoryBean afterPropertiesSet() methods get invoked?
>>
>> I think this design assumes that all the AxisServiceFactory (and other
>> possbile future factories) has properly registerd when
>> springAxisConfigurator get invoked.
>>
>> thanks,
>> Amila.
>>
>>
>>
>>>
>>> Andreas
>>>
>>> [1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/spring/
>>>
>>> On Sun, Apr 11, 2010 at 14:06, Andreas Veithen
>>> <andreas.veithen@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.
>>> > 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 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
>>> > <amilasuriarachchi@gmail.com> wrote:
>>> >>
>>> >>
>>> >> On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen
>>> >> <andreas.veithen@gmail.com>
>>> >> wrote:
>>> >>>
>>> >>> On Tue, Apr 6, 2010 at 18:56, 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.
>>> >>>
>>> >>> 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/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/
>>> >>> >
>>> >>>
>>> >>> ---------------------------------------------------------------------
>>> >>> 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/
>
>
>
> --
> Regards,
>
> Tharindu
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org


Mime
View raw message