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 Thu, 15 Apr 2010 12:37:13 GMT
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/

Mime
View raw message