cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: Use case for ${org.apache.cocoon.blocks.[BLOCK_NAME].resources} style properties
Date Tue, 15 Apr 2008 09:19:34 GMT
Reinhard Poetz wrote:
> Carsten Ziegeler wrote:
>> Reinhard Poetz wrote:
>>>
>>> I've just started to move the deployment of blocks into a 
>>> ServletContextListener and came across a (for me) unkown feature that 
>>> gives access to the path of blocks in Spring properties:
>>>
>>> This feature was introduced by Carsten as part of this SVN commit 
>>> http://cocoon.markmail.org/message/slrelbwbej3xyryq
>>>
>>> And here the text from changes.xml:
>>>
>>> <quote>
>>>   Improved the DefaultBlockResourcesHolder to act like a
>>>   PropertyPlaceholderConfigurer. This allows access to the path of 
>>> the deployed
>>>   blocks in the configuration files through properties like
>>>   ${org.apache.cocoon.blocks.[BLOCK_NAME].resources}.
>>> </quote>
>>>
>>> What's the use case for this feature? (If there is none [anymore], I 
>>> don't have to migrate it ... ;-)  ).
>>>
>> I only add features if there's a use case :)
>> This is needed for the hsqldb block to specify where the db files are 
>> located.
>> But still, it should be possible to decouple this - if the servlet 
>> context listener deploys the stuff and makes the map of deployed 
>> blocks available, a property configurer can pick it up and still 
>> replace the properties.
> 
> I don't want to make the Spring configurator depend on the block 
> deployer in the future.
Yepp, I totally agree; I'll make an attempt to get the configurator into 
Spring itself next week.

> 
> Is it possible to register more than one property configurer?
> 
I think so, but I'm not 100% sure.

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Mime
View raw message