robert burrell donkin wrote:
On 2/1/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
> but just running probably isn't enough. probably want to be able to
> integrate other services and this is where things become a little more
> difficult. ATM the database implementation uses torque. you'd probably
> want to hack a alternative implementation using JPA POJOs for the data
> binding. maybe could talk to OpenJPA over in the incubator.
Currenlty the database implementation is plain JDBC via
excalibur/cornerstone-datasource services.
Torque is only currently used in trunk as an experimental mailbox
manager backend component.
the spools and so on should be only of interest to james internally.
so there should be no interoperability issues there. yes, mailet
components in the container may want to be fed mail from the spool for
processing and other components may want to post mail onto a spool to
be processed but that should all be black box and so data sources
would be fine.
ISTM that the substantive issue is sharing mailboxes. in other words,
allowing access to a mailbox (a collection of emails for example a
user INBOX) from both james and other container based components. it
would be possible to share objects at the data access level but
perhaps it might be better to expose an interface to allow requests to
be correct scheduled.
- robert
I think I don't have understood your message, sorry. I add some more
information: hope this make sense.
What I wanted to explain was that torque is only used in an experimental
module of the trunk version of james. 2.3.0 does not include torque.
We have file or db implementations of the MailRepository and
SpoolRepository interfaces that are used to spool and store the messages
for later POP3 access.
The file implementation is done using cornerstone store object and its
stream/object file repositories. THe db implementation is custom james
code and uses direct JDBC code (JDBCMailRepository/JDBCSpoolRepository).
This is what we have in james now and what we released. (It was not an
opinion but a fact).
My opinion: the spools and the mail repositories are 2 core items, they
both deserve public interfaces. I proposed to remove the MailRepository
interface in favor of the MessageRepository many times but we delayed
the issue waiting for the first experiments on the IMAP storage stuff,
as we knew our current interfaces was not enough for IMAP, so we
preffered to first find something that worked with IMAP and then decide
what should have been part of the new MessageRepository object.
FWIW I already wrote avalon components that I deploy within james and
manage mailboxes and spools using the James apis (Store component,
MailRepository, SpoolRepository). Unfortunately withing phoenix we can't
export a service outside of the container.
If you use the spring integration code then you simply can use
context.getBean("store") and retrieve the needed
MailRepository/SpoolRepository from there.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
