axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "robert lazarski" <>
Subject Re: [Axis2] Feedback / action item on Axis2's spring support
Date Mon, 09 Jul 2007 14:39:05 GMT
Long email alert! .

I think the spring stuff could be easier for sure. To be accurate
though, you only need a bean descripter in the 'inside the aar case' .
That's not the case by using a ContextListener via the servet
container to setup spring. Note that the latter case is what xfire
does, since they don't have an aar and such.

As I think everyone knows, Spring is configured in the
AbstractMessageReceiver which was an afterthought. There were some
tricky classloader issues that came up when trying to get the 'inside
the AAR' case up. So really there's currently three part's of the
spring / axis2 integration:

1) jaxws . I think there is / was a jira on this for spring. To be
honest, I've yet to get involved in jaxws besides reading the list. In
any case my understanding is it still would involve
AbstractMessageReceiver. The threads from the links focused on the
jaxws part.

2) Spring jars Inside the AAR. This is the tricky part, and I consider
is an advanced case. It gets even trickier when using Spring to
configure Hibernate, which appears on the list every few weeks. It is
possible of course, but tricky the first time.

3) Spring jars in WEB-INF/lib . This is by far the easiest case. There
is no separate spring bean needed. As noted, this is how xfire et all
makes things simple.

So the way 2 and 3 works currently is by Spring pre-loaded object
that's already inside the classloader. There needs to be someway to

a) Hey axis2, spring is in the app and giving you the Service, so
don't instantiate one! Its this object here, you see.

b) Hey axis2, there are different places where this object may be
coming from. Get it from here! What 'Here' is, is not important at the
AbstractMessageReceiver level. Really it may be from the servlet
container, or in the 'inside the aar' case from a Spring trick that
allows you to get a bean anywhere, anytime.

So what I suggest is this:

1) Can we do spring / axis2 integration outside of services.xml ? How
else could we let AbstractMessageReceiver know that it needs to get a
pre-loaded object ? AbstractMessageReceiver defines the service class,
so unless things change it has to happen there, right ?

2) For the complex 'inside the aar' case - Is there a way for an AAR
to get things loaded from the TCCL of the Servlet container? This was
discussed a lot pre 1.0 days. I'm inclined to believe that no, it

3) Perhaps move the advanced spring stuff into another doc. The idea
being so this case doesn't distract the simple usage of spring /
axis2. The 'inside the aar' case is really particular to axis2, and
does need another bean. What this other bean does is that it
implements the Spring interface ApplicationContextAware. That allows
you to get any spring bean, anytime, anywhere. Note this other bean
the defines the Spring interface is what is suggested on the spring
list all the time for getting spring to work in a Handler and other
things that are not spring aware. It was what I used before axis2 had
spring. Its in axis2 because its an advanced spring case.


On 7/8/07, Davanum Srinivas <> wrote:
> Hi Team,
> Looks like we are missing a easy-to-use spring deployer [1] Please
> read the whole thread and let's try to incorporate any feedback
> possible into 1.3.
> thanks,
> dims
> [1]
> [2]
> --
> Davanum Srinivas ::
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message