Hi Noel/Danny,
Sorry for the delay in replying - busy, busy, busy. Here is the info you
asked for about are James usage.
Our James development is a SMTP to SMS gateway. A mailet is used to
receive a SMTP message and then send it to our SMS network. Fairly simple.
There are a few extraneous details to do with authenticating/authorizing
the sender and the receiver and matching the recipient to a mobile phone
number. The tricky part is as follows:
We have defined another mail store, to which we write all inbound messages
(well, those that match our criteria, anyway). Our mailet kicks of a
thread from it's init method, which endlessly loops around reading messages
from this store, translating them to SMS messages, then sending them to the
SMS server (implemented as an EJB call). I won't go into the details of
why we do things this way, but it should be noted that in the next phase of
this project (which is in the initial design phase right now), the use of
this aditional mail store will become even more central to our application.
The next phase should also double (or triple) the codebase and increase
throughput requirements by up to 100 times.
Here is a code snippet that outlines the key Avalon/James classes we use:
<code>
ComponentManager compMgr = (ComponentManager)getMailetContext
().getAttribute(AVALON_COMPONENT_MANAGER);
MailStore mailstore = (MailStore) compMgr.lookup
("org.apache.james.services.MailStore");
DefaultConfiguration spoolConf = new DefaultConfiguration("repository",
"generated:SmtpMailet.java");
spoolConf.setAttribute("destinationURL", _outgoingPath);
spoolConf.setAttribute("type", "SPOOL");
_outgoing = (SpoolRepository) mailstore.select(spoolConf);
</code>
I am not really sure how much of this stuff is intended to be internal to
James/Avalon and how much is supposed to be exposed to Mailet authors. It
does worry me that I had to import packages that were not included in the
mailer jar file. This indicates to me that the classes we use are not in
the public API. Particularly worrying is the requirement to cast Mail to
MailImpl in order to use the MailStore.
While I was the tech lead on this project, in reality I wrote very little
of the code. (I am generally not one of those "architects" that writes no
code, but that is just the way this one worked out.) However, I understand
that there were a number of issues with getting this actually working. A
different approach was taken initially (which still used the MailStore) but
had to be abandoned. I believe that the key issues centred around our use
of additional threads and the synchronization/locking semantics that James
uses when accessing the MailStore.
On reflection, the portions of this project that actually use James/Avalon
internal classes are fairly limited. I see the significant issue as being
the careful design work that went into finding our way through James'
synchronization/locking semantics.
All in all, I have to say that I am pretty impressed with JAMES. I have
read a fair bit of the source code (and some of the Avalon stuff, too,) and
like what I see. Clean, modular and well designed. Congrats to the James
developers on a job well done!
Cheers
ADK
--------------------------------------------
There is no magic.
"Noel J.
Bergman" To: "James Users List"
<[EMAIL PROTECTED]>
<noel@devtech. cc:
com> Subject: Implementation-specific?
12/11/2002
12:35
Please respond
to "James
Users List"
Aaron,
> Our JAMES-based codebase is becoming fairly sizable and
> is pretty tightly coupled to a few implementation-
> specific JAMES/Avalon features.
Please let us know what those are, since we're planning changes for James
v3. It would be nice to know what implementation dependencies you are
coupled with, so we can either try to accommodate users, or at least give
you a heads up on where things are going.
--- Noel
--
To unsubscribe, e-mail: <mailto:james-user-unsubscribe@;jakarta.apache.org
>
For additional commands, e-mail: <mailto:james-user-help@;jakarta.apache.org
>
-----------------------------------------------------------------------------------------------
Have you seen our website?.... http://www.vodafone.co.nz
CAUTION: This correspondence is confidential and intended for the named recipient(s)
only.
If you are not the named recipient and receive this correspondence in error, you must
not copy,
distribute or take any action in reliance on it and you should delete it from your
system and
notify the sender immediately. Thank you.
Unless otherwise stated, any views or opinions expressed are solely those of the
author and do
not represent those of Vodafone New Zealand Limited.
Vodafone New Zealand Limited
21 Pitt Street, Private Bag 92161, Auckland, 1020, New Zealand
Telephone + 64 9 357 5100
Facsimile + 64 9 377 0962
--
To unsubscribe, e-mail: <mailto:james-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:james-user-help@;jakarta.apache.org>
