Re: Mule Agents 2.0 Configuration

> If you can that would be great... I guess it's something that comes up
> all over the place really.. not sure how the best way to approach it
> is though...
>
> If there is a solution it would be good to have a HOW-TO up on the
> wiki of how to do it, and if you can't a list of some alternatives.  I
> know this is one of the trickiest areas of the schema world (at least
> for me): using polymorphism but without the xsi:type attribute and at
> the same time having to deal with conflicting namesapces etc.
>
> thanks,
>
> Dan
>
> On 8/22/07, andrew cooke <andrew@...> wrote:
>>
>>
>> i think there is a way to extend option 2.  will try a quick example and
>> get back to you.
>>
>> andrew
>>
>>
>> > 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
>> >
>> >
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>