Re: Proposal_ImproveDatabaseConfig

Wed, 18 Oct 2006 14:25:52 -0700 

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

























					Reply via email to