1 Reply Latest reply on Sep 22, 2011 3:41 AM by jbossuser71

war-deployment fails on JBoss 6.1 when the "ear" file is in collapsed/archived format

jbossuser71 Sep 22, 2011 2:12 AM

Hello All,

I have a J2EE based web application which perfectly gets deployed on JBoss 6.0 app server.
I am using JBoss's "default" server configuration.
I have an ".ear" file which contains EJBs and a ".war" file.
I am using Spring Security for user authentication and authorization

When I deploy the same ear file on JBoss 6.1, I find my WAR deployment fails with following errors.

But surprising thing is if I deploy the same ".ear" file in exploded format (i.e. un-jar or unzip the ear file content in a folder), then the deployment is successful !

22:31:14,827 INFO [StdSchedulerFactory] Quartz scheduler version: 1.8.3 22:31:14,828 INFO [QuartzScheduler] Scheduler EdmQuartzScheduler_$_NON_CLUSTERED started. 22:31:14,828 INFO [QuartzService] QuartzService(EdmQuartzMBean) started. 22:31:14,837 INFO [TomcatDeployment] deploy, ctxPath=/edm 22:31:14,896 INFO [[/edm]] Initializing Spring root WebApplicationContext 22:31:14,897 INFO [ContextLoader] Root WebApplicationContext: initialization started 22:31:14,907 INFO [XmlWebApplicationContext] Refreshing Root WebApplicationContext: startup date [Wed Sep 21 22:31:14 PDT 2011]; rootof context hierarchy 22:31:14,910 INFO [XmlBeanDefinitionReader] Loading XML bean definitions from ServletContext resource [/WEB-INF/applicationContext-business.xml] 22:31:14,911 ERROR [ContextLoader] Context initialization failed: org.springframework.beans.factory.BeanDefinitionStoreException: IOException parsing XML document from ServletContext resource [/WEB-INF/applicationContext-business.xml]; nested exception is java.io.FileNotFoundException: Could not open ServletContext resource [/WEB-INF/applicationContext-business.xml] at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:341) [:3.0.5.RELEASE] at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:302) [:3.0.5.RELEASE] at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:143) [:3.0.5.RELEASE] at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:178) [:3.0.5.RELEASE] at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:149) [:3.0.5.RELEASE] at org.springframework.web.context.support.XmlWebApplicationContext.loadBeanDefinitions(XmlWebApplicationContext.java:124) [:3.0.5.RELEASE] at org.springframework.web.context.support.XmlWebApplicationContext.loadBeanDefinitions(XmlWebApplicationContext.java:93) [:3.0.5.RELEASE] at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:130) [:3.0.5.RELEASE] at org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:467) [:3.0.5.RELEASE] at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:397) [:3.0.5.RELEASE] at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:276) [:3.0.5.RELEASE] at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:197) [:3.0.5.RELEASE] at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:47) [:3.0.5.RELEASE] at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3369) [:6.1.0.Final] at org.apache.catalina.core.StandardContext.start(StandardContext.java:3828) [:6.1.0.Final] at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:294) [:6.1.0.Final] at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:146) [:6.1.0.Final] at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:476) [:6.1.0.Final] at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118) [:6.1.0.Final] at org.jboss.web.deployers.WebModule.start(WebModule.java:95) [:6.1.0.Final] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_27] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_27] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_27] at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_27] at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) [:6.0.0.GA] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) [:6.0.0.GA] at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) [:6.0.0.GA] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:271) [:6.0.0.GA] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:670) [:6.0.0.GA] at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206) [:2.2.0.SP2] at $Proxy41.start(Unknown Source) at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:53) [:2.2.0.SP2] at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:41) [:2.2.0.SP2] at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:301) [:2.2.0.SP2] at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.SP2] . . . .

In my WAR's web.xml I have specified Spring configuration file locations as:

 <context-param> <param-name>contextConfigLocation</param-name> <param-value> /WEB-INF/applicationContext-business.xml /WEB-INF/applicationContext-security.xml </param-value> </context-param>

So, it seems the relative path of those xml files are well understood by JBoss when the ear file is in exploded format - but if I have the same EAR file in collapsed/archived format, then JBoss cannot locate those xml files.

Both format of ear works fine in JBoss 6.0 - so this might be a bug in 6.1 release?

Can anyone please suggest the possible areas to look for?

Thanks in advance,

1. Re: war-deployment fails on JBoss 6.1 when the "ear" file is in collapsed/archived format

jbossuser71 Sep 22, 2011 3:41 AM (in response to jbossuser71)

I did more debugging.
As part of the stack trace I noticed following.

=================
00:29:17,926 ERROR [StandardContext] Error listenerStart
00:29:17,926 ERROR [StandardContext] Context [/edm] startup failed due to previous errors
00:29:17,929 INFO [[/edm]] Closing Spring root WebApplicationContext
00:29:17,935 ERROR [AbstractKernelController] Error installing to Start: name=jboss.web.deployment:war=/edm state=Create mode=Manual re
quiredState=Installed: org.jboss.deployers.spi.DeploymentException: URL file:/C:/discovery_manager/edm/appserver/server/default/tmp/vfs
/automount5d67b4cc2c2a38ae/edm.ear-c3f755775af83fc3/contents/web.war/ deployment failed
        at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:325) [:6.1.0.Final]
        at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:146) [:6.1.0.Final]
        at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:476) [:6.1.0.Final]
        at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118) [:6.1.0.Final]
        at org.jboss.web.deployers.WebModule.start(WebModule.java:95) [:6.1.0.Final]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_26]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_26]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_26]
        at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) [:6.0.0.GA]
=============================

Now, using windows explorer, when I navigate to that directory, i.e. "C:\discovery_manager\edm\appserver\server\default\tmp\vfs\automount5d67b4cc2c2a38ae\edm.ear-c3f755775af83fc3\contents\web.war\WEB-INF" directory, there I could not locate any XML file - that means JBoss could not properly extract the WAR file content under "tmp" folder, for some reason.
I believe it is a bug in 6.1

This explains when I explicitly deploy the ear in "exploded" format, it works.
Can anyone validate what I am trying to refer here?
Actions