You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2008/04/10 13:36:07 UTC
Use case for ${org.apache.cocoon.blocks.[BLOCK_NAME].resources} style
properties
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 ... ;-) ).
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: Use case for ${org.apache.cocoon.blocks.[BLOCK_NAME].resources}
style properties
Posted by Carsten Ziegeler <cz...@apache.org>.
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
Re: Use case for ${org.apache.cocoon.blocks.[BLOCK_NAME].resources}
style properties
Posted by Reinhard Poetz <re...@apache.org>.
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.
Is it possible to register more than one property configurer?
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: Use case for ${org.apache.cocoon.blocks.[BLOCK_NAME].resources}
style properties
Posted by Carsten Ziegeler <cz...@apache.org>.
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.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org