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 Darrell DeBoer <dd...@bigdaz.com> on 2001/08/17 17:45:43 UTC
[COMMIT] - More UserStore/MailStore stuff
G'day all,
I've just commited a bunch of code I've been working on over the last week or
so. It involves a bit of cleaning up the configuration for Users/Mail
repositories and (I hope), better useability.
This is all in the "userstore" proposal, but I can't see any reason why it
can't be moved into the main branch pretty soon (or immediately). I'm pretty
confident that this new stuff will work as well as the main tree - just need
a couple of others to try it out, I guess.
In short:
- JDBCMailRepository (and Spool) now use Avalon/Cornerstone connection
pooling and configuration. Just set one dbUrl for the whole app, finally!
- Moved all of the SQL statements for the Mail repository into a single file
(sqlResources.xml), along with the SQL for the Users repository
- Removed the various dot.properties files for the Mail repository, and
moved all of the configuration into the james-config file.
- Fixed the JDBCMailRepository to work for user Inbox.
- Changed UsersJdbcRepository config to use a "destinationURL" syntax.
Please see the README for more details.
To build:
../build.sh -buildfile proposals/userstore/build.xml
NOTE: You need to run this as "dist/bin/run.sh", since paths are currently
set relative to the current directory. Will need to fix this to use the
BlockContext path.
enjoy
Daz
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: [COMMIT] - More UserStore/MailStore stuff
Posted by Darrell DeBoer <dd...@bigdaz.com>.
Hi Serge,
On Sun, 19 Aug 2001 07:01, Serge Knystautas wrote:
> Darrell,
>
> This looks great. Thanks a lot! I'm going to test this weekend to see
> what's left to do. I also like the build approach you used.
Thanks. Unfortunately, I'm not going to have much time in next few weeks.
But, assuming that it's working for you, I'm pretty happy that the
"userstore" proposal is ready to shift onto the main tree. The changes are
pretty pervasive, and it could be a pain to merge later on.
So, here's my
+1 - for moving the userstore proposal into the main tree.
Regarding an alpha release, I think it would be good to get one out soon.
There's still work to do, but as I understand it "alpha" means that we're not
committed to backward compatability. If that's the case, then we should move
on it. Then, we could come up with a release plan built on what Charles
suggested, but break it down into staged alpha and beta releases.
One thing I think needs doing, in both the MailStore and UserStore, is to
include the "sqlReources.xml" in the James.sar file, and get the paths
working properly, so that this file is found relative to the "block path",
rather than the current directory. This is a couple of hours work, maybe as
simple as doing:
JdbcMailRepository.contextualize(Context context) {
File rootPath;
if (context instanceof BlockContext) {
rootPath = ((BlockContext)context).getBaseDirectory();
}
}
Another thing: I'd like to see the RMI proposal in CVS. I'll get onto that
next time I have a few hours, if no-one beats me to it. We should then
migrate the current RemoteManager to use the UserManagement interface. I
think we really need a better management console; maybe the person who was
working on the servlet-based one could help out? (Or someone familiar with
Velocity?)
>
> In terms of configuring whether to store the entire message in the DB or
> the headers in the DB and body in the file, why don't we create two classes
> instead. The db:// would store the complete message in the DB and
> dbfile:// would store only the headers. Perhaps the two implementations
> could extend from a single abstract class so the SQL statements only need
> to get defined once (I'm not sure whether your resource parser handles
> inheritance).
I like the idea of providing an "extends" attribute on an <sqlDefs> element
in the sqlResources file, so that we never have to redefine SQL for similar
components. (An example would be to separate the Spool-specific SQL from the
MailRepository SQL).
Regarding the "db" and "dbfile" implementations: do we need different SQL
statements for the "db" and "dbfile" storage options? It may be simpler to
keep just one set of statements, but set the message parameter to null when
we're using file-storage. (I might be off-track here, though).
It does sound like a good idea to split the implementations for the "pure"
jdbc storage from the "combo" file/db version. This would be cleaner, but
maybe not a high priority. (In other words - up to you...). We should only
ever need a single "filestore" location, so this could be configured for the
repository class as a whole, and specifying "dbfile:" would be all the
configuration required for the different repository instances.
In fact, for starters, you could leave the implementations as-is, and just
add another <repository> config section to the MailStore. Something like:
<repository
class="org.apache.james.mailrepository.JDBCMailRepository">
<protocols>
<!-- the "file/db" storage protocol" -->
<protocol>dbfile</protocol>
</protocols>
<types>
<type>MAIL</type>
</types>
<config>
<sqlFile>dist/conf/sqlResources.xml</sqlFile>
<!-- include a filestore attribute, so that
the repository uses the correct storage option -->
<filestore>file://var/dbspool</filestore>
</config>
</repository>
(and another one for SPOOL)
This would effective do the same thing, at least until we split the
implementations. I can't be sure that this will work, but you could give it a
go. (Oh, we'd probably need to do better parsing of the destinationURL
attribute, since we currently assume a fixed-length protocol).
good luck,
ciao
Daz
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: [COMMIT] - More UserStore/MailStore stuff
Posted by Serge Knystautas <se...@lokitech.com>.
Darrell,
This looks great. Thanks a lot! I'm going to test this weekend to see
what's left to do. I also like the build approach you used.
In terms of configuring whether to store the entire message in the DB or the
headers in the DB and body in the file, why don't we create two classes
instead. The db:// would store the complete message in the DB and dbfile://
would store only the headers. Perhaps the two implementations could extend
from a single abstract class so the SQL statements only need to get defined
once (I'm not sure whether your resource parser handles inheritance).
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
----- Original Message -----
From: "Darrell DeBoer" <dd...@bigdaz.com>
To: <ja...@jakarta.apache.org>
Sent: Friday, August 17, 2001 11:45 AM
Subject: [COMMIT] - More UserStore/MailStore stuff
> G'day all,
>
> I've just commited a bunch of code I've been working on over the last week
or
> so. It involves a bit of cleaning up the configuration for Users/Mail
> repositories and (I hope), better useability.
>
> This is all in the "userstore" proposal, but I can't see any reason why it
> can't be moved into the main branch pretty soon (or immediately). I'm
pretty
> confident that this new stuff will work as well as the main tree - just
need
> a couple of others to try it out, I guess.
>
> In short:
> - JDBCMailRepository (and Spool) now use Avalon/Cornerstone connection
> pooling and configuration. Just set one dbUrl for the whole app, finally!
> - Moved all of the SQL statements for the Mail repository into a single
file
> (sqlResources.xml), along with the SQL for the Users repository
> - Removed the various dot.properties files for the Mail repository, and
> moved all of the configuration into the james-config file.
> - Fixed the JDBCMailRepository to work for user Inbox.
> - Changed UsersJdbcRepository config to use a "destinationURL" syntax.
>
> Please see the README for more details.
>
> To build:
> .../build.sh -buildfile proposals/userstore/build.xml
>
> NOTE: You need to run this as "dist/bin/run.sh", since paths are currently
> set relative to the current directory. Will need to fix this to use the
> BlockContext path.
>
> enjoy
> Daz
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org