You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Danny Angus <da...@apache.org> on 2003/01/06 13:48:17 UTC
Avalon dependance in mailets
Hi,
I've started commiting changes I've made which remove avalon dependance from
the standard mailets.
Starting with repository access, read the commmit messages to see what I've
done, below is a log snippet which demonstrates that repository access is
still functioning after my changes..
I've also got a junit test suite which sends an outgoing mail and a
deliberate undeliverable local mail, I'll commit this too, after lunch, as
it tests repository access by mailets.
06/01/03 12:16:11 INFO mailstore: JamesMailStore init...
06/01/03 12:16:11 INFO mailstore: Registering Repository instance of class
org.apache.james.mailrepository.AvalonMailRepository to handle file protocol
requests for repositories of type MAIL
06/01/03 12:16:11 INFO mailstore: Registering Repository instance of class
org.apache.james.mailrepository.AvalonSpoolRepository to handle file
protocol requests for repositories of type SPOOL
06/01/03 12:16:11 INFO mailstore: Registering Repository instance of class
org.apache.james.mailrepository.JDBCMailRepository to handle db protocol
requests for repositories of type MAIL
06/01/03 12:16:11 INFO mailstore: Registering Repository instance of class
org.apache.james.mailrepository.JDBCSpoolRepository to handle db protocol
requests for repositories of type SPOOL
06/01/03 12:16:11 INFO mailstore: Registering Repository instance of class
org.apache.james.mailrepository.JDBCMailRepository to handle dbfile protocol
requests for repositories of type MAIL
06/01/03 12:16:11 INFO mailstore: Registering Repository instance of class
org.apache.james.mailrepository.JDBCSpoolRepository to handle dbfile
protocol requests for repositories of type SPOOL
06/01/03 12:16:11 INFO mailstore: added repository:
file://var/mail/spool/SPOOL->org.apache.james.mailrepository.AvalonSpoolRepo
sitory
06/01/03 12:16:11 INFO mailstore: SpoolRepository inboundSpool opened:
31598780
06/01/03 12:16:11 INFO mailstore: James MailStore ...init
06/01/03 12:16:11 INFO mailstore: added repository:
file://var/mail/inboxes/MAIL->org.apache.james.mailrepository.AvalonMailRepo
sitory
06/01/03 12:16:11 INFO mailstore: added repository:
file://var/mail/error/MAIL->org.apache.james.mailrepository.AvalonMailReposi
tory
06/01/03 12:16:11 INFO mailstore: added repository:
file://var/mail/outgoing/SPOOL->org.apache.james.mailrepository.AvalonSpoolR
epository
06/01/03 12:16:11 INFO mailstore: added repository:
file://var/mail/spam/MAIL->org.apache.james.mailrepository.AvalonMailReposit
ory
06/01/03 12:17:31 INFO mailstore: JamesMailStore init...
06/01/03 12:17:31 INFO mailstore: Registering Repository instance of class
org.apache.james.mailrepository.AvalonMailRepository to handle file protocol
requests for repositories of type MAIL
06/01/03 12:17:31 INFO mailstore: Registering Repository instance of class
org.apache.james.mailrepository.AvalonSpoolRepository to handle file
protocol requests for repositories of type SPOOL
06/01/03 12:17:31 INFO mailstore: Registering Repository instance of class
org.apache.james.mailrepository.JDBCMailRepository to handle db protocol
requests for repositories of type MAIL
06/01/03 12:17:31 INFO mailstore: Registering Repository instance of class
org.apache.james.mailrepository.JDBCSpoolRepository to handle db protocol
requests for repositories of type SPOOL
06/01/03 12:17:31 INFO mailstore: Registering Repository instance of class
org.apache.james.mailrepository.JDBCMailRepository to handle dbfile protocol
requests for repositories of type MAIL
06/01/03 12:17:31 INFO mailstore: Registering Repository instance of class
org.apache.james.mailrepository.JDBCSpoolRepository to handle dbfile
protocol requests for repositories of type SPOOL
06/01/03 12:17:31 INFO mailstore: added repository:
file://var/mail/spool/SPOOL->org.apache.james.mailrepository.AvalonSpoolRepo
sitory
06/01/03 12:17:31 INFO mailstore: SpoolRepository inboundSpool opened:
20415955
06/01/03 12:17:31 INFO mailstore: James MailStore ...init
06/01/03 12:17:31 INFO mailstore: added repository:
file://var/mail/inboxes/MAIL->org.apache.james.mailrepository.AvalonMailRepo
sitory
06/01/03 12:17:32 INFO mailstore: added repository:
file://var/mail/error/MAIL->org.apache.james.mailrepository.AvalonMailReposi
tory
06/01/03 12:17:32 INFO mailstore: added repository:
file://var/mail/outgoing/SPOOL->org.apache.james.mailrepository.AvalonSpoolR
epository
06/01/03 12:17:32 INFO mailstore: added repository:
file://var/mail/spam/MAIL->org.apache.james.mailrepository.AvalonMailReposit
ory
06/01/03 12:19:57 INFO mailstore: added repository:
file://var/mail/inboxes/test/MAIL->org.apache.james.mailrepository.AvalonMai
lRepository
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon dependance in mailets
Posted by Matthew Bishop <ma...@thebishops.org>.
>> Hi again,
>>
>> The next thing I'm stuck on is database connections.
>> Now currently there are a squad of mailets using avalon to get database
>> connections, however we want to remove avalon dependancies from mailets,
>> so...
>>
>> do we either make db connections available through the MailetAPI
>> or do we force mailets to make other arrangements.
>
> My vote is to expose db connections via javax.sql.DataSource, and lookup
> this object via JNDI.
I agree with Serge on this as it is a defacto standard pattern nowadays for
finding and utilizing databases. I don't know if James has a mini-JNDI
service provider or not, but there must be a few floating around, I know
tomcat has a small one that could probably be used.
I know I don't like the DataMailet approach; doesn't really help anyone as
the user is going to set up their database anyways, they might as well do
what they normally do in app deployment, which is declare their JNDI data
sources. Mailets probably aren't going to be agents that float around to
other servers, they will be explicitly deployed, just like a webapp.
Matt Bishop
The conventional view serves to protect us from the painful job of thinking.
--John Kenneth Galbraith
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon dependance in mailets
Posted by Serge Knystautas <se...@lokitech.com>.
----- Original Message -----
From: "Danny Angus" <da...@apache.org>
> Hi again,
>
> The next thing I'm stuck on is database connections.
> Now currently there are a squad of mailets using avalon to get database
> connections, however we want to remove avalon dependancies from mailets,
> so...
>
> do we either make db connections available through the MailetAPI
> or do we force mailets to make other arrangements.
My vote is to expose db connections via javax.sql.DataSource, and lookup
this object via JNDI.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon dependance in mailets
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jason Webb wrote:
> I think we should stick with what we've got (log4j). They should in
> theory be pluggable, but this is Avalon's problem, not James.
This is not a problem, they *are* pluggable in Avalon.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon dependance in mailets
Posted by Jason Webb <jw...@inovem.com>.
I think we should stick with what we've got (log4j). They should in
theory be pluggable, but this is Avalon's problem, not James.
-- Jason
> -----Original Message-----
> From: Kenny Smith [mailto:kenny@journalscape.com]
> Sent: 07 January 2003 16:12
> To: James Developers List
> Cc: nicolaken@apache.org
> Subject: Re: Avalon dependance in mailets
>
>
> 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
> >
> >
> >
<snip'd>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon dependance in mailets
Posted by Kenny Smith <ke...@journalscape.com>.
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: <ma...@jakarta.apache.org>
>>
>>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon dependance in mailets
Posted by Danny Angus <da...@apache.org>.
I think that the commons logging faction (Noel) have carried the day on this
one, its pretty likely to be included.
> -----Original Message-----
> From: Jason Webb [mailto:jw@inovem.com]
> Sent: 07 January 2003 15:52
> To: 'James Developers List'; nicolaken@apache.org
> Subject: RE: Avalon dependance in mailets
>
>
> 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: <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon dependance in mailets
Posted by Jason Webb <jw...@inovem.com>.
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: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon dependance in mailets
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon dependance in mailets
Posted by Danny Angus <da...@apache.org>.
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.
> 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.
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.
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.
It would also have to be deployable either as a runtime dependance or as a
simple wrapper for single mailets.
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.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon dependance in mailets
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Serge Knystautas wrote:
> ----- Original Message -----
> From: "Serge Sozonoff" <se...@globalbeach.com>
>
>
>>>From a mailet developers point of view, I would much rather have the DB
>>stuff exposed through the Mailet API.
>>If you really want to go your own way or need something not provided by
>
> the
>
>>API you still have the freedom to do so.
>
>
> For the same reason I don't think mailet API needs to specify logging, I
> don't think we need to expose DB stuff through it. There are other standard
> approaches to doing this (that while certainly would get used by mailets,
> don't need an API).
>
> I think it would be good to flesh out the mailet specification (instead of
> relying on an API to do everything), that describes how mailets might log,
> get db connections, etc... (and explain the mailet lifecycle, whatever
> else...)
This makes me think...
Essentially the Mailet API won't thus provide portability of mailets
between servers, just a common API, right?
Meaning that I cannot simply get a mailet written from James and simply
pop it into XMailServer and hope it to run, right?
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?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon dependance in mailets
Posted by Serge Knystautas <se...@lokitech.com>.
----- Original Message -----
From: "Serge Sozonoff" <se...@globalbeach.com>
> From a mailet developers point of view, I would much rather have the DB
> stuff exposed through the Mailet API.
> If you really want to go your own way or need something not provided by
the
> API you still have the freedom to do so.
For the same reason I don't think mailet API needs to specify logging, I
don't think we need to expose DB stuff through it. There are other standard
approaches to doing this (that while certainly would get used by mailets,
don't need an API).
I think it would be good to flesh out the mailet specification (instead of
relying on an API to do everything), that describes how mailets might log,
get db connections, etc... (and explain the mailet lifecycle, whatever
else...)
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon dependance in mailets
Posted by "Noel J. Bergman" <no...@devtech.com>.
Just going back and cleaning up some easy messages before calling it a
night. It appears that we have nicely resolved this issue by using JNDI as
the mechanism by which to expose resources, analogous to the Servlet
Specification.
--- Noel
-----Original Message-----
From: Serge Sozonoff [mailto:serge@globalbeach.com]
Sent: Monday, January 06, 2003 14:02
To: James Developers List
Subject: Re: Avalon dependance in mailets
Hi,
>>From a mailet developers point of view, I would much rather have the DB
stuff exposed through the Mailet API.
If you really want to go your own way or need something not provided by the
API you still have the freedom to do so.
Also, I do agree with Danny that we probably should not force implemenations
to make db access available.
Sergei
----- Original Message -----
From: "Jason Webb" <jw...@inovem.com>
To: "'James Developers List'" <ja...@jakarta.apache.org>
Sent: Monday, January 06, 2003 6:00 PM
Subject: RE: Avalon dependance in mailets
> My opinion (and what we do here) is mailets should make their own
> arrangements.
> It's easier for both James and my code because:
> 1) James doesn't have to second guess what I might want from a DB
> connection
> 2) If I want to handle the connection (if it dies etc) I can do so
> 3) I may want to control how the pooling works etc.
>
>
> If you do your first option then using isDatabaseConnectionProvider()
> seems OK
> -- Jason
>
> > -----Original Message-----
> > From: Danny Angus [mailto:danny@apache.org]
> > Sent: 06 January 2003 16:58
> > To: James Developers List
> > Subject: RE: Avalon dependance in mailets
> >
> >
> > Hi again,
> >
> > The next thing I'm stuck on is database connections.
> > Now currently there are a squad of mailets using avalon to
> > get database connections, however we want to remove avalon
> > dependancies from mailets, so...
> >
> > do we either make db connections available through the
> > MailetAPI or do we force mailets to make other arrangements.
> >
> > Assuming the first one, which I am, I don't think that we
> > should force implementations to make db access available, it
> > may not be appropriate for every case, therefore I'm going to
> > assume that this is an optional feature of the API and add to
> > mailet context the following:
> >
> > boolean isDatabaseConnectionProvider()
> > and java.sql.Connection getDatabaseConnection(String datasourceName)
> >
> > so that mailets which require database connections can fail
> > gracefully in containers which don't support database access.
> >
> > Any thoughts?
> >
> >
> > d.
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Avalon dependance in mailets
Posted by Serge Sozonoff <se...@globalbeach.com>.
Hi,
>From a mailet developers point of view, I would much rather have the DB
stuff exposed through the Mailet API.
If you really want to go your own way or need something not provided by the
API you still have the freedom to do so.
Also, I do agree with Danny that we probably should not force implemenations
to make db access available.
Sergei
----- Original Message -----
From: "Jason Webb" <jw...@inovem.com>
To: "'James Developers List'" <ja...@jakarta.apache.org>
Sent: Monday, January 06, 2003 6:00 PM
Subject: RE: Avalon dependance in mailets
> My opinion (and what we do here) is mailets should make their own
> arrangements.
> It's easier for both James and my code because:
> 1) James doesn't have to second guess what I might want from a DB
> connection
> 2) If I want to handle the connection (if it dies etc) I can do so
> 3) I may want to control how the pooling works etc.
>
>
> If you do your first option then using isDatabaseConnectionProvider()
> seems OK
> -- Jason
>
> > -----Original Message-----
> > From: Danny Angus [mailto:danny@apache.org]
> > Sent: 06 January 2003 16:58
> > To: James Developers List
> > Subject: RE: Avalon dependance in mailets
> >
> >
> > Hi again,
> >
> > The next thing I'm stuck on is database connections.
> > Now currently there are a squad of mailets using avalon to
> > get database connections, however we want to remove avalon
> > dependancies from mailets, so...
> >
> > do we either make db connections available through the
> > MailetAPI or do we force mailets to make other arrangements.
> >
> > Assuming the first one, which I am, I don't think that we
> > should force implementations to make db access available, it
> > may not be appropriate for every case, therefore I'm going to
> > assume that this is an optional feature of the API and add to
> > mailet context the following:
> >
> > boolean isDatabaseConnectionProvider()
> > and java.sql.Connection getDatabaseConnection(String datasourceName)
> >
> > so that mailets which require database connections can fail
> > gracefully in containers which don't support database access.
> >
> > Any thoughts?
> >
> >
> > d.
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:james-dev-> unsubscribe@jakarta.apache.org>
> > For
> > additional commands,
> > e-mail: <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon dependance in mailets
Posted by Jason Webb <jw...@inovem.com>.
My opinion (and what we do here) is mailets should make their own
arrangements.
It's easier for both James and my code because:
1) James doesn't have to second guess what I might want from a DB
connection
2) If I want to handle the connection (if it dies etc) I can do so
3) I may want to control how the pooling works etc.
If you do your first option then using isDatabaseConnectionProvider()
seems OK
-- Jason
> -----Original Message-----
> From: Danny Angus [mailto:danny@apache.org]
> Sent: 06 January 2003 16:58
> To: James Developers List
> Subject: RE: Avalon dependance in mailets
>
>
> Hi again,
>
> The next thing I'm stuck on is database connections.
> Now currently there are a squad of mailets using avalon to
> get database connections, however we want to remove avalon
> dependancies from mailets, so...
>
> do we either make db connections available through the
> MailetAPI or do we force mailets to make other arrangements.
>
> Assuming the first one, which I am, I don't think that we
> should force implementations to make db access available, it
> may not be appropriate for every case, therefore I'm going to
> assume that this is an optional feature of the API and add to
> mailet context the following:
>
> boolean isDatabaseConnectionProvider()
> and java.sql.Connection getDatabaseConnection(String datasourceName)
>
> so that mailets which require database connections can fail
> gracefully in containers which don't support database access.
>
> Any thoughts?
>
>
> d.
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:james-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Database connections (was RE: Avalon dependance in mailets)
Posted by Serge Knystautas <se...@lokitech.com>.
----- Original Message -----
From: "Danny Angus" <da...@apache.org>
> there could be two kinds of mailet, Mailet's and DataMailet's the latter,
by
> implementing DataMailet, declare their requirement for database
connections.
>
> Then the container implementors can choose and declare in their
> specifications whether the container is a DataMailet container
>
> DataMailet would extend Mailet but DataMailetContext
> (getDataMailetContext()) would have to provide
> getConnection(datasourceName).
>
> Or.. using IOC the container could supply a mailetDatasource on
> initialisation which would have a single method.. getConnection().
>
> The last would make it harder for a single mailet to access more than one
> datasource, so I prefer the MailetContext().getConnection(datasourceName)
> route.
I should have responded to this email with my last comment, but again I
don't think we should tie db connections to the mailet API. While database
connections are significantly less contentious than logging, I feel the same
argument applies that the mailet API doesn't need to create dependencies
with these related libraries to address these issues.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Database connections (was RE: Avalon dependance in mailets)
Posted by Kenny Smith <ke...@journalscape.com>.
Err... that should read "I'm _not_ terribly savvy with DataSources..."
Kenny
Kenny Smith wrote:
> Hi Danny,
>
> Having a DataMailet concept is the structure that I would prefer.
> Require that DataMailet configurations be provided a datasource (the
> configuration of that can be up to the individual implementation) during
> the initialization process so that during my handling of individual
> requests the mailet can use the DataSource to get a connection. I've
> done JDBC stuff before, but I'm terribly savvy with DataSources and all
> the spiffy things that come along with advanced use of the API, but I
> also agree accessing the datasources through names would be excellent so
> that multiple datasources can be accessed.
>
> Kenny Smith
> JournalScape.com
>
> Danny Angus wrote:
>
>> Ok,
>>
>> how about this.. I think it may be a better answer to this
>>
>> there could be two kinds of mailet, Mailet's and DataMailet's the
>> latter, by
>> implementing DataMailet, declare their requirement for database
>> connections.
>>
>> Then the container implementors can choose and declare in their
>> specifications whether the container is a DataMailet container
>>
>> DataMailet would extend Mailet but DataMailetContext
>> (getDataMailetContext()) would have to provide
>> getConnection(datasourceName).
>>
>> Or.. using IOC the container could supply a mailetDatasource on
>> initialisation which would have a single method.. getConnection().
>>
>> The last would make it harder for a single mailet to access more than one
>> datasource, so I prefer the MailetContext().getConnection(datasourceName)
>> route.
>>
>> d.
>>
>>
>>> do we either make db connections available through the MailetAPI
>>> or do we force mailets to make other arrangements.
>>
>>
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Database connections (was RE: Avalon dependance in mailets)
Posted by Kenny Smith <ke...@journalscape.com>.
Hi Danny,
Having a DataMailet concept is the structure that I would prefer.
Require that DataMailet configurations be provided a datasource (the
configuration of that can be up to the individual implementation) during
the initialization process so that during my handling of individual
requests the mailet can use the DataSource to get a connection. I've
done JDBC stuff before, but I'm terribly savvy with DataSources and all
the spiffy things that come along with advanced use of the API, but I
also agree accessing the datasources through names would be excellent so
that multiple datasources can be accessed.
Kenny Smith
JournalScape.com
Danny Angus wrote:
> Ok,
>
> how about this.. I think it may be a better answer to this
>
> there could be two kinds of mailet, Mailet's and DataMailet's the latter, by
> implementing DataMailet, declare their requirement for database connections.
>
> Then the container implementors can choose and declare in their
> specifications whether the container is a DataMailet container
>
> DataMailet would extend Mailet but DataMailetContext
> (getDataMailetContext()) would have to provide
> getConnection(datasourceName).
>
> Or.. using IOC the container could supply a mailetDatasource on
> initialisation which would have a single method.. getConnection().
>
> The last would make it harder for a single mailet to access more than one
> datasource, so I prefer the MailetContext().getConnection(datasourceName)
> route.
>
> d.
>
>
>>do we either make db connections available through the MailetAPI
>>or do we force mailets to make other arrangements.
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Database connections (was RE: Avalon dependance in mailets)
Posted by Stephen McConnell <mc...@apache.org>.
Danny Angus wrote:
>Or.. using IOC the container could supply a mailetDatasource on
>initialisation which would have a single method.. getConnection().
>
>The last would make it harder for a single mailet to access more than one
>datasource, so I prefer the MailetContext().getConnection(datasourceName)
>route.
>
The IOC approach using MailetContext().getConnection( key ) gets my vote
(where key is a key to one of possibly multiple datasource URLs declared by
a particular mailet type).
Cheers, Steve.
(who is watching the Mailet spec subject with interest as it is terribly
consistent with thoughts I have about containment/containers and the
freedom
developers should have with respect to lifecycles, lifestyle, etc.).
:-)
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Database connections (was RE: Avalon dependance in mailets)
Posted by Danny Angus <da...@apache.org>.
Ok,
how about this.. I think it may be a better answer to this
there could be two kinds of mailet, Mailet's and DataMailet's the latter, by
implementing DataMailet, declare their requirement for database connections.
Then the container implementors can choose and declare in their
specifications whether the container is a DataMailet container
DataMailet would extend Mailet but DataMailetContext
(getDataMailetContext()) would have to provide
getConnection(datasourceName).
Or.. using IOC the container could supply a mailetDatasource on
initialisation which would have a single method.. getConnection().
The last would make it harder for a single mailet to access more than one
datasource, so I prefer the MailetContext().getConnection(datasourceName)
route.
d.
> do we either make db connections available through the MailetAPI
> or do we force mailets to make other arrangements.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon dependance in mailets
Posted by Danny Angus <da...@apache.org>.
Hi again,
The next thing I'm stuck on is database connections.
Now currently there are a squad of mailets using avalon to get database
connections, however we want to remove avalon dependancies from mailets,
so...
do we either make db connections available through the MailetAPI
or do we force mailets to make other arrangements.
Assuming the first one, which I am, I don't think that we should force
implementations to make db access available, it may not be appropriate for
every case, therefore I'm going to assume that this is an optional feature
of the API and add to mailet context the following:
boolean isDatabaseConnectionProvider()
and java.sql.Connection getDatabaseConnection(String datasourceName)
so that mailets which require database connections can fail gracefully in
containers which don't support database access.
Any thoughts?
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon dependance in mailets
Posted by Harmeet Bedi <ha...@kodemuse.com>.
How about
getMailetContext().getUserRepository(Object name)
instead of
getMailetContext().getUserRepository(String name)
Harmeet
----- Original Message -----
From: "Danny Angus" <da...@apache.org>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Monday, January 06, 2003 5:40 AM
Subject: RE: Avalon dependance in mailets
> Hi,
>
> My next step is a little less clear, and requires some decision making,
>
> I'm going to do the same thing for user repositories, so that
> getMailetContext().getUserRepository(String name)
> returns a UserRepository, however I don't like the incosistency between
URL
> specifications for MailRepositories and names for UserRepositories.
>
> We need, IMO, to select one style and use it consistently, I favour URL's,
> which allow repositories to be created dynamically by mailets without
extra
> config changes, but what are the other opinions? Technnically its not a
big
> issue but in order to ensure portability of mailets, the primary objective
> of the excercise, we need to document what the string can contain.
>
> I'm going to implement getMailetContext().getUserRepository(String name)
on
> the basis that it doesn't break existing configurations, and changing it
to
> getMailetContext().getUserRepository(String URL) later is not really a
> change to the method signature, but an implementation detail.
>
>
>
>
> > -----Original Message-----
> > From: Danny Angus [mailto:danny@apache.org]
>
> > I've started commiting changes I've made which remove avalon
> > dependance from
> > the standard mailets.
> > Starting with repository access,
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon dependance in mailets
Posted by Serge Knystautas <se...@lokitech.com>.
----- Original Message -----
From: "Danny Angus" <da...@apache.org>
> My next step is a little less clear, and requires some decision making,
>
> I'm going to do the same thing for user repositories, so that
> getMailetContext().getUserRepository(String name)
> returns a UserRepository, however I don't like the incosistency between
URL
> specifications for MailRepositories and names for UserRepositories.
+1, but not sure how we can resolve this for user repositories.
> We need, IMO, to select one style and use it consistently, I favour URL's,
> which allow repositories to be created dynamically by mailets without
extra
> config changes, but what are the other opinions? Technnically its not a
big
> issue but in order to ensure portability of mailets, the primary objective
> of the excercise, we need to document what the string can contain.
I prefer the "mount" approach because of the ability it gives us to extend
the types of configurations. I also think it's better to not make the
mailets aware of how/where messages are being stored... IMHO it's cleaner
for the mailet to access /spam rather than know this is a DB or a file (or
whatever) repository.
I don't want to require changing a config file and restarting to support new
mappings. Given mail repositories already support children, an admin can
leave a /file mount and then just reference children below this. But more
importantly I think whatever changes an admin makes should update the config
file, so you can either change the config file or use the admin, and those
changes are permanent. For simplicity I would put all this mounting logic
into a separate config file.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon dependance in mailets
Posted by Danny Angus <da...@apache.org>.
Hi,
My next step is a little less clear, and requires some decision making,
I'm going to do the same thing for user repositories, so that
getMailetContext().getUserRepository(String name)
returns a UserRepository, however I don't like the incosistency between URL
specifications for MailRepositories and names for UserRepositories.
We need, IMO, to select one style and use it consistently, I favour URL's,
which allow repositories to be created dynamically by mailets without extra
config changes, but what are the other opinions? Technnically its not a big
issue but in order to ensure portability of mailets, the primary objective
of the excercise, we need to document what the string can contain.
I'm going to implement getMailetContext().getUserRepository(String name) on
the basis that it doesn't break existing configurations, and changing it to
getMailetContext().getUserRepository(String URL) later is not really a
change to the method signature, but an implementation detail.
> -----Original Message-----
> From: Danny Angus [mailto:danny@apache.org]
> I've started commiting changes I've made which remove avalon
> dependance from
> the standard mailets.
> Starting with repository access,
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>