WELD-862 and Seam Cron
by Peter Royle
Hi,
I'm aiming to make a release of Seam Cron available within the next two weeks. Currently there is an outstanding issue (https://issues.jboss.org/browse/WELD-862) which prevents Cron from running properly with Weld. I have been able to carry on developing Cron by testing it against OpenWebBeans, but obviously if we are to release a Seam module it should work against Weld.
It would be nice if WELD-862 could be fixed as soon a possible so that all future versions will work well with Cron.
But more importantly I also probably need to do something special in Cron so that it will work with the version of Weld already deployed in JBoss AS and Glassfish, which will contain the bug. The workaround mentioned in the bug report is to deep copy the InvocationContext. I attempted to do this by serialising and unserialising the InvocationContext but couldn't due to UnserializableExceptions. Does anyone have any advice for me about how I might be able to work around this bug to support existing versions of Weld?
Cheers,
Pete R
3 months, 1 week
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, 11 months
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, 11 months
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, 11 months
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, 11 months
