March 2016 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-527: ------------------------------------------ List of proposed names so far: * AllowProxying * Passthrough * SupressUnproxyAbleResolution * ForceProxy * SuppressUnproxyableResolutionException * AllowFinalMethodProxying * SkipFinalMethodProxying * IgnoreFinalMethodProxying * SkipUnproxyableMethod * IgnoreUnproxyableMethod * PassOverUnproxyable * ByPassUnproxyable > allow proxying of classes with non-private final methods > -------------------------------------------------------- > > Key: CDI-527 > URL: https://issues.jboss.org/browse/CDI-527 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Assignee: Mark Struberg > Fix For: 2.0 (proposed) > > > Currently we explicitly disallow proxying of classes with non-private final methods. > EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it. > We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-420: ------------------------------------------ Last discussion on the topic, lead us to reconsider how {{annotated}} mode works. I'm going to study the spec to check if it says something about type scanning for {{annotated}} mode. If it's not the case we could specify that this mode had to scan all types. > add a bean-discovery-mode 'scoped' > ---------------------------------- > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: TBD > Reporter: Mark Struberg > Fix For: 2.0 (discussion) > > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > • each Java class, interface or enum deployed in an explicit bean archive, and > • each Java class with a bean defining annotation in an implicit bean archive. > • each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

Standrdization of option to disable CDI for all app modules in single file?

by Ondrej Mihályi

Hi, Some Java EE 6 apps still have issues with implicit scanning, even though they don't use guava and sometimes it is not possible to put beans.xml file into the problematic JARs. People are having issues with this when migrating to Glassfish 4 or Payara from Glassfish 3. With Payara server, we are thinking of creating an option in server-specific app descriptor to disable CDI completely either for whole application or just for specific modules. <https://javaee-wg.slack.com/archives/cdi2_0-jsr-365/p1458060907000004> I think it would make sense to consider some standardization of this approach in CDI 2, as I've seen issues with this on stackoverflow also with other app servers. Or is it already planned? Ondrej

8 years, 1 month

4
6
0 / 0

How to initiate a MR of JSR250 for @Priority

by Mark Paluch

Hi there, I noticed that we miss an update of JSR 250 for @Priority. Currently, @Priority allows only TYPE as target but we need PARAMETER for ordered events. How is the procedure to get an update and who can help? Best regards, Mark

8 years, 1 month

2
1
0 / 0

[JBoss JIRA] (CDI-494) Clarify that a type variable that resolves to a wildcard is not resolvable

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-494?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-494: ------------------------------------- Comment: was deleted (was: Well guys, if it's technically possible to accept unbounded and bounded wildcards for events let's do it. It's probably a mistake to compare this restriction in event rules with restriction in type resolution for DI. This said, when I read JLS [1] and this sentence : {quote}Type arguments may be either reference types or wildcards. Wildcards are useful in situations where only partial knowledge about the type parameter is required.{quote} My understanding is that {{List<? extends Number>}} is similar to {{List<T extends Number>}}. The only difference is that in the first version we won't need type information later. OTHO {{List<?>}} (or {{List<? extends Object>}}) clearly defines a List containing any type... [1] https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.5.1) > Clarify that a type variable that resolves to a wildcard is not resolvable > -------------------------------------------------------------------------- > > Key: CDI-494 > URL: https://issues.jboss.org/browse/CDI-494 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (discussion) > > > This is implicit but I've seen people confused about this several times. See e.g. https://issues.jboss.org/browse/WELD-1799 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-494) Clarify that a type variable that resolves to a wildcard is not resolvable

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-494?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand edited comment on CDI-494 at 3/14/16 9:22 AM: ------------------------------------------------------------------- Well guys, if it's technically possible to accept unbounded and bounded wildcards for events let's do it. It's probably a mistake to compare this restriction in event rules with restriction in type resolution for DI. This said, when I read JLS [1] and this sentence : {quote}Type arguments may be either reference types or wildcards. Wildcards are useful in situations where only partial knowledge about the type parameter is required.{quote} My understanding is that {{List<? extends Number>}} is similar to {{List<T extends Number>}}. The only difference is that in the first version we won't need type information later. OTHO {{List<?>}} (or {{List<? extends Object>}}) clearly defines a List containing any type... [1] https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.5.1 was (Author: antoinesabot-durand): Well guys, if it's technically possible to accept unbounded and bounded wildcards for events let's do it. It's probably a mistake to compare this restriction in event rules with restriction in type resolution for DI. This said, when I read JLS [1] and this sentence : {quote}Type arguments may be either reference types or wildcards. Wildcards are useful in situations where only partial knowledge about the type parameter is required.{quote} My understanding is that {{List<? extends Number>}} is similar to {{List<T extends Number>}}. The only difference is that in the first version we won't need type information later. OTHO List<?> (or List<? extends Object>) clearly defines a List containing any type... [1] https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.5.1 > Clarify that a type variable that resolves to a wildcard is not resolvable > -------------------------------------------------------------------------- > > Key: CDI-494 > URL: https://issues.jboss.org/browse/CDI-494 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (discussion) > > > This is implicit but I've seen people confused about this several times. See e.g. https://issues.jboss.org/browse/WELD-1799 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-494) Clarify that a type variable that resolves to a wildcard is not resolvable

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-494?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand edited comment on CDI-494 at 3/14/16 9:21 AM: ------------------------------------------------------------------- Well guys, if it's technically possible to accept unbounded and bounded wildcards for events let's do it. It's probably a mistake to compare this restriction in event rules with restriction in type resolution for DI. This said, when I read JLS [1] and this sentence : {quote}Type arguments may be either reference types or wildcards. Wildcards are useful in situations where only partial knowledge about the type parameter is required.{quote} My understanding is that {{List<? extends Number>}} is similar to {{List<T extends Number>}}. The only difference is that in the first version we won't need type information later. OTHO List<?> (or List<? extends Object>) clearly defines a List containing any type... [1] https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.5.1 was (Author: antoinesabot-durand): Well guys, if it's technically possible to accept unbounded and bounded wildcards for events let's do it. It's probably a mistake to compare this restriction in event rules with restriction in type resolution for DI. This said, when I read JLS [1] and this sentence : {quote}Type arguments may be either reference types or wildcards. Wildcards are useful in situations where only partial knowledge about the type parameter is required.{quote} My understanding is that {{List<? extends Number> }} is similar to {{List<T extends Number>}}. The only difference is that in the first version we won't need type information later. OTHO List<?> (or List<? extends Object>) clearly defines a List containing any type... [1] https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.5.1 > Clarify that a type variable that resolves to a wildcard is not resolvable > -------------------------------------------------------------------------- > > Key: CDI-494 > URL: https://issues.jboss.org/browse/CDI-494 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (discussion) > > > This is implicit but I've seen people confused about this several times. See e.g. https://issues.jboss.org/browse/WELD-1799 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-494) Clarify that a type variable that resolves to a wildcard is not resolvable

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-494?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand edited comment on CDI-494 at 3/14/16 9:21 AM: ------------------------------------------------------------------- Well guys, if it's technically possible to accept unbounded and bounded wildcards for events let's do it. It's probably a mistake to compare this restriction in event rules with restriction in type resolution for DI. This said, when I read JLS [1] and this sentence : {quote}Type arguments may be either reference types or wildcards. Wildcards are useful in situations where only partial knowledge about the type parameter is required.{quote} My understanding is that {{List<? extends Number> }} is similar to {{List<T extends Number>}}. The only difference is that in the first version we won't need type information later. OTHO List<?> (or List<? extends Object>) clearly defines a List containing any type... [1] https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.5.1 was (Author: antoinesabot-durand): Well guys, if it's technically possible to accept unbounded and bounded wildcards for events let's do it. It's probably a mistake to compare this restriction in event rules with restriction in type resolution for DI. This said, when I read JLS [1] and this sentence : {quote}Type arguments may be either reference types or wildcards. Wildcards are useful in situations where only partial knowledge about the type parameter is required.{quote} My understanding is that {{List<? extends Number> }}is similar to {{List<T extends Number>}}. The only difference is that in the first version we won't need type information later. OTHO List<?> (or List<? extends Object>) clearly defines a List containing any type... [1] https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.5.1 > Clarify that a type variable that resolves to a wildcard is not resolvable > -------------------------------------------------------------------------- > > Key: CDI-494 > URL: https://issues.jboss.org/browse/CDI-494 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (discussion) > > > This is implicit but I've seen people confused about this several times. See e.g. https://issues.jboss.org/browse/WELD-1799 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-494) Clarify that a type variable that resolves to a wildcard is not resolvable

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-494?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-494: ------------------------------------------ Well guys, if it's technically possible to accept unbounded and bounded wildcards for events let's do it. It's probably a mistake to compare this restriction in event rules with restriction in type resolution for DI. This said, when I read JLS [1] and this sentence : {quote}Type arguments may be either reference types or wildcards. Wildcards are useful in situations where only partial knowledge about the type parameter is required.{quote} My understanding is that {{List<? extends Number> }}is similar to {{List<T extends Number>}}. The only difference is that in the first version we won't need type information later. OTHO List<?> (or List<? extends Object>) clearly defines a List containing any type... [1] https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.5.1 > Clarify that a type variable that resolves to a wildcard is not resolvable > -------------------------------------------------------------------------- > > Key: CDI-494 > URL: https://issues.jboss.org/browse/CDI-494 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (discussion) > > > This is implicit but I've seen people confused about this several times. See e.g. https://issues.jboss.org/browse/WELD-1799 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-494) Clarify that a type variable that resolves to a wildcard is not resolvable

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-494?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-494: ----------------------------------- That whole area is a big pile of work. I need to dig into it each time I have to work on it ;) It's also important to always keep in the back of the head that generic coercion for standard injection and for Decorators/Producers work a bit different, especially when it comes to wildcards! > Clarify that a type variable that resolves to a wildcard is not resolvable > -------------------------------------------------------------------------- > > Key: CDI-494 > URL: https://issues.jboss.org/browse/CDI-494 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (discussion) > > > This is implicit but I've seen people confused about this several times. See e.g. https://issues.jboss.org/browse/WELD-1799 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev March 2016