hi ,it is a problem i use Virtual Host and share jvm with others
i could not set jvm arguments.... 2006/10/17, Allen Gilliland <[EMAIL PROTECTED]>:
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 >>
