[jira] [Commented] (OWB-1208) Unable to use Unmanaged with mixed CDI 2.0/1.1 bean archives

[Romain Manni-Bucau (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-1208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116067#comment-16116067
 ] 

Romain Manni-Bucau commented on OWB-1208:
-

Hi John, is it the case with not web components? Don't think unmanaged should 
work for servlets since cdi doesnt handle them at all in the spec and let the 
servlet container doing it.

> Unable to use Unmanaged with mixed CDI 2.0/1.1 bean archives
> 
>
> Key: OWB-1208
> URL: https://issues.apache.org/jira/browse/OWB-1208
> Project: OpenWebBeans
>  Issue Type: Bug
>Reporter: John D. Ament
>
> Take for instance the Apache CXF CDI Extension.  There's a `CXFCdiServlet` 
> class which has no bean defining annotations, but has a valid CDI 1.1 
> [beans.xml|https://github.com/apache/cxf/blob/master/integration/cdi/src/main/resources/META-INF/beans.xml].
>   If I start OWB from a main that has CDI 2.0's trimmed bean archive, this 
> servlet is not available as a CDI bean, and hence cannot be used within 
> Unmanaged.
> I'm not sure if the solution is that it should be a CDI bean, or if Unmanaged 
> should be able to look at non-beans.  This issue does not replicate on Weld 3.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (OWB-1208) Unable to use Unmanaged with mixed CDI 2.0/1.1 bean archives

[John D. Ament (JIRA)]

John D. Ament created OWB-1208:
--

 Summary: Unable to use Unmanaged with mixed CDI 2.0/1.1 bean 
archives
 Key: OWB-1208
 URL: https://issues.apache.org/jira/browse/OWB-1208
 Project: OpenWebBeans
  Issue Type: Bug
Reporter: John D. Ament


Take for instance the Apache CXF CDI Extension.  There's a `CXFCdiServlet` 
class which has no bean defining annotations, but has a valid CDI 1.1 
[beans.xml|https://github.com/apache/cxf/blob/master/integration/cdi/src/main/resources/META-INF/beans.xml].
  If I start OWB from a main that has CDI 2.0's trimmed bean archive, this 
servlet is not available as a CDI bean, and hence cannot be used within 
Unmanaged.

I'm not sure if the solution is that it should be a CDI bean, or if Unmanaged 
should be able to look at non-beans.  This issue does not replicate on Weld 3.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (OWB-1207) Inconsistent behavior of the instance behind CDI.current()

[John D. Ament (JIRA)]

John D. Ament created OWB-1207:
--

 Summary: Inconsistent behavior of the instance behind CDI.current()
 Key: OWB-1207
 URL: https://issues.apache.org/jira/browse/OWB-1207
 Project: OpenWebBeans
  Issue Type: Bug
Reporter: John D. Ament


The behavior of CDI.current() is a bit odd, and seems to have a bug in it.

Suppose I have the following:

{code}
Instance x = CDI.current().select(SomeClass, someQualifiers);
Instance y = CDI.current().select(SomeClass).select(someQualifiers)
{code}

Those two instances should be pointing to same set of beans, have the same set 
of qualifiers, but they do not.  x will in fact have an extra Default qualifier 
that y does not have.  The default qualifier is not expected here.  This 
happens because the return value of `instance()` in `OwbCDI` selects a default 
qualifier, and the method taking var args for type and annotations does a 
merge, whereas the second method of selecting just qualifiers does a 
replacement.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Why does CDI.current() include a Default Qualifier?

[John D. Ament]

Ok, yes that sounds vaguely familiar.  Basically, if no qualifiers are
chosen then default should be used, but as soon as you add a qualifier
Default should be removed.

On Sun, Aug 6, 2017 at 10:03 AM Romain Manni-Bucau 
wrote:

> Dont recall the whole details and 90% sure spec is not that closed on that
> point but if you dont have an implicit default, direct type lookup doesnt
> work but if another qualifier is set the *implicit* one (not default, only
> default when implicit) should be stripped IMHO.
>
> Le 6 août 2017 14:46, "John D. Ament"  a écrit :
>
> > Another issue, which may be related.
> >
> > When I use the following to look up a bean, the bean doesn't have a
> default
> > qualifier but BeanManager.getReference is attempting to add one
> >
> > beanManager.getReference(bean, bean.getBeanClass(),
> > beanManager.createCreationalContext(bean))
> >
> > This was just a regular bean, not a third party bean.
> >
> > On Sun, Aug 6, 2017 at 8:07 AM John D. Ament 
> > wrote:
> >
> > > Hey guys
> > >
> > > Before I create a ticket, I wanted to understand from your POV.  I'm
> not
> > > sure if it's a spec issue.
> > >
> > > I noticed in OWB when I do CDI.current().select(SomeClass,
> > someQualifiers)
> > > the resulting instance includes a Default qualifier.  However, when I
> do
> > > CDI.current().select(SomeClass).select(someQualifiers) it does not.
> > >
> > > I noticed that adding the Default qualifier was done in this commit
> [1].
> > > However, I don't believe this is correct.  I looked through the spec, I
> > > can't find any reference that the instance should have a default
> > qualifier
> > > on it.
> > >
> > > This causes an issue with 3rd party beans.  If I try to do something
> like
> > > programmatically lookup a bean where the qualifiers don't include a
> > default
> > > qualifier, then the lookup fails.
> > >
> > > John
> > >
> >
>

Re: Why does CDI.current() include a Default Qualifier?

[Romain Manni-Bucau]

Dont recall the whole details and 90% sure spec is not that closed on that
point but if you dont have an implicit default, direct type lookup doesnt
work but if another qualifier is set the *implicit* one (not default, only
default when implicit) should be stripped IMHO.

Le 6 août 2017 14:46, "John D. Ament"  a écrit :

> Another issue, which may be related.
>
> When I use the following to look up a bean, the bean doesn't have a default
> qualifier but BeanManager.getReference is attempting to add one
>
> beanManager.getReference(bean, bean.getBeanClass(),
> beanManager.createCreationalContext(bean))
>
> This was just a regular bean, not a third party bean.
>
> On Sun, Aug 6, 2017 at 8:07 AM John D. Ament 
> wrote:
>
> > Hey guys
> >
> > Before I create a ticket, I wanted to understand from your POV.  I'm not
> > sure if it's a spec issue.
> >
> > I noticed in OWB when I do CDI.current().select(SomeClass,
> someQualifiers)
> > the resulting instance includes a Default qualifier.  However, when I do
> > CDI.current().select(SomeClass).select(someQualifiers) it does not.
> >
> > I noticed that adding the Default qualifier was done in this commit [1].
> > However, I don't believe this is correct.  I looked through the spec, I
> > can't find any reference that the instance should have a default
> qualifier
> > on it.
> >
> > This causes an issue with 3rd party beans.  If I try to do something like
> > programmatically lookup a bean where the qualifiers don't include a
> default
> > qualifier, then the lookup fails.
> >
> > John
> >
>

Re: Why does CDI.current() include a Default Qualifier?

[John D. Ament]

Another issue, which may be related.

When I use the following to look up a bean, the bean doesn't have a default
qualifier but BeanManager.getReference is attempting to add one

beanManager.getReference(bean, bean.getBeanClass(),
beanManager.createCreationalContext(bean))

This was just a regular bean, not a third party bean.

On Sun, Aug 6, 2017 at 8:07 AM John D. Ament  wrote:

> Hey guys
>
> Before I create a ticket, I wanted to understand from your POV.  I'm not
> sure if it's a spec issue.
>
> I noticed in OWB when I do CDI.current().select(SomeClass, someQualifiers)
> the resulting instance includes a Default qualifier.  However, when I do
> CDI.current().select(SomeClass).select(someQualifiers) it does not.
>
> I noticed that adding the Default qualifier was done in this commit [1].
> However, I don't believe this is correct.  I looked through the spec, I
> can't find any reference that the instance should have a default qualifier
> on it.
>
> This causes an issue with 3rd party beans.  If I try to do something like
> programmatically lookup a bean where the qualifiers don't include a default
> qualifier, then the lookup fails.
>
> John
>

[jira] [Resolved] (MEECROWAVE-55) Upgrade to Johnzon 1.1.2

[Romain Manni-Bucau (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MEECROWAVE-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Romain Manni-Bucau resolved MEECROWAVE-55.
--
Resolution: Fixed

> Upgrade to Johnzon 1.1.2
> 
>
> Key: MEECROWAVE-55
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-55
> Project: Meecrowave
>  Issue Type: Task
>Reporter: Romain Manni-Bucau
>Assignee: Romain Manni-Bucau
> Fix For: 2.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MEECROWAVE-55) Upgrade to Johnzon 1.1.2

[Romain Manni-Bucau (JIRA)]

Romain Manni-Bucau created MEECROWAVE-55:


 Summary: Upgrade to Johnzon 1.1.2
 Key: MEECROWAVE-55
 URL: https://issues.apache.org/jira/browse/MEECROWAVE-55
 Project: Meecrowave
  Issue Type: Task
Reporter: Romain Manni-Bucau
Assignee: Romain Manni-Bucau
 Fix For: 2.0.0






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)