[Springframework-developer] Mailing list black hole

[Colin S. <col...@ex...>]

Black hole might not be the most appropriate term (messages are getting 
out eventually), but there have been some seriously large delays in 
delivering messages to the lists during the last week.

I wrote the message below 3 days ago, and it only appeared in my inbox 
now...



Colin Sampaleanu wrote:

> Matthew E. Porter wrote:
>
>> On Wednesday, October 22, 2003, at 10:18 AM, Colin Sampaleanu wrote:
>>
>>> Matthew E. Porter wrote:
>>>
>>>> Greetings.  I am testing the Spring framework with a WW2+Hibernate 
>>>> web application currently being developed.  When initially 
>>>> deploying this application, the deployer is prompted with settings 
>>>> to configure the database settings- specifically, the Hibernate 
>>>> settings.  At that point, the hibernate.cfg.xml is written and 
>>>> Hibernate is loaded.
>>>>
>>>> From what I can tell, Spring prefers this information being written 
>>>> in the applicationContext.xml file and is tied to the entire 
>>>> container.  What is the best method for accomplishing something 
>>>> similar?
>>>
>>>
>>> Actually Spring (LocalSessionFactoryBean for example) has no problem 
>>> using hibernate.cfg.xml as a source for settings. There are indeed 
>>> lifecycle issues in your usage scenario though.
>>>
>>> The container normally creates singleton beans immediately (that is, 
>>> when the container loads), so that normally LocalSessionFactoryBean 
>>> would be created at that time, and would need it's parameters 
>>> (whether or not some data is coming from an external 
>>> hibernate.cfg.xml file is irrelevant).
>>
>>
>> That was my experience; however, being a newbie to Spring, I wanted 
>> confirmation.
>>
>>> How is the deployer prompted for the params that are needed? Is this 
>>> done only on the first usage after a new deploy?
>>
>>
>> The deployer is prompted for the settings when the initially access 
>> the application in the browser.  It should only been once, right 
>> after a new deploy.
>>
>> Do you see a way to work around this?
>
>
> That's a bit of a toughie. (Spring aside, changing something like a 
> datasource which is bound to JNDI is going to be hard to do in any 
> J2EE container environment, since the J2EE container is actually 
> setting up that datasource).
>
> One approach which might be made to work would be to assemble the 
> Spring context from multiple XML files (this capability is currently 
> available in CVS, the 1.0M1 release can only do nested contexts, which 
> are not quite the same thing). So the app would start up using a 
> context which didn't include the info needed to be configured (but 
> which presumably isn't needed for prompting the deployer, either), 
> prompt the deployer for the information, then write out the proper 
> Spring context xml file which needs to be customized. Then the app 
> would restart itself, and build the context from all the xml files 
> including the one that had been written.
>
> The mehanism of how to do a restart bit is somewhat iffy, in that it 
> would probably have to be servlet container specific, that is, you 
> would restart the webapp in a container specific fashion.
>
> Your alternative of course, is to do the configuration as part of the 
> deployment process, which is what most people do.
>
> Regards,
> Colin