I had submitted some JMX deployment notification code
(DeploymentNotification class and mods to the J2eeDeployer class) which was
incorporated into JBoss 2.4x. I've just started migrating to JBoss 3.0 and
noticed that the DeploymentInfo object is not passed in the Notification
anymore, only the url data member is passed to the setUserData() method in
MainDeployer.java. I specifically need the localUrl, but the other info
was useful as well. This was so that I could open XML files that might
exist within the deployed archive. The XML files contain SQL commands (to
create additional indexes or load initial data into tables), create dynamic
MBeans instances, and provide configuration data for currently running MBeans.
As far as I can tell, changing the parameter of setUserData() to the di
(DeploymentInfo) from just the URL (di.url) would only effect one line of
code in the distribution. That would be line 459 in FarmMemberService.java
from:
URL lURL = (URL) pNotification.getUserData();
to:
URL lURL = ((DeploymentInfo)pNotification.getUserData()).url;
The other request is to move the sendNotification() in
MainDeployer.deploy() [line 514] down 4 lines after the start() method
call. This is because the archive hasn't been expanded yet. I am guessing
that when the deployer was re-architected, the number of notifications was
cut from 4 to 2. The deployment architecture has undergone major revision,
so it isn't really possible to trap after the archive is expanded by
AbstractWebContainer.buildWebContext(), but before it is start()ed. This
is because the MainDeployer.deploy() calls SubDeployer.start() which calls
AbstractWebContainer.start() which calls buildWebContext(). So it all
happens in one fell swoop. I believe that the buildWebContext()
functionality was originally in an init() method which allowed us to place
the notification in between the init() and the start().
From a symmetric point of view the Undeployment notification, occurring
within MainDeployer.undeploy(), should probably be moved before the stop(),
but if dependent MBean services are removed before the archive is stopped,
this could cause problems in redeployment, so perhaps it could be moved
between the stop() and the destroy() [line 342]. If the XML files are
removed prior to shutdown, it requires the Notification handler to cache
any shutdown operations and associate them with archive in a collection. I
am open to suggestions.
Thank you again.
Frederick N. Brier
Sr. Software Engineer
Multideck Corporation
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
