Ralph Goers wrote:
Luca Morandini wrote:
So, the chain you propose is (sorted by order of loading):
1) WEB-INF/classes/META-INF/cocoon/properties (block-wide stuff).
2) WEB-INF/classes/cocoon/properties (project-wide stuf).
In truth, I don't find the use of classes for configuration stuff
Ralph Goers schrieb:
Luca Morandini wrote:
So, the chain you propose is (sorted by order of loading):
1) WEB-INF/classes/META-INF/cocoon/properties (block-wide stuff).
2) WEB-INF/classes/cocoon/properties (project-wide stuf).
In truth, I don't find the use of classes for configuration
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Have a look at the core.properties file in the cocoon-core module. Just
put a properties file with the appropriate configuration into
WEB-INF/cocoon/properties. This should
Giacomo Pati wrote:
This raises the question if we need this? I think we should readd the
support for reading properties from WEB-INF/cocoon/properties.
IIRC we mentioned putting those into
WEB-INF/classes/META-INF/cocoon/properties
Yes, you're absolutely right! This brings back my
Luca Morandini wrote:
Remember to update the comments in the source code of
SettingsBeanFactoryPostProcessor.java then, because they still state
that WEB-INF/cocoon/properties is supported in the fall-back chain of
properties loading.
Yepp, thanks for the info - I'll take care of it in
Carsten Ziegeler wrote:
Luca Morandini wrote:
One issue, though: since the property loading mechanism uses
classpath:° protocol, property files are read in alphabetical order,
which means I might have my per-project properties ruined by the
addition of a block, unless I call them
Luca Morandini schrieb:
Carsten Ziegeler wrote:
Luca Morandini wrote:
One issue, though: since the property loading mechanism uses
classpath:° protocol, property files are read in alphabetical order,
which means I might have my per-project properties ruined by the
addition of a block,
Giacomo Pati wrote:
Carsten Ziegeler wrote:
Luca Morandini wrote:
This was neatly solved by the use of WEB-INF/cocoon/properties, since it
was loaded after the classpath:* chain.
Yes, you're right. Hmm, perhaps we should load properties from
WEB-INF/classes last. I'll have a look at that
Carsten Ziegeler wrote:
Luca Morandini schrieb:
Carsten Ziegeler wrote:
Luca Morandini wrote:
This was neatly solved by the use of WEB-INF/cocoon/properties, since it
was loaded after the classpath:* chain.
Yes, you're right. Hmm, perhaps we should load properties from
WEB-INF/classes
On Dec 12, 2006, at 7:33 AM, Luca Morandini wrote:
In truth, I don't find the use of classes for configuration stuff
done outside JARs particularly intuitive...
+1
—ml—
Mark Lundquist wrote:
On Dec 12, 2006, at 7:33 AM, Luca Morandini wrote:
In truth, I don't find the use of classes for configuration stuff
done outside JARs particularly intuitive...
+1
me-too/
Vadim
Luca Morandini wrote:
So, the chain you propose is (sorted by order of loading):
1) WEB-INF/classes/META-INF/cocoon/properties (block-wide stuff).
2) WEB-INF/classes/cocoon/properties (project-wide stuf).
In truth, I don't find the use of classes for configuration stuff
done outside JARs
Carsten Ziegeler wrote:
Have a look at the core.properties file in the cocoon-core module. Just
put a properties file with the appropriate configuration into
WEB-INF/cocoon/properties. This should work.
Carsten,
Regarding loading of properties from WEB-INF - can you point out where this is
Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Have a look at the core.properties file in the cocoon-core module. Just
put a properties file with the appropriate configuration into
WEB-INF/cocoon/properties. This should work.
Carsten,
Regarding loading of properties from WEB-INF - can
14 matches
Mail list logo
