I think there's 2 items mixed together here. You are basically talking
about doing 2 things ...
1. allow for db configuration via roller.properties
2. provide a convenient class for running individual tasks, basically
for handling the classpath issues.
I agree with doing both of these, but I think we should consider them
separately.
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.
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.
-- Allen
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
