Hi,
I remember Raju tried the mailing-lists functionality on 3.0M2 (don't
know the status of it)
Upon the UsersRepo removal from mailing list mailets, there's we could
also upgrade the database access from JDBC to JPA.
We have http://svn.apache.org/viewvc/james/server/tags/with_mailinglist/
to achieve this one day.
Tks,
Eric
On 16/12/2010 10:54, Stefano Bagnara wrote:
2010/12/16 Norman Maurer<[email protected]>:
2010/12/16 Stefano Bagnara<[email protected]>:
2010/12/16 Norman Maurer<[email protected]>:
Hi there,
as we are currently doing last changes in the API before the next
release I would like to get rid of the UsersStore interface and
implementation.
Here some background:
In previous version of James Server we allowed to configure more then
one UsersRepository and lookup each by its unique name. We forced the
User/Dev to specify at least one UsersRepository which need to have
the name "LocalUsers". This one was used as the "default" which were
used to back all "local" users. Beside this you could configure a
second one and use it in some mailets. Anyway most of our code was
bound to use the "LocalUsers" one to check for valid user etc. So I
don't see much value to support more the one at the same time. It just
complicate stuff and needed some ugly hacks to get it workin all the
way.
The only "service" which make really use of the UsersStore and so more
then one UsersRepository is the mailinglist stuff. But I think its
just plain wrong to use it here. The maillinglist use one
UsersRepository per mailinglist to store eachs users. Anyway using the
UsersRepository for this is just a misusage of a component, as it was
not really designed for that purpose. The mailinglist in fact only
need some kind of storage which map mail-addresses to the right list.
Nothing more.
So I propose to remove UsersStore and just use one UsersRepository.
For the mailinglist we have two options:
1) Remove the mailinglist stuff
2) Write some simple store for it.
I think 1 would be the fastest but maybe users still like to use it.
I'm in fact never did so I would be ok with removing it too.
So what others think about it ?
I agree with you. I never used the mailing list stuff and also can't
remember users asking questions about that.
Maybe the best thing in order to generically support persistence for
generic mailets is to add some kind of "persistent map" in the mailet
api. This way a mailet can define "named" maps and make simple
add/remove/lookup from that maps without knowledge about the real
persistence and containers can provide files/db or any other
implementation.
I agree with you that this would make sense. Anyway I think its hard
to come-up with something generic enough to work for all cases.
This "map" stuff can also be found in other system like sendmail where
they even provide a tool to build a db from the file based maps (this
is used for the domainlist, for the aliasing, for the relay server
definitions) and maybe for more.
If a mailet needs something more "complex" than simple maps it can
implement it's own serialization method for the value.
Yeah I agree as stated aboce
Maybe this would allow us to remove direct JDBC/Store references from
some mailet (most of the mailets that we still bundle in james instead
of mailet project). Then it could easily allow to write an
administrative interface (or JMX) to see defined map and alter their
content.
Stefano
I think for now we could just tag current trunk and remove all the
mailetlist stuff. If we dedicite later we still need or want it we can
merge it back.
WDYT ?
+1
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
