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?
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
Wicket uses CGLIB for its IOC modules (Spring and Guice, https://github.com/apache/wicket/blob/master/wicket-ioc/pom.xml#L36) to create proxies while injecting classes. For injecting interfaces Wicket uses JDK proxy.
The DynamicImport-Package is used for all modules: https://github.com/apache/wicket/blob/master/pom.xml#L652.
None of the active Wicket developers use OSGi at daily job, so patches for the OSGi related stuff are very welcome!
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.
The answer is as simple as: because someone else from the OSGi community suggested this solution in the past.
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.