-1 for having the security-manager optional.
the security section has been completely reworked
and the security-manager is a key functionality.
up to know the access-manager was the only mandatory
element in the security section. with the new security
code it could even be the other way round:
Why is that?
If we want to be backward compatible, that means if Jackrabbit 1.5
should 'just work' with old repository.xml files, then we need to
'make it work' if no SecurityManager is configured. That means we need
to define what is the default security manager.
Once we say 'use the default
Alexander Klimetschek wrote:
On Wed, Sep 24, 2008 at 2:25 PM, Jukka Zitting [EMAIL PROTECTED] wrote:
The question is, should the 1.5 upgrade changes in configuration files
or not? I would rather opt for a smoother upgrade with more backwards
compatibility, but I acknowledge that there are good
-1 for having the security-manager optional.
If it is not optional, we are obviously not backward compatible.
someone having an 1.4 configuration with a custom
access manager would be forced to change it anyway.
I believe most users use the default settings.
so, the question is
Angela Schreiber schrieb:
-1 for having the security-manager optional.
If it is not optional, we are obviously not backward compatible.
someone having an 1.4 configuration with a custom
access manager would be forced to change it anyway.
I believe most users use the default settings.
thomas and myself had a private conversation on that
issue and found a compromise:
have everything in the security configuration optional
would avoid any misconception regarding the relation
between security-manager and access-manager.
i.e. change dtd from
!ELEMENT Security (SecurityManager,
Hi,
On Wed, Sep 24, 2008 at 2:06 PM, Thomas Mueller (JIRA) [EMAIL PROTECTED]
wrote:
Compatibility: Jackrabbit 1.5 will not work with 1.4 repository.xml files
because of
JCR-1472 (SecurityManager). If we want to make the repository.xml backward
compatible,
we should have a look at that as
On Wed, Sep 24, 2008 at 2:25 PM, Jukka Zitting [EMAIL PROTECTED] wrote:
The question is, should the 1.5 upgrade changes in configuration files
or not? I would rather opt for a smoother upgrade with more backwards
compatibility, but I acknowledge that there are good reasons why we
might want
+1 for being backwards compatible in a minor 1.x release
In that case the SecurityManager setting should be truly optional: no
warning should be logged if it is missing.
Hi,
On Wed, Sep 24, 2008 at 8:52 PM, Thomas Müller [EMAIL PROTECTED] wrote:
In that case the SecurityManager setting should be truly optional: no
warning should be logged if it is missing.
Why is that?
We can (and should) deprecate old configurations like ones with no
SecurityManager or no
10 matches
Mail list logo
