james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Federico Barbieri <scoo...@betaversion.org>
Subject Re: [LONGISH] the thorny problem of MailetConfig.getInitParameterNames()
Date Thu, 15 Feb 2001 00:54:33 GMT

Joel Gluth wrote:
> Federico Barbieri wrote:
> > Yes I am pattern oriented and proud to be! :-)
> Absolutely. Didn't mean that to sound like a bad thing :)
> > The idea about Configuration is "you know what you're doing" so if you
> > need a value you should know the name of the element containing that
> > value. Makes sense doen't it?
> Yes... if all you're doing is initalizing an application from the ground
> up. When you want to unify configuration for disparate components, some
> of whom aren't written to deal with Avalon, interoperability becomes
> something of an issue.
> > But don't worry there is an alternative.
> <SNIP content="alternative"/>
> Aha. Thanks. I'll modify my copy of JAMES accordingly. Although, it
> doesn't really solve MailetConfig's basic problem.
> Actually, this <param name="something" value="somethingelse"/> is
> better, XML-wise, since you can actually describe the format of the
> config.xml file with a DTD that way. If, of course, proper XML is a
> concern :p

well the idea of a configuration validator could be nice... 

> Even if it's not, enforcing it does allow JAMES to have a working
> MailetConfigImpl.

and nicely decouple Mailet from Configuration 

> I know this is strictly an Avalon question now, but is there a reason
> you're allowed to specify config parameters that way, other than the
> fact that it's a neat DOM hack?

?... miss the question... 
Configuration are supposed to be very generic so that you are allow to
do whatever you want. The <param attributes/> is already used in James
for the mailet processor:
<mailet match="" class=""> 

We had the same problem... discovery of a piece of conf at run time. in
these situation the pattern <conftype attributes/> is elegant and fit
the role. In other situation you don't want discovery at run time... so
the absence of getChildren() force you to explicitely define a contract
to allow or denay discovery.


View raw message