You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Alexander Zhukov <zh...@ukrpost.net> on 2005/01/30 19:17:43 UTC
[James-NG] Avalon-free James proposal and reference implementation
Hi, James hackers!
Recently on the mailing list I saw messages of departure from
avalon-based container
So i decided to propose my ideas and reference implementation as a basis
of next generation james
(i hope avalon-free version) which i propose to call jamesng
nice points in jamesng for apache james are:
- components are independent POJOs (CDI IoC) so no funky
interface has to be implemented to extend james-ng
(see COMPONENTS)
- single file groovy-based configuration
- multiple domains support from the ground up
- adaptable user stores (enterprise does not want to change its
db/ldap directory/whatever) (see ENTERPRISE DB)
- javax.mail.Store/Folder based mail repositories support
hierarhical folders, tested with Maildir and mbox providers
(see STORES)
- extensive support for folder/store/user caching to speed-up
servers (see CACHING)
- imap4 support (not complete but usable)
- pop3 support
- independent components can be easily added and integrated into
build system
things laking:
- smtp support - no spooling/remote deliveries, working on it
right now
ENTERPRISE DB
server is large ISP/enterprise targeted which means
- support for multiple domains on a single/multiple IP addresses,
- highly configurable user stores - database should not be designed for
use with james (as it is with current james)
but rather user store adapts to the existing userstores of an
isp/enterprise.
Often enterprises already have their user databases often they contain
legacy elements which such companies
just very much hesitate to change to something new.
Above mentioned is very much true for LDAP directories - you cannot
expect an enterprise to change its
LDAP directory to fit james in
COMPONENTS
All components of james-ng are POJOs no component _must_ implement some
funky interface to be included in the server.
Components adhere CDI style IoC which besides other advantages allows
configuration to be a single groovy file.
The task of groovy configuration is to assemble all components together.
STORES
Mail stores (repositories) are plain javax.mail.Store providers.
Since javax.mail.Folder interface supports hierarchy james-ng gets
"free" IMAP support - no need to reengineer mail
repository to access folders/sub-folders. However to support all of IMAP
features such provider's Folder implementation
must as well implement UIDFolder interface to support IMAP UID operations.
For now tested are Maildir and mbox providers, but apparently nothing
prevents to write/use existing jdbc providers
that would store mails in database.
Simple groovy-based configuration allows administrator to configure
different types of stores for different users.
CACHING
I am currently in charge of rather large (150k+ users) free webmail with
multiple domains
and i dont have very new and high-performing hardware to host it so i
designed the server for performance.
The main point is to avoid unproductive waste of performance (very much
true for most unix mail servers)
stores/folders opened by users as well as user objects are cached
(certainly you can turn the cache off) instead of being
open on every user login. Very much helps for polling clients which
disconnect and connect back in 10 minutes.
Administrator can adjust the caching policy, for now implemented are
LRUCache and GCCache (reference map based cache).
If you are reading this then you are ready to see what does jamesng look
like.
Since the codebase is pretty large for an attachment to email I have
setup cvs repostitory as well as source release repository.
Source release:
http://devel.priocom.com/jamesng/jamesng-20050130-src.tar.gz
Binary release
http://devel.priocom.com/jamesng/jamesng-20050130.tar.gz
I suggest you download source release and build binary release or just
download binary release to play with the groovy
all-in-one configuration.
Anonymous CVS access:
CVSROOT=":pserver:anoncvs@devel.priocom.com:/export/cvsroot/jamesng"
anoncvs user has empty password
FishEye (like viewcvs but better and in java)
http://devel.priocom.com:8083/viewrep/JamesNG
You can also download the latest cvs checkout tarball at
http://devel.priocom.com:8083/viewrep/~tarball=tgz/JamesNG/JamesNG.tgz
As steps further steps to develop apache james i propose:
- create a new branch in svn called "JAMES_NG" or the like
- give up using avalon container in this branch
- either use one of the existing CDI containers (picocontainer) or
accept proposed groovy-based config files
- merge smtp/mailer/mailet code into JAMES_NG branch
- use the branch as a basis for James v3
Any ideas?
Flames?
What is wrong with my approach?
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Multiple Domain support, again
Posted by Danny Angus <da...@gmail.com>.
> I didn't need to change the remotemanager stuff as I add/change users via a
> webapp. But these are also no brainers.
Someone has to do the work. It is not enough to do half a job
Are you volunteering?
You *know* how to do this.. Make a Patch. Send it to the list for review
and inclusion.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Multiple Domain support, again
Posted by Vaughan Hines <va...@pppoe.ca>.
At 2005-01-30 04:05 PM, you wrote:
>I have a textfile on my desktop with the same name. Comments below.
>
>Alexander Zhukov wrote:
>> Hi, James hackers!
>>
... <snip>
>
>I prefer spring, but whatever.
>
>> - multiple domains support from the ground up
herewith follows a long post.
Three things:
1) multi domain support *really* needs to be put into James
2) Pop3 user naming schemes are a red herring and are the problem for the
multi domain admin rather than the James developer
3) most of what is discussed below has already been implemented in my own code
MULTI DOMAINS
To enable multiple domain support needs a change in James core, which to
me, is the Mailet API.
There are two different types of reasons to enable multiple domain support
from the ground up.
1) ease of use for non-developers/DBAs. The current way to do multiple
domain support requires the admin to maintain a custom database or XML file
and to add/manage users "by hand". As well, running multiple domains is a
fairly common thing to do so this is a limiting factor for wider spread
usage. I suspect that the average admin, by now, expects multiple domain
support in their mail server built-in.
2) in a multiple domain scenario using the currently supported way, any
"upstream" applications such as Fetchmail are unaware of the downstream
processing (via the mailets/matchers) of the mail recipient address. This
can cause legitimate addresses to be marked as "not found" and illegitimate
address to be okayed. Currently, this is okay for most James admins since
most issues are solved via mail forwarding and/or aliasing. However, if
you are a developer looking to extend, create or enhance any "upstream"
application *and* you are in a multiple domain situation then the lack of
multiple domain support in the James core API (Mailet) is limiting and you
will need to make you own solution (alter the Mailet API).
I would like to stress that the lack of multiple domain support for
non-DBAs/developers is a limiting factor for non developer admins to adopt
usage of James. Not a showstopper but a limitation.
In any case, the current methodology is dangerous. There are numerous
scenarios in Fetchmail whereby Fetchmail will either 1) send mail for one
user incorrectly to another user or 2) it will be marked as valid when it
is invalid or 3) vice-versa.
Example Start: $$$$$$$$$$$$$$$
A very simple example: a single domain james server S1 is configured with
users "Sue" and "Bill" who are unrelated.
"Sue" has been configured for a fetchmail account for her domain
(company.com); the fetchmail config for company.com has a default domain
tag because the mail server at her company just uses the first name (just
like James!) for email without any domain parts.
A completely unrelated third user Rob on S1 wants to send mail to
bill@company.com who is a close lawyer friend at Sue's company.
Bill@company.com is thus completely and utterly unrelated to Bill the local
S1 James user.
Using the S1 James mail server Rob sends his lawyer (bill@company.com) an
intensely private note "Dear Bill, about your extra-marital affair...".
If S1 was a multi-domain James server then the mail would get delivered to
Bill the lawyer because bill@company.com is not a valid user on the server
and it would be delivered remotely to company.com's mail server and this
scenario work and everyone is happy.
Unfortunately for Rob, the mail server S1 being used is James in single
domain mode.
On a single domain James server this will get delivered to the local "Bill"
who is completely unrelated to either Rob, Bill the lawyer @company.com or
Sue. It will get delivered because the because matcher RecipientIsLocal
will match the first name ("Bill") because user "Bill" does exist on S1 and
it will also match the server name as local because Fetchmail requires the
default domain name to be in the server names config list.
( return mailetContext.isLocalServer(recipient.getHost())
&& mailetContext.isLocalUser(recipient.getUser());
)
Thus RecipientIsLocal believes "Bill@company.com" is local and is valid and
will deliver it the inbox "Bill" which is a different Bill. While both Bill
and company.com do exist it is plainly evident that the combination
Bill@company.com does not exist on the S1 mail server.
Sooooo, if my ISP or organization happen to be using James and there is a
person with an account on the domain i'm sending to and that person has
Fetchmail configured with a default domain and there exists another user@
who is the same as my user@ then my completely properly addressed mail wilI
go to a completely unknown third party who is unrelated to me, the domain I
was sending to, and the account which was using Fetchmail. And all parties
concerned with never know about this unless the local accidental recipient
tells the S1 admin.
Since a non-techie James admin isn't going to appreciate the subtlety of
all this (***DON"T USE FETCHMAIL WITH A DEFAULT DOMAIN IN SINGLE DOMAIN
MODE***) there will be lots of problems like this. Since they will only
happen periodically and the mail can just be sent to a seemingly random
email box (imagine if the Bill the local account was really a mailing list
or an alias for someone else entirely or itself a mailbox being fetched)
these kind of issues will tend to go unnoticed until a really really
important and private email goes to the wrong person....
Example End: $$$$$$$$$$$$$$$$$$
If this example doesn't work for you ("We can change the default domain tag
requirements ...") rest assured that there are a virtual unlimited number
of weirdo scenarios llike this; it just depends on what the upstream app
such as Fetchmail does and they will be very hard to test for. There are
many subtle issues like this and it is because the upstream apps such as
Fetchmail are unable to do a proper mail address name resolution.
The inherent problem is that the James core lacks multi-domain support and
is unable to resolve "user@domain" integrally.
Conclusion: single domain James can be dangerous in highly unusual and
unsuspecting ways.
In order to do multi domain support in the core of James, the following
needs to be changed:
MailetContext.java
==============
add two calls that enable inbox-name resolution from a MailAddress.
Currently you can only do this from a String which represents the user@
part of the address.
boolean isLocalServer(String serverName);
boolean isLocalUser(String userAccount);
should be:
boolean isLocalUser(MailAddress address);
String getLocalUser(MailAddress address);
this is the entire problem/issue with multiple domain support. In the
current model, James maps/assumes just the user@ part is the key for the
inbox name. For multiple domains this causes major problems.
James.java
========
fixup calls where just the user@ part is being used.
For example, in v2.2.1 line 801 from StoreMail(...) String
originalUsername = recipient.getUser();
s/b String username = resolver.getLocalUser(recipient) or some variant
Resolver class
===========
write a class/interface with the above two methods in it. Enable
James.java to use this class.
An implementation of this class could use a database or XML. It would be
very similar to the JDBCVirtualUserTable
class except that it is accessible via the MailetContext which means all
applications can get at it to resolve mail names into
inbox names rather than just the mailets and matchers.
One way to do this is in a database implementation is to use a table with a
column triplet of:
MailAddressUser, MailAddressDomain, username with Unique constraint on
combo of the first two columns
***There can be a default implementation that still does things the single
domain way but this is dangerous, as in the example above***.
SMTPServer, Fetchmail etc.
=====================
fixup fetchmail and any other upstream applications to make the
isLocalUser(MailAddress address) call instead of the current
isLocalUser(String) one.
Various Mailets/Matchers
===================
any that uses isLocalUser(String) needs to be changed e.g. RecipientIsLocal
RemoteManager
============
change adduser (and related calls) syntax to:
adduser inboxname user <domain>
where "inboxname" is what we currently called the user in James
and "user" is the "user@" part of a mail address
and <domain> is optional and is the "@domain" part of a mail address
and add a new command to name a a default domain (or put it in the config.xml).
POP3
>
>You'd have to explain how this works, since SMTP is no-brainer, and POP3
>would not support it. Basically this is largely a function of account
>name mappers, but would need to be fleshed out.
>
It should be noted that when an admin is running in a multiple domain
scenario he or she has this naming problem to overcome regardless of the
mail server being used (on account of the fact that the admin has to tell
the users what userid to log in with).
That is, the user authentication issue is decoupled from the inbox
resolution issue. It's the user's problem to figure out the scheme and its
the mail server's problem to allow the user to express his/her solution
into the server.
As far as I can tell, this is a point which seems to have been
misunderstood in previous threads on this topic last year and before.
Which leads to the conclusion, that James simply needs to provide the admin
with a facility to do this rather than offering up a specific
username-to-inbox-name scheme. which one (user@domain, user-domain and
other variants) is largely besides the point. The mail server needs to be
pop3naming-scheme-neutral.
In order to do this the following needs changing:
POP3
====
similar type of solution as the MailetContext changes above.
The POP3 james code would change to call in to a class/interface such as:
boolean isPopUser(String pop3Name);
MailAddress getMailAddress(String pop3name);
Database/XML
===========
A database/XML schema table with a column triplet of: (MailAddressUser,
MailAddressDomain, pop3name). (Similar, as above).
Remote Manager/Web App
====================
A corresponding RemoteManager command: addpopuser pop3name user <domain>
(or a WebApp change for those using browser based admin)
This now allows James to decouple the scheme the admin chooses from the
implementation in the code.
Just as obviously, one can wrap all his into one RemoteManager change:
adduser inboxname user pop3name <domain>
Conclusion
=========
Obviously, in a database implementation of all of this, the user can use
any Web tools/db tools to change the lookup tables directly and/or use a
WebApp that takes the place of the remote manager.
I have already implemented all of this in my own codebase except changes to
SMTPServer, RemoteManager, and Pop3.
I changed James.java, a few mailets/matchers, a few Fetchmail classes,
MailetContext.java as well as implemented a Resolver class that uses a
caching JDBC implementation running on MySQL with the schemas, more or
less, as mentioned above. An XML version would be, relatively, a
no-brainer for anyone who wrote the XML user virtual stuff.
I didn't need to change the remotemanager stuff as I add/change users via a
webapp. But these are also no brainers.
The POP3 change is straightforward.
It would be better for everyone concerned if we could just make the changes
in the James core. There are other solutions. This is the one I did.
Cheers,
Vh
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [James-NG] Avalon-free James proposal and reference implementation
Posted by Alexander Zhukov <zh...@ukrpost.net>.
Steen Jansdal wrote:
> Alexander Zhukov wrote:
>
>> - single file groovy-based configuration
>
>
> IMO configuration should be located in the database.
>
> Changes to configuration should not require a restart of
> the mail server.
This can be done by MBeans
I didnt mention the MBeans part of my jamesng on purpose just not to
complicate things, but i have written two example MBeans +
MBeansConfig.groovy as an example of configuring MBeans.
As for configuration in the database - you can store groovy file in the
db - no problem
OR alternatively
all settings (like cache size, repository types, etc) can be stored in
db and groovy config script can fetch them on startup from database
groovy has built-in sql capabilities so that should be pretty straight
forward to implement by admin
refer to
http://groovy.codehaus.org/Groovy+SQL
for more details of sql in groovy
>
>
> Steen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [James-NG] Avalon-free James proposal and reference implementation
Posted by Steen Jansdal <st...@jansdal.dk>.
Alexander Zhukov wrote:
> - single file groovy-based configuration
IMO configuration should be located in the database.
Changes to configuration should not require a restart of
the mail server.
Steen
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [James-NG] Avalon-free James proposal and reference implementation
Posted by Alexander Zhukov <zh...@ukrpost.net>.
Laszlo Hornyak wrote:
> Hi!
>
> I am new to the list. I see that avalon dependency received couple of
> critics on the list. Why is avalon 'bad' and what is the intention of
> the james team with this?
I dont say avalon is bad I just think CDI approach is more scalable and
easier to understand. To form your own opinion please refer to Martin
Fowlers article "Inversion of Control Containers and the Dependency
Injection pattern"
http://www.martinfowler.com/articles/injection.html
Among benefits of CDI IoC is high level of component decoupling that is
your components may not depend on each other or have any requirement
that is a show-stopper to include your component into the software you
are developing.
>
> Laszlo
>
> Alexander Zhukov wrote:
>
>> Hi, James hackers!
>>
>> Recently on the mailing list I saw messages of departure from
>> avalon-based container
>> So i decided to propose my ideas and reference implementation as a
>> basis of next generation james
>> (i hope avalon-free version) which i propose to call jamesng
>>
>> nice points in jamesng for apache james are:
>> - components are independent POJOs (CDI IoC) so no funky
>> interface has to be implemented to extend james-ng
>> (see COMPONENTS)
>> - single file groovy-based configuration
>> - multiple domains support from the ground up
>> - adaptable user stores (enterprise does not want to change its
>> db/ldap directory/whatever) (see ENTERPRISE DB)
>> - javax.mail.Store/Folder based mail repositories support
>> hierarhical folders, tested with Maildir and mbox providers
>> (see STORES)
>> - extensive support for folder/store/user caching to speed-up
>> servers (see CACHING)
>> - imap4 support (not complete but usable)
>> - pop3 support
>> - independent components can be easily added and integrated into
>> build system
>>
>> things laking:
>> - smtp support - no spooling/remote deliveries, working on it
>> right now
>>
>> ENTERPRISE DB
>> server is large ISP/enterprise targeted which means
>> - support for multiple domains on a single/multiple IP addresses,
>> - highly configurable user stores - database should not be designed
>> for use with james (as it is with current james)
>> but rather user store adapts to the existing userstores of an
>> isp/enterprise.
>> Often enterprises already have their user databases often they contain
>> legacy elements which such companies
>> just very much hesitate to change to something new.
>> Above mentioned is very much true for LDAP directories - you cannot
>> expect an enterprise to change its
>> LDAP directory to fit james in
>>
>> COMPONENTS
>> All components of james-ng are POJOs no component _must_ implement
>> some funky interface to be included in the server.
>> Components adhere CDI style IoC which besides other advantages allows
>> configuration to be a single groovy file.
>> The task of groovy configuration is to assemble all components together.
>>
>> STORES
>> Mail stores (repositories) are plain javax.mail.Store providers.
>> Since javax.mail.Folder interface supports hierarchy james-ng gets
>> "free" IMAP support - no need to reengineer mail
>> repository to access folders/sub-folders. However to support all of
>> IMAP features such provider's Folder implementation
>> must as well implement UIDFolder interface to support IMAP UID
>> operations.
>> For now tested are Maildir and mbox providers, but apparently nothing
>> prevents to write/use existing jdbc providers
>> that would store mails in database.
>> Simple groovy-based configuration allows administrator to configure
>> different types of stores for different users.
>>
>> CACHING
>> I am currently in charge of rather large (150k+ users) free webmail
>> with multiple domains
>> and i dont have very new and high-performing hardware to host it so i
>> designed the server for performance.
>> The main point is to avoid unproductive waste of performance (very
>> much true for most unix mail servers)
>> stores/folders opened by users as well as user objects are cached
>> (certainly you can turn the cache off) instead of being
>> open on every user login. Very much helps for polling clients which
>> disconnect and connect back in 10 minutes.
>> Administrator can adjust the caching policy, for now implemented are
>> LRUCache and GCCache (reference map based cache).
>>
>> If you are reading this then you are ready to see what does jamesng
>> look like.
>> Since the codebase is pretty large for an attachment to email I have
>> setup cvs repostitory as well as source release repository.
>>
>> Source release:
>> http://devel.priocom.com/jamesng/jamesng-20050130-src.tar.gz
>> Binary release
>> http://devel.priocom.com/jamesng/jamesng-20050130.tar.gz
>>
>> I suggest you download source release and build binary release or just
>> download binary release to play with the groovy
>> all-in-one configuration.
>>
>> Anonymous CVS access:
>> CVSROOT=":pserver:anoncvs@devel.priocom.com:/export/cvsroot/jamesng"
>> anoncvs user has empty password
>>
>> FishEye (like viewcvs but better and in java)
>> http://devel.priocom.com:8083/viewrep/JamesNG
>> You can also download the latest cvs checkout tarball at
>>
>> http://devel.priocom.com:8083/viewrep/~tarball=tgz/JamesNG/JamesNG.tgz
>>
>> As steps further steps to develop apache james i propose:
>> - create a new branch in svn called "JAMES_NG" or the like
>> - give up using avalon container in this branch
>> - either use one of the existing CDI containers (picocontainer) or
>> accept proposed groovy-based config files
>> - merge smtp/mailer/mailet code into JAMES_NG branch
>> - use the branch as a basis for James v3
>>
>> Any ideas?
>> Flames?
>> What is wrong with my approach?
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
>
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [James-NG] Avalon-free James proposal and reference implementation
Posted by Danny Angus <da...@gmail.com>.
> I am new to the list. I see that avalon dependency received couple of
> critics on the list. Why is avalon 'bad'
Because the Avalon projecty has closed.
And James has always had problems responding to changes being driven
in by Avalon.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [James-NG] Avalon-free James proposal and reference implementation
Posted by Laszlo Hornyak <ko...@forgeahead.hu>.
Hi!
I am new to the list. I see that avalon dependency received couple of
critics on the list. Why is avalon 'bad' and what is the intention of
the james team with this?
Laszlo
Alexander Zhukov wrote:
> Hi, James hackers!
>
> Recently on the mailing list I saw messages of departure from
> avalon-based container
> So i decided to propose my ideas and reference implementation as a
> basis of next generation james
> (i hope avalon-free version) which i propose to call jamesng
>
> nice points in jamesng for apache james are:
> - components are independent POJOs (CDI IoC) so no funky
> interface has to be implemented to extend james-ng
> (see COMPONENTS)
> - single file groovy-based configuration
> - multiple domains support from the ground up
> - adaptable user stores (enterprise does not want to change its
> db/ldap directory/whatever) (see ENTERPRISE DB)
> - javax.mail.Store/Folder based mail repositories support
> hierarhical folders, tested with Maildir and mbox providers
> (see STORES)
> - extensive support for folder/store/user caching to speed-up
> servers (see CACHING)
> - imap4 support (not complete but usable)
> - pop3 support
> - independent components can be easily added and integrated into
> build system
>
> things laking:
> - smtp support - no spooling/remote deliveries, working on it
> right now
>
> ENTERPRISE DB
> server is large ISP/enterprise targeted which means
> - support for multiple domains on a single/multiple IP addresses,
> - highly configurable user stores - database should not be designed
> for use with james (as it is with current james)
> but rather user store adapts to the existing userstores of an
> isp/enterprise.
> Often enterprises already have their user databases often they contain
> legacy elements which such companies
> just very much hesitate to change to something new.
> Above mentioned is very much true for LDAP directories - you cannot
> expect an enterprise to change its
> LDAP directory to fit james in
>
> COMPONENTS
> All components of james-ng are POJOs no component _must_ implement
> some funky interface to be included in the server.
> Components adhere CDI style IoC which besides other advantages allows
> configuration to be a single groovy file.
> The task of groovy configuration is to assemble all components together.
>
> STORES
> Mail stores (repositories) are plain javax.mail.Store providers.
> Since javax.mail.Folder interface supports hierarchy james-ng gets
> "free" IMAP support - no need to reengineer mail
> repository to access folders/sub-folders. However to support all of
> IMAP features such provider's Folder implementation
> must as well implement UIDFolder interface to support IMAP UID
> operations.
> For now tested are Maildir and mbox providers, but apparently nothing
> prevents to write/use existing jdbc providers
> that would store mails in database.
> Simple groovy-based configuration allows administrator to configure
> different types of stores for different users.
>
> CACHING
> I am currently in charge of rather large (150k+ users) free webmail
> with multiple domains
> and i dont have very new and high-performing hardware to host it so i
> designed the server for performance.
> The main point is to avoid unproductive waste of performance (very
> much true for most unix mail servers)
> stores/folders opened by users as well as user objects are cached
> (certainly you can turn the cache off) instead of being
> open on every user login. Very much helps for polling clients which
> disconnect and connect back in 10 minutes.
> Administrator can adjust the caching policy, for now implemented are
> LRUCache and GCCache (reference map based cache).
>
> If you are reading this then you are ready to see what does jamesng
> look like.
> Since the codebase is pretty large for an attachment to email I have
> setup cvs repostitory as well as source release repository.
>
> Source release:
> http://devel.priocom.com/jamesng/jamesng-20050130-src.tar.gz
> Binary release
> http://devel.priocom.com/jamesng/jamesng-20050130.tar.gz
>
> I suggest you download source release and build binary release or just
> download binary release to play with the groovy
> all-in-one configuration.
>
> Anonymous CVS access:
> CVSROOT=":pserver:anoncvs@devel.priocom.com:/export/cvsroot/jamesng"
> anoncvs user has empty password
>
> FishEye (like viewcvs but better and in java)
> http://devel.priocom.com:8083/viewrep/JamesNG
> You can also download the latest cvs checkout tarball at
>
> http://devel.priocom.com:8083/viewrep/~tarball=tgz/JamesNG/JamesNG.tgz
>
> As steps further steps to develop apache james i propose:
> - create a new branch in svn called "JAMES_NG" or the like
> - give up using avalon container in this branch
> - either use one of the existing CDI containers (picocontainer) or
> accept proposed groovy-based config files
> - merge smtp/mailer/mailet code into JAMES_NG branch
> - use the branch as a basis for James v3
>
> Any ideas?
> Flames?
> What is wrong with my approach?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
Re: [James-NG] Avalon-free James proposal and reference implementation
Posted by Alexander Zhukov <zh...@ukrpost.net>.
Groovy is a scripting language with almost the same semantics as java
but extended to certain extent that allows a faster writting of config
scritps
The fact it is scripting language and _only_ configuration is written in
groovy gives administrator the possibility to change configuration
without recompiling java classes
configuration in jamesng and any CDI IoC application is not pure
name=value pairs or even xml like in james v2
it is more of a script with logic and method calls
which is both bad and good
bad: requires certain skills to configure
good: as flexible as java but does not require recompilation
If you know java your groovy learning curve is very short
check the groovy.codehaus.org
and additionaly the example of default config of jamesng
http://devel.priocom.com:8083/viewrep/JamesNG/container/src/groovy/DummyConfig.groovy?r=1.3
answering your question: pure java is good and i'd prefer jamesng to be
pure java application and it can be done like that, but groovy gives
more flexibility in configuration than either name=value pair properties
or xml files and it does not have to be compiled - easy for admins.
Steen Jansdal wrote:
> Why groovy?
>
> One of the things I like about James is it's use of
> pure Java. Does Groovy give us any advantage that
> Java doesn't ? Not many developers are familiar with
> groovy, so if it doesn't buy us anything significant
> I think we should avoid it.
>
> What I would like is the ability to debug James.
> With your favorite Java IDE it should be possible
> to single step thru the program, set breakpoints, etc.
>
> Steen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [James-NG] Avalon-free James proposal and reference implementation
Posted by Alexander Zhukov <zh...@ukrpost.net>.
Three to four month ago, before I looked into groovy, I would agree with
you completely and say - "groovy go away".
I invite you to look at configuration examples in groovy and you'll
understand its more understandable than xml and more flexible since flow
programming in xml is very much complicated and everybody has to invent
his own brand new xml format for the job.
Groovy has the same syntax as java and runs ontop of java - no need to
learn something new, while jython has python syntax which pretty
different to that of java.
Ahmed Mohombe wrote:
>> One of the things I like about James is it's use of
>> pure Java.
>
> Me too.
>
> Please, I beg you, put no Groovy/JPython or other things like this in
> it. For Got sake, let JAMES be a JAVA project.
>
> Thank you,
>
> Ahmed.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [James-NG] Avalon-free James proposal and reference implementation
Posted by Hes Siemelink <he...@izecom.com>.
Serge Knystautas wrote:
>> But for the mailet config we should go with the XML we're used to.
>
>
> I've been going back and forth on this. The name/value pair is nice
> and simple, but we have some long-standing issues we could wipe away
> by moving to container driven configuration and away from our
> name/value XML stuff:
> - mailets and matchers could get dependent objects (instead of JNDI or
> Avalon lookups or any of that)
> - richer configuration (nested hierarchy for mailets and more than 1
> parameter for matchers)
> - mailet could be tied to a matcher's
There is also an option of redefining the XML. The curent XML schema is
quite awkward, but it could be redesigned to allow for more matcher
parameters for example.
Isn't the current XML configuration also a relic of the Avalon-way?
>> my 2c is that we should be delivering a set of service API's and
>> implementations which can be assembled into a mail server in any of
>> several containers, let the people who want to use the container
>> configure it using the container's own configuration mechanisms.
>
James could provide configuration POJOs to make it easier to configure
it in various ways.
I would like to configure (or even reconfigure!) using Java.
Other configurations could be derived from that.
I'm not too fond of using Groovy scripts, because for most people it
will be a new technology (unlike XML), and since it is a programming
language there is more room for errors.
IMHO the best way to go is to model configuration using Java POJOs in
the James core so it is easier to make up a new configuration technique.
The current XML format could be imrpoved, but is tried and tested, so it
is worthwile to stick with it for the time being.
Cheers,
Hes.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [James-NG] Avalon-free James proposal and reference implementation
Posted by Serge Knystautas <se...@lokitech.com>.
Danny Angus wrote:
>>Either we use groovy, use another container's XML construct to configure
>>James, or invent our own XML structure. What do you suggest?
>
> I would suggest that we use the relevant constructs for the
> container(s) we support.
> So we could prepare a Spring James distribution, a Phoenix James etc etc.
Ok, but not a groovy-as-container?
> But for the mailet config we should go with the XML we're used to.
I've been going back and forth on this. The name/value pair is nice and
simple, but we have some long-standing issues we could wipe away by
moving to container driven configuration and away from our name/value
XML stuff:
- mailets and matchers could get dependent objects (instead of JNDI or
Avalon lookups or any of that)
- richer configuration (nested hierarchy for mailets and more than 1
parameter for matchers)
- mailet could be tied to a matcher's
So, I kind of like removing the configuration part of our API (and
lifecycle for that matter), and just let the containers provide it with IoC.
> my 2c is that we should be delivering a set of service API's and
> implementations which can be assembled into a mail server in any of
> several containers, let the people who want to use the container
> configure it using the container's own configuration mechanisms.
Yeah, I think James becomes a bunch of POJO's is the main issue, and
then we have to figure out a recommended container we'll be using for
distribution. I cannot see us actually providing multiple container
support out-of-the-box.
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [James-NG] Avalon-free James proposal and reference implementation
Posted by Danny Angus <da...@gmail.com>.
> Either we use groovy, use another container's XML construct to configure
> James, or invent our own XML structure. What do you suggest?
I would suggest that we use the relevant constructs for the
container(s) we support.
So we could prepare a Spring James distribution, a Phoenix James etc etc.
But for the mailet config we should go with the XML we're used to.
my 2c is that we should be delivering a set of service API's and
implementations which can be assembled into a mail server in any of
several containers, let the people who want to use the container
configure it using the container's own configuration mechanisms.
But I don't think that is the whole story..
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [James-NG] Avalon-free James proposal and reference implementation
Posted by Alexander Zhukov <zh...@ukrpost.net>.
Ahmed Mohombe wrote:
> Serge Knystautas wrote:
>
>> Ahmed Mohombe wrote:
>>
>>>> One of the things I like about James is it's use of
>>>> pure Java.
>>>
>>> Me too.
>>>
>>> Please, I beg you, put no Groovy/JPython or other things like this in
>>> it. For Got sake, let JAMES be a JAVA project.
>>
>> Can you explain your objection, or at least clarify it since Groovy is
>> Java.
>
> IMHO Groovy is not Java. Just open a Groovy file in a modern IDE (e.g.
> IntelliJ) and tell me what support do you have for it?
>
>> Either we use groovy, use another container's XML construct to
>> configure James, or invent our own XML structure. What do you suggest?
>
> Isn't the Jakarta-commons Digester not good enough?
> Besides, what's so complicated to make a simple and verbose XML
> configuration (so that everyone understands it)?
> A simple XML structure can very easily get a simple Swing or Web GUI, so
> that everyone can edit/change the configuration without too many errors.
Ahmed! It starts to seem like a holy war :)
Let me clearify, as far as I understand your points are:
XML: knows everybody, which means it is good for config
Groovy: knows very small amount of people - bad
I would say you are right.
However you may havent appreciated the CDI approach to configuration,
basically it is ability to independently configure components and
provide flow (if-then-else, for, etc.) control over the configuration.
In configuration everybody is used to you control data while in CDI IoC
approach to configuration you control _components_ which are _Java objects_.
I would say the best thing to manipulate Java objects is Java language,
right?
But configuration has to be available to admin. And, unlike developers,
admins dont like to use compilers (especially javac :)) to configure
their servers.
So the natural approach is scripted java that does not have to be
compiled - my choice is groovy - the most java-like, standards compliant
(they have JSR for it) language.
You are not required to use groovy to glue components - you can do it in
Java or any other language. XML can also be used to manipulate java
objects but it is not very much suited for it.
To summarize:
Java/Groovy: manipulates Java objects - good for CDI IoC config
XML: not very much suited to manipulate Java objects - not very
comfortable but still you can develop and easily replace my groovy
config with xml-based config that would manipulate Java objects and you
are welcome to do it, but believe me if you look into groovy and how it
fits into the big picture of CDI IoC and jamesng reference
implementation you'll appreciate it.
PS. no i dont have any income on saling groovy :)
> Just my 2 cents,
>
> Ahmed.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [James-NG] Avalon-free James proposal and reference implementation
Posted by Ahmed Mohombe <am...@yahoo.com>.
> I think we're talking different levels.
Only if "the use of containers" is already "nailed down", and there's no
way "without containers" :).
> Basically we're heading towards
> James as a collection of PoJo's,
Hmm, I've always thought of: a "collection of PoJos for James" :).
> and then we're talking about the ideal
> container for James.
If it's only about deciding what container to use, maybe it might help
by asking the opinion on the different container user lists.
The authors/community of the different containers can better answer if
their container can do(with minimal effort from our side) what we would
need for James.
> My preference would be for a container that does hot-loading, supports
> splitting configuration into multiple files, and doesn't require us to
> care about what file made the change and appropriately hot-reload only
> the parts that need to be reloaded.
I'm not aware of a container that fulfills all the requirements you
described, it's very stable, and adds no complexity for the user :).
Ahmed.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [James-NG] Avalon-free James proposal and reference implementation
Posted by Serge Knystautas <se...@lokitech.com>.
Ahmed Mohombe wrote:
> Like Phoenix? If I'm not wrong, for most of the important changes I make
> now in the james config, I still need to restart it.
> I've seen no "real hot-reloading" "out of the box" till yet.
>
> IMHO, instead of the so called "hot-reloading", a simple "instruction"
> in the "James-Admin" to reload the config file (if the admin wants that
> - cause he changed the config file") would be enough.
<snip />
> Well, IMHO there's nothing better than Log4J. Why to use another "layer"
> since log4J does the job very well (and most of them redirect to log4j
> anyway)?
Ah, irony. Yes, I'm well aware that Avalon's container framework has
not provided what James needs. :)
>> but Digester is really too simple to handle the complexities we need
>> (at least based on my experience using Digester).
>
> Hmm, I've always thought that "less is more" :). Besides, why must be
> the configuration of JAMES complex?.
James is complex because of what it is doing, not because of the
configuration tool, e.g., multiple socket servers, thread pools,
listeners, scheduling, dns servers, coexisting LDAP file AND JDBC users,
domain lists, different mail format stores, mail processors,
blacklisting and performance monitoring, etc...
The goal is to make configuration less complex as we scale, hence the
decision to use something like Groovy or Spring or Picocontainer,
etc..., rather than a simple tool that becomes unmanageable as
complexity grows.
Again, if you're only using a small piece of James, then someone could
use Digester to manage that.
> "Divide et Impera": put the config in more than one file. A simple one
> where most of the changes happen (this one could get a GUI/Wizard), and
> another one(or more), that need restart of the server anyway(with
> configs that might be very seldom changed).
I think we're talking different levels. Basically we're heading towards
James as a collection of PoJo's, and then we're talking about the ideal
container for James.
My preference would be for a container that does hot-loading, supports
splitting configuration into multiple files, and doesn't require us to
care about what file made the change and appropriately hot-reload only
the parts that need to be reloaded.
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [James-NG] Avalon-free James proposal and reference implementation
Posted by Hes Siemelink <he...@izecom.com>.
Ahmed Mohombe wrote:
> "Divide et Impera": put the config in more than one file. A simple one
> where most of the changes happen (this one could get a GUI/Wizard),
> and another one(or more), that need restart of the server anyway(with
> configs that might be very seldom changed).
Good idea.
But please let's not use XML entity reference as an 'include' mechanism.
It is confusing and error-prone.
It's better to have well-named and well-formed XML-files.
Cheers,
Hes.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [James-NG] Avalon-free James proposal and reference implementation
Posted by Gabor Kincses <np...@yahoo.com>.
--- Ahmed Mohombe <am...@yahoo.com> wrote:
[snip]
>
> > Containers provide hot-reloading and
> Like Phoenix? If I'm not wrong, for most of the
> important changes I make
> now in the james config, I still need to restart it.
> I've seen no "real hot-reloading" "out of the box"
> till yet.
>
> IMHO, instead of the so called "hot-reloading", a
> simple "instruction"
> in the "James-Admin" to reload the config file (if
> the admin wants that
> - cause he changed the config file") would be
> enough.
>
> > maybe logging if nothing else.
> Well, IMHO there's nothing better than Log4J. Why to
> use another "layer"
> since log4J does the job very well (and most of them
> redirect to log4j
> anyway)?
The people implementing UGLI would beg to differ...
Gabor
=====
Gabor Kincses
Running Mandrake Linux 10.0
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [James-NG] Avalon-free James proposal and reference implementation
Posted by Ahmed Mohombe <am...@yahoo.com>.
> I was just pointing out that the decision to use Groovy has no Java
> alternative. Instead of a Groovy file, you'd use an XML file, or a
> database table, or whatever. Groovy is nice in that it is like/based on
> Java, as opposed to XML which is entirely another beast.
Everybody knows XML, and if the structure is well designed (+ a DTD),
than there's no need to learn something.
> Containers provide hot-reloading and
Like Phoenix? If I'm not wrong, for most of the important changes I make
now in the james config, I still need to restart it.
I've seen no "real hot-reloading" "out of the box" till yet.
IMHO, instead of the so called "hot-reloading", a simple "instruction"
in the "James-Admin" to reload the config file (if the admin wants that
- cause he changed the config file") would be enough.
> maybe logging if nothing else.
Well, IMHO there's nothing better than Log4J. Why to use another "layer"
since log4J does the job very well (and most of them redirect to log4j
anyway)?
> but Digester is really too simple to handle the
> complexities we need (at least based on my experience using Digester).
Hmm, I've always thought that "less is more" :). Besides, why must be
the configuration of JAMES complex?.
"Divide et Impera": put the config in more than one file. A simple one
where most of the changes happen (this one could get a GUI/Wizard), and
another one(or more), that need restart of the server anyway(with
configs that might be very seldom changed).
Ahmed.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [James-NG] Avalon-free James proposal and reference implementation
Posted by Serge Knystautas <se...@lokitech.com>.
Ahmed Mohombe wrote:
>>> Please, I beg you, put no Groovy/JPython or other things like this in
>>> it. For Got sake, let JAMES be a JAVA project.
>>
>> Can you explain your objection, or at least clarify it since Groovy is
>> Java.
>
> IMHO Groovy is not Java. Just open a Groovy file in a modern IDE (e.g.
> IntelliJ) and tell me what support do you have for it?
That's a largely strawman argument. You say you don't want groovy
because you want a Java, but apparently want to use XML (another
not-Java technology) for it. If your argument is that Groovy has less
IDE support than XML, and less support in general, I wouldn't dispute that.
I was just pointing out that the decision to use Groovy has no Java
alternative. Instead of a Groovy file, you'd use an XML file, or a
database table, or whatever. Groovy is nice in that it is like/based on
Java, as opposed to XML which is entirely another beast.
>> Either we use groovy, use another container's XML construct to
>> configure James, or invent our own XML structure. What do you suggest?
>
> Isn't the Jakarta-commons Digester not good enough?
> Besides, what's so complicated to make a simple and verbose XML
> configuration (so that everyone understands it)?
> A simple XML structure can very easily get a simple Swing or Web GUI, so
> that everyone can edit/change the configuration without too many errors.
Containers provide hot-reloading and maybe logging if nothing else. I
think someone might want to use JamesNG SMTP socket server or mail store
using Digester, but Digester is really too simple to handle the
complexities we need (at least based on my experience using Digester).
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [James-NG] Avalon-free James proposal and reference implementation
Posted by Gabor Kincses <np...@yahoo.com>.
You seem to be describing a different container style,
like Phoenix or Spring. That should largely be
immaterial to the James core.
Except for object lifecycle management. Lightweight
(non-intrusive) containers have little lifecycle
management (picocontainer e.g. has start(), stop() and
dispose()). The differences in lifecycle management
should be isolated in container dependent lifecycle
management adaptors.
The Groovyscript seems to be done. Pick your favorite
container and write the configurator for it. I
personally use/like picocontainer. Given the current
architecture of James, main can be written with a
MutablePicoContainer in place of groovyscript.
BYO(DPI)C. Bring your own (dependency-injection)
container.
Gabor
--- Ahmed Mohombe <am...@yahoo.com> wrote:
> Serge Knystautas wrote:
> > Ahmed Mohombe wrote:
> >
> >>> One of the things I like about James is it's use
> of
> >>> pure Java.
> >>
> >>
> >> Me too.
> >>
> >> Please, I beg you, put no Groovy/JPython or other
> things like this in
> >> it. For Got sake, let JAMES be a JAVA project.
> >
> >
> > Can you explain your objection, or at least
> clarify it since Groovy is
> > Java.
> IMHO Groovy is not Java. Just open a Groovy file in
> a modern IDE (e.g.
> IntelliJ) and tell me what support do you have for
> it?
>
> > Either we use groovy, use another container's XML
> construct to configure
> > James, or invent our own XML structure. What do
> you suggest?
> Isn't the Jakarta-commons Digester not good enough?
> Besides, what's so complicated to make a simple and
> verbose XML
> configuration (so that everyone understands it)?
> A simple XML structure can very easily get a simple
> Swing or Web GUI, so
> that everyone can edit/change the configuration
> without too many errors.
>
> Just my 2 cents,
>
> Ahmed.
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail:
> server-dev-help@james.apache.org
>
>
=====
Gabor Kincses
Running Mandrake Linux 10.0
__________________________________
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [James-NG] Avalon-free James proposal and reference implementation
Posted by Ahmed Mohombe <am...@yahoo.com>.
Serge Knystautas wrote:
> Ahmed Mohombe wrote:
>
>>> One of the things I like about James is it's use of
>>> pure Java.
>>
>>
>> Me too.
>>
>> Please, I beg you, put no Groovy/JPython or other things like this in
>> it. For Got sake, let JAMES be a JAVA project.
>
>
> Can you explain your objection, or at least clarify it since Groovy is
> Java.
IMHO Groovy is not Java. Just open a Groovy file in a modern IDE (e.g.
IntelliJ) and tell me what support do you have for it?
> Either we use groovy, use another container's XML construct to configure
> James, or invent our own XML structure. What do you suggest?
Isn't the Jakarta-commons Digester not good enough?
Besides, what's so complicated to make a simple and verbose XML
configuration (so that everyone understands it)?
A simple XML structure can very easily get a simple Swing or Web GUI, so
that everyone can edit/change the configuration without too many errors.
Just my 2 cents,
Ahmed.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [James-NG] Avalon-free James proposal and reference implementation
Posted by Serge Knystautas <se...@lokitech.com>.
Ahmed Mohombe wrote:
>> One of the things I like about James is it's use of
>> pure Java.
>
> Me too.
>
> Please, I beg you, put no Groovy/JPython or other things like this in
> it. For Got sake, let JAMES be a JAVA project.
Can you explain your objection, or at least clarify it since Groovy is Java.
Either we use groovy, use another container's XML construct to configure
James, or invent our own XML structure. What do you suggest?
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [James-NG] Avalon-free James proposal and reference implementation
Posted by Ahmed Mohombe <am...@yahoo.com>.
> One of the things I like about James is it's use of
> pure Java.
Me too.
Please, I beg you, put no Groovy/JPython or other things like this in
it. For Got sake, let JAMES be a JAVA project.
Thank you,
Ahmed.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [James-NG] Avalon-free James proposal and reference implementation
Posted by Steen Jansdal <st...@jansdal.dk>.
Why groovy?
One of the things I like about James is it's use of
pure Java. Does Groovy give us any advantage that
Java doesn't ? Not many developers are familiar with
groovy, so if it doesn't buy us anything significant
I think we should avoid it.
What I would like is the ability to debug James.
With your favorite Java IDE it should be possible
to single step thru the program, set breakpoints, etc.
Steen
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[James-NG] JamesNG confluence pages + CDI IoC Quick Start Guide
Posted by Alexander Zhukov <zh...@ukrpost.net>.
Hi all!
I have a created a confluence space for JamesNG.
And posted simple CDI IoC Quick Start Guide
http://devel.priocom.com:8081/display/JamesNG/CDI+IoC+Quick+Start+Guide
In the article I try to explain
- what is CDI IoC
- why configuration is not what you are used to in CDI IoC style
- how configuration is concentrated in a single point
I invite everyone to check it out and say what you think or correct me.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [James-NG] Avalon-free James proposal and reference implementation
Posted by Alexander Zhukov <zh...@ukrpost.net>.
Serge Knystautas wrote:
> I have a textfile on my desktop with the same name. Comments below.
Really glad about it :)
>
> Alexander Zhukov wrote:
>
>> Hi, James hackers!
>>
>> Recently on the mailing list I saw messages of departure from
>> avalon-based container
>> So i decided to propose my ideas and reference implementation as a
>> basis of next generation james
>> (i hope avalon-free version) which i propose to call jamesng
>>
>> nice points in jamesng for apache james are:
>> - components are independent POJOs (CDI IoC) so no funky
>> interface has to be implemented to extend james-ng
>> (see COMPONENTS)
>
>
> +1
>
>> - single file groovy-based configuration
>
>
> I prefer spring, but whatever.
>
>> - multiple domains support from the ground up
> You'd have to explain how this works, since SMTP is no-brainer, and POP3
> would not support it. Basically this is largely a function of account
> name mappers, but would need to be fleshed out.
POP3 Example 1:
user joe
+ok enter password
pass mypass
+ok joe@default.domain.com authenticated
POP3 Example 2:
user joe@virtual.com
+ok enter password
pass otherpass
+ok joe@virutal.com authenticated
joe@default.domain.com and joe@virtual.com are completely different joes
(configurable) that may have different storage type (maildir, mbox,
etc.) and authenticate against different userstores (unix /etc/passwd
authentication, LDAP, whatever userstore you write)
userid always has a domain part
by default the domain part equals to the hostname of your machine
Yes you have to tell your Outlook users to type joe@virtual.com instead
of just joe in the Login box. But you can configure the default domain
to be not your machines hostname but rather "virtual.com" and all
default-no-domain joes will be mapped to joe@virtual.com
Is this approach wrong?
>
>> - adaptable user stores (enterprise does not want to change its
>> db/ldap directory/whatever) (see ENTERPRISE DB)
>> - javax.mail.Store/Folder based mail repositories support
>> hierarhical folders, tested with Maildir and mbox providers
>> (see STORES)
> I tried this at one point, but hit some problems for some reason. There
> are discussions in the mail archive about this.
Well it depends on the store providers you use. Definitely you'll have
problems if the provider is written from the client perspective.
>
>> - extensive support for folder/store/user caching to speed-up
>> servers (see CACHING)
>> - imap4 support (not complete but usable)
>> - pop3 support
>> - independent components can be easily added and integrated into
>> build system
>>
>> things laking:
>> - smtp support - no spooling/remote deliveries, working on it
>> right now
>
> smtp has always been what I was most focused on, and so I'd be curious
> in how this works. BTW, I would recommend quartz for scheduling.
smtp integration is my priority number one
quartz agreed, no problems
> Also NNTP is gone, but that doesn't matter to me too much. I'd prefer
> this reduction in James' scope if we were to redo everything.
I know nothing about NNTP (no experience) so if someone needs it they
are welcome to add support for it - no constraints are placed.
>
>> ENTERPRISE DB
>> server is large ISP/enterprise targeted which means
>> - support for multiple domains on a single/multiple IP addresses,
>> - highly configurable user stores - database should not be designed
>> for use with james (as it is with current james)
>> but rather user store adapts to the existing userstores of an
>> isp/enterprise.
>> Often enterprises already have their user databases often they contain
>> legacy elements which such companies
>> just very much hesitate to change to something new.
>> Above mentioned is very much true for LDAP directories - you cannot
>> expect an enterprise to change its
>> LDAP directory to fit james in
>
> All sounds fine, as long as you have something that also is available
> and setup out of the box.
Good point. For the out-of-the-box part we can use James v2 db/ldap schema.
>> COMPONENTS
>> All components of james-ng are POJOs no component _must_ implement
>> some funky interface to be included in the server.
>> Components adhere CDI style IoC which besides other advantages allows
>> configuration to be a single groovy file.
>> The task of groovy configuration is to assemble all components together.
>
> Huge +1, except the groovy part, since as I say, I prefer Spring.
Spring is a container, for now the configuration and amount of
components is not too large to use container (arguable). So I decided a
single groovy script would be fine.
> I also love groovy and use it wherever I had been considering
> Python/bash scripting and think very highly of it. I'm just curious how
> you use it for configuration.
Please refer to
http://devel.priocom.com:8083/viewrep/JamesNG/container/src/groovy/DummyConfig.groovy?r=1.3
for an example of default dummy configuration in a single groovy script
assembling, configuring and starting all necessary components.
>
>> STORES
>> Mail stores (repositories) are plain javax.mail.Store providers.
>> Since javax.mail.Folder interface supports hierarchy james-ng gets
>> "free" IMAP support - no need to reengineer mail
>> repository to access folders/sub-folders. However to support all of
>> IMAP features such provider's Folder implementation
>> must as well implement UIDFolder interface to support IMAP UID
>> operations.
>> For now tested are Maildir and mbox providers, but apparently nothing
>> prevents to write/use existing jdbc providers
>> that would store mails in database.
>> Simple groovy-based configuration allows administrator to configure
>> different types of stores for different users.
>
>
> Errr... nothing is free. There would be a bunch of work to get this
> implemented and working solidly for the jdbc providers. I'm curious
> about the licensing of the maildir and mbox providers you're using.
Maildir is javamaildir (javamaildir.sf.net) written by me and licensed
to apache james to use in a way you like :)
Mbox is weeeell modified GNU mbox provider (I know its GPL but maybe we
can try to convience Chris Burdess to license it for James)
I would volunteer to start work on JDBC provider since I have some
experience writing providers.
>
>> CACHING
>> I am currently in charge of rather large (150k+ users) free webmail
>> with multiple domains
>> and i dont have very new and high-performing hardware to host it so i
>> designed the server for performance.
>> The main point is to avoid unproductive waste of performance (very
>> much true for most unix mail servers)
>> stores/folders opened by users as well as user objects are cached
>> (certainly you can turn the cache off) instead of being
>> open on every user login. Very much helps for polling clients which
>> disconnect and connect back in 10 minutes.
>> Administrator can adjust the caching policy, for now implemented are
>> LRUCache and GCCache (reference map based cache).
>
> So is this a new caching API, or I guess I'm asking, can you swap our
> caching providers so you could use EHCache or OSCache?
No problem, it is just a statement that cache is there and stores are
not reopened on every use authentication.
I bet my caching api is easily replaced by more advanced caches out
there and since i am not an expert in caches i would prefer it replaced.
>
>> If you are reading this then you are ready to see what does jamesng
>> look like.
>> Since the codebase is pretty large for an attachment to email I have
>> setup cvs repostitory as well as source release repository.
>>
>> Source release:
>> http://devel.priocom.com/jamesng/jamesng-20050130-src.tar.gz
>> Binary release
>> http://devel.priocom.com/jamesng/jamesng-20050130.tar.gz
>
>
> My third kid just turned 2 weeks old, so I can't say when I'll have time
> to review the source, but this is very exciting.
You can check the groovy configuration examples available at
http://devel.priocom.com:8083/viewrep/JamesNG/container/src/groovy
>
>> Any ideas?
>> Flames?
>> What is wrong with my approach?
>
>
> Open source projects are made by the people who show up. I think you're
> taking a good approach, both technically and politically. This isn't
> going to be an easy change, but I think it's the right one and we need
> someone to can champion this.
Thanks a lot for your reply
It was my more than 2 year long goal to improve james substantialy
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [James-NG] Avalon-free James proposal and reference implementation
Posted by Serge Knystautas <se...@lokitech.com>.
I have a textfile on my desktop with the same name. Comments below.
Alexander Zhukov wrote:
> Hi, James hackers!
>
> Recently on the mailing list I saw messages of departure from
> avalon-based container
> So i decided to propose my ideas and reference implementation as a basis
> of next generation james
> (i hope avalon-free version) which i propose to call jamesng
>
> nice points in jamesng for apache james are:
> - components are independent POJOs (CDI IoC) so no funky
> interface has to be implemented to extend james-ng
> (see COMPONENTS)
+1
> - single file groovy-based configuration
I prefer spring, but whatever.
> - multiple domains support from the ground up
You'd have to explain how this works, since SMTP is no-brainer, and POP3
would not support it. Basically this is largely a function of account
name mappers, but would need to be fleshed out.
> - adaptable user stores (enterprise does not want to change its
> db/ldap directory/whatever) (see ENTERPRISE DB)
> - javax.mail.Store/Folder based mail repositories support
> hierarhical folders, tested with Maildir and mbox providers
> (see STORES)
I tried this at one point, but hit some problems for some reason. There
are discussions in the mail archive about this.
> - extensive support for folder/store/user caching to speed-up
> servers (see CACHING)
> - imap4 support (not complete but usable)
> - pop3 support
> - independent components can be easily added and integrated into
> build system
>
> things laking:
> - smtp support - no spooling/remote deliveries, working on it
> right now
smtp has always been what I was most focused on, and so I'd be curious
in how this works. BTW, I would recommend quartz for scheduling.
Also NNTP is gone, but that doesn't matter to me too much. I'd prefer
this reduction in James' scope if we were to redo everything.
> ENTERPRISE DB
> server is large ISP/enterprise targeted which means
> - support for multiple domains on a single/multiple IP addresses,
> - highly configurable user stores - database should not be designed for
> use with james (as it is with current james)
> but rather user store adapts to the existing userstores of an
> isp/enterprise.
> Often enterprises already have their user databases often they contain
> legacy elements which such companies
> just very much hesitate to change to something new.
> Above mentioned is very much true for LDAP directories - you cannot
> expect an enterprise to change its
> LDAP directory to fit james in
All sounds fine, as long as you have something that also is available
and setup out of the box.
> COMPONENTS
> All components of james-ng are POJOs no component _must_ implement some
> funky interface to be included in the server.
> Components adhere CDI style IoC which besides other advantages allows
> configuration to be a single groovy file.
> The task of groovy configuration is to assemble all components together.
Huge +1, except the groovy part, since as I say, I prefer Spring.
I also love groovy and use it wherever I had been considering
Python/bash scripting and think very highly of it. I'm just curious how
you use it for configuration.
> STORES
> Mail stores (repositories) are plain javax.mail.Store providers.
> Since javax.mail.Folder interface supports hierarchy james-ng gets
> "free" IMAP support - no need to reengineer mail
> repository to access folders/sub-folders. However to support all of IMAP
> features such provider's Folder implementation
> must as well implement UIDFolder interface to support IMAP UID operations.
> For now tested are Maildir and mbox providers, but apparently nothing
> prevents to write/use existing jdbc providers
> that would store mails in database.
> Simple groovy-based configuration allows administrator to configure
> different types of stores for different users.
Errr... nothing is free. There would be a bunch of work to get this
implemented and working solidly for the jdbc providers. I'm curious
about the licensing of the maildir and mbox providers you're using.
> CACHING
> I am currently in charge of rather large (150k+ users) free webmail with
> multiple domains
> and i dont have very new and high-performing hardware to host it so i
> designed the server for performance.
> The main point is to avoid unproductive waste of performance (very much
> true for most unix mail servers)
> stores/folders opened by users as well as user objects are cached
> (certainly you can turn the cache off) instead of being
> open on every user login. Very much helps for polling clients which
> disconnect and connect back in 10 minutes.
> Administrator can adjust the caching policy, for now implemented are
> LRUCache and GCCache (reference map based cache).
So is this a new caching API, or I guess I'm asking, can you swap our
caching providers so you could use EHCache or OSCache?
> If you are reading this then you are ready to see what does jamesng look
> like.
> Since the codebase is pretty large for an attachment to email I have
> setup cvs repostitory as well as source release repository.
>
> Source release:
> http://devel.priocom.com/jamesng/jamesng-20050130-src.tar.gz
> Binary release
> http://devel.priocom.com/jamesng/jamesng-20050130.tar.gz
My third kid just turned 2 weeks old, so I can't say when I'll have time
to review the source, but this is very exciting.
> Any ideas?
> Flames?
> What is wrong with my approach?
Open source projects are made by the people who show up. I think you're
taking a good approach, both technically and politically. This isn't
going to be an easy change, but I think it's the right one and we need
someone to can champion this.
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [James-NG] Avalon-free James proposal and reference implementation
Posted by Alexander Zhukov <zh...@ukrpost.net>.
Gabor Kincses wrote:
> Does using groovy mean using nanocontainer as well?
> Lightweight containers are great. I personally think
> constructor dependency injection is the right way to
> go.
Jamesng is just an attempt to move james away from avalon, for now the
configuration and amount of components is not too large to use
nanocontainer.
So I decided to use a single groovy script to integrate all components
together. Well I have to say it is becoming more complex so maybe we
should move to nanocontainer, but for now i dont use it.
Any suggestions, code contributions are welcome.
Check out the DummyConfig.groovy (the default config for the jamesng
using DummyUserStore and maildir as storage) to see for yourself how all
components are assembled, configured and started.
http://devel.priocom.com:8083/viewrep/JamesNG/container/src/groovy/DummyConfig.groovy?r=1.3
Answering your question: yes, lightweight containers are great and
nanocontainer is great as well, but the configuration is so lightweight
for now that even nanocontainer seems to be an overkill.
You are more than welcome to prove me wrong.
>
> Thanks,
> Gabor
>
> --- Alexander Zhukov <zh...@ukrpost.net> wrote:
>
>
>>Hi, James hackers!
>>
>>Recently on the mailing list I saw messages of
>>departure from
>>avalon-based container
>>So i decided to propose my ideas and reference
>>implementation as a basis
>>of next generation james
>>(i hope avalon-free version) which i propose to call
>>jamesng
>>
>>nice points in jamesng for apache james are:
>> - components are independent POJOs (CDI IoC) so no
>>funky
>> interface has to be implemented to extend
>>james-ng
>> (see COMPONENTS)
>> - single file groovy-based configuration
>> - multiple domains support from the ground up
>> - adaptable user stores (enterprise does not want
>>to change its
>> db/ldap directory/whatever) (see
>>ENTERPRISE DB)
>> - javax.mail.Store/Folder based mail repositories
>>support
>> hierarhical folders, tested with Maildir
>>and mbox providers
>> (see STORES)
>> - extensive support for folder/store/user caching
>>to speed-up
>> servers (see CACHING)
>> - imap4 support (not complete but usable)
>> - pop3 support
>> - independent components can be easily added and
>>integrated into
>> build system
>>
>>things laking:
>> - smtp support - no spooling/remote deliveries,
>>working on it
>> right now
>>
>>ENTERPRISE DB
>>server is large ISP/enterprise targeted which means
>>- support for multiple domains on a single/multiple
>>IP addresses,
>>- highly configurable user stores - database should
>>not be designed for
>>use with james (as it is with current james)
>>but rather user store adapts to the existing
>>userstores of an
>>isp/enterprise.
>>Often enterprises already have their user databases
>>often they contain
>>legacy elements which such companies
>>just very much hesitate to change to something new.
>>Above mentioned is very much true for LDAP
>>directories - you cannot
>>expect an enterprise to change its
>>LDAP directory to fit james in
>>
>>COMPONENTS
>>All components of james-ng are POJOs no component
>>_must_ implement some
>>funky interface to be included in the server.
>>Components adhere CDI style IoC which besides other
>>advantages allows
>>configuration to be a single groovy file.
>>The task of groovy configuration is to assemble all
>>components together.
>>
>>STORES
>>Mail stores (repositories) are plain
>>javax.mail.Store providers.
>>Since javax.mail.Folder interface supports hierarchy
>>james-ng gets
>>"free" IMAP support - no need to reengineer mail
>>repository to access folders/sub-folders. However to
>>support all of IMAP
>>features such provider's Folder implementation
>>must as well implement UIDFolder interface to
>>support IMAP UID operations.
>>For now tested are Maildir and mbox providers, but
>>apparently nothing
>>prevents to write/use existing jdbc providers
>>that would store mails in database.
>>Simple groovy-based configuration allows
>>administrator to configure
>>different types of stores for different users.
>>
>>CACHING
>>I am currently in charge of rather large (150k+
>>users) free webmail with
>>multiple domains
>>and i dont have very new and high-performing
>>hardware to host it so i
>>designed the server for performance.
>>The main point is to avoid unproductive waste of
>>performance (very much
>>true for most unix mail servers)
>>stores/folders opened by users as well as user
>>objects are cached
>>(certainly you can turn the cache off) instead of
>>being
>>open on every user login. Very much helps for
>>polling clients which
>>disconnect and connect back in 10 minutes.
>>Administrator can adjust the caching policy, for now
>>implemented are
>>LRUCache and GCCache (reference map based cache).
>>
>>If you are reading this then you are ready to see
>>what does jamesng look
>>like.
>>Since the codebase is pretty large for an attachment
>>to email I have
>>setup cvs repostitory as well as source release
>>repository.
>>
>>Source release:
>>
>
> http://devel.priocom.com/jamesng/jamesng-20050130-src.tar.gz
>
>>Binary release
>>
>
> http://devel.priocom.com/jamesng/jamesng-20050130.tar.gz
>
>>I suggest you download source release and build
>>binary release or just
>>download binary release to play with the groovy
>>all-in-one configuration.
>>
>>Anonymous CVS access:
>>
>>
>
> CVSROOT=":pserver:anoncvs@devel.priocom.com:/export/cvsroot/jamesng"
>
>> anoncvs user has empty password
>>
>>FishEye (like viewcvs but better and in java)
>> http://devel.priocom.com:8083/viewrep/JamesNG
>> You can also download the latest cvs checkout
>>tarball at
>>
>>
>
> http://devel.priocom.com:8083/viewrep/~tarball=tgz/JamesNG/JamesNG.tgz
>
>>As steps further steps to develop apache james i
>>propose:
>> - create a new branch in svn called "JAMES_NG"
>>or the like
>> - give up using avalon container in this branch
>> - either use one of the existing CDI containers
>>(picocontainer) or
>>accept proposed groovy-based config files
>> - merge smtp/mailer/mailet code into JAMES_NG
>>branch
>> - use the branch as a basis for James v3
>>
>>Any ideas?
>>Flames?
>>What is wrong with my approach?
>>
>>
>>
>
> ---------------------------------------------------------------------
>
>>To unsubscribe, e-mail:
>>server-dev-unsubscribe@james.apache.org
>>For additional commands, e-mail:
>>server-dev-help@james.apache.org
>>
>>
>
>
>
> =====
> Gabor Kincses
> Running Mandrake Linux 10.0
>
>
>
> __________________________________
> Do you Yahoo!?
> The all-new My Yahoo! - Get yours free!
> http://my.yahoo.com
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [James-NG] Avalon-free James proposal and reference implementation
Posted by Alexander Zhukov <zh...@ukrpost.net>.
Jeremy Boynes wrote:
> Albert Kwong wrote:
>
>> Any consideration on using HiveMind as the container?
>>
>
> or ...
>
> <blatant-plug>
> Geronimo! - the low-level container/services not the J2EE manifestation
> </blatant-plug>
>
> On a serious note, with a good container & IoC design the effort should
> be in the application interfaces and the POJOs that implement them
> rather than in the container framework being used.
Very good point. Container itself doesnt matter if you use CDI IoC.
My jamesng uses a overly simplified container that is:
... main() {
clazz = GroovyClassLoader.parseClass(groovyconfighere);
script = clazz.newInstance
script.run()
}
>
> For example, ActiveMQ servers can be configured using either Spring and
> Geronimo depending on where they are being embedded. Standalone or
> generic configurations tend to use Spring whereas when used in Geronimo
> it integrates directly into the management framework (ok, so there's a
> bit of evangelical handwaving involved here).
>
> --
> Jeremy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [James-NG] Avalon-free James proposal and reference implementation
Posted by Alexander Zhukov <zh...@ukrpost.net>.
Danny Angus wrote:
>>On a serious note, with a good container & IoC design the effort should
>>be in the application interfaces and the POJOs that implement them
>>rather than in the container framework being used.
>
>
> Yep I agree with this.
>
> I think James would secure itself most against the future by
> developing a set of functional POJO's independant of any container.
>
> It would then be the responsibility of those who care to assemble them
> into a deployable entity for the container of their choice.
>
> James could maintain one or more of these deployment sub-projects so
> that we could always deliver a fully working solution, but we'd also
> be delivering mail server functionality which could be widely embedded
> and integrated into a vast range of systems.
Absolutely! Containers do not matter any more.
James-NG is just a collection of POJOs from independent projects plus a
groovy scripts that glues them all together
>
> d.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [James-NG] Avalon-free James proposal and reference implementation
Posted by Danny Angus <da...@gmail.com>.
> On a serious note, with a good container & IoC design the effort should
> be in the application interfaces and the POJOs that implement them
> rather than in the container framework being used.
Yep I agree with this.
I think James would secure itself most against the future by
developing a set of functional POJO's independant of any container.
It would then be the responsibility of those who care to assemble them
into a deployable entity for the container of their choice.
James could maintain one or more of these deployment sub-projects so
that we could always deliver a fully working solution, but we'd also
be delivering mail server functionality which could be widely embedded
and integrated into a vast range of systems.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [James-NG] Avalon-free James proposal and reference implementation
Posted by Jeremy Boynes <jb...@apache.org>.
Albert Kwong wrote:
> Any consideration on using HiveMind as the container?
>
or ...
<blatant-plug>
Geronimo! - the low-level container/services not the J2EE manifestation
</blatant-plug>
On a serious note, with a good container & IoC design the effort should
be in the application interfaces and the POJOs that implement them
rather than in the container framework being used.
For example, ActiveMQ servers can be configured using either Spring and
Geronimo depending on where they are being embedded. Standalone or
generic configurations tend to use Spring whereas when used in Geronimo
it integrates directly into the management framework (ok, so there's a
bit of evangelical handwaving involved here).
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [James-NG] Avalon-free James proposal and reference implementation
Posted by Albert Kwong <ma...@yahoo.com>.
Any consideration on using HiveMind as the container?
Albert
--- Gabor Kincses <np...@yahoo.com> 內容：
> Does using groovy mean using nanocontainer as well?
> Lightweight containers are great. I personally
> think
> constructor dependency injection is the right way to
> go.
>
> Thanks,
> Gabor
>
> --- Alexander Zhukov <zh...@ukrpost.net> wrote:
>
> > Hi, James hackers!
> >
> > Recently on the mailing list I saw messages of
> > departure from
> > avalon-based container
> > So i decided to propose my ideas and reference
> > implementation as a basis
> > of next generation james
> > (i hope avalon-free version) which i propose to
> call
> > jamesng
> >
> > nice points in jamesng for apache james are:
> > - components are independent POJOs (CDI IoC) so
> no
> > funky
> > interface has to be implemented to extend
> > james-ng
> > (see COMPONENTS)
> > - single file groovy-based configuration
> > - multiple domains support from the ground up
> > - adaptable user stores (enterprise does not want
> > to change its
> > db/ldap directory/whatever) (see
> > ENTERPRISE DB)
> > - javax.mail.Store/Folder based mail repositories
> > support
> > hierarhical folders, tested with
> Maildir
> > and mbox providers
> > (see STORES)
> > - extensive support for folder/store/user caching
> > to speed-up
> > servers (see CACHING)
> > - imap4 support (not complete but usable)
> > - pop3 support
> > - independent components can be easily added and
> > integrated into
> > build system
> >
> > things laking:
> > - smtp support - no spooling/remote deliveries,
> > working on it
> > right now
> >
> > ENTERPRISE DB
> > server is large ISP/enterprise targeted which
> means
> > - support for multiple domains on a
> single/multiple
> > IP addresses,
> > - highly configurable user stores - database
> should
> > not be designed for
> > use with james (as it is with current james)
> > but rather user store adapts to the existing
> > userstores of an
> > isp/enterprise.
> > Often enterprises already have their user
> databases
> > often they contain
> > legacy elements which such companies
> > just very much hesitate to change to something
> new.
> > Above mentioned is very much true for LDAP
> > directories - you cannot
> > expect an enterprise to change its
> > LDAP directory to fit james in
> >
> > COMPONENTS
> > All components of james-ng are POJOs no component
> > _must_ implement some
> > funky interface to be included in the server.
> > Components adhere CDI style IoC which besides
> other
> > advantages allows
> > configuration to be a single groovy file.
> > The task of groovy configuration is to assemble
> all
> > components together.
> >
> > STORES
> > Mail stores (repositories) are plain
> > javax.mail.Store providers.
> > Since javax.mail.Folder interface supports
> hierarchy
> > james-ng gets
> > "free" IMAP support - no need to reengineer mail
> > repository to access folders/sub-folders. However
> to
> > support all of IMAP
> > features such provider's Folder implementation
> > must as well implement UIDFolder interface to
> > support IMAP UID operations.
> > For now tested are Maildir and mbox providers, but
> > apparently nothing
> > prevents to write/use existing jdbc providers
> > that would store mails in database.
> > Simple groovy-based configuration allows
> > administrator to configure
> > different types of stores for different users.
> >
> > CACHING
> > I am currently in charge of rather large (150k+
> > users) free webmail with
> > multiple domains
> > and i dont have very new and high-performing
> > hardware to host it so i
> > designed the server for performance.
> > The main point is to avoid unproductive waste of
> > performance (very much
> > true for most unix mail servers)
> > stores/folders opened by users as well as user
> > objects are cached
> > (certainly you can turn the cache off) instead of
> > being
> > open on every user login. Very much helps for
> > polling clients which
> > disconnect and connect back in 10 minutes.
> > Administrator can adjust the caching policy, for
> now
> > implemented are
> > LRUCache and GCCache (reference map based cache).
> >
> > If you are reading this then you are ready to see
> > what does jamesng look
> > like.
> > Since the codebase is pretty large for an
> attachment
> > to email I have
> > setup cvs repostitory as well as source release
> > repository.
> >
> > Source release:
> >
>
http://devel.priocom.com/jamesng/jamesng-20050130-src.tar.gz
> > Binary release
> >
>
http://devel.priocom.com/jamesng/jamesng-20050130.tar.gz
> >
> > I suggest you download source release and build
> > binary release or just
> > download binary release to play with the groovy
> > all-in-one configuration.
> >
> > Anonymous CVS access:
> >
> >
>
CVSROOT=":pserver:anoncvs@devel.priocom.com:/export/cvsroot/jamesng"
> > anoncvs user has empty password
> >
> > FishEye (like viewcvs but better and in java)
> > http://devel.priocom.com:8083/viewrep/JamesNG
> > You can also download the latest cvs checkout
> > tarball at
> >
> >
>
http://devel.priocom.com:8083/viewrep/~tarball=tgz/JamesNG/JamesNG.tgz
> >
> > As steps further steps to develop apache james i
> > propose:
> > - create a new branch in svn called
> "JAMES_NG"
> > or the like
> > - give up using avalon container in this
> branch
> > - either use one of the existing CDI
> containers
> > (picocontainer) or
> > accept proposed groovy-based config files
> > - merge smtp/mailer/mailet code into JAMES_NG
> > branch
> > - use the branch as a basis for James v3
> >
> > Any ideas?
> > Flames?
> > What is wrong with my approach?
> >
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > server-dev-unsubscribe@james.apache.org
> > For additional commands, e-mail:
> > server-dev-help@james.apache.org
> >
> >
>
>
> =====
>
=== message truncated ===
=====
Are you an MBA? Check out http://www.mba.hk for value added services.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [James-NG] Avalon-free James proposal and reference implementation
Posted by Gabor Kincses <np...@yahoo.com>.
Does using groovy mean using nanocontainer as well?
Lightweight containers are great. I personally think
constructor dependency injection is the right way to
go.
Thanks,
Gabor
--- Alexander Zhukov <zh...@ukrpost.net> wrote:
> Hi, James hackers!
>
> Recently on the mailing list I saw messages of
> departure from
> avalon-based container
> So i decided to propose my ideas and reference
> implementation as a basis
> of next generation james
> (i hope avalon-free version) which i propose to call
> jamesng
>
> nice points in jamesng for apache james are:
> - components are independent POJOs (CDI IoC) so no
> funky
> interface has to be implemented to extend
> james-ng
> (see COMPONENTS)
> - single file groovy-based configuration
> - multiple domains support from the ground up
> - adaptable user stores (enterprise does not want
> to change its
> db/ldap directory/whatever) (see
> ENTERPRISE DB)
> - javax.mail.Store/Folder based mail repositories
> support
> hierarhical folders, tested with Maildir
> and mbox providers
> (see STORES)
> - extensive support for folder/store/user caching
> to speed-up
> servers (see CACHING)
> - imap4 support (not complete but usable)
> - pop3 support
> - independent components can be easily added and
> integrated into
> build system
>
> things laking:
> - smtp support - no spooling/remote deliveries,
> working on it
> right now
>
> ENTERPRISE DB
> server is large ISP/enterprise targeted which means
> - support for multiple domains on a single/multiple
> IP addresses,
> - highly configurable user stores - database should
> not be designed for
> use with james (as it is with current james)
> but rather user store adapts to the existing
> userstores of an
> isp/enterprise.
> Often enterprises already have their user databases
> often they contain
> legacy elements which such companies
> just very much hesitate to change to something new.
> Above mentioned is very much true for LDAP
> directories - you cannot
> expect an enterprise to change its
> LDAP directory to fit james in
>
> COMPONENTS
> All components of james-ng are POJOs no component
> _must_ implement some
> funky interface to be included in the server.
> Components adhere CDI style IoC which besides other
> advantages allows
> configuration to be a single groovy file.
> The task of groovy configuration is to assemble all
> components together.
>
> STORES
> Mail stores (repositories) are plain
> javax.mail.Store providers.
> Since javax.mail.Folder interface supports hierarchy
> james-ng gets
> "free" IMAP support - no need to reengineer mail
> repository to access folders/sub-folders. However to
> support all of IMAP
> features such provider's Folder implementation
> must as well implement UIDFolder interface to
> support IMAP UID operations.
> For now tested are Maildir and mbox providers, but
> apparently nothing
> prevents to write/use existing jdbc providers
> that would store mails in database.
> Simple groovy-based configuration allows
> administrator to configure
> different types of stores for different users.
>
> CACHING
> I am currently in charge of rather large (150k+
> users) free webmail with
> multiple domains
> and i dont have very new and high-performing
> hardware to host it so i
> designed the server for performance.
> The main point is to avoid unproductive waste of
> performance (very much
> true for most unix mail servers)
> stores/folders opened by users as well as user
> objects are cached
> (certainly you can turn the cache off) instead of
> being
> open on every user login. Very much helps for
> polling clients which
> disconnect and connect back in 10 minutes.
> Administrator can adjust the caching policy, for now
> implemented are
> LRUCache and GCCache (reference map based cache).
>
> If you are reading this then you are ready to see
> what does jamesng look
> like.
> Since the codebase is pretty large for an attachment
> to email I have
> setup cvs repostitory as well as source release
> repository.
>
> Source release:
>
http://devel.priocom.com/jamesng/jamesng-20050130-src.tar.gz
> Binary release
>
http://devel.priocom.com/jamesng/jamesng-20050130.tar.gz
>
> I suggest you download source release and build
> binary release or just
> download binary release to play with the groovy
> all-in-one configuration.
>
> Anonymous CVS access:
>
>
CVSROOT=":pserver:anoncvs@devel.priocom.com:/export/cvsroot/jamesng"
> anoncvs user has empty password
>
> FishEye (like viewcvs but better and in java)
> http://devel.priocom.com:8083/viewrep/JamesNG
> You can also download the latest cvs checkout
> tarball at
>
>
http://devel.priocom.com:8083/viewrep/~tarball=tgz/JamesNG/JamesNG.tgz
>
> As steps further steps to develop apache james i
> propose:
> - create a new branch in svn called "JAMES_NG"
> or the like
> - give up using avalon container in this branch
> - either use one of the existing CDI containers
> (picocontainer) or
> accept proposed groovy-based config files
> - merge smtp/mailer/mailet code into JAMES_NG
> branch
> - use the branch as a basis for James v3
>
> Any ideas?
> Flames?
> What is wrong with my approach?
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail:
> server-dev-help@james.apache.org
>
>
=====
Gabor Kincses
Running Mandrake Linux 10.0
__________________________________
Do you Yahoo!?
The all-new My Yahoo! - Get yours free!
http://my.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org