Re: Use case for ${org.apache.cocoon.blocks.[BLOCK_NAME].resources} style properties
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ötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Use case for ${org.apache.cocoon.blocks.[BLOCK_NAME].resources} style properties
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
[EMAIL PROTECTED]
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ötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Use case for ${org.apache.cocoon.blocks.[BLOCK_NAME].resources} style properties
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
[EMAIL PROTECTED]
