ivom2gi
Jul 27th, 2005, 03:41 AM
I am developing a spring application for Weblogic Server 8.1SP4. Currently having the following problem:
Defining ContextLoaderListener in web.xml for reloading resources as following:
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/envreg-servlet.xml</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListe ner</listener-class>
</listener>
results in a classcast exception in development while weblogic automatically redeploys webapp an exploded webapp after recompilation.
Stacktrace follows:
java.lang.IllegalStateException: Root context attribute is not of type WebApplicationContext: org.springframework.web.context.support.XmlWebAppl icationContext: display name [Root WebApplicationContext]; startup date [Wed Jul 27 10:37:34 EEST 2005]; root of context hierarchy; config locations [/WEB-INF/bug-servlet.xml]
at org.springframework.web.context.support.WebApplica tionContextUtils.getWebApplicationContext(WebAppli cationContextUtils.java:64)
at org.springframework.web.servlet.FrameworkServlet.i nitWebApplicationContext(FrameworkServlet.java:249 )
at org.springframework.web.servlet.FrameworkServlet.i nitServletBean(FrameworkServlet.java:219)
at org.springframework.web.servlet.HttpServletBean.in it(HttpServletBean.java:111)
at javax.servlet.GenericServlet.init(GenericServlet.j ava:258)
at weblogic.servlet.internal.ServletStubImpl$ServletI nitAction.run(ServletStubImpl.java:1028)
at weblogic.security.acl.internal.AuthenticatedSubjec t.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(Se curityManager.java:121)
at weblogic.servlet.internal.ServletStubImpl.createSe rvlet(ServletStubImpl.java:904)
...
I have provided a minimal testcase for the issue which can be downloaded from http://ivo.webmedia.ee/bug.zip
Steps to reproduce:
1. Have a Weblogic Server 8.1SP4 running in development mode.
2. unzip bug.zip
3. deploy war folder (exploded .war file)
4. Open browser for URL http://localhost:7001/bug/. You should see a "Hello world" message.
5. Change ee.bug.HelloController.java file and recompile it to the WEB-INF/classes folder. ant compile target should do it.
6. Refresh the browser window. Stacktrace should be displayed to you.
Alternate scenarios:
- redeploy webapp from weblogic console before hitting the URL - everything works
- remove following from the web.xml. Now everything works even without redeployment from console.
<listener>
<listener-class>
org.springframework.web.context.ContextLoaderListe ner
</listener-class>
</listener>
- put to the server's classpath all the supporting libraries from WEB-INF/lib (common-log, spring, jstl) and remove those from WEB-INF/lib. Everything works now.
Business effect for the issue: notable development slowdown due to the need of manual redeployment after each change in class files.
I have previously opened a case in BEA support environment, but their claim was it to be a spring problem, most likely a classloader issue (inforrect static reference somewhere?)
Case can be reproduced with at least Spring versions 1.2.2 and 1.2.3
Defining ContextLoaderListener in web.xml for reloading resources as following:
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/envreg-servlet.xml</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListe ner</listener-class>
</listener>
results in a classcast exception in development while weblogic automatically redeploys webapp an exploded webapp after recompilation.
Stacktrace follows:
java.lang.IllegalStateException: Root context attribute is not of type WebApplicationContext: org.springframework.web.context.support.XmlWebAppl icationContext: display name [Root WebApplicationContext]; startup date [Wed Jul 27 10:37:34 EEST 2005]; root of context hierarchy; config locations [/WEB-INF/bug-servlet.xml]
at org.springframework.web.context.support.WebApplica tionContextUtils.getWebApplicationContext(WebAppli cationContextUtils.java:64)
at org.springframework.web.servlet.FrameworkServlet.i nitWebApplicationContext(FrameworkServlet.java:249 )
at org.springframework.web.servlet.FrameworkServlet.i nitServletBean(FrameworkServlet.java:219)
at org.springframework.web.servlet.HttpServletBean.in it(HttpServletBean.java:111)
at javax.servlet.GenericServlet.init(GenericServlet.j ava:258)
at weblogic.servlet.internal.ServletStubImpl$ServletI nitAction.run(ServletStubImpl.java:1028)
at weblogic.security.acl.internal.AuthenticatedSubjec t.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(Se curityManager.java:121)
at weblogic.servlet.internal.ServletStubImpl.createSe rvlet(ServletStubImpl.java:904)
...
I have provided a minimal testcase for the issue which can be downloaded from http://ivo.webmedia.ee/bug.zip
Steps to reproduce:
1. Have a Weblogic Server 8.1SP4 running in development mode.
2. unzip bug.zip
3. deploy war folder (exploded .war file)
4. Open browser for URL http://localhost:7001/bug/. You should see a "Hello world" message.
5. Change ee.bug.HelloController.java file and recompile it to the WEB-INF/classes folder. ant compile target should do it.
6. Refresh the browser window. Stacktrace should be displayed to you.
Alternate scenarios:
- redeploy webapp from weblogic console before hitting the URL - everything works
- remove following from the web.xml. Now everything works even without redeployment from console.
<listener>
<listener-class>
org.springframework.web.context.ContextLoaderListe ner
</listener-class>
</listener>
- put to the server's classpath all the supporting libraries from WEB-INF/lib (common-log, spring, jstl) and remove those from WEB-INF/lib. Everything works now.
Business effect for the issue: notable development slowdown due to the need of manual redeployment after each change in class files.
I have previously opened a case in BEA support environment, but their claim was it to be a spring problem, most likely a classloader issue (inforrect static reference somewhere?)
Case can be reproduced with at least Spring versions 1.2.2 and 1.2.3