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 Wed, 12 Jun 2002 06:18:48 GMT

Serge Knystautas wrote:
> Noel J. Bergman wrote:
>>> 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.

The main point is that the JSR 47 is not geared towards server applications.
Static accessors for server apps is a potential security hazard.

Overmore, we need to supply logging to jdk 1.3.

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

Leave logging out of the API but put Avalon Framework savy container as 
a requirement.

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

Ok, so I will write this mailet:

public class MyMailet implements Mailet,

      void enableLogging( Logger logger );

      void contextualize( Context context )
           throws ContextException;

       void parameterize( Parameters parameters )
           throws ParameterException;


and my container will honor the Avalon contracts.

You will write

public class MyMailet implements Mailet
      (in any method:)
         String param1 = Configuration.getParam("root.address");

Do these classes look like the same API?
By doing this, you are *sure* that the Mailet classes won't be portable.
Or, if they are, you loose any sensible functionality.

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

interface MailetContext
      (as now +)

      void log(String message);              // deprecated
      void log(String message, Throwable t); // deprecated

interface Mailet
    void service(Mail mail) ;

But *REQUIRE* to abide to Avalon contracts (example):

public class MyMailet
    implements Mailet
      void service(Mail mail){...}

      void init (){...}

      void dispose (){...}

      void enableLogging( Logger logger ){...}

      void service( ServiceManager manager )
         throws ServiceException{...}

       void parameterize( Parameters parameters )
           throws ParameterException{...}

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

I suggest you to look at Avalon.

Competing solutions are never an answer, but a problem, or you would be 
using those.

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

Avalon Api is very simple.
I bet that the above mailet is more portable and easier to understand
than any other possible implementation-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