December 2015 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-573) Review code of CDI class to switch to ServiceLoader

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-573?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand edited comment on CDI-573 at 12/15/15 11:47 AM: --------------------------------------------------------------------- PR sent. Code was simplified relying on JDK {{ServiceLoader}} class. We could simplify more since the only provider used is the first found (see {{configuredProvider}} initialization in {{getCDIProvider()}} method). Question is, as we didn't had tests for this code, how can we make sure that the behavior stays the same ? was (Author: antoinesabot-durand): PR sent. Code was simplified relying on JDK ServiceLoader class. We could simplify more since the only provider used is the first found (see {{configuredProvider}} initialization in {{getCDIProvider()}} method). Question is, as we didn't had tests for this code, how can we make sure that the behavior stays the same ? > Review code of CDI class to switch to ServiceLoader > --------------------------------------------------- > > Key: CDI-573 > URL: https://issues.jboss.org/browse/CDI-573 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts > Affects Versions: 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0 (proposed) > > > Right now {{CDI}} seems to mimics the JDK service loader mechanism in the the private {{findAllProviders}} method. > In order to get rid of useless code in the API and to limit compatibility issues with JDK9 and jigsaw, I think we should change this code and use Service Loader instead of doing something similar. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (CDI-573) Review code of CDI class to switch to ServiceLoader

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-573?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-573: ------------------------------------------ PR sent. Code was simplified relying on JDK ServiceLoader class. We could simplify more since the only provider used is the first found (see {{configuredProvider}} initialization in {{getCDIProvider()}} method). Question is, as we didn't had tests for this code, how can we make sure that the behavior stays the same ? > Review code of CDI class to switch to ServiceLoader > --------------------------------------------------- > > Key: CDI-573 > URL: https://issues.jboss.org/browse/CDI-573 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts > Affects Versions: 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0 (proposed) > > > Right now {{CDI}} seems to mimics the JDK service loader mechanism in the the private {{findAllProviders}} method. > In order to get rid of useless code in the API and to limit compatibility issues with JDK9 and jigsaw, I think we should change this code and use Service Loader instead of doing something similar. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (CDI-573) Review code of CDI class to switch to ServiceLoader

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-573?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-573: ------------------------------------- Fix Version/s: 2.0 (proposed) > Review code of CDI class to switch to ServiceLoader > --------------------------------------------------- > > Key: CDI-573 > URL: https://issues.jboss.org/browse/CDI-573 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts > Affects Versions: 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0 (proposed) > > > Right now {{CDI}} seems to mimics the JDK service loader mechanism in the the private {{findAllProviders}} method. > In order to get rid of useless code in the API and to limit compatibility issues with JDK9 and jigsaw, I think we should change this code and use Service Loader instead of doing something similar. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (CDI-573) Review code of CDI class to switch to ServiceLoader

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-573?page=com.atlassian.jira.plugin.sy... ] Work on CDI-573 started by Antoine Sabot-Durand. ------------------------------------------------ > Review code of CDI class to switch to ServiceLoader > --------------------------------------------------- > > Key: CDI-573 > URL: https://issues.jboss.org/browse/CDI-573 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts > Affects Versions: 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > > Right now {{CDI}} seems to mimics the JDK service loader mechanism in the the private {{findAllProviders}} method. > In order to get rid of useless code in the API and to limit compatibility issues with JDK9 and jigsaw, I think we should change this code and use Service Loader instead of doing something similar. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

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

by Matej Novotny (JIRA)

[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ] Matej Novotny commented on CDI-527: ----------------------------------- +1 for A. As pointed out by [~rmannibucau], I cannot really imagine an application where this would be a blocker. While C sounds tempting at first, I am afraid of the level of complexity it would bring into the application. Especially for anyone who isn't the original author of the code in question. > 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)

9 years

1
0
0 / 0

[JBoss JIRA] (CDI-573) Review code of CDI class to switch to ServiceLoader

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-573?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand reassigned CDI-573: ---------------------------------------- Assignee: Antoine Sabot-Durand > Review code of CDI class to switch to ServiceLoader > --------------------------------------------------- > > Key: CDI-573 > URL: https://issues.jboss.org/browse/CDI-573 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts > Affects Versions: 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > > Right now {{CDI}} seems to mimics the JDK service loader mechanism in the the private {{findAllProviders}} method. > In order to get rid of useless code in the API and to limit compatibility issues with JDK9 and jigsaw, I think we should change this code and use Service Loader instead of doing something similar. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

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

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-527: ----------------------------------- [~emilyj] Also remember that CDI-1.2 is only specified for Java7. Also note that EJB doesn't support this neither for NIVs... How would D look like in practice? System properties and excludes can be done in a non-portable way anyway. But adding system properties to any spec is in 99% a sign of a broken design. -1 for B. Just added it for completeness ;) We also could have another option E.) introduce some class excludes via beans.xml But that would have the same issues like D imo. Imo C is the most explicit and easiest for users to grasp. > 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)

9 years

1
0
0 / 0

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

by Romain Manni-Bucau (JIRA)

[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ] Romain Manni-Bucau commented on CDI-527: ---------------------------------------- [~emilyj] never has really been supported on CDI side, JDK broke some API (in a more vicious way than this jira) but doesnt mean CDi has to do anything. Do you have an example of a broken application cause of *application* code (and not JVM)? > 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)

9 years

1
0
0 / 0

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

by Emily Jiang (JIRA)

[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ] Emily Jiang commented on CDI-527: --------------------------------- I am thinking from customers' view. For legacy applications falling into this category, they suddenly stopped working with the UnproxyableResolutionException exception throwing at runtime. Sometimes it is not realistic to update the applications. We need to provide a way for the applications to continue working. I think D is good and we can introduce a system property to disable this by default and only enable the support when the property is explicitly set. > 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)

9 years

1
0
0 / 0

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

by Tomas Remes (JIRA)

[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ] Tomas Remes commented on CDI-527: --------------------------------- Yes +1 for A. I consider C as a bit of overkill too. It seems to me that it would bring rather confusion than clarification. > 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)

9 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev December 2015