I added the following comment to this proposal.
I feel this is reinventing a poor man's version of the Spring BeanFactory
(
http://www.springframework.org/docs/api/org/springframework/beans/factory/BeanFactory.html )
piece by piece. Why not use it?
This is ok as a temporary hack but please don't extend it into a pattern.
I'd propose we replace the static configuration with a
Spring BeanFactory-based config.
--a.
----- Original Message -----
From: "Allen Gilliland" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, October 16, 2006 10:19 PM
Subject: Re: Proposal_ImproveDatabaseConfig
Dave wrote:
On 10/16/06, Allen Gilliland <[EMAIL PROTECTED]> wrote:
I think there's 2 items mixed together here. You are basically talking
about doing 2 things ...
For #1 I think what you have is fine, but I would ask if there is any
reason why we shouldn't just setup Roller to always define the
connection parameters via the roller config? As I think about it more
it seems almost more complicated to have people configure their database
via a jndi datasource in their container when we could easily have them
put that same data in the roller config file, which they are supposed to
be modifying anyways. Seems like that would make the installation
process a lot easier as well as accomplish this goal.
I agree. Configuration consolidation is a good thing.
How do people feel about making this change for 3.1?
Instead of instructing folks to setup the database configuration in
their app server config (roller.xml on Tomcat for example), we would
tell them to create a roller-custom.properties tile and define these
parameters:
jdbc.driverClass=
jdbc.connectionURL=
jdbc.username=
jdbc.password=
We'd also allow the option of using a JNDI datasource.
jdbc.jndiDataSource=
I am not against this for 3.1 because I think it's a relatively small
change, but we should probably think a little bit more about exactly what
we want to support. Obviously using the first section of jdbc.*
properties is pretty easy, but it then completely bypasses any option of
using a connection pool which in my mind makes it's usefulness a bit
limited. Many users may not know the difference, but maybe we should try
and guide them?
If we want to we could include our own database pooling library, like
c3p0, and manage the pool ourselves. It's probably even possible to set
it up so that the properties jdbc.* allow the pool to be completely
defined by the user, basically the same way resource-ref works in the
web.xml. Then the user could even pick their own pooling software if they
really wanted to.
Anyways, the main point is that it probably makes sense to think more
about how this could work. Also, if we are doing this for the db
connection, maybe we should do the same for the mail session?
-- Allen
For #2 I think it looks good as well, I would just drop it in the
business.runnable package. The one thing I would consider changing is
instead of forcing people to use a taskrunner.properties file just to
set 2 properties, why not get them as cmd line arguments? or possibly
jvm arguments? i.e.
java -cp roller-planet.jar TaskRunner <task-class> <roller.dir>
[jars.dir]
java -Droller.webapp.dir=<path> -Droller.jars.dir=<path> -cp
roller-planet.jar TaskRunner <task-class>
In my mind either of those options seems a little more straight forward
than doing the taskrunner.properties file.
Yep. I like the second option.
- Dave
Dave wrote:
> To make it easier to configure standalone tasks for the Planet Roller
> webapp, I've implemented some improvements in the way that the
> database connection is configured. I'd like to move that code into
> Roller proper so we can simplify the rollertask.sh script and setup.
>
> Here's the proposal:
>
http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_ImproveDatabaseConfig
>
>
> And if you take a look at the TaskRunner and
> PlanetHibernatePersistenceStrategy (under sandbox/planetroller), you
> can see the code that does the work.
>
> - Dave
