Re: Mule Agents 2.0 Configuration

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