I'm currently building a system that requires plugins. We have a plugin development kit that allows developers to quickly write plugins without having to worry about deployment configuration information. The plugin developer simply implements the interface (or subclasses some abstract support plugins).
The plugin development kit, utlizing ANT, and Xdoclet, handles all the EJB stuff, and EAR (or SAR) packaging. This alliviates a lot of the details from the plugin developer. By removing the ObjectName from the configuration file, we can use a generic MBean interface, that builds a unique ObjectName from some other source (or combination there of, like plugin name, and version). This has multiple benefits. It allows the system administrator to set up a domain specific to plugins (and change this easily over time), and allows for a common naming convention to the generic PluginMBean (which allows for common querying). Simply put, it seperates responsibilities of the developer, the assembler, and the administrator. Example == Consider the Widget example I mentioned earlier as being a widget plugin. To develop a widget plugin, a developer simply needs to subclass AbstractWidgetPlugin, and implement the method processWidget. The assembler configures the widget.properties file, which has some properties like name, type, version, and description The kit packages everything up into a nice little uniqueWidget.sar. The administrator drops it into the widget deployment directory on systemA, then turns to his widget administration console, which now has a new entry in the Domain - widget.service.plugins the ObjectName is -> widget.service.plugins:system=A,name=UselessWidget,verison=1.2 The Widget Administrator can then configure the change widget Writable attributes as needed, view the widget's unique system RO attributes, or invoke operations. Mike David Jencks wrote: > This might be possible, but I don't see a use case or any value to allowing > this. Can you explain why you would go to the trouble of writing down the > configuration for a single mbean in a configuration file without knowing > its object name? > > david jencks > > On 2002.07.30 16:23:02 -0400 Michael Stanley wrote: > >>>Yes, depends has to be an ObjectName and it cannot have a pattern. >> >>hmm... The example I showed previosuly using the pattern, seems to be >>working. >> >> >>>ObjectNames are fixed at registration/creation time. If you need an >> >>mbean >> >>>that is so dynamic that its name is not known until it is to be >> >>registered >> >>>use >>>an mbean factory that manages the dependency issues and when approriate >>>registers the mbean with the desired name. >> >>But according to spec ObjectNames can be specified in the preRegister() >>method of MBeanRegistration implementations. From the javadoc to that >>method -> >> >>"Allows the MBean to perform any operations it needs before being >>registered in the MBean server. If the name of the MBean is not >>specified, the MBean can provide a name for its registration." >> >>Wouldn't this be another way to specify the ObjectName rather than >>making it a mandatory attribute in the mbean element of the service.xml >>config file? If ObjectName still isn't specified after running >>preRegister() then you can through the error, but I think making it >>mandatory in the config file isn't neccessary. >> >>Thoughts? >> >>Mike >> >> >>>xxxxxxxxxxxxxxxxxxxxxxxx >>>Scott Stark >>>Chief Technology Officer >>>JBoss Group, LLC >>>xxxxxxxxxxxxxxxxxxxxxxxx >>>----- Original Message ----- >>>From: "Michael Stanley" <[EMAIL PROTECTED]> >>>To: <[EMAIL PROTECTED]> >>>Sent: Tuesday, July 30, 2002 11:40 AM >>>Subject: Re: [JBoss-user] MBean interfaces to EJBs >>> >>> >>> >>> >>>>Cool. Thanks I have things working now. Very nice. >>>> >>>>Question on the depends: Does the value of the <depend> element have to >>>>be the ObjectName? And if so can it be a pattern, or does it have to >>> >>be >> >>>>the full name? >>>> >>>>for example - is something like this legal -> >>>> >>>><depends>*:EJBModule=MyEJB.jar,*</depends> >>>> >>>>Thanks again for your help, >>>>Mike >>>> >>>>PS. Is my note about the sequence of the Deployment notification >>>>accurate? If not, what is the reasoning behind the current order of >>>>events? >>> >>> >>> >>> >>> >>>------------------------------------------------------- >>>This sf.net email is sponsored by: Dice - The leading online job board >>>for high-tech professionals. Search and apply for tech jobs today! >>>http://seeker.dice.com/seeker.epl?rel_code=31 >>>_______________________________________________ >>>JBoss-user mailing list >>>[EMAIL PROTECTED] >>>https://lists.sourceforge.net/lists/listinfo/jboss-user >> >> >>-- >><Mike/> >> >> >> >> >>------------------------------------------------------- >>This sf.net email is sponsored by: Dice - The leading online job board >>for high-tech professionals. Search and apply for tech jobs today! >>http://seeker.dice.com/seeker.epl?rel_code=31 >>_______________________________________________ >>JBoss-user mailing list >>[EMAIL PROTECTED] >>https://lists.sourceforge.net/lists/listinfo/jboss-user >> >> > > > > ------------------------------------------------------- > This sf.net email is sponsored by: Dice - The leading online job board > for high-tech professionals. Search and apply for tech jobs today! > http://seeker.dice.com/seeker.epl?rel_code=31 > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user -- <Mike/> ------------------------------------------------------- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
