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 <pavelkastor...@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 - 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.
