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
