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
