You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Luca Morandini <lm...@ieee.org> on 2006/12/12 15:41:31 UTC
Re: Cocoon Properties, Re: Cocoon 2.2 Samples Setting MultipartFilter
Max Upload Size
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 zzzz.properties.
>>
>> 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 as well.
Last ? Hmm... I'm not sure I got you point.
Anyway, what I meant is that I'd like to have a way to load project-wide
properties that cannot be overridden by block-wide ones.
Regards,
--------------------
Luca Morandini
www.lucamorandini.it
--------------------
Re: Cocoon Properties, Re: Cocoon 2.2 Samples Setting MultipartFilter
Max Upload Size
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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
Re: Cocoon Properties, Re: Cocoon 2.2 Samples Setting MultipartFilter Max Upload Size
Posted by Mark Lundquist <ml...@wrinkledog.com>.
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—
Re: Cocoon Properties, Re: Cocoon 2.2 Samples Setting MultipartFilter
Max Upload Size
Posted by Luca Morandini <lm...@ieee.org>.
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
>> done outside JARs particularly intuitive... I'd rather stick with
>> WEB-INF/cocoon/properties.
> One more level is needed which is already in the 2.1 branch (and I
> thought 2.2). The system property org.apache.cocoon.settings points to
> the directory where properties can be found. In our environment we
> never touch stuff inside war or ear files, especially since they might
> not be exploded.
If you take a look at the comments in SettingsBeanFactoryPostProcessor
source code, you'll find that plenty of configuration options are
provided, and I think Cocoon should stick to that plan rather than
dropping the WEB-INF/classes/cocoon/properties option.
Regards,
--------------------
Luca Morandini
www.lucamorandini.it
--------------------
Re: Cocoon Properties, Re: Cocoon 2.2 Samples Setting MultipartFilter
Max Upload Size
Posted by Carsten Ziegeler <cz...@apache.org>.
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 stuff
>> done outside JARs particularly intuitive... I'd rather stick with
>> WEB-INF/cocoon/properties.
> One more level is needed which is already in the 2.1 branch (and I
> thought 2.2). The system property org.apache.cocoon.settings points to
> the directory where properties can be found. In our environment we
> never touch stuff inside war or ear files, especially since they might
> not be exploded.
>
This is supported in 2.2 as well, but "org.apache.cocoon.settings" is
pointing to a file rather than a directory.
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Cocoon Properties, Re: Cocoon 2.2 Samples Setting MultipartFilter
Max Upload Size
Posted by Ralph Goers <Ra...@dslextreme.com>.
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 particularly intuitive... I'd rather stick with
> WEB-INF/cocoon/properties.
One more level is needed which is already in the 2.1 branch (and I
thought 2.2). The system property org.apache.cocoon.settings points to
the directory where properties can be found. In our environment we
never touch stuff inside war or ear files, especially since they might
not be exploded.
Re: Cocoon Properties, Re: Cocoon 2.2 Samples Setting MultipartFilter
Max Upload Size
Posted by Luca Morandini <lm...@ieee.org>.
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 last. I'll have a look at that as well.
>> Last ? Hmm... I'm not sure I got you point.
>>
> Yepp, the properties system works in the way that the last definition
> wins. And this means that project-wide stuff has to be loaded last.
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 particularly intuitive... I'd rather stick with
WEB-INF/cocoon/properties.
Regards,
--------------------
Luca Morandini
www.lucamorandini.it
--------------------
Re: Cocoon Properties, Re: Cocoon 2.2 Samples Setting MultipartFilter
Max Upload Size
Posted by Carsten Ziegeler <cz...@apache.org>.
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, unless I call them zzzz.properties.
>>>
>>> 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 as well.
>
> Last ? Hmm... I'm not sure I got you point.
> Anyway, what I meant is that I'd like to have a way to load project-wide
> properties that cannot be overridden by block-wide ones.
>
Yepp, the properties system works in the way that the last definition
wins. And this means that project-wide stuff has to be loaded last.
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/