You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-user@james.apache.org by Danny Angus <Da...@slc.co.uk> on 2004/10/07 10:11:29 UTC

Re: Mailet: Getting MailRepository and UsersRepository from MailetContext


-> I was able to get this to work.  Not sure it's *the*
-> way to do it, though... Carl

You've spotted our private shame ;-)
With the crrent version of the Mailet API that is the only way.
In fact this is a defect in the API, it compels you to have some knowedge
of the "vendor specific" architecture of the Mailet container.
In this respect it breaks the separation of concerns and the portability of
mailets between vendor architectures.
In future versions of the API this defect will be fixed by the simple
expedient of requiring certain (specified) services and resources to be
registered in a JNDI context.

This might (read probably will) require the addition of some interfaces to
the API as abstract representations of the services, but on the whole these
already exist in James and it need not involve more than package-name
refactoring of the interfaces.

It is our intention that it will remain possible to allow the avalon access
route in James (to support our installed user-base) but this will be
disabled by default and eventually it is planned to close this loophole and
enforce all interactions bewteen mailets and the server to be via specified
vendor independant mechanisms alone.
When I say "vendor independant" I would hope that we can re-craft all our
"hidden" dependancies with only reference to  java.*, javax.* and
org.apache.mailet.* alone, and remove all 3rd party dependance restrictions
from developers who comply with the API.

d.




***************************************************************************
The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any  responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited.

This footnote also confirms that this email message has been swept for the presence of computer viruses.

**************************************************************************

---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org


Re: Mailet: Getting MailRepository and UsersRepository from MailetContext

Posted by Carl Downs <ca...@yahoo.com>.
Thanks for the reply Danny... apologies for the latent response.  
 
I see.  That makes sense now.  The JNDI method would be a clean way to provide access.  And as you say James already seems to have most of the abstract representations of the services (in org.apache.james.services) needed so this (package renaming, etc) shouldn't be too disruptive for users like me.
 
I was wondering one thing, though.  If the transition that you speak of is in the works now, no sense in changing anything-- just let folks access the vendor-specific stuff directly for now.  If, on the other hand, it will be a while before this change arrives, wouldn't it be simpler for users to understand what's happening and to cope with the change by just adding the interface methods (and GenericServlet impls) back in with a proviso in the javadocs that describes the group's plans?  Just a thought.  :-)
 
Thanks again,
Carl

Danny Angus <Da...@slc.co.uk> wrote:


-> I was able to get this to work. Not sure it's *the*
-> way to do it, though... Carl

You've spotted our private shame ;-)
With the crrent version of the Mailet API that is the only way.
In fact this is a defect in the API, it compels you to have some knowedge
of the "vendor specific" architecture of the Mailet container.
In this respect it breaks the separation of concerns and the portability of
mailets between vendor architectures.
In future versions of the API this defect will be fixed by the simple
expedient of requiring certain (specified) services and resources to be
registered in a JNDI context.

This might (read probably will) require the addition of some interfaces to
the API as abstract representations of the services, but on the whole these
already exist in James and it need not involve more than package-name
refactoring of the interfaces.

It is our intention that it will remain possible to allow the avalon access
route in James (to support our installed user-base) but this will be
disabled by default and eventually it is planned to close this loophole and
enforce all interactions bewteen mailets and the server to be via specified
vendor independant mechanisms alone.
When I say "vendor independant" I would hope that we can re-craft all our
"hidden" dependancies with only reference to java.*, javax.* and
org.apache.mailet.* alone, and remove all 3rd party dependance restrictions
from developers who comply with the API.

d.




***************************************************************************
The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited.

This footnote also confirms that this email message has been swept for the presence of computer viruses.

**************************************************************************

---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org


		
---------------------------------
Do you Yahoo!?
vote.yahoo.com - Register online to vote today!