james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joel Gluth <j...@ping.net>
Subject [LONGISH] the thorny problem of MailetConfig.getInitParameterNames()
Date Wed, 14 Feb 2001 23:26:28 GMT
Hi list.

In my travels today, I found myself alternately cursing the names of the
JAMES team, then taking it back on further reflection. Sorry. It
actually turns out to be minor, but I'm interested.

I've found myself writing a Mailet to use JAMES as a frontend to an
application server. I like it, and the oft-mentioned lack of docs hasn't
really been an issue. One of the core server components takes as its
constructor argument a java.util.Properties object (and I can hear you
guys snickering already, by the way, because you know what's coming).

After swearing at the JAMES MailetConfig interface for not doing
something sensible like extending java.util.Map, I shrugged and wrote a
subclass of Properties that could take a MailetConfig, iterate over its
parameters, and copy them. Apart from the fact that the JavaDoc claimed
that getInitParameterNames() returns a Collection (glad to see this is
fixed in 1.2.1, BTW), it compiled OK.

However, it didn't run OK. My AvalonRunner crashed during init with
vaguely threatening RuntimeExceptions. I soon tracked this down to my
little utility class, and to the getInitParameterNames() call. It throws
the RuntimeException, with the simple message, "Not yet implemented".

Leaving aside for the moment that this is a release candidate, and such
(undocumented!) behaviour is of questionable appropriateness to say the
least, I had a look to see if I could just write it myself. This is
where things got worrying. It turns out that MailetConfig is a wrapper
for org.apache.avalon.Configuration. The thing about Configuration is,
there is AFAICT *no way* to retrieve a list of keys at a particular
level of the tree (or at all, for that matter). You have to know what
the potential options are beforehand, and retrieve them explicitly.

So. org.apache.james.core.MailetConfigImpl is left with a contract it is
unable to fulfill, namely the MailetConfig interface. Since using Avalon
to do configuration is pretty deeply rooted in the design of JAMES,
there are two options: convince the (seemingly heavily Pattern-oriented)
Avalon team to change their interface, or to change MailetConfig.

The former is possibly not such a battle, since the main point of
avalon.Configuration is to be read-only. The latter is certainly less
so. But my question is, what's the plan?

Joel Gluth \\ Disintegration Engineer, Ping.Net     http://www.ping.net
                              Any technology distinguishable from magic 
                                            is insufficiently advanced.

View raw message