Problems running airline web application in Sun Application Server 8.2

[pfeng]

I recently published my airline.war web application and verified that the wsdl and schema were published in a separate web application. However, when it came time to run the Airline servlet which would report the wsdl and schema metdata, I ran into the following problem. I had no issues with running the ant buildscript. I noticed that the saaj.jar file contained a two argument

org.springframework.beans.factory.BeanCreationExce ption: Error creating bean with name 'messageHandlerAdapter' defined in ServletContext resource [/WEB-INF/airline-servlet.xml]: Cannot create inner bean 'org.springframework.ws.soap.saaj.SaajSoapMessageC ontextFactory#11f05a1' while setting bean property 'messageContextFactory'; nested exception is org.springframework.beans.factory.BeanCreationExce ption: Error creating bean with name 'org.springframework.ws.soap.saaj.SaajSoapMessageC ontextFactory#11f05a1' defined in ServletContext resource [/WEB-INF/airline-servlet.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.FatalBeanException: Could not instantiate class [org.springframework.ws.soap.saaj.SaajSoapMessageCo ntextFactory]; constructor threw exception; nested exception is java.lang.NoSuchMethodError: javax.xml.soap.FactoryFinder.find(Ljava/lang/StringLjava/lang/Object;

The saaj.jar packaged with the sample project contains an implementation of this javax.xml.soap.FactoryFinder.find(x,x) with two arguments INSTEAD of ONE as the error message. I plugged into web-inf/classes the FactoryFinder from saajapi.jar from the jwsdp2.0 and it did not load this(after removing the class from saaj.jar). Substituting classes is probably not the right approach, perhaps there is an additional step or configuration that I might have missed somewhere.

[Arjen Poutsma]

I'm having a hard time reproducing this. I am using the SUN Application Server 8.2 that is distributed with Netbeans 5.0 (since there is no separate download for the appserver for OS X).

Note that the dependencies of the airline sample presuppose a plain web container such as Tomcat. If you're deploying on a J2EE appserver, such as the SUN appserver, you can remove some of the depencies listed in ivy.xml. Most importantly, you can remove the SAAJ reference, since it is part of the J2EE 1.4 spec. If I remove this dependency, the airline app deploys fine on my box.

But you seem to use the Java Web Service Development pack 2.0 as well? Can you offer some more info about this?

Cheers,

[pfeng]

My Sun Appserver has jwsdp2.0 libraries pre-installed in C:\sun\appserver\lib.
Here is my situation jwsdp2.0 saaj-api.jar
spring-ws: saaj.jar

The abstract class javax.xml.soap.MessageFactory being loaded by org.springframework.ws.soap.saaj.SaajSoapMessageCo ntextFactory is one in the app server lib instead of the WEB-INF\lib\saaj.jar....

This is probably an appserver class loading switch somewhere perhaps in the server.policy

[pfeng]

airline-servlet.xml snippet.
<bean id="messageHandlerAdapter" class="org.springframework.ws.transport.http.Messa geHandlerAdapter">
<property name="messageContextFactory">
<bean class="org.springframework.ws.soap.saaj.SaajSoapMe ssageContextFactory"/>
</property>
</bean>

"WEB-INF/lib" refers to the spring airline web-application class context.
"appserver/lib" refers to the sun appserver8.2 class context.

This is a classloading VM Spring issue:
SaajSoapMessageContextFactory(WEB-INF/lib)->MessageFactory(appserver/lib)-> FactoryFinder(WEB-INF/lib)
What is going on here is that Spring reflection loads MessageFactory from appserver/lib/javaee.jar(looking for single argument in the Spring web application context)
Then it tries to find FactoryFinder in the WEB-INF/lib/saaj.jar where only the two argument findFactory exists.

I tried to remove the jwsdp2.0 dependencies in my sunapp server, but either way, the conceptual issue at hand is Spring loading classes from the wrong class context and how to adjust it since WEB-INF/lib has a javax.xml.soap.MessageFactory which should be loaded instead of the appserver class context.

[Arjen Poutsma]

My Sun Appserver has jwsdp2.0 libraries pre-installed in C:\sun\appserver\lib.
Here is my situation jwsdp2.0 saaj-api.jar
spring-ws: saaj.jar

The abstract class javax.xml.soap.MessageFactory being loaded by org.springframework.ws.soap.saaj.SaajSoapMessageCo ntextFactory is one in the app server lib instead of the WEB-INF\lib\saaj.jar....

This is probably an appserver class loading switch somewhere perhaps in the server.policy

Yes, that is what I suspected. Could you try and remove the saaj.jar from WEB-INF/lib? Since you're running on a full-fledged J2EE application server, you don't need it.

I will try and reproduce this now, with the new information you provided.

[pfeng]

If we could control the spring classloader context this could resolve the problem sooner. Meaning when bean factories load classes they create their own classloader and don't delegate to the parent classloader.

The sun App server actually has two other jar(j2ee.jar and javaee.jar) files other than the saaj-api.jar from jwsdp2.0 which contain different javax.xml.soap.MessageFactory and FactoryFinder classes. Apparently the Spring BeanFactory loads the MessageFactory from appserver/lib/javaee.jar before the appserver/lib/j2ee.jar(it also exists there has single argument FactoryFinder.find). Then loads j2ee.jar FactoryFinder version instead of the javaee.jar

I managed to copy the saaj.jar from WEB-INF into the Sun App Server java VM jre/ext/lib which is the bootstrap classloader which is checked first for the javax.xml.soap.MessageFactory and FactoryFinder. This makes the error go away.

[Arjen Poutsma]

If we could control the spring classloader context this could resolve the problem sooner. Meaning when bean factories load classes they create their own classloader and don't delegate to the parent classloader.

Spring doesn't have or create its own classloader, because that would result in a whole lot of issues within an enterprise environment. Instead, it just uses the one supplied by the environment (the application server in this case).

However, most application servers allow do you to specify which classes to load first: the ones you provided (in WEB-INF/lib, for instance), or the ones in the server application lib directory.

I installed JWSDP 2.0 on the SUN appserver, and I still can't reproduce the issue you found, but I think you found the solution yourself.

Thanks,