Mailing-List: contact java-dev-help@axis.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@axis.apache.org
Received-SPF: pass (athena.apache.org: domain of andreas.veithen@gmail.com
 designates 209.85.220.209 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type:content-transfer-encoding;
        b=dCCrJmM4QSZn104qM2o8Y/9bqafrHC3kZEDM+T+yNZvk4IDEvskxFP5yY79NkhMEDD
         Tw7q9RsMl5wHlQNKpZ58Ps3iPhdDXLVDoMNQGv8kTGXmfWxLSiTqLLUjEft3ti4hZw2+
         qJSaybY/XX+VcrDYo7jcSw8jfs+iTDqW76+NU=
MIME-Version: 1.0
In-Reply-To: 
 <A863A914122E6E48A62C3E359AC861F64CB018@aownlex012.europe.nl.intra>
References: <p2yb67458761004011416rc548155fi481575f19fcc82c4@mail.gmail.com>
	<A863A914122E6E48A62C3E359AC861F64CB018@aownlex012.europe.nl.intra>
From: Andreas Veithen <andreas.veithen@gmail.com>
Date: Fri, 2 Apr 2010 13:25:50 +0200
Message-ID: <l2tb67458761004020425x39805b3cx26838c68297b0dc@mail.gmail.com>
Subject: Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
To: java-dev@axis.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 2, 2010 at 09:40, van Hugten, Stephan
<stephan.vanhugten@atosorigin.com> wrote:
> I agree with this approach, but want to add that I already added some cod=
e for component-scanning to [1] so it's doesn't hurt to add it to the start=
.

That is a very valuable contribution, but let's first start with the
most basic stuff.

> If I understand your last point correctly, I don't think this is much of =
an implication. In my vision we should make convention leading anyway and i=
n a Spring-managed environment it shouldn't matter in which order things ar=
e configured. Order configuration should be part of an element as attribute=
 for instance like servlet filters.

With the traditional Axis2 configuration mechanisms, the order in
which things are set up is as follows: items from axis2.xml
(transports, message receivers, etc.), modules, services and finally
the ListenerManager. I don't think that the Axis2 runtime would
appreciate if that order is reversed... So order is important, but the
developer should not have to care about it.

> One questions remains for me; how are non-committers able to contribute? =
Can we send sample code somewhere?

I think we should soon put together some initial code. We can then
start to work with patches.

> Stephan van Hugten
>
> [1] https://issues.apache.org/jira/browse/AXIS2-4662
>
> -----Oorspronkelijk bericht-----
> Van: Andreas Veithen [mailto:andreas.veithen@gmail.com]
> Verzonden: do 1-4-2010 23:16
> Aan: java-dev@axis.apache.org
> Onderwerp: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-18=
1
>
> 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.
>
> There are several advantages I see in this second approach:
>
> * It is more in line with the general paradigms used in Spring.
> * 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].
> * 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.
> * It would make the implementation of the servlet very easy: just
> extend AxisServlet and look up the ConfigurationContext from the
> Spring application context.
> * 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.
>
> 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.
>
> Andreas
>
> [1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/ve=
ithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/servic=
e/PojoServiceUtil.java
> [2] https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/w=
so2/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/ve=
ithen/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/ve=
ithen/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/ve=
ithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/servic=
e/PojoServiceFactoryBean.java
>
> ---------------------------------------------------------------------
> 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
>

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