avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Farr, Aaron" <Aaron.F...@am.sony.com>
Subject RE: [AMTAGS] Updating the spec
Date Tue, 22 Jul 2003 18:51:03 GMT


> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> 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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message