I think that having an abstract life cycle of: init, start, ping, stop, destroy is ok, but constraining MBeans to implement init(), start(), ping(), stop(), destroy() methods is not ok. So I think replacing a service is a mistake but abstracting parts of it isn't. So the ServiceControl would continue to listen for registration of MBeans and be responsible for doing init, etc but would first obtain the actual methods to call from the MetaDataService, in the absence of any life-cycle meta-data the ServiceControl would default to the standard methods, at present there are work arounds such as catching ReflectionExceptions after invoking 'start' and assuming (rightly or wrongly) that this means the MBean doesn't have a start method. I think that ServiceControl doesn't manage dependancies, it just aggregates MBeans. The dependancies seem to be implicit in the order in the MLet resource file. This is ok if you want to start/stop all the mbeans but not if you want to start/stop a subset. I think we should be following the style in ant and do something like: <mlet name="really-important/> //... <mlet name="not-important" depends="really-important"/> -----Original Message----- From: Scott M Stark [mailto:[EMAIL PROTECTED]] Sent: 10 April 2001 23:57 To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Custom startup solved !? was: Nested JMX Service Groups...??! Are you talking about a new service that replaces org.jboss.util.ServiceControl or a new service? The ServiceControl MBean that manages service lifecyle also manages service dependencies and the invocation of init() and start() are distinct phases. When start is called on a service you know that every service has received an init() and every service you depend on has received a start(). ----- Original Message ----- From: "Stacy Curl" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "'Julian Gosnell'" <[EMAIL PROTECTED]> Sent: Tuesday, April 10, 2001 2:09 PM Subject: RE: [JBoss-dev] Custom startup solved !? was: Nested JMX Service Groups...??! > I think that the JBoss inspired life-cycle is too restrictive, I'd > like to be able to define life-cycle schemas in the XMLet resource > file, or in another XML file. An XMLet version might look something > like: > > <xmlets> > <xmlet code="com.sun.jdmk.comm.HtmlAdaptorServer" > archive="jmxtools.jar" > name="DefaultDomain:name=HtmlAdaptorServer"> > <meta-data> > <life-cycle> > <start> > <method name="init"/> > <method name="start"/> > </start> > <stop> > <method name="stop"/> > <method name="destroy"/> > </stop> > <ping> > <method name="ping"> > <input> > <!-- timeout --> > <param class="long">500</param> > </input> > <desired-output> > <param class="boolean">true</param> > </desired-output> > </method> > </ping> > </life-cycle> > </meta-data> > <arg type="int" value="8082"/> > </xmlet> > </xmlets> > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
