[Design of POJO Server] - JBAS-7032 or ClassLoader::getResources
by alesj
Moving this discussion to the forum.
"jaikiran" wrote :
| I could reproduce this issue:
|
| 1) Deploy an non-scoped/non-isolated Seam Ear application in 5.1.0 AS
| 2) Start the server which has the admin console
| 3) Access the admin console http://localhost:8080/admin-console
|
| 09:28:24,728 ERROR [[/admin-console]] Exception sending request initialized lifecycle event to listener instance of class org.jboss.on.embedded.LazyStartupListener
| java.lang.RuntimeException: error while reading /WEB-INF/components.xml
| at org.jboss.seam.init.Initialization.initComponentsFromXmlDocument(Initialization.java:221)
| at org.jboss.seam.init.Initialization.create(Initialization.java:124)
| at org.jboss.seam.servlet.SeamListener.contextInitialized(SeamListener.java:34)
| at org.jboss.on.embedded.LazyStartupListener.initialize(LazyStartupListener.java:182)
| at org.jboss.on.embedded.LazyStartupListener.requestInitialized(LazyStartupListener.java:240)
| at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:180)
| at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
| at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
| at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
| at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
| at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
| at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
| at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
| at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
| at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
| at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
| at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
| at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
| at java.lang.Thread.run(Thread.java:595)
| Caused by: java.lang.RuntimeException: Error loading element Identity with component name null and component class null
| at org.jboss.seam.init.Initialization.installComponentsFromXmlElements(Initialization.java:342)
| at org.jboss.seam.init.Initialization.initComponentsFromXmlDocument(Initialization.java:217)
| ... 18 more
|
|
| A bit of debugging shows that the real issue appears to be the way BaseClassLoaderDomain.getResources is implemented:
|
| void getResources(BaseClassLoader classLoader, String name, Set urls, boolean allExports) throws IOException
| {
| 1) beforeGetResources()
| 2) GetResourcesFromTheClassloader()
| 3) GetResourcesFromTheParentClassloader()
| }
|
|
| This method behaves unlike the getResource() method which returns immidiately after finding the resource from the first classloader which has access to the resource. The getResources() on the other hand pulls out the resource URLs from *all* the classloaders in the hierarchy and their exports.
|
| So in this scenario when the admin-console is being processed and a request for META-INF/components.xml is made from within this app's classloader:
|
| 1) Finds the META-INF/components.xml within the jar(s) of this admin-console.war
| 2) Goes to the parent of this admin-console.war classloader which exposes META-INF/components.xml available in the non-scoped/non-isolated Seam EAR.
| 3) Effectively, this returns a list of URLs from different (unrelated) applications and messes up the admin console
|
|
| From my understanding of the semantics of Classloader.getResources(String name) and the javadoc, i think the BaseClassLoaderDomain.getResources(BaseClassLoader cl, String name, Seturls, boolean allExp) is probably incorrect.
|
| As an workaround, i think we should probably set the EAR deployments to be isolated by default. That way we won't have a broken admin-console when some other user application with Seam does not isolate their app.
|
| P.S: There's one more issue i see with the handling of jboss-classloading.xml/jboss-web.xml classloading scoping for war deployments. But i will create a separate thread for that.
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245570#4245570
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4245570
16 years, 8 months
[Design of POJO Server] - Re: Should Touching / changing timestamp of exploded folder
by rob.stryker@jboss.com
For the record, the reason this issue even came up was because some of our tools were able to delete and re-deploy a new version of the app but do so so quickly that the scanner didn't notice the change.
Since there were no descriptors in the deployment the scanner had no way to tell this was a "new" deployment and not the same old one it was used to.
As an example of this, start up a JBoss 5.1 server and execute the following:
mkdir test.war
21:41:08,316 INFO [TomcatDeployment] deploy, ctxPath=/test
21:41:08,343 WARNING [config] Unable to process deployment descriptor for context '/test'
21:41:08,344 INFO [config] Initializing Mojarra (1.2_12-b01-FCS) for context '/test'
rm -rf test.war && mkdir test.war
(NOTHING HAPPENS)
rm -rf test.war
21:42:05,379 INFO [TomcatDeployment] undeploy, ctxPath=/test
So clearly we can see the issue I believe ;) Question is, is there a JIRA for this yet? Should I make one? When will this be supported?
Thanks ;)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245444#4245444
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4245444
16 years, 8 months