Mule Agents 2.0 Configuration

[Daniel Feist]

Hi,

I currently working on the schema and NameSpaceHander for the
management module...and I've come across some issues with agent
initialization order ...

As far as I can there are a number of different types of agent:
- NotificatonAgents
- - Log4jNotificationLoggerAgent
- - EndpointNotificationLoggerAgent
- - JMXNotificationAgent (Depends on existance of MBeanServer)

- JMXAgent (locates or creates MBeanServer )
- JMX dependent agents (Depend on existence of MBeanServer)
- - JMXNotificationAgent
- - WrapperAgent
- - Mx4jAgent
- - Jdmkgent
- - Log4JAgent

- Other agents unrelated to JMX
- - MuleAdminAgent
- - RMIRegistryAgent

A number of agents are JMX based agents and depend on the there being
a MBeanServer, which the JMXAgent locates or creates.  This means that
a number of agents need to be initialized *after* JMXAgent which is
causing me some issue....

Questions:
- Should this dependency be managed at configuration/initialization
time as it seems it was with 1.4 (but is currently causing issues with
2.0)?
- Should this dependency be resolved in Agent implementations?
- Or, should these different types of agents be recognized as such and
the xml schema  be defined in such a way that it is more intuitive to
configure and these dependencies be automatically resolved when
parsing by having the dependent agents as children of the JMXAgent?

Example with proposed configuration solution ..(might need to be
complemented with some code changes in the future)..

Mule 1.4
------------
<agents>
    <agent name="JmxAgent" className="org.mule.management.agents.JmxAgent"/>
    <agent name="Mx4jAgent" className="org.mule.management.agents.Mx4jAgent">
        <properties>
            <property name="jmxAdaptorUrl" value="http://localhost:9999"/>
        </properties>
    </agent>
    <agent name="Log4jAgent" className="org.mule.management.agents.Log4jAgent"/>

</agents>

Mule 2.0 (Current)
------------
<management:jmx-server name="simpleJmxServer">
<management:jmx-mx4j-adaptor name="jmx-mx4j"
jmxAdaptorUrl="http://127.0.0.1:8000" />
<management:jmx-log4j-agent name="Log4jAgent"/>
<management:log4j-notifications name=".."/>
<management:rmi-server name=".."/>
<management:jmx-notifications/>

Mule 2.0 (Proposed)
-----------------------------

<management:jmx-server serverName="simpleJmxServer"
createServer="false" locateServer="true">
    <management:jmx-mx4j-adaptor jmxAdaptorUrl="http://127.0.0.1:8000>
    <management:jmx-log4j-agent name="Log4jAgent"/>
    <management:jmx-notifications/>
</management:jmx-server>
<management:log4j-notifications name=".."/>
<management:rmi-server name=".."/>

thoughts?

Dan

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

    http://xircles.codehaus.org/manage_email

[Dirk Olmes]

On 8/16/07, Daniel Feist <dfeist@...> wrote:
> Hi,
>
> I currently working on the schema and NameSpaceHander for the
> management module...and I've come across some issues with agent
> initialization order ...
[...]
> Questions:
> - Should this dependency be managed at configuration/initialization
> time as it seems it was with 1.4 (but is currently causing issues with
> 2.0)?
> - Should this dependency be resolved in Agent implementations?

Definitely my farvourite from a user's point of view. Let the mule
server itself find the correct order for the agents.

-dirk

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

    http://xircles.codehaus.org/manage_email

[Andrew Perepelytsya]

Definitely my farvourite from a user's point of view. Let the mule
server itself find the correct order for the agents.

No, there was a bug specifically loooong time ago, when a declared agent order wasn't observed. Briefly, Mule must follow the user-declared order of agents, and agents can't know about each other. E.g. depending on the environment, an agent may or may not try to setup some servers (rmi registry), or use existing (created by a previous agent).

Moreover, agents may register child agents (see DefaultJmxSupportAgent), and further manipulate the list, like removing itself. There's some a bit crazy agent collection manipulations to ensure the declared order is not broken by such host agents.

As for the config, make them top-level independent nodes and let user specify the order. E.g. mx4j can't be a child/depend on jmx, as Mule could be running e.g. embedded and use server's resources.

Andrew

[Daniel Feist]

> Mule must follow the user-declared order of agents

I wonder how we would get spring to do this.... doesn't seem to by default

> and agents can't know about each other. E.g. depending on the
> environment, an agent may or may not try to setup some servers (rmi
> registry), or use existing (created by a previous agent).

Makes sense.

> As for the config, make them top-level independent nodes and let user specify the
> order. E.g. mx4j can't be a child/depend on jmx, as Mule could be running e.g.
> embedded and use server's resources.

The JMXAgent actually locates (or creates if not embedded) the jmx
server instance so even in the case where mule is running embedded it
would still be valid to configure mx4j/log4j agents as child config
elements of jmx-server (JMXAgent).  This would also ensure that
mx4j/log4j agents can't be configured without jmx-server if mule is
not embedded.

If we have everything as top-level agents there are a couple of things
we need to take into consideration:

1) Handle errors and inform user when jmx dependent agents are
configured and there is no jmx instance available.
2) If jmx-server is configured along with jmx dependent agents at the
same level, we need to deal with the initialization order issues.  I'm
not sure how this was handled in 1.4, but in 2.0 it's all delegated to
spring (initialization oder or "depends-on" attribute maybe).

Only allowing the user to configure jmx dependent agents if jmx-server
is declared (remember jmx agents locates first, then creates) I
believe would be more intuitive  and less error-prone for users and
also easier for us to manage jmx agents dependencies.

(So .... I'm still not convinced :-) )

Dan

On 8/17/07, Andrew Perepelytsya <aperepel@...> wrote:

>
>
> >
> >
> > Definitely my farvourite from a user's point of view. Let the mule
> > server itself find the correct order for the agents.
> >
> >
>
> No, there was a bug specifically loooong time ago, when a declared agent
> order wasn't observed. Briefly, Mule must follow the user-declared order of
> agents, and agents can't know about each other. E.g. depending on the
> environment, an agent may or may not try to setup some servers (rmi
> registry), or use existing (created by a previous agent).
>
> Moreover, agents may register child agents (see DefaultJmxSupportAgent), and
> further manipulate the list, like removing itself. There's some a bit crazy
> agent collection manipulations to ensure the declared order is not broken by
> such host agents.
>
> As for the config, make them top-level independent nodes and let user
> specify the order. E.g. mx4j can't be a child/depend on jmx, as Mule could
> be running e.g. embedded and use server's resources.
>
>  Andrew
>

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

    http://xircles.codehaus.org/manage_email

[Andrew Perepelytsya]

1) Handle errors and inform user when jmx dependent agents are
configured and there is no jmx instance available.

Current errors do provide that info already, did you have something in mind?

2) If jmx-server is configured along with jmx dependent agents at the
same level, we need to deal with the initialization order issues.  I'm
not sure how this was handled in 1.4, but in 2.0 it's all delegated to
spring (initialization oder or "depends-on" attribute maybe).

In 1.4 it was following the XML-declared order. Depends-on could be the way to go, but see if you can derive the names of the beans to depend on. Maybe getting the beans of JmxAgent type from the registry? Otherwise a user has to specify those attributes (that is, if Spring does not preserve the order).

Only allowing the user to configure jmx dependent agents if jmx-server
is declared (remember jmx agents locates first, then creates) I
believe would be more intuitive  and less error-prone for users and
also easier for us to manage jmx agents dependencies.

The problem here is if any future agent depends on JMX, the schema has to be updated to support it. Not the case if they are top-level.

Andrew

[Daniel Feist]

> > 1) Handle errors and inform user when jmx dependent agents are
> > configured and there is no jmx instance available.
>
> Current errors do provide that info already, did you have something in mind?

No, what's in 1.4 will work.

>
> > 2) If jmx-server is configured along with jmx dependent agents at the
> > same level, we need to deal with the initialization order issues.  I'm
> > not sure how this was handled in 1.4, but in 2.0 it's all delegated to
> > spring (initialization oder or "depends-on" attribute maybe).
>
> In 1.4 it was following the XML-declared order. Depends-on could be the way
> to go, but see if you can derive the names of the beans to depend on. Maybe
> getting the beans of JmxAgent type from the registry? Otherwise a user has
> to specify those attributes (that is, if Spring does not preserve the
> order).

I would have to look into this, avoiding all this and at the same time
making things more intuitive is my preferred route though.

> > Only allowing the user to configure jmx dependent agents if jmx-server
> > is declared (remember jmx agents locates first, then creates) I
> > believe would be more intuitive  and less error-prone for users and
> > also easier for us to manage jmx agents dependencies.
>
> The problem here is if any future agent depends on JMX, the schema has to be
> updated to support it.

Not really.  Just add a <management:jmx-custom-agent/> element or
similar, the same we do everywhere else to provide extensibility..

> Not the case if they are top-level.

The same applies top-level there is no difference (at least with 2.0
style configurations).  The schema would have jmx-server,
log4j-notification, publish-notification, chainsaw-notifications
agents defined in the schema as elements and a
<management:custom-agent class=""/> for additional or custom agents.

( There is a possibility that Jmx dependent agents implement an
additional interface, and  have the MBeanServer set automatically
rather than each of them having to look it up, but this is debatable
and separate to the choice of configuration mechanism.)

Maybe I should get together the schema for what I suggest to better
see what I mean?

Also be interesting to know what the other 2.0 guys think...

Dan

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

    http://xircles.codehaus.org/manage_email

[andrew cooke-2]

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

[Daniel Feist]

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

[andrew cooke]

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

[Daniel Feist]

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

[andrew cooke-2]

this turned out to be easier and more powerful than i expected.  not sure
how i had managed to convince myself earlier it wouldn't work this well.

see the files committed as change 8016.

this may mean i can separate out the xml module again.  will think it over
for a while first though - i may have missed something.  can you see any
problems?

andrew

ps main files are:
branches/mule-2.x/tests/functional/src/test/resources/META-INF/nest-example-base.xsd
branches/mule-2.x/tests/functional/src/test/resources/META-INF/nest-example-extension.xsd
branches/mule-2.x/tests/functional/src/test/resources/nest-example.xml

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

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

    http://xircles.codehaus.org/manage_email