« Return to Thread: Mule Agents 2.0 Configuration

Re: Mule Agents 2.0 Configuration

by Daniel Feist :: Rate this Message:

Hi,

Just a summary of the two options with example schemas and +/-'s we
have discussed...

Option 1:
=======

+ Very easy for different modules to contribute new agents, they just
add a new root elements using the module namespace (and extending
agentType complex type).

- JMX agent dependencies need to be resolved when config is parsed and
agent initialization executed in the correct order. We can do this
for known jmx agents, but ths dependency would need to be specified
somewhere in config I guess for custom jmx agents (either ordering or
"depends-on" attribute)
- Less fool-proof and intuitive for users if they have to use correct
agent order, or add "depends-on" attributes. (I don't like the idea of
requiring "depends-on" attribute.)

<root>
<xsd:element name="jmx-server"/>
<xsd:element name="jmx-mx4j-adaptor"/>
<xsd:element name="rmi-server"/>
<xsd:element name="jmx-notifications"/>
<xsd:element name="jmx-log4j"/>
<xsd:element name="log4j-notifications"/>
<xsd:element name="chainsaw-notifications"/>
<xsd:element name="publish-notifications"/>
<xsd:element name="jmx-default-config">
<xsd:element name="custom-agent" class=".."/>
</root>

Option 2:

+ More intuitive and fool-proof for users to configure jmx-agents
+ Saves complexities and/or agent ordering or extra "depends-on"
attributes (at least for all jmx agents).

- Modules can easily contribute generic agents by adding root
elements, but it is harder (or impossible?) to contribute non-custom
jmx dependent agents from other modules with another namespace in this
way.

Note "jmx-server" creates or locates MBeanServer and is used both for
embedded and standalone jmx instances
.
<root>
<xsd:element name="jmx-server"/>
<xsd:element name="jmx-default-config">
<xsd:element name="jmx-mx4j-adaptor"/>
<xsd:element name="jmx-log4j"/>
<xsd:element name="jmx-notifications"/>
<xsd:element name="jmx-custom-agent" class=".."/>
</xsd:element/>
<xsd:element name="rmi-server"/>
<xsd:element name="log4j-notifications"/>
<xsd:element name="chainsaw-notifications"/>
<xsd:element name="publish-notifications"/>
<xsd:element name="custom-agent" class=".."/>
</root>

Dan

On 8/17/07, andrew cooke <acooke@...> wrote:

> slow reading email today, sorry (and laptop just crashed hard which was a
> bit worrying - no idea why).
>
> anyway, i think people are discussing how extensible we can make schema if
> they need to be nested. a lot depends on the kind of nesting. i couldn't
> find a good solution for filters which nest aribitrarily (you can define
> things like "and-filter" which takes two nested filters for example).
>
> adding at top level is easy - we already have that (connectors). i admit
> i *still* don't understand how this works (at the top level).
>
> adding nested is harder (as far as i can tell) - jmx would need a
> "managed" element, which other modules would "subclass". so it would look
> like:
>
> <mgmt:jmx-server>
> ....
> <foo:managed>
> <foo:something/>
> <foo:another/>
> </foo:managed>
> <bar:managed>
> <bar:kofrekfoper/>
> </bar:managed>
> </mgmt:jmx-server>
>
> if that's not sufficient (and there's not something i've missed that makes
> this easier than i think, related to the top level inclusion) you could
> perhaps express dependencies explicitly:
>
> <mgmt:jmx-server name="jmx"/>
> <foo:managed name="bob" dependsOn="jmx"/>
> <bar:kodpsako dependsOn="jmx,bob"/>
>
> and then use that to construct a graph, check it doesn't have cycles, and
> use it to start things in the correct order (i have some code somewhere
> that does this but it's in erlang :o)
>
> andrew
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

http://xircles.codehaus.org/manage_email

« Return to Thread: Mule Agents 2.0 Configuration