October 2015 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-565) Unsatisfied dependency should be null?

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-565: ---------------------------------- bq. IIRC, GlassFish 4.1 and WildFly 9 doesn't actually crash during deployment. It must crash and fail with deployment error. And it's also tested by the TCK. -1 for {{@Optional}} +1 for introducing a new convenient method a la {{Instance.isResolvable()}} (or any other better name) so that something like this is possible: {code:java} class MyComponent { @Inject Instance<SomeCollaborator> collaborator; public void someMethod() { if (collaborator.isResolvable()) { collaborator.get().ping(); } } } {code} Right now, you would have to use: {code:java} class MyComponent { @Inject Instance<SomeCollaborator> collaborator; public void someMethod() { if (!collaborator.isUnsatisfied() && !collaborator.isAmbiguous()) { collaborator.get().ping(); } } } {code} > Unsatisfied dependency should be null? > -------------------------------------- > > Key: CDI-565 > URL: https://issues.jboss.org/browse/CDI-565 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Reporter: Martin Andersson > > What if I am writing a component that call a collaborator only if that class exist during runtime? It is amazingly intuitive to write code like this: > {code:java} > class MyComponent > { > @Inject > SomeCollaborator collaborator; > public void someMethod() { > // .. do something > if (collaborator != null) { > collaborator.callback(); > } > } > } > {code} > But the specification currently says in section "5.2.2. Unsatisfied and ambiguous dependencies" that this code should cause a "deployment problem". IIRC, GlassFish 4.1 and WildFly 9 doesn't actually crash during deployment. They will inject {{null}}. WebLogic 12, I just learned, do crash during deployment. > I believe it is unfortunate to have this null value logic for no apparent reason. It is inevitably so that the application code would crash anyways as soon as it tries to dereference a null reference. And you probably agree with me that there's a general guideline established in the developer community which say you shouldn't do null pointer checks all over the code because null pointers will crash exactly when and where the absence of a value really is a problem. > The work around is to inject an {{Instance}} of my type and iterate through all of them, or do any other form of programmatic lookup. However, me personally, I've had this requirement far too many times now. It is often the case that a component I write has a "subframework" in place such that when I want to affect how the application performs, I can just add in new classes of a particular type and it is scoped up. Please don't even make the notion of a design smell out of your own lack of creativity, if you want to see a concrete example then of course I am more than happy to provide you with that. Just saying =) > Something so intuitive and present in our every day coding life as a "null return value" should be present in the CDI specification too. I mean that is what the specification in essence is; one huge {{lookupInstanceOf(class)}}-method. Reading this method name, would you really expect it to crash, or return {{null}}? > How about adding in a new annotation such that the injection point accept null values for unsatisfied dependencies, but if the injection point has an annotation {{@Required}}, then an unsatisfied dependency do crash for this injection point? > You will probably say "let's do it the other way around so that we don't brake backward compatibility" by creating an {{@Optional}} annotation. Hey, if I am abusive to my wife and she divorce me. Should I continue to be abusive to my next wife so that I don't break backward compatibility? Our number one goal should be to define the most awesome specification and API possible - nothing else. If we keep leaving small piles of poo everywhere, then we will inevitably end up deep in shit. > Thank you all for your hard work and time devoted to making all of our lives so much greater. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-565) Unsatisfied dependency should be null?

by Thomas Andraschko (JIRA)

[ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.sy... ] Thomas Andraschko commented on CDI-565: --------------------------------------- +1 for @Inject @Optional > Unsatisfied dependency should be null? > -------------------------------------- > > Key: CDI-565 > URL: https://issues.jboss.org/browse/CDI-565 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Reporter: Martin Andersson > > What if I am writing a component that call a collaborator only if that class exist during runtime? It is amazingly intuitive to write code like this: > {code:java} > class MyComponent > { > @Inject > SomeCollaborator collaborator; > public void someMethod() { > // .. do something > if (collaborator != null) { > collaborator.callback(); > } > } > } > {code} > But the specification currently says in section "5.2.2. Unsatisfied and ambiguous dependencies" that this code should cause a "deployment problem". IIRC, GlassFish 4.1 and WildFly 9 doesn't actually crash during deployment. They will inject {{null}}. WebLogic 12, I just learned, do crash during deployment. > I believe it is unfortunate to have this null value logic for no apparent reason. It is inevitably so that the application code would crash anyways as soon as it tries to dereference a null reference. And you probably agree with me that there's a general guideline established in the developer community which say you shouldn't do null pointer checks all over the code because null pointers will crash exactly when and where the absence of a value really is a problem. > The work around is to inject an {{Instance}} of my type and iterate through all of them, or do any other form of programmatic lookup. However, me personally, I've had this requirement far too many times now. It is often the case that a component I write has a "subframework" in place such that when I want to affect how the application performs, I can just add in new classes of a particular type and it is scoped up. Please don't even make the notion of a design smell out of your own lack of creativity, if you want to see a concrete example then of course I am more than happy to provide you with that. Just saying =) > Something so intuitive and present in our every day coding life as a "null return value" should be present in the CDI specification too. I mean that is what the specification in essence is; one huge {{lookupInstanceOf(class)}}-method. Reading this method name, would you really expect it to crash, or return {{null}}? > How about adding in a new annotation such that the injection point accept null values for unsatisfied dependencies, but if the injection point has an annotation {{@Required}}, then an unsatisfied dependency do crash for this injection point? > You will probably say "let's do it the other way around so that we don't brake backward compatibility" by creating an {{@Optional}} annotation. Hey, if I am abusive to my wife and she divorce me. Should I continue to be abusive to my next wife so that I don't break backward compatibility? Our number one goal should be to define the most awesome specification and API possible - nothing else. If we keep leaving small piles of poo everywhere, then we will inevitably end up deep in shit. > Thank you all for your hard work and time devoted to making all of our lives so much greater. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-565) Unsatisfied dependency should be null?

by Martin Andersson (JIRA)

Martin Andersson created CDI-565: ------------------------------------ Summary: Unsatisfied dependency should be null? Key: CDI-565 URL: https://issues.jboss.org/browse/CDI-565 Project: CDI Specification Issues Issue Type: Feature Request Components: Beans Reporter: Martin Andersson What if I am writing a component that call a collaborator only if that class exist during runtime? It is amazingly intuitive to write code like this: {code:java} class MyComponent { @Inject SomeCollaborator collaborator; public void someMethod() { // .. do something if (collaborator != null) { collaborator.callback(); } } } {code} But the specification currently says in section "5.2.2. Unsatisfied and ambiguous dependencies" that this code should cause a "deployment problem". IIRC, GlassFish 4.1 and WildFly 9 doesn't actually crash during deployment. They will inject {{null}}. WebLogic 12, I just learned, do crash during deployment. I believe it is unfortunate to have this null value logic for no apparent reason. It is inevitably so that the application code would crash anyways as soon as it tries to dereference a null reference. And you probably agree with me that there's a general guideline established in the developer community which say you shouldn't do null pointer checks all over the code because null pointers will crash exactly when and where the absence of a value really is a problem. The work around is to inject an {{Instance}} of my type and iterate through all of them, or do any other form of programmatic lookup. However, me personally, I've had this requirement far too many times now. It is often the case that a component I write has a "subframework" in place such that when I want to affect how the application performs, I can just add in new classes of a particular type and it is scoped up. Please don't even make the notion of a design smell out of your own lack of creativity, if you want to see a concrete example then of course I am more than happy to provide you with that. Just saying =) Something so intuitive and present in our every day coding life as a "null return value" should be present in the CDI specification too. I mean that is what the specification in essence is; one huge {{lookupInstanceOf(class)}}-method. Reading this method name, would you really expect it to crash, or return {{null}}? How about adding in a new annotation such that the injection point accept null values for unsatisfied dependencies, but if the injection point has an annotation {{@Required}}, then an unsatisfied dependency do crash for this injection point? You will probably say "let's do it the other way around so that we don't brake backward compatibility" by creating an {{@Optional}} annotation. Hey, if I am abusive to my wife and she divorce me. Should I continue to be abusive to my next wife so that I don't break backward compatibility? Our number one goal should be to define the most awesome specification and API possible - nothing else. If we keep leaving small piles of poo everywhere, then we will inevitably end up deep in shit. Thank you all for your hard work and time devoted to making all of our lives so much greater. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-51) Support static injection

by Vsevolod Golovanov (JIRA)

[ https://issues.jboss.org/browse/CDI-51?page=com.atlassian.jira.plugin.sys... ] Vsevolod Golovanov commented on CDI-51: --------------------------------------- The "Forum Reference" link is dead, quoting relevant part here. {quote} Injection for static members has a couple of problems: * A class can be shared between multiple applications, and the Java EE spec does not define rules for this. * Outside Java EE, it's difficult to define exactly when a static member is injected. Nevertheless, there are a couple of great usecases for this: * logger injection, * injection for entity classes, and * injection into objects with a passivating scope. So we do need to support something here. Perhaps it would be enough to say: * no static injection in shared libraries, and * static fields are injected before the very first instance of a bean is instantiated (but then static injection would not be supported for non-bean classes). {quote} https://web.archive.org/web/20130529234448/http://www.seamframework.org/W... > Support static injection > ------------------------ > > Key: CDI-51 > URL: https://issues.jboss.org/browse/CDI-51 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: TBD > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

Next meeting on October 20th

by Antoine Sabot-Durand

Hi all, I can't make it for today's netting and will give a talk next Tuesday. So we'll meet again on the 20th. In the meantime I'm working on async review and SE bootstrap review. Check the coming PR. Antoine

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-564) Async events simplification and clarification

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-564?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-564: ---------------------------------- And we should also clarify the usage of the returned CompletionStage - see also CDI-563. > Async events simplification and clarification > --------------------------------------------- > > Key: CDI-564 > URL: https://issues.jboss.org/browse/CDI-564 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > > Following our F2F meeting, we decided to simplify Asynchronous event: > * {{FireAsync()}} should only triggers async observers > * Exception handling should be done with JDK 8 {{CompletionException}} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-564) Async events simplification and clarification

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-564?page=com.atlassian.jira.plugin.sy... ] Work on CDI-564 started by Antoine Sabot-Durand. ------------------------------------------------ > Async events simplification and clarification > --------------------------------------------- > > Key: CDI-564 > URL: https://issues.jboss.org/browse/CDI-564 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > > Following our F2F meeting, we decided to simplify Asynchronous event: > * {{FireAsync()}} should only triggers async observers > * Exception handling should be done with JDK 8 {{CompletionException}} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-564) Async events simplification and clarification

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-564?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-564: ------------------------------------- Summary: Async events simplification and clarification (was: Async events simplification ad clarification) > Async events simplification and clarification > --------------------------------------------- > > Key: CDI-564 > URL: https://issues.jboss.org/browse/CDI-564 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > > Following our F2F meeting, we decided to simplify Asynchronous event: > * {{FireAsync()}} should only triggers async observers > * Exception handling should be done with JDK 8 {{CompletionException}} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-564) Async events simplification ad clarification

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-564?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-564: ------------------------------------- Description: Following our F2F meeting, we decided to simplify Asynchronous event: * {{FireAsync()}} should only triggers async observers * Exception handling should be done with JDK 8 {{CompletionException}} was: Following our F2F meeting, we decided to simplify Asynchronous event: * {{FireAsync() }}should only triggers async observers * Exception handling should be done with JDK 8 {{CompletionException}} > Async events simplification ad clarification > -------------------------------------------- > > Key: CDI-564 > URL: https://issues.jboss.org/browse/CDI-564 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > > Following our F2F meeting, we decided to simplify Asynchronous event: > * {{FireAsync()}} should only triggers async observers > * Exception handling should be done with JDK 8 {{CompletionException}} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-564) Async events simplification ad clarification

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-564?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand reassigned CDI-564: ---------------------------------------- Assignee: Antoine Sabot-Durand > Async events simplification ad clarification > -------------------------------------------- > > Key: CDI-564 > URL: https://issues.jboss.org/browse/CDI-564 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > > Following our F2F meeting, we decided to simplify Asynchronous event: > * {{FireAsync() }}should only triggers async observers > * Exception handling should be done with JDK 8 {{CompletionException}} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev October 2015