This would be cool, very cool in fact, but a little ambitious for my
available time frame right now. I think I will go ahead with the simple
dependency checking I outlined previously. Unless there is someone who feels
like taking on your challenge...
David
> -----Original Message-----
> From: Rickard �berg [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, September 06, 2001 3:08 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Deployment Dependencies (was RE: [JBoss-dev] RH
> startup and
> JBossMQ)
>
>
> marc fleury wrote:
> > | <?xml version="1.0" encoding="UTF-8"?>
> > | <server>
> > |
> > | <depends>JBOSS-SYSTEM:service=Naming</depends>
> > | <depends>JBOSS-SYSTEM:service=AnotherService</depends>
> > |
> > | <classpath archives="jbossmq.jar"/>
> > |
> > | <mbean code="org.jboss.mq.server.JBossMQService"
> > | name="JBossMQ:service=Server"/>
> > |
> > | *snip*snip*
> > |
> > | </server>
>
> Sometime in a bright future this, and the actual service config stuff,
> really should be in RDF (http://www.w3.org/RDF/). It would be
> very very
> cool as it wouldn't then be XML-dependent, i.e. you could store it in
> the-whatever-store (e.g. LDAP, e.g. RDBMS).
>
> > Thanks that is an easy solution. You will create a graph
> of dependencies in
> > the service controller. It was needed for the longest
> time. If I remember
> > correctly someone coded that long time ago and you might
> find a trace of the
> > dependency manager somewhere in the attic.
>
> I implemented this in my XS server (google on it to find it
> :-), and it
> was one of the things I've been missing in JBoss. Should've been done
> properly ages ago.
>
> > My own vote on my own suggestion at this point is thumbs
> down for the simple
> > reason that the "explicit" MBean dependency is simpler for
> us to code. So go
> > ahead with your idea, XP.
>
> Yes, explicit is probably better.
>
> > It is simpler than ClassLoader dependency graphs that a
> certain Rickard
> > Oberg was advocating
>
> ehrm.. wouldn't say advocating, more like mentioned as a possibility.
> Aaanyway.
>
> > for administrators to build, but it is still "MBean
> > dependencies" built by administrators when we could do away
> with it. I
> > don't see a problem with requiring that administrators be
> aware of what
> > services depend on what services. It seems like a natural
> task, jason?
>
> I'd like to pop in a thought from the Jini-line of thinking:
> in Jini you
> don't specify what services you want, instead you say "I want
> something
> that looks like this". Of course, if you specify enough you
> will end up
> with saying exactly which service you want, but that's not
> the standard
> case. The J2EE way, or rather the JNDI way, is to say "I want
> the object
> named X", so there's no flexibility. You know what you want,
> and that's
> that. It's rather uninspired IMnsHO.
>
> So, one could adopt the Jini way and let the developer of the
> MBean, not
> the administrator of the server, say "This MBean depends on the
> availability of other MBeans looking like this and this".
> That could be
> expressed either in code, or in XML. The key point is that this
> shouldn't really have to be done in the configuration of the
> service/server, because it involves knowledge that the admin really
> *shouldn't have to have*.
>
> Also, one could argue whether to put this in the MBean itself or in a
> separate MBean. Inside the MBean would mean that the MBean
> itself could
> be put into any other server and still function, whereas in a separate
> MBean would then require that this extra MBean is also deployed in the
> server (which may be != JBoss).
>
> Actually, one could have the same argument about the configuration
> persistence. Currently the JBoss server "pushes" config to the MBean,
> whereas it is much more portable to let the MBean pull. And I believe
> the JMX spec actually promotes this way of doing it (look at the
> PersistentMBean/ModelMBean interface). That said, the actual
> MBean could
> still be using get/set methods, it's just that the MBean itself uses
> some util code to get the config and call these methods by using
> reflection on itself. The result is a more self-contained
> MBean that can
> live in a more "core JMX" environment.
>
> Wouldn't that be just cool.
>
> /Rickard
>
> --
> Rickard �berg
> Software Development Specialist
> xlurc - Xpedio Link�ping Ubiquitous Research Center
> Author of "Mastering RMI"
> Email: [EMAIL PROTECTED]
>
> _______________________________________________
> 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
