Notification of shutdown commencing
by Brian Stansberry
I can't figure out a way to produce a notification of an impending
server shutdown if a user does a soft kill of the server process.
It's easy enough if shutdown is initiated by a management op; the op
handler can trigger the notification. But a soft kill triggers a
shutdown hook registered by the MSC ServiceContainer, and once that
starts, services start stopping semi-randomly and its too late to notify
anyone that that is going to start happening.
The MSC shutdown stuff isn't exposed, so there's no way to tie into
that. Adding another shutdown hook doesn't help as there's no
predictable order of execution.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
11 years, 8 months
Application-specific server side invocation interceptors?
by Jaikiran Pai
Just saw this thread on the user forum
https://community.jboss.org/thread/205538?tstart=0 where the user is
trying to plugin a custom server side interceptor (based off the JBoss
Invocation project) in the EE invocation chain. It seems to me that he
has a valid use case, but we currently don't support adding new
application-specific (non EE) interceptors to the invocation. Is this
something that we should be supporting? Or is there some other way to do
what he's trying to do?
-Jaikiran
11 years, 11 months
How to deprecate a AS7 resource attribute
by Jeff Mesnil
As I help to integrate HornetQ 2.3 into AS7, we have to deprecate a few attributes that are no longer supported by HornetQ.
Every time I have to deprecate an attribute I wonder if I have not forgotten to do something.
I wrote a little checklist in the Wiki[1].
I'll follow it to always deprecate attributes in the same way. I might be wrong but I'll be consistently wrong :)
Feel free to comment if you think something is missing/incorrect.
jeff
[1] https://community.jboss.org/wiki/HowToDeprecateAnAS7Attribute
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
12 years, 2 months
as7-master-testsuite-ip6 - Build # 4329 - Failure!
by ci-builds＠redhat.com
as7-master-testsuite-ip6 - Build # 4329 - Failure:
Check console output at to view the results.
Public: http://hudson.jboss.org/hudson/job/as7-master-testsuite-ip6/4329
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.testSimpleBundleWithJarExtension
Error Message:
java.util.concurrent.ExecutionException: java.io.IOException: <html><head><title>JBoss Web/7.0.17.Final - 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>HTTP Status 500 - </h1><HR size="1" noshade="noshade"><p><b>type</b> Exception report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>The server encountered an internal error () that prevented it from fulfilling this request.</u></p><p><b>exception</b> <pre>javax.servlet.ServletException: No resources org.apache.catalina.servlets.DefaultServlet.init(DefaultServlet.java:284) javax.servlet.GenericServlet.init(GenericServlet.java:242) org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:165) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:372) org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679) org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) java.lang.Thread.run(Thread.java:662) </pre></p><p><b>root cause</b> <pre>javax.naming.NameNotFoundException: comp/Resources -- service jboss.naming.context.java.comp.Resources org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:97) org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179) org.jboss.as.naming.InitialContext.lookup(InitialContext.java:119) org.jboss.as.naming.NamingContext.lookup(NamingContext.java:215) javax.naming.InitialContext.lookup(InitialContext.java:392) org.apache.catalina.servlets.DefaultServlet.init(DefaultServlet.java:279) javax.servlet.GenericServlet.init(GenericServlet.java:242) org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:165) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:372) org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679) org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) java.lang.Thread.run(Thread.java:662) </pre></p><p><b>note</b> <u>The full stack trace of the root cause is available in the JBoss Web/7.0.17.Final logs.</u></p><HR size="1" noshade="noshade"><h3>JBoss Web/7.0.17.Final</h3></body></html>
12 years, 2 months
[AS7-5477] Allow processing of the module phase to be deferred
by Thomas Diesler
Folks,
the patch set is ready for review: #3117
<https://github.com/jbossas/jboss-as/pull/3117>
This functionality is constraint to osgi only. If there is a bundle
deployment that cannot resolve (possibly the user said so) I'll set the
FIRST_MODULE_USE phase to initial NEVER. The deployment hangs in the
configure module phase and awaits an external trigger. The bundle is
metadata valid and in state Bundle.INSTALLED.
A Bundle.start() operation sets up a service tracker and activates the
deferred phase. this only succeeds if the bundle can get resolved and
has a Module attached. The bundle deployment proceeds through the phases
and activates. If there is failure in any of the tracked services
Bundle.start() will fail with the root cause and the FIRST_MODULE_USE
phase is set back to NEVER - this is a partial undeploy. After
correcting the problem the user can re-attempt a Bundle.start().
In case of bundles contained in an EAR, I set the FIRST_MODULE_USE phase
of the EAR to PASSIVE.
It is possible that some DUPs dont support repeated deploy calls (yet).
In which case they use
DeploymentUtils.skipRepeatedActivation(deploymentUnit, 0)
with the number of attempts they do support (see
ModuleJndiBindingProcessor
<https://github.com/tdiesler/jboss-as/commit/0f7fd068206f2a49c006f3c633057...>).
Some techs that support bundle deployments (i.e.
web,jaxrs,jaxws,jpa,cdi,ejb3) may still need more work to support
restart after failure. This can be done on a case by case basis.
Generally DUPs can now assume that a module is attached for a host
bundle deployment. In case of an unresolved bundle deployment we don't
miss the work they do any more. However, we still need the module not
null checks because bundle fragment deployments never have a module.
They attach to a host and use that class loader.
Thoughts?
cheers
--thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
12 years, 2 months
Serialization, proxies issue & AS7-5496
by Scott Marlow
I was able to reproduce the CNFE issue reported in AS7-5496 (using MySQL
+ the test case attached to the jira).
The jira reports that the CNFE problem only occurs with Hibernate (using
EclipseLink is a workaround). I suspect that EclipseLink might not be
using a proxy for the lazy association but not really sure. According
to the jira, this also used to work with AS5 (older Hibernate).
During the first EJB client invocation, an entity is returned that
contains a (lazy assocation) proxy that seems to be handled by a call to
readResolve(). During the readResolve(), the original
org.hibernate.proxy.pojo.javassist.SerializableProxy instance is
replaced with a newly generated class
de.seimet.photo.entity.Location_$$_javassist_2 instance.
However, when the returned entity is passed to the other EJB client
invocation (as a parameter), the generated class
de.seimet.photo.entity.Location_$$_javassist_2, will not be known on the
server side (causing the cnfe.)
More details are in the jira.
I'll try using the older version of Hibernate and see if that helps.
Any other suggestions?
Scott
12 years, 2 months
Branch question: 7.1-next vs 7.1
by Tom Jenkinson
Apologies if this has been asked (possibly multiple times) before -
searching the mailing list archives is as not simple as SBS (though
would love to be educated otherwise).
Please can someone clarify the difference between the 7.1 and 7.1-next
branches? Near as I can tell they are identical so I just wondered as to
their purpose: https://github.com/jbossas/jboss-as/compare/7.1-next...7.1
Thanks,
Tom
12 years, 2 months
