axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Dupuis <christ...@springide.org>
Subject Re: Spring Support commited
Date Wed, 17 May 2006 13:29:16 GMT
Hi Robert,

thanks for following up and your feedback. I added some comments below.

Quoting robert lazarski <robertlazarski@gmail.com>:

> 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 <christian@springide.org> 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

Mime
View raw message