james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oki DZ <ok...@pindad.com>
Subject Re: DB code committed
Date Thu, 02 Aug 2001 03:00:29 GMT
On Thu, 2 Aug 2001, Darrell DeBoer wrote:
> I reckon using Avalon to manage Database connections would make sense, to get 
> the built in pooling features if nothing else. My understanding is that we 
> could use Excalibur JdbcDataSource for our connection management, but it 
> seems that this would currently require configuring a datasource at each 
> point where one is required (ie on a "per-repository" basis - User, Spool, 
> Inbox, etc), even if they all use the same db. This could get pretty arduous, 
> especially since we call every mailing list a separate "repository".

Well, it should be like that, shouldn't it? I mean, to get a db
connection, you'd have a Connection object in each repository.
 
> Possibly better would be to use the Cornerstone DataSourceSelector block to 
> load JdbcDataSource components, so that all datasources could be configured 
> in a single config section, and referred to by name elsewhere in the config 
> file. Different Mail Repositories (spool, inbox, error, spam) could use the 
> same or different datasource, and be configured to use the same table with an 
> index column (as is currently), or separate tables.

This one is better, I think (compared to have a configuration section in
config.xml for each repository).
 
> This is the theory, now to the implementation. I've tried both of these 
> approaches for the JdbcUsersRepository but ran into problems. I haven't spent 
> a great deal of time tracking them down, but if anyone has any advice I'd 
> appreciate it.

I had the same problem too. Excalibur's JdbcDataSource needed a
configuration section for itself, even though you could use it without any
compilation error; just a runtime error, saying that the object wasn't
initialized. Last time I asked in the avalon-dev list. There is a FAQ
entry in Cocoon 2's site regarding JdbcDataSource:
http://xml.apache.org/cocoon2/datasources.html (I didn't know what was
going on; the JdbcDataSource's doc was only available in Cocoon project's
site. There was none in Excalibur's doc.  Interesting... maybe it was a
way to "attract" people to the other Apache projects' sites <those
developers winking>).

It seems that using JdbcDataSource is not that difficult; the
documentation is there in the above link, loud and clear. But I already
implemented the db pooling using one of the Turbine services, so I guess
I'm stuck with it.  It was pretty tedious to have the services available
for James; you'd have to write an Avalon block to load the TurbineConfig
class, and wrote some classes to get the services. I think it was
worthwhile though, so that I know how to write Avalon blocks (and get them
loaded at appropriate time;  ie: the db connection pooling service should
be available before the AvalonMailStore block gets loaded). 

I guess, using JdbcDataSource in James is naturally The Right Thing(tm).
 
> My main problem is that whenever I fiddle with the James config file (eg try 
> to set a DataSourceSelector block) I get this (unhelpful) exception message 
> on Phoenix startup: 
> 
> Phoenix 3.1a1-dev
>  
> There was an uncaught exception:
....

I experienced that exceptions many times. Basically, if you had
Configuration.getChild("some-element") and Avalon couldn't find it, then
you'd have the exceptions. This surely is just one of the possible causes,
though.
 
> I plan to have a better look, but if anyone knows what's going on, it would 
> help me out. (I can replicate this problem by simply renaming the 
> <pop3server> element to <pop3server1> and attempting to start James).

Yes, the POPServer couldn't find its configuration section.  

I think Phoenix should have a better error reporting problem (not just
waiting the JVM stack to be overflowed); having its XML parser printing
out the line number where it couldn't get the appropriate input elements
would be really helpful.

Oki
 


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


Mime
View raw message