Regression - DeltaSpike 1.4.2 & Weld 2.3.1?

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Regression - DeltaSpike 1.4.2 & Weld 2.3.1?

John D. Ament
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
Reply | Threaded
Open this post in threaded view
|

Re: Regression - DeltaSpike 1.4.2 & Weld 2.3.1?

Gerhard Petracek
Administrator
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 <[hidden email]>:

> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Regression - DeltaSpike 1.4.2 & Weld 2.3.1?

Gerhard Petracek
Administrator
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 <[hidden email]>:

> 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 <[hidden email]>:
>
>> 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
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Regression - DeltaSpike 1.4.2 & Weld 2.3.1?

John D. Ament
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 <[hidden email]>
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 <[hidden email]>:
>
> > 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 <[hidden email]>:
> >
> >> 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
> >>
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Regression - DeltaSpike 1.4.2 & Weld 2.3.1?

Gerhard Petracek
Administrator
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 <[hidden email]>:

> 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 <
> [hidden email]>
> 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 <[hidden email]
> >:
> >
> > > 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 <[hidden email]>:
> > >
> > >> 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
> > >>
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Regression - DeltaSpike 1.4.2 & Weld 2.3.1?

Martin Kouba
In reply to this post by John D. Ament
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 <[hidden email]>
> 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 <[hidden email]>:
>>
>>> 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 <[hidden email]>:
>>>
>>>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Regression - DeltaSpike 1.4.2 & Weld 2.3.1?

Mark Struberg
Administrator
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 <[hidden email]>:
>
> 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 <[hidden email]>
>> 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 <[hidden email]>:
>>>
>>>> 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 <[hidden email]>:
>>>>
>>>>> 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

Reply | Threaded
Open this post in threaded view
|

Re: Regression - DeltaSpike 1.4.2 & Weld 2.3.1?

Martin Kouba
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 <[hidden email]>:
>>
>> 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 <[hidden email]>
>>> 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 <[hidden email]>:
>>>>
>>>>> 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 <[hidden email]>:
>>>>>
>>>>>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Regression - DeltaSpike 1.4.2 & Weld 2.3.1?

Martin Kouba
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 <[hidden email]>:
>>>
>>> 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
>>>> <[hidden email]>
>>>> 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
>>>>> <[hidden email]>:
>>>>>
>>>>>> 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 <[hidden email]>:
>>>>>>
>>>>>>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Regression - DeltaSpike 1.4.2 & Weld 2.3.1?

Mark Struberg
Administrator
In reply to this post by Martin Kouba
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 <[hidden email]>:
>
> 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 <[hidden email]>:
>>>
>>> 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 <[hidden email]>
>>>> 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 <[hidden email]>:
>>>>>
>>>>>> 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 <[hidden email]>:
>>>>>>
>>>>>>> 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