Re: [1.4] Merge ac.xconf into publication.xconf? (was: [Vote] Release 1.4 RC1)

[Andreas Hartmann <an...@apache.org>]

Joern Nettingsmeier schrieb:
> i forgot:
> 
> in the future, we should aim for a separation of program logic
> (including java code, sitemaps and other cocoon stuff as well as
> configuration) and content or data (including ac user/group data and
> usecase permissions), for three reasons:
> 
> * security: the servlet container should not have write access to the
> webapp code, but it does need to write data at runtime.
> 
> * ease of backup: the user should not be forced to backup program code
> that can easily be re-build, nor make special provisions to exclude it.
> hence, all data should be grouped together or at least be groupable.
> 
> * separation of logic and data is just Correct(tm), and the j2ee webapp
> slimeball is Wrong(tm). users who want everything in one easily
> deployable but ugly WAR-file can still do so by configuring their
> storage accordingly.
> 
> 
> specifically, this means that ac/password, ac/policies and
> usecase-policies.xml should not be under config/ but under a "store"
> directory by default, along with the content repository.

Ultimately, with the current architecture, the whole publication
directory would belong there since publications can be added during
runtime ...

With 1.4 ante portas (hopefully) we have to draw the line somewhere
for the moment. Experience tells that these changes have to be tested
thoroughly on different OSs, and I have to admit I wouldn't like to
open another construction site.

I'd suggest to merge Joern's changes, leave the configuration as
it is, and add some documentation what files to change to use an
external store location.

After 1.4 we can talk about this again. And if we decide to change
the location of config files, it is proably possible to provide a
little Ant target to update the user's installation.

-- Andreas


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org

Re: [1.4] Merge ac.xconf into publication.xconf? (was: [Vote] Release 1.4 RC1)

[Joern Nettingsmeier <ne...@folkwang-hochschule.de>]

Andreas Hartmann wrote:
> Joern Nettingsmeier schrieb:
>> i forgot:
>>
>> in the future, we should aim for a separation of program logic
>> (including java code, sitemaps and other cocoon stuff as well as
>> configuration) and content or data (including ac user/group data and
>> usecase permissions), for three reasons:
>>
>> * security: the servlet container should not have write access to the
>> webapp code, but it does need to write data at runtime.
>>
>> * ease of backup: the user should not be forced to backup program code
>> that can easily be re-build, nor make special provisions to exclude it.
>> hence, all data should be grouped together or at least be groupable.
>>
>> * separation of logic and data is just Correct(tm), and the j2ee webapp
>> slimeball is Wrong(tm). users who want everything in one easily
>> deployable but ugly WAR-file can still do so by configuring their
>> storage accordingly.
>>
>>
>> specifically, this means that ac/password, ac/policies and
>> usecase-policies.xml should not be under config/ but under a "store"
>> directory by default, along with the content repository.
> 
> Ultimately, with the current architecture, the whole publication
> directory would belong there since publications can be added during
> runtime ...

true. it would also help lenya admins a lot if sitemaps etc did not 
require re-deployment after changes but be read from the content-dir 
location directly and not be copied into the webapp directory.

> With 1.4 ante portas (hopefully) we have to draw the line somewhere
> for the moment. Experience tells that these changes have to be tested
> thoroughly on different OSs, and I have to admit I wouldn't like to
> open another construction site.

absolutely.
i just meant to bring up some general directions that we might consider 
in future changes...



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org