Hi Stefano,
You're right, having spring modules is a bit bloated for mailbox and
imap. I won't go for it.
The samples could be provided by the unit tests (if it is not already
available).
We can retalk about your points about filesystem,... later on when we
will review server modules from the outside.
About the simplificastion of the mailbox API:
- yes, I could have implicit parameters deduced from the session,...
makes sense to me.
- about the transaction, we should look the different implementation
(jpa,...) to identity the impacts of changing this.
Tks,
Eric
On 21/01/2011 11:51, Stefano Bagnara wrote:
2011/1/21 Eric Charles<e...@apache.org>:
Hi,
The spring is for now completely defined in sever.
This means that developers willing to use mailbox (or imap) as a component
have no straigh-forward way to assemble mailbox classes with spring.
We could create a spring module for mailbox (and imap), define there the
injection, and simply import the definition in server context.
A bit like cxf does with:
<import resource="classpath:META-INF/cxf/cxf.xml" />
<import resource="classpath:META-INF/cxf/cxf-extension-soap.xml" />
<import resource="classpath:META-INF/cxf/cxf-servlet.xml" />
About the place of the spring context, META-INF seems to be a trend in many
projects. We could place them in META-INF/james.
How much james-server specific are the current spring?
e.g: I see:
james-mailbox-maildir-context.xml references filesystem, so it is not "generic".
james-mailbox-jcr-context.xml have path references that seems specific
to james-server.
The mailbox spring xml are not complex spring objects, but I don't
know if they are really needed to setup standalone mailbox.
Isn't a "main" constructing the right objects enough? Or instead
mailbox code expect something spring specific to happen?
About IMAP:
----
<bean id="imapserver" class="org.apache.james.imapserver.netty.IMAPServer">
<property name="imapDecoder" ref="imapDecoder"/>
<property name="imapEncoder" ref="imapEncoder"/>
</bean>
<bean id="imapProcessor"
class="org.apache.james.imap.processor.main.DefaultImapProcessorFactory"
factory-method="createDefaultProcessor">
<constructor-arg index="0" ref="mailboxmanager"/>
<constructor-arg index="1" ref="subscriptionManager"/>
</bean>
<bean id="imapDecoder" factory-bean="imapDecoderFactory"
factory-method="buildImapDecoder"/>
<bean id="imapDecoderFactory"
class="org.apache.james.imap.main.DefaultImapDecoderFactory"/>
<bean id="imapEncoder" factory-bean="imapEncoderFactory"
factory-method="buildImapEncoder"/>
<bean id="imapEncoderFactory"
class="org.apache.james.imap.encode.main.DefaultImapEncoderFactory"/>
----
Why don't we simply provide a main class in imap that does the following:
public ImapServer create(MailboxManager mailboxManager,
SubscriptionManager subscriptionManager) {
ImapDecoder imapDecoder =
org.apache.james.imap.main.DefaultImapDecoderFactory.buildImapDecoder();
ImapEncoder imapEncoder =
org.apache.james.imap.main.DefaultImapEncoderFactory.buildImapEncoder();
ImapServer server = new
org.apache.james.imapserver.netty.IMAPServer(imapDecoder,
imapEncoder);
ImapProcessor imapProcessor =
org.apache.james.imap.processor.main.DefaultImapProcessorFactory.createDefaultProcessor(mailboxManager,
subscriptionManager);
return server;
}
mailbox and imap should be simple enough to not need spring. I expect
users of that libraries to integrate them in their own environment and
I see spring dependency as a limit in this case.
This means that definitions are embedded in jars, so less easy to change.
However, I think only developers needs to change beans, so it will be easy
for him to have a custom spring context with its own files.
If they don't use injection or lifecycle or other spring facilities I
don't see a big advantage in providing the spring stuff instead of a
simple "default" class. If only developers need to change it then they
can write their own class if the default one is not enough.
Also, this will allow more easily to write more samples for the different
projects (mailbox, imap,...).
Wdyt?
I think using mailbox should be easier... I haven't looked very much
at it, but it seems that in order to simply create a folder and put a
message into it or getting a list of messages from a folder is a
complex task right now.
How do I create a maildir folder right now? I think we can't expect
direct mailbox users if we don't provide a simpler interface for it
(or maybe I simply haven't found it).
Here is the code I find in a test:
----
MaildirStore store = new MaildirStore(MAILDIR_HOME + "/%domain/%user");
MaildirMailboxSessionMapperFactory mf = new
MaildirMailboxSessionMapperFactory(store);
MaildirMailboxManager manager = new MaildirMailboxManager(mf, null, store);
manager.init();
String user = "test@localhost";
MailboxSession session = manager.createSystemSession(user, new
SimpleLog("Test"));
manager.createMailbox(new MailboxPath(MailboxConstants.USER_NAMESPACE,
user, "Trash"), session);
-----
I find it a bit "complex" for an average user that is simply looking
for a "maildir" library.
At least it should be easy to reduce it a bit like this:
-------
MaildirMailboxManager manager = new
MaildirMailboxManager("myfolder/%domain/%user"); // internally create
MaildirStore and MaildirMailboxSessionMapperFactory appropriately and
maybe also init() it!
String user = "test@localhost";
MailboxSession session = manager.createSystemSession(user); // no
logger parameter, then use a slf4j
manager.createMailbox("Trash", session); // this can create the
MailboxPath using "Trash" as a user folder, so getting the user from
the session and the namespace from MailboxConstants.USER_NAMESPACE.
-------
And maybe it should be even simpler: I try to think why I would need
maildir and probably I don't expect to deal with sessions and users,
but only with path and messages (but maybe I'm missing the goal of the
mailbox library).
If this is possible then I don't see why an user should care about spring.
Just my 2 cents: of course you better know what's in there, so if you
still think having spring config in mailbox then go ahead.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
