You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by "John D. Ament" <jo...@apache.org> on 2015/11/15 18:29:08 UTC
Regression - DeltaSpike 1.4.2 & Weld 2.3.1?
All,
I just tried upgrading my app locally to Weld 2.3.1 (in prep for a wildfly
10 upgrade). After upgrading Weld to 2.3.1, some of my repository tests
started failing with the following output.
java.lang.NullPointerException
at org.jboss.weld.util.Preconditions.checkNotNull(Preconditions.java:51)
at
org.jboss.weld.injection.AbstractResourceInjection.<init>(AbstractResourceInjection.java:39)
at
org.jboss.weld.injection.FieldResourceInjection.<init>(FieldResourceInjection.java:48)
at
org.jboss.weld.injection.ResourceInjectionFactory$ResourceInjectionProcessor.createFieldResourceInjection(ResourceInjectionFactory.java:217)
at
org.jboss.weld.injection.ResourceInjectionFactory$ResourceInjectionProcessor.createResourceInjections(ResourceInjectionFactory.java:189)
at
org.jboss.weld.injection.ResourceInjectionFactory.discoverType(ResourceInjectionFactory.java:449)
at
org.jboss.weld.injection.ResourceInjectionFactory.getResourceInjections(ResourceInjectionFactory.java:97)
at
org.jboss.weld.injection.producer.ResourceInjector.<init>(ResourceInjector.java:59)
at
org.jboss.weld.injection.producer.ResourceInjector.of(ResourceInjector.java:49)
at
org.jboss.weld.injection.producer.BeanInjectionTarget.<init>(BeanInjectionTarget.java:63)
at
org.jboss.weld.injection.producer.BeanInjectionTarget.createDefault(BeanInjectionTarget.java:47)
at
org.jboss.weld.manager.InjectionTargetFactoryImpl.chooseInjectionTarget(InjectionTargetFactoryImpl.java:128)
at
org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:87)
at org.jboss.weld.bean.ManagedBean.<init>(ManagedBean.java:100)
at org.jboss.weld.bean.ManagedBean.of(ManagedBean.java:80)
at
org.jboss.weld.bootstrap.AbstractBeanDeployer.createManagedBean(AbstractBeanDeployer.java:261)
at
org.jboss.weld.bootstrap.BeanDeployer.createClassBean(BeanDeployer.java:228)
at
org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:78)
at
org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:75)
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)
Useful, right?
Anyways, after running through the debuggah, I found that the
UserTransaction instance referenced in UserTransactionResolver was null and
was causing Weld to stop working. Looking at CI, it appears that we're
passing against 2.3.0, however the appropriate tests (e.g.
https://github.com/apache/deltaspike/blob/master/deltaspike/modules/data/impl/src/test/java/org/apache/deltaspike/data/impl/mapping/MappedRepositoryTest.java
)
are marked webprofile so I'm not sure they'd be run against a standalone
container this way.
Has anyone seen something like this? Just wondering before I ping the weld
guys.
John
Re: Regression - DeltaSpike 1.4.2 & Weld 2.3.1?
Posted by Gerhard Petracek <ge...@gmail.com>.
hi john,
since it's a regression in weld, you should be able to upgrade ds
(the resource-injection-point was just moved and not added).
regards,
gerhard
2015-11-15 21:48 GMT+01:00 John D. Ament <jo...@apache.org>:
> Not really feasible to upgrade right now, due to regression issues in the
> data module (previously discussed on list).
>
> However, your tip was useful. Unfortunately, it is a weld regression
> problem. Previously, these resource injected fields were just left as null
> (which is more appropriate from my stand point). Now weld is throwing a
> NPE when trying to inject them, since there's no provider for resource
> injection available.
>
> John
>
> On Sun, Nov 15, 2015 at 3:35 PM Gerhard Petracek <
> gerhard.petracek@gmail.com>
> wrote:
>
> > short addition:
> > please upgrade to the latest snapshot (the next release is due quite
> soon).
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2015-11-15 21:22 GMT+01:00 Gerhard Petracek <gerhard.petracek@gmail.com
> >:
> >
> > > hi john,
> > >
> > > we just moved the resource-injection-point one "level" back to support
> > > atomikos (see ManagedUserTransactionResolver).
> > > the first jndi lookup afterwards (which is used as a fallback), is
> > already
> > > what we had before.
> > >
> > > regards,
> > > gerhard
> > >
> > >
> > >
> > > 2015-11-15 18:29 GMT+01:00 John D. Ament <jo...@apache.org>:
> > >
> > >> All,
> > >>
> > >> I just tried upgrading my app locally to Weld 2.3.1 (in prep for a
> > wildfly
> > >> 10 upgrade). After upgrading Weld to 2.3.1, some of my repository
> tests
> > >> started failing with the following output.
> > >>
> > >> java.lang.NullPointerException
> > >>
> > >> at
> org.jboss.weld.util.Preconditions.checkNotNull(Preconditions.java:51)
> > >>
> > >> at
> > >>
> > >>
> >
> org.jboss.weld.injection.AbstractResourceInjection.<init>(AbstractResourceInjection.java:39)
> > >>
> > >> at
> > >>
> > >>
> >
> org.jboss.weld.injection.FieldResourceInjection.<init>(FieldResourceInjection.java:48)
> > >>
> > >> at
> > >>
> > >>
> >
> org.jboss.weld.injection.ResourceInjectionFactory$ResourceInjectionProcessor.createFieldResourceInjection(ResourceInjectionFactory.java:217)
> > >>
> > >> at
> > >>
> > >>
> >
> org.jboss.weld.injection.ResourceInjectionFactory$ResourceInjectionProcessor.createResourceInjections(ResourceInjectionFactory.java:189)
> > >>
> > >> at
> > >>
> > >>
> >
> org.jboss.weld.injection.ResourceInjectionFactory.discoverType(ResourceInjectionFactory.java:449)
> > >>
> > >> at
> > >>
> > >>
> >
> org.jboss.weld.injection.ResourceInjectionFactory.getResourceInjections(ResourceInjectionFactory.java:97)
> > >>
> > >> at
> > >>
> > >>
> >
> org.jboss.weld.injection.producer.ResourceInjector.<init>(ResourceInjector.java:59)
> > >>
> > >> at
> > >>
> > >>
> >
> org.jboss.weld.injection.producer.ResourceInjector.of(ResourceInjector.java:49)
> > >>
> > >> at
> > >>
> > >>
> >
> org.jboss.weld.injection.producer.BeanInjectionTarget.<init>(BeanInjectionTarget.java:63)
> > >>
> > >> at
> > >>
> > >>
> >
> org.jboss.weld.injection.producer.BeanInjectionTarget.createDefault(BeanInjectionTarget.java:47)
> > >>
> > >> at
> > >>
> > >>
> >
> org.jboss.weld.manager.InjectionTargetFactoryImpl.chooseInjectionTarget(InjectionTargetFactoryImpl.java:128)
> > >>
> > >> at
> > >>
> > >>
> >
> org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:87)
> > >>
> > >> at org.jboss.weld.bean.ManagedBean.<init>(ManagedBean.java:100)
> > >>
> > >> at org.jboss.weld.bean.ManagedBean.of(ManagedBean.java:80)
> > >>
> > >> at
> > >>
> > >>
> >
> org.jboss.weld.bootstrap.AbstractBeanDeployer.createManagedBean(AbstractBeanDeployer.java:261)
> > >>
> > >> at
> > >>
> > >>
> >
> org.jboss.weld.bootstrap.BeanDeployer.createClassBean(BeanDeployer.java:228)
> > >>
> > >> at
> > >>
> > >>
> >
> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:78)
> > >>
> > >> at
> > >>
> > >>
> >
> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:75)
> > >>
> > >> 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)
> > >>
> > >>
> > >> Useful, right?
> > >>
> > >>
> > >> Anyways, after running through the debuggah, I found that the
> > >> UserTransaction instance referenced in UserTransactionResolver was
> null
> > >> and
> > >> was causing Weld to stop working. Looking at CI, it appears that
> we're
> > >> passing against 2.3.0, however the appropriate tests (e.g.
> > >>
> > >>
> >
> https://github.com/apache/deltaspike/blob/master/deltaspike/modules/data/impl/src/test/java/org/apache/deltaspike/data/impl/mapping/MappedRepositoryTest.java
> > >> )
> > >> are marked webprofile so I'm not sure they'd be run against a
> standalone
> > >> container this way.
> > >>
> > >>
> > >> Has anyone seen something like this? Just wondering before I ping the
> > >> weld
> > >> guys.
> > >>
> > >>
> > >> John
> > >>
> > >
> > >
> >
>
Re: Regression - DeltaSpike 1.4.2 & Weld 2.3.1?
Posted by Mark Struberg <st...@yahoo.de>.
No, CDI-1.0 was specified to also work in SE already. See the already mentioned last paragraph in chapter 1. Remember that back in those times there was a political pressure to not market this feature too much ;)
We also discussed whether we need to change the wording back in CDI-1.1. But afair there was a common understanding that there is no necessity to change it as it is wide enough.
Anyway, glad it’s just a bug in an arquillian connector anyway.
LieGrue,
strub
> Am 19.11.2015 um 08:54 schrieb Martin Kouba <mk...@redhat.com>:
>
> Ok...
>
> 1. Up to 1.2 CDI itself is still an EE technology, and it's usage in Java SE is completely undefined
> 2. Why should CDI in Java SE care about EE resources? For the same reason an application is using (declares a dependency on) EE resources in Java SE.
>
> So I still think it is correct to fail fast if a bean requires an EE resource and it's not available.
>
> Martin
>
> Dne 18.11.2015 v 22:45 Mark Struberg napsal(a):
>> Martin, it seems you missed that the whole Resource section in the CDI spec ONLY applies if you run in an EE environment.
>>
>> This paragraph btw also mentions EJBs as a ‚resource‘ („For a remote EJB, @EJB must be specified…“). But I assume that you will agree with me that the CDI container shall NOT implement EJBs just because of that paragraph, right? So why should CDI in JavaSE care about EE resources?
>>
>> LieGrue,
>> strub
>>
>>
>>> Am 18.11.2015 um 10:52 schrieb Martin Kouba <mk...@redhat.com>:
>>>
>>> Well, I wouldn't say it's a Weld regression, more like a change in behaviour which follows the way CDI handles unsatisfied dependencies. On the other hand the error message should be definitely more clear (NPE is not really user-friendly ;-).
>>>
>>> Martin
>>>
>>> Dne 15.11.2015 v 21:48 John D. Ament napsal(a):
>>>> Not really feasible to upgrade right now, due to regression issues in the
>>>> data module (previously discussed on list).
>>>>
>>>> However, your tip was useful. Unfortunately, it is a weld regression
>>>> problem. Previously, these resource injected fields were just left as null
>>>> (which is more appropriate from my stand point). Now weld is throwing a
>>>> NPE when trying to inject them, since there's no provider for resource
>>>> injection available.
>>>>
>>>> John
>>>>
>>>> On Sun, Nov 15, 2015 at 3:35 PM Gerhard Petracek <ge...@gmail.com>
>>>> wrote:
>>>>
>>>>> short addition:
>>>>> please upgrade to the latest snapshot (the next release is due quite soon).
>>>>>
>>>>> regards,
>>>>> gerhard
>>>>>
>>>>>
>>>>>
>>>>> 2015-11-15 21:22 GMT+01:00 Gerhard Petracek <ge...@gmail.com>:
>>>>>
>>>>>> hi john,
>>>>>>
>>>>>> we just moved the resource-injection-point one "level" back to support
>>>>>> atomikos (see ManagedUserTransactionResolver).
>>>>>> the first jndi lookup afterwards (which is used as a fallback), is
>>>>> already
>>>>>> what we had before.
>>>>>>
>>>>>> regards,
>>>>>> gerhard
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2015-11-15 18:29 GMT+01:00 John D. Ament <jo...@apache.org>:
>>>>>>
>>>>>>> All,
>>>>>>>
>>>>>>> I just tried upgrading my app locally to Weld 2.3.1 (in prep for a
>>>>> wildfly
>>>>>>> 10 upgrade). After upgrading Weld to 2.3.1, some of my repository tests
>>>>>>> started failing with the following output.
>>>>>>>
>>>>>>> java.lang.NullPointerException
>>>>>>>
>>>>>>> at org.jboss.weld.util.Preconditions.checkNotNull(Preconditions.java:51)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.jboss.weld.injection.AbstractResourceInjection.<init>(AbstractResourceInjection.java:39)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.jboss.weld.injection.FieldResourceInjection.<init>(FieldResourceInjection.java:48)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.jboss.weld.injection.ResourceInjectionFactory$ResourceInjectionProcessor.createFieldResourceInjection(ResourceInjectionFactory.java:217)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.jboss.weld.injection.ResourceInjectionFactory$ResourceInjectionProcessor.createResourceInjections(ResourceInjectionFactory.java:189)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.jboss.weld.injection.ResourceInjectionFactory.discoverType(ResourceInjectionFactory.java:449)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.jboss.weld.injection.ResourceInjectionFactory.getResourceInjections(ResourceInjectionFactory.java:97)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.jboss.weld.injection.producer.ResourceInjector.<init>(ResourceInjector.java:59)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.jboss.weld.injection.producer.ResourceInjector.of(ResourceInjector.java:49)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.jboss.weld.injection.producer.BeanInjectionTarget.<init>(BeanInjectionTarget.java:63)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.jboss.weld.injection.producer.BeanInjectionTarget.createDefault(BeanInjectionTarget.java:47)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.jboss.weld.manager.InjectionTargetFactoryImpl.chooseInjectionTarget(InjectionTargetFactoryImpl.java:128)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:87)
>>>>>>>
>>>>>>> at org.jboss.weld.bean.ManagedBean.<init>(ManagedBean.java:100)
>>>>>>>
>>>>>>> at org.jboss.weld.bean.ManagedBean.of(ManagedBean.java:80)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.jboss.weld.bootstrap.AbstractBeanDeployer.createManagedBean(AbstractBeanDeployer.java:261)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.jboss.weld.bootstrap.BeanDeployer.createClassBean(BeanDeployer.java:228)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:78)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:75)
>>>>>>>
>>>>>>> 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)
>>>>>>>
>>>>>>>
>>>>>>> Useful, right?
>>>>>>>
>>>>>>>
>>>>>>> Anyways, after running through the debuggah, I found that the
>>>>>>> UserTransaction instance referenced in UserTransactionResolver was null
>>>>>>> and
>>>>>>> was causing Weld to stop working. Looking at CI, it appears that we're
>>>>>>> passing against 2.3.0, however the appropriate tests (e.g.
>>>>>>>
>>>>>>>
>>>>> https://github.com/apache/deltaspike/blob/master/deltaspike/modules/data/impl/src/test/java/org/apache/deltaspike/data/impl/mapping/MappedRepositoryTest.java
>>>>>>> )
>>>>>>> are marked webprofile so I'm not sure they'd be run against a standalone
>>>>>>> container this way.
>>>>>>>
>>>>>>>
>>>>>>> Has anyone seen something like this? Just wondering before I ping the
>>>>>>> weld
>>>>>>> guys.
>>>>>>>
>>>>>>>
>>>>>>> John
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> --
>>> Martin Kouba
>>> Software Engineer
>>> Red Hat, Czech Republic
>>
>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
Re: Regression - DeltaSpike 1.4.2 & Weld 2.3.1?
Posted by Martin Kouba <mk...@redhat.com>.
FYI it seems it's more an arquillian-weld-ee-embedded-1.1 issue.
See also https://issues.jboss.org/browse/WELD-2065
Martin
Dne 19.11.2015 v 08:54 Martin Kouba napsal(a):
> Ok...
>
> 1. Up to 1.2 CDI itself is still an EE technology, and it's usage in
> Java SE is completely undefined
> 2. Why should CDI in Java SE care about EE resources? For the same
> reason an application is using (declares a dependency on) EE resources
> in Java SE.
>
> So I still think it is correct to fail fast if a bean requires an EE
> resource and it's not available.
>
> Martin
>
> Dne 18.11.2015 v 22:45 Mark Struberg napsal(a):
>> Martin, it seems you missed that the whole Resource section in the CDI
>> spec ONLY applies if you run in an EE environment.
>>
>> This paragraph btw also mentions EJBs as a ‚resource‘ („For a remote
>> EJB, @EJB must be specified…“). But I assume that you will agree with
>> me that the CDI container shall NOT implement EJBs just because of
>> that paragraph, right? So why should CDI in JavaSE care about EE
>> resources?
>>
>> LieGrue,
>> strub
>>
>>
>>> Am 18.11.2015 um 10:52 schrieb Martin Kouba <mk...@redhat.com>:
>>>
>>> Well, I wouldn't say it's a Weld regression, more like a change in
>>> behaviour which follows the way CDI handles unsatisfied dependencies.
>>> On the other hand the error message should be definitely more clear
>>> (NPE is not really user-friendly ;-).
>>>
>>> Martin
>>>
>>> Dne 15.11.2015 v 21:48 John D. Ament napsal(a):
>>>> Not really feasible to upgrade right now, due to regression issues
>>>> in the
>>>> data module (previously discussed on list).
>>>>
>>>> However, your tip was useful. Unfortunately, it is a weld regression
>>>> problem. Previously, these resource injected fields were just left
>>>> as null
>>>> (which is more appropriate from my stand point). Now weld is
>>>> throwing a
>>>> NPE when trying to inject them, since there's no provider for resource
>>>> injection available.
>>>>
>>>> John
>>>>
>>>> On Sun, Nov 15, 2015 at 3:35 PM Gerhard Petracek
>>>> <ge...@gmail.com>
>>>> wrote:
>>>>
>>>>> short addition:
>>>>> please upgrade to the latest snapshot (the next release is due
>>>>> quite soon).
>>>>>
>>>>> regards,
>>>>> gerhard
>>>>>
>>>>>
>>>>>
>>>>> 2015-11-15 21:22 GMT+01:00 Gerhard Petracek
>>>>> <ge...@gmail.com>:
>>>>>
>>>>>> hi john,
>>>>>>
>>>>>> we just moved the resource-injection-point one "level" back to
>>>>>> support
>>>>>> atomikos (see ManagedUserTransactionResolver).
>>>>>> the first jndi lookup afterwards (which is used as a fallback), is
>>>>> already
>>>>>> what we had before.
>>>>>>
>>>>>> regards,
>>>>>> gerhard
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2015-11-15 18:29 GMT+01:00 John D. Ament <jo...@apache.org>:
>>>>>>
>>>>>>> All,
>>>>>>>
>>>>>>> I just tried upgrading my app locally to Weld 2.3.1 (in prep for a
>>>>> wildfly
>>>>>>> 10 upgrade). After upgrading Weld to 2.3.1, some of my
>>>>>>> repository tests
>>>>>>> started failing with the following output.
>>>>>>>
>>>>>>> java.lang.NullPointerException
>>>>>>>
>>>>>>> at
>>>>>>> org.jboss.weld.util.Preconditions.checkNotNull(Preconditions.java:51)
>>>>>>>
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.jboss.weld.injection.AbstractResourceInjection.<init>(AbstractResourceInjection.java:39)
>>>>>
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.jboss.weld.injection.FieldResourceInjection.<init>(FieldResourceInjection.java:48)
>>>>>
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.jboss.weld.injection.ResourceInjectionFactory$ResourceInjectionProcessor.createFieldResourceInjection(ResourceInjectionFactory.java:217)
>>>>>
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.jboss.weld.injection.ResourceInjectionFactory$ResourceInjectionProcessor.createResourceInjections(ResourceInjectionFactory.java:189)
>>>>>
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.jboss.weld.injection.ResourceInjectionFactory.discoverType(ResourceInjectionFactory.java:449)
>>>>>
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.jboss.weld.injection.ResourceInjectionFactory.getResourceInjections(ResourceInjectionFactory.java:97)
>>>>>
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.jboss.weld.injection.producer.ResourceInjector.<init>(ResourceInjector.java:59)
>>>>>
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.jboss.weld.injection.producer.ResourceInjector.of(ResourceInjector.java:49)
>>>>>
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.jboss.weld.injection.producer.BeanInjectionTarget.<init>(BeanInjectionTarget.java:63)
>>>>>
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.jboss.weld.injection.producer.BeanInjectionTarget.createDefault(BeanInjectionTarget.java:47)
>>>>>
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.jboss.weld.manager.InjectionTargetFactoryImpl.chooseInjectionTarget(InjectionTargetFactoryImpl.java:128)
>>>>>
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:87)
>>>>>
>>>>>>>
>>>>>>> at org.jboss.weld.bean.ManagedBean.<init>(ManagedBean.java:100)
>>>>>>>
>>>>>>> at org.jboss.weld.bean.ManagedBean.of(ManagedBean.java:80)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.jboss.weld.bootstrap.AbstractBeanDeployer.createManagedBean(AbstractBeanDeployer.java:261)
>>>>>
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.jboss.weld.bootstrap.BeanDeployer.createClassBean(BeanDeployer.java:228)
>>>>>
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:78)
>>>>>
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:75)
>>>>>
>>>>>>>
>>>>>>> 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)
>>>>>>>
>>>>>>>
>>>>>>> Useful, right?
>>>>>>>
>>>>>>>
>>>>>>> Anyways, after running through the debuggah, I found that the
>>>>>>> UserTransaction instance referenced in UserTransactionResolver
>>>>>>> was null
>>>>>>> and
>>>>>>> was causing Weld to stop working. Looking at CI, it appears that
>>>>>>> we're
>>>>>>> passing against 2.3.0, however the appropriate tests (e.g.
>>>>>>>
>>>>>>>
>>>>> https://github.com/apache/deltaspike/blob/master/deltaspike/modules/data/impl/src/test/java/org/apache/deltaspike/data/impl/mapping/MappedRepositoryTest.java
>>>>>
>>>>>>> )
>>>>>>> are marked webprofile so I'm not sure they'd be run against a
>>>>>>> standalone
>>>>>>> container this way.
>>>>>>>
>>>>>>>
>>>>>>> Has anyone seen something like this? Just wondering before I
>>>>>>> ping the
>>>>>>> weld
>>>>>>> guys.
>>>>>>>
>>>>>>>
>>>>>>> John
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> --
>>> Martin Kouba
>>> Software Engineer
>>> Red Hat, Czech Republic
>>
>
--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
Re: Regression - DeltaSpike 1.4.2 & Weld 2.3.1?
Posted by Martin Kouba <mk...@redhat.com>.
Ok...
1. Up to 1.2 CDI itself is still an EE technology, and it's usage in
Java SE is completely undefined
2. Why should CDI in Java SE care about EE resources? For the same
reason an application is using (declares a dependency on) EE resources
in Java SE.
So I still think it is correct to fail fast if a bean requires an EE
resource and it's not available.
Martin
Dne 18.11.2015 v 22:45 Mark Struberg napsal(a):
> Martin, it seems you missed that the whole Resource section in the CDI spec ONLY applies if you run in an EE environment.
>
> This paragraph btw also mentions EJBs as a ‚resource‘ („For a remote EJB, @EJB must be specified…“). But I assume that you will agree with me that the CDI container shall NOT implement EJBs just because of that paragraph, right? So why should CDI in JavaSE care about EE resources?
>
> LieGrue,
> strub
>
>
>> Am 18.11.2015 um 10:52 schrieb Martin Kouba <mk...@redhat.com>:
>>
>> Well, I wouldn't say it's a Weld regression, more like a change in behaviour which follows the way CDI handles unsatisfied dependencies. On the other hand the error message should be definitely more clear (NPE is not really user-friendly ;-).
>>
>> Martin
>>
>> Dne 15.11.2015 v 21:48 John D. Ament napsal(a):
>>> Not really feasible to upgrade right now, due to regression issues in the
>>> data module (previously discussed on list).
>>>
>>> However, your tip was useful. Unfortunately, it is a weld regression
>>> problem. Previously, these resource injected fields were just left as null
>>> (which is more appropriate from my stand point). Now weld is throwing a
>>> NPE when trying to inject them, since there's no provider for resource
>>> injection available.
>>>
>>> John
>>>
>>> On Sun, Nov 15, 2015 at 3:35 PM Gerhard Petracek <ge...@gmail.com>
>>> wrote:
>>>
>>>> short addition:
>>>> please upgrade to the latest snapshot (the next release is due quite soon).
>>>>
>>>> regards,
>>>> gerhard
>>>>
>>>>
>>>>
>>>> 2015-11-15 21:22 GMT+01:00 Gerhard Petracek <ge...@gmail.com>:
>>>>
>>>>> hi john,
>>>>>
>>>>> we just moved the resource-injection-point one "level" back to support
>>>>> atomikos (see ManagedUserTransactionResolver).
>>>>> the first jndi lookup afterwards (which is used as a fallback), is
>>>> already
>>>>> what we had before.
>>>>>
>>>>> regards,
>>>>> gerhard
>>>>>
>>>>>
>>>>>
>>>>> 2015-11-15 18:29 GMT+01:00 John D. Ament <jo...@apache.org>:
>>>>>
>>>>>> All,
>>>>>>
>>>>>> I just tried upgrading my app locally to Weld 2.3.1 (in prep for a
>>>> wildfly
>>>>>> 10 upgrade). After upgrading Weld to 2.3.1, some of my repository tests
>>>>>> started failing with the following output.
>>>>>>
>>>>>> java.lang.NullPointerException
>>>>>>
>>>>>> at org.jboss.weld.util.Preconditions.checkNotNull(Preconditions.java:51)
>>>>>>
>>>>>> at
>>>>>>
>>>>>>
>>>> org.jboss.weld.injection.AbstractResourceInjection.<init>(AbstractResourceInjection.java:39)
>>>>>>
>>>>>> at
>>>>>>
>>>>>>
>>>> org.jboss.weld.injection.FieldResourceInjection.<init>(FieldResourceInjection.java:48)
>>>>>>
>>>>>> at
>>>>>>
>>>>>>
>>>> org.jboss.weld.injection.ResourceInjectionFactory$ResourceInjectionProcessor.createFieldResourceInjection(ResourceInjectionFactory.java:217)
>>>>>>
>>>>>> at
>>>>>>
>>>>>>
>>>> org.jboss.weld.injection.ResourceInjectionFactory$ResourceInjectionProcessor.createResourceInjections(ResourceInjectionFactory.java:189)
>>>>>>
>>>>>> at
>>>>>>
>>>>>>
>>>> org.jboss.weld.injection.ResourceInjectionFactory.discoverType(ResourceInjectionFactory.java:449)
>>>>>>
>>>>>> at
>>>>>>
>>>>>>
>>>> org.jboss.weld.injection.ResourceInjectionFactory.getResourceInjections(ResourceInjectionFactory.java:97)
>>>>>>
>>>>>> at
>>>>>>
>>>>>>
>>>> org.jboss.weld.injection.producer.ResourceInjector.<init>(ResourceInjector.java:59)
>>>>>>
>>>>>> at
>>>>>>
>>>>>>
>>>> org.jboss.weld.injection.producer.ResourceInjector.of(ResourceInjector.java:49)
>>>>>>
>>>>>> at
>>>>>>
>>>>>>
>>>> org.jboss.weld.injection.producer.BeanInjectionTarget.<init>(BeanInjectionTarget.java:63)
>>>>>>
>>>>>> at
>>>>>>
>>>>>>
>>>> org.jboss.weld.injection.producer.BeanInjectionTarget.createDefault(BeanInjectionTarget.java:47)
>>>>>>
>>>>>> at
>>>>>>
>>>>>>
>>>> org.jboss.weld.manager.InjectionTargetFactoryImpl.chooseInjectionTarget(InjectionTargetFactoryImpl.java:128)
>>>>>>
>>>>>> at
>>>>>>
>>>>>>
>>>> org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:87)
>>>>>>
>>>>>> at org.jboss.weld.bean.ManagedBean.<init>(ManagedBean.java:100)
>>>>>>
>>>>>> at org.jboss.weld.bean.ManagedBean.of(ManagedBean.java:80)
>>>>>>
>>>>>> at
>>>>>>
>>>>>>
>>>> org.jboss.weld.bootstrap.AbstractBeanDeployer.createManagedBean(AbstractBeanDeployer.java:261)
>>>>>>
>>>>>> at
>>>>>>
>>>>>>
>>>> org.jboss.weld.bootstrap.BeanDeployer.createClassBean(BeanDeployer.java:228)
>>>>>>
>>>>>> at
>>>>>>
>>>>>>
>>>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:78)
>>>>>>
>>>>>> at
>>>>>>
>>>>>>
>>>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:75)
>>>>>>
>>>>>> 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)
>>>>>>
>>>>>>
>>>>>> Useful, right?
>>>>>>
>>>>>>
>>>>>> Anyways, after running through the debuggah, I found that the
>>>>>> UserTransaction instance referenced in UserTransactionResolver was null
>>>>>> and
>>>>>> was causing Weld to stop working. Looking at CI, it appears that we're
>>>>>> passing against 2.3.0, however the appropriate tests (e.g.
>>>>>>
>>>>>>
>>>> https://github.com/apache/deltaspike/blob/master/deltaspike/modules/data/impl/src/test/java/org/apache/deltaspike/data/impl/mapping/MappedRepositoryTest.java
>>>>>> )
>>>>>> are marked webprofile so I'm not sure they'd be run against a standalone
>>>>>> container this way.
>>>>>>
>>>>>>
>>>>>> Has anyone seen something like this? Just wondering before I ping the
>>>>>> weld
>>>>>> guys.
>>>>>>
>>>>>>
>>>>>> John
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>> --
>> Martin Kouba
>> Software Engineer
>> Red Hat, Czech Republic
>
--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
Re: Regression - DeltaSpike 1.4.2 & Weld 2.3.1?
Posted by Mark Struberg <st...@yahoo.de>.
Martin, it seems you missed that the whole Resource section in the CDI spec ONLY applies if you run in an EE environment.
This paragraph btw also mentions EJBs as a ‚resource‘ („For a remote EJB, @EJB must be specified…“). But I assume that you will agree with me that the CDI container shall NOT implement EJBs just because of that paragraph, right? So why should CDI in JavaSE care about EE resources?
LieGrue,
strub
> Am 18.11.2015 um 10:52 schrieb Martin Kouba <mk...@redhat.com>:
>
> Well, I wouldn't say it's a Weld regression, more like a change in behaviour which follows the way CDI handles unsatisfied dependencies. On the other hand the error message should be definitely more clear (NPE is not really user-friendly ;-).
>
> Martin
>
> Dne 15.11.2015 v 21:48 John D. Ament napsal(a):
>> Not really feasible to upgrade right now, due to regression issues in the
>> data module (previously discussed on list).
>>
>> However, your tip was useful. Unfortunately, it is a weld regression
>> problem. Previously, these resource injected fields were just left as null
>> (which is more appropriate from my stand point). Now weld is throwing a
>> NPE when trying to inject them, since there's no provider for resource
>> injection available.
>>
>> John
>>
>> On Sun, Nov 15, 2015 at 3:35 PM Gerhard Petracek <ge...@gmail.com>
>> wrote:
>>
>>> short addition:
>>> please upgrade to the latest snapshot (the next release is due quite soon).
>>>
>>> regards,
>>> gerhard
>>>
>>>
>>>
>>> 2015-11-15 21:22 GMT+01:00 Gerhard Petracek <ge...@gmail.com>:
>>>
>>>> hi john,
>>>>
>>>> we just moved the resource-injection-point one "level" back to support
>>>> atomikos (see ManagedUserTransactionResolver).
>>>> the first jndi lookup afterwards (which is used as a fallback), is
>>> already
>>>> what we had before.
>>>>
>>>> regards,
>>>> gerhard
>>>>
>>>>
>>>>
>>>> 2015-11-15 18:29 GMT+01:00 John D. Ament <jo...@apache.org>:
>>>>
>>>>> All,
>>>>>
>>>>> I just tried upgrading my app locally to Weld 2.3.1 (in prep for a
>>> wildfly
>>>>> 10 upgrade). After upgrading Weld to 2.3.1, some of my repository tests
>>>>> started failing with the following output.
>>>>>
>>>>> java.lang.NullPointerException
>>>>>
>>>>> at org.jboss.weld.util.Preconditions.checkNotNull(Preconditions.java:51)
>>>>>
>>>>> at
>>>>>
>>>>>
>>> org.jboss.weld.injection.AbstractResourceInjection.<init>(AbstractResourceInjection.java:39)
>>>>>
>>>>> at
>>>>>
>>>>>
>>> org.jboss.weld.injection.FieldResourceInjection.<init>(FieldResourceInjection.java:48)
>>>>>
>>>>> at
>>>>>
>>>>>
>>> org.jboss.weld.injection.ResourceInjectionFactory$ResourceInjectionProcessor.createFieldResourceInjection(ResourceInjectionFactory.java:217)
>>>>>
>>>>> at
>>>>>
>>>>>
>>> org.jboss.weld.injection.ResourceInjectionFactory$ResourceInjectionProcessor.createResourceInjections(ResourceInjectionFactory.java:189)
>>>>>
>>>>> at
>>>>>
>>>>>
>>> org.jboss.weld.injection.ResourceInjectionFactory.discoverType(ResourceInjectionFactory.java:449)
>>>>>
>>>>> at
>>>>>
>>>>>
>>> org.jboss.weld.injection.ResourceInjectionFactory.getResourceInjections(ResourceInjectionFactory.java:97)
>>>>>
>>>>> at
>>>>>
>>>>>
>>> org.jboss.weld.injection.producer.ResourceInjector.<init>(ResourceInjector.java:59)
>>>>>
>>>>> at
>>>>>
>>>>>
>>> org.jboss.weld.injection.producer.ResourceInjector.of(ResourceInjector.java:49)
>>>>>
>>>>> at
>>>>>
>>>>>
>>> org.jboss.weld.injection.producer.BeanInjectionTarget.<init>(BeanInjectionTarget.java:63)
>>>>>
>>>>> at
>>>>>
>>>>>
>>> org.jboss.weld.injection.producer.BeanInjectionTarget.createDefault(BeanInjectionTarget.java:47)
>>>>>
>>>>> at
>>>>>
>>>>>
>>> org.jboss.weld.manager.InjectionTargetFactoryImpl.chooseInjectionTarget(InjectionTargetFactoryImpl.java:128)
>>>>>
>>>>> at
>>>>>
>>>>>
>>> org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:87)
>>>>>
>>>>> at org.jboss.weld.bean.ManagedBean.<init>(ManagedBean.java:100)
>>>>>
>>>>> at org.jboss.weld.bean.ManagedBean.of(ManagedBean.java:80)
>>>>>
>>>>> at
>>>>>
>>>>>
>>> org.jboss.weld.bootstrap.AbstractBeanDeployer.createManagedBean(AbstractBeanDeployer.java:261)
>>>>>
>>>>> at
>>>>>
>>>>>
>>> org.jboss.weld.bootstrap.BeanDeployer.createClassBean(BeanDeployer.java:228)
>>>>>
>>>>> at
>>>>>
>>>>>
>>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:78)
>>>>>
>>>>> at
>>>>>
>>>>>
>>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:75)
>>>>>
>>>>> 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)
>>>>>
>>>>>
>>>>> Useful, right?
>>>>>
>>>>>
>>>>> Anyways, after running through the debuggah, I found that the
>>>>> UserTransaction instance referenced in UserTransactionResolver was null
>>>>> and
>>>>> was causing Weld to stop working. Looking at CI, it appears that we're
>>>>> passing against 2.3.0, however the appropriate tests (e.g.
>>>>>
>>>>>
>>> https://github.com/apache/deltaspike/blob/master/deltaspike/modules/data/impl/src/test/java/org/apache/deltaspike/data/impl/mapping/MappedRepositoryTest.java
>>>>> )
>>>>> are marked webprofile so I'm not sure they'd be run against a standalone
>>>>> container this way.
>>>>>
>>>>>
>>>>> Has anyone seen something like this? Just wondering before I ping the
>>>>> weld
>>>>> guys.
>>>>>
>>>>>
>>>>> John
>>>>>
>>>>
>>>>
>>>
>>
>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
Re: Regression - DeltaSpike 1.4.2 & Weld 2.3.1?
Posted by Martin Kouba <mk...@redhat.com>.
Well, I wouldn't say it's a Weld regression, more like a change in
behaviour which follows the way CDI handles unsatisfied dependencies. On
the other hand the error message should be definitely more clear (NPE is
not really user-friendly ;-).
Martin
Dne 15.11.2015 v 21:48 John D. Ament napsal(a):
> Not really feasible to upgrade right now, due to regression issues in the
> data module (previously discussed on list).
>
> However, your tip was useful. Unfortunately, it is a weld regression
> problem. Previously, these resource injected fields were just left as null
> (which is more appropriate from my stand point). Now weld is throwing a
> NPE when trying to inject them, since there's no provider for resource
> injection available.
>
> John
>
> On Sun, Nov 15, 2015 at 3:35 PM Gerhard Petracek <ge...@gmail.com>
> wrote:
>
>> short addition:
>> please upgrade to the latest snapshot (the next release is due quite soon).
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2015-11-15 21:22 GMT+01:00 Gerhard Petracek <ge...@gmail.com>:
>>
>>> hi john,
>>>
>>> we just moved the resource-injection-point one "level" back to support
>>> atomikos (see ManagedUserTransactionResolver).
>>> the first jndi lookup afterwards (which is used as a fallback), is
>> already
>>> what we had before.
>>>
>>> regards,
>>> gerhard
>>>
>>>
>>>
>>> 2015-11-15 18:29 GMT+01:00 John D. Ament <jo...@apache.org>:
>>>
>>>> All,
>>>>
>>>> I just tried upgrading my app locally to Weld 2.3.1 (in prep for a
>> wildfly
>>>> 10 upgrade). After upgrading Weld to 2.3.1, some of my repository tests
>>>> started failing with the following output.
>>>>
>>>> java.lang.NullPointerException
>>>>
>>>> at org.jboss.weld.util.Preconditions.checkNotNull(Preconditions.java:51)
>>>>
>>>> at
>>>>
>>>>
>> org.jboss.weld.injection.AbstractResourceInjection.<init>(AbstractResourceInjection.java:39)
>>>>
>>>> at
>>>>
>>>>
>> org.jboss.weld.injection.FieldResourceInjection.<init>(FieldResourceInjection.java:48)
>>>>
>>>> at
>>>>
>>>>
>> org.jboss.weld.injection.ResourceInjectionFactory$ResourceInjectionProcessor.createFieldResourceInjection(ResourceInjectionFactory.java:217)
>>>>
>>>> at
>>>>
>>>>
>> org.jboss.weld.injection.ResourceInjectionFactory$ResourceInjectionProcessor.createResourceInjections(ResourceInjectionFactory.java:189)
>>>>
>>>> at
>>>>
>>>>
>> org.jboss.weld.injection.ResourceInjectionFactory.discoverType(ResourceInjectionFactory.java:449)
>>>>
>>>> at
>>>>
>>>>
>> org.jboss.weld.injection.ResourceInjectionFactory.getResourceInjections(ResourceInjectionFactory.java:97)
>>>>
>>>> at
>>>>
>>>>
>> org.jboss.weld.injection.producer.ResourceInjector.<init>(ResourceInjector.java:59)
>>>>
>>>> at
>>>>
>>>>
>> org.jboss.weld.injection.producer.ResourceInjector.of(ResourceInjector.java:49)
>>>>
>>>> at
>>>>
>>>>
>> org.jboss.weld.injection.producer.BeanInjectionTarget.<init>(BeanInjectionTarget.java:63)
>>>>
>>>> at
>>>>
>>>>
>> org.jboss.weld.injection.producer.BeanInjectionTarget.createDefault(BeanInjectionTarget.java:47)
>>>>
>>>> at
>>>>
>>>>
>> org.jboss.weld.manager.InjectionTargetFactoryImpl.chooseInjectionTarget(InjectionTargetFactoryImpl.java:128)
>>>>
>>>> at
>>>>
>>>>
>> org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:87)
>>>>
>>>> at org.jboss.weld.bean.ManagedBean.<init>(ManagedBean.java:100)
>>>>
>>>> at org.jboss.weld.bean.ManagedBean.of(ManagedBean.java:80)
>>>>
>>>> at
>>>>
>>>>
>> org.jboss.weld.bootstrap.AbstractBeanDeployer.createManagedBean(AbstractBeanDeployer.java:261)
>>>>
>>>> at
>>>>
>>>>
>> org.jboss.weld.bootstrap.BeanDeployer.createClassBean(BeanDeployer.java:228)
>>>>
>>>> at
>>>>
>>>>
>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:78)
>>>>
>>>> at
>>>>
>>>>
>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:75)
>>>>
>>>> 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)
>>>>
>>>>
>>>> Useful, right?
>>>>
>>>>
>>>> Anyways, after running through the debuggah, I found that the
>>>> UserTransaction instance referenced in UserTransactionResolver was null
>>>> and
>>>> was causing Weld to stop working. Looking at CI, it appears that we're
>>>> passing against 2.3.0, however the appropriate tests (e.g.
>>>>
>>>>
>> https://github.com/apache/deltaspike/blob/master/deltaspike/modules/data/impl/src/test/java/org/apache/deltaspike/data/impl/mapping/MappedRepositoryTest.java
>>>> )
>>>> are marked webprofile so I'm not sure they'd be run against a standalone
>>>> container this way.
>>>>
>>>>
>>>> Has anyone seen something like this? Just wondering before I ping the
>>>> weld
>>>> guys.
>>>>
>>>>
>>>> John
>>>>
>>>
>>>
>>
>
--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
Re: Regression - DeltaSpike 1.4.2 & Weld 2.3.1?
Posted by "John D. Ament" <jo...@apache.org>.
Not really feasible to upgrade right now, due to regression issues in the
data module (previously discussed on list).
However, your tip was useful. Unfortunately, it is a weld regression
problem. Previously, these resource injected fields were just left as null
(which is more appropriate from my stand point). Now weld is throwing a
NPE when trying to inject them, since there's no provider for resource
injection available.
John
On Sun, Nov 15, 2015 at 3:35 PM Gerhard Petracek <ge...@gmail.com>
wrote:
> short addition:
> please upgrade to the latest snapshot (the next release is due quite soon).
>
> regards,
> gerhard
>
>
>
> 2015-11-15 21:22 GMT+01:00 Gerhard Petracek <ge...@gmail.com>:
>
> > hi john,
> >
> > we just moved the resource-injection-point one "level" back to support
> > atomikos (see ManagedUserTransactionResolver).
> > the first jndi lookup afterwards (which is used as a fallback), is
> already
> > what we had before.
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2015-11-15 18:29 GMT+01:00 John D. Ament <jo...@apache.org>:
> >
> >> All,
> >>
> >> I just tried upgrading my app locally to Weld 2.3.1 (in prep for a
> wildfly
> >> 10 upgrade). After upgrading Weld to 2.3.1, some of my repository tests
> >> started failing with the following output.
> >>
> >> java.lang.NullPointerException
> >>
> >> at org.jboss.weld.util.Preconditions.checkNotNull(Preconditions.java:51)
> >>
> >> at
> >>
> >>
> org.jboss.weld.injection.AbstractResourceInjection.<init>(AbstractResourceInjection.java:39)
> >>
> >> at
> >>
> >>
> org.jboss.weld.injection.FieldResourceInjection.<init>(FieldResourceInjection.java:48)
> >>
> >> at
> >>
> >>
> org.jboss.weld.injection.ResourceInjectionFactory$ResourceInjectionProcessor.createFieldResourceInjection(ResourceInjectionFactory.java:217)
> >>
> >> at
> >>
> >>
> org.jboss.weld.injection.ResourceInjectionFactory$ResourceInjectionProcessor.createResourceInjections(ResourceInjectionFactory.java:189)
> >>
> >> at
> >>
> >>
> org.jboss.weld.injection.ResourceInjectionFactory.discoverType(ResourceInjectionFactory.java:449)
> >>
> >> at
> >>
> >>
> org.jboss.weld.injection.ResourceInjectionFactory.getResourceInjections(ResourceInjectionFactory.java:97)
> >>
> >> at
> >>
> >>
> org.jboss.weld.injection.producer.ResourceInjector.<init>(ResourceInjector.java:59)
> >>
> >> at
> >>
> >>
> org.jboss.weld.injection.producer.ResourceInjector.of(ResourceInjector.java:49)
> >>
> >> at
> >>
> >>
> org.jboss.weld.injection.producer.BeanInjectionTarget.<init>(BeanInjectionTarget.java:63)
> >>
> >> at
> >>
> >>
> org.jboss.weld.injection.producer.BeanInjectionTarget.createDefault(BeanInjectionTarget.java:47)
> >>
> >> at
> >>
> >>
> org.jboss.weld.manager.InjectionTargetFactoryImpl.chooseInjectionTarget(InjectionTargetFactoryImpl.java:128)
> >>
> >> at
> >>
> >>
> org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:87)
> >>
> >> at org.jboss.weld.bean.ManagedBean.<init>(ManagedBean.java:100)
> >>
> >> at org.jboss.weld.bean.ManagedBean.of(ManagedBean.java:80)
> >>
> >> at
> >>
> >>
> org.jboss.weld.bootstrap.AbstractBeanDeployer.createManagedBean(AbstractBeanDeployer.java:261)
> >>
> >> at
> >>
> >>
> org.jboss.weld.bootstrap.BeanDeployer.createClassBean(BeanDeployer.java:228)
> >>
> >> at
> >>
> >>
> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:78)
> >>
> >> at
> >>
> >>
> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:75)
> >>
> >> 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)
> >>
> >>
> >> Useful, right?
> >>
> >>
> >> Anyways, after running through the debuggah, I found that the
> >> UserTransaction instance referenced in UserTransactionResolver was null
> >> and
> >> was causing Weld to stop working. Looking at CI, it appears that we're
> >> passing against 2.3.0, however the appropriate tests (e.g.
> >>
> >>
> https://github.com/apache/deltaspike/blob/master/deltaspike/modules/data/impl/src/test/java/org/apache/deltaspike/data/impl/mapping/MappedRepositoryTest.java
> >> )
> >> are marked webprofile so I'm not sure they'd be run against a standalone
> >> container this way.
> >>
> >>
> >> Has anyone seen something like this? Just wondering before I ping the
> >> weld
> >> guys.
> >>
> >>
> >> John
> >>
> >
> >
>
Re: Regression - DeltaSpike 1.4.2 & Weld 2.3.1?
Posted by Gerhard Petracek <ge...@gmail.com>.
short addition:
please upgrade to the latest snapshot (the next release is due quite soon).
regards,
gerhard
2015-11-15 21:22 GMT+01:00 Gerhard Petracek <ge...@gmail.com>:
> hi john,
>
> we just moved the resource-injection-point one "level" back to support
> atomikos (see ManagedUserTransactionResolver).
> the first jndi lookup afterwards (which is used as a fallback), is already
> what we had before.
>
> regards,
> gerhard
>
>
>
> 2015-11-15 18:29 GMT+01:00 John D. Ament <jo...@apache.org>:
>
>> All,
>>
>> I just tried upgrading my app locally to Weld 2.3.1 (in prep for a wildfly
>> 10 upgrade). After upgrading Weld to 2.3.1, some of my repository tests
>> started failing with the following output.
>>
>> java.lang.NullPointerException
>>
>> at org.jboss.weld.util.Preconditions.checkNotNull(Preconditions.java:51)
>>
>> at
>>
>> org.jboss.weld.injection.AbstractResourceInjection.<init>(AbstractResourceInjection.java:39)
>>
>> at
>>
>> org.jboss.weld.injection.FieldResourceInjection.<init>(FieldResourceInjection.java:48)
>>
>> at
>>
>> org.jboss.weld.injection.ResourceInjectionFactory$ResourceInjectionProcessor.createFieldResourceInjection(ResourceInjectionFactory.java:217)
>>
>> at
>>
>> org.jboss.weld.injection.ResourceInjectionFactory$ResourceInjectionProcessor.createResourceInjections(ResourceInjectionFactory.java:189)
>>
>> at
>>
>> org.jboss.weld.injection.ResourceInjectionFactory.discoverType(ResourceInjectionFactory.java:449)
>>
>> at
>>
>> org.jboss.weld.injection.ResourceInjectionFactory.getResourceInjections(ResourceInjectionFactory.java:97)
>>
>> at
>>
>> org.jboss.weld.injection.producer.ResourceInjector.<init>(ResourceInjector.java:59)
>>
>> at
>>
>> org.jboss.weld.injection.producer.ResourceInjector.of(ResourceInjector.java:49)
>>
>> at
>>
>> org.jboss.weld.injection.producer.BeanInjectionTarget.<init>(BeanInjectionTarget.java:63)
>>
>> at
>>
>> org.jboss.weld.injection.producer.BeanInjectionTarget.createDefault(BeanInjectionTarget.java:47)
>>
>> at
>>
>> org.jboss.weld.manager.InjectionTargetFactoryImpl.chooseInjectionTarget(InjectionTargetFactoryImpl.java:128)
>>
>> at
>>
>> org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:87)
>>
>> at org.jboss.weld.bean.ManagedBean.<init>(ManagedBean.java:100)
>>
>> at org.jboss.weld.bean.ManagedBean.of(ManagedBean.java:80)
>>
>> at
>>
>> org.jboss.weld.bootstrap.AbstractBeanDeployer.createManagedBean(AbstractBeanDeployer.java:261)
>>
>> at
>>
>> org.jboss.weld.bootstrap.BeanDeployer.createClassBean(BeanDeployer.java:228)
>>
>> at
>>
>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:78)
>>
>> at
>>
>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:75)
>>
>> 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)
>>
>>
>> Useful, right?
>>
>>
>> Anyways, after running through the debuggah, I found that the
>> UserTransaction instance referenced in UserTransactionResolver was null
>> and
>> was causing Weld to stop working. Looking at CI, it appears that we're
>> passing against 2.3.0, however the appropriate tests (e.g.
>>
>> https://github.com/apache/deltaspike/blob/master/deltaspike/modules/data/impl/src/test/java/org/apache/deltaspike/data/impl/mapping/MappedRepositoryTest.java
>> )
>> are marked webprofile so I'm not sure they'd be run against a standalone
>> container this way.
>>
>>
>> Has anyone seen something like this? Just wondering before I ping the
>> weld
>> guys.
>>
>>
>> John
>>
>
>
Re: Regression - DeltaSpike 1.4.2 & Weld 2.3.1?
Posted by Gerhard Petracek <ge...@gmail.com>.
hi john,
we just moved the resource-injection-point one "level" back to support
atomikos (see ManagedUserTransactionResolver).
the first jndi lookup afterwards (which is used as a fallback), is already
what we had before.
regards,
gerhard
2015-11-15 18:29 GMT+01:00 John D. Ament <jo...@apache.org>:
> All,
>
> I just tried upgrading my app locally to Weld 2.3.1 (in prep for a wildfly
> 10 upgrade). After upgrading Weld to 2.3.1, some of my repository tests
> started failing with the following output.
>
> java.lang.NullPointerException
>
> at org.jboss.weld.util.Preconditions.checkNotNull(Preconditions.java:51)
>
> at
>
> org.jboss.weld.injection.AbstractResourceInjection.<init>(AbstractResourceInjection.java:39)
>
> at
>
> org.jboss.weld.injection.FieldResourceInjection.<init>(FieldResourceInjection.java:48)
>
> at
>
> org.jboss.weld.injection.ResourceInjectionFactory$ResourceInjectionProcessor.createFieldResourceInjection(ResourceInjectionFactory.java:217)
>
> at
>
> org.jboss.weld.injection.ResourceInjectionFactory$ResourceInjectionProcessor.createResourceInjections(ResourceInjectionFactory.java:189)
>
> at
>
> org.jboss.weld.injection.ResourceInjectionFactory.discoverType(ResourceInjectionFactory.java:449)
>
> at
>
> org.jboss.weld.injection.ResourceInjectionFactory.getResourceInjections(ResourceInjectionFactory.java:97)
>
> at
>
> org.jboss.weld.injection.producer.ResourceInjector.<init>(ResourceInjector.java:59)
>
> at
>
> org.jboss.weld.injection.producer.ResourceInjector.of(ResourceInjector.java:49)
>
> at
>
> org.jboss.weld.injection.producer.BeanInjectionTarget.<init>(BeanInjectionTarget.java:63)
>
> at
>
> org.jboss.weld.injection.producer.BeanInjectionTarget.createDefault(BeanInjectionTarget.java:47)
>
> at
>
> org.jboss.weld.manager.InjectionTargetFactoryImpl.chooseInjectionTarget(InjectionTargetFactoryImpl.java:128)
>
> at
>
> org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:87)
>
> at org.jboss.weld.bean.ManagedBean.<init>(ManagedBean.java:100)
>
> at org.jboss.weld.bean.ManagedBean.of(ManagedBean.java:80)
>
> at
>
> org.jboss.weld.bootstrap.AbstractBeanDeployer.createManagedBean(AbstractBeanDeployer.java:261)
>
> at
>
> org.jboss.weld.bootstrap.BeanDeployer.createClassBean(BeanDeployer.java:228)
>
> at
>
> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:78)
>
> at
>
> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:75)
>
> 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)
>
>
> Useful, right?
>
>
> Anyways, after running through the debuggah, I found that the
> UserTransaction instance referenced in UserTransactionResolver was null and
> was causing Weld to stop working. Looking at CI, it appears that we're
> passing against 2.3.0, however the appropriate tests (e.g.
>
> https://github.com/apache/deltaspike/blob/master/deltaspike/modules/data/impl/src/test/java/org/apache/deltaspike/data/impl/mapping/MappedRepositoryTest.java
> )
> are marked webprofile so I'm not sure they'd be run against a standalone
> container this way.
>
>
> Has anyone seen something like this? Just wondering before I ping the weld
> guys.
>
>
> John
>