Hi Robert,
thanks for following up and your feedback. I added some comments below.
Quoting robert lazarski <[EMAIL PROTECTED]>:
Christian, great to know we have members of the Spring participating on the
list! Lets see how we can improve what we've got. See my comments inline:
On 5/17/06, Christian Dupuis <[EMAIL PROTECTED]> wrote:
Hi all,
nice to see that the Spring integration topic has been kicked up
by the Axis team. I have a couple of comments regarding the code
that has been commited:
- I don't see why you introduced the ApplicationContextHolder with a
static reference to the Spring ApplicationContext. There is another
way to get the ApplicationContext that you should consider, because
with that non invasive approach there is no need to configure a
proprietary Axis2 ApplicationContextHolder in the Spring config.
When using Spring's ContextLoader(Servlet|Listener) the
ApplicationContext
is exposed in the ServletContext. And the ServletContext itself is
exposed in Axis2's MessageContext properties. Using that approach the
SpringAbstractMessageReceiver's makeNewServiceObject can be changed to
ServletContext oServletContext = (ServletContext)
msgContext.getOptions().
getProperty(Constants.SERVLET_CONTEXT);
ApplicationContext aCtx =
WebApplicationContextUtils.getWebApplicationContext(oServletContext);
and the ApplicationContextHolder class can be removed.
I was aware of the ServletContext approach but chose not to use it for one
simple reason: Axis2 supports other transports such as SMTP and TCP, and
therefore, does not always run in a servlet container. So I didn't want to
make a rule that I must always be able to get a servlet context. Perhaps
others can comment here, but that was the choice I made. It just so happens,
Christian, that you're the right person to ask about this:
Suppose someone wants to use Axis2 in Spring IDE. In some cases they want to
be a client to an axis2 service and in other cases they are the actual
service. They've choosen TCP as the transport for synchronous services and
SMTP for asynchonous services. In that scenario, from a Spring IDE
perspective, how might makeNewServiceObject() get a reference to
ApplicationContext?
While the ApplicationContextHolder class is simple, if possible I'm all for
removing it.
IMHO static references in Axis2's Classloading setup will cause problems.
The problem with the different transports and how to get access to the
Spring ApplicationContext is why I suggest to implement a support superclass
(using parameter with name ServiceClass) which hooks into Axis2
lifecycle using
init/destroy/configure Methods via DependencyManager.
Speaking about different transports another problem comes up: How should the
Spring ApplicationContext be loaded in a JMS or Mail transport environment?
That superclass can leverage a pluggable strategy which is responsible for
locating or loading a Spring Application Context. The ApplicationContext can
then be exposed using one of the Axis2 Context implementations as a property.
That is very much inline with the ServletEndpointSupport for Spring's Axis 1.x
integration and enables you guys to streamline your receiver
implementations and
add different data bindings without the need to bother with the Spring
integration.
If I were you (or a member of the Axis2 team) I would actually delegate the
concern of loading/maintaining/locating a Spring context to the Spring team.
- I'm not quite sure if the choosen approach to integrate Spring with
Axis2 on the server-side is the best. Basically that is because invoking
Spring beans as a pojo service implementations now becomes a concern for
the
Receiver implementation. With the current Receiver architecture (which
needs
refactoring btw.) you end up implementing different message receivers
for
"plain" Axis2 and for the integration with Spring (as you did with
RawXML
and RPC) which are bascially copies of each other in order to integrate
different data binding frameworks.
IMHO there are two possible solutions for that: You can refactor the
receiver stuff incl. Axis2's core receivers to provide better extension
points (template methods to invoke business logic). Or you can choose a
different approach to integrate Spring which is not aware of actual
message
receiving.
The last approach can be implemented by providing a superclass for Axis2
pojo based service objects. That superclass can access the Spring
ApplicationContext and provide the required business logic Spring bean
to
invoke. That is quite similiar to Spring's JAX-RPC (based on Axis 1.x)
integration; look into ServletEndpointSupport.
calling business logic)
There at least needs to be refactoring on the implementation of the
Spring*Receivers. The other points I'll try to bring up in our scheduled IRC
chat later today.
If there is anything I can do further clarify the above, please let me know.
Cheers
Christian
-
Spring IDE
http://springide.org
Thanks Christian for the constructive feedback. I'll post messages to the
dev list when we get some progess here.
Robert
http://www.braziloutsource.com/
Cheers
Christian
-
Spring IDE
http://springide.org
