From ooo_saturn7 at mail.ru Tue May 9 03:04:39 2017 From: ooo_saturn7 at mail.ru (=?UTF-8?B?QWxleCBTdmlyaWRvdg==?=) Date: Tue, 09 May 2017 10:04:39 +0300 Subject: [weld-dev] =?utf-8?q?Thread_deadlock_with_osgi_refresh?= Message-ID: <1494313479.209858581@f415.i.mail.ru> 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 of weld 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) -- Alex Sviridov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20170509/11d19f8b/attachment-0001.html From mkouba at redhat.com Tue May 9 05:22:23 2017 From: mkouba at redhat.com (Martin Kouba) Date: Tue, 9 May 2017 11:22:23 +0200 Subject: [weld-dev] Thread deadlock with osgi refresh In-Reply-To: <1494313479.209858581@f415.i.mail.ru> References: <1494313479.209858581@f415.i.mail.ru> Message-ID: Hi Alex, I don't know much about Felix and OSGi but it seems the org.apache.felix.framework.Felix.acquireGlobalLock() is waiting to wake up and the thread holds lock on org.jboss.weld.util.bytecode.ClassFileUtils. Have you tried PAX CDI guys already? Martin Dne 9.5.2017 v 09:04 Alex Sviridov napsal(a): > 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 of weld 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)| > > > > > -- > Alex Sviridov > > > _______________________________________________ > weld-dev mailing list > weld-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev > -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic From ooo_saturn7 at mail.ru Tue May 9 05:45:27 2017 From: ooo_saturn7 at mail.ru (=?UTF-8?B?QWxleCBTdmlyaWRvdg==?=) Date: Tue, 09 May 2017 12:45:27 +0300 Subject: [weld-dev] =?utf-8?q?Thread_deadlock_with_osgi_refresh?= In-Reply-To: References: <1494313479.209858581@f415.i.mail.ru> Message-ID: <1494323127.806305892@f427.i.mail.ru> Hi Martin Thank you very much for your answer. Yes, I asked them. Please see https://groups.google.com/forum/#!topic/ops4j/msmgHq0B1l8 >???????, 9 ??? 2017, 12:22 +03:00 ?? Martin Kouba : > >Hi Alex, > >I don't know much about Felix and OSGi but it seems the >org.apache.felix.framework.Felix.acquireGlobalLock() is waiting to wake >up and the thread holds lock on >org.jboss.weld.util.bytecode.ClassFileUtils. Have you tried PAX CDI guys >already? > >Martin > >Dne 9.5.2017 v 09:04 Alex Sviridov napsal(a): >> 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 of weld 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)| >> >> >> >> >> -- >> Alex Sviridov >> >> >> _______________________________________________ >> weld-dev mailing list >> weld-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/weld-dev >> > >-- >Martin Kouba >Senior Software Engineer >Red Hat, Czech Republic -- Alex Sviridov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20170509/78231e42/attachment-0001.html From mkouba at redhat.com Tue May 9 06:34:36 2017 From: mkouba at redhat.com (Martin Kouba) Date: Tue, 9 May 2017 12:34:36 +0200 Subject: [weld-dev] Thread deadlock with osgi refresh In-Reply-To: <1494323127.806305892@f427.i.mail.ru> References: <1494313479.209858581@f415.i.mail.ru> <1494323127.806305892@f427.i.mail.ru> Message-ID: Well, when looking at Niclas's answer - 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(). Martin Dne 9.5.2017 v 11:45 Alex Sviridov napsal(a): > Hi Martin > > Thank you very much for your answer. Yes, I asked them. Please see > https://groups.google.com/forum/#!topic/ops4j/msmgHq0B1l8 > > > ???????, 9 ??? 2017, 12:22 +03:00 ?? Martin Kouba : > > Hi Alex, > > I don't know much about Felix and OSGi but it seems the > org.apache.felix.framework.Felix.acquireGlobalLock() is waiting to wake > up and the thread holds lock on > org.jboss.weld.util.bytecode.ClassFileUtils. Have you tried PAX CDI > guys > already? > > Martin > > Dne 9.5.2017 v 09:04 Alex Sviridov napsal(a): > > 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 of weld 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)| > > > > > > > > > > -- > > Alex Sviridov > > > > > > _______________________________________________ > > weld-dev mailing list > > weld-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/weld-dev > > > > -- > Martin Kouba > Senior Software Engineer > Red Hat, Czech Republic > > > > -- > Alex Sviridov -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic From mkouba at redhat.com Mon May 15 04:30:29 2017 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 15 May 2017 10:30:29 +0200 Subject: [weld-dev] Weld 3.0.0.Final released Message-ID: http://weld.cdi-spec.org/news/2017/05/15/weld-300Final/ -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic From ggastald at redhat.com Mon May 15 14:44:32 2017 From: ggastald at redhat.com (George Gastaldi) Date: Mon, 15 May 2017 15:44:32 -0300 Subject: [weld-dev] Weld 3.0.0.Final released In-Reply-To: References: Message-ID: Cool! Question: What's the reason why Weld-core-impl depends on jboss-interceptors-api_1.2_spec and jboss-el-api_3.0_spec given that cdi-api:2.0 already brings javax.incerceptor.api:1.2 and javax.el-api:3.0.0 as transitive dependencies? PS: Just upgraded Furnace to use Weld 3.0.0.Final and all tests are passing. Great job! Best Regards, George Gastaldi Principal Software Engineer Red Hat Remote Joinville - Santa Catarina ggastald at redhat.com M: +55-47-99711-1000 TRIED. TESTED. TRUSTED. @redhatnews Red Hat Red Hat On Mon, May 15, 2017 at 5:30 AM, Martin Kouba wrote: > http://weld.cdi-spec.org/news/2017/05/15/weld-300Final/ > > -- > Martin Kouba > Senior Software Engineer > Red Hat, Czech Republic > _______________________________________________ > weld-dev mailing list > weld-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20170515/227b7b39/attachment.html From mkouba at redhat.com Tue May 16 03:00:37 2017 From: mkouba at redhat.com (Martin Kouba) Date: Tue, 16 May 2017 09:00:37 +0200 Subject: [weld-dev] Weld 3.0.0.Final released In-Reply-To: References: Message-ID: <9230188a-6ce5-d243-1acd-6609fb5200c0@redhat.com> Dne 15.5.2017 v 20:44 George Gastaldi napsal(a): > Cool! > > Question: What's the reason why Weld-core-impl depends on > jboss-interceptors-api_1.2_spec and jboss-el-api_3.0_spec given that > cdi-api:2.0 already brings javax.incerceptor.api:1.2 and > javax.el-api:3.0.0 as transitive dependencies? Well, it's always been like this. In EE users don't depend on Weld at all. In SE users usually bring in weld-se directly (depends on Weld core and Weld API - depends on cdi-api with exclusions https://github.com/weld/api/blob/master/pom.xml#L190) and explicit cdi-api dependency is not needed. But the truth is we should probably revisit this since users can now depend on cdi-api and use CDI bootstrap API, ie. bring weld only as an impl dependency. > > PS: Just upgraded Furnace to use Weld 3.0.0.Final and all tests are > passing. Great job! That's great ;-) > > > Best Regards, > > > > George Gastaldi > > Principal Software Engineer > > Red Hat > > Remote > > Joinville - Santa Catarina > > ggastald at redhat.com M: +55-47-99711-1000 > > > > TRIED. TESTED. TRUSTED. > > @redhatnews Red Hat > Red Hat > > > > On Mon, May 15, 2017 at 5:30 AM, Martin Kouba > wrote: > > http://weld.cdi-spec.org/news/2017/05/15/weld-300Final/ > > > -- > Martin Kouba > Senior Software Engineer > Red Hat, Czech Republic > _______________________________________________ > weld-dev mailing list > weld-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev > > > -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic From ooo_saturn7 at mail.ru Mon May 22 02:50:18 2017 From: ooo_saturn7 at mail.ru (=?UTF-8?B?QWxleCBTdmlyaWRvdg==?=) Date: Mon, 22 May 2017 09:50:18 +0300 Subject: [weld-dev] =?utf-8?q?Application_scoped_bean_and_its_lifecycle?= Message-ID: <1495435818.849704651@f411.i.mail.ru> Hi all I use pax-cdi -1.0.0.RC2 and weld 2.3.5.Final and this is my test class: import javax.enterprise.context.ApplicationScoped; import javax.enterprise.context.Destroyed; import javax.enterprise.context.Initialized; import javax.enterprise.event.Observes; @ApplicationScoped public class Test { public Test() { System.out.println("Test was created."); } public void init(@Observes @Initialized(ApplicationScoped.class) Object init) { System.out.println("Test was initialized"); } public void destroy(@Observes @Destroyed(ApplicationScoped.class) Object init) { System.out.println("Test was destroyed."); } } When I start test-bundle I see the following output: Test was created. Test was initialized Test was initialized When I stop test-bundle I see the following output: Test was destroyed. Test was created. Test was destroyed. So as result this bean was two times created, two times initialized and two times destroyed. I expected that this bean must be once created, one initialized and once destroyed. Is this a bug that must be reported or my mistake? -- Alex Sviridov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20170522/6c2950b9/attachment.html From mkouba at redhat.com Mon May 22 03:48:43 2017 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 22 May 2017 09:48:43 +0200 Subject: [weld-dev] Application scoped bean and its lifecycle In-Reply-To: <1495435818.849704651@f411.i.mail.ru> References: <1495435818.849704651@f411.i.mail.ru> Message-ID: Hi Alex, this looks really weird. Could you try to print out the event payload, e.g. System.out.println(init)? Also you should be always very careful when using code inside the no-args constructor of a normal-scoped bean -> it will be also executed when creating a client proxy. In your case, if you do @Inject Test and invoke any method then you will also see "Test was created" printed twice. Martin Dne 22.5.2017 v 08:50 Alex Sviridov napsal(a): > Hi all > > I use pax-cdi -1.0.0.RC2 and weld 2.3.5.Final and this is my test class: > > import javax.enterprise.context.ApplicationScoped; > import javax.enterprise.context.Destroyed; > import javax.enterprise.context.Initialized; > import javax.enterprise.event.Observes; > > @ApplicationScoped > public class Test { > > public Test() { > System.out.println("Test was created."); > } > > public void init(@Observes @Initialized(ApplicationScoped.class) Object > init) { > System.out.println("Test was initialized"); > } > > public void destroy(@Observes @Destroyed(ApplicationScoped.class) > Object init) { > System.out.println("Test was destroyed."); > } > } > > When I start test-bundle I see the following output: > Test was created. > Test was initialized > Test was initialized > When I stop test-bundle I see the following output: > Test was destroyed. > Test was created. > Test was destroyed. > > So as result this bean was two times created, two times initialized and two > times destroyed. > > I expected that this bean must be once created, one initialized and once > destroyed. > > Is this a bug that must be reported or my mistake? > > -- > Alex Sviridov > > > _______________________________________________ > weld-dev mailing list > weld-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev > -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic From ooo_saturn7 at mail.ru Mon May 22 03:57:16 2017 From: ooo_saturn7 at mail.ru (=?UTF-8?B?QWxleCBTdmlyaWRvdg==?=) Date: Mon, 22 May 2017 10:57:16 +0300 Subject: [weld-dev] =?utf-8?q?Application_scoped_bean_and_its_lifecycle?= In-Reply-To: References: <1495435818.849704651@f411.i.mail.ru> Message-ID: <1495439836.339661742@f401.i.mail.ru> Hi Martin Thank you for your answer. 1) I don't inject Test class anywhere. 2) I modified init and destroy methods: ??? public void init(@Observes @Initialized(ApplicationScoped.class) Object init) { ??????? System.out.println(init); ??????? System.out.println("Test was initialized"); ??? } ??? public void destroy(@Observes @Destroyed(ApplicationScoped.class) Object init) { ??????? System.out.println(init); ??????? System.out.println("Test was destroyed."); ??? } Now on bundle start: Test was created. Application context initialized. Test was initialized java.lang.Object at 48813e62 Test was initialized Now on bundle stop: java.lang.Object at 48813e62 Test was destroyed. Test was created. Application context destroyed. Test was destroyed. >???????????, 22 ??? 2017, 10:48 +03:00 ?? Martin Kouba : > >Hi Alex, > >this looks really weird. Could you try to print out the event payload, >e.g. System.out.println(init)? > >Also you should be always very careful when using code inside the >no-args constructor of a normal-scoped bean -> it will be also executed >when creating a client proxy. In your case, if you do @Inject Test and >invoke any method then you will also see "Test was created" printed twice. > >Martin > >Dne 22.5.2017 v 08:50 Alex Sviridov napsal(a): >> Hi all >> >> I use pax-cdi -1.0.0.RC2 and weld 2.3.5.Final and this is my test class: >> >> import javax.enterprise.context.ApplicationScoped; >> import javax.enterprise.context.Destroyed; >> import javax.enterprise.context.Initialized; >> import javax.enterprise.event.Observes; >> >> @ApplicationScoped >> public class Test { >> >> public Test() { >> System.out.println("Test was created."); >> } >> >> public void init(@Observes @Initialized(ApplicationScoped.class) Object >> init) { >> System.out.println("Test was initialized"); >> } >> >> public void destroy(@Observes @Destroyed(ApplicationScoped.class) >> Object init) { >> System.out.println("Test was destroyed."); >> } >> } >> >> When I start test-bundle I see the following output: >> Test was created. >> Test was initialized >> Test was initialized >> When I stop test-bundle I see the following output: >> Test was destroyed. >> Test was created. >> Test was destroyed. >> >> So as result this bean was two times created, two times initialized and two >> times destroyed. >> >> I expected that this bean must be once created, one initialized and once >> destroyed. >> >> Is this a bug that must be reported or my mistake? >> >> -- >> Alex Sviridov >> >> >> _______________________________________________ >> weld-dev mailing list >> weld-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/weld-dev >> > >-- >Martin Kouba >Senior Software Engineer >Red Hat, Czech Republic -- Alex Sviridov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20170522/b1493159/attachment.html From mkouba at redhat.com Mon May 22 04:50:56 2017 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 22 May 2017 10:50:56 +0200 Subject: [weld-dev] Application scoped bean and its lifecycle In-Reply-To: <1495439836.339661742@f401.i.mail.ru> References: <1495435818.849704651@f411.i.mail.ru> <1495439836.339661742@f401.i.mail.ru> Message-ID: Ok, now I know what's going on. The event with payload "Application context initialized." comes directly from Weld. Whereas the second one java.lang.Object at 48813e62 comes from PAX CDI [1]. Up to version 2.2 Weld did not fire @Initialized/@Destroyed events for @ApplicationScoped for non-web modules. The behavior changed in 2.3 - see also WELD-1821 [2]. This explains the events fired twice. WRT Test bean instance created twice - the problem is that @Destroyed(ApplicationScoped.class) event is fired after the actual destruction. So if you declare an observer on an @ApplicationScoped you're entering the "undefined behavior zone". In Weld, the Test bean is created again. I've created WELD-2389 [3] to track this issue. Thanks, Martin [1] https://github.com/ops4j/org.ops4j.pax.cdi/blob/master/pax-cdi-weld/src/main/java/org/ops4j/pax/cdi/weld/impl/WeldCdiContainer.java#L154 [2] https://issues.jboss.org/browse/WELD-1821 [3] https://issues.jboss.org/browse/WELD-2389 Dne 22.5.2017 v 09:57 Alex Sviridov napsal(a): > Hi Martin > > Thank you for your answer. > > 1) I don't inject Test class anywhere. > 2) I modified init and destroy methods: > public void init(@Observes @Initialized(ApplicationScoped.class) > Object init) { > System.out.println(init); > System.out.println("Test was initialized"); > } > > public void destroy(@Observes @Destroyed(ApplicationScoped.class) > Object init) { > System.out.println(init); > System.out.println("Test was destroyed."); > } > > Now on bundle start: > > Test was created. > Application context initialized. > Test was initialized > java.lang.Object at 48813e62 > Test was initialized > > Now on bundle stop: > > java.lang.Object at 48813e62 > Test was destroyed. > Test was created. > Application context destroyed. > Test was destroyed. > > > ???????????, 22 ??? 2017, 10:48 +03:00 ?? Martin Kouba > : > > Hi Alex, > > this looks really weird. Could you try to print out the event payload, > e.g. System.out.println(init)? > > Also you should be always very careful when using code inside the > no-args constructor of a normal-scoped bean -> it will be also executed > when creating a client proxy. In your case, if you do @Inject Test and > invoke any method then you will also see "Test was created" printed > twice. > > Martin > > Dne 22.5.2017 v 08:50 Alex Sviridov napsal(a): > > Hi all > > > > I use pax-cdi -1.0.0.RC2 and weld 2.3.5.Final and this is my test > class: > > > > import javax.enterprise.context.ApplicationScoped; > > import javax.enterprise.context.Destroyed; > > import javax.enterprise.context.Initialized; > > import javax.enterprise.event.Observes; > > > > @ApplicationScoped > > public class Test { > > > > public Test() { > > System.out.println("Test was created."); > > } > > > > public void init(@Observes @Initialized(ApplicationScoped.class) > Object > > init) { > > System.out.println("Test was initialized"); > > } > > > > public void destroy(@Observes @Destroyed(ApplicationScoped.class) > > Object init) { > > System.out.println("Test was destroyed."); > > } > > } > > > > When I start test-bundle I see the following output: > > Test was created. > > Test was initialized > > Test was initialized > > When I stop test-bundle I see the following output: > > Test was destroyed. > > Test was created. > > Test was destroyed. > > > > So as result this bean was two times created, two times > initialized and two > > times destroyed. > > > > I expected that this bean must be once created, one initialized > and once > > destroyed. > > > > Is this a bug that must be reported or my mistake? > > > > -- > > Alex Sviridov > > > > > > _______________________________________________ > > weld-dev mailing list > > weld-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/weld-dev > > > > -- > Martin Kouba > Senior Software Engineer > Red Hat, Czech Republic > > > > -- > Alex Sviridov -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic From ooo_saturn7 at mail.ru Mon May 22 06:03:18 2017 From: ooo_saturn7 at mail.ru (=?UTF-8?B?QWxleCBTdmlyaWRvdg==?=) Date: Mon, 22 May 2017 13:03:18 +0300 Subject: [weld-dev] =?utf-8?q?Application_scoped_bean_and_its_lifecycle?= In-Reply-To: <1c736be7-18ed-1e15-73c5-73c44a956b59@redhat.com> References: <1495435818.849704651@f411.i.mail.ru> <1495444449.685809882@f305.i.mail.ru> <1c736be7-18ed-1e15-73c5-73c44a956b59@redhat.com> Message-ID: <1495447398.656406100@f310.i.mail.ru> Martin, Thank you for your answer. I replaced 2.3.5.Final with 2.2.16.Final. Besides in 2.2.16 in manifest I had to export package org.jboss.weld.config which is used by pax-cdi. Now? on bundle start: Test was created. java.lang.Object at 6bc3928f Test was initialized Now? on bundle stop: java.lang.Object at 6bc3928f Test was destroyed. ???????????, 22 ??? 2017, 12:27 +03:00 ?? Martin Kouba : > >Dne 22.5.2017 v 11:14 Alex Sviridov napsal(a): >> Martin, >> >> In your message you wrote : "Up to version 2.2 Weld did not fire >> @Initialized/@Destroyed events for >> @ApplicationScoped for non-web modules.". >> >> In WELD-2389 you wrote : "Right now, this service is registered for any >> non-SE environment". >> >> I use OSGi + PAX-CDI + WELD + JAVAFX. As I suppose this is a SE >> application (not EE). >> Could you explain "Right now, this service is registered for any non-SE >> environment" ? > >Well, I'm talking about Weld SPI and I'm refering to the environment >info provided by the integrator. PAX CDI provides a custom >implementation of org.jboss.weld.bootstrap.api.Environment, which is >fine. The problem is that Weld currently skips registration only if >org.jboss.weld.bootstrap.api.Environments.SE is used. > >> >> Best regards, Alex >> >> >> ???????????, 22 ??? 2017, 11:51 +03:00 ?? Martin Kouba >> < mkouba at redhat.com >: >> >> Ok, now I know what's going on. >> >> The event with payload "Application context initialized." comes >> directly >> from Weld. Whereas the second one java.lang.Object at 48813e62 comes from >> PAX CDI [1]. >> >> Up to version 2.2 Weld did not fire @Initialized/@Destroyed events for >> @ApplicationScoped for non-web modules. The behavior changed in 2.3 - >> see also WELD-1821 [2]. >> >> This explains the events fired twice. >> >> WRT Test bean instance created twice - the problem is that >> @Destroyed(ApplicationScoped.class) event is fired after the actual >> destruction. So if you declare an observer on an @ApplicationScoped >> you're entering the "undefined behavior zone". In Weld, the Test >> bean is >> created again. >> >> I've created WELD-2389 [3] to track this issue. >> >> Thanks, >> >> Martin >> >> [1] >> https://github.com/ops4j/org.ops4j.pax.cdi/blob/master/pax-cdi-weld/src/main/java/org/ops4j/pax/cdi/weld/impl/WeldCdiContainer.java#L154 >> >> [2] >> https://issues.jboss.org/browse/WELD-1821 >> >> [3] >> https://issues.jboss.org/browse/WELD-2389 >> >> >> Dne 22.5.2017 v 09:57 Alex Sviridov napsal(a): >> > Hi Martin >> > >> > Thank you for your answer. >> > >> > 1) I don't inject Test class anywhere. >> > 2) I modified init and destroy methods: >> > public void init(@Observes @Initialized(ApplicationScoped.class) >> > Object init) { >> > System.out.println(init); >> > System.out.println("Test was initialized"); >> > } >> > >> > public void destroy(@Observes @Destroyed(ApplicationScoped.class) >> > Object init) { >> > System.out.println(init); >> > System.out.println("Test was destroyed."); >> > } >> > >> > Now on bundle start: >> > >> > Test was created. >> > Application context initialized. >> > Test was initialized >> > java.lang.Object at 48813e62 >> > Test was initialized >> > >> > Now on bundle stop: >> > >> > java.lang.Object at 48813e62 >> > Test was destroyed. >> > Test was created. >> > Application context destroyed. >> > Test was destroyed. >> > >> > >> > ???????????, 22 ??? 2017, 10:48 +03:00 ?? Martin Kouba >> > < mkouba at redhat.com >: >> > >> > Hi Alex, >> > >> > this looks really weird. Could you try to print out the event >> payload, >> > e.g. System.out.println(init)? >> > >> > Also you should be always very careful when using code inside the >> > no-args constructor of a normal-scoped bean -> it will be also >> executed >> > when creating a client proxy. In your case, if you do @Inject >> Test and >> > invoke any method then you will also see "Test was created" printed >> > twice. >> > >> > Martin >> > >> > Dne 22.5.2017 v 08:50 Alex Sviridov napsal(a): >> > > Hi all >> > > >> > > I use pax-cdi -1.0.0.RC2 and weld 2.3.5.Final and this is my test >> > class: >> > > >> > > import javax.enterprise.context.ApplicationScoped; >> > > import javax.enterprise.context.Destroyed; >> > > import javax.enterprise.context.Initialized; >> > > import javax.enterprise.event.Observes; >> > > >> > > @ApplicationScoped >> > > public class Test { >> > > >> > > public Test() { >> > > System.out.println("Test was created."); >> > > } >> > > >> > > public void init(@Observes @Initialized(ApplicationScoped.class) >> > Object >> > > init) { >> > > System.out.println("Test was initialized"); >> > > } >> > > >> > > public void destroy(@Observes @Destroyed(ApplicationScoped.class) >> > > Object init) { >> > > System.out.println("Test was destroyed."); >> > > } >> > > } >> > > >> > > When I start test-bundle I see the following output: >> > > Test was created. >> > > Test was initialized >> > > Test was initialized >> > > When I stop test-bundle I see the following output: >> > > Test was destroyed. >> > > Test was created. >> > > Test was destroyed. >> > > >> > > So as result this bean was two times created, two times >> > initialized and two >> > > times destroyed. >> > > >> > > I expected that this bean must be once created, one initialized >> > and once >> > > destroyed. >> > > >> > > Is this a bug that must be reported or my mistake? >> > > >> > > -- >> > > Alex Sviridov >> > > >> > > >> > > _______________________________________________ >> > > weld-dev mailing list >> > > weld-dev at lists.jboss.org >> > >> > > https://lists.jboss.org/mailman/listinfo/weld-dev >> > > >> > >> > -- >> > Martin Kouba >> > Senior Software Engineer >> > Red Hat, Czech Republic >> > >> > >> > >> > -- >> > Alex Sviridov >> >> -- >> Martin Kouba >> Senior Software Engineer >> Red Hat, Czech Republic >> >> >> >> -- >> Alex Sviridov > >-- >Martin Kouba >Senior Software Engineer >Red Hat, Czech Republic -- Alex Sviridov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20170522/1aec086d/attachment-0001.html From mkouba at redhat.com Mon May 22 06:34:01 2017 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 22 May 2017 12:34:01 +0200 Subject: [weld-dev] Application scoped bean and its lifecycle In-Reply-To: <1495447398.656406100@f310.i.mail.ru> References: <1495435818.849704651@f411.i.mail.ru> <1495444449.685809882@f305.i.mail.ru> <1c736be7-18ed-1e15-73c5-73c44a956b59@redhat.com> <1495447398.656406100@f310.i.mail.ru> Message-ID: <0d970815-1656-a548-2a8d-e45ca3549a77@redhat.com> I don't recommend downgrading Weld. A more important issues could be fixed in newer versions. In your case, I would modify the Test bean to count with multiple @Initialized events and replace @Destroyed with @PreDestroy callback: class Test { void appContextInit(@Observes @Initialized(ApplicationScoped.class) init) { // Empty body - force eager instantiation } @PostConstruct void onInit() { // logic... will only be called once } @PreDestroy void onDestroy() { // logic.... will be called once before @Destroyed(ApplicationScoped.class) } } Dne 22.5.2017 v 12:03 Alex Sviridov napsal(a): > Martin, > > Thank you for your answer. I replaced 2.3.5.Final with 2.2.16.Final. > Besides in 2.2.16 > manifest I had to export package org.jboss.weld.config which is used by > pax-cdi. > > Now on bundle start: > Test was created. > java.lang.Object at 6bc3928f > Test was initialized > > Now on bundle stop: > java.lang.Object at 6bc3928f > Test was destroyed. > > ???????????, 22 ??? 2017, 12:27 +03:00 ?? Martin Kouba : > > > Dne 22.5.2017 v 11:14 Alex Sviridov napsal(a): > > Martin, > > > > In your message you wrote : "Up to version 2.2 Weld did not fire > > @Initialized/@Destroyed events for > > @ApplicationScoped for non-web modules.". > > > > In WELD-2389 you wrote : "Right now, this service is registered > for any > > non-SE environment". > > > > I use OSGi + PAX-CDI + WELD + JAVAFX. As I suppose this is a SE > > application (not EE). > > Could you explain "Right now, this service is registered for any > non-SE > > environment" ? > > Well, I'm talking about Weld SPI and I'm refering to the environment > info provided by the integrator. PAX CDI provides a custom > implementation of org.jboss.weld.bootstrap.api.Environment, which is > fine. The problem is that Weld currently skips registration only if > org.jboss.weld.bootstrap.api.Environments.SE is used. > > > > > Best regards, Alex > > > > > > ???????????, 22 ??? 2017, 11:51 +03:00 ?? Martin Kouba > > >: > > > > Ok, now I know what's going on. > > > > The event with payload "Application context initialized." comes > > directly > > from Weld. Whereas the second one java.lang.Object at 48813e62 comes > from > > PAX CDI [1]. > > > > Up to version 2.2 Weld did not fire @Initialized/@Destroyed > events for > > @ApplicationScoped for non-web modules. The behavior changed in 2.3 - > > see also WELD-1821 [2]. > > > > This explains the events fired twice. > > > > WRT Test bean instance created twice - the problem is that > > @Destroyed(ApplicationScoped.class) event is fired after the actual > > destruction. So if you declare an observer on an @ApplicationScoped > > you're entering the "undefined behavior zone". In Weld, the Test > > bean is > > created again. > > > > I've created WELD-2389 [3] to track this issue. > > > > Thanks, > > > > Martin > > > > [1] > > > https://github.com/ops4j/org.ops4j.pax.cdi/blob/master/pax-cdi-weld/src/main/java/org/ops4j/pax/cdi/weld/impl/WeldCdiContainer.java#L154 > > > > [2] > > https://issues.jboss.org/browse/WELD-1821 > > > > [3] > > https://issues.jboss.org/browse/WELD-2389 > > > > > > Dne 22.5.2017 v 09:57 Alex Sviridov napsal(a): > > > Hi Martin > > > > > > Thank you for your answer. > > > > > > 1) I don't inject Test class anywhere. > > > 2) I modified init and destroy methods: > > > public void init(@Observes @Initialized(ApplicationScoped.class) > > > Object init) { > > > System.out.println(init); > > > System.out.println("Test was initialized"); > > > } > > > > > > public void destroy(@Observes @Destroyed(ApplicationScoped.class) > > > Object init) { > > > System.out.println(init); > > > System.out.println("Test was destroyed."); > > > } > > > > > > Now on bundle start: > > > > > > Test was created. > > > Application context initialized. > > > Test was initialized > > > java.lang.Object at 48813e62 > > > Test was initialized > > > > > > Now on bundle stop: > > > > > > java.lang.Object at 48813e62 > > > Test was destroyed. > > > Test was created. > > > Application context destroyed. > > > Test was destroyed. > > > > > > > > > ???????????, 22 ??? 2017, 10:48 +03:00 ?? Martin Kouba > > > > >>: > > > > > > Hi Alex, > > > > > > this looks really weird. Could you try to print out the event > > payload, > > > e.g. System.out.println(init)? > > > > > > Also you should be always very careful when using code inside the > > > no-args constructor of a normal-scoped bean -> it will be also > > executed > > > when creating a client proxy. In your case, if you do @Inject > > Test and > > > invoke any method then you will also see "Test was created" printed > > > twice. > > > > > > Martin > > > > > > Dne 22.5.2017 v 08:50 Alex Sviridov napsal(a): > > > > Hi all > > > > > > > > I use pax-cdi -1.0.0.RC2 and weld 2.3.5.Final and this is my test > > > class: > > > > > > > > import javax.enterprise.context.ApplicationScoped; > > > > import javax.enterprise.context.Destroyed; > > > > import javax.enterprise.context.Initialized; > > > > import javax.enterprise.event.Observes; > > > > > > > > @ApplicationScoped > > > > public class Test { > > > > > > > > public Test() { > > > > System.out.println("Test was created."); > > > > } > > > > > > > > public void init(@Observes @Initialized(ApplicationScoped.class) > > > Object > > > > init) { > > > > System.out.println("Test was initialized"); > > > > } > > > > > > > > public void destroy(@Observes @Destroyed(ApplicationScoped.class) > > > > Object init) { > > > > System.out.println("Test was destroyed."); > > > > } > > > > } > > > > > > > > When I start test-bundle I see the following output: > > > > Test was created. > > > > Test was initialized > > > > Test was initialized > > > > When I stop test-bundle I see the following output: > > > > Test was destroyed. > > > > Test was created. > > > > Test was destroyed. > > > > > > > > So as result this bean was two times created, two times > > > initialized and two > > > > times destroyed. > > > > > > > > I expected that this bean must be once created, one initialized > > > and once > > > > destroyed. > > > > > > > > Is this a bug that must be reported or my mistake? > > > > > > > > -- > > > > Alex Sviridov > > > > > > > > > > > > _______________________________________________ > > > > weld-dev mailing list > > > > weld-dev at lists.jboss.org > > > > >> > > > > https://lists.jboss.org/mailman/listinfo/weld-dev > > > > > > > > > > -- > > > Martin Kouba > > > Senior Software Engineer > > > Red Hat, Czech Republic > > > > > > > > > > > > -- > > > Alex Sviridov > > > > -- > > Martin Kouba > > Senior Software Engineer > > Red Hat, Czech Republic > > > > > > > > -- > > Alex Sviridov > > -- > Martin Kouba > Senior Software Engineer > Red Hat, Czech Republic > > > > -- > Alex Sviridov -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic From EMIJIANG at uk.ibm.com Wed May 31 08:53:54 2017 From: EMIJIANG at uk.ibm.com (Emily Jiang) Date: Wed, 31 May 2017 13:53:54 +0100 Subject: [weld-dev] Interceptor & Interceptors Message-ID: Hi Martin, In the updated Interceptor spec, it has the following statement: "The Interceptor annotation is ignored on interceptor classes bound using the Interceptors annotation." I assume this already the case in Weld 2.x, CDI 1.2 implementation. Right? Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI & MicroProfile Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20170531/e1d86838/attachment.html