On 5/17/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
> I don't think we need "database.connectionProvider" -- if we find JDBC
> properties set, we use them otherwise we use the same JNDI setup we've
> always used. All we're doing here is decided whether to initialize the
> ORM system (i.e. Hibernate or JPA) with a list of JDBC connection
> parameters or a JNDI resource name. The ORM system has it's own
> internal "DatabaseProvider" which doles out connections.
I still prefer that we have explicit properties to define the strategy
for getting db connections or mail sessions. Not only is it more
explicit and therefore easier to read the config and know what is
supposed to happen, but it also allows you to keep configurations for
each option in the config without triggering different behavior.
That's a good point. I added explicit connectionType parameters to the proposal.
I know we already have jdbc.* properties being used, but I prefer the
database.* property names for consistency sake, so I think we should
switch to those.
I added database.* naming to the proposal too.
I also think that when someone chooses database.provider=jndi that we
should also support a property for choosing their own jndi name, such as
database.jndiName=jdbc/rollerdb.
And while you are correct that ORM solutions have their own
DatabaseProvider classes that still does not negate our need for one.
The purpose of this class in Roller is still very valid and IMO should
be there to handle extracting the proper config properties and creating
the DataSource, handling db testing (to see that the db is there), and
install/upgrade procedures. I actually think it's preferrable if we
inject our own DataSource into the ORM configs when we create the
sessionFactory/entityManager rather than forcing the ORM config to look
it up itself. For example, in hibernate that just means setting the
connection provider to InjectedDataSourceConnectionProvider and making
sure to call setDataSource() before building the sessionFactory. That
seems like a better way to do it than how we do it now where we
dynamically rebuild the hibernate xml config file.
I'm going to look into that, but I'm not ready to write it into our
out of the proposal yet. For Hibernate, I can see how
ConnectionProvider can allow us to get rid of that dynamic XML file
generation, but I don't see an analogous technique for JPA yet.
Speaking of JPA, it's a pity to have to do the work for both JPA and
Hibernate, perhaps I would wait until after the JPA switch (I owe
everybody an update on that topic).
I agree that we want to be able to display errors to users, but with the
DatabaseProvider option as I detailed above and the Bootstrapper then
this would happen naturally without needing to try and extract errors
from the ORM tool and store them somewhere. The workflow would be more
natural such as ...
1. container started and contextInitialized() called
2. DatabaseProvider constructed
3. check configured datasource
4. if datasource is good then check for install/upgrade work
5. once install/upgrade work is complete then move on
6. MailProvider constructed
7. check configured mail session
8. if mail session is good then move on
9. bootstrap application
Yes, that makes sense.
I'm going to try to work out the details of the provides and a
bootstapping next. Thanks for the quick and detailed feedback.
- Dave
