Subsystem specific deployer configurations in standalone.xml/domain.xml
by Brian Stansberry
I've been working $subject in order to help support Thomas Diesler's
request for AS7-3694[1]. The gist of this request is to add deployment
unit processing (DUP) configuration as children of the deployment
resource itself. Thomas' OSGi use case is one place where this would be
used. I expect HASingleton deployment will be another.
WIP is at [2]. I'm looking for feedback. :)
What I've done is based on what Thomas did at [3]. What I want to do is
move from the generic key/value pairs in that patch to a more formally
describable management API. Instead of:
<deployment name="foo.war"...>
<properties>
<property name="start.policy" value="DEFERRED"/>
<property>
</deployment>
It would be something analogous to how a profile configuration is done:
<deployment name="foo.war"...>
<deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
<start-policy value="deferred"/>
</deployment>
</deployment>
The existing Extension API already has the hooks to support this.
Extensions can register xml parsers for children of the <deployment>
element and can register management resources to act as children of the
/deployment=foo.war resource as well. Several subsystems already take
advantage of the latter. Until now the former has been an unimplemented
API. The commit at [4] implements it.
A couple things giving me some concern:
1) The above xml:
<deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
Nicer would be something like:
<deployers>
<subsystem xmlns="urn:jboss:domain:osgi:1.2">
I need to figure out if I can do some tricks with the parsing to allow
that to happen.
2) The structure of the resource tree. We already support resources like
this:
/deployment=foo.war/subsystem=web
Subsystems register resources like those to expose metrics. The commit
at [4] uses that same tree. When subsystems could now register child
resources to the deployment=* resource, they could include both runtime
stuff and configuration stuff.
I'm not sure that mixing the two is ideal, although it's what we do for
the regular subsystem resources in the profile. I'm vaguely concerned
that if someday the configuration that subsystems choose to expose via
this mechanism gets complex, the mixing of metrics with configuration in
the same tree will start to break down.
Comments are appreciated.
[1] https://issues.jboss.org/browse/AS7-3694
[2] https://github.com/bstansberry/jboss-as/commits/AS7-3694
[3] https://github.com/jbossas/jboss-as/pull/3230
[4]
https://github.com/bstansberry/jboss-as/commit/6326003a104ac4ac825e8dda4c...
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
12 years
Deployment Diagnostics
by Stephen Coy
Hi there,
Has anyone given much thought to providing more diagnostics when things go wrong during deployment.
For example, I recently encountered a problem with an EAR deployment that failed silently.
A thread dump revealed that it was stuck at the wait in org.jboss.as.ee.component.BasicComponent.waitForComponentStart().
I eventually figured out that there was a problem in my jboss-ejb3.xml file, but there were no clues to go on at all.
Another potential issue with this particular problem is that it's not possible to perform a regular server shutdown once it's in the state above. A "kill -9" is required.
I have a sample project that demonstrates this BTW.
Cheers,
Steve Coy
12 years
as7-master-testsuite-ip6 - Build # 5387 - Failure!
by ci-builds＠redhat.com
as7-master-testsuite-ip6 - Build # 5387 - Failure:
Check console output at to view the results.
Public: http://hudson.jboss.org/hudson/job/as7-master-testsuite-ip6/5387
Internal: http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...
Test summary:
1 tests failed.
REGRESSION: org.jboss.as.test.integration.osgi.webapp.WebAppTestCase.testBundleWithWebContextPath
Error Message:
java.util.concurrent.ExecutionException: java.io.IOException: <html><head><title>JBoss Web/7.2.0.Alpha2 - JBWEB000064: Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>JBWEB000065: HTTP Status 500 - No resources</h1><HR size="1" noshade="noshade"><p><b>JBWEB000309: type</b> JBWEB000066: Exception report</p><p><b>JBWEB000068: message</b> <u>No resources</u></p><p><b>JBWEB000069: description</b> <u>JBWEB000145: The server encountered an internal error that prevented it from fulfilling this request.</u></p><p><b>JBWEB000070: exception</b> <pre>javax.servlet.ServletException: No resources org.apache.catalina.servlets.DefaultServlet.init(DefaultServlet.java:278) javax.servlet.GenericServlet.init(GenericServlet.java:242) org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:652) org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:919) java.lang.Thread.run(Thread.java:662) </pre></p><p><b>JBWEB000071: root cause</b> <pre>javax.naming.NameNotFoundException: comp/Resources -- service jboss.naming.context.java.comp.Resources org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:103) org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193) org.jboss.as.naming.InitialContext.lookup(InitialContext.java:120) org.jboss.as.naming.NamingContext.lookup(NamingContext.java:182) org.jboss.as.naming.NamingContext.lookup(NamingContext.java:178) javax.naming.InitialContext.lookup(InitialContext.java:392) org.apache.catalina.servlets.DefaultServlet.init(DefaultServlet.java:273) javax.servlet.GenericServlet.init(GenericServlet.java:242) org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:652) org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:919) java.lang.Thread.run(Thread.java:662) </pre></p><p><b>JBWEB000072: note</b> <u>JBWEB000073: The full stack trace of the root cause is available in the JBoss Web/7.2.0.Alpha2 logs.</u></p><HR size="1" noshade="noshade"><h3>JBoss Web/7.2.0.Alpha2</h3></body></html>
12 years
(no subject)
by Srineel Mazumdar
Hi,
Using STS 3.1 with JBOSS AS7.1.1 final. Right clicking on application and
selected Run On Server. Gives 404 error. The same process works fine for
Glassfish server. Checked standalone folder
(C:\Server\jboss-as-7.1.1.Final\standalone\deployments\NewPetstore.war).
The war is deployed.
Please help.
Regards,
Srineel
12 years
