On 2002.04.13 15:39:37 -0400 Frederick N. Brier wrote: > 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? I think it's fine to do this. You may find that your new data mbeans start wanting to have operations after you define them;-). I'm not sure if you are aware of the mbean dependency mechanism, using the <depends optional-attribute-name="attributename">objectname</depends>. Using one of these supplies the mbean with it an ObjectName reference to another, and makes it wait in the create and start steps until the mbean it depends on is created and started. This is useful to make sure things start up in the right order.
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. I'm actually no longer sure;-). As of today you can use the dependency mechanism both ways between mbeans and ejb's (or rather their containers). If Scott hasn't frozen the code I'll see about moving the deploy/undeploy notifications anyway. I think they make more sense after deployment is complete/before undeployment starts. thanks david jencks > > 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
