Hi Chris The Guava issue looks to me like OSGi cannot create a consistent class space. Chain 1 is your import (version 30.1 or higher), but the problem is Chain 2, where your class-space is transitively exposed to the Guava version used by Jackrabbit Oak (I guess you're using/implementing a class/interface from org.apache.jackrabbit.oak.spi.security.authentication). IMHO this indicates that there could be a problem, but probably there isn't. It depends, I guess, on whether your code exchanges any Guava-objects with Oak. I.e. if you receive a Guava-object from Oak, it is backed by a class from Guava version 15.x, but your code only has the corresponding class from version 31.1. Then it would blow up with somewhat cryptic messages claiming that guava.Object is not a guava.Object (because they are actually different versions of the same class and thus different classes at runtime).
So the pragmatic (and maybe only possible) solution is embedding Guava, as you have done. Regards Julian On Wed, Jun 30, 2021 at 12:49 AM Cris Rockwell <[email protected]> wrote: > > Hi Robert > > > Why are there version ranges used in the pom? > I was using Maven bracket notation for version ranges that I had actually > tested. But I see it’s not needed, and removed the bracket range on the > versions. Now it builds without downloading any SNAPSHOTS. > > > > checker-qual-2.11.1.jar > > error_prone_annotations-2.3.4.jar > > failureaccess-1.0.1.jar > > These are dependencies of Google Guava, which is also an embedded dependency. > If I didn't embed Guava, the deps above wouldn’t be needed. Sling comes with > Guava v15. But OpenSAML libraries currently require 30.1.1-jre. Having a > recent version of Guava installed as a bundle could help a lot. But having > both versions as bundles doesn’t seem to work. I am getting the error below... > > [ERROR] Bundles: Cannot start > org.osgi.framework.BundleException: Uses constraint violation. Unable to > resolve resource org.apache.sling.auth.saml2 [org.apache.sling.auth.saml2 > [234](R 234.57)] because it is exposed to package 'com.google.common.base' > from resources com.google.guava [com.google.guava [251](R 251.0)] and > com.google.guava [com.google.guava [87](R 87.0)] via two dependency chains. > > Chain 1: > org.apache.sling.auth.saml2 [org.apache.sling.auth.saml2 [234](R 234.57)] > import: > (&(osgi.wiring.package=com.google.common.base)(version>=30.1.0)(!(version>=31.0.0))) > | > export: osgi.wiring.package: com.google.common.base > com.google.guava [com.google.guava [251](R 251.0)] > > Chain 2: > org.apache.sling.auth.saml2 [org.apache.sling.auth.saml2 [234](R 234.57)] > import: > (&(osgi.wiring.package=org.apache.jackrabbit.oak.spi.security.authentication)(version>=1.4.0)(!(version>=2.0.0))) > | > export: > osgi.wiring.package=org.apache.jackrabbit.oak.spi.security.authentication; > uses:=org.apache.jackrabbit.oak.commons > org.apache.jackrabbit.oak-security-spi > [org.apache.jackrabbit.oak-security-spi [104](R 104.0)] > import: > (&(osgi.wiring.package=org.apache.jackrabbit.oak.commons)(version>=1.6.0)(!(version>=2.0.0))) > | > export: osgi.wiring.package=org.apache.jackrabbit.oak.commons; > uses:=com.google.common.base > org.apache.jackrabbit.oak-commons [org.apache.jackrabbit.oak-commons [97](R > 97.0)] > import: > (&(osgi.wiring.package=com.google.common.base)(version>=15.0.0)(!(version>=21.0.0))) > | > export: osgi.wiring.package: com.google.common.base > com.google.guava [com.google.guava [87](R 87.0)] Unresolved requirements: > [[org.apache.sling.auth.saml2 [234](R 234.57)] osgi.wiring.package; > (&(osgi.wiring.package=org.apache.jackrabbit.oak.spi.security.authentication)(version>=1.4.0)(!(version>=2.0.0)))] > > > Strange that it would have this error because the Import-Package header > specifies version 30.1. So for now Guava and those three deps mentioned are > still embedded. > > Import-Package: com.codahale.metrics; version="[4.1, 5)", > com.google.common.base; version="[30.1, 31)", com.google.common.collect; > version="[30.1, 31)", com.google.common.escape; version="[30.1, 31)", > com.google.common.io; version="[30.1, 31)", com.google.common.net; > version="[30.1, 31)", > > > > > metrics-core-4.1.9.jar > > Upgrading metrics-core past v3 causes a lot of problems with many Sling > bundles. I counted ~40 bundles that went from Active to Installed state. But > when installed with parallel versions (v3 and v4) everything seems fine. > > > > velocity-engine-core-2.3.jar > > Velocity doesn’t need to be embedded. This can be installed as a bundle. > > > > commons-lang 2.6 is EOL and unmaintained, but we include it in the > > bundle. > > After updating the velocity to 2.3, commons-lang-2 is not needed. > > > > xmlsec-2.2.2.jar > > xmlsec can be installed as a bundle. > > While I agree it might be better if all the dependencies were OSGi bundles. > But there’s only so long I can go round and round with Guava. All of the deps > you mentioned that I could use as bundles are now bundles. Guava and it’s > dependencies are still embedded, and that might be fine for this release. > OpenSAML libs are also still embedded. > > Let me know your thoughts. > > Regards > Cris > > > > > On May 31, 2021, at 9:32 AM, Robert Munteanu <[email protected]> wrote: > > > > Hi, > > > > On Thu, 2021-05-27 at 15:06 -0400, Cris Rockwell wrote: > >> Hi, > >> > >> We solved 3 Jira issues in this initial release: > >> https://issues.apache.org/jira/projects/SLING/versions/12350210 < > >> https://issues.apache.org/jira/projects/SLING/versions/12350210> > >> > >> Staging repository: > >> https://repository.apache.org/content/repositories/orgapachesling-2457 > > > > Thanks for setting up the vote, I know it's been quite a journey :-) > > > > A couple of notes/questions from me, see below. > > > > 1. I tried to rebuild the source release, and it seems it's pulling in > > SNAPSHOT version from various repositories > > > > Downloading from apache.snapshots: > > https://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.auth.core/1.4.1-SNAPSHOT/maven-metadata.xml > > Downloaded from apache.snapshots: > > https://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.auth.core/1.4.1-SNAPSHOT/maven-metadata.xml > > (1.0 kB at 8.5 kB/s) > > Downloading from apache.snapshots: > > https://repository.apache.org/snapshots/org/apache/jackrabbit/oak-auth-external/1.35-SNAPSHOT/maven-metadata.xml > > Downloading from shibboleth: > > https://build.shibboleth.net/nexus/content/repositories/releases/org/apache/jackrabbit/oak-auth-external/1.35-SNAPSHOT/maven-metadata.xml > > Downloading from shibboleth: > > https://build.shibboleth.net/nexus/content/repositories/releases/org/apache/jackrabbit/oak-parent/1.35-SNAPSHOT/maven-metadata.xml > > Downloading from apache.snapshots: > > https://repository.apache.org/snapshots/org/apache/jackrabbit/oak-parent/1.35-SNAPSHOT/maven-metadata.xml > > > > (multiple occurences) > > > > I think this comes from the usage of version ranges in the pom.xml, e.g. > > > > <dependency> > > <groupId>org.apache.commons</groupId> > > <artifactId>commons-lang3</artifactId> > > <version>[3.5,3.9]</version> > > <scope>provided</scope> > > </dependency> > > > > Why are there version ranges used in the pom? > > > > 2. The depedendecy list is large, probably needed :-) but I wanted to > > ask about a couple. > > > > There are a number of jars embedded, some of then look like could be > > replaced with bundles: > > > > metrics-core-4.1.9.jar > > velocity-1.7.jar > > xmlsec-2.1.4.jar > > > > Also, do we need the checker framework and annotations at runtime? > > > > checker-qual-2.11.1.jar > > error_prone_annotations-2.3.4.jar > > > > commons-lang 2.6 is EOL and unmaintained, but we include it in the > > bundle. > > > > commons-lang-2.6.jar > > > > I think that embedding only what is needed and allowing the user to > > deploy up-to-date depedencies will improve the security standing of > > installations using the Sling saml bundle. > > > > Thanks, > > Robert > > >
