[ 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)