an explicit undeploy operation should remove state that otherwise needs
to survive server restart.
How can I distinguish between these two cases in a DUP?
JBoss OSGi Lead
JBoss, a division of Red Hat
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?
We are going to be starting the basis for EAP 6.1 using the master branch, which will freeze on Jan 8. Please notify me immediately if you have unfinished or unstable features currently in master. We need to stabilize, disable, remove, or mark tech preview anything that is incomplete and not on the high-priority feature list below . Also starting today, any pull request introducing a new feature that is not on the priority list will not be merged.
As an example, patching and ha singleton will not be merged, they will be consumed for 6.2.
If you have any questions just let me know.
 High Priority 6.1 Alpha List:
PRODMGT-196 - Dynamic remoting configuration using InitialContext (in progress)
PRODMGT-247 - Trusted EJB Security context propagation (in progress)
PRODMGT-254 - Interceptor support for custom protocol data in ejb invocations (in progress)
PRODMGT-46 - Centralize Datasource Password Encryption (Done)
PRODMGT-195 - Expand usage of property substitution in management model (Done)
JBPAPP-1456 - PCKS11 keystore support (done)
JBPAPP-923 - Key alias is not managable (Done)
PRODMGT-200 - Application specific logging configuration (done)
AS7-5768 - Module based RARs
I'd like to try to leverage JUnitDiff for AS CI.
(older version, I don't have nice enough data to show with new)
Could we please archive the test report files of this job?
All I need is something like this at the end:
find testsuite/ -name 'TEST-*.xml' -or -name '*-output.txt' | zip
and have testsuite-reports.zip archived.
The zip currently has 2.7 MB if there are no or few errors. The job
keeps 100 runs. That's 270 MB, I think that's no problem.
JUnitDiff has an integration with Jenkins - a plugin which can create
these reports automatically.
It could help detect intermittent tests more easily; also, it could help
with certain analysis, like test failures corelation etc.
So if it proves useful, we could add it to the builds.
If not, at least me and Honza Brazdil will have some real data to test
JUnitDiff with :)