[
https://issues.apache.org/jira/browse/SHIRO-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16697860#comment-16697860
]
Steinar Bang commented on SHIRO-537:
------------------------------------
I discovered that the package containing the missing class was missing from
Import-Package of my bundle (probably because it is created with reflection).
So I added an explicit import for the package, but the activator still failed.
So I took a closer look at the imports of the package that failed to load and
saw something interesting: one of the imported packages is provided from two
different bundles.
(!) Having multiple bundles provide the same package is _not_ a good thing in
OSGi
I'm not entirely sure what will happen when two bundles provide the same
package in OSGi, but I _think_ what happens is that one of the packages will be
picked and only the classes in the imported package will be visible.
Details on what I did and what I saw:
# I added an explicit import for the missing package (all of the packages
formerly imported by * as well as the missing package)
{noformat}
--- a/ukelonn.web.security/pom.xml
+++ b/ukelonn.web.security/pom.xml
@@ -173,7 +173,7 @@
<Bundle-SymbolicName>${Bundle-SymbolicName}</Bundle-SymbolicName>
<Bundle-Version>${project.version}</Bundle-Version>
<Karaf-Commands>*</Karaf-Commands>
- <Import-Package>*</Import-Package>
+
<Import-Package>org.apache.shiro.web.config,javax.servlet,no.priv.bang.ukelonn,org.apache.shiro.authc,org.apache.shiro.authc.credential,org.apache.shiro.authz,org.apache.shiro.config,org.apache.shiro.mgt,org.apache.shiro.realm,org.apache.shiro.subject,org.apache.shiro.util,org.apache.shiro.web.env,org.apache.shiro.web.filter.mgt,org.apache.shiro.web.mgt,org.apache.shiro.web.servlet,org.osgi.framework,org.osgi.framework.wiring,org.osgi.service.http.context</Import-Package>
<Export-Package>!*</Export-Package>
<Include-Resource>/=target/classes/</Include-Resource>
<_removeheaders>
{noformat}
# The activator still failed with the NoClassDefFoundError
# I listed the imported packages in the WebIniSecurityManagerFactory
{noformat}
import org.apache.shiro.config
import org.apache.shiro.mgt
import org.apache.shiro.web.filter.mgt
import org.apache.shiro.web.mgt
{noformat}
# I used the package:imports command in the apache karaf console, and
discovered that one of the packages was exported by two different bundles
{noformat}
org.apache.shiro.config │
1.4.1.SNAPSHOT │ 387 │ org.apache.shiro.config.core
org.apache.shiro.config │
1.4.1.SNAPSHOT │ 388 │ org.apache.shiro.core
{noformat}
There are two possible workarounds for this:
# Rebundle shiro in a bundle that combines the split packages
# Import the .class files from the split packages into my bundle (but that will
probably introduce other class loader issues)
There are two possible fixes for this in shiro
# Rename packages so that there are no duplicates (this is the correct fix)
# Re-integrate the packages, ie. put all of the classes in a particular package
into the package in a single bundle (the easiest way to do this is to collaps
the split jars back into one)
> Class load issue in OSGI in ClassUtils
> --------------------------------------
>
> Key: SHIRO-537
> URL: https://issues.apache.org/jira/browse/SHIRO-537
> Project: Shiro
> Issue Type: Bug
> Affects Versions: 1.2.3
> Environment: OSGi Felix 4.0.3
> Reporter: Tom Nelson
> Priority: Major
>
> I had the same issue that is described in:
> http://stackoverflow.com/questions/20653146/how-to-load-class-in-an-osgi-e4-environment-while-using-shiro
> where it was suggested a bug was entered but never was, so here it is. A
> similar workaround worked for me:
> Thread currentThread = Thread.currentThread();
> ClassLoader originalCl = currentThread.getContextClassLoader();
> try {
> Class<?> clazz = ((InfrastructureServer)
> server).getBundleContext().getBundle()
>
> .loadClass(CustomRolePermissionResolver.class.getName());
> ClassLoader bundleClassLoader = clazz.getClassLoader();
> currentThread.setContextClassLoader(bundleClassLoader);
> webappContext.deploy(httpServer);
> } catch (ClassNotFoundException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } finally {
> currentThread.setContextClassLoader(originalCl);
> }
> In addition, commons-collections 3.2.1 must be used in an OSGi environment, I
> suggest bumping your dependency.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)