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: Finer Logging Control for Mailets/Matchers
Date Mon, 10 Jun 2002 12:34:39 GMT

Danny Angus wrote:
>>If it's enough, then why do *all* frameworks based on the servlet Spec
>>simply not use it?
> Surely its because frameworks are there to provide easier & faster routes to
> market, encapsulating best-practice and complying with patterns that have
> been tested and proven worthwhile in terms of product design.
> An API is not a framework, it is less than that, it is a set of rules
> allowing the creation and re-use of third party code which guarantees that
> if all contributors comply with the API their contributions will
> interoperate in a defined way. including frameworks.
> Frameworks compete to provide developers with additional resources,
> services, and patterns which allow developers to build complete
> applications, an API should (IMHO) only specify the least rules necessary to
> accomplish the fundamental requirements (in this case processing email
> messages)
> It is not a fundamental requirement of a message processing, or
> request/response API that it provide extensive logging, but any framework
> providing a feature rich layer for developers on top of the API (or
> underlying its implementation) would be expected to fill this gap.

Ok, which means IIUC that the mailet api should not contain logging?
I agree.

>>Also of the java.lang? Of java.util?
>>You must have a dependency; the important thing is that that dependency is
>>the basic stable common block on which you build.
> No, of course not, and I'll assume that you missed my original mail about
> dependancies and aren't just taking the piss.
> I originally said that any dependancies outside of java.* and javax.mail.*
> should be avoided if possible.
> The reason is that (again MHO) we want to encourage the use of Mailet API as
> widely as is possible, and if any other packages than org.apache.mailet,
> java and javax.mail are required it may work against us.
> If there is a real need for other dependancies then fine, mailet will depend
> on them. I just don't believe that logging is a case in point here.
> Obviously logging is bound to be required by almost every user of Mailet, I
> just don't subscribe to the idea that it is the role of the Mailet API to
> provide it.

Then we agree :-)

>>Java API is one.
>>For Apache Java servers, it's Avalon Framework.
> Thats exacly the point, the Mailet API isn't an Apache Java Server, it
> provides an API which James implements, but I'd like to see other products
> implement it as well.
> (and in fact my new employers are already doing just that)


>>This is what has been done in the Cocoon context object and is't
>>We got burt on this, since it's a big fat HOLE in your framework-api.
>>An Api must abstract, not make you work with underlying implementations.
>>For example, the xml DOM API left open the use of implementation-dictated
>>methods for creating parsers and parsing.
>>What we got were programs that needed a specific parser.
>>Jaxp solved this, but it was a real PITA to convert all legacy code.
> But we're not talking about that, we're saying that generating logs should
> be implementation dependant, decided by the end user.
> What is the benefit of denying them that choice?
> And where does that choice create any greater problem than of an installed
> Mailet application requiring some third party .jar files placed in a lib
> directory.
> We cannot legislate for every possible dependancy that applications may
> have, why do we have to legislate for logging? does it not make more sense
> to draw our line in the sand around those features directly related to mail
> processing, and leave other issues for other experts?

Of course, you are correct.

I thought I read about a simple log(String) method...
I agree that the Mailet API should not legislate on logging, and 
delegate (in our case) to the Avalon Apis, that are made just to do this 

>>I also don't see why making the Mailet API depend on the Avalon Framework
>>API is a bad idea.
>>In fact, I *strongly* think that all Apache Java server APIs should depend
>>on and use Avalon Framework.
> Quite possibly, I agree with this to a certain extent, I don't think it
> explains why we have to provide logging services in the Mailet API though.

Yes yes yes +1+1+1

>>Avalon framework is made to keep all the lifecycle methods of
>>server Apis in
>>a single package.
>>If you don't use them, if you don't want dependency from them,
>>well, Avalon
>>framework could simply die.
> We may well depend upon avalon life-cycle interfaces, but not without
> considering why. It is not enough (sorry guys) that it is a jakarta project.
> Any dependacy has to offer real added value, javax.mail does this (for
> reasons Serge keeps reminding everyone) avalon.framework proably does too, I
> accept that.


>>I see you haven't replied to my other points, so I assume they
>>were correct.
> What other points..?
> 	"Yeah, cut 'n paste!
> 	The real code reuse!
> 	:-P"

hehehe you got me on this one ;-)

>>Any solid technical reason for not using Avalon framework API?
>>I yet have to see one.
> None, as I have just pointed out.

Ok, so let me push this discussion a bit further.
The Mailet API is basically the Mailet interface(s) and the Context.
Most of the problems with defining a server api come from the definition 
of the container in fact, with regards to common services: logging, 
getting other services, Context, etc.

These classes are more geared towards talking to a *generic* server app 
container rather that mail api, and could be directly handled by AF:

MailetConfig: Configuration-Configurable
MailContext: Context-Contextualizable

Also the Exception could extend the Cascading Exception.

In this way, the core mailet api is just about mail, and the generic 
container stuff is handled by Avalon Framework Api.

Every spec about server apps would use the same Avalon Api for common 
stuff, and result easy and consistend for the developers.

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