Bug 54684 - PoolProperties.toString() causes NoClassDefFoundError exception
Summary: PoolProperties.toString() causes NoClassDefFoundError exception
Status: RESOLVED FIXED
Alias: None
Product: Tomcat Modules
Classification: Unclassified
Component: jdbc-pool (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-13 08:39 UTC by Martin Lichtin
Modified: 2013-03-14 07:41 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Lichtin 2013-03-13 08:39:00 UTC
When turning on DEBUG logging, toString() causes the following exception.
It happens in an OSGi environment.

SLF4J: Failed toString() invocation on an object of type [org.apache.tomcat.jdbc.pool.DataSource]
2013-03-12 14:17:13,612 | DEBUG | Blueprint Extender: 1    | ServiceRecipe                    | lueprint.container.ServiceRecipe  276 | 7 - org.apache.aries.blueprint.core - 1.1.0 | Creating service instance
java.lang.NoClassDefFoundError: javax/naming/spi/ObjectFactory
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:791)
    at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2128)
    at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1432)
    at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
    at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
    at org.apache.tomcat.jdbc.pool.PoolProperties.toString(PoolProperties.java:804)
    at java.lang.String.valueOf(String.java:2854)
    at java.lang.StringBuilder.append(StringBuilder.java:128)
    at org.apache.tomcat.jdbc.pool.DataSourceProxy.toString(DataSourceProxy.java:215)
    at org.slf4j.helpers.MessageFormatter.safeObjectAppend(MessageFormatter.java:304)
    at org.slf4j.helpers.MessageFormatter.deeplyAppendParameter(MessageFormatter.java:276)
    at org.slf4j.helpers.MessageFormatter.arrayFormat(MessageFormatter.java:230)
    at org.slf4j.helpers.MessageFormatter.format(MessageFormatter.java:124)
    at org.ops4j.pax.logging.slf4j.Slf4jLogger.debug(Slf4jLogger.java:280)
    at org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:302)
    at org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:249)
    at org.apache.aries.blueprint.container.ServiceRecipe.internalCreate(ServiceRecipe.java:146)
    at org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
    at java.util.concurrent.FutureTask.run(FutureTask.java:166)
    at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)
    at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:245)
    at org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:183)
    at org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:668)
    at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:370)
    at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:261)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
    at java.util.concurrent.FutureTask.run(FutureTask.java:166)
    at org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)
    at org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
    at java.util.concurrent.FutureTask.run(FutureTask.java:166)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.ClassNotFoundException: javax.naming.spi.ObjectFactory not found by org.apache.tomcat.jdbc [165]
    at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1460)
    at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
    at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
    ... 41 more
Comment 1 Violeta Georgieva 2013-03-13 08:49:15 UTC
The current Import-Package contains

Import-Package:  javax.management;version="0", javax.management.openmb
 ean;version="0", javax.naming;version="0", javax.sql;version="0", org
 .apache.juli.logging;version="[6.0.18, 7.0.0)"

We need to add "javax.naming.spi" also to it
Comment 2 Violeta Georgieva 2013-03-13 08:54:30 UTC
Also this version range is strange because it specifies that jdbc-pool can work only with org.apache.juli.logging version 6.x. Is that correct?

org.apache.juli.logging;version="[6.0.18, 7.0.0)"
Comment 3 Martin Lichtin 2013-03-13 09:29:15 UTC
(In reply to comment #2)
> Also this version range is strange because it specifies that jdbc-pool can
> work only with org.apache.juli.logging version 6.x. Is that correct?
> 
> org.apache.juli.logging;version="[6.0.18, 7.0.0)"

Yes it seems wrong. See also bug 54684 where this is discussed.
Even worse, because Juli is not packaged as an OSGi bundle (and therefore
not versioned for an OSGi import), the version range causes yet another issue.
Comment 4 Martin Lichtin 2013-03-13 14:17:13 UTC
I ment to refer to bug 52318
Comment 5 Konstantin Kolinko 2013-03-14 04:00:45 UTC
Should have been fixed by r1455854 r1456068
Comment 6 Violeta Georgieva 2013-03-14 07:41:15 UTC
Thanks for the report.
Fixed in trunk and 7.0.x and will be included in 7.0.39 onwards.