james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Knystautas <ser...@lokitech.com>
Subject Re: [Mailet API] Logging Proposal
Date Wed, 12 Jun 2002 05:19:28 GMT
Noel J. Bergman wrote:
> I was not criticizing.  I was simply pointing out that this is how the
> current Mailet API supported what you had asked me, namely what to do about
> mailets that want something, e.g., a repository, that is not supported on a
> specific container.  I then further noted that (since this mechanism uses
> Avalon Frameworks), that Best Practices with the Avalon Frameworks
> programming model would work a bit differently, and I gave an example.

Ok, then I'm not sure why you're discussing changing the mailet API. 
What need is not being met?  Is it just complete portability?  What 
functionality do you think should get incorporated into the mailet API then?

>>Ahem... JSR 47 HAS produced a common API for logging.  It's called
>>java.util.logging.
> 
> 
> True ... but it is neither in the Servlet API nor exposed to Mailets, which
> was sort of the context of the discourse.

Sorry, but from my view this discourse went like this... you were 
advocating adding logging to the mailet API.  I said there are too many 
ways and pointed to the fact there are many implementations.  You said 
there are so many implementations only because there was no common API. 
  I'm pointing out how their was a JSR and so there is a common API. 
So, tracing it back, I think there are multiple implementations not 
because of a lack of a common API... it's because there are different 
needs.  There are different needs, so we shouldn't add this into the 
mailet API.

We provide log(), which is basically an equivalent of System.err.  If a 
developer wants serious logging capabilities, he/she can either use what 
comes with the JDK, use Avalon's logger, or whatever third party library 
they have around.  I don't think adding some other jar is a violation of 
the mailet portability nor using JDK 1.4 logging as a violation of it.

Sorry, I don't mean to sound like a broken record, but I just wanted to 
clarify the context of the discourse as I remembered it.

> Wait, I have not said that James + Avalon Frameworks doesn't do something!
> I said that a Mailet API *WITHOUT* Avalon Frameworks is anemic, and that if
> we don't specify how to fill the gaps (using the Avalon Frameworks is one
> way), then those gaps will be filled with vendor-specific solutions, and
> that is the thing that is unacceptable.

Again, I'd like to hear what you want to add to the mailet API.  Again, 
from my perspective most of the conversation talks about Java and 
programming language concepts instead of concrete concepts to change in 
the mailet API.

>>You've got a mailet API... you've got composable, etc-able
>>interfaces that you can get as servlet context attributes.
>>You can log, you can store, and whatever else that the
>>Avalon-framework is providing.
> 
> 
> Exactly!  And I want to be able to RELY upon that regardless of whose
> container implementation I'm using.  That's it exactly!

I guess I would only suggest you take a look at the "competing" 
solutions to mailets right now.  They are very processing-centric, 
basically they are to SMTP what CGI was to HTTP.  Few of them have any 
concept of user repositories, message repositories, application logging, 
or other enterprise mail server features.  None of them really grasp the 
power of Java, and that's hopefully part of why mailets are the right 
answer.

But I'm not sure if we need to create new API (and especially need to 
touch the mailet API) to support these concepts.  Maybe we can map out 
what we need in terms of "Enterprise Mail Server Services" and find 
existing Java APIs that fill these needs.

For user repository API... well, JNDI would work, right?  The current 
user repositories could be exposed as JNDI resources, and the 
non-portable mailets could be changed to work against a JNDI resource. 
Then message repository API we build as implementations of JavaMail's 
javax.mail.Folder (actually doesn't look as irrational as you might 
think).  Logging I think is pretty easy... JDK 1.4 is readily available, 
or heck we're on Avalon-framework so just use that API.  Database 
access... well, I've really really wanted to expose the db pooling as a 
javax.sql.DataSource as that would just make a ton of sense and make the 
mailet more portable.

I think the more we rely on other existing Java API, the easier it will 
be for mailet developers to get up to speed, and ultimately the more 
portable mailets will be.

> 	--- Noel [off to get some sleep before ENG v NGA in a few hours]


Good luck!
-- 
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/


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