Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <708282778.1259056599815.JavaMail.jira@brutus>
Date: Tue, 24 Nov 2009 09:56:39 +0000 (UTC)
From: "angela (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Issue Comment Edited: (JCR-2399) Enable protected security
 importers by default
In-Reply-To: <865973316.1258722699963.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/JCR-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781844#action_12781844 ] 

angela edited comment on JCR-2399 at 11/24/09 9:56 AM:
-------------------------------------------------------

> but why not making our life easier?

I'm not convinced that this change would make our life any easier. this import extensions is just one piece
from a whole bunch of additional configuration and functionality extensions we need at Day in order to work 
around self made problems... and I don't think we should discuss those in the public, should we?

> btw: whatever the default is, an import should not leave the transient space in a weird state, like the 
> missing jcr:principalName properties after a user import.

that's the consequence of the compromise I agreed on, although I already wished several time I hadn't. the user nodes were protected in the past for good reasons and there was no wired state whatsoever if I hadn't agreed to relax that restriction for Day specific needs. 

      was (Author: anchela):
    > but why not making our life easier?

I'm not convinced that this change would make our life any easier. this import extensions is just one piece
from a whole bunch of additional configuration and functionality extensions we need at Day in order to work 
around self made problems... and I don't think we should discuss those in the public, shouldn't we?

> btw: whatever the default is, an import should not leave the transient space in a weird state, like the 
> missing jcr:principalName properties after a user import.

that's the consequence of the compromise I agreed on, although I already wished several time I hadn't. the user nodes were protected in the past for good reasons and there was no wired state whatsoever if I hadn't agreed to relax that restriction for Day specific needs. 
  
> Enable protected security importers by default
> ----------------------------------------------
>
>                 Key: JCR-2399
>                 URL: https://issues.apache.org/jira/browse/JCR-2399
>             Project: Jackrabbit Content Repository
>          Issue Type: Wish
>          Components: jackrabbit-core
>    Affects Versions: 2.0-beta1
>            Reporter: Tobias Bocanegra
>         Attachments: default_importers.r882540.patch
>
>
> We added those cool protected property and node importers for enabling sysview import of users,groupd and acls. unfortunately, they are only
> enabled when the respective config is set:
> <Import>
>   <ProtectedNodeImporter class="org.apache.jackrabbit.core.xml.AccessControlImporter"/>
>   <ProtectedPropertyImporter class="org.apache.jackrabbit.core.security.user.UserImporter">
>     <param name="importBehavior" value="besteffort"/>
>   </ProtectedPropertyImporter>
> </Import>
> i think we should enable them by default, i.e. for an empty config. if someone wants to disable them, they can still reference the default importers:
> <Import>
>   <ProtectedNodeImporter class="org.apache.jackrabbit.core.xml.DefaultProtectedNodeImporter"/>
>   <ProtectedPropertyImporter class="org.apache.jackrabbit.core.xml.DefaultProtectedPropertyImporter" />
> </Import>

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.