java.lang.IllegalAccessError when using LdapFilter

[mcculls]

Originally reported on Google Code with ID 71

The line 

AttributeFilter ldap = Filters.ldap("(module=three)");

produce the following Stack trace 

Exception in thread "main" java.lang.IllegalAccessError: tried to access class org.osgi.framework.FrameworkUtil$FilterImpl
from class org.ops4j.peaberry.internal.FrameworkUtil
    at org.ops4j.peaberry.internal.FrameworkUtil.createFilter(FrameworkUtil.java:76)
    at org.ops4j.peaberry.util.ldap.LdapAttributeFilter.<init>(LdapAttributeFilter.java:39)
    at org.ops4j.peaberry.util.Filters.ldap(Filters.java:43)
    at Test.main(Test.java:11)

Using Peaberry 1.2

Reported by jerome.joslet on 2012-01-04 09:05:34

[mcculls]

I think the issue comes from the jarjar plugin configuration

Reported by romain.gilles on 2012-07-27 22:00:54

[mcculls]

I would like to know why there are those specific rules:

            <rule>
              <pattern>org.osgi.framework.Filter</pattern>
              <result>org.ops4j.peaberry.internal.Filter</result>
            </rule>
            <rule>
              <pattern>org.osgi.framework.FrameworkUtil</pattern>
              <result>org.ops4j.peaberry.internal.FrameworkUtil</result>
            </rule>
            <rule>
              <pattern>org.osgi.framework.InvalidSyntaxException</pattern>
              <result>org.ops4j.peaberry.internal.InvalidSyntaxException</result>
            </rule>

Reported by romain.gilles on 2012-07-27 22:03:34

[mcculls]

There was a feature request for the filter code to work outside of OSGi, so we embed
a filter implementation plus its API - since neither the API or implementation are
exposed outside of the bundle it is meant to be jarjar'd so that it is truly independent
whether running inside OSGi or part of a classic Java classpath.

It looks like the jarjar repackaging is missing the filter subclass, which would explain
the exception.

Reported by mcculls on 2012-07-28 00:18:27

[mcculls]

So clearly if you remove those rules everything work fine. Those rules are here to make
filter available outside maven environment?

Reported by romain.gilles on 2012-07-28 11:49:43

[mcculls]

The main reason to jarjar the filter implementation is to avoid classpath conflicts
when running outside of OSGi, and to avoid exposing a dependency on a full OSGi implementation
when we really only require the LDAP filter.

Reported by mcculls on 2012-07-28 11:54:49

[mcculls]

Yes the error comes from the missing inner class. Jarjar does not handle the inner class
or something like that with this configuration.
Are you sure that this configuration will be enough because if you have a look to the
Filter class it required the ServiceReference and then by transitivity Bundle and ...

Romain

Reported by romain.gilles on 2012-07-28 11:55:14

[mcculls]

I'm able to reproduce the issue with an integration test (pax exam) added in the peaberry.activation.test
project.
----
Tests in error: 
  testLdap(org.ops4j.peaberry.util.FiltersTest): org/osgi/framework/FrameworkUtil$FilterImpl

Tests run: 11, Failures: 0, Errors: 1, Skipped: 0
----

Romain

Reported by romain.gilles on 2012-07-28 12:26:44

[mcculls]

I have updated the jarjar configuration as follow:
<rule>
     <pattern>org.osgi.framework.FrameworkUtil*</pattern>
     <result>org.ops4j.peaberry.internal.FrameworkUtil@1</result>
</rule>
By this way all the inner classes are moved but I still have the same exception.

Reported by romain.gilles on 2012-07-28 12:33:20

[mcculls]

I've added a basic test and a fix to the jarjar config - make sure you rebuild from
the top-level directory.

Reported by mcculls on 2012-07-28 13:09:14

[mcculls]

Ok everything works on my side I think the issue can be close.
May I suggest you something?
I think the new peaberry integration test project for this test in particular should
not depends on 'osgi.core'.
I have created a patch that reorganize this dependency.

Romain.

Reported by romain.gilles on 2012-07-29 14:39:08

---

• _Attachment: reorganize_osgi_core_dependency.patch_

[mcculls]

peaberry.tests/pom.xml currently excludes compile/system/provided scope dependencies
in the surefire configuration, to make sure inherited compile dependencies don't accidentally
leak onto the test classpath:

   http://maven.apache.org/plugins/maven-surefire-plugin/examples/configuring-classpath.html#Removing_Dependency_Classpath_Elements

But yes, probably worth cleaning up the parent dependencies to avoid such a leak in
the first place.

Reported by mcculls on 2012-07-29 15:14:58

• Status changed: Fixed