[
https://issues.apache.org/jira/browse/JCR-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15635685#comment-15635685
]
Jeffrey Bornemann commented on JCR-4050:
----------------------------------------
Thanks for your response!
I'm not sure we explored JCR-remoting. At the time Grabbit was conceived, I
know we explored vlt, and recap. We were using the AEM Package Manager at the
time, and were looking for scalable, less time-consuming options. Since then,
we have implemented other ways within Grabbit to improve performance beyond
number of handshakes, such as compression, batch processing, delta syncing,
etc. We have had some pretty decent community involvement, and contribution
since then. Some of our users report syncing to 100+ nodes at a time
effectively, and within reasonable time. We might have to take a look at the
improvements you mentioned to see if we can draw any inspiration.
I'm certainly happy to explore options, but I suspect anything that is a major
deviation from the tools current approach is probably not a good trade from our
current working, but less than ideal interaction with jackrabbit-api.
rep:password is really the only "black sheep" we have had to poke at in the
UserManager API to get it to behave the way we need it to.
> Allow creation of users with existing password hashes in UserManager
> ---------------------------------------------------------------------
>
> Key: JCR-4050
> URL: https://issues.apache.org/jira/browse/JCR-4050
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-api, jackrabbit-core, security
> Reporter: Jeffrey Bornemann
> Priority: Minor
>
> We utilize the UserManager API within Grabbit for syncing authorizable nodes
> between servers.
> Unfortunately, when it comes to syncing users, and specifically setting
> passwords from existing users; we have no public API facing way to create
> users with existing password hashes. We currently have to resort to using
> reflection, grabbing internal tree objects, and a bunch of nastiness that we
> would love to avoid with this change.
> Other consumers may also find this useful.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
