Hi Rory,
Rory Douglas schrieb:
> While following the steps in [1] to configure the Jackrabbit 1.5
> DefaultAccessManager, I had to update the jackrabbit-api bundle
> configuration in the POM a little:
>
> 1) Updated <Export-Package> from: org.apache.jackrabbit.api;version=1.4
> to: org.apache.jackrabbit.api.*;version=1.5.0
> 2) Updated <dependency> version to 1.5.0
>
> This solved errors relating to references to
> org.apache.jackrabbit.api.security.user/principal packages.
I did not update the Sling jackrabbit-api bundle, because starting with
1.5.0, the Jackrabbit API library from the Jackrabbit project is already
a proper bundle and contains all required headers, such as the exports.
Therfore, I think that we will most probably discontinue the Sling
jcr/jackrabbit-api module and instead start using the Jackrabbit API
library directly.
So, in your case, just deploy the jackrabbit-api-1.5.0.jar and remove
the Sling Jackrabbit API bundle.
>
>
> I also updated the embedded dependencies of jackrabbit-server bundle
> configuration in the POM to match those mentioned in Jackrabbit 1.5
> release notes:
>
> 3) Changed/added the following:
> pdfbox;version=0.7.3,
> fontbox;version=0.1.0,
> jempbox;version=0.2.0,
> poi;version=3.0.2-FINAL,
> poi-scratchpad;version=3.0.2-FINAL,
Cool, could you please create an issue attaching pom.xml patch ? That
would be great.
>
> 4) Removed the direct nekohtml dependency (the newest 1.9.7 version gets
> pulled in via jackrabbit-text-extractors dependency).
Assume, this would be included in the patch to (3)
>
>
> Lastly, to follow the final step in [1] (actually updating an ACL on a
> node), you need to get the AccessControlManager, which is currently only
> available on the SessionImpl class (<sigh>), so I retained my
> jackrabbit-server POM tweak to make those o.a.j.core classes visible
> outside the bundle:
>
> <Export-Package>
> org.apache.jackrabbit.core.*,
> org.apache.jackrabbit.spi.*
> </Export-Package>
>
>
> That last tweak is ugly, and could perhaps be avoided by exporting a
> utility class from the jackrabbit-server bundle that can return the
> AccessControlManager without exposing the o.a.j.core classes (say,
> AccessControlUtil.getAccessControlManager(Session session))?
I agree whole-heartedly about this. I would not want to add this export
and was thinking about applying some API tweaks in the jackrabbit support.
But providing a utility method is proably the better solution. How about
something like this (without error handling):
AccessControlManager getAccessControlManager(Session session) {
if (session instanceof PooledSession) {
session = ((PooledSession) session).getSession();
}
Method m =
session.getClass().getMethod("getAccessControlManager");
return (AccessControlManager) m.invoke();
}
I would think, such a method would go into the o.a.s.jcr.base.util
package of the jcr/base bundle. WDYT ?
Once, the API is available, the utility method would be re-written to
make use of the API.
WDYT ?
Please note, that JSR-283 has not been finalized yet and is still being
worked on. See issue JCR-1588[1] for more information about the work
being done in the area of security. I hope there will be a release of
either the 1.5 line or the 1.6 trunk soon, which incorporates more
up-to-date implementations.
Regards
Felix
[1] https://issues.apache.org/jira/browse/JCR-1588
>
> Regards,
> Rory
>
> [1] http://www.nabble.com/Jackrabbit-1.5-Security-td21080602.html
>
>
> Felix Meschberger wrote:
>> Hi all again,
>>
>> Well, I think, I have finished upgrading to Jackrabbit 1.5. There may be
>> glitches, which should be fixed in the next few days...
>>
>> Please report any issues, you might find. Thanks.
>>
>> Regards
>> Felix
>>
>> Felix Meschberger schrieb:
>>
>>> Hi all,
>>>
>>> I am currently committing the changes to use Jackrabbit 1.5 in Sling.
>>> This may result in temporary failure building Sling.
>>>
>>> As soon as I am done, I will inform you.
>>>
>>> Regards
>>> Felix
>>>
>>>
>
