Re: Mule Agents 2.0 Configuration

> 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
>
>