Re: Proposal_ImproveDatabaseConfig

Tue, 17 Oct 2006 11:31:50 -0700 


Anil Gangolli wrote:



----- Original Message ----- From: "Dave" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, October 17, 2006 8:46 AM
Subject: Re: Proposal_ImproveDatabaseConfig



Yes, this requires more discussion.



Definitely, it's a more extensive proposal.  I'd just prefer to discuss 
more before going down the road of a doing a sequence of our own hacks 
of this kind.



I agree that considering Spring for some of this configuration work is a 
good idea.  Personally I am still a little skeptical, but we should 
definitely start up another proposal/discussion about using Spring for 
configuration.







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?



Yes; at least I've done it with DataSource.  It should work for the 
MailSession as well.



We could also instantiate and initialize the Roller object, manager, 
persistence layer this way.



How would it work?



The one-line answer is that the BeanFactory instantiates the objects and 
sets their props for you either via constructor or immediately after a 
default construction via setters on the objects.



Would it be a simple property file as it is now?


Normally it would be XML-based.


Would we be able to override with a simple property file as we do now?



I have done something like our overrides with another XML file and an 
intermediate bean of class Map.



There is also PropertyOverrideConfigurer 
(http://www.springframework.org/docs/api/org/springframework/beans/factory/config/PropertyOverrideConfigurer.html) 




which does overrides more like our own with plain properties files.  I 
have not used this though.



I think this is the main key for this proposal.  When it comes to 
database configuration we want that to come from the roller properties 
file and that means that if we want to use Spring that we would have to 
map properties again.


Last time (with acegi properties) that didn't go so well :/

-- Allen




--a.




- 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