[
https://issues.apache.org/jira/browse/JCR-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577465#action_12577465
]
Thomas Mueller commented on JCR-1462:
-
Committed in revision 635940.
This is a 'proof of
[
https://issues.apache.org/jira/browse/JCR-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577480#action_12577480
]
Marcel Reutegger commented on JCR-1462:
---
I tend to agree that the repository should not
[
https://issues.apache.org/jira/browse/JCR-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579477#action_12579477
]
Thomas Mueller commented on JCR-1462:
-
Committed in revision 637933:
XML validation is no
[
https://issues.apache.org/jira/browse/JCR-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581918#action_12581918
]
Marcel Reutegger commented on JCR-1462:
---
I'm not happy with the current situation. Now
[
https://issues.apache.org/jira/browse/JCR-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581943#action_12581943
]
Thomas Mueller commented on JCR-1462:
-
> there is a warn message in the log for every wor
[
https://issues.apache.org/jira/browse/JCR-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581970#action_12581970
]
Marcel Reutegger commented on JCR-1462:
---
> What about only logging a warning when parsi
[
https://issues.apache.org/jira/browse/JCR-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582001#action_12582001
]
Thomas Mueller commented on JCR-1462:
-
Revision 640880: throw an exception when using uns
[
https://issues.apache.org/jira/browse/JCR-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582003#action_12582003
]
Thomas Mueller commented on JCR-1462:
-
Revision 640884: log a warning when repository.xml
[
https://issues.apache.org/jira/browse/JCR-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582203#action_12582203
]
Marcel Reutegger commented on JCR-1462:
---
IMO, this issue can be set to fixed.
Thomas,
[
https://issues.apache.org/jira/browse/JCR-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582206#action_12582206
]
Thomas Mueller commented on JCR-1462:
-
> do you want to implement anything else?
Yes, th
[
https://issues.apache.org/jira/browse/JCR-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633868#action_12633868
]
Micah Whitacre commented on JCR-1462:
-
I'm not sure I have permissions to reopen this bug
[
https://issues.apache.org/jira/browse/JCR-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12634048#action_12634048
]
Marcel Reutegger commented on JCR-1462:
---
I think we should remove the DTD validation ag
[
https://issues.apache.org/jira/browse/JCR-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12634052#action_12634052
]
Alexander Klimetschek commented on JCR-1462:
What about a two-pass parsing: in th
[
https://issues.apache.org/jira/browse/JCR-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12634063#action_12634063
]
Jukka Zitting commented on JCR-1462:
How about if we set the http://apache.org/xml/featur
[
https://issues.apache.org/jira/browse/JCR-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12634072#action_12634072
]
Marcel Reutegger commented on JCR-1462:
---
Is this option implementation independent?
>
[
https://issues.apache.org/jira/browse/JCR-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12634075#action_12634075
]
Jukka Zitting commented on JCR-1462:
> Is this option implementation independent?
No, i
[
https://issues.apache.org/jira/browse/JCR-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12634118#action_12634118
]
Thomas Mueller commented on JCR-1462:
-
> how much we are actually gaining by enabling DTD
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
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
+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
-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
> 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
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
-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
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
to
and change the configuration parsi
27 matches
Mail list logo
