Well, according to the stack trace, someone does. I've checked weld and pax-cdi bundles and they don't have any dynamic import. Can you double check all the deployed bundles ? Maybe it's not one of you bundles, but there's definitely at least one bundle which uses dynamic import. One way to avoid the dynamic import resolution is to back all dynamically imported packages by statically imported optional packages, so that they are rather statically bound than dynamically bound. Also, if you can easily reproduce the issue, one good way would be to put a breakpoint in org.apache.felix.framework.StatefulResolver.resolve( StatefulResolver.java:481) and check which package cause the resolution.
2017-05-09 14:54 GMT+02:00 Pavel <pavelkastor...@gmail.com>: > Hi Guillaume > > Thank you for your answer. But I don't use any dynamic-imports. > > вторник, 9 мая 2017 г., 15:52:03 UTC+3 пользователь Guillaume Nodet > написал: >> >> Yeah, and I'm telling you that you should remove the DynamicImport from >> your bundles in order maybe to get around those issues. >> >> 2017-05-09 14:40 GMT+02:00 Pavel <pavelka...@gmail.com>: >> >>> I wrote to Weld developers and this is the answer I got from them >>> >>> I'm not sure whether this is a PAX-CDI, Felix or Weld problem. >>> The only argument is what I wrote earlier: >>> "it is true that Weld's ClassFileUtils holds 0x00000000fd03aa50 and also >>> waiting in another thread to release this lock. But the weld-worker-1 >>> thread (which holds the lock) is in state WAITING (on object monitor) >>> due to >>> org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5332) >>> which calls m_bundleLock.wait()." >>> >>> So there is a problem - if PAX-CDI + Weld + Felix are used then bundle >>> update >>> operation is not supported in many cases which require osgi refresh. >>> >>> The question to community - should I create pax-cdi issue as pax-cdi is >>> the responsible >>> for creating weld containers for osgi bundles or this is the end of >>> story? >>> >>> вторник, 9 мая 2017 г., 2:14:31 UTC+3 пользователь Niclas Hedhman >>> написал: >>>> >>>> I see two locks in JBoss Weld. >>>> >>>> - locked <0x00000000fd03aa50> (a java.lang.Class for >>>> org.jboss.weld.util.bytecode.ClassFileUtils) >>>> >>>> >>>> and I doubt that it is anything we can do about it in OPS4J to avoid >>>> this. >>>> >>>> >>>> >>>> On Mon, May 8, 2017 at 6:02 PM, Pavel <pavelka...@gmail.com> wrote: >>>> >>>>> Hi all >>>>> >>>>> I use pax-cdi 1.0.0.RC2 with weld-osgi-bundle 2.3.5. And I have two >>>>> bundles: bundleA and bundleB. >>>>> >>>>> BundleB has CDI beans and CDI container is created for bundleB. >>>>> Besides bundleB depends on bundleA. >>>>> >>>>> Now I update bundleA and do osgi refresh using this code >>>>> >>>>> Bundle systemBundle = bundleContext.getBundle(0); >>>>> FrameworkWiring frameworkWiring = >>>>> systemBundle.adapt(FrameworkWiring.class); >>>>> frameworkWiring.refreshBundles(null); >>>>> >>>>> What I see in log of bundle B. >>>>> >>>>> 2017-05-08 12:31:42,831 | DEBUG | xFrameworkWiring | ? | BundleEvent >>>>> STOPPING - com.bundleB >>>>> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | ServiceEvent >>>>> UNREGISTERING - [java.lang.Object] - com.bundleB >>>>> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | BundleEvent >>>>> STOPPED - com.bundleB >>>>> 2017-05-08 12:31:42,845 | DEBUG | xFrameworkWiring | ? | BundleEvent >>>>> UNRESOLVED - com.bundleB >>>>> 2017-05-08 12:31:42,885 | DEBUG | xFrameworkWiring | ? | BundleEvent >>>>> RESOLVED - com.bundleB >>>>> 2017-05-08 12:31:42,886 | DEBUG | xFrameworkWiring | ? | BundleEvent >>>>> STARTING - com.bundleB >>>>> 2017-05-08 12:31:43,164 | DEBUG | xFrameworkWiring | ? | ServiceEvent >>>>> REGISTERED - [java.lang.Object] - com.bundleB >>>>> >>>>> Please,note that bundleB didn't change state to STARTED. When I don't use >>>>> in bundleB CDI >>>>> beans and CDI container is not created for bundleB then everything is ok >>>>> - after bundleA >>>>> update and osgi refresh bundleB reaches STARTED state. >>>>> >>>>> Is this a bug or maybe I do something wrong or something else? This is >>>>> some thread dump: >>>>> >>>>> "weld-worker-3" #146 daemon prio=5 os_prio=0 tid=0x00007f3e08044000 >>>>> nid=0x1dc8 waiting for monitor entry [0x00007f3dd867a000] >>>>> java.lang.Thread.State: BLOCKED (on object monitor) >>>>> at >>>>> org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:108) >>>>> - waiting to lock <0x00000000fd03aa50> (a java.lang.Class for >>>>> org.jboss.weld.util.bytecode.ClassFileUtils) >>>>> at >>>>> org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:97) >>>>> at >>>>> org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:491) >>>>> at >>>>> org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:364) >>>>> at >>>>> org.jboss.weld.bean.builtin.AbstractFacadeBean.initializeAfterBeanDiscovery(AbstractFacadeBean.java:61) >>>>> at >>>>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:136) >>>>> at >>>>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:127) >>>>> at >>>>> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63) >>>>> at >>>>> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56) >>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266) >>>>> at >>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >>>>> at >>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>>>> at java.lang.Thread.run(Thread.java:745) >>>>> >>>>> "weld-worker-1" #144 daemon prio=5 os_prio=0 tid=0x00007f3e08042800 >>>>> nid=0x1dc6 in Object.wait() [0x00007f3dd967e000] >>>>> java.lang.Thread.State: WAITING (on object monitor) >>>>> at java.lang.Object.wait(Native Method) >>>>> at java.lang.Object.wait(Object.java:502) >>>>> at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5332) >>>>> - locked <0x00000000ed6de970> (a [Ljava.lang.Object;) >>>>> at >>>>> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:481) >>>>> at >>>>> org.apache.felix.framework.BundleWiringImpl.searchDynamicImports(BundleWiringImpl.java:1652) >>>>> at >>>>> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1552) >>>>> at >>>>> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79) >>>>> at >>>>> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018) >>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) >>>>> at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1925) >>>>> at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978) >>>>> at >>>>> org.apache.xbean.osgi.bundle.util.DelegatingBundle.loadClass(DelegatingBundle.java:170) >>>>> at >>>>> org.apache.xbean.osgi.bundle.util.BundleClassLoader.loadClass(BundleClassLoader.java:75) >>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:411) >>>>> - locked <0x00000000fb14e428> (a >>>>> org.ops4j.pax.cdi.weld.impl.util.BundleClassLoader) >>>>> at >>>>> org.ops4j.pax.cdi.weld.impl.util.BundleClassLoader.loadClass(BundleClassLoader.java:193) >>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) >>>>> at java.lang.ClassLoader.defineClass1(Native Method) >>>>> at java.lang.ClassLoader.defineClass(ClassLoader.java:760) >>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>> at >>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>>> at >>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>> at java.lang.reflect.Method.invoke(Method.java:497) >>>>> at >>>>> org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:108) >>>>> - locked <0x00000000fd03aa50> (a java.lang.Class for >>>>> org.jboss.weld.util.bytecode.ClassFileUtils) >>>>> at >>>>> org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:97) >>>>> at >>>>> org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:491) >>>>> at >>>>> org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:364) >>>>> at >>>>> org.jboss.weld.bean.builtin.AbstractFacadeBean.initializeAfterBeanDiscovery(AbstractFacadeBean.java:61) >>>>> at >>>>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:136) >>>>> at >>>>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:127) >>>>> at >>>>> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63) >>>>> at >>>>> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56) >>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266) >>>>> at >>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >>>>> at >>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>>>> at java.lang.Thread.run(Thread.java:745) >>>>> >>>>> "FelixFrameworkWiring" #17 daemon prio=5 os_prio=0 tid=0x00007f3e74410800 >>>>> nid=0x1c6e waiting on condition [0x00007f3e5e579000] >>>>> java.lang.Thread.State: WAITING (parking) >>>>> at sun.misc.Unsafe.park(Native Method) >>>>> - parking to wait for <0x00000000fb86f398> (a >>>>> java.util.concurrent.FutureTask) >>>>> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >>>>> at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429) >>>>> at java.util.concurrent.FutureTask.get(FutureTask.java:191) >>>>> at >>>>> java.util.concurrent.AbstractExecutorService.invokeAll(AbstractExecutorService.java:244) >>>>> at >>>>> org.jboss.weld.executor.AbstractExecutorServices.invokeAllAndCheckForExceptions(AbstractExecutorServices.java:43) >>>>> at >>>>> org.jboss.weld.executor.AbstractExecutorServices.invokeAllAndCheckForExceptions(AbstractExecutorServices.java:51) >>>>> at >>>>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer.doAfterBeanDiscovery(ConcurrentBeanDeployer.java:113) >>>>> at >>>>> org.jboss.weld.bootstrap.BeanDeployment.afterBeanDiscovery(BeanDeployment.java:271) >>>>> at >>>>> org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:434) >>>>> at >>>>> org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83) >>>>> - locked <0x00000000fad0fc60> (a org.jboss.weld.bootstrap.WeldBootstrap) >>>>> at >>>>> org.ops4j.pax.cdi.weld.impl.WeldCdiContainer.createBeanManager(WeldCdiContainer.java:133) >>>>> at >>>>> org.ops4j.pax.cdi.weld.impl.WeldCdiContainer.access$000(WeldCdiContainer.java:57) >>>>> at >>>>> org.ops4j.pax.cdi.weld.impl.WeldCdiContainer$1.call(WeldCdiContainer.java:98) >>>>> at >>>>> org.ops4j.pax.cdi.spi.AbstractCdiContainer.doWithClassLoader(AbstractCdiContainer.java:151) >>>>> at >>>>> org.ops4j.pax.cdi.weld.impl.WeldCdiContainer.doStart(WeldCdiContainer.java:94) >>>>> at >>>>> org.ops4j.pax.cdi.spi.AbstractCdiContainer.start(AbstractCdiContainer.java:85) >>>>> - locked <0x00000000facbf020> (a >>>>> org.ops4j.pax.cdi.weld.impl.WeldCdiContainer) >>>>> at >>>>> org.ops4j.pax.cdi.extender.impl.CdiExtender.createContainer(CdiExtender.java:184) >>>>> at >>>>> org.ops4j.pax.cdi.extender.impl.CdiExtender.addingBundle(CdiExtender.java:133) >>>>> - locked <0x00000000edd04c60> (a >>>>> org.ops4j.pax.cdi.extender.impl.CdiExtender) >>>>> at >>>>> org.ops4j.pax.cdi.extender.impl.CdiExtender.addingBundle(CdiExtender.java:64) >>>>> at >>>>> org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:469) >>>>> at >>>>> org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:415) >>>>> at >>>>> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256) >>>>> at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229) >>>>> at >>>>> org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444) >>>>> at >>>>> org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:916) >>>>> at >>>>> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:835) >>>>> at >>>>> org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:517) >>>>> at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4541) >>>>> at org.apache.felix.framework.Felix.startBundle(Felix.java:2172) >>>>> at >>>>> org.apache.felix.framework.Felix$RefreshHelper.restart(Felix.java:5063) >>>>> at org.apache.felix.framework.Felix.refreshPackages(Felix.java:4253) >>>>> at >>>>> org.apache.felix.framework.FrameworkWiringImpl.run(FrameworkWiringImpl.java:188) >>>>> at java.lang.Thread.run(Thread.java:745) >>>>> >>>>> >>>>> >>>>> -- >>>>> -- >>>>> ------------------ >>>>> OPS4J - http://www.ops4j.org - op...@googlegroups.com >>>>> >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "OPS4J" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to ops4j+un...@googlegroups.com. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>>> >>>> -- >>>> Niclas Hedhman, Software Developer >>>> http://polygene.apache.org - New Energy for Java >>>> >>> -- >>> -- >>> ------------------ >>> OPS4J - http://www.ops4j.org - op...@googlegroups.com >>> >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "OPS4J" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to ops4j+un...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> ------------------------ >> Guillaume Nodet >> >> -- > -- > ------------------ > OPS4J - http://www.ops4j.org - ops4j@googlegroups.com > > --- > You received this message because you are subscribed to the Google Groups > "OPS4J" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to ops4j+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- ------------------------ Guillaume Nodet -- -- ------------------ OPS4J - http://www.ops4j.org - ops4j@googlegroups.com --- You received this message because you are subscribed to the Google Groups "OPS4J" group. To unsubscribe from this group and stop receiving emails from it, send an email to ops4j+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
