> -----Original Message-----
> From: Stephen McConnell [mailto:[EMAIL PROTECTED]
>
> And now for the contradiction - I don't think we should do this. As I
> described to Vinay - I think we should hold off until we get more
> experience with the basic meta-info model.
>
> Thoughts?
I agree about holding off for right now.
I also want to point out the problem of embedding _too_ much information in
the meta-info, particularly any information which you or an end user might
want to configure at deployment. I've run into this with a set of
extensions which provide JMS to avalon components. Currently I have two
ways of expressing the JMS subscription information:
1. Meta-Info approach:
<stage>
<stage key="urn:mds:jms-listener ">
<attributes>
<attribute key="urn:mds:connection" value="jmsconnection"/>
<attribute key="urn:mds:subject" value="jmstopic"/>
</attributes>
</stage>
</stage>
2. Configuration approach:
<configuration>
...
<subscription connection="jmsconnection" subject="jmstopic"/>
...
</configuration>
Because DeploymentStageExtensions can access the Appliance (and consequently
the component's configuration), either approach works. The thing is, if I
only use the meta-info approach, then if I need to change the JMS
destination or connection name, then I need to unjar the component, edit the
meta-info file and rejar the thing. Otherwise, I could just give the jar'ed
blocks and components to my users and they can override the configuration
easily (this is a great feature in merlin).
So unless there's an easy way to edit or override meta-info (perhaps JMX?)
then I'm currently of the opinion that some of it should be left in
configuration files. If anyone has some better ideas on this, I'd love to
hear them.
jaaron
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
