[
https://issues.apache.org/jira/browse/TOMEE-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14547129#comment-14547129
]
Nuno G. de M commented on TOMEE-1586:
-------------------------------------
Hi there.
Sorry for that, our mirror has more dependencies than currently exist in the
central...
In any case, on this particular bug-report you do not actually need CORBA nort
gf-client test dependency, whcih carries a lot of baggage. You can disable
dependency on the pom.xml of the war file.
Or you can add this repository>
<repositories>
+ <repository>
+ <id>EclipseLink Repository</id>
+ <url>http://download.eclipse.org/rt/eclipselink/maven.repo/</url>
+ </repository>
+ </repositories>
And for the Old prime faces library, it does not really matter, updating the
version to 5.2 is ok.
I've checked in these changes.
NOTE:
Release 1.7.3 does not fix the issue on the <jar-file> path.
One note, my personal computer is an Ubuntu 14 LTS. (I should open a different
bug here )
Under ubuntu, the Netbeans plugin for TOMEEE release 1.7.3 build 19 does not
seem to be the most reliable thing.
On my machine, at least, when I startup the container, the plugin does not
realiye that the container has started and continues waiting for it to startup.
Then I only have the option to run "terminate" on the container, I cannot not
do the usual stop.
Another thing that I-ve noticed on the NetBeans plugin,is that when you deploy
using this plugin, it creates a context.xml in the conf/ folder to TOMEE base
and the container will forever be trying to deploy the application. If the
application breaks during deployment, you enter an infinite loop of the
container wanting or the plugin trying to get the application deployed.
You have to stop the stop the container at this point and delete the
context.xml from the catalina folder on conf/ to make the server usable again.
I presently deploy by copy pasting the war file to the webapps folder, it is a
safer approach.
Regards.
> 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)
