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 17:00:36 GMT
> 1/ if everything was standardised where would the space for innovation be?

There is plenty of room for innovation.  Or do you believe that everyone
should start by writing the operating system (or chip design), and work up
from there?  ;-)  [No, I'm sure you don't.  I'm making a joke to make a

All that I am saying is that there needs to be a standard contract to common
services.  Logging has been demonstrated as a common service to which
components need access.

2/ if certain functionality will not affect the implementation or
portability why would anyone want to control it.

I am not talking about implementation.  I am talking about interface.  I
could not care less what the implementation is for any given container.  I
just want to know how my Mailet interacts with the container in such manner
as to receive the service desired and provided.

> > (a) Adopt the Avalon programming model,
> Non standard (by your own reckoning)

Agreed.  Unless we ADOPT it as the standard, with the understanding that we
will move to adopt JSR 111.

> >  or (c) accept that the functionality will be non-standard,
> > platform-specific.

> No, accept that the functionality can be application dependant. Not by the
> mailte container, but by the mailets themselves.

Same thing, different words.  Application dependent, non-portable, chaotic.
I will have 24 mailets and 6 different ways in which they implemented
logging.  We can do better.

> > Perhaps you are unfamilar with ServletContext.log()?  Logging is part
> > of the Servlet API.  It isn't always sufficient, which is why other
> > schemes have been developed, but it is present.

> Doh Thats *exactly* the model that I'm proposing for mailet. That we leave
> logging to *Other people* servlet proves that this approach doesn't break
> anything.

I believe that you're missing the point.  It is chaotic in the servlet world
because if I want anything better than ServletContext.log(), there is no
standard either for the servlet author or the admin.  The servlet model
doesn't point to something that works, it points to something that is being
actively worked on to be FIXED.

The Avalon Logging Framework provides a common interface that the author can
count on, and an Avalon container provides a mechanism that allows the admin
to associate the logging mechanism they want with the components.  This does
not stifle innovation or impose a logging implementation.  Not every
container has to provide the exact same admin interface, or logging
implementation.  It can innovate as much as it wants, but the container has
the opportunity to affect the admin's desires onto the components.  It
simply standardizes the contract for authors, and allows administrators to
use the logging mechanism of THEIR choice.

> So we leave mailet logging and other peripheral services to the developers
> of a Mailet framework, which can be based on avalon, provide armfulls of
> additional services and promote the rapid development and deployment of
> sophisticated Mailet applications.

What is the difference between "The Mailet API" and a Mailet Framework in
your mind?  Mailet authors need to a defined interface to key services.
>From where does that come?

If we adopt the Servlet model, it comes from the Mailet API.  If we adopt
the Avalon model, it comes from mandating that the Mailet Container has
responsibilities behind servicing just the Mailet API.

What I am saying is that the Mailet Specification consists of two parts: one
is the Mailet API, the other talks about necessary semantics provided by the
container.  This is the same as the Servlet spec, Java Beans spec, JSP spec,
etc.  The choices are to widen the API (Servlet approach), or widen the
semantic responsibilities of the container (Avalon approach).

I believe that the latter provides a more future-proof, cleaner, more
scalable, solution.  It does NOT tie components to any given implementation,
and actually better facilitates changing the interfaces over time.

	--- 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