You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by mit_jones <ti...@mccarthy.co.nz> on 2013/05/22 04:08:08 UTC

Advice on general approach to solving NoClassDefFoundError/ClassNotFoundException

Hi,

I am working with a Felix/Karaf based application that has made heavy use of
DynamicImport-Package. I have been trying to remove the
DynamicImport-Package headers and replace with Import-Package. 

I have managed to do this successfully but my approach is very tedious
involving removing all existing classes from the bundle and then adding them
back class by class resolving each import package required as I go.

How can I do this in a better way? 

Alternatively for example if I just remove DynamicImport-Package and try to
install and start the bundle the exception below is printed on the Karaf
console. I cannot see how this exception can help me ultimately end up with
an Import-Package shown below.

      <Import-Package>.
            <removed  for brevity>
            org.apache.camel.builder,
            org.apache.camel.spring,
            *
     </Import-Package>



Bundle ID: 265
root > Exception in thread "SpringOsgiExtenderThread-41"
java.lang.NoClassDefFoundError: org/ops4j/pax/logging/spi/PaxAppender
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
	at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
	at org.ops4j.pax.logging.util.OsgiUtil.loadClass(OsgiUtil.java:99)
	at
org.apache.log4j.OsgiThrowableRenderer.findClass(OsgiThrowableRenderer.java:221)
	at
org.apache.log4j.OsgiThrowableRenderer.formatElement(OsgiThrowableRenderer.java:134)
	at
org.apache.log4j.OsgiThrowableRenderer.doRender(OsgiThrowableRenderer.java:105)
	at
org.apache.log4j.OsgiThrowableRenderer.doRender(OsgiThrowableRenderer.java:52)
	at
org.apache.log4j.spi.ThrowableInformation.getThrowableStrRep(ThrowableInformation.java:89)
	at
org.apache.log4j.spi.LoggingEvent.getThrowableStrRep(LoggingEvent.java:413)
	at
org.ops4j.pax.logging.service.internal.PaxLoggingEventImpl.getThrowableStrRep(PaxLoggingEventImpl.java:127)
	at
uniworks.core.logging.UniWorksLoggingAppender.convert(UniWorksLoggingAppender.java:53)
	at
uniworks.core.logging.UniWorksLoggingAppender.doAppend(UniWorksLoggingAppender.java:33)
	at
org.ops4j.pax.logging.service.internal.PaxAppenderProxy.doAppend(PaxAppenderProxy.java:63)
	at
org.ops4j.pax.logging.service.internal.AppenderBridgeImpl.append(AppenderBridgeImpl.java:39)
	at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251)
	at
org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:66)
	at org.apache.log4j.Category.callAppenders(Category.java:193)
	at org.apache.log4j.Category.forcedLog(Category.java:365)
	at org.apache.log4j.Category.log(Category.java:772)
	at
org.ops4j.pax.logging.service.internal.PaxLoggerImpl.error(PaxLoggerImpl.java:159)
	at
org.ops4j.pax.logging.internal.TrackingLogger.error(TrackingLogger.java:96)
	at org.apache.commons.logging.internal.JclLogger.error(JclLogger.java:174)
	at
org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.fail(DependencyWaiterApplicationContextExecutor.java:424)
	at
org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.stageOne(DependencyWaiterApplicationContextExecutor.java:275)
	at
org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.refresh(DependencyWaiterApplicationContextExecutor.java:169)
	at
org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:175)
	at
org.springframework.osgi.extender.internal.activator.ContextLoaderListener$2.run(ContextLoaderListener.java:716)
	at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.ClassNotFoundException:
org.ops4j.pax.logging.spi.PaxAppender
	at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
	... 38 more




Thanks,

Tim




--
View this message in context: http://apache-felix.18485.x6.nabble.com/Advice-on-general-approach-to-solving-NoClassDefFoundError-ClassNotFoundException-tp5003405.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: Advice on general approach to solving NoClassDefFoundError/ClassNotFoundException

Posted by mit_jones <ti...@mccarthy.co.nz>.
Thanks Neil.

The project uses Spring DM as you have indicated and not Blueprint. I think
not analysing the spring config files is likely to be the cause of this
issue as I know that at least the application classes are not loaded using
Class.forName().

I am fairly certain that the errors are coming from this bundle as after
adding the required Import-Package instructions (as shown above) the
exception is no longer raised and the application works as expected.

Our build process is currently tied to maven and I found reference to a
maven plugin https://github.com/toby1984/maven-dependency-analyzer-spring
that I guess ultimately makes use of the Spring analyzer mentioned in
http://www.aqute.biz/Bnd/Plugins. Thanks for information regarding the
analyser, I will look into it further.

I guess moving to Blueprint would ultimately be the best solution and if I
understand correctly the maven bundle plugin will analyse the Blueprint
config files 'out of the box'.

Tim



--
View this message in context: http://apache-felix.18485.x6.nabble.com/Advice-on-general-approach-to-solving-NoClassDefFoundError-ClassNotFoundException-tp5003405p5003433.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: Advice on general approach to solving NoClassDefFoundError/ClassNotFoundException

Posted by Neil Bartlett <nj...@gmail.com>.
I have two suggestions.

First, bnd finds all dependencies that are statically present in the .class
files, and as Richard said this is normally sufficient, but it misses
dynamically loaded classes, e.g. using Class.forName(). However it seems
like you are using Spring, so another big source of dependencies is the set
of classes named in any Spring XML files. Those are static dependencies
after all, but they are referenced from any .class file. So that is
somewhere you can look for your missing dependencies.

Now, bnd has a plugin mechanism and I think we used to have a "Spring
Analyzer" plugin that would find these XML dependencies automatically.
Unfortunately I don't know if that plugin still works, but our Blueprint
analyzer *does* still work. Have you considered using Blueprint instead of
plain Spring in your bundle? It's basically the same as Spring but with
explicit OSGi support.

My second suggestion is that maybe the errors are coming from another
bundle entirely? When you see a CNFE/NCDFE it's not always obvious which
bundle was the cause, so before messing with Import-Package on this bundle,
make sure it's this bundle with the problem.

Regards
Neil


On Thu, May 23, 2013 at 10:11 PM, mit_jones <ti...@mccarthy.co.nz> wrote:

> Thanks Richard.
>
> I will investigate further as to why the classes cannot be detected.
> Although I am fairly certain that at least some of the classes are not
> loaded as you described. For example the imported package
> 'uniworks.core.ejb' refers to a custom annotation.
>
> In our case it is a little frustrating that all of the application bundles
> require a non default Import-Package instruction (or
> DynamicImport-Package).
> This is in contrast to what appears to be the norm as inferred from
> http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html"The
> default for this header is "*", resulting in importing all referred
> packages. This header *rarely* has to be explicitly specified".
>
> Given that bnd is unable to detect the classes required and therefore one
> must wait until runtime for an exception that contains no information that
> points to the required class it makes it difficult to work out which
> package
> is actually required for the Import-Package instruction.
>
> So is it normal to see what amounts to an essentially non useful exception
> or is there likely something in our set up that is obscuring the real
> exception that would point either directly or indirectly to the unfindable
> class?
>
>
> Tim
>
>
>
>
>
> --
> View this message in context:
> http://apache-felix.18485.x6.nabble.com/Advice-on-general-approach-to-solving-NoClassDefFoundError-ClassNotFoundException-tp5003405p5003431.html
> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>

Re: Advice on general approach to solving NoClassDefFoundError/ClassNotFoundException

Posted by mit_jones <ti...@mccarthy.co.nz>.
Thanks Richard.

I will investigate further as to why the classes cannot be detected.
Although I am fairly certain that at least some of the classes are not
loaded as you described. For example the imported package
'uniworks.core.ejb' refers to a custom annotation.

In our case it is a little frustrating that all of the application bundles
require a non default Import-Package instruction (or DynamicImport-Package).
This is in contrast to what appears to be the norm as inferred from
http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html "The
default for this header is "*", resulting in importing all referred
packages. This header *rarely* has to be explicitly specified".

Given that bnd is unable to detect the classes required and therefore one
must wait until runtime for an exception that contains no information that
points to the required class it makes it difficult to work out which package
is actually required for the Import-Package instruction. 

So is it normal to see what amounts to an essentially non useful exception
or is there likely something in our set up that is obscuring the real
exception that would point either directly or indirectly to the unfindable
class?


Tim





--
View this message in context: http://apache-felix.18485.x6.nabble.com/Advice-on-general-approach-to-solving-NoClassDefFoundError-ClassNotFoundException-tp5003405p5003431.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: Advice on general approach to solving NoClassDefFoundError/ClassNotFoundException

Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 5/22/13 16:16 , mit_jones wrote:
> Richard, sorry I should have said that we use the maven-bundle-plugin (v
> 2.3.7) which I understand uses bnd to produce the manifest file.
>
> So if I were to instruct the default <Import-Package>*</Import-Package> I
> get the exception above. However if I instruct
>
>                          <Import-Package>org.springframework.aop,
>                                          org.springframework.aop.framework,
>                                          org.aopalliance.aop,
>                                          org.apache.camel.builder,
>                                          org.apache.camel.spring,
>                                          net.sf.cglib.proxy,
>                                          net.sf.cglib.core,
>                                          org.apache.camel,
>                                          uniworks.core.ejb,
>                                          uniworks.interfaces.processors,
>                                          uniworks.livestock.api,
>                                          uniworks.reporting.api,
>                                          *
>                          </Import-Package>
>
> then all is okay. So for whatever reason the maven bundle plugin and I
> assume therefore bnd is unable to 'calculate' the required list of imports.

Ok, I was confused.

Yes, the simple "*" should calculate everything you need, unless someone 
is doing something in a way that cannot be detected (e.g., loading a 
class by a configured string or something). In such a case, dynamic 
import would work where static imports would fail.

If you are aware of such cases, then you should either use dynamic 
imports for those specific cases, since that is why they were created. 
Or if you know that this will always be the value you can just manually 
add that package to your static import set above.

-> richard

>
> Tim
>
>
>
>
>
>
> --
> View this message in context: http://apache-felix.18485.x6.nabble.com/Advice-on-general-approach-to-solving-NoClassDefFoundError-ClassNotFoundException-tp5003405p5003421.html
> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: Advice on general approach to solving NoClassDefFoundError/ClassNotFoundException

Posted by mit_jones <ti...@mccarthy.co.nz>.
Richard, sorry I should have said that we use the maven-bundle-plugin (v
2.3.7) which I understand uses bnd to produce the manifest file. 

So if I were to instruct the default <Import-Package>*</Import-Package> I
get the exception above. However if I instruct

                        <Import-Package>org.springframework.aop,
                                        org.springframework.aop.framework,
                                        org.aopalliance.aop,
                                        org.apache.camel.builder,
                                        org.apache.camel.spring,
                                        net.sf.cglib.proxy,
                                        net.sf.cglib.core,
                                        org.apache.camel,
                                        uniworks.core.ejb, 
                                        uniworks.interfaces.processors,
                                        uniworks.livestock.api,
                                        uniworks.reporting.api,
                                        *
                        </Import-Package>

then all is okay. So for whatever reason the maven bundle plugin and I
assume therefore bnd is unable to 'calculate' the required list of imports. 

Tim






--
View this message in context: http://apache-felix.18485.x6.nabble.com/Advice-on-general-approach-to-solving-NoClassDefFoundError-ClassNotFoundException-tp5003405p5003421.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: Advice on general approach to solving NoClassDefFoundError/ClassNotFoundException

Posted by "Richard S. Hall" <he...@ungoverned.org>.
Perhaps I'm confused, but why don't you just use bnd to rewrap the JAR 
file and generate its OSGi metadata?

-> richard

On 5/21/13 22:08 , mit_jones wrote:
> Hi,
>
> I am working with a Felix/Karaf based application that has made heavy use of
> DynamicImport-Package. I have been trying to remove the
> DynamicImport-Package headers and replace with Import-Package.
>
> I have managed to do this successfully but my approach is very tedious
> involving removing all existing classes from the bundle and then adding them
> back class by class resolving each import package required as I go.
>
> How can I do this in a better way?
>
> Alternatively for example if I just remove DynamicImport-Package and try to
> install and start the bundle the exception below is printed on the Karaf
> console. I cannot see how this exception can help me ultimately end up with
> an Import-Package shown below.
>
>        <Import-Package>.
>              <removed  for brevity>
>              org.apache.camel.builder,
>              org.apache.camel.spring,
>              *
>       </Import-Package>
>
>
>
> Bundle ID: 265
> root > Exception in thread "SpringOsgiExtenderThread-41"
> java.lang.NoClassDefFoundError: org/ops4j/pax/logging/spi/PaxAppender
> 	at java.lang.ClassLoader.defineClass1(Native Method)
> 	at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
> 	at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
> 	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
> 	at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
> 	at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
> 	at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> 	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> 	at org.ops4j.pax.logging.util.OsgiUtil.loadClass(OsgiUtil.java:99)
> 	at
> org.apache.log4j.OsgiThrowableRenderer.findClass(OsgiThrowableRenderer.java:221)
> 	at
> org.apache.log4j.OsgiThrowableRenderer.formatElement(OsgiThrowableRenderer.java:134)
> 	at
> org.apache.log4j.OsgiThrowableRenderer.doRender(OsgiThrowableRenderer.java:105)
> 	at
> org.apache.log4j.OsgiThrowableRenderer.doRender(OsgiThrowableRenderer.java:52)
> 	at
> org.apache.log4j.spi.ThrowableInformation.getThrowableStrRep(ThrowableInformation.java:89)
> 	at
> org.apache.log4j.spi.LoggingEvent.getThrowableStrRep(LoggingEvent.java:413)
> 	at
> org.ops4j.pax.logging.service.internal.PaxLoggingEventImpl.getThrowableStrRep(PaxLoggingEventImpl.java:127)
> 	at
> uniworks.core.logging.UniWorksLoggingAppender.convert(UniWorksLoggingAppender.java:53)
> 	at
> uniworks.core.logging.UniWorksLoggingAppender.doAppend(UniWorksLoggingAppender.java:33)
> 	at
> org.ops4j.pax.logging.service.internal.PaxAppenderProxy.doAppend(PaxAppenderProxy.java:63)
> 	at
> org.ops4j.pax.logging.service.internal.AppenderBridgeImpl.append(AppenderBridgeImpl.java:39)
> 	at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251)
> 	at
> org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:66)
> 	at org.apache.log4j.Category.callAppenders(Category.java:193)
> 	at org.apache.log4j.Category.forcedLog(Category.java:365)
> 	at org.apache.log4j.Category.log(Category.java:772)
> 	at
> org.ops4j.pax.logging.service.internal.PaxLoggerImpl.error(PaxLoggerImpl.java:159)
> 	at
> org.ops4j.pax.logging.internal.TrackingLogger.error(TrackingLogger.java:96)
> 	at org.apache.commons.logging.internal.JclLogger.error(JclLogger.java:174)
> 	at
> org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.fail(DependencyWaiterApplicationContextExecutor.java:424)
> 	at
> org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.stageOne(DependencyWaiterApplicationContextExecutor.java:275)
> 	at
> org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.refresh(DependencyWaiterApplicationContextExecutor.java:169)
> 	at
> org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:175)
> 	at
> org.springframework.osgi.extender.internal.activator.ContextLoaderListener$2.run(ContextLoaderListener.java:716)
> 	at java.lang.Thread.run(Thread.java:662)
> Caused by: java.lang.ClassNotFoundException:
> org.ops4j.pax.logging.spi.PaxAppender
> 	at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> 	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> 	... 38 more
>
>
>
>
> Thanks,
>
> Tim
>
>
>
>
> --
> View this message in context: http://apache-felix.18485.x6.nabble.com/Advice-on-general-approach-to-solving-NoClassDefFoundError-ClassNotFoundException-tp5003405.html
> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org