Hi David I am using my own Deployement/Undeployment notifications and I am only using them when a file is going to be deployed. This is one of the first steps during deployment and I am not interested in the following steps.
Andy ----- Original Message ----- From: "David Jencks" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, April 12, 2002 7:04 PM Subject: Re: [JBoss-dev] Deployment Notifications in JBoss 3.0 changed > 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 > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
