james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: [Mailet API] Logging Proposal
Date Tue, 11 Jun 2002 05:38:55 GMT
> > Either way, it must be possible to author a Mailet that implements
> > LogEnabled, and have it able to load within the container.
> That reads like you agree... seems to contradict previous comment of
> yours...?

Actually, I have not made any statement against Avalon Frameworks that I am
aware of; I have tried to present what I understand to be the points of
Danny's objections, and I thought I was clear when I was speaking in that

> certain requirements, e.g., the LogEnabled interface must be in classpath.
> Bzzt *no*.  Classpath is for beginners.

Relax.  Not literal.  Saying "classpath" is just shorthand to means that it
is available to resolve when loading a dependent class.  If you prefer to
say that it must be visible to the classloader, that's fine.

> Other Java platforms?  Please elaborate.

For example, whatever Java language e-mail server his company is working on,
even if it is not written using Avalon technologies.  Your point is that
Avalon Framework is pending as a javax package, and should be considered
standard for server services; no more "non-standard" than javax.mail or

> OK, I'll post the smallest possible insecure, non-classloader separated
> Mailet container to this mail-list.  It won't be till the weekend.  It
> will be explanation by example, given that the Framework website docs
> are the justificatin from the applicable pattern's advocates.

PERFECT.  :-D  I look forward to reading it.

> > Consider that the current mailet container is not compatible in that
> > so this would lead to an exercise in implementing that change.
> Err yup.  You worried about revolution over evolution?

No.  It seems to me that the programming pattern promoted by Avalon actually
does a nice job of controlling revolution vs evolution.  The ability to
support revolution without breaking may be the strongest argument in favor
of its patterns.

> There are tens of lurkers in this mail-list that would use things
> from the Avalon project but are less likely to now as they have been
> infected with an 'Avalon is bad' Meme.

I don't think I've heard anyone say that Avalon is bad, just that using it
is tying the code to a particular platform.

> For the record, the Avalon projects technologies are excellent,
> well designed and applicable to many server concepts.

That may be, but it seems that most people currently think of Avalon as a
platform, rather than as specification with a reference implementation.
Thus the objections to tying to a particular platform.

Discussions like this provide opportunities to illustrate the programming
technique(s) employed when using Avalon technologies, and to show why
although they may be new to many people, they provide a powerful approach to
interface composition, allow organic interface development, and are
platform-neutral.  You might also, from time to time, provide people with
links to the discussions of IoC and SoC in the context of Avalon.

> > You are arguing that org.apache.avalon.framework.* should be on the
list, and
> > represents platform-independent interfaces that are well-designed, ought
> > be, and in fact are being, adopted on multiple server platforms.
> I claim and advocate that.

Now you just need to convince people with voting rights.  ;-)

	--- Noel

To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>

View raw message