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.
Principal Software Engineer
JBoss by Red Hat
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?
is this intentional?
IMO quickstarts should be foolproof, and one of ways to make it so
should be that `mvn clean install` should pass without requirements
like "AS is running on port 8080".
java.lang.RuntimeException: Failed request with HTTP status: 404
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.
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.
JBoss, a division of Red Hat
the patch set is ready for review: #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
with the number of attempts they do support (see
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.
JBoss OSGi Lead
JBoss, a division of Red Hat
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
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?
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