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
to
and change the configuration parsi
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.
-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 whethe
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
> 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 S
-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: t
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
+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.
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 wa
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 th
10 matches
Mail list logo