james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Angus" <da...@apache.org>
Subject RE: Finer Logging Control for Mailets/Matchers
Date Mon, 10 Jun 2002 10:52:48 GMT

> 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

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.

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

> 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
> *B*a*a*a*d.
> 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

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?

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

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

> Any solid technical reason for not using Avalon framework API?
> I yet have to see one.

None, as I have just pointed out.

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