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 16:19:30 GMT
Darrell,

> * I pretty much agree with Danny and Serge that the Mailet API itself
>   shouldn't have any direct dependencies on the Avalon Framework

If you adopt the Avalon programming model, that would most likely be the
case.  The Mailet interfaces would be clean because the Avalon programming
model is based upon composition of fine grained interfaces on the
components.

But I strongly disagree with the rest of what you said, purely on the
grounds that you did not make it mandatory.  The argument is presented
below.  If you make your statements mandatory, then we're in agreement.

> * Any Mailet written solely against the Mailet API will function perfectly
in
>   James, the Reference implementation of a Mailet container.

> * This doesn't mean that a particular Mailet shouldn't be able to use
Avalon
>   Framework interfaces

Insufficient.  Mailets should be portable.  We can't simply wash our hands
of a functional area and say "it isn't Mailet behavior, so we just won't
deal with it."  A Mailet needs to use a service.  We need to provide a
common means to do so, or we effectively mandate platform-dependence.

> LogEnabled provides a clean, implementation neutral way of getting
> a Logger from the Mailet container, but some mailets may choose
> other ways.

A Mailet may CHOOSE another way, but that means it will be
platform-dependent.  Fine, but we must still support platform-independence.
It is one thing to say that I can roll my own, but quite another to say that
I MUST.  How do we ensure both platform independence and proper behavior if
everyone rolls their own?  The platform neutral stance is to EITHER have
logging in the Mailet API, or say that if a container wants to providing
logging to platform-independent mailets then it SHALL use LogEnabled.
Otherwise you have software anarchy.

> * I believe that James should provide support for a relevant subset of
Avalon
>   contracts, maybe just LogEnabled, or any others that seem very useful.

No.  Not a strong enough statement.  If JAMES does it, then it is James
specific.  We either provide a portable Mailet specification, or just bag
the whole independent API idea, and say that James IS the Mailet SDK.  Which
is NOT what we want to say.  It is not JAMES that does it, but Mailet
Containers do it, of which James is the reference implementation.

> * If a Mailet writer wants their *LogEnabled* Mailet to work in a
>   non-avalonized container, they would need to ensure that they
>   provide a default Logger themselves

Absolutely NO!  From where do they get this "default Logger", hmmm?  LogKit?
System.err.println?  Vendor specific API?  Log4J?  Do you see my point?
This is anarchy.

This relates to Danny's question: 'What do you mean by "platform-specific"',
which I believe I have just demonstrated.  If I have a non-avalonized
container, no standard logging, and a bunch of rolled-my-own-logging mailets
from various sources, I am a frustrated and annoyed administrator.  The
container should provide me with logging, or not, by some standard interface
(contract) with my component.

> these are just mailet implementations, and not part of the Mailet API
itself.

As a Mailet author, the API is what I know.  Unless the Mailet Specification
tells me what ELSE I can know to be PORTABLE, e.g., tells me that I use the
Avalon Frameworks, and that Mailet Containers will do the right things.

> I guess the main point is that we can have the Mailet API completely
> independent of Avalon-Framework, yet still *support* Avalon-Framework
> contracts in James, the Mailet Container. This keeps the Mailet API clean,

James is A Mailet Container.  You need to mandate that this as common
behavior for A Mailet Container, not just James.  Else, you are wrong.  It
punts.  It says that "oh, well we don't know how to do it, so here is one
way, but don't count on it; it isn't our problem."

Clean?  Here is clean:

   interface Mailet { public void service(Mail) throws Exception }

That provides the minimal behavior, but it is insufficient to allow me to
write real-world portable mailets.  The missing pieces need to be filled in
either by expanding the portable specification, or by writing vendor
specific mailets.  The Servlet API and the Avalon model expand the portable
specification differently.

The Servlet API specifies the entirety of the common interface, including
such things as logging and configuration.  Container authors need implement
just those interfaces, plus the semantics defined in the specification.

In the Avalon model, the API focuses on domain-specific behavior, and the
container specification places additional requirement upon the container.
Container authors would be told how containers interact with components,
inspect their interfaces, etc.  The container specification indicates how
the container provides configuration information to a component, independent
of the component domain.  The good news is that this core container behavior
is independent of the component types.  Servlet containers and Mailet
containers, today, have a lot of purpose-built code, but that would change
if both APIs were "Avalon-ized."  There would be more common code.  The
differences would be in the specifics of handling HTTP requests and Mail
requests.

This is why I asked Paul if he could provide a simple Avalon container, so
that we can all see whether or not it is reasonable to mandate that all
containers support this approach.  My feeling is that it could be the right
way to go.  The alternative is the Servlet API approach, but we already know
that there are issues there.  The wrong thing is to just punt, and mandate
platform-dependence by inaction.

	--- Noel


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


Mime
View raw message