axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert lazarski <robertlazar...@gmail.com>
Subject Re: Axis2-Spring integration
Date Wed, 31 Mar 2010 20:12:05 GMT
On Wed, Mar 31, 2010 at 4:01 PM, Andreas Veithen
<andreas.veithen@gmail.com> wrote:
>
> If everybody proposes his own code as a starting point, we will get
> nowhere. I think we should start from scratch, and then as we progress
> through the different areas we want to cover, take over those
> components from the three codebases that fit well into the
> architecture, discarding those that need to be redesigned. Anyway I
> think that both WSF/Spring and Axis2M share an architectural flaw that
> will make it difficult to support the standalone (non servlet) case
> and Spring at the client side. I will provide an analysis of this
> issue later.
>

I've been following this discussion, and imho starting from scratch
makes the most sense to me. I'd personally really like to see anything
for spring that gets developed be a part of the standard axis2 distro,
as I don't see it being used much if not. Therefore a module would be
great, no new incubator project or anything like that needed. All I
really have to add in technical terms is to maintain the current
simplicity, ie as simple as possible but no simpler, as until now I
don't see a need for anything else.

If you look at the current spring implementation, its about 50 lines
of total code. The main parts are the classloader parts and spring's
native ApplicationContextHolder. The fact that axis2 supplies its own
ApplicationContextHolder implementation should not obscure the fact
that its model is a very common way outside of axis2 - ie in the
general spring world - of getting spring beans in non-spring
controlled places like jsp's, jaxws, unit tests etc.

Over the years, the current approach has indeed had the flaw of
depending on an aar. While its not that common to see jaxws questions
on these lists, it should be supported. I personally don't even put
the service classes in the aar for the projects I work on - just a
services.xml . I just think the aar approach in general is overkill,
and its intended uses, while they exist, is the exception and not the
rule. Most problems with understanding how spring works in axis2 is
imho because of the aar model.  That being said, I think its arguable
that the "spring inside the aar" - ie one completely isolated spring
instance per aar - needs to continue be supported.

In short, I'd be curious to see if the current
ApplicationContextHolder based idea could exist in both jaxws and aar
based services, and whatever else is being discussed. The fact its
really a spring class designed for non-spring use makes me think it
can. It also has the advantage of being easily supported in
ServiceLifeCycle, ie non-servlet, applications. All the current code
getting tossed would be fine by me.

That all being said, this discussion comes as I'm soon leaving for
vacation for one month. All I can therefore add until then is that I'm
skeptical that anything big or outside of the axis2 project is needed.
I'd also like to remind people that what we have now works for most
people in most cases - servlet, non-servlet, one spring instance for
all aars and one spring per aar, ie about 99% of the spring questions
on the list. The area that could be improved imho is removing the aar
and services.xml dependency for spring in axis2. While the 50 lines or
so of current code is easy to understand, the current docs show more
complexity than might be needed.

- R

---------------------------------------------------------------------
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