9:56 a.m.
Hi,
We just discovered an issue where using a lambda in an observer method
results in a synthesized method for that lambda that since u60 makes
the @Observes annotation visible. This will cause CDI (Weld
2.2.2.Final in this case as shipped with GlassFish 4.1) to see this
generated method as an actual observer method.
See the following mail on the OpenJDK list for details:
http://mail.openjdk.java.net/pipermail/lambda-dev/2015-August/012146.html...
The suggestion there is that it's simply a bug in the CDI implementation.
I wonder, should the CDI spec in general say that synthesized methods
should be ignored when scanning for observer (and possible other)
methods? I briefly scanned through the spec but didn't see any
references to synthesized methods.
Kind regards,
Arjan Tijms
11:13 a.m.
Hi Arjan,
I'm not sure that we should state that in the spec. The fact that the
compiler generates a synthetic method for the lambda is a java
implementation choice. Our implementation should only consider code written
by user not the one generated by the compiler. Wdyt Jozef ?
Antoine
Le mer. 26 août 2015 à 16:56, arjan tijms <arjan.tijms(a)gmail.com> a écrit :
Hi,
We just discovered an issue where using a lambda in an observer method
results in a synthesized method for that lambda that since u60 makes
the @Observes annotation visible. This will cause CDI (Weld
2.2.2.Final in this case as shipped with GlassFish 4.1) to see this
generated method as an actual observer method.
See the following mail on the OpenJDK list for details:
http://mail.openjdk.java.net/pipermail/lambda-dev/2015-August/012146.html...
The suggestion there is that it's simply a bug in the CDI implementation.
I wonder, should the CDI spec in general say that synthesized methods
should be ignored when scanning for observer (and possible other)
methods? I briefly scanned through the spec but didn't see any
references to synthesized methods.
Kind regards,
Arjan Tijms
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the
code under the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.
5:58 a.m.
I'd be concerned if we introduced text explicitly calling out code written
by the developer instead of generated by the compiler. What if I'm using
an annotation processor that generated implementations for CDI beans? Those
would get ignored.
Better to say something along the lines of synthesized methods are not
typically visible, therefore shouldn't be scanned.
John
On Wed, Aug 26, 2015 at 12:14 PM Antoine Sabot-Durand <
antoine(a)sabot-durand.net> wrote:
Hi Arjan,
I'm not sure that we should state that in the spec. The fact that the
compiler generates a synthetic method for the lambda is a java
implementation choice. Our implementation should only consider code written
by user not the one generated by the compiler. Wdyt Jozef ?
Antoine
Le mer. 26 août 2015 à 16:56, arjan tijms <arjan.tijms(a)gmail.com> a
écrit :
> Hi,
>
> We just discovered an issue where using a lambda in an observer method
> results in a synthesized method for that lambda that since u60 makes
> the @Observes annotation visible. This will cause CDI (Weld
> 2.2.2.Final in this case as shipped with GlassFish 4.1) to see this
> generated method as an actual observer method.
>
> See the following mail on the OpenJDK list for details:
>
>
>
http://mail.openjdk.java.net/pipermail/lambda-dev/2015-August/012146.html...
>
> The suggestion there is that it's simply a bug in the CDI implementation.
>
> I wonder, should the CDI spec in general say that synthesized methods
> should be ignored when scanning for observer (and possible other)
> methods? I briefly scanned through the spec but didn't see any
> references to synthesized methods.
>
> Kind regards,
> Arjan Tijms
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the
code under the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.
2:17 a.m.
Agreed, this looks like a bug in Weld.
On 26.08.2015 16:56, arjan tijms wrote:
Hi,
We just discovered an issue where using a lambda in an observer method
results in a synthesized method for that lambda that since u60 makes
the @Observes annotation visible. This will cause CDI (Weld
2.2.2.Final in this case as shipped with GlassFish 4.1) to see this
generated method as an actual observer method.
See the following mail on the OpenJDK list for details:
http://mail.openjdk.java.net/pipermail/lambda-dev/2015-August/012146.html...
The suggestion there is that it's simply a bug in the CDI implementation.
I wonder, should the CDI spec in general say that synthesized methods
should be ignored when scanning for observer (and possible other)
methods? I briefly scanned through the spec but didn't see any
references to synthesized methods.
Kind regards,
Arjan Tijms
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the code under the
Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
ideas provided on this list, the provider waives all patent and other intellectual
property rights inherent in such information.
7:18 a.m.
On Thu, Aug 27, 2015 at 9:17 AM, Jozef Hartinger <jharting(a)redhat.com> wrote:
Agreed, this looks like a bug in Weld.
I checked on OWB too (using TomEE 7.0-snapshot), this time using the
reproducer as given here: https://github.com/payara/Payara/issues/407
And on OWB there did not seem to be any problems.
To double check I added another observer method to the test class that
should fail deployment, namely:
public void foo(@Observes String someString, Integer thisshouldFail) {
List<String> strList = Arrays.asList("s1", "s2",
"s3");
final int a = 0;
final int b = 1;
strList.forEach((s) -> { System.out.printf("%s - %d - %d -
%s\n", someString, a, b, s); });
}
And that one indeed failed (as it should).
So it looks like this particular problem is localized to Weld.
7:22 a.m.
OWB handles synthetic methods already AFAIK, surely why we see this behavior
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau>
|
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>
2015-08-27 14:18 GMT+02:00 arjan tijms <arjan.tijms(a)gmail.com>:
On Thu, Aug 27, 2015 at 9:17 AM, Jozef Hartinger
<jharting(a)redhat.com>
wrote:
> Agreed, this looks like a bug in Weld.
I checked on OWB too (using TomEE 7.0-snapshot), this time using the
reproducer as given here: https://github.com/payara/Payara/issues/407
And on OWB there did not seem to be any problems.
To double check I added another observer method to the test class that
should fail deployment, namely:
public void foo(@Observes String someString, Integer thisshouldFail) {
List<String> strList = Arrays.asList("s1", "s2",
"s3");
final int a = 0;
final int b = 1;
strList.forEach((s) -> { System.out.printf("%s - %d - %d -
%s\n", someString, a, b, s); });
}
And that one indeed failed (as it should).
So it looks like this particular problem is localized to Weld.
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the
code under the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.
3787
days inactive
3788
days old
5 comments
5 participants
participants (5)
-
Antoine Sabot-Durand -
arjan tijms -
John D. Ament -
Jozef Hartinger -
Romain Manni-Bucau