Problems deploying app on WebLogic 8.1 SP4

[hyness]

I have been developing a springapp on JBoss 4 which works great, but now the app needs to be deployed on WebLogic 8.1 SP 4, and I'm having some problems which I couldn't find any answers for with search.

I have the ContextLoaderListener to read in the config, but it doesn't seem to work as I get the following error...

####<Jul 18, 2005 4&#58;48&#58;59 PM PDT> <Warning> <HTTP> <vongodev.contentproject.com> <vongodev-srv> <ExecuteThread&#58; '1' for queue&#58; 'weblogic.kernel.System'> <<WLS Kernel>> <> <BEA-101162> <User defined listener org.springframework.web.context.ContextLoaderListener failed&#58; java.lang.NoSuchMethodError&#58; <init>.>

I should be able to use this Listener according to the docs...

Servlet 2.3 containers known to work with bootstrap listeners are:

* Apache Tomcat 4.x
* Jetty 4.x
* Resin 2.1.8+
* Orion 2.0.2+
* BEA WebLogic 8.1 SP3

When I take that out and use the ContextLoaderServlet, the webapp will deploy, but I can't use the DispatcherServlet...

Error 500--Internal Server Error

javax.servlet.ServletException: Servlet class: 'org.springframework.web.servlet.DispatcherServlet' doesn't have a default constructor
	at weblogic.servlet.internal.ServletStubImpl$ServletInitAction.run()Ljava.lang.Object;(ServletStubImpl.java:1032)
	at weblogic.security.acl.internal.AuthenticatedSubject.doAs(Lweblogic.security.subject.AbstractSubject;Ljava.security.PrivilegedAction;)Ljava.lang.Object;(AuthenticatedSubject.java:321)
	at weblogic.security.service.SecurityManager.runAs(Lweblogic.security.acl.internal.AuthenticatedSubject;Lweblogic.security.acl.internal.AuthenticatedSubject;Ljava.security.PrivilegedAction;)Ljava.lang.Object;(SecurityManager.java:121)
	at weblogic.servlet.internal.ServletStubImpl.createServlet()Ljavax.servlet.Servlet;(ServletStubImpl.java:904)
	at weblogic.servlet.internal.ServletStubImpl.createInstances()V(ServletStubImpl.java:883)
	at weblogic.servlet.internal.ServletStubImpl.prepareServlet(Lweblogic.servlet.internal.RequestCallback;)V(ServletStubImpl.java:822)
	at weblogic.servlet.internal.ServletStubImpl.getServlet(Lweblogic.servlet.internal.RequestCallback;)Ljavax.servlet.Servlet;(ServletStubImpl.java:535)
	at weblogic.servlet.internal.ServletStubImpl.invokeServlet(Ljavax.servlet.ServletRequest;Ljavax.servlet.ServletResponse;Lweblogic.servlet.internal.FilterChainImpl;)V(ServletStubImpl.java:373)
	at weblogic.servlet.internal.ServletStubImpl.invokeServlet(Ljavax.servlet.ServletRequest;Ljavax.servlet.ServletResponse;)V(ServletStubImpl.java:315)
	at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run()Ljava.lang.Object;(WebAppServletContext.java:6718)
	at weblogic.security.acl.internal.AuthenticatedSubject.doAs(Lweblogic.security.subject.AbstractSubject;Ljava.security.PrivilegedAction;)Ljava.lang.Object;(AuthenticatedSubject.java:321)
	at weblogic.security.service.SecurityManager.runAs(Lweblogic.security.acl.internal.AuthenticatedSubject;Lweblogic.security.acl.internal.AuthenticatedSubject;Ljava.security.PrivilegedAction;)Ljava.lang.Object;(SecurityManager.java:121)
	at weblogic.servlet.internal.WebAppServletContext.invokeServlet(Lweblogic.servlet.internal.ServletRequestImpl;Lweblogic.servlet.internal.ServletResponseImpl;)V(WebAppServletContext.java:3764)
	at weblogic.servlet.internal.ServletRequestImpl.execute(Lweblogic.kernel.ExecuteThread;)V(ServletRequestImpl.java:2644)
	at weblogic.kernel.ExecuteThread.execute(Lweblogic.kernel.ExecuteRequest;)V(ExecuteThread.java:219)
	at weblogic.kernel.ExecuteThread.run()V(ExecuteThread.java:178)
	at java.lang.Thread.startThreadFromVM(Ljava.lang.Thread;)V(Unknown Source)

According to the javadocs there IS a default constructor, but I couldn't find it in the source code. I'm really frustrated, especially since this all works fine in Tomcat and JBoss, but I'm constrained by the client's choice of app server, no mater how misguided it may be.

Any help would be appreciated

[Rod Johnson]

There are no issues I'm aware of on WLS 8.1, although I'm not sure if we're tried SP4. I'll ask someone to take a look.

Spring works well on WebLogic--in fact Interface21 and BEA announced at JavaOne a partnership to deliver support for Spring on WebLogic.

So rest assured, the problem will be solved :-)

[Juergen Hoeller]

The behavior you're experiencing is very odd. It seems that you either get a failure in the static initializer of the ContextLoaderListener class, or a "no default constructor found" for the DispatcherServlet class. Of course, both ContextLoaderListener and DispatcherServlet are perfectly valid classes, so I do not understand at all where that failure comes from.

I regularly test against exactly that version - WebLogic 8.1 SP4 - on Windows, in particular before every Spring release. I've just re-verified that, for example, our JPetStore as shipped in Spring 1.2.2 works nicely on WebLogic 8.1 SP4 on Windows XP, out-of-the-box without any changes. This is running JRockit 8.1 SP4 as JVM.

Could you please check whether Spring 1.2.2's JPetStore works on your WebLogic installation? Simply call "warfile" in the "samples/jpetstore" directory of the Spring distribution, then take the generated "jpetstore.war" from the "samples/jpetstore/dist" directory and drop it into WebLogic's "applications" directory (within your WebLogic domain).

This should run without any issues, making JPetStore available at "http://localhost:7001/jpetstore" (or whatever your server port is). If that works, please verify what Spring build you're using in your application. Try using the exact spring.jar from the 1.2.2 distribution in your application, reproducing JPetStore's environment as far as possible.

Juergen

[robh]

Also check that you haven't deployed servlet-api.jar with your app and that you don't have more than one spring.jar on the classpath for your application.

Rob

[hyness]

I was just hoping for help from the Spring community, I never in my wildest dreams thought Rod, Juergen and Rob would help me with my silly problem. You guys have become heroes of mine ever since I learned about Spring. You've opened my eyes to a completely new paradigm, and made my life as a developer much simpler, thank you. I don't know if you tire of hearing that, but since I unexpectedly had your attention I just had to say it.

Ok, I have tracked down the problem to XFire, which I am using to expose some Spring beans as Web Services (as enumerated in the remoting section of the spring reference manual). I started with a completely empty WAR and started adding jars and this where the problem occured. I removed the jars and all references to XFire in the web.xml and included everything else, and the app deploys and runs fine.

Do you think any of the following jars would cause this problem?
stax-1.1.1-dev.jar
stax-api-1.0.jar

Once I include the xfire configuration it blows up with the same exception as above. If i remove the xfire stuff from web.xml, the app deploys and runs fine, even with all of the xfire jars included. Any thoughts or known issues with XFire? Or am I stuck trying to get the XFire guys help on this (AFAIK its only one developer who's swamped with his own problems)?

Thanks for the help

[robh]

That sounds like a really strange problem. What classes are you including to support XFire. It doesn't include its own Spring classes does it? Or perhaps it includes its own servlet classes?

Rob

[hyness]

XFire, AFAIK, doesn't override any Spring classes and nothing in the jars is in an org.springframework package. It does have a list of beans to include, which is where I've narrowed the problem down to. I removed the servlet definitions that XFire requires to expose a webservice, but I kept that list of beans that is loaded by the ContextLoaderListener and the dependent jars that Xfire requires. The bean definitions are what is causing the error. The really strange thing is this application works great on all the other app server/servlet containers I've tried (Tomcat and JBoss).

Here is the minimal list of jars I've included to get rid of any ClassNotFound warnings but still produces the error...

xfire-aegis-1.0-SNAPSHOT.jar
xfire-annotations-1.0-SNAPSHOT.jar
xfire-core-1.0-SNAPSHOT.jar
xfire-spring-1.0-SNAPSHOT.jar
stax-api-1.0.jar

Here are the beans that are causing the problem...

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http&#58;//www.springframework.org/dtd/spring-beans.dtd">

<beans>

    <bean id="xfire.serviceRegistry"
        class="org.codehaus.xfire.service.DefaultServiceRegistry"
        singleton="true"/>

    <bean id="xfire.transportManager"
        class="org.codehaus.xfire.transport.DefaultTransportManager"
        singleton="true">
        <constructor-arg index="0">
            <ref bean="xfire.serviceRegistry"/>
        </constructor-arg>
    </bean>

    <bean id="xfire"
        class="org.codehaus.xfire.DefaultXFire"
        singleton="true">
        <constructor-arg index="0">
            <ref bean="xfire.serviceRegistry"/>
        </constructor-arg>
        <constructor-arg index="1">
            <ref bean="xfire.transportManager"/>
        </constructor-arg>
    </bean>

    <bean id="xfire.typeMappingRegistry"
        class="org.codehaus.xfire.aegis.type.DefaultTypeMappingRegistry"
        init-method="createDefaultMappings"
        singleton="true">
    </bean>

    <bean id="xfire.aegisBindingProvider"
        class="org.codehaus.xfire.aegis.AegisBindingProvider"
        singleton="true">
        <constructor-arg index="0">
          <ref bean="xfire.typeMappingRegistry"/>
        </constructor-arg>
    </bean>

    <bean id="xfire.serviceFactory"
        class="org.codehaus.xfire.service.binding.ObjectServiceFactory"
        singleton="true">
        <constructor-arg index="0">
            <ref bean="xfire.transportManager"/>
        </constructor-arg>
        <constructor-arg index="1">
            <ref bean="xfire.aegisBindingProvider"/>
        </constructor-arg>
    </bean>

</beans>

I doubt WebLogic uses any of these libraries. I guess I'm on my own on this one.

Thanks again for taking the time to help

[hyness]

One other thing I noticed is one of the dependent jars is stax-1.1.1.jar and inside is a com.bea.xml.stream package...could this have anything to do with this particular error? I guess something inside xfire has dependency on a com.bea package. I'm pinging the xfire devs too, but none are around.

Thanks again

[hyness]

Problem solved. Turns out WebLogic 8.1 uses an older version of javax/xml/namespace/QName.class than XFire requires. The fix was to include the new version of QName.class in a jar by itself and then prepend that to the WebLogic's classpath. A really ugly fix, but it works.

It was just really weird how that error manifested itself into a seemingly Spring related problem. I should have known better. Thanks for all the help, and hopefully anyone who has this problem will be able to find this thread with search. The XFire guys are updating their docs too.

[sotretus]

Putting your jar in the classpath will affect every application on that server. I would recommend creating a WEB-INF\weblogic.xml file inside your application with the following:

<weblogic-web-app>
<container-descriptor>
<prefer-web-inf-classes>true</prefer-web-inf-classes>
</container-descriptor>
</weblogic-web-app>

See also:
http://e-docs.bea.com/wls/docs81/pro...ssloading.html