Latest Sling snapshots break trunk

[Ray Davis]

Just a quick warning that the newest Sling SNAPSHOT bundles will bust
Nakamura (message appended below). Checking out and building Sling rev
964331 (from before the upgrade to Jackrabbit 2.1) fixes the issue.

Best,
Ray

...
25.07.2010 13:22:20.751 *ERROR* [FelixDispatchQueue]
org.sakaiproject.nakamura.securityloader FrameworkEvent ERROR
(org.osgi.framework.BundleException: Unresolved constraint in bundle
org.sakaiproject.nakamura.auth.trusted [78]: package;
(&(package=org.apache.jackrabbit.api.security.principal)(version>=2.1.0)))
org.osgi.framework.BundleException: Unresolved constraint in bundle
org.sakaiproject.nakamura.auth.trusted [78]: package;
(&(package=org.apache.jackrabbit.api.security.principal)(version>=2.1.0))
at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3295)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1653)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1124)
at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264)
at java.lang.Thread.run(Thread.java:637)
...

[Ian Boston]

And at the moment a change to Jackrabbit 2.1 makes it impossible to upgrade. I feared the might be the case when the changes to Sling were proposed but didn't have time to gather the evidence.

One of the classes we depend on now has a private constructor so we cant use it, I am looking into it now to see of there is anyway round this, without patching Jackrabbit.
If there isn't we will be stuck on Jackrabbit 2.0 or we will have to drop all of the timed release and related use cases.

Makes me wonder if we shouldn't just fix on a working Snapshot version of Sling and not follow head anymore ? It would be a pity since we would be unable to contribute anything back to Sling.

Ian

> --
> You received this message because you are subscribed to the Google Groups "Sakai Nakamura" group.
> To post to this group, send email to sakai-...@googlegroups.com.
> To unsubscribe from this group, send email to sakai-kernel...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sakai-kernel?hl=en.
>

[Clay Fenlason]

There was a time when I thought that our alignment with Jackrabbit was
straightforward, and Sling was the wildcard. The feeling is growing on
me that the real situation is the reverse.

I don't of course understand the internals for ACLs that force our
authn/authz gymnastics and JR patching, and I might be misconstruing
how these problems enter in, but I'm wondering if at some point we
need to take on a serious team effort to try to insulate ourselves
from JR a bit better. I don't doubt that Ian has arrived at a
technical design as good as can be managed in the time available, or
maybe taking time to have the whole team focus on a robust solution
might put us in better stead, or maybe we just come to some agreement
on how to manage workarounds for JR upgrades.

It may be that our present course is the best that can be hoped for,
but it's feeling like our strategy is brittle (against the backdrop of
JR's evolution) and a source of project risk.

~Clay

[Ian Boston]

While neither JR and the JCR Specification don't support all our use cases we are going to be vulnerable to modifications in Jackrabbit core.
There is no reason why the JCR Spec or JR core below the API should support our use cases, other than the fact we think its important.
Its also unreasonable to expect Jackrabbit core below the JCR Spec not to change things just because we have been forced to bind to implementation code and need to do things with it that were not intended.

There is a robust solution.
We implement our own Access Control Provider for Jackrabbit and maintain it, but that would probably require a significant commitment of time from a really good java dev.

Ian

[Clay Fenlason]

Comments in-line.

On Mon, Jul 26, 2010 at 8:49 AM, Ian Boston <i...@tfd.co.uk> wrote:
> While neither JR and the JCR Specification don't support all our use cases we are going to be vulnerable to modifications in Jackrabbit core.
> There is no reason why the JCR Spec or JR core below the API should support our use cases, other than the fact we think its important.
> Its also unreasonable to expect Jackrabbit core below the JCR Spec not to change things just because we have been forced to bind to implementation code and need to do things with it that were not intended.

Right. Nothing in my remarks was directed at what JR should be doing.
Just trying to get clearer about what we should be doing in light of
it.

> There is a robust solution.
> We implement our own Access Control Provider for Jackrabbit and maintain it, but that would probably require a significant commitment of time from a really good java dev.

OK, thanks. That sounds like the reference point against which we
should measure these occasional bouts of disruption. I take it that so
far we're still rather beneath that threshold of effort.

~Clay

[Ian Boston]

Update:
I have got server to compile, and startup but most of the ACL integration tests are now broken.
Even a very simple write:deny for a single user on a single node, doesn't work any more, still investigating.
Ian

[Carl Hall]

As a workaround in one case, as I was working with the opensso bundle last night, I added this in the import-package to make it wire up correctly:

org.apache.jackrabbit.api.*;version=0.0,

Theoretically, you should be able to use something like:

org.apache.jackrabbit.api.*;version="[2.0,2.1)"

but I got a parse error and went with the easy 0.0.

[Ian Boston]

All fixed now, however I done believe what I have done will be sustainable longer term so expect some problems at the next upgrade to Jackrabbit, if there is one.
Ian