Eclipse Community Forums: Virgo » Class not found mystery

Home » Eclipse Projects » Virgo » Class not found mystery

Class not found mystery [message #783817]

Thu, 26 January 2012 09:23

Eclipse User

Hello everyone.

I have the following issue: when I run my app on top of a Virgo Kernel, I get the following intermittent error:

Exception in thread "pool-2-thread-1" org.eclipse.virgo.kernel.osgi.framework.ExtendedNoClassDefFoundError: org/apache/http/impl/cookie/AbstractCookieSpec in KernelBundleClassLoader: [bundle=com.springsource.org.apache.httpcomponents.httpclient_4.1.1] in KernelBundleClassLoader: [bundle=com.springsource.org.apache.httpcomponents.httpclient_4.1.1] in KernelBundleClassLoader: [bundle=com.springsource.org.apache.httpcomponents.httpclient_4.1.1] in KernelBundleClassLoader: [bundle=com.springsource.org.apache.httpcomponents.httpclient_4.1.1] in KernelBundleClassLoader: [bundle=com.springsource.org.apache.httpcomponents.httpclient_4.1.1] in KernelBundleClassLoader: [bundle=com.springsource.org.apache.httpcomponents.httpclient_4.1.1]
	at org.eclipse.virgo.kernel.userregion.internal.equinox.KernelBundleClassLoader.loadClass(KernelBundleClassLoader.java:140)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
	at org.apache.http.impl.cookie.BestMatchSpec.getStrict(BestMatchSpec.java:75)
	at org.apache.http.impl.cookie.BestMatchSpec.getVersion(BestMatchSpec.java:209)
	at org.apache.http.client.protocol.RequestAddCookies.process(RequestAddCookies.java:202)
	at org.apache.http.protocol.ImmutableHttpProcessor.process(ImmutableHttpProcessor.java:108)
	at org.apache.http.protocol.HttpRequestExecutor.preProcess(HttpRequestExecutor.java:174)
	at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:452)
	at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
	at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:754)
	at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:732)
	at uk.co.igindex.springrest.client.AbstractHTTPClientRequest.execute(AbstractHTTPClientRequest.java:60)
	at uk.co.igindex.springrest.client.RequestProxyImpl.executeRequest(RequestProxyImpl.java:300)
	at uk.co.igindex.springrest.client.RequestProxyImpl.doGet(RequestProxyImpl.java:247)
	at com.iggroup.wt.pendingaccount.client.PendingAccountClientImpl.getPendingAccountProcesses(PendingAccountClientImpl.java:96)
	at com.iggroup.wb.workbench.accounts.accountopening.data.PendingAccountsController.getAccountsByStage(PendingAccountsController.java:96)
	at com.iggroup.wb.workbench.accounts.accountopening.data.PendingAccountsController.access$000(PendingAccountsController.java:16)
	at com.iggroup.wb.workbench.accounts.accountopening.data.PendingAccountsController$GetPendingAccountsByStageJob.run(PendingAccountsController.java:59)
	at com.iggroup.wb.core.common.utils.CommonsThreadPool$FixedSizeThreadPool$3.run(CommonsThreadPool.java:72)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:662)
Caused by: org.eclipse.virgo.kernel.osgi.framework.ExtendedNoClassDefFoundError: org/apache/http/impl/cookie/AbstractCookieSpec in KernelBundleClassLoader: [bundle=com.springsource.org.apache.httpcomponents.httpclient_4.1.1] in KernelBundleClassLoader: [bundle=com.springsource.org.apache.httpcomponents.httpclient_4.1.1] in KernelBundleClassLoader: [bundle=com.springsource.org.apache.httpcomponents.httpclient_4.1.1] in KernelBundleClassLoader: [bundle=com.springsource.org.apache.httpcomponents.httpclient_4.1.1] in KernelBundleClassLoader: [bundle=com.springsource.org.apache.httpcomponents.httpclient_4.1.1]
	at org.eclipse.virgo.kernel.userregion.internal.equinox.KernelBundleClassLoader.defineClass(KernelBundleClassLoader.java:242)
	at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:601)
	at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:567)
	at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:490)
	at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass_LockClassLoader(ClasspathManager.java:478)
	at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:458)
	at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216)
	at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:400)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:476)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:429)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:417)
	at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)

In the first place, the stack trace seems to imply that the same bundle that contains the class in question (com.springsource.org.apache.httpcomponents.httpclient) cannot find it at runtime, which is odd.

Secondly, when I inspect bundles in the Virgo console, I can see that bundle com.springsource.org.apache.httpcomponents.httpclient is active and that it correctly contains the class in question (via "clhas" command) and it exports it, as expected.

Finally, the problem is, as I said, intermittent, but I cannot figure out what that may mean.

What may be going wrong?

TIA,
B.

Re: Class not found mystery [message #783833 is a reply to message #783817]

Thu, 26 January 2012 09:58

Eclipse User

This is a strange one. The bundle has no optional imports, so since it has resolved successfully, its class loading behaviour should be predictable.

One thing looks a bit fishy: I don't remember seeing diagnostics with repeated "in KernelBundleClassLoader: [bundle=...] ..." sequences before. But that may be a red herring and I'm not sure what it suggests.

It's possible there is a JVM class loading issue. You might try specfifying the JVM argument -verbose:class although this may cause other issues because of the volume of output.

My final suggestion is to attach a debugger and put a breakpoint on ExtendedNoClassDefFoundError being thrown. With a bit of luck you'll be able use drop to frame to repeatedly attempt the load and then debug as close to the JVM native methods as you can get. Not for the faint hearted I'm afraid.

Re: Class not found mystery [message #783835 is a reply to message #783833]

Thu, 26 January 2012 10:03

Eclipse User

Thanks for the suggestions, Glyn. Not terribly encouraging, but I'll embark on the adventure!... Wink

Re: Class not found mystery [message #783872 is a reply to message #783835]

Thu, 26 January 2012 11:18

Eclipse User

Hi,

NoClassDefFoundError basically means that the class is there but something else prevented loading. Most probable causes:
* Exceptions in static block
* Missing imported class
* Class version mismatch (class is compiled with incompatible JVM)

Can you please check with clload command if the class can really be loaded from com.springsource.org.apache.httpcomponents.httpclient?

If the bundle can load the class then perhaps incorrect loader is used in the chain.

Regards,
Hristo Iliev

Re: Class not found mystery [message #784244 is a reply to message #783872]

Fri, 27 January 2012 03:43

Eclipse User

Hi Hristo, thank you very much for your explanation.

I have tried clload and indeed the bundle loads the class without problems. A clexport also shows the dependencies I would expect.

So how to reason about the class loader chaining problem you suggest, in this context? Any hint?

Thanks again,
B.

Re: Class not found mystery [message #784266 is a reply to message #784244]

Fri, 27 January 2012 04:15

Eclipse User

Hi,

From the stack it seems the load call is initiated by web request. I suppose that the loader used in this case is somehow different from the bundle loader.

Can you get some information about the exact loader used in KernelBundleClassLoader.loadClass? A breakpoint in BestMatchSpec.getStrict seems like a good starting point.

Regards,
Hristo Iliev

Re: Class not found mystery [message #784288 is a reply to message #784266]

Fri, 27 January 2012 04:50

Eclipse User

Excellent, will try that, thanks!

Re: Class not found mystery [message #784349 is a reply to message #784288]

Fri, 27 January 2012 06:47

Eclipse User

A little more grist for the mill.

When everything works like a Swiss clock and I do a clload for the class, I get:

osgi> clload org.apache.http.impl.cookie.AbstractCookieSpec

Successfully loaded [org.apache.http.impl.cookie.AbstractCookieSpec] from:
  90    com.iggroup.wt.sso.ig-osgi-wt-sso-securedhttpclient
        [exported by 96 com.springsource.org.apache.httpcomponentns.httpclient]
  96    com.springsource.org.apache.httpcomponentns.httpclient
  89    com.iggroup.springrest.ig-osgi-wt-springrest-intf
        [exported by 96 com.springsource.org.apache.httpcomponentns.httpclient]
  110   com.iggroup.pendingaccount.ig-osgi-wt-pendingaccount-client
        [exported by 96 com.springsource.org.apache.httpcomponentns.httpclient]

but when I get the exception, the same clload command yields:

osgi> clload org.apache.http.impl.cookie.AbstractCookieSpec

Successfully loaded [org.apache.http.impl.cookie.AbstractCookieSpec] from:
  96    com.springsource.org.apache.httpcomponentns.httpclient

There is something fundamental I am missing here. I would have thought that, since the com.springsource.org.apache.httpcomponentns.httpclient bundle is the only one that exports the package to which this class belongs, the class should only be loaded from it. Evidence seems to suggest instead that things do not work when this is the case and that the class needs to be loadable from multiple bundles.

Does any kind soul have an explanation for a simpleton like me? Embarrassed

TIA,
B.

Re: Class not found mystery [message #784414 is a reply to message #784349]

Fri, 27 January 2012 08:40

Eclipse User

The output actually means that your bundles can load the needed class. They do not contain the class, but it is exported from bundle 96 (since you have the right imports).

The interesting here is that when there is a problem it seems that all your bundles are not wired to 96 com.springsource.org.apache.httpcomponentns.httpclient.

Are there any logs hinting a problem with the wiring of your bundles? If not we need to compare the OSGi wiring in both cases to check what went wrong.

Previous Topic:	Maven plugin to deploy bundles to Virgo
Next Topic:	War File URL Virgo vs Jetty

Goto Forum:

-=] Back to Top [=-

Current Time: Tue May 13 14:50:15 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter