cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: Use case for ${org.apache.cocoon.blocks.[BLOCK_NAME].resources} style properties
Date Tue, 15 Apr 2008 08:51:49 GMT
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 
>> 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 

Is it possible to register more than one property configurer?

Reinhard Pötz                            Managing Director, {Indoqa} GmbH

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair

View raw message