As I understand you DynamicImport-Package must be defined in bundle MANIFEST.
So do I need to check MANIFESTs of all bundles for containing DynamicImport-Package property? вторник, 9 мая 2017 г., 16:04:53 UTC+3 пользователь Guillaume Nodet написал: > > 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 <[email protected] <javascript:>>: > >> 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 <[email protected]>: >>> >>>> 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 <[email protected]> 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 - [email protected] >>>>>> >>>>>> --- >>>>>> 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 [email protected]. >>>>>> 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 - [email protected] >>>> >>>> --- >>>> 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 [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> >>> -- >>> ------------------------ >>> Guillaume Nodet >>> >>> -- >> -- >> ------------------ >> OPS4J - http://www.ops4j.org - [email protected] <javascript:> >> >> --- >> 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 [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > ------------------------ > Guillaume Nodet > > -- -- ------------------ OPS4J - http://www.ops4j.org - [email protected] --- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
