james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kenny Smith <ke...@journalscape.com>
Subject Re: Avalon dependance in mailets
Date Tue, 07 Jan 2003 16:11:42 GMT
Hi Jason,

I don't know enough technically about about java.util.logging and log4j 
to really give a blow by blow of which is better. I've used both, they 
both worked fine, both seemed easy to use. I think I like log4j better, 
but that's not really a good enough reason for choosing one over the 
other. I would probably lean towards log4j simply because it's another 
apache product. Any support we can give is good support. :)

Kenny

Jason Webb wrote:
> Logging is an interesting one.
> As far as mailet developers are concerned I think logging should be
> provided (by the container?).  Everyone needs to log something at some
> time, but DB access is not always required. 
> My only real problem with the current system is it's lack of fine
> control over the logging. If James 3.0 will go to JDK 1.4 we could use
> the builtin logging there. I'm not going to get into a logging system
> war here either :)
> 
> 
> -- Jason
> 
> 
> 
>>-----Original Message-----
>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org] 
>>Sent: 07 January 2003 15:29
>>To: James Developers List
>>Subject: Re: Avalon dependance in mailets
>>
>>
>>
>>Danny Angus wrote:
>>
>>> Nicola Ken Barozzi wrote:
>>>
>>>
>>>>This makes me think...
>>>
>>>Its a thought provoking topic!
>>>I wrote another reply to this mail, but by the end of it 
>>
>>I'd changed 
>>
>>>my mind, here's version 2 :-)
>>>
>>>
>>>>Essentially the Mailet API won't thus provide portability 
>>
>>of mailets 
>>
>>>>between servers, just a common API, right?
>>>
>>>Actually the work I've been doing is supposed to this so ..
>>>
>>>
>>>>Meaning that I cannot simply get a mailet written from James and 
>>>>simply pop it into XMailServer and hope it to run, right?
>>>
>>>That is not correct *unless* your mailet uses Avalon via 
>>
>>James to get 
>>
>>>database connections, in which case your mailet will not be 
>>
>>portable. 
>>
>>>In all other cases it will be.
>>
>>Errr, what about logging? I mean that every service that a 
>>mailet uses 
>>that are not part of the mailet API can potentially be a portability 
>>breaker.
>>
>>Not that I see this as a bad thing, in fact I start to understand the 
>>reasoning behind a simple API.
>>
>>
>>>>This could be a strength and a weekness.
>>>>Strength because it's easier to learn, implement and to 
>>
>>keep focused 
>>
>>>>in development . Weekness because it's not made to make completely 
>>>>portable mailets.
>>>>
>>>>So what about doing a Mailet spec as defined above and define an 
>>>>additional Avalon Mailet profile, that James could use, to define 
>>>>other aspects like logging, get db connections, etc?
>>>
>>>We discussed this a while ago, and I argued that we should keep the 
>>>API as clean of dependancies as we can. The db issue is really only 
>>>relevant for the portability of James mailets, it is 
>>
>>possible to write 
>>
>>>portable db access mailets by managing connections independantly of 
>>>James.
>>
>>Yup.
>>
>>
>>>If what you are suggesting is that we should build a portable 100% 
>>>Mailet API compliant framework which would itself manage these 
>>>services for any mailets written to use it then I agree.
>>
>>:-)
>>
>>Of course, I see this Mailet API compliant framework as
>>
>>   Mailet API + Avalon API
>>
>>IMHO if we say that James mailets are just Avalon Components that use 
>>Mailet API, then there is no need to define anything else.
>>
>>
>>>It would have to be compact, I have a vision of the Mailet 
>>
>>API being 
>>
>>>used in client software for mail filtering and similar tasks.
>>
>>Yes.
>>
>>
>>>It would also have to be deployable either as a runtime 
>>
>>dependance or 
>>
>>>as a simple wrapper for single mailets.
>>
>>Cool.
>>
>>
>>>One further option might be to include processors in the API 
>>>specification and create a distributable processor which 
>>
>>could offer 
>>
>>>services to the mailets it contained.
>>>
>>>At the end of the day, though, if we assume that not all mailet 
>>>containers will be capable of providing JDBC connectivity for some 
>>>reason then mailets using JDBC will have their portability 
>>
>>restricted 
>>
>>>no matter what we do.
>>
>>Yes, that's what I came to think too.
>>
>>-- 
>>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>
>>
>>
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>
> 
> 


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