You know I read your MBean deployment message back on 10Sep2001, but it didn't really penetrate because we had already added the DeploymentNotification mechanism to 2.4x. I think I could re-engineer my code to fit within the .sar approach. What I called "creating MBeans instances" associated with an archive was one of the things I had implemented on top of the DeploymentNotifcation mechanism, and is exactly what the .sar/-service.xml mechanism does. I wish I had known perhaps we could have worked on it together <sad shake of head>. I still am figuring out how to participate. The other two things I use it for are loading data for existing MBeans. I could specify MBean instances in the -service.xml file that would have no real interface, but in the start method, find the global MBean and add the data to its dictionary, or in the other way I was using it, execute a series of SQL commands. Do you think it perverse to create MBean classes with no interfaces that just load data for other MBeans? My current mechanism just looks at every archive for a particular name .xml file (for each kind of function) and then processes it. Let me know what you think. Didn't you say if a .sar and EJB were bundles, the MBeans would get processed first? Thank you.
Fred Brier At 10:04 PM 4/12/2002, you wrote: >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
