james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [Mailet API] Logging Proposal
Date Tue, 11 Jun 2002 15:01:35 GMT

Dave Morris wrote:
> A few ideas to add to the discussion ....
> What about other 'services' which the container could/should provide.
> Configuration being a case in point.
> The avalon framework provides a rich configuration toolkit.
> The current Mailet API restricts the configuration to name value pairs.
> If you are going to add (or link) the avalon framework logging components to the
> Mailet API, then why only add one part of the framework.
> Surely, there would be a case for also adding the configuration components, and
> possibly others as well.
> So, the question becomes do we link the Mailet API to the avalon framework
> components.
> Not just the logging components, but logging, configuration and possibly others.
> (I'm not suggesting that we should, just extending the scope of the question)
> If the aim is to make the Mailet API general purpose, similar to the Servlet
> API.
> Then it might be useful to look at some simple and complex Servlets as possible
> use cases.
> To write a simple request/response Servlet, all you need is the stripped down
> Servlet API.
> No logging, no configuration, just handle the request and response.
> One (theoretical) application would be a simple Servlet running on an embedded
> device in a domestic appliance.
> A web server in a fridge which responds to a HTTP request with an XML fragment
> containing the current temperature.
> No logging API required, because there isn't anywhere to log to.
> For a complex content management system, have a look at Cocoon.
> Cocoon is a whole framework on its own, providing a rich set of tools to the
> components inside it, including hooks to the Avalon framework configuration and
> logging components.
> If we look at the Mailet API in the same way.
> One (theoretical) application would be a simple Mailet running on an embedded
> device in a domestic appliance.
> Send an email to the fridge, and it replies with an email containing an XML
> fragment with the current temperature.
> No logging, as there is no where to log to.
> No configuration, everything apart from IP address is hard wired in silicon.
> On the other hand, for a full scale enterprise level messaging system, with JDBC
> repositories, LDAP user repositories, mailing lists, multiple user aliases etc.
> you need a rich toolkit including both configuration and logging components.
> Perhaps there are three projects in one.
> 1) The Mailet API (equivalent to Servlet).
> 2) The reference server implementation (equivalent to Tomcat).
> plus, people working to extend this to implement
> 3) An Enterprise scale mail management system (equivalent to Cocoon).
> To be honest, I missed this distinction when I started working on my own
> Mailets.
> I saw the 'E' in JamEs and immediately started thinking in terms of a full scale
> Enterprise system.
> It is only really since reading the ideas and thoughts in this discussion that
> the three distinct parts have become clearer.
> Following the Servlet/Mailet analogy.
> How about this :
> 1) The Mailet API is the absolute minimum required to process an email.
> 2) The current implementation of James as a container for the Mailet API, with
> the required protocol handlers and basic storage, e.g. file based MailRepository
> and SpoolRepository.
> 3) The Enterprise components (and here I would include things like the JDBC
> Repository etc.) could live inside an EnterpriseMailProcessor, which _is_a_
> Mailet.
> Much like Cocoon _is_a_ Servlet, but also acts as a container for XML
> Generators, Transformers and Processors etc. with its own configuration and
> logging services. The EnterpriseMailProcessor Mailet would provide access to the
> Avalon framework services such as logging and configuration required by a
> complex Enterprise scale message system.

The ideas here expressed are reasonable, and at a first read I thought 
I'd agree...

But using a "clean" system would mean not using Configuration, Logging, 
Avalon Context, etc... and leave them to a James uberMailet implementation.
This would make the API half-succesfull, because mailets written four 
James would not be able to run unmodified in other containers, since 
they use implementation specific things.

What you propose is conceptually interesting, but how would you write 
such an API?


Let me express another thought.

Logging is needed by *any* server app.
Configuration too.

This means that any server API could use Avalon interfaces.

I could have Mailet API, Portlet API, Cronlet API, etc... all using 
Avalon Framework stuff.
Should they *depend* on Avalon?
Three apis all depending on Avalon?

Avalon is orthogonal to server apps.

Like some of you said, I want the Mailets that run in an Avalon server 
to be treated as Avalon stuff.
This is not dependence, but *coexistence*.

I'm still not quite sure of the details, but I would take away from the 
core Mailet API *all* references to Avalon stuff.

Then *require* that the container abides to Avalon contracts.

This way the container needs to abide to the Avalon contracts (logging, 
configuration, etc), that are interfaces, but not have them in the API.

Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

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