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
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
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)"
(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.
I ment to refer to bug 52318
Should have been fixed by r1455854 r1456068
Thanks for the report. Fixed in trunk and 7.0.x and will be included in 7.0.39 onwards.