james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject [server.trunk] extract "handler" stuff from core-module (Was: modules/package refactoring)
Date Sun, 03 Aug 2008 22:35:50 GMT
Stefano Bagnara ha scritto:
> Hi all,
> After I moved tests in the right places (excluding IMAP), I'd like to 
> sort out a better structure for our modules.
> IMHO we have some modules that is not appropriate (domain-api, as an 
> example, contains unrelated interfaces, does not need to exist) and we 
> have the core-module that should be splitted into multiple modules.
> The first thing I'd like to do is to create a "server-library" (or maybe 
> a listener-library / daemon-library) including code that is used by 
> services listening (pop3server, smtpserver, imapserver, nntpserver, 
> remotemanager).

While a wait an answer I'm working on this new module and I have questions.

1) any preference about the name? (it will include common code for 
cornerstone/excalibur based tcp listening services)

2) InternetPrintWriter is used both by code that will belong to the new 
module and by code used by other classes in core-library: I see we 
already have another copy in imap-codec-library. Should I make another 
copy or maybe it's better to have an "util-api" module (the name is 
weird, but this is the "workaround" for introducing an utility module in 
the current ant build)? I don't like code duplication so I would prefer 
to have the "api name" workaround or to introduce multiple dependencies 
levels in our build (maven does not have this limit, so ant build should 
be updated someway)...

3) I identified this classes as candidates to be part of this new module:
util.InternetPrintWriter (* see #2)

4) util.connection.* simply contains implementations for 
services.JamesConnectionManager and they names are directly referred in 
assembly.xml . IMHO they should be moved to a different package (they 
are not utilities, they are implementations of a service!). Maybe they 
should be moved and then we can create a compatibility-function module 
(or maybe put them in the phoenix-deployment, so that we don't bring 
this stuff to the spring deployment too) with classes in the old package 
simply extending the one in the new package. Opinions?

5) Most classes I listed in #3 should be moved to better packages to not 
overlap with already existing packages. Excluding 
services.JamesConnectionManager and the util.connection package I 
already discussed in #4 they are only used in james code and I think it 
is unlikely they are widely used by JAMES users/developers, so I propose 
to repackage them without creating a compatibility layer (we can create 
it in case someone will complain). I would use:
"something.connman" instead of util.connection
"something.watchdog" instead of util.watchdog
"services.JamesConnectionManager" unchanged (ATM, for compatibility 
reasons, and maybe moved to an API module later, but this is 
cornerstone/excalibur specific)
"something" for every other class from core and util listed in #3.
Where "something" should be the same name we choose for the library name 
(something-library, so, something could be "daemon", "listener", 
"handler", or any other idea you may propose....). ATM I'm slightly for 
something composite like "avalon-handler-library" and the "something" 
package could be "handler.avalon"

I think the answer to this use case will allow me to proceed with other 
simpler choices, too.


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

View raw message