Looks OK to me. I'll check with Andy about the FarmService. Do you need notifications of each step (there are actually 5 or 6) or are the deploy and undeploy notifications enough?
I'm not sure exactly what you are using the notifications for, but I assume you know about the *-service.xml files and sar files, which let you deploy sets of mbeans at any time? There is also a dependency mechanism that lets mbean deployment wait for other mbeans (including ejbs, but right now you can't make an ejb wait for anything;-). david jencks On 2002.04.12 20:33:09 -0400 Frederick N. Brier wrote: > 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 > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
