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 say: 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 cannot. 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. Thoughts? Robert On 7/8/07, Davanum Srinivas <[EMAIL PROTECTED]> 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] http://www.nabble.com/Re%3A-Axis2-vs-CXF-p11481341.html [2] http://www.nabble.com/Axis2-vs-CXF-tf4030139.html -- Davanum Srinivas :: http://davanum.wordpress.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]