Issue resolving correct org.apache.servicemix.bundles.cglib bundle


Dear all,

I realized, that PAX-WICKET has an issue when working with Karaf 3.0.0 and you have already the following bundle installed before you start installing the wicket and pax-wicket features:

Conducting the following steps support reproducing the issue:

(1) Install the CGLIB ServiceMix Bundle 3.0_1

(2) Add PAX-WICKET features to Karaf and install the required features

(3) Install you application (e.g. the sample application using a BundleActivator is sufficient)

As a result you will see the following output:

The reason of this behaviour seems to be the following:

(a) The 2.2.2_1 CGLIB Bundle will be imported by "org.ops4j.pax.wicket.service"

(b) The 3.0_1 CGLIB Bundle will be imported by "org.apache.wicket.core"

Since the 3.0_1 Version does not seem to be compliant to the bundle resolution, I would recommend that wicket-core MANIFEST will be enhanced with an Import-Package statement for the correct CGLIB version (e.g. 2.2.2_1)
From Wicket 7.x onwards this might change as far as I have checked the current dependencies.

Is there a way to resolve the issue already in Wicket 6.x and PAX-WICKET 3.x?




Karaf 3.0.0


Christoph Läubrich
November 27, 2014, 6:35 AM

I think this is the a bug of wicket, if any of their packages depends on cglib they should have a proper import-package for the GBLIB version, as well as a proper use-clause on the export package. This is the only way to ensure all dependencies are wired correctly.
Can you tell what exact wicket bundle has the 'DynamicImport-Package: *' and in fact requires cglib?
Of course we can try to use resolver hook but that has some implication:

  • We must impose some sort of start-order-dependecy to make sure the resolver is startet before any other bundle or we must restart bundles already started

  • The resolver must be a seperate bundle without any dependency to wicket or pax wicket

  • If Wicket once require a special version of CG-lib it will fail with obscure "method not found" errors because we force it to wire against an older version

  • Finding dependency problem will be harder since we work "behind the scene" so users/developers get confused

Martin Grigorov
November 28, 2014, 11:21 AM


Wicket uses CGLIB for its IOC modules (Spring and Guice, to create proxies while injecting classes. For injecting interfaces Wicket uses JDK proxy.
The DynamicImport-Package is used for all modules:

None of the active Wicket developers use OSGi at daily job, so patches for the OSGi related stuff are very welcome!

Christoph Läubrich
December 3, 2014, 7:12 AM

Okay thanks for the information, or can anyone of you provide a sample application and list of required bundles that illustrate the problem? I'll then try to debug the root cause of this.
can you tell why wicket uses dynamic-imports in such a wide way instead of declaring dedicated package imports? In general DynamicImport-Package: * is considered bad style since it can lead to massive overhead when loading classes and might cause resolving issues like this as well as start-order dependencies.

Martin Grigorov
December 3, 2014, 8:20 AM

The answer is as simple as: because someone else from the OSGi community suggested this solution in the past.

Christoph Läubrich
May 10, 2016, 7:26 AM

Okay, it seems I found the issue, problem is that the CGLIB uses the clasloader of the enhanced class to load other clases as well as cglib classes so wicket-core is used to search cg-lib classes.


Christoph Läubrich


Christoph Emmersberger



Affects versions