james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darrell DeBoer <li...@bigdaz.com>
Subject Re: DB code committed
Date Thu, 02 Aug 2001 06:42:10 GMT
Thanks for the pointers, I'm going to try to get the DataSourceSelector block 
running in a sample app - if that works, I'll try to move it into James.

On Thu,  2 Aug 2001 13:00, Oki DZ wrote:
> 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

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

View raw message