Thanks Adrian, I will leave the notification content as is and make DeploymentInfo accessible from MainDeployer via a managed-operation.
(Less work, too;-) Thanks david On 2002.04.13 20:26:31 -0400 Adrian Brock wrote: > Hi, > > Just a heads up. > > I realise this notification was originally only used > by the farm service, and is only used locally. > But ideally all JMX notifications should contain > Serializable data, for people who want to monitor > remotely. > Currently, the DeploymentInfo isn't Serializable. > > Regards, > Adrian > > > 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) > > L = (URL) pNotification.getUserData(); > > > > to: > > > > URL lURL = > > RL 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-dev > > lopment > > > _________________________________________________________ > View thread online: http://main.jboss.org/thread.jsp?forum=66&thread=8622 > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
