I made a commit today to fix that problem. Make sure you're using the latest HibernatePersistenceStrategy.
- Dave On 10/18/06, Allen Gilliland <[EMAIL PROTECTED]> wrote:
Dave, I think there is an issue with the way this is currently working. The new way always wants to build a parsed xml document to work on and I think the way the validation works forces it to call out to the web for the DTD. This is a problem for me and potentially other people who are behind firewalls and don't want to have their hibernate DTD pulled from the hibernate site. For example, right now I am trying to run some unit tests and everything is failing with this exception. Same thing happens if I startup my webserver without any proxy settings ... FATAL 2006-10-18 14:13:20,928 HibernateRollerImpl:<init> - Error initializing Hibernate org.jdom.input.JDOMParseException: Error on line 21: External entity not found: "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd";. at org.jdom.input.SAXBuilder.build(SAXBuilder.java:468) at org.jdom.input.SAXBuilder.build(SAXBuilder.java:770) at org.apache.roller.business.hibernate.HibernatePersistenceStrategy.<init>(HibernatePersistenceStrategy.java:74) at org.apache.roller.business.hibernate.HibernateRollerImpl.<init>(HibernateRollerImpl.java:83) at org.apache.roller.business.hibernate.HibernateRollerImpl.instantiate(HibernateRollerImpl.java:101) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.roller.model.RollerFactory.getRoller(RollerFactory.java:66 -- Allen Dave wrote: > Yes, this requires more discussion. > > I'm going to add what I need specifically for the standalone tasks, > but I'm going to leave the Roller webapp database configuration alone > for now. > > Anil, would bean factory allow us to have one static/startup config > file that includes all existing properties plus database resource and > mail resource? How would it work? Would it be a simple property file > as it is now? Would we be able to override with a simple property file > as we do now? > > - Dave > > > > > On 10/17/06, Anil Gangolli <[EMAIL PROTECTED]> wrote: >> >> 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 >> >>> >> > >> >>
