Interceptor & Interceptors
by Emily Jiang
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(a)uk.ibm.com
Lotus Notes: Emily Jiang/UK/IBM@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
8 years, 1 month
Re: [weld-dev] Application scoped bean and its lifecycle
by Alex Sviridov
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@6bc3928f
Test was initialized
Now on bundle stop:
java.lang.Object@6bc3928f
Test was destroyed.
Понедельник, 22 мая 2017, 12:27 +03:00 от Martin Kouba <mkouba(a)redhat.com>:
>
>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(a)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@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/m...
>>
>> [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@48813e62
>> > Test was initialized
>> >
>> > Now on bundle stop:
>> >
>> > java.lang.Object@48813e62
>> > Test was destroyed.
>> > Test was created.
>> > Application context destroyed.
>> > Test was destroyed.
>> >
>> >
>> > Понедельник, 22 мая 2017, 10:48 +03:00 от Martin Kouba
>> > < mkouba(a)redhat.com <mailto: mkouba(a)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(a)lists.jboss.org <mailto: weld-dev(a)lists.jboss.org >
>> <mailto: weld-dev(a)lists.jboss.org <mailto: weld-dev(a)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
8 years, 1 month
Application scoped bean and its lifecycle
by Alex Sviridov
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
8 years, 1 month
Thread deadlock with osgi refresh
by Alex Sviridov
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
8 years, 2 months
