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
