From issues at jboss.org Thu Oct 1 02:47:00 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Thu, 1 Oct 2015 02:47:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-383) Clarify that session context is also destroyed at shutdown/undeploy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114037#comment-13114037 ] Mark Struberg commented on CDI-383: ----------------------------------- Session invalidation != application shutdown. I think this paragraph in the servlet spec exists because the containers are allowed to either persist the sessions and reuse them at a later restart OR to not use persistent sessions. In the later case the sessioncontexts need to get destroyed of course. I asked myself the same question when working on this in OWB. And the conclusio (after discussing with many other people) was that we should _strictly_ follow the Session listener. If he tells us to destroy the session then we also gonna kill this very sessioncontext. If not then nothing happens. What is the impact of evicting the session anyway? The most important is that the @PreDestroy method on @SessionScoped beans get called. But what if the server is clustered? If a single node goes down this doesn't mean that the users session is dead. It could have been survived on a memcached (and get picked up from other nodes if required). Or there might be node-pairing and the shutdown might be part of a 'ripple-restart'. In this case the session survives as well as it got replicated to the paired node. My conclusio of all those things was that @PreDestroy in any passivating bean is _not_ reliable anyway. What if the cluster goes down and the new application version is not able to deserialize the bean again? What if the time spent during shut down is too long and the server doesn't even bother to reload the session from disk again (as he knows it is already timed out). Or think about @ViewScoped beans in case JSF is configured to use client-side state saving. And the user just closes his browser ;) There are many similar cases where you cannot 100% rely on beans in passivating scopes to be cleaned up properly. > Clarify that session context is also destroyed at shutdown/undeploy > ------------------------------------------------------------------- > > Key: CDI-383 > URL: https://issues.jboss.org/browse/CDI-383 > Project: CDI Specification Issues > Issue Type: Bug > Components: Contexts > Affects Versions: 1.1.PFD > Reporter: Marko Luk?a > > Section 6.7.2. states "The session context is destroyed > when the HTTPSession times out, after all HttpSessionListener s have been called, and at the very end of any request > in which invalidate() was called, after all filters and ServletRequestListener s have been called." > The first part of the above sentence should not only say that the context is destroyed after all listeners have been called specifically in the event of a session timeout. It should specify that this is also true when the session is being destroyed as a result of server shutdown or web-app undeploy. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 1 03:16:01 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 1 Oct 2015 03:16:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-383) Clarify that session context is also destroyed at shutdown/undeploy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114041#comment-13114041 ] Martin Kouba commented on CDI-383: ---------------------------------- Yep, I think we should reject this issue because of undefined behavior and follow the session listener. On the other hand, if it's not reliable users should be very careful when using passivating scopes backed by an HttpSession. > Clarify that session context is also destroyed at shutdown/undeploy > ------------------------------------------------------------------- > > Key: CDI-383 > URL: https://issues.jboss.org/browse/CDI-383 > Project: CDI Specification Issues > Issue Type: Bug > Components: Contexts > Affects Versions: 1.1.PFD > Reporter: Marko Luk?a > > Section 6.7.2. states "The session context is destroyed > when the HTTPSession times out, after all HttpSessionListener s have been called, and at the very end of any request > in which invalidate() was called, after all filters and ServletRequestListener s have been called." > The first part of the above sentence should not only say that the context is destroyed after all listeners have been called specifically in the event of a session timeout. It should specify that this is also true when the session is being destroyed as a result of server shutdown or web-app undeploy. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 1 03:48:00 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Thu, 1 Oct 2015 03:48:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-383) Clarify that session context is also destroyed at shutdown/undeploy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114044#comment-13114044 ] Mark Struberg commented on CDI-383: ----------------------------------- +1. But it's not only related to @SessionScoped. Basically @PreDestroy is not reliable for _all_ beans of passivating contexts as you can see in my @ViewScoped bean example. > Clarify that session context is also destroyed at shutdown/undeploy > ------------------------------------------------------------------- > > Key: CDI-383 > URL: https://issues.jboss.org/browse/CDI-383 > Project: CDI Specification Issues > Issue Type: Bug > Components: Contexts > Affects Versions: 1.1.PFD > Reporter: Marko Luk?a > > Section 6.7.2. states "The session context is destroyed > when the HTTPSession times out, after all HttpSessionListener s have been called, and at the very end of any request > in which invalidate() was called, after all filters and ServletRequestListener s have been called." > The first part of the above sentence should not only say that the context is destroyed after all listeners have been called specifically in the event of a session timeout. It should specify that this is also true when the session is being destroyed as a result of server shutdown or web-app undeploy. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 1 06:44:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 1 Oct 2015 06:44:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-537) Event firing on JavaEE component classes- JPA entity listener In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114102#comment-13114102 ] Martin Kouba commented on CDI-537: ---------------------------------- Yes, I think we should do some work on the spec level. Both the JPA and CDI specs should be aware of the chicken-and-egg problem during bootstrap - the CDI container must support injection of JPA components but JPA entity listeners must be able to inject CDI beans as well. In other words, the entity listeners should be instantiated after the CDI container is initialized. Thus, ProcessInjectionTarget events for these components must be fired before the listeners exist and then later on used by the JPA. Note that the JPA spec states: bq. "The persistence provider is responsible for using the CDI SPI to create instances of the entity listener class" > Event firing on JavaEE component classes- JPA entity listener > ------------------------------------------------------------- > > Key: CDI-537 > URL: https://issues.jboss.org/browse/CDI-537 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Affects Versions: 1.2.Final > Reporter: Emily Jiang > > In CDI 1.2 spec > 11.5.7. ProcessInjectionPoint event > The container must fire an event for every injection point of every Java EE component class > supporting injection that may be instantiated by the container at runtime, including every managed bean declared using @ManagedBean, EJB session or message-driven bean, bean, interceptor or decorator. > The JavaEE component classes are mentioned in JavaEE platform EE.5-1, which includes servlets, servlet filters, entity listeners etc. > My concern is about entity listeners in JPA. Eclipse link has done all the injection for entity listeners. It does not fire the event, @See createEntityListenerAndInjectDependancies(...) > JPA spec section 3.5.1 does not mention this event requirement. How can the eclipse cdi implementation satisfy the CDI spec? > [1] http://git.eclipse.org/c/eclipselink/eclipselink.runtime.git/tree/foundation/org.eclipse.persistence.core/src/org/eclipse/persistence/internal/sessions/cdi/EntityListenerInjectionManagerImpl.java?h=2.6_WAS] > I had an initial discussion with Jozef. > Jozef wrote: " > Doing this using purely CDI APIs can be a bit tricky. One option that will most likely work is to combine BeanManager.resolveObserverMethods() method with a custom implementation of ProcessInjectionTarget interface. That way you can resolve the matching observer methods and then call their notify() method to deliver the event. Exception handling needs to be implemented to match the spec. > We should update the spec to define a more direct route and for the JPA spec to mention this requirement." > My response: > "+1 on revisiting this on the CDI spec. I think adding an additional method on the BeanManager api, e.g. fireProcessInjectionTarget would be good. Effectively, it is to promote this very method on WeldManager to BeanManager." -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 1 09:04:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 1 Oct 2015 09:04:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-557) Chapter "10.4.3. The EventMetadata interface" mentions fireAsyncEvent method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-557: ---------------------------------------- Assignee: Antoine Sabot-Durand Resolution: Done > Chapter "10.4.3. The EventMetadata interface" mentions fireAsyncEvent method > ---------------------------------------------------------------------------- > > Key: CDI-557 > URL: https://issues.jboss.org/browse/CDI-557 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Tomas Remes > Assignee: Antoine Sabot-Durand > Priority: Minor > > http://docs.jboss.org/cdi/spec/2.0.EDR1/cdi-spec.html#event_metadata > In paragraph for isAsync method there is: > {quote} > isAsync() returns true if the event was fired with fireAsync() or fireAsyncEvent() methods otherwise returns false. > {quote} > AFAIK There is no such method. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From antoine at sabot-durand.net Thu Oct 1 10:10:46 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 01 Oct 2015 14:10:46 +0000 Subject: [cdi-dev] EDR1 merged into master + asciidoctor sources cleaning Message-ID: Hi all, I just merged EDR1 to master (and kept a tag for master status before EDR1). I also reviewed all Asciidoctor source file to switch their format to 1 sentence by line and switch to new format for literal in Asciidoctor. Took me a few hours to be sure that spec before and after stays exactly the same (detected 4 or 5 formatting errors in the process) This new format will make pull requests easier to read : instead of having a whole paragraph changed when a word is updated, only the matching sentence will be affected. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151001/00653f3b/attachment.html From mkouba at redhat.com Thu Oct 1 10:26:03 2015 From: mkouba at redhat.com (Martin Kouba) Date: Thu, 1 Oct 2015 16:26:03 +0200 Subject: [cdi-dev] EDR1 merged into master + asciidoctor sources cleaning In-Reply-To: References: Message-ID: <560D427B.3090105@redhat.com> Looks good! Dne 1.10.2015 v 16:10 Antoine Sabot-Durand napsal(a): > Hi all, > > I just merged EDR1 to master (and kept a tag for master status before EDR1). > > I also reviewed all Asciidoctor source file to switch their format to 1 > sentence by line and switch to new format for literal in Asciidoctor. > > Took me a few hours to be sure that spec before and after stays exactly > the same (detected 4 or 5 formatting errors in the process) > > This new format will make pull requests easier to read : instead of > having a whole paragraph changed when a word is updated, only the > matching sentence will be affected. > > Antoine > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. > -- Martin Kouba Software Engineer Red Hat, Czech Republic From antonin at stefanutti.fr Thu Oct 1 12:30:25 2015 From: antonin at stefanutti.fr (Antonin Stefanutti) Date: Thu, 1 Oct 2015 16:30:25 +0000 Subject: [cdi-dev] Adding / vetoing CDI extensions programmatically Message-ID: <808F2CC8-2687-4A3E-ABA4-2C62A8D8E6BF@stefanutti.fr> Hi CDI mates, I?ve been developing a couple of CDI extensions over the last couple of years and been facing this recurrent situation: - I develop the extension against the latest CDI release version (1.2 for the time being), - As the extension gets used, comes the requests to run the extension in previous CDI versions, - As any real-world extensions heavily rely on the CDI SPI, they never happen to be backward-compatible, - And that?s understandable that the end-users won?t upgrade its runtime environment for just one extension. One option is to rewrite the extension against the oldest required CDI version (generally 1.0 as a lot of people still use that version as part of Java EE 6) by working around lacking functionalities from the CDI SPI at the cost of code readability or even removed features that are impossible to re-implement. To avoid that, it is obviously possible to create a separate branch / module dedicated to porting the extension to the oldest possible CDI version, but then comes the packaging / distribution problem: - You assign different versions to the branches, unfortunately that does not work for projects that include their own CDI extension into the same codeline (like Apache Camel, JBoss Infinispan, ?) as it doesn?t make sense to impact the whole project versioning for one possible container / runtime among others possible, - Or you create two artifacts / modules whose name (or classifier) somehow contains the CDI compatible version. That?s not very ideal either, and in any case, that?s the end user burden to make the decision which artifact to choose from a list that will grow over time with CDI 2.0 and future CDI versions. Which leads to my point... As there exists a way to add / veto annotated types and beans programmatically, one solution that will help addressing the above problems, both for the extension developers and users, would be to have the ability to add / veto extensions dynamically. That way, multiple version / part of the extension could be packaged into a single artifact and activated dynamically during the application initialisation phase based on some runtime criteria, in my use case the CDI environment version. The point here is not to discuss potential implementations, but we could imagine having an AfterExtensionDiscovery of BeforeTypeDiscovery lifecycle event from which adding or vetoing extensions would be possible, or some mechanisms in the beans.xml file to include / exclude an extension... So before discussing implementation details, I?d like your opinion on that use case, whether it?s valid or other options exist. Thanks, Antonin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151001/68b34e9b/attachment-0001.html From struberg at yahoo.de Thu Oct 1 15:15:58 2015 From: struberg at yahoo.de (Mark Struberg) Date: Thu, 1 Oct 2015 21:15:58 +0200 Subject: [cdi-dev] Adding / vetoing CDI extensions programmatically In-Reply-To: <808F2CC8-2687-4A3E-ABA4-2C62A8D8E6BF@stefanutti.fr> References: <808F2CC8-2687-4A3E-ABA4-2C62A8D8E6BF@stefanutti.fr> Message-ID: <6176918B-B339-4C2E-BC09-189CE12BA3D3@yahoo.de> You might look at DeltaSpikes ?Deactivatable? LieGrue, strub > Am 01.10.2015 um 18:30 schrieb Antonin Stefanutti : > > Hi CDI mates, > > I?ve been developing a couple of CDI extensions over the last couple of years and been facing this recurrent situation: > - I develop the extension against the latest CDI release version (1.2 for the time being), > - As the extension gets used, comes the requests to run the extension in previous CDI versions, > - As any real-world extensions heavily rely on the CDI SPI, they never happen to be backward-compatible, > - And that?s understandable that the end-users won?t upgrade its runtime environment for just one extension. > > One option is to rewrite the extension against the oldest required CDI version (generally 1.0 as a lot of people still use that version as part of Java EE 6) by working around lacking functionalities from the CDI SPI at the cost of code readability or even removed features that are impossible to re-implement. > > To avoid that, it is obviously possible to create a separate branch / module dedicated to porting the extension to the oldest possible CDI version, but then comes the packaging / distribution problem: > - You assign different versions to the branches, unfortunately that does not work for projects that include their own CDI extension into the same codeline (like Apache Camel, JBoss Infinispan, ?) as it doesn?t make sense to impact the whole project versioning for one possible container / runtime among others possible, > - Or you create two artifacts / modules whose name (or classifier) somehow contains the CDI compatible version. > > That?s not very ideal either, and in any case, that?s the end user burden to make the decision which artifact to choose from a list that will grow over time with CDI 2.0 and future CDI versions. > > Which leads to my point... As there exists a way to add / veto annotated types and beans programmatically, one solution that will help addressing the above problems, both for the extension developers and users, would be to have the ability to add / veto extensions dynamically. That way, multiple version / part of the extension could be packaged into a single artifact and activated dynamically during the application initialisation phase based on some runtime criteria, in my use case the CDI environment version. The point here is not to discuss potential implementations, but we could imagine having an AfterExtensionDiscovery of BeforeTypeDiscovery lifecycle event from which adding or vetoing extensions would be possible, or some mechanisms in the beans.xml file to include / exclude an extension... > > So before discussing implementation details, I?d like your opinion on that use case, whether it?s valid or other options exist. > > Thanks, > Antonin > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. From arjan.tijms at gmail.com Thu Oct 1 16:44:57 2015 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 1 Oct 2015 22:44:57 +0200 Subject: [cdi-dev] Adding / vetoing CDI extensions programmatically In-Reply-To: <808F2CC8-2687-4A3E-ABA4-2C62A8D8E6BF@stefanutti.fr> References: <808F2CC8-2687-4A3E-ABA4-2C62A8D8E6BF@stefanutti.fr> Message-ID: There's an existing issue for this: https://issues.jboss.org/browse/CDI-157 The JSF EG is also really interested in this, for https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1361 and several other things. Kind regards, Arjan Tijms On Thu, Oct 1, 2015 at 6:30 PM, Antonin Stefanutti wrote: > Hi CDI mates, > > I?ve been developing a couple of CDI extensions over the last couple of > years and been facing this recurrent situation: > - I develop the extension against the latest CDI release version (1.2 for > the time being), > - As the extension gets used, comes the requests to run the extension in > previous CDI versions, > - As any real-world extensions heavily rely on the CDI SPI, they never > happen to be backward-compatible, > - And that?s understandable that the end-users won?t upgrade its runtime > environment for just one extension. > > One option is to rewrite the extension against the oldest required CDI > version (generally 1.0 as a lot of people still use that version as part of > Java EE 6) by working around lacking functionalities from the CDI SPI at the > cost of code readability or even removed features that are impossible to > re-implement. > > To avoid that, it is obviously possible to create a separate branch / module > dedicated to porting the extension to the oldest possible CDI version, but > then comes the packaging / distribution problem: > - You assign different versions to the branches, unfortunately that does > not work for projects that include their own CDI extension into the same > codeline (like Apache Camel, JBoss Infinispan, ?) as it doesn?t make sense > to impact the whole project versioning for one possible container / runtime > among others possible, > - Or you create two artifacts / modules whose name (or classifier) somehow > contains the CDI compatible version. > > That?s not very ideal either, and in any case, that?s the end user burden to > make the decision which artifact to choose from a list that will grow over > time with CDI 2.0 and future CDI versions. > > Which leads to my point... As there exists a way to add / veto annotated > types and beans programmatically, one solution that will help addressing the > above problems, both for the extension developers and users, would be to > have the ability to add / veto extensions dynamically. That way, multiple > version / part of the extension could be packaged into a single artifact and > activated dynamically during the application initialisation phase based on > some runtime criteria, in my use case the CDI environment version. The point > here is not to discuss potential implementations, but we could imagine > having an AfterExtensionDiscovery of BeforeTypeDiscovery lifecycle event > from which adding or vetoing extensions would be possible, or some > mechanisms in the beans.xml file to include / exclude an extension... > > So before discussing implementation details, I?d like your opinion on that > use case, whether it?s valid or other options exist. > > Thanks, > Antonin > > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. From rmannibucau at gmail.com Thu Oct 1 16:55:45 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Thu, 1 Oct 2015 13:55:45 -0700 Subject: [cdi-dev] Adding / vetoing CDI extensions programmatically In-Reply-To: References: <808F2CC8-2687-4A3E-ABA4-2C62A8D8E6BF@stefanutti.fr> Message-ID: Interesting, couldn't excludes supports it? when processing extensions we have the beans.xml model so extensions could be filtered this way, no? Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-10-01 13:44 GMT-07:00 arjan tijms : > There's an existing issue for this: > https://issues.jboss.org/browse/CDI-157 > > The JSF EG is also really interested in this, for > https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1361 and > several other things. > > Kind regards, > Arjan Tijms > > > On Thu, Oct 1, 2015 at 6:30 PM, Antonin Stefanutti > wrote: > > Hi CDI mates, > > > > I?ve been developing a couple of CDI extensions over the last couple of > > years and been facing this recurrent situation: > > - I develop the extension against the latest CDI release version (1.2 for > > the time being), > > - As the extension gets used, comes the requests to run the extension in > > previous CDI versions, > > - As any real-world extensions heavily rely on the CDI SPI, they never > > happen to be backward-compatible, > > - And that?s understandable that the end-users won?t upgrade its runtime > > environment for just one extension. > > > > One option is to rewrite the extension against the oldest required CDI > > version (generally 1.0 as a lot of people still use that version as part > of > > Java EE 6) by working around lacking functionalities from the CDI SPI at > the > > cost of code readability or even removed features that are impossible to > > re-implement. > > > > To avoid that, it is obviously possible to create a separate branch / > module > > dedicated to porting the extension to the oldest possible CDI version, > but > > then comes the packaging / distribution problem: > > - You assign different versions to the branches, unfortunately that does > > not work for projects that include their own CDI extension into the same > > codeline (like Apache Camel, JBoss Infinispan, ?) as it doesn?t make > sense > > to impact the whole project versioning for one possible container / > runtime > > among others possible, > > - Or you create two artifacts / modules whose name (or classifier) > somehow > > contains the CDI compatible version. > > > > That?s not very ideal either, and in any case, that?s the end user > burden to > > make the decision which artifact to choose from a list that will grow > over > > time with CDI 2.0 and future CDI versions. > > > > Which leads to my point... As there exists a way to add / veto annotated > > types and beans programmatically, one solution that will help addressing > the > > above problems, both for the extension developers and users, would be to > > have the ability to add / veto extensions dynamically. That way, multiple > > version / part of the extension could be packaged into a single artifact > and > > activated dynamically during the application initialisation phase based > on > > some runtime criteria, in my use case the CDI environment version. The > point > > here is not to discuss potential implementations, but we could imagine > > having an AfterExtensionDiscovery of BeforeTypeDiscovery lifecycle event > > from which adding or vetoing extensions would be possible, or some > > mechanisms in the beans.xml file to include / exclude an extension... > > > > So before discussing implementation details, I?d like your opinion on > that > > use case, whether it?s valid or other options exist. > > > > Thanks, > > Antonin > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151001/5b6695ea/attachment.html From mkouba at redhat.com Fri Oct 2 03:59:20 2015 From: mkouba at redhat.com (Martin Kouba) Date: Fri, 2 Oct 2015 09:59:20 +0200 Subject: [cdi-dev] Adding / vetoing CDI extensions programmatically In-Reply-To: References: <808F2CC8-2687-4A3E-ABA4-2C62A8D8E6BF@stefanutti.fr> Message-ID: <560E3958.3030904@redhat.com> Dne 1.10.2015 v 22:55 Romain Manni-Bucau napsal(a): > Interesting, couldn't excludes supports it? when processing extensions > we have the beans.xml model so extensions could be filtered this way, no? No. beans.xml excludes are local (i.e. per bean archive). Extensions are global - per application. > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2015-10-01 13:44 GMT-07:00 arjan tijms >: > > There's an existing issue for this: > https://issues.jboss.org/browse/CDI-157 > > The JSF EG is also really interested in this, for > https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1361 and > several other things. > > Kind regards, > Arjan Tijms > > > On Thu, Oct 1, 2015 at 6:30 PM, Antonin Stefanutti > > wrote: > > Hi CDI mates, > > > > I?ve been developing a couple of CDI extensions over the last > couple of > > years and been facing this recurrent situation: > > - I develop the extension against the latest CDI release version > (1.2 for > > the time being), > > - As the extension gets used, comes the requests to run the > extension in > > previous CDI versions, > > - As any real-world extensions heavily rely on the CDI SPI, they > never > > happen to be backward-compatible, > > - And that?s understandable that the end-users won?t upgrade its > runtime > > environment for just one extension. > > > > One option is to rewrite the extension against the oldest > required CDI > > version (generally 1.0 as a lot of people still use that version > as part of > > Java EE 6) by working around lacking functionalities from the CDI > SPI at the > > cost of code readability or even removed features that are > impossible to > > re-implement. > > > > To avoid that, it is obviously possible to create a separate > branch / module > > dedicated to porting the extension to the oldest possible CDI > version, but > > then comes the packaging / distribution problem: > > - You assign different versions to the branches, unfortunately > that does > > not work for projects that include their own CDI extension into > the same > > codeline (like Apache Camel, JBoss Infinispan, ?) as it doesn?t > make sense > > to impact the whole project versioning for one possible container > / runtime > > among others possible, > > - Or you create two artifacts / modules whose name (or > classifier) somehow > > contains the CDI compatible version. > > > > That?s not very ideal either, and in any case, that?s the end > user burden to > > make the decision which artifact to choose from a list that will > grow over > > time with CDI 2.0 and future CDI versions. > > > > Which leads to my point... As there exists a way to add / veto > annotated > > types and beans programmatically, one solution that will help > addressing the > > above problems, both for the extension developers and users, > would be to > > have the ability to add / veto extensions dynamically. That way, > multiple > > version / part of the extension could be packaged into a single > artifact and > > activated dynamically during the application initialisation phase > based on > > some runtime criteria, in my use case the CDI environment > version. The point > > here is not to discuss potential implementations, but we could > imagine > > having an AfterExtensionDiscovery of BeforeTypeDiscovery > lifecycle event > > from which adding or vetoing extensions would be possible, or some > > mechanisms in the beans.xml file to include / exclude an extension... > > > > So before discussing implementation details, I?d like your > opinion on that > > use case, whether it?s valid or other options exist. > > > > Thanks, > > Antonin > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at 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 at 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 at 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. > -- Martin Kouba Software Engineer Red Hat, Czech Republic From antonio.goncalves at gmail.com Fri Oct 2 04:31:51 2015 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Fri, 2 Oct 2015 10:31:51 +0200 Subject: [cdi-dev] Adding / vetoing CDI extensions programmatically In-Reply-To: <560E3958.3030904@redhat.com> References: <808F2CC8-2687-4A3E-ABA4-2C62A8D8E6BF@stefanutti.fr> <560E3958.3030904@redhat.com> Message-ID: BTW during the F2F meeting we discussed the idea of having a "global" beans.xml (the same idea behind web.xml and web-fragment.xml). So the idea is to be able to include/exclude globally. Antonio On Fri, Oct 2, 2015 at 9:59 AM, Martin Kouba wrote: > Dne 1.10.2015 v 22:55 Romain Manni-Bucau napsal(a): > > Interesting, couldn't excludes supports it? when processing extensions > > we have the beans.xml model so extensions could be filtered this way, no? > > No. beans.xml excludes are local (i.e. per bean archive). Extensions are > global - per application. > > > > > > > Romain Manni-Bucau > > @rmannibucau | Blog > > | Github > > | LinkedIn > > | Tomitriber > > > > > > 2015-10-01 13:44 GMT-07:00 arjan tijms > >: > > > > There's an existing issue for this: > > https://issues.jboss.org/browse/CDI-157 > > > > The JSF EG is also really interested in this, for > > https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1361 and > > several other things. > > > > Kind regards, > > Arjan Tijms > > > > > > On Thu, Oct 1, 2015 at 6:30 PM, Antonin Stefanutti > > > wrote: > > > Hi CDI mates, > > > > > > I?ve been developing a couple of CDI extensions over the last > > couple of > > > years and been facing this recurrent situation: > > > - I develop the extension against the latest CDI release version > > (1.2 for > > > the time being), > > > - As the extension gets used, comes the requests to run the > > extension in > > > previous CDI versions, > > > - As any real-world extensions heavily rely on the CDI SPI, they > > never > > > happen to be backward-compatible, > > > - And that?s understandable that the end-users won?t upgrade its > > runtime > > > environment for just one extension. > > > > > > One option is to rewrite the extension against the oldest > > required CDI > > > version (generally 1.0 as a lot of people still use that version > > as part of > > > Java EE 6) by working around lacking functionalities from the CDI > > SPI at the > > > cost of code readability or even removed features that are > > impossible to > > > re-implement. > > > > > > To avoid that, it is obviously possible to create a separate > > branch / module > > > dedicated to porting the extension to the oldest possible CDI > > version, but > > > then comes the packaging / distribution problem: > > > - You assign different versions to the branches, unfortunately > > that does > > > not work for projects that include their own CDI extension into > > the same > > > codeline (like Apache Camel, JBoss Infinispan, ?) as it doesn?t > > make sense > > > to impact the whole project versioning for one possible container > > / runtime > > > among others possible, > > > - Or you create two artifacts / modules whose name (or > > classifier) somehow > > > contains the CDI compatible version. > > > > > > That?s not very ideal either, and in any case, that?s the end > > user burden to > > > make the decision which artifact to choose from a list that will > > grow over > > > time with CDI 2.0 and future CDI versions. > > > > > > Which leads to my point... As there exists a way to add / veto > > annotated > > > types and beans programmatically, one solution that will help > > addressing the > > > above problems, both for the extension developers and users, > > would be to > > > have the ability to add / veto extensions dynamically. That way, > > multiple > > > version / part of the extension could be packaged into a single > > artifact and > > > activated dynamically during the application initialisation phase > > based on > > > some runtime criteria, in my use case the CDI environment > > version. The point > > > here is not to discuss potential implementations, but we could > > imagine > > > having an AfterExtensionDiscovery of BeforeTypeDiscovery > > lifecycle event > > > from which adding or vetoing extensions would be possible, or some > > > mechanisms in the beans.xml file to include / exclude an > extension... > > > > > > So before discussing implementation details, I?d like your > > opinion on that > > > use case, whether it?s valid or other options exist. > > > > > > Thanks, > > > Antonin > > > > > > _______________________________________________ > > > cdi-dev mailing list > > > cdi-dev at 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 at 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 at 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. > > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. > -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151002/ae3052fd/attachment.html From antoine at sabot-durand.net Fri Oct 2 04:54:09 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 02 Oct 2015 08:54:09 +0000 Subject: [cdi-dev] Adding / vetoing CDI extensions programmatically In-Reply-To: References: <808F2CC8-2687-4A3E-ABA4-2C62A8D8E6BF@stefanutti.fr> <560E3958.3030904@redhat.com> Message-ID: I think the idea of a global configuration, either in a global-beans.xml, either in the code ((ProcessExtensions or AfterExtensionDiscovery ;)) is an interesting topic. Now this doesn't solve the problem for existing version : no obvious way to remove a 2.0 extension in 1.2 code... Antoine Le ven. 2 oct. 2015 ? 10:32, Antonio Goncalves a ?crit : > BTW during the F2F meeting we discussed the idea of having a "global" > beans.xml (the same idea behind web.xml and web-fragment.xml). So the idea > is to be able to include/exclude globally. > > Antonio > > On Fri, Oct 2, 2015 at 9:59 AM, Martin Kouba wrote: > >> Dne 1.10.2015 v 22:55 Romain Manni-Bucau napsal(a): >> > Interesting, couldn't excludes supports it? when processing extensions >> > we have the beans.xml model so extensions could be filtered this way, >> no? >> >> No. beans.xml excludes are local (i.e. per bean archive). Extensions are >> global - per application. >> >> > >> > >> > Romain Manni-Bucau >> > @rmannibucau | Blog >> > | Github >> > | LinkedIn >> > | Tomitriber >> > >> > >> > 2015-10-01 13:44 GMT-07:00 arjan tijms > > >: >> > >> > There's an existing issue for this: >> > https://issues.jboss.org/browse/CDI-157 >> > >> > The JSF EG is also really interested in this, for >> > https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1361 and >> > several other things. >> > >> > Kind regards, >> > Arjan Tijms >> > >> > >> > On Thu, Oct 1, 2015 at 6:30 PM, Antonin Stefanutti >> > > wrote: >> > > Hi CDI mates, >> > > >> > > I?ve been developing a couple of CDI extensions over the last >> > couple of >> > > years and been facing this recurrent situation: >> > > - I develop the extension against the latest CDI release version >> > (1.2 for >> > > the time being), >> > > - As the extension gets used, comes the requests to run the >> > extension in >> > > previous CDI versions, >> > > - As any real-world extensions heavily rely on the CDI SPI, they >> > never >> > > happen to be backward-compatible, >> > > - And that?s understandable that the end-users won?t upgrade its >> > runtime >> > > environment for just one extension. >> > > >> > > One option is to rewrite the extension against the oldest >> > required CDI >> > > version (generally 1.0 as a lot of people still use that version >> > as part of >> > > Java EE 6) by working around lacking functionalities from the CDI >> > SPI at the >> > > cost of code readability or even removed features that are >> > impossible to >> > > re-implement. >> > > >> > > To avoid that, it is obviously possible to create a separate >> > branch / module >> > > dedicated to porting the extension to the oldest possible CDI >> > version, but >> > > then comes the packaging / distribution problem: >> > > - You assign different versions to the branches, unfortunately >> > that does >> > > not work for projects that include their own CDI extension into >> > the same >> > > codeline (like Apache Camel, JBoss Infinispan, ?) as it doesn?t >> > make sense >> > > to impact the whole project versioning for one possible container >> > / runtime >> > > among others possible, >> > > - Or you create two artifacts / modules whose name (or >> > classifier) somehow >> > > contains the CDI compatible version. >> > > >> > > That?s not very ideal either, and in any case, that?s the end >> > user burden to >> > > make the decision which artifact to choose from a list that will >> > grow over >> > > time with CDI 2.0 and future CDI versions. >> > > >> > > Which leads to my point... As there exists a way to add / veto >> > annotated >> > > types and beans programmatically, one solution that will help >> > addressing the >> > > above problems, both for the extension developers and users, >> > would be to >> > > have the ability to add / veto extensions dynamically. That way, >> > multiple >> > > version / part of the extension could be packaged into a single >> > artifact and >> > > activated dynamically during the application initialisation phase >> > based on >> > > some runtime criteria, in my use case the CDI environment >> > version. The point >> > > here is not to discuss potential implementations, but we could >> > imagine >> > > having an AfterExtensionDiscovery of BeforeTypeDiscovery >> > lifecycle event >> > > from which adding or vetoing extensions would be possible, or >> some >> > > mechanisms in the beans.xml file to include / exclude an >> extension... >> > > >> > > So before discussing implementation details, I?d like your >> > opinion on that >> > > use case, whether it?s valid or other options exist. >> > > >> > > Thanks, >> > > Antonin >> > > >> > > _______________________________________________ >> > > cdi-dev mailing list >> > > cdi-dev at 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 at 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 at 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. >> > >> >> -- >> Martin Kouba >> Software Engineer >> Red Hat, Czech Republic >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at 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. >> > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter > | LinkedIn > | Pluralsight > | Paris > JUG | Devoxx France > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151002/4eb9dac2/attachment-0001.html From andraschko.thomas at gmail.com Fri Oct 2 05:05:23 2015 From: andraschko.thomas at gmail.com (Thomas Andraschko) Date: Fri, 2 Oct 2015 11:05:23 +0200 Subject: [cdi-dev] Adding / vetoing CDI extensions programmatically In-Reply-To: References: <808F2CC8-2687-4A3E-ABA4-2C62A8D8E6BF@stefanutti.fr> <560E3958.3030904@redhat.com> Message-ID: a global-beans.xml sounds like good way to add something to the CDI API which is similiar to DeltaSpike global alternatives! 2015-10-02 10:54 GMT+02:00 Antoine Sabot-Durand : > I think the idea of a global configuration, either in a global-beans.xml, > either in the code ((ProcessExtensions or AfterExtensionDiscovery ;)) is an > interesting topic. > > Now this doesn't solve the problem for existing version : no obvious way > to remove a 2.0 extension in 1.2 code... > > Antoine > > Le ven. 2 oct. 2015 ? 10:32, Antonio Goncalves < > antonio.goncalves at gmail.com> a ?crit : > >> BTW during the F2F meeting we discussed the idea of having a "global" >> beans.xml (the same idea behind web.xml and web-fragment.xml). So the idea >> is to be able to include/exclude globally. >> >> Antonio >> >> On Fri, Oct 2, 2015 at 9:59 AM, Martin Kouba wrote: >> >>> Dne 1.10.2015 v 22:55 Romain Manni-Bucau napsal(a): >>> > Interesting, couldn't excludes supports it? when processing extensions >>> > we have the beans.xml model so extensions could be filtered this way, >>> no? >>> >>> No. beans.xml excludes are local (i.e. per bean archive). Extensions are >>> global - per application. >>> >>> > >>> > >>> > Romain Manni-Bucau >>> > @rmannibucau | Blog >>> > | Github >>> > | LinkedIn >>> > | Tomitriber >>> > >>> > >>> > 2015-10-01 13:44 GMT-07:00 arjan tijms >> > >: >>> > >>> > There's an existing issue for this: >>> > https://issues.jboss.org/browse/CDI-157 >>> > >>> > The JSF EG is also really interested in this, for >>> > https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1361 and >>> > several other things. >>> > >>> > Kind regards, >>> > Arjan Tijms >>> > >>> > >>> > On Thu, Oct 1, 2015 at 6:30 PM, Antonin Stefanutti >>> > > wrote: >>> > > Hi CDI mates, >>> > > >>> > > I?ve been developing a couple of CDI extensions over the last >>> > couple of >>> > > years and been facing this recurrent situation: >>> > > - I develop the extension against the latest CDI release version >>> > (1.2 for >>> > > the time being), >>> > > - As the extension gets used, comes the requests to run the >>> > extension in >>> > > previous CDI versions, >>> > > - As any real-world extensions heavily rely on the CDI SPI, they >>> > never >>> > > happen to be backward-compatible, >>> > > - And that?s understandable that the end-users won?t upgrade its >>> > runtime >>> > > environment for just one extension. >>> > > >>> > > One option is to rewrite the extension against the oldest >>> > required CDI >>> > > version (generally 1.0 as a lot of people still use that version >>> > as part of >>> > > Java EE 6) by working around lacking functionalities from the >>> CDI >>> > SPI at the >>> > > cost of code readability or even removed features that are >>> > impossible to >>> > > re-implement. >>> > > >>> > > To avoid that, it is obviously possible to create a separate >>> > branch / module >>> > > dedicated to porting the extension to the oldest possible CDI >>> > version, but >>> > > then comes the packaging / distribution problem: >>> > > - You assign different versions to the branches, unfortunately >>> > that does >>> > > not work for projects that include their own CDI extension into >>> > the same >>> > > codeline (like Apache Camel, JBoss Infinispan, ?) as it doesn?t >>> > make sense >>> > > to impact the whole project versioning for one possible >>> container >>> > / runtime >>> > > among others possible, >>> > > - Or you create two artifacts / modules whose name (or >>> > classifier) somehow >>> > > contains the CDI compatible version. >>> > > >>> > > That?s not very ideal either, and in any case, that?s the end >>> > user burden to >>> > > make the decision which artifact to choose from a list that will >>> > grow over >>> > > time with CDI 2.0 and future CDI versions. >>> > > >>> > > Which leads to my point... As there exists a way to add / veto >>> > annotated >>> > > types and beans programmatically, one solution that will help >>> > addressing the >>> > > above problems, both for the extension developers and users, >>> > would be to >>> > > have the ability to add / veto extensions dynamically. That way, >>> > multiple >>> > > version / part of the extension could be packaged into a single >>> > artifact and >>> > > activated dynamically during the application initialisation >>> phase >>> > based on >>> > > some runtime criteria, in my use case the CDI environment >>> > version. The point >>> > > here is not to discuss potential implementations, but we could >>> > imagine >>> > > having an AfterExtensionDiscovery of BeforeTypeDiscovery >>> > lifecycle event >>> > > from which adding or vetoing extensions would be possible, or >>> some >>> > > mechanisms in the beans.xml file to include / exclude an >>> extension... >>> > > >>> > > So before discussing implementation details, I?d like your >>> > opinion on that >>> > > use case, whether it?s valid or other options exist. >>> > > >>> > > Thanks, >>> > > Antonin >>> > > >>> > > _______________________________________________ >>> > > cdi-dev mailing list >>> > > cdi-dev at 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 at 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 at 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. >>> > >>> >>> -- >>> Martin Kouba >>> Software Engineer >>> Red Hat, Czech Republic >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at 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. >>> >> >> >> >> -- >> Antonio Goncalves >> Software architect, Java Champion and Pluralsight author >> >> Web site | Twitter >> | LinkedIn >> | Pluralsight >> | Paris >> JUG | Devoxx France >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151002/484cf0d7/attachment.html From antonin at stefanutti.fr Fri Oct 2 05:20:53 2015 From: antonin at stefanutti.fr (Antonin Stefanutti) Date: Fri, 2 Oct 2015 09:20:53 +0000 Subject: [cdi-dev] Adding / vetoing CDI extensions programmatically In-Reply-To: References: <808F2CC8-2687-4A3E-ABA4-2C62A8D8E6BF@stefanutti.fr> <560E3958.3030904@redhat.com> Message-ID: On 02 Oct 2015, at 10:54, Antoine Sabot-Durand > wrote: Now this doesn't solve the problem for existing version : no obvious way to remove a 2.0 extension in 1.2 code? I thought about that too and, in my use case at least, that would be fine if: - Extension for CDI version < 2.0 use the default service provider mechanism, - Extension for CDI version >= 2.0 does not use the service provider mechanism, - In CDI runtime version >= 2.0 the old version is deactivated programatically while the new version is added programmatically. On 01 Oct 2015, at 21:15, Mark Struberg > wrote: You might look at DeltaSpikes ?Deactivatable? Thanks. I?d be very interested in what mechanism is used to prevent the container from loading the extension? On 01 Oct 2015, at 22:44, arjan tijms > wrote: There's an existing issue for this: https://issues.jboss.org/browse/CDI-157 Thanks. Looks like this is a generic need, though pretty advanced. We?ll be able to track the outcome of this discussion in that ticket then. Antonin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151002/58ef3ed1/attachment-0001.html From antoine at sabot-durand.net Fri Oct 2 05:25:36 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 02 Oct 2015 09:25:36 +0000 Subject: [cdi-dev] Adding / vetoing CDI extensions programmatically In-Reply-To: References: <808F2CC8-2687-4A3E-ABA4-2C62A8D8E6BF@stefanutti.fr> <560E3958.3030904@redhat.com> Message-ID: There's a solution at implementation level. Since extension developed for 1.2 contains unknown classes in 1.0, the impl could catch the "class not found" exception on an extension send a warning to user and don't use the extension. In other way instead of letting the app crash, manage the crash by ignoring the extension. Antoine Le ven. 2 oct. 2015 ? 11:20, Antonin Stefanutti a ?crit : > > On 02 Oct 2015, at 10:54, Antoine Sabot-Durand > wrote: > > Now this doesn't solve the problem for existing version : no obvious way > to remove a 2.0 extension in 1.2 code? > > > I thought about that too and, in my use case at least, that would be fine > if: > - Extension for CDI version < 2.0 use the default service provider > mechanism, > - Extension for CDI version >= 2.0 does not use the service provider > mechanism, > - In CDI runtime version >= 2.0 the old version is deactivated > programatically while the new version is added programmatically. > > On 01 Oct 2015, at 21:15, Mark Struberg wrote: > > You might look at DeltaSpikes ?Deactivatable? > > > Thanks. I?d be very interested in what mechanism is used to prevent the > container from loading the extension? > > On 01 Oct 2015, at 22:44, arjan tijms wrote: > > There's an existing issue for this: > https://issues.jboss.org/browse/CDI-157 > > > Thanks. Looks like this is a generic need, though pretty advanced. We?ll > be able to track the outcome of this discussion in that ticket then. > > Antonin > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151002/2633e9e6/attachment.html From antonin at stefanutti.fr Fri Oct 2 05:41:36 2015 From: antonin at stefanutti.fr (Antonin Stefanutti) Date: Fri, 2 Oct 2015 09:41:36 +0000 Subject: [cdi-dev] Adding / vetoing CDI extensions programmatically In-Reply-To: References: <808F2CC8-2687-4A3E-ABA4-2C62A8D8E6BF@stefanutti.fr> <560E3958.3030904@redhat.com> Message-ID: > On 02 Oct 2015, at 11:25, Antoine Sabot-Durand wrote: > > There's a solution at implementation level. Since extension developed for 1.2 contains unknown classes in 1.0, the impl could catch the "class not found" exception on an extension send a warning to user and don't use the extension. In other way instead of letting the app crash, manage the crash by ignoring the extension. Indeed. Before 2.0 (considering that feature is available), relying on a solution at implementation level would be the only solution. But that would require back-porting that solution to older versions of the implementations, since that is the original requirement. In my specific use case, I can have a CDI 1.0 and CDI 2.0 extensions so spec level / end-user solution would work. It?s preferable if possible that the compatibility knowledge be captured functionally rather than relying on an exception mechanism. From struberg at yahoo.de Fri Oct 2 09:10:47 2015 From: struberg at yahoo.de (Mark Struberg) Date: Fri, 2 Oct 2015 15:10:47 +0200 Subject: [cdi-dev] Adding / vetoing CDI extensions programmatically In-Reply-To: References: <808F2CC8-2687-4A3E-ABA4-2C62A8D8E6BF@stefanutti.fr> <560E3958.3030904@redhat.com> Message-ID: We already discussed in that direction a long time ago. Check the comments in https://issues.jboss.org/browse/CDI-18. The idea was to ?merge? info in beans.xml where information with a higher ?ordinal? (importance) overwrite information from a beans.xml with lower priority. But we didn?t end up going in this direction yet but instead went with having @Priority on each and every class. LieGrue, strub > Am 02.10.2015 um 10:31 schrieb Antonio Goncalves : > > BTW during the F2F meeting we discussed the idea of having a "global" beans.xml (the same idea behind web.xml and web-fragment.xml). So the idea is to be able to include/exclude globally. > > Antonio > > On Fri, Oct 2, 2015 at 9:59 AM, Martin Kouba wrote: > Dne 1.10.2015 v 22:55 Romain Manni-Bucau napsal(a): > > Interesting, couldn't excludes supports it? when processing extensions > > we have the beans.xml model so extensions could be filtered this way, no? > > No. beans.xml excludes are local (i.e. per bean archive). Extensions are > global - per application. > > > > > > > Romain Manni-Bucau > > @rmannibucau | Blog > > | Github > > | LinkedIn > > | Tomitriber > > > > > > 2015-10-01 13:44 GMT-07:00 arjan tijms > >: > > > > There's an existing issue for this: > > https://issues.jboss.org/browse/CDI-157 > > > > The JSF EG is also really interested in this, for > > https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1361 and > > several other things. > > > > Kind regards, > > Arjan Tijms > > > > > > On Thu, Oct 1, 2015 at 6:30 PM, Antonin Stefanutti > > > wrote: > > > Hi CDI mates, > > > > > > I?ve been developing a couple of CDI extensions over the last > > couple of > > > years and been facing this recurrent situation: > > > - I develop the extension against the latest CDI release version > > (1.2 for > > > the time being), > > > - As the extension gets used, comes the requests to run the > > extension in > > > previous CDI versions, > > > - As any real-world extensions heavily rely on the CDI SPI, they > > never > > > happen to be backward-compatible, > > > - And that?s understandable that the end-users won?t upgrade its > > runtime > > > environment for just one extension. > > > > > > One option is to rewrite the extension against the oldest > > required CDI > > > version (generally 1.0 as a lot of people still use that version > > as part of > > > Java EE 6) by working around lacking functionalities from the CDI > > SPI at the > > > cost of code readability or even removed features that are > > impossible to > > > re-implement. > > > > > > To avoid that, it is obviously possible to create a separate > > branch / module > > > dedicated to porting the extension to the oldest possible CDI > > version, but > > > then comes the packaging / distribution problem: > > > - You assign different versions to the branches, unfortunately > > that does > > > not work for projects that include their own CDI extension into > > the same > > > codeline (like Apache Camel, JBoss Infinispan, ?) as it doesn?t > > make sense > > > to impact the whole project versioning for one possible container > > / runtime > > > among others possible, > > > - Or you create two artifacts / modules whose name (or > > classifier) somehow > > > contains the CDI compatible version. > > > > > > That?s not very ideal either, and in any case, that?s the end > > user burden to > > > make the decision which artifact to choose from a list that will > > grow over > > > time with CDI 2.0 and future CDI versions. > > > > > > Which leads to my point... As there exists a way to add / veto > > annotated > > > types and beans programmatically, one solution that will help > > addressing the > > > above problems, both for the extension developers and users, > > would be to > > > have the ability to add / veto extensions dynamically. That way, > > multiple > > > version / part of the extension could be packaged into a single > > artifact and > > > activated dynamically during the application initialisation phase > > based on > > > some runtime criteria, in my use case the CDI environment > > version. The point > > > here is not to discuss potential implementations, but we could > > imagine > > > having an AfterExtensionDiscovery of BeforeTypeDiscovery > > lifecycle event > > > from which adding or vetoing extensions would be possible, or some > > > mechanisms in the beans.xml file to include / exclude an extension... > > > > > > So before discussing implementation details, I?d like your > > opinion on that > > > use case, whether it?s valid or other options exist. > > > > > > Thanks, > > > Antonin > > > > > > _______________________________________________ > > > cdi-dev mailing list > > > cdi-dev at 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 at 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 at 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. > > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. From issues at jboss.org Mon Oct 5 10:23:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 5 Oct 2015 10:23:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-458) Give the possibility to deactivate an observer in ProcessObserverMethod In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-458: ---------------------------------------- Assignee: Antoine Sabot-Durand > Give the possibility to deactivate an observer in ProcessObserverMethod > ----------------------------------------------------------------------- > > Key: CDI-458 > URL: https://issues.jboss.org/browse/CDI-458 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events, Portable Extensions > Affects Versions: 1.2.Final > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0 (proposed) > > > Today if a user want to deactivate an observer at deployment time, she needs to observes {{ProcessAnnotatedType}} with {{@WithAnnotation(Observes.class)}} and replace the annotatedType by a new one without the {{@Observes}} annotation. It's quite heavy to manage. > We could add a {{veto()}} method in {{ProcessObserverMethod}} to do this in a far easier and intuitive way. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 5 10:25:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 5 Oct 2015 10:25:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-458) Give the possibility to deactivate an observer in ProcessObserverMethod In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-458 started by Antoine Sabot-Durand. ------------------------------------------------ > Give the possibility to deactivate an observer in ProcessObserverMethod > ----------------------------------------------------------------------- > > Key: CDI-458 > URL: https://issues.jboss.org/browse/CDI-458 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events, Portable Extensions > Affects Versions: 1.2.Final > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0 (proposed) > > > Today if a user want to deactivate an observer at deployment time, she needs to observes {{ProcessAnnotatedType}} with {{@WithAnnotation(Observes.class)}} and replace the annotatedType by a new one without the {{@Observes}} annotation. It's quite heavy to manage. > We could add a {{veto()}} method in {{ProcessObserverMethod}} to do this in a far easier and intuitive way. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 5 12:00:01 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 5 Oct 2015 12:00:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-559) typo on page 113 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-559: ---------------------------------------- Assignee: Antoine Sabot-Durand > typo on page 113 > ---------------- > > Key: CDI-559 > URL: https://issues.jboss.org/browse/CDI-559 > Project: CDI Specification Issues > Issue Type: Bug > Components: Events > Affects Versions: 2.0-EDR1 > Environment: n/a > Reporter: Emily Jiang > Assignee: Antoine Sabot-Durand > Priority: Trivial > Fix For: 2.0-EDR2 > > > On CDI 2.0 spec page 113 > @javax.enterprise.event.ObservesAsync+`should be @javax.enterprise.event.ObservesAsync in bold -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 5 12:00:01 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 5 Oct 2015 12:00:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-559) typo on page 113 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-559. -------------------------------------- Fix Version/s: 2.0-EDR2 Resolution: Done > typo on page 113 > ---------------- > > Key: CDI-559 > URL: https://issues.jboss.org/browse/CDI-559 > Project: CDI Specification Issues > Issue Type: Bug > Components: Events > Affects Versions: 2.0-EDR1 > Environment: n/a > Reporter: Emily Jiang > Assignee: Antoine Sabot-Durand > Priority: Trivial > Fix For: 2.0-EDR2 > > > On CDI 2.0 spec page 113 > @javax.enterprise.event.ObservesAsync+`should be @javax.enterprise.event.ObservesAsync in bold -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 5 12:27:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 5 Oct 2015 12:27:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-564) Async events simplification ad clarification In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-564: ---------------------------------------- Summary: 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 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) From issues at jboss.org Mon Oct 5 12:29:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 5 Oct 2015 12:29:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-564) Async events simplification ad clarification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] 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) From issues at jboss.org Mon Oct 5 12:42:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 5 Oct 2015 12:42:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-564) Async events simplification ad clarification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] 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) From issues at jboss.org Mon Oct 5 12:43:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 5 Oct 2015 12:43:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-564) Async events simplification and clarification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] 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) From issues at jboss.org Mon Oct 5 12:47:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 5 Oct 2015 12:47:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-564) Async events simplification and clarification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] 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) From issues at jboss.org Tue Oct 6 02:52:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 6 Oct 2015 02:52:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-564) Async events simplification and clarification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13115263#comment-13115263 ] 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) From antoine at sabot-durand.net Tue Oct 6 03:43:10 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 06 Oct 2015 07:43:10 +0000 Subject: [cdi-dev] Next meeting on October 20th Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151006/904f85ab/attachment.html From issues at jboss.org Tue Oct 6 09:22:00 2015 From: issues at jboss.org (Vsevolod Golovanov (JIRA)) Date: Tue, 6 Oct 2015 09:22:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-51) Support static injection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13115456#comment-13115456 ] 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/Weld/DependencyInjectionWishlist > 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) From issues at jboss.org Tue Oct 6 09:50:00 2015 From: issues at jboss.org (Martin Andersson (JIRA)) Date: Tue, 6 Oct 2015 09:50:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-565) Unsatisfied dependency should be null? In-Reply-To: References: Message-ID: 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) From issues at jboss.org Tue Oct 6 09:53:00 2015 From: issues at jboss.org (Thomas Andraschko (JIRA)) Date: Tue, 6 Oct 2015 09:53:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-565) Unsatisfied dependency should be null? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13115472#comment-13115472 ] 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) From issues at jboss.org Tue Oct 6 10:25:01 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 6 Oct 2015 10:25:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-565) Unsatisfied dependency should be null? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13115510#comment-13115510 ] 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 collaborator; public void someMethod() { if (collaborator.isResolvable()) { collaborator.get().ping(); } } } {code} Right now, you would have to use: {code:java} class MyComponent { @Inject Instance 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) From issues at jboss.org Tue Oct 6 11:05:01 2015 From: issues at jboss.org (Thomas Andraschko (JIRA)) Date: Tue, 6 Oct 2015 11:05:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-565) Unsatisfied dependency should be null? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13115540#comment-13115540 ] Thomas Andraschko commented on CDI-565: --------------------------------------- Yeah, thats a possible way but via something like @Optional, it would be MUCH EASIER for the enduser! > 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) From issues at jboss.org Tue Oct 6 11:34:00 2015 From: issues at jboss.org (Martin Andersson (JIRA)) Date: Tue, 6 Oct 2015 11:34:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-565) Unsatisfied dependency should be null? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13115572#comment-13115572 ] Martin Andersson commented on CDI-565: -------------------------------------- erm, now that I think of it. Changing the behavior such that {{null}} is injected instead of having the deployment crash isn't breaking backward compatibility. All old applications deployed has obviously resolved all their unsatisfied dependencies, right? Question is what type of behavior do we want to see for future applications (deployments)? I have talked to several Java developers at this point. They all agree with my comments made about {{null}} earlier. The most intuitive thing is to inject {{null}}, leaving the application a fair chance to actually manage this situation which provingly, is a good feature to have from time to time without complex workarounds using "guru" API:s like {{Instance}}. To turn things around, which issue are we trying to solve, or how exactly are we trying to "help" developers by failing the deployment for unsatisfied dependencies? I can only see the down sides of this behavior. If we know what's right, then as men (and women for some of us!), we are obliged to do the right thing without paying attention to the "fear of change". I cannot stress enough that Java EE is a complex technology stack and if we are to stand a chance in a competitive environment, we have to stop looking for quick fixes and workarounds. Isn't it possible to cast a vote on the JBoss forum or something, asking people that don't already know the answer, what they think should happen to an unsatisfied dependency? That is what I asked my developers. All but one new guy said {{null}}. > 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) From issues at jboss.org Tue Oct 6 11:45:01 2015 From: issues at jboss.org (Martin Andersson (JIRA)) Date: Tue, 6 Oct 2015 11:45:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-565) Unsatisfied dependency should be null? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13115580#comment-13115580 ] Martin Andersson commented on CDI-565: -------------------------------------- What do we expect to happen here: {code} Person person = new Person(); String name = person.getName(); {code} Yeah, only a problem if we try to dereference the name! =) CDI is one huge "getter". No difference. Most if not all getter methods we write every day return {{null}} and let the client deal with it. If the client require a value and rather have his application blow up with a more specialized exception, then he probably call a more niche method: {code} String name = person.requireName(); {code} I.e, here's what I believe we should do if and only if we want the deployment to fail: {code} @Inject @Required String name; {code} Or maybe even more straight forward: {code} @Inject @DeploymentRequired String name; {code} This way, we can even configure a bit how we want the deployment to fail: {code} @Inject @Required(throwClass=MySuperAwesomeException.class) String name; {code} This "issue" really comes down to what we think is the most intuitive behavior and, whether or not it really brake backward compatbility and if so, how bad would that actually be. I believe 1) {{null}} is the most intuitive thing to do here and it is a good thing leaving the application to deal with it. 2) We don't brake backward compatibility at all. Let me know what you think. > 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) From issues at jboss.org Wed Oct 7 02:51:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 7 Oct 2015 02:51:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-565) Unsatisfied dependency should be null? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13115740#comment-13115740 ] Martin Kouba commented on CDI-565: ---------------------------------- Ok, there is a lot of discussions about {{null}} and its usefulness. Some people even think it's a bad practice and that's why {{com.google.common.base.Optional}} and friends exist. But that's not the point here. I think the validation of dependencies during deployment (and fail fast) is a great feature which helps most of the developers most of the time (mostly to avoid surprising NPEs in the runtime). In other words, having an unsatisfied dependency which is OK is not a typical use case. It's more like an exception or corner case. And that's why "simple" {{Instance}} API exists. > 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) From issues at jboss.org Wed Oct 7 08:22:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 7 Oct 2015 08:22:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-566) Container lifecycle events and context initialization events are synchronous In-Reply-To: References: Message-ID: Martin Kouba created CDI-566: -------------------------------- Summary: Container lifecycle events and context initialization events are synchronous Key: CDI-566 URL: https://issues.jboss.org/browse/CDI-566 Project: CDI Specification Issues Issue Type: Clarification Components: Events Reporter: Martin Kouba I believe this should be more explicit. Also portable extensions should be encouraged to fire sync events when a custom context is initialized, see also 6.7. Context management for built-in scopes. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 7 08:22:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 7 Oct 2015 08:22:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-566) Container lifecycle events and context initialization events are synchronous In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-566: ----------------------------- Affects Version/s: 2.0-EDR1 > Container lifecycle events and context initialization events are synchronous > ---------------------------------------------------------------------------- > > Key: CDI-566 > URL: https://issues.jboss.org/browse/CDI-566 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Martin Kouba > > I believe this should be more explicit. Also portable extensions should be encouraged to fire sync events when a custom context is initialized, see also 6.7. Context management for built-in scopes. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 7 09:38:00 2015 From: issues at jboss.org (Martin Andersson (JIRA)) Date: Wed, 7 Oct 2015 09:38:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-565) Unsatisfied dependency should be null? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13115971#comment-13115971 ] Martin Andersson commented on CDI-565: -------------------------------------- Or {{java.util.Optional}} since JDK 8. Yeah, I think we all agree that the ideal world make a minimal use of {{null}}. But I sure don't think we can ever manage without {{null}}. In fact, {{null}} has some really good use cases. What would you think if {{Map.get(Object)}} threw an exception instead of returning {{null}} when the mapping doesn't exist? Well, the CDI container is one huge map. I ask for a mapped value given a set of types and/or qualifiers - the keys. What is the difference? Even if you do think {{null}} is absolute evil, then it is with us already for better or worse. Convenience, or what we together believe is the most intuitive approach, has to take precedence. Fail-fast is a good practice, but having it implemented just because one can may be a brutal way of enforcing dogma upon others. I see this "fail-fast" approach as both braking intuition and reducing the service offer. I'm not saying I am right. I am trying to find out why some of us developers has to pay the price, for what benefit, for what gain? You say it "helps developers" by "avoiding surprising NPE:s at runtime". All exceptions not handled is a surprise, whether that happens during deployment or runtime. But let me point out that if anything is a surprise, then it is the exception types CDI define and all vendor-specific messages the application servers output in the log file, and you know I am right on this point. New developers in particular will have to walk though a lot of struggles until they have a solid understanding of the CDI vocabulary like "ambiguous" and "unsatisified". Compare that with a a {{java.lang.NullPointerException}} in the log file with a clear stack trace to the exact source code line where the reference was dereferenced. What a NPE is and how to deal with it is probably what all new developers learn on their very first day. Non-developers like to praise programmers as being some kind of super humans. What I often find myself saying in response to my friends, and experiences I think you share with me, is that I am lazy. I am not really a problem solver. I am not really smart. I'm trying to find the best architecture such that the design can do the thinking for me. I am trying to reduce complexity, trying to simplify and automate everything. Most importantly, I will not try to fix a problem before I have one. And that is super important. By trying to fix a problem before I have it, I might end up introducing one instead. Been there done that many times over. Recognize the situation? That's why we are having this discussion. "Premature optimization is the root of all evil" and ya'll know it =) Least you can do is {{@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) From issues at jboss.org Wed Oct 7 11:41:00 2015 From: issues at jboss.org (Sven Linstaedt (JIRA)) Date: Wed, 7 Oct 2015 11:41:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-565) Unsatisfied dependency should be null? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13116084#comment-13116084 ] Sven Linstaedt commented on CDI-565: ------------------------------------ Though this suggestion might not break backward compability with regards to runtime, it would break with the existing expectations of CDI users. Currently CDI implementations assert injection point validation during startup. Dropping this behavior will possible introduce some nice NPE in the future. I was not aware there is a part of the java community advocating in favor of null values as part of api contracts, as modern typed languages i know of managed to avoid NPEs at all. Long story short: +1 for extending either {{Provider}} or {{Instance}}. > 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) From issues at jboss.org Wed Oct 7 11:42:00 2015 From: issues at jboss.org (Sven Linstaedt (JIRA)) Date: Wed, 7 Oct 2015 11:42:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-565) Unsatisfied dependency should be null? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13116084#comment-13116084 ] Sven Linstaedt edited comment on CDI-565 at 10/7/15 11:41 AM: -------------------------------------------------------------- Though this suggestion might not break backward compability with regards to runtime, it would break with the existing expectations of CDI users. Currently CDI implementations assert injection point validation during startup. Dropping this behavior will possible introduce some nice NPE in the future. I was not aware there is a part of the java community advocating in favor of null values as part of api contracts, as modern typed languages i know of managed to handle nullable types different than java to avoid NPEs at all. Long story short: +1 for extending either {{Provider}} or {{Instance}}. was (Author: tzwoenn): Though this suggestion might not break backward compability with regards to runtime, it would break with the existing expectations of CDI users. Currently CDI implementations assert injection point validation during startup. Dropping this behavior will possible introduce some nice NPE in the future. I was not aware there is a part of the java community advocating in favor of null values as part of api contracts, as modern typed languages i know of managed to avoid NPEs at all. Long story short: +1 for extending either {{Provider}} or {{Instance}}. > 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) From issues at jboss.org Wed Oct 7 17:10:00 2015 From: issues at jboss.org (Martin Andersson (JIRA)) Date: Wed, 7 Oct 2015 17:10:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-565) Unsatisfied dependency should be null? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13116194#comment-13116194 ] Martin Andersson commented on CDI-565: -------------------------------------- I'm not sure I fully understood you on that "dropping behavior"-thing. NPE:s is kind of what I try to advertise here =) {{null}} is and will always be a valid candidate to represent the absence, or lack of, a value. *YES*, we all agree that it is easy to misuse {{null}} and {{null}} should be avoided if we so can. My point is definitely not that {{null}} is a god sent gift. Please reread my comments and see if you can answer the questions I asked, for example, what is the difference between {{Map}} and the CDI container (when it comes to dependency lookup)? Also compare {{EntityManager.find()}} from the JPA specification which I believe is another comparable interface. Everything is an API. I don't understand this notion really or how it relates to the topic of discussion. I googled the CDI specification, {{null}} return values are used everywhere. Would you like to advocate that we setup tens of new exception types into our type system instead? Speaking of API:s, I would appreciate an {{Optional}} return type from a service only if it is conceivable and often enough the case that no return value is present. For example: {{tryCatchAFish()}}, {{getLotteryWinner()}}. Or, if it is conceivably so that the client doesn't bother about the presence of the value, he's sole intent is to pass it around somewhere. For example: {{myDataSource.getSomeData().ifPresent(someValueContainer::setThatField)}}. I myself overused {{Optional}} once it was out in JDK 8, singing praise to Jesus every minute of the day. Only to discover that my overuse of it introduced complex boilerplate code. Eventually I got so lazy that I dereferenced those optionals anyway ({{Optional.get().doSomething()}} and so it was only a matter of time before I found myself back in square one. But this time, not only did I have NPE:s, all my clients had to make an extra method call all over the place for no apparent gain. More than anything else, I learnt by my own mistake that if a parameter is optional for the client, then accept {{null}}. Don't force the clients to type {{Optional.empty()}} instead of the oh so simple blueish keyword {{null}}. Null as parameters make the life easier for the implementations too. Also, if you know a "modern language" that had any success avoiding {{null}}, please let me know. That would be interesting. For example, how would I create a new 10 element array? Am I required to have all ten elements right of the bat? Guys, what is the most intuitive thing to do here? Why do you believe that the dependency lookup should have different semantics than {{Map.get()}}? > 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) From issues at jboss.org Wed Oct 7 17:12:00 2015 From: issues at jboss.org (Martin Andersson (JIRA)) Date: Wed, 7 Oct 2015 17:12:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-565) Unsatisfied dependency should be null? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13116194#comment-13116194 ] Martin Andersson edited comment on CDI-565 at 10/7/15 5:11 PM: --------------------------------------------------------------- I'm not sure I fully understood you on that "dropping behavior"-thing. NPE:s is kind of what I try to advertise here =) {{null}} is and will always be a valid candidate to represent the absence, or lack of, a value. *YES*, we all agree that it is easy to misuse {{null}} and {{null}} should be avoided if we so can. My point is definitely not that {{null}} is a god sent gift. Please reread my comments and see if you can answer the questions I asked, for example, what is the difference between {{Map}} and the CDI container (when it comes to dependency lookup)? Also compare {{EntityManager.find()}} from the JPA specification which I believe is another comparable interface. Everything is an API. I don't understand this notion really or how it relates to the topic of discussion. I googled the CDI specification, {{null}} return values are used everywhere. Would you like to advocate that we setup tens of new exception types into our type system instead? Speaking of API:s, I would appreciate an {{Optional}} return type from a service only if it is conceivable and often enough the case that no return value is present. For example: {{tryCatchAFish()}}, {{getLotteryWinner()}}. Or, if it is conceivably so that the client doesn't bother about the presence of the value. For example: {{myDataSource.getSomeData().ifPresent(someValueContainer::setThatField)}}. I myself overused {{Optional}} once it was out in JDK 8, singing praise to Jesus every minute of the day. Only to discover that my overuse of it introduced complex boilerplate code. Eventually I got so lazy that I dereferenced those optionals anyway ({{Optional.get().doSomething()}} and so it was only a matter of time before I found myself back in square one. But this time, not only did I have NPE:s, all my clients had to make an extra method call all over the place for no apparent gain. More than anything else, I learnt by my own mistake that if a parameter is optional for the client, then accept {{null}}. Don't force the clients to type {{Optional.empty()}} instead of the oh so simple blueish keyword {{null}}. Null as parameters make the life easier for the implementations too. Also, if you know a "modern language" that had any success avoiding {{null}}, please let me know. That would be interesting. For example, how would I create a new 10 element array? Am I required to have all ten elements right of the bat? Guys, what is the most intuitive thing to do here? Why do you believe that the dependency lookup should have different semantics than {{Map.get()}}? was (Author: martin.andersson): I'm not sure I fully understood you on that "dropping behavior"-thing. NPE:s is kind of what I try to advertise here =) {{null}} is and will always be a valid candidate to represent the absence, or lack of, a value. *YES*, we all agree that it is easy to misuse {{null}} and {{null}} should be avoided if we so can. My point is definitely not that {{null}} is a god sent gift. Please reread my comments and see if you can answer the questions I asked, for example, what is the difference between {{Map}} and the CDI container (when it comes to dependency lookup)? Also compare {{EntityManager.find()}} from the JPA specification which I believe is another comparable interface. Everything is an API. I don't understand this notion really or how it relates to the topic of discussion. I googled the CDI specification, {{null}} return values are used everywhere. Would you like to advocate that we setup tens of new exception types into our type system instead? Speaking of API:s, I would appreciate an {{Optional}} return type from a service only if it is conceivable and often enough the case that no return value is present. For example: {{tryCatchAFish()}}, {{getLotteryWinner()}}. Or, if it is conceivably so that the client doesn't bother about the presence of the value, he's sole intent is to pass it around somewhere. For example: {{myDataSource.getSomeData().ifPresent(someValueContainer::setThatField)}}. I myself overused {{Optional}} once it was out in JDK 8, singing praise to Jesus every minute of the day. Only to discover that my overuse of it introduced complex boilerplate code. Eventually I got so lazy that I dereferenced those optionals anyway ({{Optional.get().doSomething()}} and so it was only a matter of time before I found myself back in square one. But this time, not only did I have NPE:s, all my clients had to make an extra method call all over the place for no apparent gain. More than anything else, I learnt by my own mistake that if a parameter is optional for the client, then accept {{null}}. Don't force the clients to type {{Optional.empty()}} instead of the oh so simple blueish keyword {{null}}. Null as parameters make the life easier for the implementations too. Also, if you know a "modern language" that had any success avoiding {{null}}, please let me know. That would be interesting. For example, how would I create a new 10 element array? Am I required to have all ten elements right of the bat? Guys, what is the most intuitive thing to do here? Why do you believe that the dependency lookup should have different semantics than {{Map.get()}}? > 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) From issues at jboss.org Thu Oct 8 08:38:00 2015 From: issues at jboss.org (Sven Linstaedt (JIRA)) Date: Thu, 8 Oct 2015 08:38:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-565) Unsatisfied dependency should be null? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13116394#comment-13116394 ] Sven Linstaedt commented on CDI-565: ------------------------------------ There are several examples of existing APIs either accepting or returning {{null}} values. The point is one can not simply change their "behavior" (API contract). If one decides for {{java.until.Map#get}} e.g. to throw a NoSuchElementException in case if absent key, one would break the contract that was asserted beforehand. Changing a existing contract is possible, but one should have a good reason for doing so. Optional injection points are from my point of view not worth changing the existing contract for injection point validation during startup. > 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) From issues at jboss.org Fri Oct 9 04:38:00 2015 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Fri, 9 Oct 2015 04:38:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-433) AdminEvent example has redundant qualifiers. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13116779#comment-13116779 ] Tomas Remes commented on CDI-433: --------------------------------- https://github.com/cdi-spec/cdi/pull/260 > AdminEvent example has redundant qualifiers. > -------------------------------------------- > > Key: CDI-433 > URL: https://issues.jboss.org/browse/CDI-433 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: John Ament > Priority: Minor > > In the CDI 1.2 spec, the following text appears: > For example, this injected Event has specified type LoggedInEvent and specified qualifier @Admin: > {{@Inject @Admin Event any;}} > The select() method returns a child Event for a given specified type and additional specified qualifiers. If no specified type is given, the specified type is the same as the parent. > For example, this child Event has required type AdminLoggedInEvent and additional specified qualifier {{@Admin}}: > {noformat} > Event admin = any.select( > AdminLoggedInEvent.class, > new AdminQualifier() ); > {noformat} > The problem is that the injection point any already is qualified @Admin, so the use is duplicate here. I believe the intention was that the injection point would read > {{@Inject Event any;}} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 9 05:03:00 2015 From: issues at jboss.org (Emily Jiang (JIRA)) Date: Fri, 9 Oct 2015 05:03:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-565) Unsatisfied dependency should be null? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13116794#comment-13116794 ] Emily Jiang commented on CDI-565: --------------------------------- +1 for not breaking backward compatibility. Introducing the optional injection forces the end users to check for null, which is boilerplate code in most scenarios and confusing. +1 for using Instance to cater for the optional injection is the right way to go. > 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) From emijiang6 at googlemail.com Fri Oct 9 05:42:54 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Fri, 9 Oct 2015 10:42:54 +0100 Subject: [cdi-dev] HttpSession failover from cdi 1.0 impl to cdi 1.2 impl Message-ID: I am investigating the HttpSession failover for SessionScoped or ConversationScoped beans. I think it is not easy to failover from the CDI 1.0 impl to CDI1.2 impl, as the bean proxies instead of the raw bean was serialised and the proxies are different between cdi 1.0 and cdi 1.2. Has anyone have any thoughts on this? If not possible, this is a big limitation for CDI as EJB container has no such limitation. -- Thanks Emily ================= Emily Jiang ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151009/4e8a7ad3/attachment.html From mkouba at redhat.com Fri Oct 9 06:54:35 2015 From: mkouba at redhat.com (Martin Kouba) Date: Fri, 9 Oct 2015 12:54:35 +0200 Subject: [cdi-dev] HttpSession failover from cdi 1.0 impl to cdi 1.2 impl In-Reply-To: References: Message-ID: <56179CEB.8070201@redhat.com> I wonder whether this behavior is defined somewhere, i.e. if all EJB implementations must support "failover" between minor versions (e.g. EJB 3.0 and 3.2), in other words the passivation mechanism may not change. This would mean that an EJB app might be deployed to a "cluster" of mixed Java EE 6 and Java EE 7 app servers - seems to me like an extremely risky experiment. Martin Dne 9.10.2015 v 11:42 Emily Jiang napsal(a): > I am investigating the HttpSession failover for SessionScoped or > ConversationScoped beans. I think it is not easy to failover from the > CDI 1.0 impl to CDI1.2 impl, as the bean proxies instead of the raw bean > was serialised and the proxies are different between cdi 1.0 and cdi > 1.2. Has anyone have any thoughts on this? If not possible, this is a > big limitation for CDI as EJB container has no such limitation. > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. > -- Martin Kouba Software Engineer Red Hat, Czech Republic From struberg at yahoo.de Fri Oct 9 07:41:27 2015 From: struberg at yahoo.de (Mark Struberg) Date: Fri, 9 Oct 2015 13:41:27 +0200 Subject: [cdi-dev] HttpSession failover from cdi 1.0 impl to cdi 1.2 impl In-Reply-To: References: Message-ID: All the proxy serialisation is totally container specific. This is the same for JPA btw. Clustering only works between two containers of the same kind and sometimes is also even limited to specific versions. Btw, EJB has the same limitations when it comes to NIV? LieGrue, strub > Am 09.10.2015 um 11:42 schrieb Emily Jiang : > > I am investigating the HttpSession failover for SessionScoped or ConversationScoped beans. I think it is not easy to failover from the CDI 1.0 impl to CDI1.2 impl, as the bean proxies instead of the raw bean was serialised and the proxies are different between cdi 1.0 and cdi 1.2. Has anyone have any thoughts on this? If not possible, this is a big limitation for CDI as EJB container has no such limitation. > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. From struberg at yahoo.de Fri Oct 9 07:53:14 2015 From: struberg at yahoo.de (Mark Struberg) Date: Fri, 9 Oct 2015 13:53:14 +0200 Subject: [cdi-dev] HttpSession failover from cdi 1.0 impl to cdi 1.2 impl In-Reply-To: <56179CEB.8070201@redhat.com> References: <56179CEB.8070201@redhat.com> Message-ID: <08B1F21E-CC32-4542-8C05-26533ACA2433@yahoo.de> Wonder the same. I?m 100% sure that it is NOT portable for NIV. Wheras for EJB2 style EJBs it _might_ working due to RMI/IIOP (Though don?t remember whether this was only specified for remoting or also for clustering. Nor do I remember if the spec said anything about clustering at all). I guess there often is ?additional? wrapper stuff handed over in addition to the normal beans for EJB3 style EJBs. I know for sure that we do exactly that in OpenEJB. We have additional wrappers e.g. for transported Exceptions when doing remoting. We hand over the ?string representation? and the original Exception stack data separately. In case we cannot de-serialize the Exception on the other side. Think about sending some OptimisticLockException (or even some internal Hibernate Exception) over to an EJB client which doesn?t have any Hibernate jars and not even the jaa-spec jar on it?s classpath? Similar additional information might be stored in any EJB proxy. Or think about Extended Persistence Contexts. How should that ever work to be serialized between e.g. WildFly and Glassfish? How would you replicate over some Hibernate Exception if the other node is running Glassfish with EclipseLink? :) LieGrue, strub > Am 09.10.2015 um 12:54 schrieb Martin Kouba : > > I wonder whether this behavior is defined somewhere, i.e. if all EJB > implementations must support "failover" between minor versions (e.g. EJB > 3.0 and 3.2), in other words the passivation mechanism may not change. > This would mean that an EJB app might be deployed to a "cluster" of > mixed Java EE 6 and Java EE 7 app servers - seems to me like an > extremely risky experiment. > > Martin > > Dne 9.10.2015 v 11:42 Emily Jiang napsal(a): >> I am investigating the HttpSession failover for SessionScoped or >> ConversationScoped beans. I think it is not easy to failover from the >> CDI 1.0 impl to CDI1.2 impl, as the bean proxies instead of the raw bean >> was serialised and the proxies are different between cdi 1.0 and cdi >> 1.2. Has anyone have any thoughts on this? If not possible, this is a >> big limitation for CDI as EJB container has no such limitation. >> >> -- >> Thanks >> Emily >> ================= >> Emily Jiang >> ejiang at apache.org >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at 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. >> > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. From rmannibucau at gmail.com Fri Oct 9 07:54:56 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Fri, 9 Oct 2015 13:54:56 +0200 Subject: [cdi-dev] HttpSession failover from cdi 1.0 impl to cdi 1.2 impl In-Reply-To: <08B1F21E-CC32-4542-8C05-26533ACA2433@yahoo.de> References: <56179CEB.8070201@redhat.com> <08B1F21E-CC32-4542-8C05-26533ACA2433@yahoo.de> Message-ID: AFAIK nothing portable in EJB spec and cluster features are mentionned but not as explicit as CDI. Back to the original question (CDI ;)): there is nothing in the spec about clustering so this is 100% up to vendors. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-10-09 13:53 GMT+02:00 Mark Struberg : > Wonder the same. I?m 100% sure that it is NOT portable for NIV. Wheras for > EJB2 style EJBs it _might_ working due to RMI/IIOP (Though don?t remember > whether this was only specified for remoting or also for clustering. Nor do > I remember if the spec said anything about clustering at all). > > I guess there often is ?additional? wrapper stuff handed over in addition > to the normal beans for EJB3 style EJBs. I know for sure that we do exactly > that in OpenEJB. We have additional wrappers e.g. for transported > Exceptions when doing remoting. We hand over the ?string representation? > and the original Exception stack data separately. In case we cannot > de-serialize the Exception on the other side. Think about sending some > OptimisticLockException (or even some internal Hibernate Exception) over to > an EJB client which doesn?t have any Hibernate jars and not even the > jaa-spec jar on it?s classpath? Similar additional information might be > stored in any EJB proxy. Or think about Extended Persistence Contexts. How > should that ever work to be serialized between e.g. WildFly and Glassfish? > How would you replicate over some Hibernate Exception if the other node is > running Glassfish with EclipseLink? :) > > LieGrue, > strub > > > > Am 09.10.2015 um 12:54 schrieb Martin Kouba : > > > > I wonder whether this behavior is defined somewhere, i.e. if all EJB > > implementations must support "failover" between minor versions (e.g. EJB > > 3.0 and 3.2), in other words the passivation mechanism may not change. > > This would mean that an EJB app might be deployed to a "cluster" of > > mixed Java EE 6 and Java EE 7 app servers - seems to me like an > > extremely risky experiment. > > > > Martin > > > > Dne 9.10.2015 v 11:42 Emily Jiang napsal(a): > >> I am investigating the HttpSession failover for SessionScoped or > >> ConversationScoped beans. I think it is not easy to failover from the > >> CDI 1.0 impl to CDI1.2 impl, as the bean proxies instead of the raw bean > >> was serialised and the proxies are different between cdi 1.0 and cdi > >> 1.2. Has anyone have any thoughts on this? If not possible, this is a > >> big limitation for CDI as EJB container has no such limitation. > >> > >> -- > >> Thanks > >> Emily > >> ================= > >> Emily Jiang > >> ejiang at apache.org > >> > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at 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. > >> > > > > -- > > Martin Kouba > > Software Engineer > > Red Hat, Czech Republic > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151009/e7a6161c/attachment-0001.html From john.d.ament at gmail.com Fri Oct 9 08:05:37 2015 From: john.d.ament at gmail.com (John D. Ament) Date: Fri, 09 Oct 2015 12:05:37 +0000 Subject: [cdi-dev] HttpSession failover from cdi 1.0 impl to cdi 1.2 impl In-Reply-To: References: <56179CEB.8070201@redhat.com> <08B1F21E-CC32-4542-8C05-26533ACA2433@yahoo.de> Message-ID: Even then, the CDI spec doesn't define any built in session scoped/conversation scoped beans. It would really be up to the app code on how to support this as well between the two containers. On Fri, Oct 9, 2015 at 7:55 AM Romain Manni-Bucau wrote: > AFAIK nothing portable in EJB spec and cluster features are mentionned but > not as explicit as CDI. Back to the original question (CDI ;)): there is > nothing in the spec about clustering so this is 100% up to vendors. > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2015-10-09 13:53 GMT+02:00 Mark Struberg : > >> Wonder the same. I?m 100% sure that it is NOT portable for NIV. Wheras >> for EJB2 style EJBs it _might_ working due to RMI/IIOP (Though don?t >> remember whether this was only specified for remoting or also for >> clustering. Nor do I remember if the spec said anything about clustering at >> all). >> >> I guess there often is ?additional? wrapper stuff handed over in addition >> to the normal beans for EJB3 style EJBs. I know for sure that we do exactly >> that in OpenEJB. We have additional wrappers e.g. for transported >> Exceptions when doing remoting. We hand over the ?string representation? >> and the original Exception stack data separately. In case we cannot >> de-serialize the Exception on the other side. Think about sending some >> OptimisticLockException (or even some internal Hibernate Exception) over to >> an EJB client which doesn?t have any Hibernate jars and not even the >> jaa-spec jar on it?s classpath? Similar additional information might be >> stored in any EJB proxy. Or think about Extended Persistence Contexts. How >> should that ever work to be serialized between e.g. WildFly and Glassfish? >> How would you replicate over some Hibernate Exception if the other node is >> running Glassfish with EclipseLink? :) >> >> LieGrue, >> strub >> >> >> > Am 09.10.2015 um 12:54 schrieb Martin Kouba : >> > >> > I wonder whether this behavior is defined somewhere, i.e. if all EJB >> > implementations must support "failover" between minor versions (e.g. EJB >> > 3.0 and 3.2), in other words the passivation mechanism may not change. >> > This would mean that an EJB app might be deployed to a "cluster" of >> > mixed Java EE 6 and Java EE 7 app servers - seems to me like an >> > extremely risky experiment. >> > >> > Martin >> > >> > Dne 9.10.2015 v 11:42 Emily Jiang napsal(a): >> >> I am investigating the HttpSession failover for SessionScoped or >> >> ConversationScoped beans. I think it is not easy to failover from the >> >> CDI 1.0 impl to CDI1.2 impl, as the bean proxies instead of the raw >> bean >> >> was serialised and the proxies are different between cdi 1.0 and cdi >> >> 1.2. Has anyone have any thoughts on this? If not possible, this is a >> >> big limitation for CDI as EJB container has no such limitation. >> >> >> >> -- >> >> Thanks >> >> Emily >> >> ================= >> >> Emily Jiang >> >> ejiang at apache.org >> >> >> >> >> >> _______________________________________________ >> >> cdi-dev mailing list >> >> cdi-dev at 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. >> >> >> > >> > -- >> > Martin Kouba >> > Software Engineer >> > Red Hat, Czech Republic >> > _______________________________________________ >> > cdi-dev mailing list >> > cdi-dev at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151009/d3400ada/attachment.html From issues at jboss.org Fri Oct 9 09:25:00 2015 From: issues at jboss.org (Martin Andersson (JIRA)) Date: Fri, 9 Oct 2015 09:25:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-565) Unsatisfied dependency should be null? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13116971#comment-13116971 ] Martin Andersson commented on CDI-565: -------------------------------------- Emily, good to have you here. You wrote: {quote} .. optional injection forces the end users to check for null, which is boilerplate code in most scenarios and confusing. {quote} I must say that is just wrong. The user doesn't have to do anything. With the proposed change, all CDI applications remain the same. We are talking about trading a "premature" CDI specific exception type, {{DeploymentException}} for the more specialized and well known {{NullPointerException}} during runtime. The fallacy in the CDI specification is that it treat an unsatisfied dependency as a problem. Section "5.2.2. Unsatisfied and ambiguous dependencies" {quote} If an unsatisfied .. dependency exists, the container automatically detects the problem and treats it as a deployment problem. {quote} But we know an unsatisfied dependency cannot always be treated as a problem. Contrary to what you stated, I had hoped all experienced Java developers abide to the principle of not writing "paranoid" null checks all over the code unless null is expected. Because +if+ and +when+ null is a problem, we will face a NPE exactly +where+ that problem surface. In a sense, nothing could ever be more clear or easily debugged and understood. If you don't agree with me, please share your thoughts. Until then, I say that checking for null, which is what all CDI implementations currently do, is the boilerplate code. It saddens me that they are enforced to act in this way with quite possibly the only result achieved being a reduced feature set offered to the application developer. Today, when the application want to have an optional dependency, then he has to write, yeah that's right: *boilerplate code*.. to circumvent the normal lookup mechanism and take the route through {{Instance}} which is not the first API most people learn about. Even more so, {{Instance}} will provide you with all the available injection targets. If your application only expected one to be present, any more than so would be ambiguous, then the application has to add it's own {{@PostContruct}} method that crash bean initialization if more than just one target was found. Compare all this *boilerplate code* to the simple use of one annotation {{@Inject}} which automatically, and with all right, treat many targets of the same kind being ambiguous. So if this proposition goes through, the "intuitive" approach would enrich CDI:s service offer and vastly reduce boilerplate code that all those applications in need of optional dependencies has to write. Like any other normal Java application, those that do require their dependency to be present will face the world's most known exception type: NPE. I say we reach out a hand to them by introducing the {{@Required}} annotation. Today, I believe that in this context, CDI work in an unintuitive way only to destroy its own usability and API simplicity. Again, the real question for us to answer, or vote on, is what the most intuitive approach is. If the most intuitive approach break backward compatibility, then the change has to wait to the next major release. Me personally, I would also like someone to give their view as to why CDI:s injection mechanism is semantically different from {{Map.get()}}? > 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) From issues at jboss.org Fri Oct 9 09:40:00 2015 From: issues at jboss.org (Martin Andersson (JIRA)) Date: Fri, 9 Oct 2015 09:40:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-565) Unsatisfied dependency should be null? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13116971#comment-13116971 ] Martin Andersson edited comment on CDI-565 at 10/9/15 9:39 AM: --------------------------------------------------------------- Emily, good to have you here. You wrote: {quote} .. optional injection forces the end users to check for null, which is boilerplate code in most scenarios and confusing. {quote} I must say that this statement is just wrong. The user doesn't have to do anything. With the proposed change, all CDI applications remain the same. We are talking about trading a "premature" CDI specific exception type, {{DeploymentException}} for the more specialized and well known {{NullPointerException}} during runtime. The fallacy in the CDI specification is that it treat an unsatisfied dependency as a problem. Section "5.2.2. Unsatisfied and ambiguous dependencies" {quote} If an unsatisfied .. dependency exists, the container automatically detects the problem and treats it as a deployment problem. {quote} But we know an unsatisfied dependency cannot always be treated as a problem. Contrary to what you stated, I had hoped all experienced Java developers abide to the principle of not writing "paranoid" null checks all over the code unless null is expected. Because +if+ and +when+ null is a problem, we will face a NPE exactly +where+ that problem surface. In a sense, nothing could ever be more clear or easily debugged and understood. If you don't agree with me, please share your thoughts. Until then, I say that checking for null, which is what all CDI implementations currently do, is the boilerplate code. It saddens me that they are enforced to act in this way with quite possibly the only result achieved being a reduced feature set offered to the application developer. Today, when the application want to have an optional dependency, then he has to write, yeah that's right: *boilerplate code*.. to circumvent the normal lookup mechanism and take the route through {{Instance}} which is not the first API most people learn about. Even more so, {{Instance}} will provide you with all the available injection targets. If your application only expected one to be present, any more than so would be ambiguous, then the application has to add it's own {{@PostContruct}} method that crash bean initialization if more than just one target was found. Compare all this *boilerplate code* to the simple use of one annotation {{@Inject}} which automatically, and with all right, treat many targets of the same kind being ambiguous. So if this proposition goes through, the "intuitive" approach would enrich CDI:s service offer and vastly reduce boilerplate code that all those applications in need of optional dependencies has to write. Like any other normal Java application, those that do require their dependency to be present will face the world's most known exception type: NPE. I say we reach out a hand to them by introducing the {{@Required}} annotation. Today, I believe that in this context, CDI work in an unintuitive way only to destroy its own usability and API simplicity. Again, the real question for us to answer, or vote on, is what the most intuitive approach is. If the most intuitive approach break backward compatibility, then the change has to wait to the next major release. Me personally, I would also like someone to give their view as to why CDI:s injection mechanism is semantically different from {{Map.get()}}? was (Author: martin.andersson): Emily, good to have you here. You wrote: {quote} .. optional injection forces the end users to check for null, which is boilerplate code in most scenarios and confusing. {quote} I must say that is just wrong. The user doesn't have to do anything. With the proposed change, all CDI applications remain the same. We are talking about trading a "premature" CDI specific exception type, {{DeploymentException}} for the more specialized and well known {{NullPointerException}} during runtime. The fallacy in the CDI specification is that it treat an unsatisfied dependency as a problem. Section "5.2.2. Unsatisfied and ambiguous dependencies" {quote} If an unsatisfied .. dependency exists, the container automatically detects the problem and treats it as a deployment problem. {quote} But we know an unsatisfied dependency cannot always be treated as a problem. Contrary to what you stated, I had hoped all experienced Java developers abide to the principle of not writing "paranoid" null checks all over the code unless null is expected. Because +if+ and +when+ null is a problem, we will face a NPE exactly +where+ that problem surface. In a sense, nothing could ever be more clear or easily debugged and understood. If you don't agree with me, please share your thoughts. Until then, I say that checking for null, which is what all CDI implementations currently do, is the boilerplate code. It saddens me that they are enforced to act in this way with quite possibly the only result achieved being a reduced feature set offered to the application developer. Today, when the application want to have an optional dependency, then he has to write, yeah that's right: *boilerplate code*.. to circumvent the normal lookup mechanism and take the route through {{Instance}} which is not the first API most people learn about. Even more so, {{Instance}} will provide you with all the available injection targets. If your application only expected one to be present, any more than so would be ambiguous, then the application has to add it's own {{@PostContruct}} method that crash bean initialization if more than just one target was found. Compare all this *boilerplate code* to the simple use of one annotation {{@Inject}} which automatically, and with all right, treat many targets of the same kind being ambiguous. So if this proposition goes through, the "intuitive" approach would enrich CDI:s service offer and vastly reduce boilerplate code that all those applications in need of optional dependencies has to write. Like any other normal Java application, those that do require their dependency to be present will face the world's most known exception type: NPE. I say we reach out a hand to them by introducing the {{@Required}} annotation. Today, I believe that in this context, CDI work in an unintuitive way only to destroy its own usability and API simplicity. Again, the real question for us to answer, or vote on, is what the most intuitive approach is. If the most intuitive approach break backward compatibility, then the change has to wait to the next major release. Me personally, I would also like someone to give their view as to why CDI:s injection mechanism is semantically different from {{Map.get()}}? > 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) From issues at jboss.org Mon Oct 12 04:24:00 2015 From: issues at jboss.org (Emily Jiang (JIRA)) Date: Mon, 12 Oct 2015 04:24:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-565) Unsatisfied dependency should be null? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13117271#comment-13117271 ] Emily Jiang commented on CDI-565: --------------------------------- I think the suggestion is to change the DeploymentException to NullPointerException during runtime. I would rather my application is not starting rather than failing with NPE during runtime. In this way, if my application starts, I know it will behave correctly rather than half cooked. I am not a fun of NullPointerException. I cannot see the real issue of this, rather than changing Instance<> to @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) From issues at jboss.org Mon Oct 12 17:17:00 2015 From: issues at jboss.org (arjan tijms (JIRA)) Date: Mon, 12 Oct 2015 17:17:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-565) Unsatisfied dependency should be null? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13117571#comment-13117571 ] arjan tijms commented on CDI-565: --------------------------------- Just one other option to take into account; next to {{Instance}}, what about {{Optional}}? That would more or less function like {{Instance}} does today, but with the difference that it would only provide 0 or 1 instances. If more than 1 bean would eligible it's ambiguous and the familiar exception would be thrown during deployment. {{Optional}} may also be more familiar to developers (eventually when JDK 8 is more used), and has a somewhat easier syntax. Perhaps needless to say but programmatically using the bean manager API the 0 or 1 is of course already possible. We use something like this in OmniSecurity with this admittedly not superbly coded [getReferenceOrNull|https://github.com/omnifaces/omnisecurity/blob/master/src/main/java/org/omnifaces/security/cdi/Beans.java#L48] method. > 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) From emijiang6 at googlemail.com Mon Oct 12 17:56:02 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Mon, 12 Oct 2015 22:56:02 +0100 Subject: [cdi-dev] HttpSession failover from cdi 1.0 impl to cdi 1.2 impl In-Reply-To: References: <56179CEB.8070201@redhat.com> <08B1F21E-CC32-4542-8C05-26533ACA2433@yahoo.de> Message-ID: Thank you Mark for the useful information! I forgot to cc cdi-dev:(. Yes, I meant the session failover in a cluster containing multiple servers. >From what you described, it seems the session failover can only occur among the servers containing the same level of OWB. It is going to be very tricky to get OWB 1.0/1.1 to failover to OWB 1.2 servers. The serialization/deserialization is very different. I believe in Weld, the Weld generated subclass is stored in the session. Martin K, please correct me if I am wrong. To move forward, can we work out a plan to support failover among different CDI levels of the same kind in the future CDI releases as the current failover support is a real limitation? On Mon, Oct 12, 2015 at 9:29 AM, Mark Struberg wrote: > Deliberately private? Or did you simply forget to cc cdi-dev? Feel free to > forward my answers to the list. > > > > The EJB spec does not say anything about failover. > > Yes it says nothing about session failover or session replication. It is > pretty vocal about remoting however. And this is technologically very close > to clustering on many servers (Server talking to another Server). > We probably have to explicitly distinguish a simple Session failover to a > functional clustering aka scale up (mostly @Remote). > > Guess you are just refering to the former, right? > For EJBs you can also only have @Stateful beans affected by session > replication. And only if you store them in the Session (which gets > replicated) of course. Or since EE6 if they are annotated with a CDI Scope > annotation which ends up in the http session along the line > (@SessionScoped, @ConversationScoped, various custom scopes, e.g. > DeltaSpike @WindowScoped or @ViewAccessScoped). Or an @Dependent @Stateful > which gets injected in a bean which ends up in the HttpSession. > Any other EJBs which might get moved to another cluster node as a whole? > > Re OWB 1.1 and 1.2 compat. I fear it?s not easy. The ?Contextual Instance? > stored in OWB-1.1 is _always_ without any interceptors or decorators. It > doesn?t even contain any javassist dependencies. BUT if you inject any > other NormalScoped bean into it _THEN_ you will have the ?proxy shale? for > those. And they of course contain javassist classes. > > In OWB-1.0 and 1.1 we also had a single ?unified? proxy stack which > contained NormalScoping, Interceptor logic and Decorator logic. > In OWB-1.2 and up we did split this and now have 3 different proxies: > NormalScoping proxies aka the ?Contextual References?. They are _not_ part > of the Contextual Instance. Then we have Interceptor/Decoratpr Proxies > (both in a single proxy class) and for abstract Decorators we also generate > a simple proxy which just implements the missing methods. The later 2 > proxies are part of the ?Contextual Instance? and thus get stored in the > ContextualInstanceBag/SessionContext in the HttpSession. > And of course you have the same impact of injected NormalScoped beans into > a e.g. @SessionScoped bean as with OWB-1.1. > > > I guess that wou will get hit with similar constellations in Weld as well. > > > LieGrue, > strub > > > > > > Am 11.10.2015 um 22:28 schrieb Emily Jiang : > > > > The EJB spec does not say anything about failover. Some EJB > implementations can support failover between different server levels. I am > talking about failover among the same kind. I don't believe OWB can support > failover between cdi 1.0 and cdi 1.2, neither does Weld can do. > > > > On Fri, Oct 9, 2015 at 12:53 PM, Mark Struberg > wrote: > > Wonder the same. I?m 100% sure that it is NOT portable for NIV. Wheras > for EJB2 style EJBs it _might_ working due to RMI/IIOP (Though don?t > remember whether this was only specified for remoting or also for > clustering. Nor do I remember if the spec said anything about clustering at > all). > > > > I guess there often is ?additional? wrapper stuff handed over in > addition to the normal beans for EJB3 style EJBs. I know for sure that we > do exactly that in OpenEJB. We have additional wrappers e.g. for > transported Exceptions when doing remoting. We hand over the ?string > representation? and the original Exception stack data separately. In case > we cannot de-serialize the Exception on the other side. Think about sending > some OptimisticLockException (or even some internal Hibernate Exception) > over to an EJB client which doesn?t have any Hibernate jars and not even > the jaa-spec jar on it?s classpath? Similar additional information might be > stored in any EJB proxy. Or think about Extended Persistence Contexts. How > should that ever work to be serialized between e.g. WildFly and Glassfish? > How would you replicate over some Hibernate Exception if the other node is > running Glassfish with EclipseLink? :) > > > > LieGrue, > > strub > > > > > > > Am 09.10.2015 um 12:54 schrieb Martin Kouba : > > > > > > I wonder whether this behavior is defined somewhere, i.e. if all EJB > > > implementations must support "failover" between minor versions (e.g. > EJB > > > 3.0 and 3.2), in other words the passivation mechanism may not change. > > > This would mean that an EJB app might be deployed to a "cluster" of > > > mixed Java EE 6 and Java EE 7 app servers - seems to me like an > > > extremely risky experiment. > > > > > > Martin > > > > > > Dne 9.10.2015 v 11:42 Emily Jiang napsal(a): > > >> I am investigating the HttpSession failover for SessionScoped or > > >> ConversationScoped beans. I think it is not easy to failover from the > > >> CDI 1.0 impl to CDI1.2 impl, as the bean proxies instead of the raw > bean > > >> was serialised and the proxies are different between cdi 1.0 and cdi > > >> 1.2. Has anyone have any thoughts on this? If not possible, this is a > > >> big limitation for CDI as EJB container has no such limitation. > > >> > > >> -- > > >> Thanks > > >> Emily > > >> ================= > > >> Emily Jiang > > >> ejiang at apache.org > > >> > > >> > > >> _______________________________________________ > > >> cdi-dev mailing list > > >> cdi-dev at 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. > > >> > > > > > > -- > > > Martin Kouba > > > Software Engineer > > > Red Hat, Czech Republic > > > _______________________________________________ > > > cdi-dev mailing list > > > cdi-dev at 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 at 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. > > > > > > > > -- > > Thanks > > Emily > > ================= > > Emily Jiang > > ejiang at apache.org > > -- Thanks Emily ================= Emily Jiang ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151012/cc351657/attachment-0001.html From mkouba at redhat.com Tue Oct 13 02:44:01 2015 From: mkouba at redhat.com (Martin Kouba) Date: Tue, 13 Oct 2015 08:44:01 +0200 Subject: [cdi-dev] HttpSession failover from cdi 1.0 impl to cdi 1.2 impl In-Reply-To: References: <56179CEB.8070201@redhat.com> <08B1F21E-CC32-4542-8C05-26533ACA2433@yahoo.de> Message-ID: <561CA831.1000502@redhat.com> Dne 12.10.2015 v 23:56 Emily Jiang napsal(a): > Thank you Mark for the useful information! I forgot to cc cdi-dev:(. > Yes, I meant the session failover in a cluster containing multiple servers. > From what you described, it seems the session failover can only occur > among the servers containing the same level of OWB. It is going to be > very tricky to get OWB 1.0/1.1 to failover to OWB 1.2 servers. The > serialization/deserialization is very different. > > I believe in Weld, the Weld generated subclass is stored in the session. > Martin K, please correct me if I am wrong. Well, not exactly. Weld stores a contextual reference (subclass), a creational context and some info about the contextual (a bean, its id, etc.). You always need these to destroy a contextual instance properly. And it's not compatible between weld 1.1 and 2.0+. First of all in weld 1.1 javassist is used but in 2+ it was replaced by jboss-classfilewriter. Also there are some optimizations in the contextual info part. > > To move forward, can we work out a plan to support failover among > different CDI levels of the same kind in the future CDI releases as the > current failover support is a real limitation? > > On Mon, Oct 12, 2015 at 9:29 AM, Mark Struberg > wrote: > > Deliberately private? Or did you simply forget to cc cdi-dev? Feel > free to forward my answers to the list. > > > > The EJB spec does not say anything about failover. > > Yes it says nothing about session failover or session replication. > It is pretty vocal about remoting however. And this is > technologically very close to clustering on many servers (Server > talking to another Server). > We probably have to explicitly distinguish a simple Session failover > to a functional clustering aka scale up (mostly @Remote). > > Guess you are just refering to the former, right? > For EJBs you can also only have @Stateful beans affected by session > replication. And only if you store them in the Session (which gets > replicated) of course. Or since EE6 if they are annotated with a CDI > Scope annotation which ends up in the http session along the line > (@SessionScoped, @ConversationScoped, various custom scopes, e.g. > DeltaSpike @WindowScoped or @ViewAccessScoped). Or an @Dependent > @Stateful which gets injected in a bean which ends up in the > HttpSession. > Any other EJBs which might get moved to another cluster node as a whole? > > Re OWB 1.1 and 1.2 compat. I fear it?s not easy. The ?Contextual > Instance? stored in OWB-1.1 is _always_ without any interceptors or > decorators. It doesn?t even contain any javassist dependencies. BUT > if you inject any other NormalScoped bean into it _THEN_ you will > have the ?proxy shale? for those. And they of course contain > javassist classes. > > In OWB-1.0 and 1.1 we also had a single ?unified? proxy stack which > contained NormalScoping, Interceptor logic and Decorator logic. > In OWB-1.2 and up we did split this and now have 3 different > proxies: NormalScoping proxies aka the ?Contextual References?. They > are _not_ part of the Contextual Instance. Then we have > Interceptor/Decoratpr Proxies (both in a single proxy class) and for > abstract Decorators we also generate a simple proxy which just > implements the missing methods. The later 2 proxies are part of the > ?Contextual Instance? and thus get stored in the > ContextualInstanceBag/SessionContext in the HttpSession. > And of course you have the same impact of injected NormalScoped > beans into a e.g. @SessionScoped bean as with OWB-1.1. > > > I guess that wou will get hit with similar constellations in Weld as > well. > > > LieGrue, > strub > > > > > > Am 11.10.2015 um 22:28 schrieb Emily Jiang > >: > > > > The EJB spec does not say anything about failover. Some EJB > implementations can support failover between different server > levels. I am talking about failover among the same kind. I don't > believe OWB can support failover between cdi 1.0 and cdi 1.2, > neither does Weld can do. > > > > On Fri, Oct 9, 2015 at 12:53 PM, Mark Struberg > wrote: > > Wonder the same. I?m 100% sure that it is NOT portable for NIV. > Wheras for EJB2 style EJBs it _might_ working due to RMI/IIOP > (Though don?t remember whether this was only specified for remoting > or also for clustering. Nor do I remember if the spec said anything > about clustering at all). > > > > I guess there often is ?additional? wrapper stuff handed over in > addition to the normal beans for EJB3 style EJBs. I know for sure > that we do exactly that in OpenEJB. We have additional wrappers e.g. > for transported Exceptions when doing remoting. We hand over the > ?string representation? and the original Exception stack data > separately. In case we cannot de-serialize the Exception on the > other side. Think about sending some OptimisticLockException (or > even some internal Hibernate Exception) over to an EJB client which > doesn?t have any Hibernate jars and not even the jaa-spec jar on > it?s classpath? Similar additional information might be stored in > any EJB proxy. Or think about Extended Persistence Contexts. How > should that ever work to be serialized between e.g. WildFly and > Glassfish? How would you replicate over some Hibernate Exception if > the other node is running Glassfish with EclipseLink? :) > > > > LieGrue, > > strub > > > > > > > Am 09.10.2015 um 12:54 schrieb Martin Kouba >: > > > > > > I wonder whether this behavior is defined somewhere, i.e. if > all EJB > > > implementations must support "failover" between minor versions > (e.g. EJB > > > 3.0 and 3.2), in other words the passivation mechanism may not > change. > > > This would mean that an EJB app might be deployed to a "cluster" of > > > mixed Java EE 6 and Java EE 7 app servers - seems to me like an > > > extremely risky experiment. > > > > > > Martin > > > > > > Dne 9.10.2015 v 11:42 Emily Jiang napsal(a): > > >> I am investigating the HttpSession failover for SessionScoped or > > >> ConversationScoped beans. I think it is not easy to failover > from the > > >> CDI 1.0 impl to CDI1.2 impl, as the bean proxies instead of > the raw bean > > >> was serialised and the proxies are different between cdi 1.0 > and cdi > > >> 1.2. Has anyone have any thoughts on this? If not possible, > this is a > > >> big limitation for CDI as EJB container has no such limitation. > > >> > > >> -- > > >> Thanks > > >> Emily > > >> ================= > > >> Emily Jiang > > >> ejiang at apache.org > > > > >> > > >> > > >> _______________________________________________ > > >> cdi-dev mailing list > > >> cdi-dev at 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. > > >> > > > > > > -- > > > Martin Kouba > > > Software Engineer > > > Red Hat, Czech Republic > > > _______________________________________________ > > > cdi-dev mailing list > > > cdi-dev at 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 at 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. > > > > > > > > -- > > Thanks > > Emily > > ================= > > Emily Jiang > > ejiang at apache.org > > > > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. > -- Martin Kouba Software Engineer Red Hat, Czech Republic From struberg at yahoo.de Tue Oct 13 03:24:55 2015 From: struberg at yahoo.de (Mark Struberg) Date: Tue, 13 Oct 2015 09:24:55 +0200 Subject: [cdi-dev] HttpSession failover from cdi 1.0 impl to cdi 1.2 impl In-Reply-To: <561CA831.1000502@redhat.com> References: <56179CEB.8070201@redhat.com> <08B1F21E-CC32-4542-8C05-26533ACA2433@yahoo.de> <561CA831.1000502@redhat.com> Message-ID: I think the best way to cluster servers of different versions is to use pairing. Of course the tupels must be of the same making. That way you can ?fade out? old server versions by simply stopping ?new? traffic to the old servers on the load balancer without loosing 24/7 uptime. FTR: I?m -1 on specifying every internal data structures needed for replication. That would put a huge burden on us (OWB and Weld) and would limit our possibilities in improving our software. LieGrue, staub > Am 13.10.2015 um 08:44 schrieb Martin Kouba : > > Dne 12.10.2015 v 23:56 Emily Jiang napsal(a): >> Thank you Mark for the useful information! I forgot to cc cdi-dev:(. >> Yes, I meant the session failover in a cluster containing multiple servers. >> From what you described, it seems the session failover can only occur >> among the servers containing the same level of OWB. It is going to be >> very tricky to get OWB 1.0/1.1 to failover to OWB 1.2 servers. The >> serialization/deserialization is very different. >> >> I believe in Weld, the Weld generated subclass is stored in the session. >> Martin K, please correct me if I am wrong. > > Well, not exactly. Weld stores a contextual reference (subclass), a creational context and some info about the contextual (a bean, its id, etc.). You always need these to destroy a contextual instance properly. > > And it's not compatible between weld 1.1 and 2.0+. First of all in weld 1.1 javassist is used but in 2+ it was replaced by jboss-classfilewriter. Also there are some optimizations in the contextual info part. > >> >> To move forward, can we work out a plan to support failover among >> different CDI levels of the same kind in the future CDI releases as the >> current failover support is a real limitation? >> >> On Mon, Oct 12, 2015 at 9:29 AM, Mark Struberg > > wrote: >> >> Deliberately private? Or did you simply forget to cc cdi-dev? Feel >> free to forward my answers to the list. >> >> >> > The EJB spec does not say anything about failover. >> >> Yes it says nothing about session failover or session replication. >> It is pretty vocal about remoting however. And this is >> technologically very close to clustering on many servers (Server >> talking to another Server). >> We probably have to explicitly distinguish a simple Session failover >> to a functional clustering aka scale up (mostly @Remote). >> >> Guess you are just refering to the former, right? >> For EJBs you can also only have @Stateful beans affected by session >> replication. And only if you store them in the Session (which gets >> replicated) of course. Or since EE6 if they are annotated with a CDI >> Scope annotation which ends up in the http session along the line >> (@SessionScoped, @ConversationScoped, various custom scopes, e.g. >> DeltaSpike @WindowScoped or @ViewAccessScoped). Or an @Dependent >> @Stateful which gets injected in a bean which ends up in the >> HttpSession. >> Any other EJBs which might get moved to another cluster node as a whole? >> >> Re OWB 1.1 and 1.2 compat. I fear it?s not easy. The ?Contextual >> Instance? stored in OWB-1.1 is _always_ without any interceptors or >> decorators. It doesn?t even contain any javassist dependencies. BUT >> if you inject any other NormalScoped bean into it _THEN_ you will >> have the ?proxy shale? for those. And they of course contain >> javassist classes. >> >> In OWB-1.0 and 1.1 we also had a single ?unified? proxy stack which >> contained NormalScoping, Interceptor logic and Decorator logic. >> In OWB-1.2 and up we did split this and now have 3 different >> proxies: NormalScoping proxies aka the ?Contextual References?. They >> are _not_ part of the Contextual Instance. Then we have >> Interceptor/Decoratpr Proxies (both in a single proxy class) and for >> abstract Decorators we also generate a simple proxy which just >> implements the missing methods. The later 2 proxies are part of the >> ?Contextual Instance? and thus get stored in the >> ContextualInstanceBag/SessionContext in the HttpSession. >> And of course you have the same impact of injected NormalScoped >> beans into a e.g. @SessionScoped bean as with OWB-1.1. >> >> >> I guess that wou will get hit with similar constellations in Weld as >> well. >> >> >> LieGrue, >> strub >> >> >> >> >> > Am 11.10.2015 um 22:28 schrieb Emily Jiang >> >: >> > >> > The EJB spec does not say anything about failover. Some EJB >> implementations can support failover between different server >> levels. I am talking about failover among the same kind. I don't >> believe OWB can support failover between cdi 1.0 and cdi 1.2, >> neither does Weld can do. >> > >> > On Fri, Oct 9, 2015 at 12:53 PM, Mark Struberg > > wrote: >> > Wonder the same. I?m 100% sure that it is NOT portable for NIV. >> Wheras for EJB2 style EJBs it _might_ working due to RMI/IIOP >> (Though don?t remember whether this was only specified for remoting >> or also for clustering. Nor do I remember if the spec said anything >> about clustering at all). >> > >> > I guess there often is ?additional? wrapper stuff handed over in >> addition to the normal beans for EJB3 style EJBs. I know for sure >> that we do exactly that in OpenEJB. We have additional wrappers e.g. >> for transported Exceptions when doing remoting. We hand over the >> ?string representation? and the original Exception stack data >> separately. In case we cannot de-serialize the Exception on the >> other side. Think about sending some OptimisticLockException (or >> even some internal Hibernate Exception) over to an EJB client which >> doesn?t have any Hibernate jars and not even the jaa-spec jar on >> it?s classpath? Similar additional information might be stored in >> any EJB proxy. Or think about Extended Persistence Contexts. How >> should that ever work to be serialized between e.g. WildFly and >> Glassfish? How would you replicate over some Hibernate Exception if >> the other node is running Glassfish with EclipseLink? :) >> > >> > LieGrue, >> > strub >> > >> > >> > > Am 09.10.2015 um 12:54 schrieb Martin Kouba > >: >> > > >> > > I wonder whether this behavior is defined somewhere, i.e. if >> all EJB >> > > implementations must support "failover" between minor versions >> (e.g. EJB >> > > 3.0 and 3.2), in other words the passivation mechanism may not >> change. >> > > This would mean that an EJB app might be deployed to a "cluster" of >> > > mixed Java EE 6 and Java EE 7 app servers - seems to me like an >> > > extremely risky experiment. >> > > >> > > Martin >> > > >> > > Dne 9.10.2015 v 11:42 Emily Jiang napsal(a): >> > >> I am investigating the HttpSession failover for SessionScoped or >> > >> ConversationScoped beans. I think it is not easy to failover >> from the >> > >> CDI 1.0 impl to CDI1.2 impl, as the bean proxies instead of >> the raw bean >> > >> was serialised and the proxies are different between cdi 1.0 >> and cdi >> > >> 1.2. Has anyone have any thoughts on this? If not possible, >> this is a >> > >> big limitation for CDI as EJB container has no such limitation. >> > >> >> > >> -- >> > >> Thanks >> > >> Emily >> > >> ================= >> > >> Emily Jiang >> > >> ejiang at apache.org >> > >> > >> >> > >> >> > >> _______________________________________________ >> > >> cdi-dev mailing list >> > >> cdi-dev at 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. >> > >> >> > > >> > > -- >> > > Martin Kouba >> > > Software Engineer >> > > Red Hat, Czech Republic >> > > _______________________________________________ >> > > cdi-dev mailing list >> > > cdi-dev at 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 at 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. >> > >> > >> > >> > -- >> > Thanks >> > Emily >> > ================= >> > Emily Jiang >> > ejiang at apache.org >> >> >> >> >> -- >> Thanks >> Emily >> ================= >> Emily Jiang >> ejiang at apache.org >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at 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. >> > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic From issues at jboss.org Tue Oct 13 03:34:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 13 Oct 2015 03:34:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-565) Unsatisfied dependency should be null? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13117613#comment-13117613 ] Martin Kouba commented on CDI-565: ---------------------------------- [~atijms] Do you mean {{java.util.Optional}}? It's final and not serializable. So you can't use it for passivating scopes. > 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) From issues at jboss.org Tue Oct 13 03:39:00 2015 From: issues at jboss.org (Sven Linstaedt (JIRA)) Date: Tue, 13 Oct 2015 03:39:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-565) Unsatisfied dependency should be null? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13117614#comment-13117614 ] Sven Linstaedt commented on CDI-565: ------------------------------------ As far as I remember there was already a discussion around introducing optional dependencies via {{java.util.Optional}}. The problem is {{java.util.Optional}} was not meant for long term state holding, but rather for API design. Optional instances are not directly serializable putting something with optional dependencies in a serializable scope will probably cause either exceptions or headaches for CDI providers ;) If the next CDI version solely depend on Java 8, one could introduce a new method like {{Instance#getOptional()}}, which likely still throw an exception if multiple instances are available. > 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) From mkouba at redhat.com Tue Oct 13 03:40:39 2015 From: mkouba at redhat.com (Martin Kouba) Date: Tue, 13 Oct 2015 09:40:39 +0200 Subject: [cdi-dev] HttpSession failover from cdi 1.0 impl to cdi 1.2 impl In-Reply-To: References: <56179CEB.8070201@redhat.com> <08B1F21E-CC32-4542-8C05-26533ACA2433@yahoo.de> <561CA831.1000502@redhat.com> Message-ID: <561CB577.4010903@redhat.com> Dne 13.10.2015 v 09:24 Mark Struberg napsal(a): > I think the best way to cluster servers of different versions is to use pairing. Of course the tupels must be of the same making. > That way you can ?fade out? old server versions by simply stopping ?new? traffic to the old servers on the load balancer without loosing 24/7 uptime. > > FTR: I?m -1 on specifying every internal data structures needed for replication. That would put a huge burden on us (OWB and Weld) and would limit our possibilities in improving our software. I have the same opinion. It would be too limiting. > > LieGrue, > staub > > >> Am 13.10.2015 um 08:44 schrieb Martin Kouba : >> >> Dne 12.10.2015 v 23:56 Emily Jiang napsal(a): >>> Thank you Mark for the useful information! I forgot to cc cdi-dev:(. >>> Yes, I meant the session failover in a cluster containing multiple servers. >>> From what you described, it seems the session failover can only occur >>> among the servers containing the same level of OWB. It is going to be >>> very tricky to get OWB 1.0/1.1 to failover to OWB 1.2 servers. The >>> serialization/deserialization is very different. >>> >>> I believe in Weld, the Weld generated subclass is stored in the session. >>> Martin K, please correct me if I am wrong. >> >> Well, not exactly. Weld stores a contextual reference (subclass), a creational context and some info about the contextual (a bean, its id, etc.). You always need these to destroy a contextual instance properly. >> >> And it's not compatible between weld 1.1 and 2.0+. First of all in weld 1.1 javassist is used but in 2+ it was replaced by jboss-classfilewriter. Also there are some optimizations in the contextual info part. >> >>> >>> To move forward, can we work out a plan to support failover among >>> different CDI levels of the same kind in the future CDI releases as the >>> current failover support is a real limitation? >>> >>> On Mon, Oct 12, 2015 at 9:29 AM, Mark Struberg >> > wrote: >>> >>> Deliberately private? Or did you simply forget to cc cdi-dev? Feel >>> free to forward my answers to the list. >>> >>> >>> > The EJB spec does not say anything about failover. >>> >>> Yes it says nothing about session failover or session replication. >>> It is pretty vocal about remoting however. And this is >>> technologically very close to clustering on many servers (Server >>> talking to another Server). >>> We probably have to explicitly distinguish a simple Session failover >>> to a functional clustering aka scale up (mostly @Remote). >>> >>> Guess you are just refering to the former, right? >>> For EJBs you can also only have @Stateful beans affected by session >>> replication. And only if you store them in the Session (which gets >>> replicated) of course. Or since EE6 if they are annotated with a CDI >>> Scope annotation which ends up in the http session along the line >>> (@SessionScoped, @ConversationScoped, various custom scopes, e.g. >>> DeltaSpike @WindowScoped or @ViewAccessScoped). Or an @Dependent >>> @Stateful which gets injected in a bean which ends up in the >>> HttpSession. >>> Any other EJBs which might get moved to another cluster node as a whole? >>> >>> Re OWB 1.1 and 1.2 compat. I fear it?s not easy. The ?Contextual >>> Instance? stored in OWB-1.1 is _always_ without any interceptors or >>> decorators. It doesn?t even contain any javassist dependencies. BUT >>> if you inject any other NormalScoped bean into it _THEN_ you will >>> have the ?proxy shale? for those. And they of course contain >>> javassist classes. >>> >>> In OWB-1.0 and 1.1 we also had a single ?unified? proxy stack which >>> contained NormalScoping, Interceptor logic and Decorator logic. >>> In OWB-1.2 and up we did split this and now have 3 different >>> proxies: NormalScoping proxies aka the ?Contextual References?. They >>> are _not_ part of the Contextual Instance. Then we have >>> Interceptor/Decoratpr Proxies (both in a single proxy class) and for >>> abstract Decorators we also generate a simple proxy which just >>> implements the missing methods. The later 2 proxies are part of the >>> ?Contextual Instance? and thus get stored in the >>> ContextualInstanceBag/SessionContext in the HttpSession. >>> And of course you have the same impact of injected NormalScoped >>> beans into a e.g. @SessionScoped bean as with OWB-1.1. >>> >>> >>> I guess that wou will get hit with similar constellations in Weld as >>> well. >>> >>> >>> LieGrue, >>> strub >>> >>> >>> >>> >>> > Am 11.10.2015 um 22:28 schrieb Emily Jiang >>> >: >>> > >>> > The EJB spec does not say anything about failover. Some EJB >>> implementations can support failover between different server >>> levels. I am talking about failover among the same kind. I don't >>> believe OWB can support failover between cdi 1.0 and cdi 1.2, >>> neither does Weld can do. >>> > >>> > On Fri, Oct 9, 2015 at 12:53 PM, Mark Struberg >> > wrote: >>> > Wonder the same. I?m 100% sure that it is NOT portable for NIV. >>> Wheras for EJB2 style EJBs it _might_ working due to RMI/IIOP >>> (Though don?t remember whether this was only specified for remoting >>> or also for clustering. Nor do I remember if the spec said anything >>> about clustering at all). >>> > >>> > I guess there often is ?additional? wrapper stuff handed over in >>> addition to the normal beans for EJB3 style EJBs. I know for sure >>> that we do exactly that in OpenEJB. We have additional wrappers e.g. >>> for transported Exceptions when doing remoting. We hand over the >>> ?string representation? and the original Exception stack data >>> separately. In case we cannot de-serialize the Exception on the >>> other side. Think about sending some OptimisticLockException (or >>> even some internal Hibernate Exception) over to an EJB client which >>> doesn?t have any Hibernate jars and not even the jaa-spec jar on >>> it?s classpath? Similar additional information might be stored in >>> any EJB proxy. Or think about Extended Persistence Contexts. How >>> should that ever work to be serialized between e.g. WildFly and >>> Glassfish? How would you replicate over some Hibernate Exception if >>> the other node is running Glassfish with EclipseLink? :) >>> > >>> > LieGrue, >>> > strub >>> > >>> > >>> > > Am 09.10.2015 um 12:54 schrieb Martin Kouba >> >: >>> > > >>> > > I wonder whether this behavior is defined somewhere, i.e. if >>> all EJB >>> > > implementations must support "failover" between minor versions >>> (e.g. EJB >>> > > 3.0 and 3.2), in other words the passivation mechanism may not >>> change. >>> > > This would mean that an EJB app might be deployed to a "cluster" of >>> > > mixed Java EE 6 and Java EE 7 app servers - seems to me like an >>> > > extremely risky experiment. >>> > > >>> > > Martin >>> > > >>> > > Dne 9.10.2015 v 11:42 Emily Jiang napsal(a): >>> > >> I am investigating the HttpSession failover for SessionScoped or >>> > >> ConversationScoped beans. I think it is not easy to failover >>> from the >>> > >> CDI 1.0 impl to CDI1.2 impl, as the bean proxies instead of >>> the raw bean >>> > >> was serialised and the proxies are different between cdi 1.0 >>> and cdi >>> > >> 1.2. Has anyone have any thoughts on this? If not possible, >>> this is a >>> > >> big limitation for CDI as EJB container has no such limitation. >>> > >> >>> > >> -- >>> > >> Thanks >>> > >> Emily >>> > >> ================= >>> > >> Emily Jiang >>> > >> ejiang at apache.org >>> > >>> > >> >>> > >> >>> > >> _______________________________________________ >>> > >> cdi-dev mailing list >>> > >> cdi-dev at 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. >>> > >> >>> > > >>> > > -- >>> > > Martin Kouba >>> > > Software Engineer >>> > > Red Hat, Czech Republic >>> > > _______________________________________________ >>> > > cdi-dev mailing list >>> > > cdi-dev at 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 at 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. >>> > >>> > >>> > >>> > -- >>> > Thanks >>> > Emily >>> > ================= >>> > Emily Jiang >>> > ejiang at apache.org >>> >>> >>> >>> >>> -- >>> Thanks >>> Emily >>> ================= >>> Emily Jiang >>> ejiang at apache.org >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at 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. >>> >> >> -- >> Martin Kouba >> Software Engineer >> Red Hat, Czech Republic > -- Martin Kouba Software Engineer Red Hat, Czech Republic From issues at jboss.org Tue Oct 13 06:31:00 2015 From: issues at jboss.org (arjan tijms (JIRA)) Date: Tue, 13 Oct 2015 06:31:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-565) Unsatisfied dependency should be null? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13117665#comment-13117665 ] arjan tijms commented on CDI-565: --------------------------------- {quote}Do you mean java.util.Optional? It's final and not serializable. So you can't use it for passivating scopes.{quote} You're right, I overlooked that. Very unfortunate for this situation. It's a long time away still, but I remember hearing that JDK 10 Optional may become a value type and value types are implicitly serializable. {quote}Optional instances are not directly serializable putting something with optional dependencies in a serializable scope will probably cause either exceptions or headaches for CDI providers {quote} It's sure not going to be pretty. A custom serializer may threat {{Optional}} fields special, e.g. just checking if they have a value and if so serializing that instead in a custom location. Upon restoring, if there's nothing saved in a custom location instantiate an empty Optional for the field in question, otherwise an Optional with the deserialized value. But yeah, not pretty, and probably headache inducing indeed. {quote}If the next CDI version solely depend on Java 8, one could introduce a new method like Instance#getOptional(){quote} I don't know. It's a little help but doesn't give you the "at most 1" guaranty during deployment. > 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) From antoine at sabot-durand.net Fri Oct 16 04:18:59 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 16 Oct 2015 08:18:59 +0000 Subject: [cdi-dev] Spec with TCK assertion Message-ID: Hi all, In case you missed it, I released the new version of spec including TCK assertion: http://www.cdi-spec.org/news/2015/10/15/Learn-CDI-with-TCK/ Thanks again to Tomas who did a smart job here Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151016/571a2977/attachment.html From issues at jboss.org Fri Oct 16 09:54:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 16 Oct 2015 09:54:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-522) Create add method setObserver() to ProcessObserverMethod SPI event In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119097#comment-13119097 ] Antoine Sabot-Durand edited comment on CDI-522 at 10/16/15 9:53 AM: -------------------------------------------------------------------- PR Also solves CDI-458 was (Author: antoinesabot-durand): Also solves CDI-458 > Create add method setObserver() to ProcessObserverMethod SPI event > ------------------------------------------------------------------ > > Key: CDI-522 > URL: https://issues.jboss.org/browse/CDI-522 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 1.2.Final > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > Right now {{ObserverMethod}} cannot be change in an extension. In the philosophy of {{ProcessAnnotatedType#setAnnotatedType}} or {{ProcessBeanAttributes#setBeanAttributes}} we could add a {{ProcessObserverMethod#setObserverMethod}} to change properties on an observer. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 16 11:04:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 16 Oct 2015 11:04:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-433) AdminEvent example has redundant qualifiers. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-433: ------------------------------------- Fix Version/s: 2.0-EDR2 > AdminEvent example has redundant qualifiers. > -------------------------------------------- > > Key: CDI-433 > URL: https://issues.jboss.org/browse/CDI-433 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: John Ament > Priority: Minor > Fix For: 2.0-EDR2 > > > In the CDI 1.2 spec, the following text appears: > For example, this injected Event has specified type LoggedInEvent and specified qualifier @Admin: > {{@Inject @Admin Event any;}} > The select() method returns a child Event for a given specified type and additional specified qualifiers. If no specified type is given, the specified type is the same as the parent. > For example, this child Event has required type AdminLoggedInEvent and additional specified qualifier {{@Admin}}: > {noformat} > Event admin = any.select( > AdminLoggedInEvent.class, > new AdminQualifier() ); > {noformat} > The problem is that the injection point any already is qualified @Admin, so the use is duplicate here. I believe the intention was that the injection point would read > {{@Inject Event any;}} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 16 13:54:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 16 Oct 2015 13:54:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-553) Chapter 10.5.3. Observer method invocation context should probably be in EE part In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-553: ------------------------------------- Fix Version/s: 2.0-EDR2 > Chapter 10.5.3. Observer method invocation context should probably be in EE part > -------------------------------------------------------------------------------- > > Key: CDI-553 > URL: https://issues.jboss.org/browse/CDI-553 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Tomas Remes > Fix For: 2.0-EDR2 > > > Chapter {{10.5.3. Observer method invocation context}} mainly speaks about transaction context and security context. AFAIK security context is a Java EE term and can be tested using EJBs. > So I think this chapter should be moved (or possibly split up) to the EE part of spec. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 16 13:55:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 16 Oct 2015 13:55:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-544) 10.2.3. The Event interface - provided executor cannot execute observers notification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-544: ------------------------------------- Fix Version/s: 2.0-EDR2 > 10.2.3. The Event interface - provided executor cannot execute observers notification > ------------------------------------------------------------------------------------- > > Key: CDI-544 > URL: https://issues.jboss.org/browse/CDI-544 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0-EDR1 > Reporter: Tomas Remes > Fix For: 2.0-EDR2 > > > {quote} > If the provided executor cannot execute observers notification, an IllegalArgumentException is thrown. > {quote} > What does it mean "cannot execute"? I am not really sure. Does it mean the observer throws an exception which should be wrapped in IAE? > This would likely contradict {{10.5.1. Handling multiple exceptions thrown during an asynchronous event}}. > Maybe this sentence could be omitted. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 16 13:55:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 16 Oct 2015 13:55:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-528) Minor inconsistency in Built-in qualifiers chapter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-528: ------------------------------------- Fix Version/s: 2.0-EDR2 (was: 2.0 (discussion)) > Minor inconsistency in Built-in qualifiers chapter > -------------------------------------------------- > > Key: CDI-528 > URL: https://issues.jboss.org/browse/CDI-528 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Tomas Remes > Assignee: Antoine Sabot-Durand > Priority: Minor > Fix For: 2.0-EDR2 > > > 2.3.1. Built-in qualifier types states: > {quote} > If a bean does not explicitly declare a qualifier other than @Named , the bean has exactly one additional qualifier, of type @Default . > {quote} > This means that following bean has @Named, @Default, @Any qualifiers: > {code} > @Named > public class Dog {} > {code} > but this one is not required to have @Default qualifier: > {code} > @Named > @Any > public class Dog {} > {code} > It doesn't make much sense IMHO. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 16 13:56:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 16 Oct 2015 13:56:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-522) Create add method setObserver() to ProcessObserverMethod SPI event In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-522: ------------------------------------- Fix Version/s: 2.0-EDR2 (was: 2.0 (discussion)) > Create add method setObserver() to ProcessObserverMethod SPI event > ------------------------------------------------------------------ > > Key: CDI-522 > URL: https://issues.jboss.org/browse/CDI-522 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 1.2.Final > Reporter: Antoine Sabot-Durand > Fix For: 2.0-EDR2 > > > Right now {{ObserverMethod}} cannot be change in an extension. In the philosophy of {{ProcessAnnotatedType#setAnnotatedType}} or {{ProcessBeanAttributes#setBeanAttributes}} we could add a {{ProcessObserverMethod#setObserverMethod}} to change properties on an observer. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 16 13:57:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 16 Oct 2015 13:57:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-458) Give the possibility to deactivate an observer in ProcessObserverMethod In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-458: ------------------------------------- Fix Version/s: 2.0-EDR2 (was: 2.0 (proposed)) > Give the possibility to deactivate an observer in ProcessObserverMethod > ----------------------------------------------------------------------- > > Key: CDI-458 > URL: https://issues.jboss.org/browse/CDI-458 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events, Portable Extensions > Affects Versions: 1.2.Final > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0-EDR2 > > > Today if a user want to deactivate an observer at deployment time, she needs to observes {{ProcessAnnotatedType}} with {{@WithAnnotation(Observes.class)}} and replace the annotatedType by a new one without the {{@Observes}} annotation. It's quite heavy to manage. > We could add a {{veto()}} method in {{ProcessObserverMethod}} to do this in a far easier and intuitive way. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 16 13:57:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 16 Oct 2015 13:57:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-160) Split specification into "core" and "Java EE integration" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-160: ------------------------------------- Fix Version/s: 2.0-EDR1 (was: 2.0 (proposed)) > Split specification into "core" and "Java EE integration" > --------------------------------------------------------- > > Key: CDI-160 > URL: https://issues.jboss.org/browse/CDI-160 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Antoine Sabot-Durand > Priority: Critical > Fix For: 2.0-EDR1 > > > In order to better support implementations of CDI such as Weld SE, Errai, and OpenWebBeans which are currently not certifiable by JSR-299 (as they don't implement any of the Java EE integrations) we should split the spec into core and Java EE integrations, and offer two modes within the TCK as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From EMIJIANG at uk.ibm.com Fri Oct 16 17:58:23 2015 From: EMIJIANG at uk.ibm.com (Emily Jiang) Date: Fri, 16 Oct 2015 22:58:23 +0100 Subject: [cdi-dev] Spec with TCK assertion In-Reply-To: References: Message-ID: <201510162159.t9GLxHqd026148@d06av04.portsmouth.uk.ibm.com> This is an awesome feature! Great job, Tomas! Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB From: Antoine Sabot-Durand To: cdi-dev , Date: 16/10/2015 09:19 Subject: [cdi-dev] Spec with TCK assertion Sent by: cdi-dev-bounces at lists.jboss.org Hi all, In case you missed it, I released the new version of spec including TCK assertion: http://www.cdi-spec.org/news/2015/10/15/Learn-CDI-with-TCK/ Thanks again to Tomas who did a smart job here Antoine_______________________________________________ cdi-dev mailing list cdi-dev at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151016/0e229d3a/attachment-0001.html From david.blevins at gmail.com Sat Oct 17 05:06:04 2015 From: david.blevins at gmail.com (David Blevins) Date: Sat, 17 Oct 2015 02:06:04 -0700 Subject: [cdi-dev] Adding Lambdas as CDI beans Message-ID: <7DC34D19-1B5E-4A25-B1F2-FB59045B0092@gmail.com> In brainstorming mode about fun that could be made possible with Java 8 and Java EE. Question in my mind is: is there some way we could make it possible for Lambdas or Method Refs to be CDI beans? It goes against the grain obviously as CDI creation is very much a ?Don?t call us, we?ll call you? kind of thing. The VM dynamically creates a wrapper object around the Lambda or method reference and it implements the given interface. To make it work, there would need to be some non-producer method way of saying ?put this thing in the context with these qualifiers?. Imagine a method somewhere that would allow you to: public void addObserver(java.util.function.Consumer observer, Annotation... qualifiers); Then you could take advantage as follows: final List uris = new ArrayList<>(); // @Observes URI addObserver((Consumer) uris::add); // @Observes Thread addObserver(Runtime.getRuntime()::addShutdownHook); // @Observes Runnable addObserver((Consumer) Executors.newFixedThreadPool(3)::submit); // @Observes URI addObserver((Consumer) System.out::println, new AnnotationLiteral() { }); // @Observes Handler final Logger logger = Logger.getLogger("somewhere"); addObserver(logger::addHandler); // add handlers via event // @Observes @Fine String addObserver((Consumer) logger::fine, new AnnotationLiteral() {}); } -David -- David Blevins http://twitter.com/dblevins http://www.tomitribe.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151017/865e6fe0/attachment.html From sven.linstaedt at gmail.com Sat Oct 17 07:51:40 2015 From: sven.linstaedt at gmail.com (Sven Linstaedt) Date: Sat, 17 Oct 2015 13:51:40 +0200 Subject: [cdi-dev] Adding Lambdas as CDI beans In-Reply-To: <7DC34D19-1B5E-4A25-B1F2-FB59045B0092@gmail.com> References: <7DC34D19-1B5E-4A25-B1F2-FB59045B0092@gmail.com> Message-ID: Just one question: Who is on charge and is able of managing this unmanaged instances, e.g. lifecycle, serialization, concurrency (e.g. when dealing with closures)? Functional programming and DI seem to be somehow disjunct in this case. E.g. manually setting up observers seem to better fit extension than normal application code. On the other side, specifying producer methods or fields, that are injectable and return lambda expressions seems to be a no brainier for CDI, is not it? As long as they are not scoped in a serializable context. Have a nice weekend Sven -- sent by phone > Am 17.10.2015 um 11:06 schrieb David Blevins : > > In brainstorming mode about fun that could be made possible with Java 8 and Java EE. > > Question in my mind is: is there some way we could make it possible for Lambdas or Method Refs to be CDI beans? > > It goes against the grain obviously as CDI creation is very much a ?Don?t call us, we?ll call you? kind of thing. The VM dynamically creates a wrapper object around the Lambda or method reference and it implements the given interface. > > To make it work, there would need to be some non-producer method way of saying ?put this thing in the context with these qualifiers?. > > Imagine a method somewhere that would allow you to: > > public void addObserver(java.util.function.Consumer observer, Annotation... qualifiers); > > > Then you could take advantage as follows: > > final List uris = new ArrayList<>(); > // @Observes URI > addObserver((Consumer) uris::add); > > // @Observes Thread > addObserver(Runtime.getRuntime()::addShutdownHook); > > // @Observes Runnable > addObserver((Consumer) Executors.newFixedThreadPool(3)::submit); > > // @Observes URI > addObserver((Consumer) System.out::println, new AnnotationLiteral() { > }); > > // @Observes Handler > final Logger logger = Logger.getLogger("somewhere"); > addObserver(logger::addHandler); // add handlers via event > > // @Observes @Fine String > addObserver((Consumer) logger::fine, new AnnotationLiteral() {}); > } > > > > -David > > > > -- > David Blevins > http://twitter.com/dblevins > http://www.tomitribe.com > > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151017/fe62d02d/attachment.html From john.d.ament at gmail.com Sat Oct 17 09:03:51 2015 From: john.d.ament at gmail.com (John D. Ament) Date: Sat, 17 Oct 2015 13:03:51 +0000 Subject: [cdi-dev] Adding Lambdas as CDI beans In-Reply-To: References: <7DC34D19-1B5E-4A25-B1F2-FB59045B0092@gmail.com> Message-ID: Sven, I'm a little curious, why do they need to avoid serializable contexts? In all honesty, I use app scoped functions, predicates in my code, at least in a couple of places. Lambdas are specifically meant for operations, not data, so they should be in a highly reusable scope (in my opinion at least). On the flip side, I have a hard time justifying needing to provide injectable beans for lambdas since good encapsulation should indicate they're only used in a single spot. John On Sat, Oct 17, 2015 at 7:51 AM Sven Linstaedt wrote: > Just one question: Who is on charge and is able of managing this unmanaged > instances, e.g. lifecycle, serialization, concurrency (e.g. when dealing > with closures)? > > Functional programming and DI seem to be somehow disjunct in this case. > E.g. manually setting up observers seem to better fit extension than normal > application code. > > On the other side, specifying producer methods or fields, that are > injectable and return lambda expressions seems to be a no brainier for CDI, > is not it? As long as they are not scoped in a serializable context. > > Have a nice weekend > Sven > > -- sent by phone > > Am 17.10.2015 um 11:06 schrieb David Blevins : > > In brainstorming mode about fun that could be made possible with Java 8 > and Java EE. > > Question in my mind is: is there some way we could make it possible for > Lambdas or Method Refs to be CDI beans? > > It goes against the grain obviously as CDI creation is very much a ?Don?t > call us, we?ll call you? kind of thing. The VM dynamically creates a > wrapper object around the Lambda or method reference and it implements the > given interface. > > To make it work, there would need to be some non-producer method way of > saying ?put this thing in the context with these qualifiers?. > > Imagine a method somewhere that would allow you to: > > public void addObserver(java.util.function.Consumer observer, > Annotation... qualifiers); > > > Then you could take advantage as follows: > > final List uris = new ArrayList<>(); > // @Observes URI > addObserver((Consumer) uris::add); > > // @Observes Thread > addObserver(Runtime.getRuntime()::addShutdownHook); > > // @Observes Runnable > addObserver((Consumer) > Executors.newFixedThreadPool(3)::submit); > > // @Observes URI > addObserver((Consumer) System.out::println, new > AnnotationLiteral() { > }); > > // @Observes Handler > final Logger logger = Logger.getLogger("somewhere"); > addObserver(logger::addHandler); // add handlers via event > > // @Observes @Fine String > addObserver((Consumer) logger::fine, new > AnnotationLiteral() {}); > } > > > > -David > > > > -- > David Blevins > http://twitter.com/dblevins > http://www.tomitribe.com > > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151017/a194ca18/attachment-0001.html From rmannibucau at gmail.com Sat Oct 17 09:36:41 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sat, 17 Oct 2015 15:36:41 +0200 Subject: [cdi-dev] Adding Lambdas as CDI beans In-Reply-To: References: <7DC34D19-1B5E-4A25-B1F2-FB59045B0092@gmail.com> Message-ID: Side note: lambda are serializable technically Le 17 oct. 2015 15:04, "John D. Ament" a ?crit : > Sven, > > I'm a little curious, why do they need to avoid serializable contexts? In > all honesty, I use app scoped functions, predicates in my code, at least in > a couple of places. Lambdas are specifically meant for operations, not > data, so they should be in a highly reusable scope (in my opinion at least). > > On the flip side, I have a hard time justifying needing to provide > injectable beans for lambdas since good encapsulation should indicate > they're only used in a single spot. > > John > > On Sat, Oct 17, 2015 at 7:51 AM Sven Linstaedt > wrote: > >> Just one question: Who is on charge and is able of managing this >> unmanaged instances, e.g. lifecycle, serialization, concurrency (e.g. when >> dealing with closures)? >> >> Functional programming and DI seem to be somehow disjunct in this case. >> E.g. manually setting up observers seem to better fit extension than normal >> application code. >> >> On the other side, specifying producer methods or fields, that are >> injectable and return lambda expressions seems to be a no brainier for CDI, >> is not it? As long as they are not scoped in a serializable context. >> >> Have a nice weekend >> Sven >> >> -- sent by phone >> >> Am 17.10.2015 um 11:06 schrieb David Blevins : >> >> In brainstorming mode about fun that could be made possible with Java 8 >> and Java EE. >> >> Question in my mind is: is there some way we could make it possible for >> Lambdas or Method Refs to be CDI beans? >> >> It goes against the grain obviously as CDI creation is very much a ?Don?t >> call us, we?ll call you? kind of thing. The VM dynamically creates a >> wrapper object around the Lambda or method reference and it implements the >> given interface. >> >> To make it work, there would need to be some non-producer method way of >> saying ?put this thing in the context with these qualifiers?. >> >> Imagine a method somewhere that would allow you to: >> >> public void addObserver(java.util.function.Consumer observer, >> Annotation... qualifiers); >> >> >> Then you could take advantage as follows: >> >> final List uris = new ArrayList<>(); >> // @Observes URI >> addObserver((Consumer) uris::add); >> >> // @Observes Thread >> addObserver(Runtime.getRuntime()::addShutdownHook); >> >> // @Observes Runnable >> addObserver((Consumer) >> Executors.newFixedThreadPool(3)::submit); >> >> // @Observes URI >> addObserver((Consumer) System.out::println, new >> AnnotationLiteral() { >> }); >> >> // @Observes Handler >> final Logger logger = Logger.getLogger("somewhere"); >> addObserver(logger::addHandler); // add handlers via event >> >> // @Observes @Fine String >> addObserver((Consumer) logger::fine, new >> AnnotationLiteral() {}); >> } >> >> >> >> -David >> >> >> >> -- >> David Blevins >> http://twitter.com/dblevins >> http://www.tomitribe.com >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151017/c490443d/attachment.html From sven.linstaedt at gmail.com Sat Oct 17 12:54:11 2015 From: sven.linstaedt at gmail.com (Sven Linstaedt) Date: Sat, 17 Oct 2015 18:54:11 +0200 Subject: [cdi-dev] Adding Lambdas as CDI beans In-Reply-To: References: <7DC34D19-1B5E-4A25-B1F2-FB59045B0092@gmail.com> Message-ID: <58C038CB-DAA8-4926-AE52-32308BF1197A@gmail.com> Hi John most, if not all Java 8 lambda types are not serializable afaik (sure, one can specify custom serializable lambdas, but I guess this happens rather rarely), so assigning a lambda typed bean a serializable context will probably always cause problems. Even the lamda type itself is serializable, it does not mean it's closure is. Even though application scoped lambda beans are in general no problem at all, most other contexts are. So the question is, whether to allow lambda typed bean to have any serializable scope at all. Don't get me wrong. I am a huge fan of Java 8 and functional programming in general, but I think FP's way of expressive design somehow collides with CDI's rather declarative style. At least for non-SPI code. Best regards Sven -- sent by phone > Am 17.10.2015 um 15:03 schrieb John D. Ament : > > Sven, > > I'm a little curious, why do they need to avoid serializable contexts? In all honesty, I use app scoped functions, predicates in my code, at least in a couple of places. Lambdas are specifically meant for operations, not data, so they should be in a highly reusable scope (in my opinion at least). > > On the flip side, I have a hard time justifying needing to provide injectable beans for lambdas since good encapsulation should indicate they're only used in a single spot. > > John > > On Sat, Oct 17, 2015 at 7:51 AM Sven Linstaedt wrote: >> Just one question: Who is on charge and is able of managing this unmanaged instances, e.g. lifecycle, serialization, concurrency (e.g. when dealing with closures)? >> >> Functional programming and DI seem to be somehow disjunct in this case. E.g. manually setting up observers seem to better fit extension than normal application code. >> >> On the other side, specifying producer methods or fields, that are injectable and return lambda expressions seems to be a no brainier for CDI, is not it? As long as they are not scoped in a serializable context. >> >> Have a nice weekend >> Sven >> >> -- sent by phone >> >>> Am 17.10.2015 um 11:06 schrieb David Blevins : >>> >>> In brainstorming mode about fun that could be made possible with Java 8 and Java EE. >>> >>> Question in my mind is: is there some way we could make it possible for Lambdas or Method Refs to be CDI beans? >>> >>> It goes against the grain obviously as CDI creation is very much a ?Don?t call us, we?ll call you? kind of thing. The VM dynamically creates a wrapper object around the Lambda or method reference and it implements the given interface. >>> >>> To make it work, there would need to be some non-producer method way of saying ?put this thing in the context with these qualifiers?. >>> >>> Imagine a method somewhere that would allow you to: >>> >>> public void addObserver(java.util.function.Consumer observer, Annotation... qualifiers); >>> >>> >>> Then you could take advantage as follows: >>> >>> final List uris = new ArrayList<>(); >>> // @Observes URI >>> addObserver((Consumer) uris::add); >>> >>> // @Observes Thread >>> addObserver(Runtime.getRuntime()::addShutdownHook); >>> >>> // @Observes Runnable >>> addObserver((Consumer) Executors.newFixedThreadPool(3)::submit); >>> >>> // @Observes URI >>> addObserver((Consumer) System.out::println, new AnnotationLiteral() { >>> }); >>> >>> // @Observes Handler >>> final Logger logger = Logger.getLogger("somewhere"); >>> addObserver(logger::addHandler); // add handlers via event >>> >>> // @Observes @Fine String >>> addObserver((Consumer) logger::fine, new AnnotationLiteral() {}); >>> } >>> >>> >>> >>> -David >>> >>> >>> >>> -- >>> David Blevins >>> http://twitter.com/dblevins >>> http://www.tomitribe.com >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151017/b0a2e2e7/attachment-0001.html From rmannibucau at gmail.com Sat Oct 17 12:57:24 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sat, 17 Oct 2015 18:57:24 +0200 Subject: [cdi-dev] Adding Lambdas as CDI beans In-Reply-To: <58C038CB-DAA8-4926-AE52-32308BF1197A@gmail.com> References: <7DC34D19-1B5E-4A25-B1F2-FB59045B0092@gmail.com> <58C038CB-DAA8-4926-AE52-32308BF1197A@gmail.com> Message-ID: 2015-10-17 18:54 GMT+02:00 Sven Linstaedt : > Hi John > > most, if not all Java 8 lambda types are not serializable afaik (sure, one > can specify custom serializable lambdas, but I guess this happens rather > rarely), so assigning a lambda typed bean a serializable context will > probably always cause problems. Even the lamda type itself is serializable, > it does not mean it's closure is. Even though application scoped lambda > beans are in general no problem at all, most other contexts are. So the > question is, whether to allow lambda typed bean to have any serializable > scope at all. > > java.lang.invoke.SerializedLambda is done for that so should be > Don't get me wrong. I am a huge fan of Java 8 and functional programming > in general, but I think FP's way of expressive design somehow collides with > CDI's rather declarative style. At least for non-SPI code. > > Same here, I think a good API should deserve it. Being able to bind in an extension or through an event not needed a SPI file a lambda would be great but I think we are out of CDI - as backbone - scope there. Maybe doing a proto using custom events can help to play with it and see what we can do of it. > Best regards > Sven > > -- sent by phone > > Am 17.10.2015 um 15:03 schrieb John D. Ament : > > Sven, > > I'm a little curious, why do they need to avoid serializable contexts? In > all honesty, I use app scoped functions, predicates in my code, at least in > a couple of places. Lambdas are specifically meant for operations, not > data, so they should be in a highly reusable scope (in my opinion at least). > > On the flip side, I have a hard time justifying needing to provide > injectable beans for lambdas since good encapsulation should indicate > they're only used in a single spot. > > John > > On Sat, Oct 17, 2015 at 7:51 AM Sven Linstaedt > wrote: > >> Just one question: Who is on charge and is able of managing this >> unmanaged instances, e.g. lifecycle, serialization, concurrency (e.g. when >> dealing with closures)? >> >> Functional programming and DI seem to be somehow disjunct in this case. >> E.g. manually setting up observers seem to better fit extension than normal >> application code. >> >> On the other side, specifying producer methods or fields, that are >> injectable and return lambda expressions seems to be a no brainier for CDI, >> is not it? As long as they are not scoped in a serializable context. >> >> Have a nice weekend >> Sven >> >> -- sent by phone >> >> Am 17.10.2015 um 11:06 schrieb David Blevins : >> >> In brainstorming mode about fun that could be made possible with Java 8 >> and Java EE. >> >> Question in my mind is: is there some way we could make it possible for >> Lambdas or Method Refs to be CDI beans? >> >> It goes against the grain obviously as CDI creation is very much a ?Don?t >> call us, we?ll call you? kind of thing. The VM dynamically creates a >> wrapper object around the Lambda or method reference and it implements the >> given interface. >> >> To make it work, there would need to be some non-producer method way of >> saying ?put this thing in the context with these qualifiers?. >> >> Imagine a method somewhere that would allow you to: >> >> public void addObserver(java.util.function.Consumer observer, >> Annotation... qualifiers); >> >> >> Then you could take advantage as follows: >> >> final List uris = new ArrayList<>(); >> // @Observes URI >> addObserver((Consumer) uris::add); >> >> // @Observes Thread >> addObserver(Runtime.getRuntime()::addShutdownHook); >> >> // @Observes Runnable >> addObserver((Consumer) >> Executors.newFixedThreadPool(3)::submit); >> >> // @Observes URI >> addObserver((Consumer) System.out::println, new >> AnnotationLiteral() { >> }); >> >> // @Observes Handler >> final Logger logger = Logger.getLogger("somewhere"); >> addObserver(logger::addHandler); // add handlers via event >> >> // @Observes @Fine String >> addObserver((Consumer) logger::fine, new >> AnnotationLiteral() {}); >> } >> >> >> >> -David >> >> >> >> -- >> David Blevins >> http://twitter.com/dblevins >> http://www.tomitribe.com >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at 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 at 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 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151017/e602f92e/attachment.html From issues at jboss.org Sun Oct 18 07:22:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 18 Oct 2015 07:22:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-547) Resolving sync/async observer methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119247#comment-13119247 ] Antoine Sabot-Durand commented on CDI-547: ------------------------------------------ IMO {{resolveObserverMethods}} should be "synchronous agnostic". The idea behind this method is to provide a way perform TypeSafe resolution for observers. In JDK8 it's quite easy to filter the returned set to get sync or async if it's needed. Regarding confusion, as this method is reserved to advanced developers I don't see it as a real issue. > Resolving sync/async observer methods > ------------------------------------- > > Key: CDI-547 > URL: https://issues.jboss.org/browse/CDI-547 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Jozef Hartinger > > There's the [BeanManager.resolveObserverMethods()|http://docs.jboss.org/cdi/api/2.0.EDR1/javax/enterprise/inject/spi/BeanManager.html#resolveObserverMethods-T-java.lang.annotation.Annotation...-] method for resolving observer methods. > With addition of sync/async events and observers it is not unclear what the semantics of this methods are. We'll most likely need to add new or overloaded methods to make it possible to resolve observers for sync/async events. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 18 07:53:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 18 Oct 2015 07:53:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-541) Ordering of async observers (vs sync observers) is not specified In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119248#comment-13119248 ] Antoine Sabot-Durand commented on CDI-541: ------------------------------------------ I suggest that we support ordering in Async Event. The idea behind async event is not to optimize asynchronous treatment but to allow people to fire and forget (or deal later) an event. Now that we decide to split async from sync obervers invocation, confusion there won't be confusion on th topic Providing ordering for async add more feature and helps build more use case for end users. Implementation would be free to use multi thread for events sharing the same priority. > Ordering of async observers (vs sync observers) is not specified > ---------------------------------------------------------------- > > Key: CDI-541 > URL: https://issues.jboss.org/browse/CDI-541 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Tomas Remes > > I think this needs to be specified. E.g. what happens if I fire async event and have more matching sync and async observers? Are all sync observes called first in given order with no regard to async observers priority? > For example: > {{event.fireAsync(new Message());}} > {code} > public class First { > > void observeMessage(@Observes @Priority(2000) Message message){} > } > {code} > {code} > public class Second { > > void observeMessage(@ObservesAsync @Priority(2100) Message message){} > } > {code} > {code} > public class Third { > > void observeMessage(@Observes @Priority(2200) Message message){} > } > {code} > {code} > public class Fourth { > > void observeMessage(@ObservesAsync @Priority(2300) Message message){} > } > {code} > What will be the order in this case? First, Third, Second, Fourth? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 18 16:42:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sun, 18 Oct 2015 16:42:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-563) Event.fireAsync() - clarify the usage of the returned CompletionStage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119253#comment-13119253 ] Antoine Sabot-Durand commented on CDI-563: ------------------------------------------ I'm not sure to get your point. We are using API (and impl) provided by Java 8. Async event behavior won't be more confusing than this standard API. Regarding context propagation as we said we won't support it, I don't think it'll be a problem > Event.fireAsync() - clarify the usage of the returned CompletionStage > --------------------------------------------------------------------- > > Key: CDI-563 > URL: https://issues.jboss.org/browse/CDI-563 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Martin Kouba > > So far {{CompletionStage}} is only mentioned in "10.5.1. Handling multiple exceptions thrown during an asynchronous event" and the {{Event.fireAsync()}} javadoc is too general. However, the {{CompletionStage}} itself does not define an unambiguous contract for its methods. E.g. what thread is used to execute a given callback? Or what's the _"stage's default asynchronous execution facility"_? I believe this is left on implementors. In Weld 3.0 Alpha we're using {{CompletableFuture}} under the hood, and its more concrete in this area, e.g.: > {quote} > * Actions supplied for dependent completions of _non-async_ methods may be performed by the thread that completes the current CompletableFuture, or by any other caller of a completion method. > {quote} > So as a result, if an async delivery is finished before a sync dependent action is registered, the callback is executed in the caller thread: > {code:java} > event.fireAsync(new Message()).thenAccept((m) -> System.out.println("This might be executed in a caller thread or in a different thread!")); > {code} > And this might be confusing. Especially from the context propagation point of view. I think the spec should clarify the contract of a returned {{CompletionStage}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 19 02:12:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 19 Oct 2015 02:12:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-563) Event.fireAsync() - clarify the usage of the returned CompletionStage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119273#comment-13119273 ] Martin Kouba commented on CDI-563: ---------------------------------- Ok, so first the CompletionStage API itself does not define the behavior completely. E.g. "default asynchronous execution facility" is left on implementors - and CDI is de facto an implementor. If we don't state anything it's unspecified. And I don't believe this part of the spec should be a place for experiments. Re context propagation - that's just the one of the clarifications I'm talking about. I think that if we don't specify anything, users would expect contexts to always work. > Event.fireAsync() - clarify the usage of the returned CompletionStage > --------------------------------------------------------------------- > > Key: CDI-563 > URL: https://issues.jboss.org/browse/CDI-563 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Martin Kouba > > So far {{CompletionStage}} is only mentioned in "10.5.1. Handling multiple exceptions thrown during an asynchronous event" and the {{Event.fireAsync()}} javadoc is too general. However, the {{CompletionStage}} itself does not define an unambiguous contract for its methods. E.g. what thread is used to execute a given callback? Or what's the _"stage's default asynchronous execution facility"_? I believe this is left on implementors. In Weld 3.0 Alpha we're using {{CompletableFuture}} under the hood, and its more concrete in this area, e.g.: > {quote} > * Actions supplied for dependent completions of _non-async_ methods may be performed by the thread that completes the current CompletableFuture, or by any other caller of a completion method. > {quote} > So as a result, if an async delivery is finished before a sync dependent action is registered, the callback is executed in the caller thread: > {code:java} > event.fireAsync(new Message()).thenAccept((m) -> System.out.println("This might be executed in a caller thread or in a different thread!")); > {code} > And this might be confusing. Especially from the context propagation point of view. I think the spec should clarify the contract of a returned {{CompletionStage}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 19 02:27:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 19 Oct 2015 02:27:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-547) Resolving sync/async observer methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119274#comment-13119274 ] Martin Kouba commented on CDI-547: ---------------------------------- +1 WRT confusion - I don't see a problem anymore, my previous comment was created in the time when {{fire()}} was used for async events as well (EDR1). > Resolving sync/async observer methods > ------------------------------------- > > Key: CDI-547 > URL: https://issues.jboss.org/browse/CDI-547 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Jozef Hartinger > > There's the [BeanManager.resolveObserverMethods()|http://docs.jboss.org/cdi/api/2.0.EDR1/javax/enterprise/inject/spi/BeanManager.html#resolveObserverMethods-T-java.lang.annotation.Annotation...-] method for resolving observer methods. > With addition of sync/async events and observers it is not unclear what the semantics of this methods are. We'll most likely need to add new or overloaded methods to make it possible to resolve observers for sync/async events. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From mkouba at redhat.com Mon Oct 19 02:40:49 2015 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 19 Oct 2015 08:40:49 +0200 Subject: [cdi-dev] Adding Lambdas as CDI beans In-Reply-To: References: <7DC34D19-1B5E-4A25-B1F2-FB59045B0092@gmail.com> Message-ID: <56249071.3060609@redhat.com> In CDI 2.0 we propose to support lambdas in the bean builder API - currently available as a weld experimental feature in AfterBeanDiscovery and Weld SE - see also [1] and [2]. For observers a similar builder might be useful. Martin [1] http://weld.cdi-spec.org/news/2015/02/25/weld-300Alpha5/#_bean_builder_api [2] https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/extensions/custombeans/BuilderExtension.java Dne 17.10.2015 v 13:51 Sven Linstaedt napsal(a): > Just one question: Who is on charge and is able of managing this > unmanaged instances, e.g. lifecycle, serialization, concurrency (e.g. > when dealing with closures)? > > Functional programming and DI seem to be somehow disjunct in this case. > E.g. manually setting up observers seem to better fit extension than > normal application code. > > On the other side, specifying producer methods or fields, that are > injectable and return lambda expressions seems to be a no brainier for > CDI, is not it? As long as they are not scoped in a serializable context. > > Have a nice weekend > Sven > > -- sent by phone > > Am 17.10.2015 um 11:06 schrieb David Blevins >: > >> In brainstorming mode about fun that could be made possible with Java >> 8 and Java EE. >> >> Question in my mind is: is there some way we could make it possible >> for Lambdas or Method Refs to be CDI beans? >> >> It goes against the grain obviously as CDI creation is very much a >> ?Don?t call us, we?ll call you? kind of thing. The VM dynamically >> creates a wrapper object around the Lambda or method reference and it >> implements the given interface. >> >> To make it work, there would need to be some non-producer method way >> of saying ?put this thing in the context with these qualifiers?. >> >> Imagine a method somewhere that would allow you to: >> >> public void addObserver(java.util.function.Consumer >> observer, Annotation... qualifiers); >> >> >> Then you could take advantage as follows: >> >> final List uris = new ArrayList<>(); >> // @Observes URI >> addObserver((Consumer) uris::add); >> >> // @Observes Thread >> addObserver(Runtime.getRuntime()::addShutdownHook); >> >> // @Observes Runnable >> addObserver((Consumer) >> Executors.newFixedThreadPool(3)::submit); >> >> // @Observes URI >> addObserver((Consumer) System.out::println, new >> AnnotationLiteral() { >> }); >> >> // @Observes Handler >> final Logger logger = Logger.getLogger("somewhere"); >> addObserver(logger::addHandler); // add handlers via event >> >> // @Observes @Fine String >> addObserver((Consumer) logger::fine, new >> AnnotationLiteral() {}); >> } >> >> >> >> -David >> >> >> >> -- >> David Blevins >> http://twitter.com/dblevins >> http://www.tomitribe.com >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at 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 at 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. > -- Martin Kouba Software Engineer Red Hat, Czech Republic From rmannibucau at gmail.com Mon Oct 19 02:44:12 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 19 Oct 2015 08:44:12 +0200 Subject: [cdi-dev] Adding Lambdas as CDI beans In-Reply-To: <56249071.3060609@redhat.com> References: <7DC34D19-1B5E-4A25-B1F2-FB59045B0092@gmail.com> <56249071.3060609@redhat.com> Message-ID: would be super cool to not have to write an extension for that, cant we use applicationscope init event or an prioritized event at this moment - avoiding the spi is a must for end user usage IMO? Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-10-19 8:40 GMT+02:00 Martin Kouba : > In CDI 2.0 we propose to support lambdas in the bean builder API - > currently available as a weld experimental feature in AfterBeanDiscovery > and Weld SE - see also [1] and [2]. > > For observers a similar builder might be useful. > > Martin > > [1] > http://weld.cdi-spec.org/news/2015/02/25/weld-300Alpha5/#_bean_builder_api > > [2] > > https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/extensions/custombeans/BuilderExtension.java > > > > Dne 17.10.2015 v 13:51 Sven Linstaedt napsal(a): > > Just one question: Who is on charge and is able of managing this > > unmanaged instances, e.g. lifecycle, serialization, concurrency (e.g. > > when dealing with closures)? > > > > Functional programming and DI seem to be somehow disjunct in this case. > > E.g. manually setting up observers seem to better fit extension than > > normal application code. > > > > On the other side, specifying producer methods or fields, that are > > injectable and return lambda expressions seems to be a no brainier for > > CDI, is not it? As long as they are not scoped in a serializable context. > > > > Have a nice weekend > > Sven > > > > -- sent by phone > > > > Am 17.10.2015 um 11:06 schrieb David Blevins > >: > > > >> In brainstorming mode about fun that could be made possible with Java > >> 8 and Java EE. > >> > >> Question in my mind is: is there some way we could make it possible > >> for Lambdas or Method Refs to be CDI beans? > >> > >> It goes against the grain obviously as CDI creation is very much a > >> ?Don?t call us, we?ll call you? kind of thing. The VM dynamically > >> creates a wrapper object around the Lambda or method reference and it > >> implements the given interface. > >> > >> To make it work, there would need to be some non-producer method way > >> of saying ?put this thing in the context with these qualifiers?. > >> > >> Imagine a method somewhere that would allow you to: > >> > >> public void addObserver(java.util.function.Consumer > >> observer, Annotation... qualifiers); > >> > >> > >> Then you could take advantage as follows: > >> > >> final List uris = new ArrayList<>(); > >> // @Observes URI > >> addObserver((Consumer) uris::add); > >> > >> // @Observes Thread > >> addObserver(Runtime.getRuntime()::addShutdownHook); > >> > >> // @Observes Runnable > >> addObserver((Consumer) > >> Executors.newFixedThreadPool(3)::submit); > >> > >> // @Observes URI > >> addObserver((Consumer) System.out::println, new > >> AnnotationLiteral() { > >> }); > >> > >> // @Observes Handler > >> final Logger logger = Logger.getLogger("somewhere"); > >> addObserver(logger::addHandler); // add handlers via event > >> > >> // @Observes @Fine String > >> addObserver((Consumer) logger::fine, new > >> AnnotationLiteral() {}); > >> } > >> > >> > >> > >> -David > >> > >> > >> > >> -- > >> David Blevins > >> http://twitter.com/dblevins > >> http://www.tomitribe.com > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at 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 at 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. > > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151019/0253b4c4/attachment.html From issues at jboss.org Mon Oct 19 02:50:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 19 Oct 2015 02:50:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-541) Ordering of async observers (vs sync observers) is not specified In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119276#comment-13119276 ] Martin Kouba commented on CDI-541: ---------------------------------- +1 For this proposal. > Ordering of async observers (vs sync observers) is not specified > ---------------------------------------------------------------- > > Key: CDI-541 > URL: https://issues.jboss.org/browse/CDI-541 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Tomas Remes > > I think this needs to be specified. E.g. what happens if I fire async event and have more matching sync and async observers? Are all sync observes called first in given order with no regard to async observers priority? > For example: > {{event.fireAsync(new Message());}} > {code} > public class First { > > void observeMessage(@Observes @Priority(2000) Message message){} > } > {code} > {code} > public class Second { > > void observeMessage(@ObservesAsync @Priority(2100) Message message){} > } > {code} > {code} > public class Third { > > void observeMessage(@Observes @Priority(2200) Message message){} > } > {code} > {code} > public class Fourth { > > void observeMessage(@ObservesAsync @Priority(2300) Message message){} > } > {code} > What will be the order in this case? First, Third, Second, Fourth? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From mkouba at redhat.com Mon Oct 19 03:17:02 2015 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 19 Oct 2015 09:17:02 +0200 Subject: [cdi-dev] Adding Lambdas as CDI beans In-Reply-To: References: <7DC34D19-1B5E-4A25-B1F2-FB59045B0092@gmail.com> <56249071.3060609@redhat.com> Message-ID: <562498EE.3020604@redhat.com> Dne 19.10.2015 v 08:44 Romain Manni-Bucau napsal(a): > would be super cool to not have to write an extension for that, cant we > use applicationscope init event or an prioritized event at this moment - > avoiding the spi is a must for end user usage IMO? Not possible, it's too late. ApplicationScoped init event is fired after the deployment validation. Well, maybe it's not that explicitly defined but it wouldn't make much sense to fire it before validation as you have to resolve a set of validated observers, usually declared on validated beans. > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2015-10-19 8:40 GMT+02:00 Martin Kouba >: > > In CDI 2.0 we propose to support lambdas in the bean builder API - > currently available as a weld experimental feature in AfterBeanDiscovery > and Weld SE - see also [1] and [2]. > > For observers a similar builder might be useful. > > Martin > > [1] > http://weld.cdi-spec.org/news/2015/02/25/weld-300Alpha5/#_bean_builder_api > > [2] > https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/extensions/custombeans/BuilderExtension.java > > > > Dne 17.10.2015 v 13:51 Sven Linstaedt napsal(a): > > Just one question: Who is on charge and is able of managing this > > unmanaged instances, e.g. lifecycle, serialization, concurrency (e.g. > > when dealing with closures)? > > > > Functional programming and DI seem to be somehow disjunct in this case. > > E.g. manually setting up observers seem to better fit extension than > > normal application code. > > > > On the other side, specifying producer methods or fields, that are > > injectable and return lambda expressions seems to be a no brainier for > > CDI, is not it? As long as they are not scoped in a serializable context. > > > > Have a nice weekend > > Sven > > > > -- sent by phone > > > > Am 17.10.2015 um 11:06 schrieb David Blevins > > >>: > > > >> In brainstorming mode about fun that could be made possible with > Java > >> 8 and Java EE. > >> > >> Question in my mind is: is there some way we could make it possible > >> for Lambdas or Method Refs to be CDI beans? > >> > >> It goes against the grain obviously as CDI creation is very much a > >> ?Don?t call us, we?ll call you? kind of thing. The VM dynamically > >> creates a wrapper object around the Lambda or method reference > and it > >> implements the given interface. > >> > >> To make it work, there would need to be some non-producer method way > >> of saying ?put this thing in the context with these qualifiers?. > >> > >> Imagine a method somewhere that would allow you to: > >> > >> public void addObserver(java.util.function.Consumer > >> observer, Annotation... qualifiers); > >> > >> > >> Then you could take advantage as follows: > >> > >> final List uris = new ArrayList<>(); > >> // @Observes URI > >> addObserver((Consumer) uris::add); > >> > >> // @Observes Thread > >> addObserver(Runtime.getRuntime()::addShutdownHook); > >> > >> // @Observes Runnable > >> addObserver((Consumer) > >> Executors.newFixedThreadPool(3)::submit); > >> > >> // @Observes URI > >> addObserver((Consumer) System.out::println, new > >> AnnotationLiteral() { > >> }); > >> > >> // @Observes Handler > >> final Logger logger = Logger.getLogger("somewhere"); > >> addObserver(logger::addHandler); // add handlers via event > >> > >> // @Observes @Fine String > >> addObserver((Consumer) logger::fine, new > >> AnnotationLiteral() {}); > >> } > >> > >> > >> > >> -David > >> > >> > >> > >> -- > >> David Blevins > >> http://twitter.com/dblevins > >> http://www.tomitribe.com > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at 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 at 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. > > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. > > -- Martin Kouba Software Engineer Red Hat, Czech Republic From rmannibucau at gmail.com Mon Oct 19 03:19:32 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 19 Oct 2015 09:19:32 +0200 Subject: [cdi-dev] Adding Lambdas as CDI beans In-Reply-To: <562498EE.3020604@redhat.com> References: <7DC34D19-1B5E-4A25-B1F2-FB59045B0092@gmail.com> <56249071.3060609@redhat.com> <562498EE.3020604@redhat.com> Message-ID: 2015-10-19 9:17 GMT+02:00 Martin Kouba : > Dne 19.10.2015 v 08:44 Romain Manni-Bucau napsal(a): > >> would be super cool to not have to write an extension for that, cant we >> use applicationscope init event or an prioritized event at this moment - >> avoiding the spi is a must for end user usage IMO? >> > > Not possible, it's too late. ApplicationScoped init event is fired after > the deployment validation. Well, maybe it's not that explicitly defined but > it wouldn't make much sense to fire it before validation as you have to > resolve a set of validated observers, usually declared on validated beans. > > we speak about cdi 2.0 so all is possible, i think all places would work but to be used it should respect the lightweight programmatic model of business beans of CDI. The SPI is always a "let's do differently" - was only my point. Side note: since you add beans you should do it before the validation as well but means you cant skip Extension which is a pain :( > >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> 2015-10-19 8:40 GMT+02:00 Martin Kouba > >: >> >> In CDI 2.0 we propose to support lambdas in the bean builder API - >> currently available as a weld experimental feature in >> AfterBeanDiscovery >> and Weld SE - see also [1] and [2]. >> >> For observers a similar builder might be useful. >> >> Martin >> >> [1] >> >> http://weld.cdi-spec.org/news/2015/02/25/weld-300Alpha5/#_bean_builder_api >> >> [2] >> >> https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/extensions/custombeans/BuilderExtension.java >> >> >> >> Dne 17.10.2015 v 13:51 Sven Linstaedt napsal(a): >> > Just one question: Who is on charge and is able of managing this >> > unmanaged instances, e.g. lifecycle, serialization, concurrency >> (e.g. >> > when dealing with closures)? >> > >> > Functional programming and DI seem to be somehow disjunct in this >> case. >> > E.g. manually setting up observers seem to better fit extension than >> > normal application code. >> > >> > On the other side, specifying producer methods or fields, that are >> > injectable and return lambda expressions seems to be a no brainier >> for >> > CDI, is not it? As long as they are not scoped in a serializable >> context. >> > >> > Have a nice weekend >> > Sven >> > >> > -- sent by phone >> > >> > Am 17.10.2015 um 11:06 schrieb David Blevins < >> david.blevins at gmail.com >> > > >>>: >> >> > >> >> In brainstorming mode about fun that could be made possible with >> Java >> >> 8 and Java EE. >> >> >> >> Question in my mind is: is there some way we could make it >> possible >> >> for Lambdas or Method Refs to be CDI beans? >> >> >> >> It goes against the grain obviously as CDI creation is very much a >> >> ?Don?t call us, we?ll call you? kind of thing. The VM dynamically >> >> creates a wrapper object around the Lambda or method reference >> and it >> >> implements the given interface. >> >> >> >> To make it work, there would need to be some non-producer method >> way >> >> of saying ?put this thing in the context with these qualifiers?. >> >> >> >> Imagine a method somewhere that would allow you to: >> >> >> >> public void addObserver(java.util.function.Consumer >> >> observer, Annotation... qualifiers); >> >> >> >> >> >> Then you could take advantage as follows: >> >> >> >> final List uris = new ArrayList<>(); >> >> // @Observes URI >> >> addObserver((Consumer) uris::add); >> >> >> >> // @Observes Thread >> >> addObserver(Runtime.getRuntime()::addShutdownHook); >> >> >> >> // @Observes Runnable >> >> addObserver((Consumer) >> >> Executors.newFixedThreadPool(3)::submit); >> >> >> >> // @Observes URI >> >> addObserver((Consumer) System.out::println, new >> >> AnnotationLiteral() { >> >> }); >> >> >> >> // @Observes Handler >> >> final Logger logger = Logger.getLogger("somewhere"); >> >> addObserver(logger::addHandler); // add handlers via event >> >> >> >> // @Observes @Fine String >> >> addObserver((Consumer) logger::fine, new >> >> AnnotationLiteral() {}); >> >> } >> >> >> >> >> >> >> >> -David >> >> >> >> >> >> >> >> -- >> >> David Blevins >> >> http://twitter.com/dblevins >> >> http://www.tomitribe.com >> >> >> >> _______________________________________________ >> >> cdi-dev mailing list >> >> cdi-dev at 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 at 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. >> > >> >> -- >> Martin Kouba >> Software Engineer >> Red Hat, Czech Republic >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at 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. >> >> >> > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151019/ceb8d036/attachment.html From issues at jboss.org Mon Oct 19 10:37:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 19 Oct 2015 10:37:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-563) Event.fireAsync() - clarify the usage of the returned CompletionStage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119499#comment-13119499 ] Antoine Sabot-Durand commented on CDI-563: ------------------------------------------ My first idea was to go directly for {{CompletableFuture}} in our API (methods return type, etc...). [~jharting] raised concerns about using an impl where an API exist (I agreed with him) and features in CompletableFuture that we might not allow our users to have access to (I'm not sure to follow him there, especially when {{CompletionStage}} has a dependency on {{CompletableFuture}} with the {{toCompletableFuture()}} method). So even if we won't expose CompletableFuture in our API for good practices, we won't reimplement what was nicely done in JDK8 and will use {{CompletableFuture}} under the hood. That's why I dont think we can say CDI will be an implementor of {{CompletionStage}}, we will be a user of {{CompletableFuture}} thru its main interface. The only open question, IMO, is about default {{Executor}} used in {{CompletableFuture}} (based on fork/join if I'm not mistaken). [~mkouba], you're probably the best person to know if this default Executor is the best for us or if we should use our own {{Executor}} (CompletableFuture has methods to override default executor). So, unless I missed something, either we specify the behavior from default Executor in {{completableFuture}} or define ours. The user will always have the possibility to use her own Executor with the dedicated {{fireAsync()}} method. > Event.fireAsync() - clarify the usage of the returned CompletionStage > --------------------------------------------------------------------- > > Key: CDI-563 > URL: https://issues.jboss.org/browse/CDI-563 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Martin Kouba > > So far {{CompletionStage}} is only mentioned in "10.5.1. Handling multiple exceptions thrown during an asynchronous event" and the {{Event.fireAsync()}} javadoc is too general. However, the {{CompletionStage}} itself does not define an unambiguous contract for its methods. E.g. what thread is used to execute a given callback? Or what's the _"stage's default asynchronous execution facility"_? I believe this is left on implementors. In Weld 3.0 Alpha we're using {{CompletableFuture}} under the hood, and its more concrete in this area, e.g.: > {quote} > * Actions supplied for dependent completions of _non-async_ methods may be performed by the thread that completes the current CompletableFuture, or by any other caller of a completion method. > {quote} > So as a result, if an async delivery is finished before a sync dependent action is registered, the callback is executed in the caller thread: > {code:java} > event.fireAsync(new Message()).thenAccept((m) -> System.out.println("This might be executed in a caller thread or in a different thread!")); > {code} > And this might be confusing. Especially from the context propagation point of view. I think the spec should clarify the contract of a returned {{CompletionStage}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 19 11:06:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 19 Oct 2015 11:06:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-563) Event.fireAsync() - clarify the usage of the returned CompletionStage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119519#comment-13119519 ] Martin Kouba commented on CDI-563: ---------------------------------- bq. I'm not sure to follow him there, especially when CompletionStage has a dependency on CompletableFuture with the toCompletableFuture() method It's kind of a strange dependency, intended probably as a compatibility/interoperation feature. However, implementations are not required to support this conversion. bq. Martin Kouba, you're probably the best person to know if this default Executor is the best for us or if we should use our own Executor... I don't think {{ForkJoinPool.commonPool()}} is a good fit for Java EE. But it's ok for Java SE. I'm for: * having {{CompletionStage}} in the CDI API * declaring explicitly that *the stage's default asynchronous execution facility is not defined*, in other words it is implementor and environment specific * declaring explicitly that *the context propagation is not guaranteed for asynchronous execution* (both the default and custom executor) What do you think? > Event.fireAsync() - clarify the usage of the returned CompletionStage > --------------------------------------------------------------------- > > Key: CDI-563 > URL: https://issues.jboss.org/browse/CDI-563 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Martin Kouba > > So far {{CompletionStage}} is only mentioned in "10.5.1. Handling multiple exceptions thrown during an asynchronous event" and the {{Event.fireAsync()}} javadoc is too general. However, the {{CompletionStage}} itself does not define an unambiguous contract for its methods. E.g. what thread is used to execute a given callback? Or what's the _"stage's default asynchronous execution facility"_? I believe this is left on implementors. In Weld 3.0 Alpha we're using {{CompletableFuture}} under the hood, and its more concrete in this area, e.g.: > {quote} > * Actions supplied for dependent completions of _non-async_ methods may be performed by the thread that completes the current CompletableFuture, or by any other caller of a completion method. > {quote} > So as a result, if an async delivery is finished before a sync dependent action is registered, the callback is executed in the caller thread: > {code:java} > event.fireAsync(new Message()).thenAccept((m) -> System.out.println("This might be executed in a caller thread or in a different thread!")); > {code} > And this might be confusing. Especially from the context propagation point of view. I think the spec should clarify the contract of a returned {{CompletionStage}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 19 11:10:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 19 Oct 2015 11:10:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-563) Event.fireAsync() - clarify the usage of the returned CompletionStage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119519#comment-13119519 ] Martin Kouba edited comment on CDI-563 at 10/19/15 11:09 AM: ------------------------------------------------------------- bq. I'm not sure to follow him there, especially when CompletionStage has a dependency on CompletableFuture with the toCompletableFuture() method It's kind of a strange dependency, intended probably as a compatibility/interoperation feature. However, implementations are not required to support this conversion. bq. Martin Kouba, you're probably the best person to know if this default Executor is the best for us or if we should use our own Executor... I don't think {{ForkJoinPool.commonPool()}} is a good fit for Java EE. But it's ok for Java SE. I'm for: * having {{CompletionStage}} in the CDI API * declaring explicitly that *the stage's default asynchronous execution facility is not defined*, in other words it is implementor and environment specific * declaring explicitly that *the context propagation is not guaranteed for ANY execution* (default execution, default async execution and custom async via a supplied Executor) What do you think? was (Author: mkouba): bq. I'm not sure to follow him there, especially when CompletionStage has a dependency on CompletableFuture with the toCompletableFuture() method It's kind of a strange dependency, intended probably as a compatibility/interoperation feature. However, implementations are not required to support this conversion. bq. Martin Kouba, you're probably the best person to know if this default Executor is the best for us or if we should use our own Executor... I don't think {{ForkJoinPool.commonPool()}} is a good fit for Java EE. But it's ok for Java SE. I'm for: * having {{CompletionStage}} in the CDI API * declaring explicitly that *the stage's default asynchronous execution facility is not defined*, in other words it is implementor and environment specific * declaring explicitly that *the context propagation is not guaranteed for asynchronous execution* (both the default and custom executor) What do you think? > Event.fireAsync() - clarify the usage of the returned CompletionStage > --------------------------------------------------------------------- > > Key: CDI-563 > URL: https://issues.jboss.org/browse/CDI-563 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Martin Kouba > > So far {{CompletionStage}} is only mentioned in "10.5.1. Handling multiple exceptions thrown during an asynchronous event" and the {{Event.fireAsync()}} javadoc is too general. However, the {{CompletionStage}} itself does not define an unambiguous contract for its methods. E.g. what thread is used to execute a given callback? Or what's the _"stage's default asynchronous execution facility"_? I believe this is left on implementors. In Weld 3.0 Alpha we're using {{CompletableFuture}} under the hood, and its more concrete in this area, e.g.: > {quote} > * Actions supplied for dependent completions of _non-async_ methods may be performed by the thread that completes the current CompletableFuture, or by any other caller of a completion method. > {quote} > So as a result, if an async delivery is finished before a sync dependent action is registered, the callback is executed in the caller thread: > {code:java} > event.fireAsync(new Message()).thenAccept((m) -> System.out.println("This might be executed in a caller thread or in a different thread!")); > {code} > And this might be confusing. Especially from the context propagation point of view. I think the spec should clarify the contract of a returned {{CompletionStage}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From dblevins at tomitribe.com Sat Oct 17 05:04:46 2015 From: dblevins at tomitribe.com (David Blevins) Date: Sat, 17 Oct 2015 02:04:46 -0700 Subject: [cdi-dev] Adding Lambdas as CDI beans Message-ID: <35656E05-57C1-41EA-B611-DB85F9696641@tomitribe.com> In brainstorming mode about fun that could be made possible with Java 8 and Java EE. Question in my mind is: is there some way we could make it possible for Lambdas or Method Refs to be CDI beans? It goes against the grain obviously as CDI creation is very much a ?Don?t call us, we?ll call you? kind of thing. The VM dynamically creates a wrapper object around the Lambda or method reference and it implements the given interface. To make it work, there would need to be some non-producer method way of saying ?put this thing in the context with these qualifiers?. Imagine a method somewhere that would allow you to: public void addObserver(java.util.function.Consumer observer, Annotation... qualifiers); Then you could take advantage as follows: final List uris = new ArrayList<>(); // @Observes URI addObserver((Consumer) uris::add); // @Observes Thread addObserver(Runtime.getRuntime()::addShutdownHook); // @Observes Runnable addObserver((Consumer) Executors.newFixedThreadPool(3)::submit); // @Observes URI addObserver((Consumer) System.out::println, new AnnotationLiteral() { }); // @Observes Handler final Logger logger = Logger.getLogger("somewhere"); addObserver(logger::addHandler); // add handlers via event // @Observes @Fine String addObserver((Consumer) logger::fine, new AnnotationLiteral() {}); } -David From cdewolf at redhat.com Mon Oct 19 14:20:22 2015 From: cdewolf at redhat.com (Carlo de Wolf) Date: Mon, 19 Oct 2015 20:20:22 +0200 Subject: [cdi-dev] Adding Lambdas as CDI beans In-Reply-To: References: <7DC34D19-1B5E-4A25-B1F2-FB59045B0092@gmail.com> <58C038CB-DAA8-4926-AE52-32308BF1197A@gmail.com> Message-ID: <56253466.2070001@redhat.com> There is a cave-at serializing a lambda, the capturing class must be the exact same on both ends. See also https://github.com/wolfc/jboss-beach-lambchops/blob/d4677021899dc945c3acb1b7eb73ff7cc901b223/client/src/main/java/org/jboss/beach/lambchops/client/Client.java#L111 In my case I just serialize the capturing class as well and ensure the other end has a defining class loader. :-) Carlo On 10/17/2015 06:57 PM, Romain Manni-Bucau wrote: > > 2015-10-17 18:54 GMT+02:00 Sven Linstaedt >: > > Hi John > > most, if not all Java 8 lambda types are not serializable afaik > (sure, one can specify custom serializable lambdas, but I guess > this happens rather rarely), so assigning a lambda typed bean a > serializable context will probably always cause problems. Even the > lamda type itself is serializable, it does not mean it's closure > is. Even though application scoped lambda beans are in general no > problem at all, most other contexts are. So the question is, > whether to allow lambda typed bean to have any serializable scope > at all. > > > java.lang.invoke.SerializedLambda is done for that so should be > > Don't get me wrong. I am a huge fan of Java 8 and functional > programming in general, but I think FP's way of expressive design > somehow collides with CDI's rather declarative style. At least for > non-SPI code. > > > > Same here, I think a good API should deserve it. Being able to bind in > an extension or through an event not needed a SPI file a lambda would > be great but I think we are out of CDI - as backbone - scope there. > Maybe doing a proto using custom events can help to play with it and > see what we can do of it. > > Best regards > Sven > > -- sent by phone > > Am 17.10.2015 um 15:03 schrieb John D. Ament > >: > >> Sven, >> >> I'm a little curious, why do they need to avoid serializable >> contexts? In all honesty, I use app scoped functions, predicates >> in my code, at least in a couple of places. Lambdas are >> specifically meant for operations, not data, so they should be in >> a highly reusable scope (in my opinion at least). >> >> On the flip side, I have a hard time justifying needing to >> provide injectable beans for lambdas since good encapsulation >> should indicate they're only used in a single spot. >> >> John >> >> On Sat, Oct 17, 2015 at 7:51 AM Sven Linstaedt >> > wrote: >> >> Just one question: Who is on charge and is able of managing >> this unmanaged instances, e.g. lifecycle, serialization, >> concurrency (e.g. when dealing with closures)? >> >> Functional programming and DI seem to be somehow disjunct in >> this case. E.g. manually setting up observers seem to better >> fit extension than normal application code. >> >> On the other side, specifying producer methods or fields, >> that are injectable and return lambda expressions seems to be >> a no brainier for CDI, is not it? As long as they are not >> scoped in a serializable context. >> >> Have a nice weekend >> Sven >> >> -- sent by phone >> >> Am 17.10.2015 um 11:06 schrieb David Blevins >> >: >> >>> In brainstorming mode about fun that could be made possible >>> with Java 8 and Java EE. >>> >>> Question in my mind is: is there some way we could make it >>> possible for Lambdas or Method Refs to be CDI beans? >>> >>> It goes against the grain obviously as CDI creation is very >>> much a ?Don?t call us, we?ll call you? kind of thing. The >>> VM dynamically creates a wrapper object around the Lambda or >>> method reference and it implements the given interface. >>> >>> To make it work, there would need to be some non-producer >>> method way of saying ?put this thing in the context with >>> these qualifiers?. >>> >>> Imagine a method somewhere that would allow you to: >>> >>> public void >>> addObserver(java.util.function.Consumer observer, >>> Annotation... qualifiers); >>> >>> >>> Then you could take advantage as follows: >>> >>> final List uris = new ArrayList<>(); >>> // @Observes URI >>> addObserver((Consumer) uris::add); >>> >>> // @Observes Thread >>> addObserver(Runtime.getRuntime()::addShutdownHook); >>> >>> // @Observes Runnable >>> addObserver((Consumer) >>> Executors.newFixedThreadPool(3)::submit); >>> >>> // @Observes URI >>> addObserver((Consumer) System.out::println, new >>> AnnotationLiteral() { >>> }); >>> >>> // @Observes Handler >>> final Logger logger = Logger.getLogger("somewhere"); >>> addObserver(logger::addHandler); // add handlers via event >>> >>> // @Observes @Fine String >>> addObserver((Consumer) logger::fine, new >>> AnnotationLiteral() {}); >>> } >>> >>> >>> >>> -David >>> >>> >>> >>> -- >>> David Blevins >>> http://twitter.com/dblevins >>> http://www.tomitribe.com >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at 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 at 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151019/7bf93947/attachment-0001.html From issues at jboss.org Mon Oct 19 15:28:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 19 Oct 2015 15:28:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-563) Event.fireAsync() - clarify the usage of the returned CompletionStage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119614#comment-13119614 ] Antoine Sabot-Durand commented on CDI-563: ------------------------------------------ {quote}bq. I'm not sure to follow him there, especially when CompletionStage has a dependency on CompletableFuture with the toCompletableFuture() method It's kind of a strange dependency, intended probably as a compatibility/interoperation feature. However, implementations are not required to support this conversion.{quote} I'm not sure, but I think we should, since it's the only way to access the {{get()}} method to allow user to wait for the outcome... {quote} I don't think {{ForkJoinPool.commonPool()}} is a good fit for Java EE. But it's ok for Java SE. {quote} +1 {quote}I'm for: * having {{CompletionStage}} in the CDI API{quote} Yes we also agree here. {quote}* declaring explicitly that *the stage's default asynchronous execution facility is not defined*, in other words it is implementor and environment specific {quote} My favorite option as well ;). I'm just not sure where to add it in the chapter {quote}* declaring explicitly that *the context propagation is not guaranteed for ANY execution* (default execution, default async execution and custom async via a supplied Executor) {quote} Regarding propagation, I thought that the mention in [10.5.3. Observer method invocation context|http://docs.jboss.org/cdi/spec/2.0.EDR1/cdi-spec.html#observer_method_invocation_context], was explicit enough: bq. If the observer method is asynchronous, it is called in a new lifecycle contexts, a new transaction context but the same security context as the invocation of Event.fireAsync(). What do you think we should add? > Event.fireAsync() - clarify the usage of the returned CompletionStage > --------------------------------------------------------------------- > > Key: CDI-563 > URL: https://issues.jboss.org/browse/CDI-563 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Martin Kouba > > So far {{CompletionStage}} is only mentioned in "10.5.1. Handling multiple exceptions thrown during an asynchronous event" and the {{Event.fireAsync()}} javadoc is too general. However, the {{CompletionStage}} itself does not define an unambiguous contract for its methods. E.g. what thread is used to execute a given callback? Or what's the _"stage's default asynchronous execution facility"_? I believe this is left on implementors. In Weld 3.0 Alpha we're using {{CompletableFuture}} under the hood, and its more concrete in this area, e.g.: > {quote} > * Actions supplied for dependent completions of _non-async_ methods may be performed by the thread that completes the current CompletableFuture, or by any other caller of a completion method. > {quote} > So as a result, if an async delivery is finished before a sync dependent action is registered, the callback is executed in the caller thread: > {code:java} > event.fireAsync(new Message()).thenAccept((m) -> System.out.println("This might be executed in a caller thread or in a different thread!")); > {code} > And this might be confusing. Especially from the context propagation point of view. I think the spec should clarify the contract of a returned {{CompletionStage}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 20 07:34:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 20 Oct 2015 07:34:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-563) Event.fireAsync() - clarify the usage of the returned CompletionStage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119851#comment-13119851 ] Martin Kouba commented on CDI-563: ---------------------------------- bq. My favorite option as well . I'm just not sure where to add it in the chapter I would add a new paragraph in 10.2.3. The Event interface... something like "The fireAsync() methods return a CompletionStage whose default asynchronous execution facility is specific to the container implementation." bq. What do you think we should add? I don't like the wording "called in a new lifecycle contexts". What exactly does it mean? Maybe we should just rephrase this. > Event.fireAsync() - clarify the usage of the returned CompletionStage > --------------------------------------------------------------------- > > Key: CDI-563 > URL: https://issues.jboss.org/browse/CDI-563 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Martin Kouba > > So far {{CompletionStage}} is only mentioned in "10.5.1. Handling multiple exceptions thrown during an asynchronous event" and the {{Event.fireAsync()}} javadoc is too general. However, the {{CompletionStage}} itself does not define an unambiguous contract for its methods. E.g. what thread is used to execute a given callback? Or what's the _"stage's default asynchronous execution facility"_? I believe this is left on implementors. In Weld 3.0 Alpha we're using {{CompletableFuture}} under the hood, and its more concrete in this area, e.g.: > {quote} > * Actions supplied for dependent completions of _non-async_ methods may be performed by the thread that completes the current CompletableFuture, or by any other caller of a completion method. > {quote} > So as a result, if an async delivery is finished before a sync dependent action is registered, the callback is executed in the caller thread: > {code:java} > event.fireAsync(new Message()).thenAccept((m) -> System.out.println("This might be executed in a caller thread or in a different thread!")); > {code} > And this might be confusing. Especially from the context propagation point of view. I think the spec should clarify the contract of a returned {{CompletionStage}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 20 07:54:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 20 Oct 2015 07:54:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-563) Event.fireAsync() - clarify the usage of the returned CompletionStage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119861#comment-13119861 ] Antoine Sabot-Durand commented on CDI-563: ------------------------------------------ {quote}bq. What do you think we should add? I don't like the wording "called in a new lifecycle contexts". What exactly does it mean? Maybe we should just rephrase this.{quote} I'm not a big fan of this wording either. But it came from discussion with Jozef, and the fact that for the sake of non-denormalize the spec we shouldn't repeat what is said in [6.7|http://docs.jboss.org/cdi/spec/2.0.EDR1/cdi-spec.html#builtin_contexts]: bq. The context associated with a built-in normal scope propagates across local, synchronous Java method calls. The context does not propagate across remote method invocations or to asynchronous processes. Perhaps we could find a way to have a clearer phrase pointing to this assertion. It lets the possibility for a third party to create a normal scope supporting propagation. > Event.fireAsync() - clarify the usage of the returned CompletionStage > --------------------------------------------------------------------- > > Key: CDI-563 > URL: https://issues.jboss.org/browse/CDI-563 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Martin Kouba > > So far {{CompletionStage}} is only mentioned in "10.5.1. Handling multiple exceptions thrown during an asynchronous event" and the {{Event.fireAsync()}} javadoc is too general. However, the {{CompletionStage}} itself does not define an unambiguous contract for its methods. E.g. what thread is used to execute a given callback? Or what's the _"stage's default asynchronous execution facility"_? I believe this is left on implementors. In Weld 3.0 Alpha we're using {{CompletableFuture}} under the hood, and its more concrete in this area, e.g.: > {quote} > * Actions supplied for dependent completions of _non-async_ methods may be performed by the thread that completes the current CompletableFuture, or by any other caller of a completion method. > {quote} > So as a result, if an async delivery is finished before a sync dependent action is registered, the callback is executed in the caller thread: > {code:java} > event.fireAsync(new Message()).thenAccept((m) -> System.out.println("This might be executed in a caller thread or in a different thread!")); > {code} > And this might be confusing. Especially from the context propagation point of view. I think the spec should clarify the contract of a returned {{CompletionStage}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 20 07:55:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 20 Oct 2015 07:55:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-543) Handling exception during async event - contradiction? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-543: ------------------------------------- Fix Version/s: 2.0-EDR2 > Handling exception during async event - contradiction? > ------------------------------------------------------ > > Key: CDI-543 > URL: https://issues.jboss.org/browse/CDI-543 > Project: CDI Specification Issues > Issue Type: Bug > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Tomas Remes > Fix For: 2.0-EDR2 > > > In {{10.5. Observer notification}} there is (wrt sync observer method): > {quote} > Otherwise, the exception aborts processing of the event. No other observer methods of that event will be called > {quote} > This looks like contradiction to {{10.5.1. Handling multiple exceptions thrown during an asynchronous event}} where is: > {quote} > If an event is asynchronous, and an exception is thrown by any of its notified observers, the CompletionStage returned by fireAsync will complete exceptionally .. > {quote} > The question is following: Async Event is fired -> some sync observers are notified -> one of them throws exception -> async observers will be notified or not? > I assume they should be notified and therefore {{10.5. Observer notification}} needs an update. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 20 08:00:04 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 20 Oct 2015 08:00:04 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-563) Event.fireAsync() - clarify the usage of the returned CompletionStage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119868#comment-13119868 ] Martin Kouba commented on CDI-563: ---------------------------------- bq. Perhaps we could find a way to have a clearer phrase pointing to this assertion. +1 > Event.fireAsync() - clarify the usage of the returned CompletionStage > --------------------------------------------------------------------- > > Key: CDI-563 > URL: https://issues.jboss.org/browse/CDI-563 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Martin Kouba > > So far {{CompletionStage}} is only mentioned in "10.5.1. Handling multiple exceptions thrown during an asynchronous event" and the {{Event.fireAsync()}} javadoc is too general. However, the {{CompletionStage}} itself does not define an unambiguous contract for its methods. E.g. what thread is used to execute a given callback? Or what's the _"stage's default asynchronous execution facility"_? I believe this is left on implementors. In Weld 3.0 Alpha we're using {{CompletableFuture}} under the hood, and its more concrete in this area, e.g.: > {quote} > * Actions supplied for dependent completions of _non-async_ methods may be performed by the thread that completes the current CompletableFuture, or by any other caller of a completion method. > {quote} > So as a result, if an async delivery is finished before a sync dependent action is registered, the callback is executed in the caller thread: > {code:java} > event.fireAsync(new Message()).thenAccept((m) -> System.out.println("This might be executed in a caller thread or in a different thread!")); > {code} > And this might be confusing. Especially from the context propagation point of view. I think the spec should clarify the contract of a returned {{CompletionStage}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 20 12:25:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 20 Oct 2015 12:25:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-527: ------------------------------------- Fix Version/s: 2.0 (proposed) (was: 2.0 (discussion)) > 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 > 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) From issues at jboss.org Tue Oct 20 12:27:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 20 Oct 2015 12:27:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-527: ---------------------------------------- Assignee: Mark Struberg > 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) From issues at jboss.org Wed Oct 21 10:07:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 21 Oct 2015 10:07:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13120531#comment-13120531 ] Martin Kouba commented on CDI-527: ---------------------------------- For the record - the spec only requires the injection points to be validated, or rather the required bean types to be proxyable. So for the HashMap from JDK7 a simple workaround would be to inject/use the Map interface. -1 for introducing a new annotation - this wouldn't help for third-party bean classes, e.g. the JDK7's HashMap example. > 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) From issues at jboss.org Wed Oct 21 10:21:00 2015 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Wed, 21 Oct 2015 10:21:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13120547#comment-13120547 ] Tomas Remes commented on CDI-527: --------------------------------- I am not sure I follow on this. On the NIV's it's explicitly stated in {{4.9.8 Session Bean?s No-Interface View}} that: {quote} Only private methods of the bean class and any superclasses except java.lang.Object may be declared final. {quote} There is no problem from CDI point of view AFAIK. In the case of interface view types I can't see any problem as well because the proxy instance is created for the interface type (not impl) which has all methods public and not final. What's the reason for CDI to behave differently? In fact I think we can't supress EJB validations anyway. > 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) From issues at jboss.org Fri Oct 23 14:44:00 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Fri, 23 Oct 2015 14:44:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13121697#comment-13121697 ] Mark Struberg commented on CDI-527: ----------------------------------- [~tremes] I think this wording only got introduced pretty recently. Afaik it was not there in EJB-3.1. So I assume they 'fixed' it into the wrong direction. And I fear it's an illegal non-backward compatible change in the EJB spec... [~mkouba] No, I think you are not right. Read the paragraph 3.15. It is all about unproxyable BEAN TYPES. Not the Injection Points, it is BEAN TYPES. got me? Only looking at injection points would also trash Extensions, EL and dynamic resolving (BeanManager#getBean by name or type). > 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) From issues at jboss.org Mon Oct 26 03:20:02 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 26 Oct 2015 03:20:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13121824#comment-13121824 ] Martin Kouba commented on CDI-527: ---------------------------------- [~struberg] Yes, it is about bean types. But the validation requirement is clearly defined: bq. A bean type must be proxyable if an injection point resolves to a bean... Otherwise, the container automatically detects the problem, and treats it as a deployment problem. For extensions, EL, etc. - you get {{UnproxyableResolutionException}} at runtime. Also note that a contextual reference is not required to implement all bean types of the bean. Only the required bean type and all interfaces (see 6.5.3. Contextual reference for a bean). > 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) From antoine at sabot-durand.net Tue Oct 27 06:02:24 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 27 Oct 2015 10:02:24 +0000 Subject: [cdi-dev] No meeting today Message-ID: In JavaOne, I'll be in the middle of a talk during the meeting... See you next week. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151027/c7b4ce9e/attachment.html From issues at jboss.org Tue Oct 27 11:04:00 2015 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Tue, 27 Oct 2015 11:04:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-567) Investigate user data holding in instances In-Reply-To: References: Message-ID: Romain Manni-Bucau created CDI-567: -------------------------------------- Summary: Investigate user data holding in instances Key: CDI-567 URL: https://issues.jboss.org/browse/CDI-567 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Romain Manni-Bucau Need: attach some data to instances Solutions (a few I'm thinking about writing these lines): - allow CDI extensions to register ClassFileTransformer (or a CDI interface) to modify the bytecode of classes (I like this one since it opens a lot of awesome doors - far more than what is needed for this task feature - and even to make CDI instances not CDI compliant ;) but it is very technical) - allow context to handle data associated with their instances (caricaturally: a Map would be associated to the context and it would be accessible either from an event - sadly we cant reuse initialized/destroyed ones - or the context itself) - extend all beans having a registered "DataEnricher" to be able to handle this and make it inherit from a new interface "DataGetSet" (the name is horrible but it is to share the idea ;)) Main goal is to get rid of all the ThreadLocals CDI extensions can need when writing not final applications (= make libraries writer's lifes easier) on one side and to make easier to associate a model to an instance on another side (=avoid to redo the same in all extensions). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 29 09:22:00 2015 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Thu, 29 Oct 2015 09:22:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-567) Investigate user data holding in instances In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13123318#comment-13123318 ] Tomas Remes commented on CDI-567: --------------------------------- Sorry but I don't understand much. I am not really sure what you would like to achieve. Can you elaborate please (some code example might be helpful)? Can you point me to some extension (as an example) which uses ThreadLocal? > Investigate user data holding in instances > ------------------------------------------ > > Key: CDI-567 > URL: https://issues.jboss.org/browse/CDI-567 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Romain Manni-Bucau > > Need: attach some data to instances > Solutions (a few I'm thinking about writing these lines): > - allow CDI extensions to register ClassFileTransformer (or a CDI interface) to modify the bytecode of classes (I like this one since it opens a lot of awesome doors - far more than what is needed for this task feature - and even to make CDI instances not CDI compliant ;) but it is very technical) > - allow context to handle data associated with their instances (caricaturally: a Map would be associated to the context and it would be accessible either from an event - sadly we cant reuse initialized/destroyed ones - or the context itself) > - extend all beans having a registered "DataEnricher" to be able to handle this and make it inherit from a new interface "DataGetSet" (the name is horrible but it is to share the idea ;)) > Main goal is to get rid of all the ThreadLocals CDI extensions can need when writing not final applications (= make libraries writer's lifes easier) on one side and to make easier to associate a model to an instance on another side (=avoid to redo the same in all extensions). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 29 09:39:00 2015 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Thu, 29 Oct 2015 09:39:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-567) Investigate user data holding in instances In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13123333#comment-13123333 ] Romain Manni-Bucau commented on CDI-567: ---------------------------------------- DeltaSpike uses some thread local for transaction and data stuff. Idea is to allo to store meta information in bean themself. We would probably desire to have two kind of enrich-able storage: - one on Bean (model meta) - one on instances when possible (when proxied to make it simple) for instance related meta > Investigate user data holding in instances > ------------------------------------------ > > Key: CDI-567 > URL: https://issues.jboss.org/browse/CDI-567 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Romain Manni-Bucau > > Need: attach some data to instances > Solutions (a few I'm thinking about writing these lines): > - allow CDI extensions to register ClassFileTransformer (or a CDI interface) to modify the bytecode of classes (I like this one since it opens a lot of awesome doors - far more than what is needed for this task feature - and even to make CDI instances not CDI compliant ;) but it is very technical) > - allow context to handle data associated with their instances (caricaturally: a Map would be associated to the context and it would be accessible either from an event - sadly we cant reuse initialized/destroyed ones - or the context itself) > - extend all beans having a registered "DataEnricher" to be able to handle this and make it inherit from a new interface "DataGetSet" (the name is horrible but it is to share the idea ;)) > Main goal is to get rid of all the ThreadLocals CDI extensions can need when writing not final applications (= make libraries writer's lifes easier) on one side and to make easier to associate a model to an instance on another side (=avoid to redo the same in all extensions). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 29 10:32:00 2015 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Thu, 29 Oct 2015 10:32:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-545) Clarify that observers can't be remote business method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13123415#comment-13123415 ] Tomas Remes commented on CDI-545: --------------------------------- https://github.com/cdi-spec/cdi/pull/262 > Clarify that observers can't be remote business method > ------------------------------------------------------- > > Key: CDI-545 > URL: https://issues.jboss.org/browse/CDI-545 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Java EE integration > Affects Versions: 1.2.Final > Reporter: Antoine Sabot-Durand > > In section 10.4 of 1.2 spec we have: > {quote} > If the bean is a session bean, the observer method must be either a business method of the EJB or a static method of the bean class. > {quote} > in 10.4.2 we also have: > {quote} > If a non-static method of a session bean class has a parameter annotated {{@Observes}}, and the method is not a business method of the EJB, the container automatically detects the problem and treats it as a definition error. > {quote} > This 2 assertions don't prevent an observer to be a business method of a remote client of an EJB. We should be more precise here and forbid this scenario. -- This message was sent by Atlassian JIRA (v6.4.11#64026)