As opposed to the current Configuration Service that already pases the MLet
semantics to XML???
why?
marc
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of
|Lemoine David-dlemoi01
|Sent: Wednesday, April 11, 2001 11:05 AM
|To: '[EMAIL PROTECTED]'
|Subject: RE: [JBoss-dev] Custom startup solved !? was: Nested JMX
|Service Groups...??!
|
|
|Hi,
|
|Whatever solution you decide on for this problem, I think it could
|be a good idea to replace the current MLet MBean-loader with
|Stacy's XML-based XMLet.
|
|Just my 2 irish cents,
|
|David.
|
|-----Original Message-----
|From: Stacy Curl [mailto:[EMAIL PROTECTED]]
|Sent: 11 April 2001 15:33
|To: '[EMAIL PROTECTED]'
|Subject: RE: [JBoss-dev] Custom startup solved !? was: Nested JMX
|Service Groups...??!
|
|
|Ok, sorry for the misunderstanding. I think that putting extra methods onto
|JBoss MBeans is one technique, but this is an example of meta-data. I think
|a better technique would be to do something like:
|
|// My XML is rusty
|
|<xmlet code="JBossService">
| <meta-data>
| &JbossServiceEntry;
| <!-- No life cycle, default to JBoss Service lifecycle -->
| </meta-data>
|</xmlet>
|
|<xmlet code="JettyMBean">
| <meta-data>
| <!-- No JBossServiceEntry, will not be managed by ServiceControl -->
| &JettyEntry;
| </meta-data>
|</xmlet>
|
|<xmlet code="FlibbleMBean">
| <meta-data>
| &JbossServiceEntry;
| &FlibbleLifeCycleEntry;
| </meta-data>
|</xmlet>
|
|where JBossServiceEntry is:
|
|<!ENTITY name="JBossServiceEntry"
| CDATA[
| <entry>
| <key><param class="java.lang.String">JBossService</param></key>
| <value><param class="boolean">true</param></value>
| </entry>
| ]]>
|
|<!ENTITY name="FlibbleLifeCycleEntry"
| CDATA[
| <entry>
| <key>
| <param class="java.lang.String">life-cycle-start</param>
| </key>
| <value>
| <param class="MethodSignature[]">
| <param class="MethodSignature">
| <param class="java.lang.String">init</param>
| </param>
| <param class="MethodSignature">
| <param class="java.lang.String">start</param>
| </param>
| </param>
| </value>
| </entry>
| ]]>
|
|This moves the burden from MBean's to the config, and it gives you the
|ability to change what is considered to be a JBossService without changing
|code.
|
|-----Original Message-----
|From: Julian Gosnell [mailto:[EMAIL PROTECTED]]
|Sent: 11 April 2001 12:00
|To: [EMAIL PROTECTED]
|Cc: [EMAIL PROTECTED]
|Subject: RE: [JBoss-dev] Custom startup solved !? was: Nested JMX
|Service Groups...??!
|
|
|Stacy,
|
|I like your idea of abstracting the lifecycle mapping.
|However, as I understand your description here, it
|still does not address my problem.
|
|You suggest that in the absence of valid metadata, you
|would assume the default lifecycle (I assume you mean
|default JBoss Service lifecycle).
|
|The problem is that not all MBeans that may wish to
|publish their interface via the JBoss JMX agent
|necessarily want their lifecycle managed by
|ServiceControl. They may not be a Service.
|
|I suggest that the default behaviour should be _NOT_
|to assume that every registered MBean is a Service.
|
|Services should publish a method - e.g.
|isAJBossService(), which can be looked for by
|ServiceControl. This could be added to Service,
|implemented in MBeanServiceSupport etc, bringing most
|MBeans used in JBoss into the fold.
|
|3rd party MBeans developed outside JBoss, but finding
|themselves running inside JBoss would then be free to
|share the JBoss JMX Agent, without fear of being
|tampered with by ServiceControl.
|
|I am asking for a clear division between JMX and JBoss
|Services. JBoss Services may be MBeans, but not all
|MBeans are JBoss Services.
|
|I hope this makes sense,
|
|
|Jules
|
|--- Stacy Curl <[EMAIL PROTECTED]> wrote:
|> 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
|
|
|__________________________________________________
|Do You Yahoo!?
|Get email at your own domain with Yahoo! Mail.
|http://personal.mail.yahoo.com/
|
|_______________________________________________
|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
|
|_______________________________________________
|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
