[jira] [Commented] (TOMEE-1586) CDI Producer Injection Point Divergence against WELD

["Romain Manni-Bucau (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TOMEE-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14546835#comment-14546835 ] 

Romain Manni-Bucau commented on TOMEE-1586:
-------------------------------------------

Hi

few notes:
1) please dont use google drive but github/code google/bitbucket or any platform allowing to browse sources online
2) opencdi = openwebbeans actually

Now linked to the issue: ready your description and if I got it right I think it is more a weld bug, their bugtracker is https://issues.jboss.org/browse/WELD/ (side note: this is not our role to forward them bugs)

> CDI Producer Injection Point Divergence against WELD
> ----------------------------------------------------
>
>                 Key: TOMEE-1586
>                 URL: https://issues.apache.org/jira/browse/TOMEE-1586
>             Project: TomEE
>          Issue Type: Bug
>    Affects Versions: 1.7.1
>         Environment: Windows 7, Tomee 1.7.1
>            Reporter: Nuno G. de M
>            Priority: Minor
>             Fix For: 1.7.2
>
>
> In a relative obscure/non-trivial Injection/production scenarion of CDI beans, there is a difference between the Injection Point passed to a producer under WELD bundled with Glassfish 3.1.2.X and Weblogic 12.1.2 vs TomEE open-cdi.
> Please see the zip file provided in the google drive link bellow.
> https://drive.google.com/file/d/0B_dEiNBGUsxqUkVXdWl3bmVXXzQ/view?usp=sharing
> The zip file cotains a .docx and builds on top of the sample project provided from TOMEE-1580 issue.
> Careful with the persistence.xml file of the project since its current commit state it will deploy glassfish 3.1.2 but not to TOmee 1_7_1 due to JNDI Name and Jar-file locaiton elements.
> In any case, the issue is describe in the docx.
> It is not clear if the bug is the implementation of WELD or of OpenCdi.
> In fact the behavior of OpenCDI seems to be more logical - from my point of view - but since the WELD is the reference implementation, you are being assigned this bug.
> TO summarize the issue:
> You will have a @RequestScoped bean being injected a @qualified "Holder bean".
> For this HolderBean there will be a producer.
> And the @Qualifier for the injection willl have an attribute value - e.g. @Qualifier(value="rockBalboa")
> (2) This producer that will provide the HolderInstance will use the BeanManager to create an instance of the "Holder" object tha tis specific fo the qualifier value (rockyBalboa)
> (3) When the BeanManager is creating the Holder object it will try to resolve the @Injection points of the holder.
> Namely there will be an 
> @Iject
> @Qaulifier 
> Instance<SomeInterface>
> Within this holder object.
> (4) The big diffence between WELD and OpenCDI now seems the be the following.
> Each of the Instances that will be iterated over this Instace attribute are created through a second producer.
> And on this second producer the InjectionPoint object is different in WELD and OpenCdi.
> In Weld the injection point has the same charateristics of the Ibjection point passed to the Producer of the Holder object.
> On OpenCDI the injection point has the characterists of the Holder object iself.
> When your code is based on WELD, this has the negative effect that if your code depended on the InjectionPoint in this very specific circunstance to carry the "rockyBalboa" value that existed in the @RequestScoped bean that initially asked for a Holder instance .... well only on Weblogic and Glassfish will this happen.
> On Tomee the producer for the Holder will get it, but not the producer for the nested beans.
> I would request that if this issue belongs to WELD that you forward the bug to them.
> I give low priority to this Bug - since there are programtic ways to make the code work under both implementations. The holder object has knowledge of the original injection point annotation and can therefore force its knowledge of "rockyBalboa" into the underlying beans ....
> But still, code has to be reworked to funciton under both implementations.
> Kindest regards,
> Nuno.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)