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
>> >>>
>> >
>>
>>
