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, 7 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, 10 months
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
Where to put test cases for fixes?
by Brad Maxwell
Hello, is there any particular place we should be putting unit tests for
bugs that get fixed?
I see these various tests are laid out, I'm making a test case for an
issue related to a Sar deployment, which is in integration, but then it
isn't clear where it might go under there, currently I have it in smoke
because there are related tests there, but it seems like my test might
should be elsewhere.
Any thoughts?
* benchmark - benchmarking integration tests
* compat - compatibility tests (require special dependencies)
* domain - domain management integration tests (require special
framework)
* integration - general integration tests
* stress - stress integration tests
basic/ clust/ iiop/ manualmode/ multinode/ osgi/
smoke/ xts/
Thanks,
Brad
12 years, 1 month
FYI, a new version of Javassist will soon be available which will have a fix for JASSIST-163 (impacts Weld, jbossws-native-core, scannotation, slf4j, Hibernate)...
by Scott Marlow
After 3.1.17 of Javassist is released and testing looks good, we can
look at AS7-5127 which is about upgrading javassist in as7 to improve
performance (as long as the new javassist doesn't break anything).
Obviously, if Javassist 3.1.17 breaks something, we will not be able to
upgrade.
I took a look at which AS7 modules (statically) depend on javassist and
the list is:
1. Weld
2. jbossws-native-core
3. scannotation
4. slf4j
5. Hibernate
I'm testing Hibernate with the new javassist but don't know how to test
(1), (2), (3), (4) above. Is there anything else that we need to try
besides the AS7 testsuite to gain confidence that we can upgrade to
javassist 3.1.17 (after its released soon)?
I built trunk of javassist locally and caught one minor failure with the
Hibernate test suite (see yesterdays comments in JASSIST-163). I'm
built AS7 with the updated hibernate/javassist jars and passed the AS7
testsuite.
If anyone wants to do additional testing with the javassist trunk, let
me know and I'll ask for more time to do testing before 3.1.17 is
released. Or others could also coordinate through JASSIST-163.
Scott
12 years, 1 month
