> You have to generate a jboss-service.xml anyway to put in the .sar to get > the mbean deployed, so use the xdoclet -service.xml file generator to > generate it for you. It already includes the mbean name specified in the > @jmx.mbean tag. If you want attributes, make xdoclet generate them also.
But this doesn't alleviate the *-service.xml file from needing to know the administration domain. And if I ever want to change the administration domain (or make it deployment specific), i need to modify every *-service.xml file. Xdoclet is great, but it also munges responsibilities a tad. For instance, an EJB developer is not intended to be the person who assigns a JndiName. However, in Xdoclet, JndiName can be put and maintained in the code itself. (Don't get me wrong, I haven't worked on a project where this isn't the case anyway, but it still is an example of how Xdoclet is used to merge responsibilities defined in the spec) In the end, I feel that this is just one of those things, that should behave according to the spec. Mike > > david jencks > > On 2002.07.30 17:27:02 -0400 Michael Stanley wrote: > >>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 >> >> > > > > ------------------------------------------------------- > 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
