From issues at jboss.org Tue Jul 1 04:31:26 2014 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Tue, 1 Jul 2014 04:31:26 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-446) Clarify validity/invalidity of using direct access to public fields In-Reply-To: References: Message-ID: Tomas Remes created CDI-446: ------------------------------- Summary: Clarify validity/invalidity of using direct access to public fields Key: CDI-446 URL: https://issues.jboss.org/browse/CDI-446 Project: CDI Specification Issues Issue Type: Clarification Reporter: Tomas Remes The spec could clarify validity/invalidity of using direct access to public fields. Accessing public fields directly could cause potential problems, when testing/using various implementations - see linked issue. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 09:30:24 2014 From: issues at jboss.org (Phil Zampino (JIRA)) Date: Tue, 1 Jul 2014 09:30:24 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-447) Section 12.1 specifies that JVM classpath must be included in bean archive identification In-Reply-To: References: Message-ID: Phil Zampino created CDI-447: -------------------------------- Summary: Section 12.1 specifies that JVM classpath must be included in bean archive identification Key: CDI-447 URL: https://issues.jboss.org/browse/CDI-447 Project: CDI Specification Issues Issue Type: Clarification Components: Packaging and Deployment Affects Versions: 1.2.Final Reporter: Phil Zampino Section 12.1 of the spec states: When determining which archives are bean archives, the container must consider: ? Library jars, EJB jars or application client jars ? The WEB-INF/classes directory of a war ? Directories in the JVM classpath For CDI 1.0, I think the inclusion of "directories in the JVM classpath" would not be a big deal. However, since the introduction of implicit bean archives, I'm wondering if implementations are required to scan the JVM classpath for classes annotated with bean-defining annotations. This seems like it has the potential to be an expensive requirement, and it should not be required. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 09:38:25 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 1 Jul 2014 09:38:25 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-447) Section 12.1 specifies that JVM classpath must be included in bean archive identification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981033#comment-12981033 ] Martin Kouba commented on CDI-447: ---------------------------------- I think this only applies to an embeddable EJB container, see paragraph below: {quote} The container searches for beans in all bean archives in the application classpath: * In an application deployed as an ear, ... {quote} And in fact, an embeddable EJB container is not even covered by the TCK. > Section 12.1 specifies that JVM classpath must be included in bean archive identification > ----------------------------------------------------------------------------------------- > > Key: CDI-447 > URL: https://issues.jboss.org/browse/CDI-447 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Packaging and Deployment > Affects Versions: 1.2.Final > Reporter: Phil Zampino > > Section 12.1 of the spec states: > When determining which archives are bean archives, the container must consider: > ? Library jars, EJB jars or application client jars > ? The WEB-INF/classes directory of a war > ? Directories in the JVM classpath > For CDI 1.0, I think the inclusion of "directories in the JVM classpath" would not be a big deal. However, since the introduction of implicit bean archives, I'm wondering if implementations are required to scan the JVM classpath for classes annotated with bean-defining annotations. This seems like it has the potential to be an expensive requirement, and it should not be required. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 09:48:25 2014 From: issues at jboss.org (Phil Zampino (JIRA)) Date: Tue, 1 Jul 2014 09:48:25 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-447) Section 12.1 specifies that JVM classpath must be included in bean archive identification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981044#comment-12981044 ] Phil Zampino commented on CDI-447: ---------------------------------- Thanks for the clarification. Do you agree that it's not clear in the spec that this only applies to embeddable EJB containers? > Section 12.1 specifies that JVM classpath must be included in bean archive identification > ----------------------------------------------------------------------------------------- > > Key: CDI-447 > URL: https://issues.jboss.org/browse/CDI-447 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Packaging and Deployment > Affects Versions: 1.2.Final > Reporter: Phil Zampino > > Section 12.1 of the spec states: > When determining which archives are bean archives, the container must consider: > ? Library jars, EJB jars or application client jars > ? The WEB-INF/classes directory of a war > ? Directories in the JVM classpath > For CDI 1.0, I think the inclusion of "directories in the JVM classpath" would not be a big deal. However, since the introduction of implicit bean archives, I'm wondering if implementations are required to scan the JVM classpath for classes annotated with bean-defining annotations. This seems like it has the potential to be an expensive requirement, and it should not be required. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 10:02:25 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 1 Jul 2014 10:02:25 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-447) Section 12.1 specifies that JVM classpath must be included in bean archive identification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981054#comment-12981054 ] Martin Kouba commented on CDI-447: ---------------------------------- Well yes, this section could be split into several subsections. Right now it contains five lists and is not very easy to read. > Section 12.1 specifies that JVM classpath must be included in bean archive identification > ----------------------------------------------------------------------------------------- > > Key: CDI-447 > URL: https://issues.jboss.org/browse/CDI-447 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Packaging and Deployment > Affects Versions: 1.2.Final > Reporter: Phil Zampino > > Section 12.1 of the spec states: > When determining which archives are bean archives, the container must consider: > ? Library jars, EJB jars or application client jars > ? The WEB-INF/classes directory of a war > ? Directories in the JVM classpath > For CDI 1.0, I think the inclusion of "directories in the JVM classpath" would not be a big deal. However, since the introduction of implicit bean archives, I'm wondering if implementations are required to scan the JVM classpath for classes annotated with bean-defining annotations. This seems like it has the potential to be an expensive requirement, and it should not be required. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From antoine at sabot-durand.net Tue Jul 1 16:38:19 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 1 Jul 2014 22:38:19 +0200 Subject: [cdi-dev] CDI 2.0 JSR proposal needs supporters Message-ID: <6706757D-F23D-4278-AA22-F7E5A4631943@sabot-durand.net> Hi all, Pete and I just finished the draft of CDI 2.0 JSR proposal. It?s there : https://docs.google.com/document/d/1al1rdAs3CN34a9zTe3cXsLL4LBfHhzP8EbuDJ2YQ0qc/edit?usp=sharing The proposal now needs supporter to be ready for submission, so if you or your company is member of the JCP or play a visible role in Java community and willing to support officially this JSR, please let us know. The document is open for comments but please use this only if you have an important point that couldn?t be discussed after JSR launch. Don?t forget to check the companion doc of this JSR regarding introduction of ? parts ? in CDI : https://docs.google.com/document/d/1jzCuFQjtCSrnZGRAHjn0oknWvEaP3h0KizW1mHB4AZU/edit?usp=sharing The information in the document is not part of the JSR proposal, just a first idea of what parts could be. The only thing that we?d want to make official in the JSR proposal is this concept of parts. Their granularity, number or included features will be discussed by the futur EG. Thank you for your commitment and feedback, Antoine -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140701/44b728c3/attachment.bin From john.d.ament at gmail.com Tue Jul 1 20:13:47 2014 From: john.d.ament at gmail.com (John D. Ament) Date: Tue, 1 Jul 2014 20:13:47 -0400 Subject: [cdi-dev] CDI 2.0 JSR proposal needs supporters In-Reply-To: <6706757D-F23D-4278-AA22-F7E5A4631943@sabot-durand.net> References: <6706757D-F23D-4278-AA22-F7E5A4631943@sabot-durand.net> Message-ID: Antoine, I added a bunch of "suggestions" to the proposal. It generally looks good and there's some minor things to refine. It looks like I might qualify, if this list does not lie [1]. So, if you'd have me, I'd be interested in joining the EG. John [1]: https://jcp.org/ja/participation/members/A On Tue, Jul 1, 2014 at 4:38 PM, Antoine Sabot-Durand wrote: > Hi all, > > > Pete and I just finished the draft of CDI 2.0 JSR proposal. It?s there : https://docs.google.com/document/d/1al1rdAs3CN34a9zTe3cXsLL4LBfHhzP8EbuDJ2YQ0qc/edit?usp=sharing > > The proposal now needs supporter to be ready for submission, so if you or your company is member of the JCP or play a visible role in Java community and willing to support officially this JSR, please let us know. > > The document is open for comments but please use this only if you have an important point that couldn?t be discussed after JSR launch. > > Don?t forget to check the companion doc of this JSR regarding introduction of ? parts ? in CDI : https://docs.google.com/document/d/1jzCuFQjtCSrnZGRAHjn0oknWvEaP3h0KizW1mHB4AZU/edit?usp=sharing > > The information in the document is not part of the JSR proposal, just a first idea of what parts could be. The only thing that we?d want to make official in the JSR proposal is this concept of parts. Their granularity, number or included features will be discussed by the futur EG. > > Thank you for your commitment and feedback, > > Antoine > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev From antoine at sabot-durand.net Wed Jul 2 07:40:21 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 2 Jul 2014 13:40:21 +0200 Subject: [cdi-dev] Renaming the Spec for CDI 2.0 ? Message-ID: Hi, As we intend to include Java SE support, Martin propose to rename the complete name of the spec ? Contexts and Dependency Injection for Java EE ? by removing the EE. New name would be ? Contexts and Dependency Injection for Java ?. On the principle I?m ok with that except if it brings issue with the JCP or Java EE 8 EC. What do you think ? Antoine -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140702/2f786334/attachment.bin From arne.limburg at openknowledge.de Wed Jul 2 07:45:38 2014 From: arne.limburg at openknowledge.de (Arne Limburg) Date: Wed, 2 Jul 2014 11:45:38 +0000 Subject: [cdi-dev] Renaming the Spec for CDI 2.0 ? In-Reply-To: Message-ID: Hi Antoine, No problem with that. A question comes to my mind on that: What is the official name of JSR-330 (@Inject)? We should not clash with it. But I guess, at least the "Contexts" is missing from their name. Cheers, Arne Am 02.07.14 13:40 schrieb "Antoine Sabot-Durand" unter : >Hi, > > >As we intend to include Java SE support, Martin propose to rename the >complete name of the spec ? Contexts and Dependency Injection for Java EE >? by removing the EE. New name would be ? Contexts and Dependency >Injection for Java ?. > >On the principle I?m ok with that except if it brings issue with the JCP >or Java EE 8 EC. What do you think ? > >Antoine From pmuir at redhat.com Wed Jul 2 07:46:51 2014 From: pmuir at redhat.com (Pete Muir) Date: Wed, 2 Jul 2014 12:46:51 +0100 Subject: [cdi-dev] Renaming the Spec for CDI 2.0 ? In-Reply-To: References: Message-ID: On 2 Jul 2014, at 12:45, Arne Limburg wrote: > Hi Antoine, > > > No problem with that. A question comes to my mind on that: What is the > official name of JSR-330 (@Inject)? "JSR 330: Dependency Injection for Java" > We should not clash with it. But I > guess, at least the "Contexts" is missing from their name. So it seems a good transition to me. > > Cheers, > Arne > > Am 02.07.14 13:40 schrieb "Antoine Sabot-Durand" unter > : > >> Hi, >> >> >> As we intend to include Java SE support, Martin propose to rename the >> complete name of the spec ? Contexts and Dependency Injection for Java EE >> ? by removing the EE. New name would be ? Contexts and Dependency >> Injection for Java ?. >> >> On the principle I?m ok with that except if it brings issue with the JCP >> or Java EE 8 EC. What do you think ? >> >> Antoine > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev From antoine at sabot-durand.net Wed Jul 2 07:58:37 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 2 Jul 2014 13:58:37 +0200 Subject: [cdi-dev] Renaming the Spec for CDI 2.0 ? In-Reply-To: References: Message-ID: <60FB444E-8B1F-42C9-9A49-436A1112159E@sabot-durand.net> Ok, so let?s do it. PS: Speaking of renaming I often dream of stealing Dr Emmet Brown's DeLorean to go back in time and change the ?CDI? acronym when I see this page: http://en.wikipedia.org/wiki/CDI. When I wake up and realize it?s too late ;). Le 2 juil. 2014 ? 13:46, Pete Muir a ?crit : > > On 2 Jul 2014, at 12:45, Arne Limburg wrote: > >> Hi Antoine, >> >> >> No problem with that. A question comes to my mind on that: What is the >> official name of JSR-330 (@Inject)? > > "JSR 330: Dependency Injection for Java" > >> We should not clash with it. But I >> guess, at least the "Contexts" is missing from their name. > > So it seems a good transition to me. > >> >> Cheers, >> Arne >> >> Am 02.07.14 13:40 schrieb "Antoine Sabot-Durand" unter >> : >> >>> Hi, >>> >>> >>> As we intend to include Java SE support, Martin propose to rename the >>> complete name of the spec ? Contexts and Dependency Injection for Java EE >>> ? by removing the EE. New name would be ? Contexts and Dependency >>> Injection for Java ?. >>> >>> On the principle I?m ok with that except if it brings issue with the JCP >>> or Java EE 8 EC. What do you think ? >>> >>> Antoine >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140702/e24dbea9/attachment.bin From antoine at sabot-durand.net Wed Jul 2 07:44:07 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 2 Jul 2014 13:44:07 +0200 Subject: [cdi-dev] CDI 2.0 JSR proposal needs supporters In-Reply-To: References: <6706757D-F23D-4278-AA22-F7E5A4631943@sabot-durand.net> Message-ID: Thanks John, I added you. Antoine Le 2 juil. 2014 ? 02:13, John D. Ament a ?crit : > Antoine, > > I added a bunch of "suggestions" to the proposal. It generally looks > good and there's some minor things to refine. > > It looks like I might qualify, if this list does not lie [1]. So, if > you'd have me, I'd be interested in joining the EG. > > John > > [1]: https://jcp.org/ja/participation/members/A > > On Tue, Jul 1, 2014 at 4:38 PM, Antoine Sabot-Durand > wrote: >> Hi all, >> >> >> Pete and I just finished the draft of CDI 2.0 JSR proposal. It?s there : https://docs.google.com/document/d/1al1rdAs3CN34a9zTe3cXsLL4LBfHhzP8EbuDJ2YQ0qc/edit?usp=sharing >> >> The proposal now needs supporter to be ready for submission, so if you or your company is member of the JCP or play a visible role in Java community and willing to support officially this JSR, please let us know. >> >> The document is open for comments but please use this only if you have an important point that couldn?t be discussed after JSR launch. >> >> Don?t forget to check the companion doc of this JSR regarding introduction of ? parts ? in CDI : https://docs.google.com/document/d/1jzCuFQjtCSrnZGRAHjn0oknWvEaP3h0KizW1mHB4AZU/edit?usp=sharing >> >> The information in the document is not part of the JSR proposal, just a first idea of what parts could be. The only thing that we?d want to make official in the JSR proposal is this concept of parts. Their granularity, number or included features will be discussed by the futur EG. >> >> Thank you for your commitment and feedback, >> >> Antoine >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140702/5bdba253/attachment.bin From struberg at yahoo.de Wed Jul 2 14:08:35 2014 From: struberg at yahoo.de (Mark Struberg) Date: Wed, 2 Jul 2014 19:08:35 +0100 Subject: [cdi-dev] CDI 2.0 JSR proposal needs supporters In-Reply-To: <6706757D-F23D-4278-AA22-F7E5A4631943@sabot-durand.net> References: <6706757D-F23D-4278-AA22-F7E5A4631943@sabot-durand.net> Message-ID: <1404324515.21549.YahooMailNeo@web28901.mail.ir2.yahoo.com> Currently on vacation. Will read and give feedback on the proposal in 2 days. Would be happy to join the team again. LieGrue, strub On Tuesday, 1 July 2014, 22:38, Antoine Sabot-Durand wrote: > > >Hi all, > > >Pete and I just finished the draft of CDI 2.0 JSR proposal. It?s there : https://docs.google.com/document/d/1al1rdAs3CN34a9zTe3cXsLL4LBfHhzP8EbuDJ2YQ0qc/edit?usp=sharing > >The proposal now needs supporter to be ready for submission, so if you or your company is member of the JCP or play a visible role in Java community and willing to support officially this JSR, please let us know. > >The document is open for comments but please use this only if you have an important point that couldn?t be discussed after JSR launch. > >Don?t forget to check the companion doc of this JSR regarding introduction of ? parts ? in CDI : https://docs.google.com/document/d/1jzCuFQjtCSrnZGRAHjn0oknWvEaP3h0KizW1mHB4AZU/edit?usp=sharing > >The information in the document is not part of the JSR proposal, just a first idea of what parts could be. The only thing that we?d want to make official in the JSR proposal is this concept of parts. Their granularity, number? or included features will be discussed by the futur EG. > >Thank you for your commitment and feedback, > >Antoine >_______________________________________________ >cdi-dev mailing list >cdi-dev at lists.jboss.org >https://lists.jboss.org/mailman/listinfo/cdi-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140702/fe55abe2/attachment-0001.html From antoine at sabot-durand.net Wed Jul 2 16:43:57 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 2 Jul 2014 22:43:57 +0200 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 Message-ID: Hi all, Since the first mention of CDI 2.0 preparation work, we've received a lot of comment about JSR 330 evolution. With the release of the proposal draft yesterday, this topic came up again. So let me give my point of view on this subject to have an open discussion here. When we started to discuss about modularity with Pete in last november, my first idea was to go see what we could add in JSR 330 to make it a true specification that could be the first module of CDI. My idea at that time was to discuss with JSR 330 owner to see if we could bring basic concept we have in CDI to AtInject spec. In my mind the main features would have been: - Enhance the javax.inject.Provider interface to bring it at the same level than javax.enterprise.inject.Instance. That would have included support for AnnotationLiteral and TypeLiteral as well - Add a Container interface (a very light BeanManger) in JSR 330 to be able to resolve beans instance from outside managed beans - Add a mechanism to get this Container from non managed beans (like we get access to BeanManager from JNDI or CDI class) At that time, I contacted Bob Lee without success (didn?t tried Pivotal since I don?t have contact there). I checked with JCP what could be done if we?d like to see an evolution of JSR 330 and the owner doesn?t care, there seems to have solutions but I let it aside since we were in the middle of CDI 1.2 MR at that time. Today I?m a bit torn about this point. Working on opening JSR 330 could be like opening pandora box, since I see 2 scenarios : 1) former JSR 330 owners wake up and are ok to get for a new spec version they lead: Knowing the history of JSR 330 vs JSR 299 I?m not sure everything we?d need would be heard and even if the people leading this would be cooperative, a lot of discussion and negotiation would be needed to be sure that this new AtInject wouldn?t contain features incompatible with CDI. So it?d be very time consuming with no guarantee to get what we?d need at the end. 2) former JSR 330 owner don?t mind others take ownership of their spec to enhance it and we (Red Hat) are the one to take this ownership to secure CDI: The best solution to minimize risk. But leading a new specification is a lot more work than just deciding that we have a specific basic inject ? part ? in CDI 2.0. Leading a spec is very time consuming, so it could be better on the paper but will impact CDI 2.0 new features. To sum up, as a Java EE user (like I have been for 10 years) I?d be happy to see this (scenario 2), but as CDI spec lead I fear that it could lead us in a trap (going to scenario 1 or consuming precious time on AtInject+1 instead of CDI 2.0) Your input, solutions or comment would be appreciated on this point. Antoine -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140702/f8a0af20/attachment.bin From martijnverburg at gmail.com Thu Jul 3 04:51:26 2014 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 3 Jul 2014 09:51:26 +0100 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: References: Message-ID: Hi All, To be blunt, this is a social/community issue - not a technical one. We simply need to get hold of the folks at Pivotal, Google (and other 330 EG members) and get them around the virtual table. If they subsequently aren't interested then fine, you should forge your own path. There's an absolute mega ton of 330 based DI code out there and 330 compliant containers, if CDI 2.0 wants to be the defacto std going forwards it simply can't afford ignore that. @Antoine - let's put our heads together and see who we need to get hold of in the 330 group, I think CDI 2.0 has strong merits and should be explored. @Werner - your comments about Bob's commitment (considering what he's done for the tech community at large, let alone Java) are highly inappropriate, please refrain from personal attacks on this or any other public forum. Cheers, Martijn On 3 July 2014 09:02, Antonio Goncalves wrote: > > To sum up, as a Java EE user (like I have been for 10 years) I?d be > happy to see this (scenario 2), but as CDI spec lead I fear that it could > lead us in a trap (going to scenario 1 or consuming precious time on > AtInject+1 instead of CDI 2.0) > > Well, I'm not spec lead, I'm just a Java EE user... so I like scenario 2 > ;o) > > But on the other hand, I think there is so much work to be done around CDI > 2.0, parts, and taking those parts to other specifications that battling > with JSR 330 might be time consuming. I would go for scenario 1.... and > cross fingers > > > On Wed, Jul 2, 2014 at 11:18 PM, Werner Keil > wrote: > >> Dear Antoine/all, >> >> Thanks for the detailed overview and trying to reach out to the former >> Spec Leads and EG of JSR 330. I also copied Anatole, Spec Lead of JSR 354, >> since Bob Lee is officially in his EG, but has practically never provided >> input there either (like we tend to see sometimes from others considered >> "Rock Stars" of the Java Community but since then seemingly resting on >> their laurels or just too busy counting their stock options?[?]) >> >> Given CDI already was the public perception of "javax.inject" for most >> parts, I don't necessarily see that it had to be an MR to the original JSR, >> though as those involved in the EC (Martijn, Badr/MoroccoJUG,..) could >> probably check with the PMO how to handle a case where the Maintenance Lead >> of a JSR was not in the position to continue. I last met J?rgen H?ller >> about a year ago in Copenhagen, so for Pivotal's part as Co Spec Lead, I >> guess he or the likes of Josh Long could be best to speak to. Happy to get >> you in touch with them if you want. >> >> Red Hat was also EG member of JSR 330, so Pete, Gavin or whoever else was >> there (I remember him from conversations where Mike Keith and I took part >> in synergy discussions between 330 and CDI 1.0) at the time could also help >> you with this. >> >> In theory this could also be part of a new JSR (CDI 2) as long as none of >> the enhancements you have in mind break the existing API of JSR 330. The >> scope of CDI 2 to work in an SE/standalone or more lightweight environment >> than Java EE environment raises a good question of package names like " javax.enterprise.inject.*" >> So maybe there is room for synergies in a package namespace other than >> "javax.enterprise" at least for new things you have in mind. >> >> Kind Regards, >> >> Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead | >> Eclipse UOMo Lead, Babel Language Champion | Apache Committer >> >> Twitter @wernerkeil | @UnitAPI | @JSR354 | #EclipseUOMo | #Java_Social | >> #DevOps >> Skype werner.keil | Google+ gplus.to/wernerkeil >> >> * Developer Week: 14/15 Jul 2014, N?rnberg, Germany. Werner Keil, JCP EC >> Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class >> Continuous Delivery", "JSR 363 and IoT" (GER) >> >> * JavaZone 2014: 9-11 Sep 2014, Oslo, Norway. Werner Keil, JCP EC Member, >> JSR 363 Spec Lead will present "JSR 363 - The Answer to Life Science and >> the Internet of Everything" >> >> * JavaOne 2014: Sep 28-Oct 2 2014, San Francisco, USA, Werner Keil, JCP >> EC Member, JSR 354 EG Member will host "Java and Digital Currencies, Friend >> or FOE" >> >> * JMaghreb 3.0: 4-6 Nov 2014, Casablanca, Morocco. Werner Keil, JCP EC >> Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class >> DevOps", "JSR 363" >> >> * Mobile Developer Conference kompakt: 18 Nov 2014, Hamburg, Germany. >> Werner Keil, JCP EC Member, Apache DeviceMap Committer will present "Apache >> DeviceMap" (GER) >> >> >> On Wed, Jul 2, 2014 at 10:43 PM, Antoine Sabot-Durand < >> antoine at sabot-durand.net> wrote: >> >>> Hi all, >>> >>> Since the first mention of CDI 2.0 preparation work, we've received a >>> lot of comment about JSR 330 evolution. With the release of the proposal >>> draft yesterday, this topic came up again. So let me give my point of view >>> on this subject to have an open discussion here. >>> >>> When we started to discuss about modularity with Pete in last november, >>> my first idea was to go see what we could add in JSR 330 to make it a true >>> specification that could be the first module of CDI. My idea at that time >>> was to discuss with JSR 330 owner to see if we could bring basic concept we >>> have in CDI to AtInject spec. In my mind the main features would have been: >>> - Enhance the javax.inject.Provider interface to bring it at the >>> same level than javax.enterprise.inject.Instance. That would have >>> included support for AnnotationLiteral and TypeLiteral as well >>> - Add a Container interface (a very light BeanManger) in JSR 330 to be >>> able to resolve beans instance from outside managed beans >>> - Add a mechanism to get this Container from non managed beans (like we >>> get access to BeanManager from JNDI or CDI class) >>> >>> At that time, I contacted Bob Lee without success (didn?t tried Pivotal >>> since I don?t have contact there). I checked with JCP what could be done if >>> we?d like to see an evolution of JSR 330 and the owner doesn?t care, there >>> seems to have solutions but I let it aside since we were in the middle of >>> CDI 1.2 MR at that time. >>> >>> Today I?m a bit torn about this point. Working on opening JSR 330 could >>> be like opening pandora box, since I see 2 scenarios : >>> >>> 1) former JSR 330 owners wake up and are ok to get for a new spec >>> version they lead: >>> Knowing the history of JSR 330 vs JSR 299 I?m not sure everything we?d >>> need would be heard and even if the people leading this would be >>> cooperative, a lot of discussion and negotiation would be needed to be sure >>> that this new AtInject wouldn?t contain features incompatible with CDI. So >>> it?d be very time consuming with no guarantee to get what we?d need at the >>> end. >>> >>> 2) former JSR 330 owner don?t mind others take ownership of their spec >>> to enhance it and we (Red Hat) are the one to take this ownership to secure >>> CDI: >>> The best solution to minimize risk. But leading a new specification is a >>> lot more work than just deciding that we have a specific basic inject ? >>> part ? in CDI 2.0. Leading a spec is very time consuming, so it could be >>> better on the paper but will impact CDI 2.0 new features. >>> >>> To sum up, as a Java EE user (like I have been for 10 years) I?d be >>> happy to see this (scenario 2), but as CDI spec lead I fear that it could >>> lead us in a trap (going to scenario 1 or consuming precious time on >>> AtInject+1 instead of CDI 2.0) >>> >>> Your input, solutions or comment would be appreciated on this point. >>> >>> Antoine >>> >>> >>> >> > > > -- > 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/20140703/249ff424/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 257 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140703/249ff424/attachment-0001.gif From martijnverburg at gmail.com Thu Jul 3 05:02:28 2014 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 3 Jul 2014 10:02:28 +0100 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: References: Message-ID: FYI - I've sent a note to the various folks from Google, Pivotal et al, I'll let Antoine explain the CDI 2.0 proposal to them and I'm sure they'll either join this mailing list / discussion or we'll quickly find out there's no appetite and we can move on. Cheers, Martijn On 3 July 2014 09:51, Martijn Verburg wrote: > Hi All, > > To be blunt, this is a social/community issue - not a technical one. We > simply need to get hold of the folks at Pivotal, Google (and other 330 EG > members) and get them around the virtual table. If they subsequently > aren't interested then fine, you should forge your own path. > > There's an absolute mega ton of 330 based DI code out there and 330 > compliant containers, if CDI 2.0 wants to be the defacto std going forwards > it simply can't afford ignore that. > > @Antoine - let's put our heads together and see who we need to get hold of > in the 330 group, I think CDI 2.0 has strong merits and should be explored. > > @Werner - your comments about Bob's commitment (considering what he's done > for the tech community at large, let alone Java) are highly inappropriate, > please refrain from personal attacks on this or any other public forum. > > > Cheers, > Martijn > > > On 3 July 2014 09:02, Antonio Goncalves > wrote: > >> > To sum up, as a Java EE user (like I have been for 10 years) I?d be >> happy to see this (scenario 2), but as CDI spec lead I fear that it could >> lead us in a trap (going to scenario 1 or consuming precious time on >> AtInject+1 instead of CDI 2.0) >> >> Well, I'm not spec lead, I'm just a Java EE user... so I like scenario 2 >> ;o) >> >> But on the other hand, I think there is so much work to be done around >> CDI 2.0, parts, and taking those parts to other specifications that >> battling with JSR 330 might be time consuming. I would go for scenario >> 1.... and cross fingers >> >> >> On Wed, Jul 2, 2014 at 11:18 PM, Werner Keil >> wrote: >> >>> Dear Antoine/all, >>> >>> Thanks for the detailed overview and trying to reach out to the former >>> Spec Leads and EG of JSR 330. I also copied Anatole, Spec Lead of JSR 354, >>> since Bob Lee is officially in his EG, but has practically never provided >>> input there either (like we tend to see sometimes from others considered >>> "Rock Stars" of the Java Community but since then seemingly resting on >>> their laurels or just too busy counting their stock options?[?]) >>> >>> Given CDI already was the public perception of "javax.inject" for most >>> parts, I don't necessarily see that it had to be an MR to the original JSR, >>> though as those involved in the EC (Martijn, Badr/MoroccoJUG,..) could >>> probably check with the PMO how to handle a case where the Maintenance Lead >>> of a JSR was not in the position to continue. I last met J?rgen H?ller >>> about a year ago in Copenhagen, so for Pivotal's part as Co Spec Lead, I >>> guess he or the likes of Josh Long could be best to speak to. Happy to get >>> you in touch with them if you want. >>> >>> Red Hat was also EG member of JSR 330, so Pete, Gavin or whoever else >>> was there (I remember him from conversations where Mike Keith and I took >>> part in synergy discussions between 330 and CDI 1.0) at the time could also >>> help you with this. >>> >>> In theory this could also be part of a new JSR (CDI 2) as long as none >>> of the enhancements you have in mind break the existing API of JSR 330. The >>> scope of CDI 2 to work in an SE/standalone or more lightweight environment >>> than Java EE environment raises a good question of package names like " javax.enterprise.inject.*" >>> So maybe there is room for synergies in a package namespace other than >>> "javax.enterprise" at least for new things you have in mind. >>> >>> Kind Regards, >>> >>> Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead | >>> Eclipse UOMo Lead, Babel Language Champion | Apache Committer >>> >>> Twitter @wernerkeil | @UnitAPI | @JSR354 | #EclipseUOMo | #Java_Social >>> | #DevOps >>> Skype werner.keil | Google+ gplus.to/wernerkeil >>> >>> * Developer Week: 14/15 Jul 2014, N?rnberg, Germany. Werner Keil, JCP EC >>> Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class >>> Continuous Delivery", "JSR 363 and IoT" (GER) >>> >>> * JavaZone 2014: 9-11 Sep 2014, Oslo, Norway. Werner Keil, JCP EC >>> Member, JSR 363 Spec Lead will present "JSR 363 - The Answer to Life >>> Science and the Internet of Everything" >>> >>> * JavaOne 2014: Sep 28-Oct 2 2014, San Francisco, USA, Werner Keil, JCP >>> EC Member, JSR 354 EG Member will host "Java and Digital Currencies, Friend >>> or FOE" >>> >>> * JMaghreb 3.0: 4-6 Nov 2014, Casablanca, Morocco. Werner Keil, JCP EC >>> Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class >>> DevOps", "JSR 363" >>> >>> * Mobile Developer Conference kompakt: 18 Nov 2014, Hamburg, Germany. >>> Werner Keil, JCP EC Member, Apache DeviceMap Committer will present "Apache >>> DeviceMap" (GER) >>> >>> >>> On Wed, Jul 2, 2014 at 10:43 PM, Antoine Sabot-Durand < >>> antoine at sabot-durand.net> wrote: >>> >>>> Hi all, >>>> >>>> Since the first mention of CDI 2.0 preparation work, we've received a >>>> lot of comment about JSR 330 evolution. With the release of the proposal >>>> draft yesterday, this topic came up again. So let me give my point of view >>>> on this subject to have an open discussion here. >>>> >>>> When we started to discuss about modularity with Pete in last november, >>>> my first idea was to go see what we could add in JSR 330 to make it a true >>>> specification that could be the first module of CDI. My idea at that time >>>> was to discuss with JSR 330 owner to see if we could bring basic concept we >>>> have in CDI to AtInject spec. In my mind the main features would have been: >>>> - Enhance the javax.inject.Provider interface to bring it at the >>>> same level than javax.enterprise.inject.Instance. That would have >>>> included support for AnnotationLiteral and TypeLiteral as well >>>> - Add a Container interface (a very light BeanManger) in JSR 330 to be >>>> able to resolve beans instance from outside managed beans >>>> - Add a mechanism to get this Container from non managed beans (like >>>> we get access to BeanManager from JNDI or CDI class) >>>> >>>> At that time, I contacted Bob Lee without success (didn?t tried Pivotal >>>> since I don?t have contact there). I checked with JCP what could be done if >>>> we?d like to see an evolution of JSR 330 and the owner doesn?t care, there >>>> seems to have solutions but I let it aside since we were in the middle of >>>> CDI 1.2 MR at that time. >>>> >>>> Today I?m a bit torn about this point. Working on opening JSR 330 could >>>> be like opening pandora box, since I see 2 scenarios : >>>> >>>> 1) former JSR 330 owners wake up and are ok to get for a new spec >>>> version they lead: >>>> Knowing the history of JSR 330 vs JSR 299 I?m not sure everything we?d >>>> need would be heard and even if the people leading this would be >>>> cooperative, a lot of discussion and negotiation would be needed to be sure >>>> that this new AtInject wouldn?t contain features incompatible with CDI. So >>>> it?d be very time consuming with no guarantee to get what we?d need at the >>>> end. >>>> >>>> 2) former JSR 330 owner don?t mind others take ownership of their spec >>>> to enhance it and we (Red Hat) are the one to take this ownership to secure >>>> CDI: >>>> The best solution to minimize risk. But leading a new specification is >>>> a lot more work than just deciding that we have a specific basic inject ? >>>> part ? in CDI 2.0. Leading a spec is very time consuming, so it could be >>>> better on the paper but will impact CDI 2.0 new features. >>>> >>>> To sum up, as a Java EE user (like I have been for 10 years) I?d be >>>> happy to see this (scenario 2), but as CDI spec lead I fear that it could >>>> lead us in a trap (going to scenario 1 or consuming precious time on >>>> AtInject+1 instead of CDI 2.0) >>>> >>>> Your input, solutions or comment would be appreciated on this point. >>>> >>>> Antoine >>>> >>>> >>>> >>> >> >> >> -- >> 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/20140703/a7af1b69/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 257 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140703/a7af1b69/attachment.gif From antoine at sabot-durand.net Thu Jul 3 06:15:19 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 3 Jul 2014 12:15:19 +0200 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: References: Message-ID: <25AE3FE1-2FFB-4DE9-82FE-2814E7BE299D@sabot-durand.net> Martijn, I started this thread to discuss wether we should do what you?ve just done or not . I?d have liked to have Pete input before stepping like this. I guess the decision is taken now ;). Anyway, thanks for your enthusiasm. It gives good vibes for the coming JSR ;). Antoine Le 3 juil. 2014 ? 11:02, Martijn Verburg a ?crit : > FYI - I've sent a note to the various folks from Google, Pivotal et al, I'll let Antoine explain the CDI 2.0 proposal to them and I'm sure they'll either join this mailing list / discussion or we'll quickly find out there's no appetite and we can move on. > > Cheers, > Martijn > > > On 3 July 2014 09:51, Martijn Verburg wrote: > Hi All, > > To be blunt, this is a social/community issue - not a technical one. We simply need to get hold of the folks at Pivotal, Google (and other 330 EG members) and get them around the virtual table. If they subsequently aren't interested then fine, you should forge your own path. > > There's an absolute mega ton of 330 based DI code out there and 330 compliant containers, if CDI 2.0 wants to be the defacto std going forwards it simply can't afford ignore that. > > @Antoine - let's put our heads together and see who we need to get hold of in the 330 group, I think CDI 2.0 has strong merits and should be explored. > > @Werner - your comments about Bob's commitment (considering what he's done for the tech community at large, let alone Java) are highly inappropriate, please refrain from personal attacks on this or any other public forum. > > > Cheers, > Martijn > > > On 3 July 2014 09:02, Antonio Goncalves wrote: > > To sum up, as a Java EE user (like I have been for 10 years) I?d be happy to see this (scenario 2), but as CDI spec lead I fear that it could lead us in a trap (going to scenario 1 or consuming precious time on AtInject+1 instead of CDI 2.0) > > Well, I'm not spec lead, I'm just a Java EE user... so I like scenario 2 ;o) > > But on the other hand, I think there is so much work to be done around CDI 2.0, parts, and taking those parts to other specifications that battling with JSR 330 might be time consuming. I would go for scenario 1.... and cross fingers > > > On Wed, Jul 2, 2014 at 11:18 PM, Werner Keil wrote: > Dear Antoine/all, > > Thanks for the detailed overview and trying to reach out to the former Spec Leads and EG of JSR 330. I also copied Anatole, Spec Lead of JSR 354, since Bob Lee is officially in his EG, but has practically never provided input there either (like we tend to see sometimes from others considered "Rock Stars" of the Java Community but since then seemingly resting on their laurels or just too busy counting their stock options?<329.gif>) > > Given CDI already was the public perception of "javax.inject" for most parts, I don't necessarily see that it had to be an MR to the original JSR, though as those involved in the EC (Martijn, Badr/MoroccoJUG,..) could probably check with the PMO how to handle a case where the Maintenance Lead of a JSR was not in the position to continue. I last met J?rgen H?ller about a year ago in Copenhagen, so for Pivotal's part as Co Spec Lead, I guess he or the likes of Josh Long could be best to speak to. Happy to get you in touch with them if you want. > > Red Hat was also EG member of JSR 330, so Pete, Gavin or whoever else was there (I remember him from conversations where Mike Keith and I took part in synergy discussions between 330 and CDI 1.0) at the time could also help you with this. > > In theory this could also be part of a new JSR (CDI 2) as long as none of the enhancements you have in mind break the existing API of JSR 330. The scope of CDI 2 to work in an SE/standalone or more lightweight environment than Java EE environment raises a good question of package names like " javax.enterprise.inject.*" So maybe there is room for synergies in a package namespace other than "javax.enterprise" at least for new things you have in mind. > > Kind Regards, > > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead | Eclipse UOMo Lead, Babel Language Champion | Apache Committer > Twitter @wernerkeil | @UnitAPI | @JSR354 | #EclipseUOMo | #Java_Social | #DevOps > Skype werner.keil | Google+ gplus.to/wernerkeil > > * Developer Week: 14/15 Jul 2014, N?rnberg, Germany. Werner Keil, JCP EC Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class Continuous Delivery", "JSR 363 and IoT" (GER) > > * JavaZone 2014: 9-11 Sep 2014, Oslo, Norway. Werner Keil, JCP EC Member, JSR 363 Spec Lead will present "JSR 363 - The Answer to Life Science and the Internet of Everything" > > * JavaOne 2014: Sep 28-Oct 2 2014, San Francisco, USA, Werner Keil, JCP EC Member, JSR 354 EG Member will host "Java and Digital Currencies, Friend or FOE" > > * JMaghreb 3.0: 4-6 Nov 2014, Casablanca, Morocco. Werner Keil, JCP EC Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class DevOps", "JSR 363" > > * Mobile Developer Conference kompakt: 18 Nov 2014, Hamburg, Germany. Werner Keil, JCP EC Member, Apache DeviceMap Committer will present "Apache DeviceMap" (GER) > > > On Wed, Jul 2, 2014 at 10:43 PM, Antoine Sabot-Durand wrote: > Hi all, > > Since the first mention of CDI 2.0 preparation work, we've received a lot of comment about JSR 330 evolution. With the release of the proposal draft yesterday, this topic came up again. So let me give my point of view on this subject to have an open discussion here. > > When we started to discuss about modularity with Pete in last november, my first idea was to go see what we could add in JSR 330 to make it a true specification that could be the first module of CDI. My idea at that time was to discuss with JSR 330 owner to see if we could bring basic concept we have in CDI to AtInject spec. In my mind the main features would have been: > - Enhance the javax.inject.Provider interface to bring it at the same level than javax.enterprise.inject.Instance. That would have included support for AnnotationLiteral and TypeLiteral as well > - Add a Container interface (a very light BeanManger) in JSR 330 to be able to resolve beans instance from outside managed beans > - Add a mechanism to get this Container from non managed beans (like we get access to BeanManager from JNDI or CDI class) > > At that time, I contacted Bob Lee without success (didn?t tried Pivotal since I don?t have contact there). I checked with JCP what could be done if we?d like to see an evolution of JSR 330 and the owner doesn?t care, there seems to have solutions but I let it aside since we were in the middle of CDI 1.2 MR at that time. > > Today I?m a bit torn about this point. Working on opening JSR 330 could be like opening pandora box, since I see 2 scenarios : > > 1) former JSR 330 owners wake up and are ok to get for a new spec version they lead: > Knowing the history of JSR 330 vs JSR 299 I?m not sure everything we?d need would be heard and even if the people leading this would be cooperative, a lot of discussion and negotiation would be needed to be sure that this new AtInject wouldn?t contain features incompatible with CDI. So it?d be very time consuming with no guarantee to get what we?d need at the end. > > 2) former JSR 330 owner don?t mind others take ownership of their spec to enhance it and we (Red Hat) are the one to take this ownership to secure CDI: > The best solution to minimize risk. But leading a new specification is a lot more work than just deciding that we have a specific basic inject ? part ? in CDI 2.0. Leading a spec is very time consuming, so it could be better on the paper but will impact CDI 2.0 new features. > > To sum up, as a Java EE user (like I have been for 10 years) I?d be happy to see this (scenario 2), but as CDI spec lead I fear that it could lead us in a trap (going to scenario 1 or consuming precious time on AtInject+1 instead of CDI 2.0) > > Your input, solutions or comment would be appreciated on this point. > > Antoine > > > > > > > -- > 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/20140703/4f8ed06a/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140703/4f8ed06a/attachment-0001.bin From werner.keil at gmail.com Wed Jul 2 17:18:14 2014 From: werner.keil at gmail.com (Werner Keil) Date: Wed, 2 Jul 2014 23:18:14 +0200 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: References: Message-ID: Dear Antoine/all, Thanks for the detailed overview and trying to reach out to the former Spec Leads and EG of JSR 330. I also copied Anatole, Spec Lead of JSR 354, since Bob Lee is officially in his EG, but has practically never provided input there either (like we tend to see sometimes from others considered "Rock Stars" of the Java Community but since then seemingly resting on their laurels or just too busy counting their stock options?[?]) Given CDI already was the public perception of "javax.inject" for most parts, I don't necessarily see that it had to be an MR to the original JSR, though as those involved in the EC (Martijn, Badr/MoroccoJUG,..) could probably check with the PMO how to handle a case where the Maintenance Lead of a JSR was not in the position to continue. I last met J?rgen H?ller about a year ago in Copenhagen, so for Pivotal's part as Co Spec Lead, I guess he or the likes of Josh Long could be best to speak to. Happy to get you in touch with them if you want. Red Hat was also EG member of JSR 330, so Pete, Gavin or whoever else was there (I remember him from conversations where Mike Keith and I took part in synergy discussions between 330 and CDI 1.0) at the time could also help you with this. In theory this could also be part of a new JSR (CDI 2) as long as none of the enhancements you have in mind break the existing API of JSR 330. The scope of CDI 2 to work in an SE/standalone or more lightweight environment than Java EE environment raises a good question of package names like " javax.enterprise.inject.*" So maybe there is room for synergies in a package namespace other than "javax.enterprise" at least for new things you have in mind. Kind Regards, Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead | Eclipse UOMo Lead, Babel Language Champion | Apache Committer Twitter @wernerkeil | @UnitAPI | @JSR354 | #EclipseUOMo | #Java_Social | #DevOps Skype werner.keil | Google+ gplus.to/wernerkeil * Developer Week: 14/15 Jul 2014, N?rnberg, Germany. Werner Keil, JCP EC Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class Continuous Delivery", "JSR 363 and IoT" (GER) * JavaZone 2014: 9-11 Sep 2014, Oslo, Norway. Werner Keil, JCP EC Member, JSR 363 Spec Lead will present "JSR 363 - The Answer to Life Science and the Internet of Everything" * JavaOne 2014: Sep 28-Oct 2 2014, San Francisco, USA, Werner Keil, JCP EC Member, JSR 354 EG Member will host "Java and Digital Currencies, Friend or FOE" * JMaghreb 3.0: 4-6 Nov 2014, Casablanca, Morocco. Werner Keil, JCP EC Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class DevOps", "JSR 363" * Mobile Developer Conference kompakt: 18 Nov 2014, Hamburg, Germany. Werner Keil, JCP EC Member, Apache DeviceMap Committer will present "Apache DeviceMap" (GER) On Wed, Jul 2, 2014 at 10:43 PM, Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi all, > > Since the first mention of CDI 2.0 preparation work, we've received a lot > of comment about JSR 330 evolution. With the release of the proposal draft > yesterday, this topic came up again. So let me give my point of view on > this subject to have an open discussion here. > > When we started to discuss about modularity with Pete in last november, my > first idea was to go see what we could add in JSR 330 to make it a true > specification that could be the first module of CDI. My idea at that time > was to discuss with JSR 330 owner to see if we could bring basic concept we > have in CDI to AtInject spec. In my mind the main features would have been: > - Enhance the javax.inject.Provider interface to bring it at the same > level than javax.enterprise.inject.Instance. That would have included > support for AnnotationLiteral and TypeLiteral as well > - Add a Container interface (a very light BeanManger) in JSR 330 to be > able to resolve beans instance from outside managed beans > - Add a mechanism to get this Container from non managed beans (like we > get access to BeanManager from JNDI or CDI class) > > At that time, I contacted Bob Lee without success (didn?t tried Pivotal > since I don?t have contact there). I checked with JCP what could be done if > we?d like to see an evolution of JSR 330 and the owner doesn?t care, there > seems to have solutions but I let it aside since we were in the middle of > CDI 1.2 MR at that time. > > Today I?m a bit torn about this point. Working on opening JSR 330 could be > like opening pandora box, since I see 2 scenarios : > > 1) former JSR 330 owners wake up and are ok to get for a new spec version > they lead: > Knowing the history of JSR 330 vs JSR 299 I?m not sure everything we?d > need would be heard and even if the people leading this would be > cooperative, a lot of discussion and negotiation would be needed to be sure > that this new AtInject wouldn?t contain features incompatible with CDI. So > it?d be very time consuming with no guarantee to get what we?d need at the > end. > > 2) former JSR 330 owner don?t mind others take ownership of their spec to > enhance it and we (Red Hat) are the one to take this ownership to secure > CDI: > The best solution to minimize risk. But leading a new specification is a > lot more work than just deciding that we have a specific basic inject ? > part ? in CDI 2.0. Leading a spec is very time consuming, so it could be > better on the paper but will impact CDI 2.0 new features. > > To sum up, as a Java EE user (like I have been for 10 years) I?d be happy > to see this (scenario 2), but as CDI spec lead I fear that it could lead us > in a trap (going to scenario 1 or consuming precious time on AtInject+1 > instead of CDI 2.0) > > Your input, solutions or comment would be appreciated on this point. > > Antoine > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140702/c8293753/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 257 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140702/c8293753/attachment-0001.gif From antonio.goncalves at gmail.com Thu Jul 3 04:02:43 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Thu, 3 Jul 2014 10:02:43 +0200 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: References: Message-ID: > To sum up, as a Java EE user (like I have been for 10 years) I?d be happy to see this (scenario 2), but as CDI spec lead I fear that it could lead us in a trap (going to scenario 1 or consuming precious time on AtInject+1 instead of CDI 2.0) Well, I'm not spec lead, I'm just a Java EE user... so I like scenario 2 ;o) But on the other hand, I think there is so much work to be done around CDI 2.0, parts, and taking those parts to other specifications that battling with JSR 330 might be time consuming. I would go for scenario 1.... and cross fingers On Wed, Jul 2, 2014 at 11:18 PM, Werner Keil wrote: > Dear Antoine/all, > > Thanks for the detailed overview and trying to reach out to the former > Spec Leads and EG of JSR 330. I also copied Anatole, Spec Lead of JSR 354, > since Bob Lee is officially in his EG, but has practically never provided > input there either (like we tend to see sometimes from others considered > "Rock Stars" of the Java Community but since then seemingly resting on > their laurels or just too busy counting their stock options?[?]) > > Given CDI already was the public perception of "javax.inject" for most > parts, I don't necessarily see that it had to be an MR to the original JSR, > though as those involved in the EC (Martijn, Badr/MoroccoJUG,..) could > probably check with the PMO how to handle a case where the Maintenance Lead > of a JSR was not in the position to continue. I last met J?rgen H?ller > about a year ago in Copenhagen, so for Pivotal's part as Co Spec Lead, I > guess he or the likes of Josh Long could be best to speak to. Happy to get > you in touch with them if you want. > > Red Hat was also EG member of JSR 330, so Pete, Gavin or whoever else was > there (I remember him from conversations where Mike Keith and I took part > in synergy discussions between 330 and CDI 1.0) at the time could also help > you with this. > > In theory this could also be part of a new JSR (CDI 2) as long as none of > the enhancements you have in mind break the existing API of JSR 330. The > scope of CDI 2 to work in an SE/standalone or more lightweight environment > than Java EE environment raises a good question of package names like " javax.enterprise.inject.*" > So maybe there is room for synergies in a package namespace other than > "javax.enterprise" at least for new things you have in mind. > > Kind Regards, > > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead | > Eclipse UOMo Lead, Babel Language Champion | Apache Committer > > Twitter @wernerkeil | @UnitAPI | @JSR354 | #EclipseUOMo | #Java_Social | > #DevOps > Skype werner.keil | Google+ gplus.to/wernerkeil > > * Developer Week: 14/15 Jul 2014, N?rnberg, Germany. Werner Keil, JCP EC > Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class > Continuous Delivery", "JSR 363 and IoT" (GER) > > * JavaZone 2014: 9-11 Sep 2014, Oslo, Norway. Werner Keil, JCP EC Member, > JSR 363 Spec Lead will present "JSR 363 - The Answer to Life Science and > the Internet of Everything" > > * JavaOne 2014: Sep 28-Oct 2 2014, San Francisco, USA, Werner Keil, JCP EC > Member, JSR 354 EG Member will host "Java and Digital Currencies, Friend or > FOE" > > * JMaghreb 3.0: 4-6 Nov 2014, Casablanca, Morocco. Werner Keil, JCP EC > Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class > DevOps", "JSR 363" > > * Mobile Developer Conference kompakt: 18 Nov 2014, Hamburg, Germany. > Werner Keil, JCP EC Member, Apache DeviceMap Committer will present "Apache > DeviceMap" (GER) > > > On Wed, Jul 2, 2014 at 10:43 PM, Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > >> Hi all, >> >> Since the first mention of CDI 2.0 preparation work, we've received a lot >> of comment about JSR 330 evolution. With the release of the proposal draft >> yesterday, this topic came up again. So let me give my point of view on >> this subject to have an open discussion here. >> >> When we started to discuss about modularity with Pete in last november, >> my first idea was to go see what we could add in JSR 330 to make it a true >> specification that could be the first module of CDI. My idea at that time >> was to discuss with JSR 330 owner to see if we could bring basic concept we >> have in CDI to AtInject spec. In my mind the main features would have been: >> - Enhance the javax.inject.Provider interface to bring it at the same >> level than javax.enterprise.inject.Instance. That would have included >> support for AnnotationLiteral and TypeLiteral as well >> - Add a Container interface (a very light BeanManger) in JSR 330 to be >> able to resolve beans instance from outside managed beans >> - Add a mechanism to get this Container from non managed beans (like we >> get access to BeanManager from JNDI or CDI class) >> >> At that time, I contacted Bob Lee without success (didn?t tried Pivotal >> since I don?t have contact there). I checked with JCP what could be done if >> we?d like to see an evolution of JSR 330 and the owner doesn?t care, there >> seems to have solutions but I let it aside since we were in the middle of >> CDI 1.2 MR at that time. >> >> Today I?m a bit torn about this point. Working on opening JSR 330 could >> be like opening pandora box, since I see 2 scenarios : >> >> 1) former JSR 330 owners wake up and are ok to get for a new spec version >> they lead: >> Knowing the history of JSR 330 vs JSR 299 I?m not sure everything we?d >> need would be heard and even if the people leading this would be >> cooperative, a lot of discussion and negotiation would be needed to be sure >> that this new AtInject wouldn?t contain features incompatible with CDI. So >> it?d be very time consuming with no guarantee to get what we?d need at the >> end. >> >> 2) former JSR 330 owner don?t mind others take ownership of their spec to >> enhance it and we (Red Hat) are the one to take this ownership to secure >> CDI: >> The best solution to minimize risk. But leading a new specification is a >> lot more work than just deciding that we have a specific basic inject ? >> part ? in CDI 2.0. Leading a spec is very time consuming, so it could be >> better on the paper but will impact CDI 2.0 new features. >> >> To sum up, as a Java EE user (like I have been for 10 years) I?d be happy >> to see this (scenario 2), but as CDI spec lead I fear that it could lead us >> in a trap (going to scenario 1 or consuming precious time on AtInject+1 >> instead of CDI 2.0) >> >> Your input, solutions or comment would be appreciated on this point. >> >> Antoine >> >> >> > -- 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/20140703/a34e1a7e/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: 329.gif Type: image/gif Size: 257 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140703/a34e1a7e/attachment-0001.gif From werner.keil at gmail.com Thu Jul 3 05:34:56 2014 From: werner.keil at gmail.com (Werner Keil) Date: Thu, 3 Jul 2014 11:34:56 +0200 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: References: Message-ID: @Martijn/all, Thanks for reaching out to Pivotal/Google. You know best, Google may be a bit tricky considering the lawsuit. And please cool down about non-responsive or inactive peopple in the JCP or elsewhere. As you know best (though you are not the primary rep for LJC there any more), the JSR 364 EG EC and other JCP.next initiatives were keen to get people involved, but we don't want "Vanity Members" who just claim they are on a list or get their "pin stripe" full of JSR or other Open Source "memberships" without ever contributing more than to say "Hello" or "Goodbye" in a mailing list. Regardless of his or Interface 21's/SpringSource's contribtion to the larger Java ecosystem, the former Co Spec Lead or JSR 330 Rod Johnson was exactly that case (I personally whitnessed his "15 min. of Fame" in a single EC F2F where he then vanished and was never seen) And especially in JSR 354 Crazy Bob has been equally invisible. Which is why Anatole wanted to have a word with him about still being on the EG or not. We need people like Antoine who try to get things done now, not "filibusters" or some "bust" in a "Hall of Fame" (well, to some extent that's what the "Rock Stars" are for[?]), neither in this JSR nor others. There could be other roles for them from "Observer" to "Contributor" (if JSR 364 concludes) so please try your best to get 364 or 358 out, but spare this here. Cheers, Werner On Thu, Jul 3, 2014 at 11:02 AM, Martijn Verburg wrote: > FYI - I've sent a note to the various folks from Google, Pivotal et al, > I'll let Antoine explain the CDI 2.0 proposal to them and I'm sure they'll > either join this mailing list / discussion or we'll quickly find out > there's no appetite and we can move on. > > Cheers, > Martijn > > > On 3 July 2014 09:51, Martijn Verburg wrote: > >> Hi All, >> >> To be blunt, this is a social/community issue - not a technical one. We >> simply need to get hold of the folks at Pivotal, Google (and other 330 EG >> members) and get them around the virtual table. If they subsequently >> aren't interested then fine, you should forge your own path. >> >> There's an absolute mega ton of 330 based DI code out there and 330 >> compliant containers, if CDI 2.0 wants to be the defacto std going forwards >> it simply can't afford ignore that. >> >> @Antoine - let's put our heads together and see who we need to get hold >> of in the 330 group, I think CDI 2.0 has strong merits and should be >> explored. >> >> @Werner - your comments about Bob's commitment (considering what he's >> done for the tech community at large, let alone Java) are highly >> inappropriate, please refrain from personal attacks on this or any other >> public forum. >> >> >> Cheers, >> Martijn >> >> >> On 3 July 2014 09:02, Antonio Goncalves >> wrote: >> >>> > To sum up, as a Java EE user (like I have been for 10 years) I?d be >>> happy to see this (scenario 2), but as CDI spec lead I fear that it could >>> lead us in a trap (going to scenario 1 or consuming precious time on >>> AtInject+1 instead of CDI 2.0) >>> >>> Well, I'm not spec lead, I'm just a Java EE user... so I like scenario 2 >>> ;o) >>> >>> But on the other hand, I think there is so much work to be done around >>> CDI 2.0, parts, and taking those parts to other specifications that >>> battling with JSR 330 might be time consuming. I would go for scenario >>> 1.... and cross fingers >>> >>> >>> On Wed, Jul 2, 2014 at 11:18 PM, Werner Keil >>> wrote: >>> >>>> Dear Antoine/all, >>>> >>>> Thanks for the detailed overview and trying to reach out to the former >>>> Spec Leads and EG of JSR 330. I also copied Anatole, Spec Lead of JSR 354, >>>> since Bob Lee is officially in his EG, but has practically never provided >>>> input there either (like we tend to see sometimes from others considered >>>> "Rock Stars" of the Java Community but since then seemingly resting on >>>> their laurels or just too busy counting their stock options?[?]) >>>> >>>> Given CDI already was the public perception of "javax.inject" for most >>>> parts, I don't necessarily see that it had to be an MR to the original JSR, >>>> though as those involved in the EC (Martijn, Badr/MoroccoJUG,..) could >>>> probably check with the PMO how to handle a case where the Maintenance Lead >>>> of a JSR was not in the position to continue. I last met J?rgen H?ller >>>> about a year ago in Copenhagen, so for Pivotal's part as Co Spec Lead, I >>>> guess he or the likes of Josh Long could be best to speak to. Happy to get >>>> you in touch with them if you want. >>>> >>>> Red Hat was also EG member of JSR 330, so Pete, Gavin or whoever else >>>> was there (I remember him from conversations where Mike Keith and I took >>>> part in synergy discussions between 330 and CDI 1.0) at the time could also >>>> help you with this. >>>> >>>> In theory this could also be part of a new JSR (CDI 2) as long as none >>>> of the enhancements you have in mind break the existing API of JSR 330. The >>>> scope of CDI 2 to work in an SE/standalone or more lightweight environment >>>> than Java EE environment raises a good question of package names like " >>>> javax.enterprise.inject.*" So maybe there is room for synergies in a >>>> package namespace other than "javax.enterprise" at least for new things you >>>> have in mind. >>>> >>>> Kind Regards, >>>> >>>> Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead | >>>> Eclipse UOMo Lead, Babel Language Champion | Apache Committer >>>> >>>> Twitter @wernerkeil | @UnitAPI | @JSR354 | #EclipseUOMo | #Java_Social >>>> | #DevOps >>>> Skype werner.keil | Google+ gplus.to/wernerkeil >>>> >>>> * Developer Week: 14/15 Jul 2014, N?rnberg, Germany. Werner Keil, JCP >>>> EC Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class >>>> Continuous Delivery", "JSR 363 and IoT" (GER) >>>> >>>> * JavaZone 2014: 9-11 Sep 2014, Oslo, Norway. Werner Keil, JCP EC >>>> Member, JSR 363 Spec Lead will present "JSR 363 - The Answer to Life >>>> Science and the Internet of Everything" >>>> >>>> * JavaOne 2014: Sep 28-Oct 2 2014, San Francisco, USA, Werner Keil, JCP >>>> EC Member, JSR 354 EG Member will host "Java and Digital Currencies, Friend >>>> or FOE" >>>> >>>> * JMaghreb 3.0: 4-6 Nov 2014, Casablanca, Morocco. Werner Keil, JCP EC >>>> Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class >>>> DevOps", "JSR 363" >>>> >>>> * Mobile Developer Conference kompakt: 18 Nov 2014, Hamburg, Germany. >>>> Werner Keil, JCP EC Member, Apache DeviceMap Committer will present "Apache >>>> DeviceMap" (GER) >>>> >>>> >>>> On Wed, Jul 2, 2014 at 10:43 PM, Antoine Sabot-Durand < >>>> antoine at sabot-durand.net> wrote: >>>> >>>>> Hi all, >>>>> >>>>> Since the first mention of CDI 2.0 preparation work, we've received a >>>>> lot of comment about JSR 330 evolution. With the release of the proposal >>>>> draft yesterday, this topic came up again. So let me give my point of view >>>>> on this subject to have an open discussion here. >>>>> >>>>> When we started to discuss about modularity with Pete in last >>>>> november, my first idea was to go see what we could add in JSR 330 to make >>>>> it a true specification that could be the first module of CDI. My idea at >>>>> that time was to discuss with JSR 330 owner to see if we could bring basic >>>>> concept we have in CDI to AtInject spec. In my mind the main features would >>>>> have been: >>>>> - Enhance the javax.inject.Provider interface to bring it at the >>>>> same level than javax.enterprise.inject.Instance. That would have >>>>> included support for AnnotationLiteral and TypeLiteral as well >>>>> - Add a Container interface (a very light BeanManger) in JSR 330 to >>>>> be able to resolve beans instance from outside managed beans >>>>> - Add a mechanism to get this Container from non managed beans (like >>>>> we get access to BeanManager from JNDI or CDI class) >>>>> >>>>> At that time, I contacted Bob Lee without success (didn?t tried >>>>> Pivotal since I don?t have contact there). I checked with JCP what could be >>>>> done if we?d like to see an evolution of JSR 330 and the owner doesn?t >>>>> care, there seems to have solutions but I let it aside since we were in the >>>>> middle of CDI 1.2 MR at that time. >>>>> >>>>> Today I?m a bit torn about this point. Working on opening JSR 330 >>>>> could be like opening pandora box, since I see 2 scenarios : >>>>> >>>>> 1) former JSR 330 owners wake up and are ok to get for a new spec >>>>> version they lead: >>>>> Knowing the history of JSR 330 vs JSR 299 I?m not sure everything we?d >>>>> need would be heard and even if the people leading this would be >>>>> cooperative, a lot of discussion and negotiation would be needed to be sure >>>>> that this new AtInject wouldn?t contain features incompatible with CDI. So >>>>> it?d be very time consuming with no guarantee to get what we?d need at the >>>>> end. >>>>> >>>>> 2) former JSR 330 owner don?t mind others take ownership of their spec >>>>> to enhance it and we (Red Hat) are the one to take this ownership to secure >>>>> CDI: >>>>> The best solution to minimize risk. But leading a new specification is >>>>> a lot more work than just deciding that we have a specific basic inject ? >>>>> part ? in CDI 2.0. Leading a spec is very time consuming, so it could be >>>>> better on the paper but will impact CDI 2.0 new features. >>>>> >>>>> To sum up, as a Java EE user (like I have been for 10 years) I?d be >>>>> happy to see this (scenario 2), but as CDI spec lead I fear that it could >>>>> lead us in a trap (going to scenario 1 or consuming precious time on >>>>> AtInject+1 instead of CDI 2.0) >>>>> >>>>> Your input, solutions or comment would be appreciated on this point. >>>>> >>>>> Antoine >>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> 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/20140703/32b7479a/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 257 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140703/32b7479a/attachment-0001.gif From werner.keil at gmail.com Thu Jul 3 05:49:35 2014 From: werner.keil at gmail.com (Werner Keil) Date: Thu, 3 Jul 2014 11:49:35 +0200 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: References: Message-ID: P.s.: The list of JCP Members after the renewal could be a little outdated, but given Pivotal looks like a completely independent company now, not a department of VMWare, they do not even seem to be a JCP Member at the moment, so Pivotal reviving JSR 330 or becoming MR might require them joining[?] On Thu, Jul 3, 2014 at 11:34 AM, Werner Keil wrote: > @Martijn/all, > > Thanks for reaching out to Pivotal/Google. You know best, Google may be a > bit tricky considering the lawsuit. > > And please cool down about non-responsive or inactive peopple in the JCP > or elsewhere. As you know best (though you are not the primary rep for LJC > there any more), the JSR 364 EG EC and other JCP.next initiatives were keen > to get people involved, but we don't want "Vanity Members" who just claim > they are on a list or get their "pin stripe" full of JSR or other Open > Source "memberships" without ever contributing more than to say "Hello" or > "Goodbye" in a mailing list. Regardless of his or Interface > 21's/SpringSource's contribtion to the larger Java ecosystem, the former Co > Spec Lead or JSR 330 Rod Johnson was exactly that case (I personally > whitnessed his "15 min. of Fame" in a single EC F2F where he then vanished > and was never seen) > And especially in JSR 354 Crazy Bob has been equally invisible. Which is > why Anatole wanted to have a word with him about still being on the EG or > not. > > We need people like Antoine who try to get things done now, not > "filibusters" or some "bust" in a "Hall of Fame" (well, to some extent > that's what the "Rock Stars" are for[?]), neither in this JSR nor others. > There could be other roles for them from "Observer" to "Contributor" (if > JSR 364 concludes) so please try your best to get 364 or 358 out, but spare > this here. > > Cheers, > Werner > > On Thu, Jul 3, 2014 at 11:02 AM, Martijn Verburg > wrote: > >> FYI - I've sent a note to the various folks from Google, Pivotal et al, >> I'll let Antoine explain the CDI 2.0 proposal to them and I'm sure they'll >> either join this mailing list / discussion or we'll quickly find out >> there's no appetite and we can move on. >> >> Cheers, >> Martijn >> >> >> On 3 July 2014 09:51, Martijn Verburg wrote: >> >>> Hi All, >>> >>> To be blunt, this is a social/community issue - not a technical one. We >>> simply need to get hold of the folks at Pivotal, Google (and other 330 EG >>> members) and get them around the virtual table. If they subsequently >>> aren't interested then fine, you should forge your own path. >>> >>> There's an absolute mega ton of 330 based DI code out there and 330 >>> compliant containers, if CDI 2.0 wants to be the defacto std going forwards >>> it simply can't afford ignore that. >>> >>> @Antoine - let's put our heads together and see who we need to get hold >>> of in the 330 group, I think CDI 2.0 has strong merits and should be >>> explored. >>> >>> @Werner - your comments about Bob's commitment (considering what he's >>> done for the tech community at large, let alone Java) are highly >>> inappropriate, please refrain from personal attacks on this or any other >>> public forum. >>> >>> >>> Cheers, >>> Martijn >>> >>> >>> On 3 July 2014 09:02, Antonio Goncalves >>> wrote: >>> >>>> > To sum up, as a Java EE user (like I have been for 10 years) I?d be >>>> happy to see this (scenario 2), but as CDI spec lead I fear that it could >>>> lead us in a trap (going to scenario 1 or consuming precious time on >>>> AtInject+1 instead of CDI 2.0) >>>> >>>> Well, I'm not spec lead, I'm just a Java EE user... so I like scenario >>>> 2 ;o) >>>> >>>> But on the other hand, I think there is so much work to be done around >>>> CDI 2.0, parts, and taking those parts to other specifications that >>>> battling with JSR 330 might be time consuming. I would go for scenario >>>> 1.... and cross fingers >>>> >>>> >>>> On Wed, Jul 2, 2014 at 11:18 PM, Werner Keil >>>> wrote: >>>> >>>>> Dear Antoine/all, >>>>> >>>>> Thanks for the detailed overview and trying to reach out to the former >>>>> Spec Leads and EG of JSR 330. I also copied Anatole, Spec Lead of JSR 354, >>>>> since Bob Lee is officially in his EG, but has practically never provided >>>>> input there either (like we tend to see sometimes from others considered >>>>> "Rock Stars" of the Java Community but since then seemingly resting on >>>>> their laurels or just too busy counting their stock options?[?]) >>>>> >>>>> Given CDI already was the public perception of "javax.inject" for most >>>>> parts, I don't necessarily see that it had to be an MR to the original JSR, >>>>> though as those involved in the EC (Martijn, Badr/MoroccoJUG,..) could >>>>> probably check with the PMO how to handle a case where the Maintenance Lead >>>>> of a JSR was not in the position to continue. I last met J?rgen H?ller >>>>> about a year ago in Copenhagen, so for Pivotal's part as Co Spec Lead, I >>>>> guess he or the likes of Josh Long could be best to speak to. Happy to get >>>>> you in touch with them if you want. >>>>> >>>>> Red Hat was also EG member of JSR 330, so Pete, Gavin or whoever else >>>>> was there (I remember him from conversations where Mike Keith and I took >>>>> part in synergy discussions between 330 and CDI 1.0) at the time could also >>>>> help you with this. >>>>> >>>>> In theory this could also be part of a new JSR (CDI 2) as long as none >>>>> of the enhancements you have in mind break the existing API of JSR 330. The >>>>> scope of CDI 2 to work in an SE/standalone or more lightweight environment >>>>> than Java EE environment raises a good question of package names like " >>>>> javax.enterprise.inject.*" So maybe there is room for synergies in a >>>>> package namespace other than "javax.enterprise" at least for new things you >>>>> have in mind. >>>>> >>>>> Kind Regards, >>>>> >>>>> Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead | >>>>> Eclipse UOMo Lead, Babel Language Champion | Apache Committer >>>>> >>>>> Twitter @wernerkeil | @UnitAPI | @JSR354 | #EclipseUOMo | #Java_Social >>>>> | #DevOps >>>>> Skype werner.keil | Google+ gplus.to/wernerkeil >>>>> >>>>> * Developer Week: 14/15 Jul 2014, N?rnberg, Germany. Werner Keil, JCP >>>>> EC Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' >>>>> class Continuous Delivery", "JSR 363 and IoT" (GER) >>>>> >>>>> * JavaZone 2014: 9-11 Sep 2014, Oslo, Norway. Werner Keil, JCP EC >>>>> Member, JSR 363 Spec Lead will present "JSR 363 - The Answer to Life >>>>> Science and the Internet of Everything" >>>>> >>>>> * JavaOne 2014: Sep 28-Oct 2 2014, San Francisco, USA, Werner Keil, >>>>> JCP EC Member, JSR 354 EG Member will host "Java and Digital Currencies, >>>>> Friend or FOE" >>>>> >>>>> * JMaghreb 3.0: 4-6 Nov 2014, Casablanca, Morocco. Werner Keil, JCP EC >>>>> Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class >>>>> DevOps", "JSR 363" >>>>> >>>>> * Mobile Developer Conference kompakt: 18 Nov 2014, Hamburg, Germany. >>>>> Werner Keil, JCP EC Member, Apache DeviceMap Committer will present "Apache >>>>> DeviceMap" (GER) >>>>> >>>>> >>>>> On Wed, Jul 2, 2014 at 10:43 PM, Antoine Sabot-Durand < >>>>> antoine at sabot-durand.net> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> Since the first mention of CDI 2.0 preparation work, we've received a >>>>>> lot of comment about JSR 330 evolution. With the release of the proposal >>>>>> draft yesterday, this topic came up again. So let me give my point of view >>>>>> on this subject to have an open discussion here. >>>>>> >>>>>> When we started to discuss about modularity with Pete in last >>>>>> november, my first idea was to go see what we could add in JSR 330 to make >>>>>> it a true specification that could be the first module of CDI. My idea at >>>>>> that time was to discuss with JSR 330 owner to see if we could bring basic >>>>>> concept we have in CDI to AtInject spec. In my mind the main features would >>>>>> have been: >>>>>> - Enhance the javax.inject.Provider interface to bring it at the >>>>>> same level than javax.enterprise.inject.Instance. That would have >>>>>> included support for AnnotationLiteral and TypeLiteral as well >>>>>> - Add a Container interface (a very light BeanManger) in JSR 330 to >>>>>> be able to resolve beans instance from outside managed beans >>>>>> - Add a mechanism to get this Container from non managed beans (like >>>>>> we get access to BeanManager from JNDI or CDI class) >>>>>> >>>>>> At that time, I contacted Bob Lee without success (didn?t tried >>>>>> Pivotal since I don?t have contact there). I checked with JCP what could be >>>>>> done if we?d like to see an evolution of JSR 330 and the owner doesn?t >>>>>> care, there seems to have solutions but I let it aside since we were in the >>>>>> middle of CDI 1.2 MR at that time. >>>>>> >>>>>> Today I?m a bit torn about this point. Working on opening JSR 330 >>>>>> could be like opening pandora box, since I see 2 scenarios : >>>>>> >>>>>> 1) former JSR 330 owners wake up and are ok to get for a new spec >>>>>> version they lead: >>>>>> Knowing the history of JSR 330 vs JSR 299 I?m not sure everything >>>>>> we?d need would be heard and even if the people leading this would be >>>>>> cooperative, a lot of discussion and negotiation would be needed to be sure >>>>>> that this new AtInject wouldn?t contain features incompatible with CDI. So >>>>>> it?d be very time consuming with no guarantee to get what we?d need at the >>>>>> end. >>>>>> >>>>>> 2) former JSR 330 owner don?t mind others take ownership of their >>>>>> spec to enhance it and we (Red Hat) are the one to take this ownership to >>>>>> secure CDI: >>>>>> The best solution to minimize risk. But leading a new specification >>>>>> is a lot more work than just deciding that we have a specific basic inject >>>>>> ? part ? in CDI 2.0. Leading a spec is very time consuming, so it could be >>>>>> better on the paper but will impact CDI 2.0 new features. >>>>>> >>>>>> To sum up, as a Java EE user (like I have been for 10 years) I?d be >>>>>> happy to see this (scenario 2), but as CDI spec lead I fear that it could >>>>>> lead us in a trap (going to scenario 1 or consuming precious time on >>>>>> AtInject+1 instead of CDI 2.0) >>>>>> >>>>>> Your input, solutions or comment would be appreciated on this point. >>>>>> >>>>>> Antoine >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> 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/20140703/15dee426/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 257 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140703/15dee426/attachment-0001.gif From atsticks at gmail.com Thu Jul 3 05:58:56 2014 From: atsticks at gmail.com (Anatole Tresch) Date: Thu, 3 Jul 2014 11:58:56 +0200 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: References: Message-ID: <380AE357-A2CF-4949-A6B7-EB21362DC89A@gmail.com> Hi All Same from my side. My experience eg with Google guys has been very positive and constructive. I would expect there is a real chance to turn the former conflict into a widely accepted standard, which would be very valuable for any future evolution in the Java eco-system. Best Anatole - Anatole Tresch Gl?rnischweg 10 8620 Wetzikon Tel +41 (43) 317 05 30 - Send from Mobile > Am 03.07.2014 um 11:02 schrieb Martijn Verburg : > > FYI - I've sent a note to the various folks from Google, Pivotal et al, I'll let Antoine explain the CDI 2.0 proposal to them and I'm sure they'll either join this mailing list / discussion or we'll quickly find out there's no appetite and we can move on. > > Cheers, > Martijn > > >> On 3 July 2014 09:51, Martijn Verburg wrote: >> Hi All, >> >> To be blunt, this is a social/community issue - not a technical one. We simply need to get hold of the folks at Pivotal, Google (and other 330 EG members) and get them around the virtual table. If they subsequently aren't interested then fine, you should forge your own path. >> >> There's an absolute mega ton of 330 based DI code out there and 330 compliant containers, if CDI 2.0 wants to be the defacto std going forwards it simply can't afford ignore that. >> >> @Antoine - let's put our heads together and see who we need to get hold of in the 330 group, I think CDI 2.0 has strong merits and should be explored. >> >> @Werner - your comments about Bob's commitment (considering what he's done for the tech community at large, let alone Java) are highly inappropriate, please refrain from personal attacks on this or any other public forum. >> >> >> Cheers, >> Martijn >> >> >>> On 3 July 2014 09:02, Antonio Goncalves wrote: >>> > To sum up, as a Java EE user (like I have been for 10 years) I?d be happy to see this (scenario 2), but as CDI spec lead I fear that it could lead us in a trap (going to scenario 1 or consuming precious time on AtInject+1 instead of CDI 2.0) >>> >>> Well, I'm not spec lead, I'm just a Java EE user... so I like scenario 2 ;o) >>> >>> But on the other hand, I think there is so much work to be done around CDI 2.0, parts, and taking those parts to other specifications that battling with JSR 330 might be time consuming. I would go for scenario 1.... and cross fingers >>> >>> >>>> On Wed, Jul 2, 2014 at 11:18 PM, Werner Keil wrote: >>>> Dear Antoine/all, >>>> >>>> Thanks for the detailed overview and trying to reach out to the former Spec Leads and EG of JSR 330. I also copied Anatole, Spec Lead of JSR 354, since Bob Lee is officially in his EG, but has practically never provided input there either (like we tend to see sometimes from others considered "Rock Stars" of the Java Community but since then seemingly resting on their laurels or just too busy counting their stock options?<329.gif>) >>>> >>>> Given CDI already was the public perception of "javax.inject" for most parts, I don't necessarily see that it had to be an MR to the original JSR, though as those involved in the EC (Martijn, Badr/MoroccoJUG,..) could probably check with the PMO how to handle a case where the Maintenance Lead of a JSR was not in the position to continue. I last met J?rgen H?ller about a year ago in Copenhagen, so for Pivotal's part as Co Spec Lead, I guess he or the likes of Josh Long could be best to speak to. Happy to get you in touch with them if you want. >>>> >>>> Red Hat was also EG member of JSR 330, so Pete, Gavin or whoever else was there (I remember him from conversations where Mike Keith and I took part in synergy discussions between 330 and CDI 1.0) at the time could also help you with this. >>>> >>>> In theory this could also be part of a new JSR (CDI 2) as long as none of the enhancements you have in mind break the existing API of JSR 330. The scope of CDI 2 to work in an SE/standalone or more lightweight environment than Java EE environment raises a good question of package names like " javax.enterprise.inject.*" So maybe there is room for synergies in a package namespace other than "javax.enterprise" at least for new things you have in mind. >>>> >>>> Kind Regards, >>>> >>>> Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead | Eclipse UOMo Lead, Babel Language Champion | Apache Committer >>>> Twitter @wernerkeil | @UnitAPI | @JSR354 | #EclipseUOMo | #Java_Social | #DevOps >>>> Skype werner.keil | Google+ gplus.to/wernerkeil >>>> >>>> * Developer Week: 14/15 Jul 2014, N?rnberg, Germany. Werner Keil, JCP EC Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class Continuous Delivery", "JSR 363 and IoT" (GER) >>>> >>>> * JavaZone 2014: 9-11 Sep 2014, Oslo, Norway. Werner Keil, JCP EC Member, JSR 363 Spec Lead will present "JSR 363 - The Answer to Life Science and the Internet of Everything" >>>> >>>> * JavaOne 2014: Sep 28-Oct 2 2014, San Francisco, USA, Werner Keil, JCP EC Member, JSR 354 EG Member will host "Java and Digital Currencies, Friend or FOE" >>>> >>>> * JMaghreb 3.0: 4-6 Nov 2014, Casablanca, Morocco. Werner Keil, JCP EC Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class DevOps", "JSR 363" >>>> >>>> * Mobile Developer Conference kompakt: 18 Nov 2014, Hamburg, Germany. Werner Keil, JCP EC Member, Apache DeviceMap Committer will present "Apache DeviceMap" (GER) >>>> >>>> >>>>> On Wed, Jul 2, 2014 at 10:43 PM, Antoine Sabot-Durand wrote: >>>>> Hi all, >>>>> >>>>> Since the first mention of CDI 2.0 preparation work, we've received a lot of comment about JSR 330 evolution. With the release of the proposal draft yesterday, this topic came up again. So let me give my point of view on this subject to have an open discussion here. >>>>> >>>>> When we started to discuss about modularity with Pete in last november, my first idea was to go see what we could add in JSR 330 to make it a true specification that could be the first module of CDI. My idea at that time was to discuss with JSR 330 owner to see if we could bring basic concept we have in CDI to AtInject spec. In my mind the main features would have been: >>>>> - Enhance the javax.inject.Provider interface to bring it at the same level than javax.enterprise.inject.Instance. That would have included support for AnnotationLiteral and TypeLiteral as well >>>>> - Add a Container interface (a very light BeanManger) in JSR 330 to be able to resolve beans instance from outside managed beans >>>>> - Add a mechanism to get this Container from non managed beans (like we get access to BeanManager from JNDI or CDI class) >>>>> >>>>> At that time, I contacted Bob Lee without success (didn?t tried Pivotal since I don?t have contact there). I checked with JCP what could be done if we?d like to see an evolution of JSR 330 and the owner doesn?t care, there seems to have solutions but I let it aside since we were in the middle of CDI 1.2 MR at that time. >>>>> >>>>> Today I?m a bit torn about this point. Working on opening JSR 330 could be like opening pandora box, since I see 2 scenarios : >>>>> >>>>> 1) former JSR 330 owners wake up and are ok to get for a new spec version they lead: >>>>> Knowing the history of JSR 330 vs JSR 299 I?m not sure everything we?d need would be heard and even if the people leading this would be cooperative, a lot of discussion and negotiation would be needed to be sure that this new AtInject wouldn?t contain features incompatible with CDI. So it?d be very time consuming with no guarantee to get what we?d need at the end. >>>>> >>>>> 2) former JSR 330 owner don?t mind others take ownership of their spec to enhance it and we (Red Hat) are the one to take this ownership to secure CDI: >>>>> The best solution to minimize risk. But leading a new specification is a lot more work than just deciding that we have a specific basic inject ? part ? in CDI 2.0. Leading a spec is very time consuming, so it could be better on the paper but will impact CDI 2.0 new features. >>>>> >>>>> To sum up, as a Java EE user (like I have been for 10 years) I?d be happy to see this (scenario 2), but as CDI spec lead I fear that it could lead us in a trap (going to scenario 1 or consuming precious time on AtInject+1 instead of CDI 2.0) >>>>> >>>>> Your input, solutions or comment would be appreciated on this point. >>>>> >>>>> Antoine >>> >>> >>> >>> -- >>> 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/20140703/2f1b801b/attachment.html From martijnverburg at gmail.com Thu Jul 3 06:31:03 2014 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 3 Jul 2014 11:31:03 +0100 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: <25AE3FE1-2FFB-4DE9-82FE-2814E7BE299D@sabot-durand.net> References: <25AE3FE1-2FFB-4DE9-82FE-2814E7BE299D@sabot-durand.net> Message-ID: Hi Antoine, My apologies - I'm like a Bull in a China shop when it comes to trying to get people together - I always figure that if its a "No" then we should get to the "No" quickly :-). I think CDI 2.0 is important to the community at large - it may pivot slightly from the original intent, but context aware DI for Java SE would be a powerful tool in the toolbox (e.g. Oh look I'm writing a Java SE app that uses websockets......, now I just need to inject a....). Cheers, Martijn On 3 July 2014 11:15, Antoine Sabot-Durand wrote: > Martijn, > > I started this thread to discuss wether we should do what you?ve just done > or not . I?d have liked to have Pete input before stepping like this. I > guess the decision is taken now ;). > Anyway, thanks for your enthusiasm. It gives good vibes for the coming JSR > ;). > > > Antoine > > > Le 3 juil. 2014 ? 11:02, Martijn Verburg a > ?crit : > > FYI - I've sent a note to the various folks from Google, Pivotal et al, > I'll let Antoine explain the CDI 2.0 proposal to them and I'm sure they'll > either join this mailing list / discussion or we'll quickly find out > there's no appetite and we can move on. > > Cheers, > Martijn > > > On 3 July 2014 09:51, Martijn Verburg wrote: > >> Hi All, >> >> To be blunt, this is a social/community issue - not a technical one. We >> simply need to get hold of the folks at Pivotal, Google (and other 330 EG >> members) and get them around the virtual table. If they subsequently >> aren't interested then fine, you should forge your own path. >> >> There's an absolute mega ton of 330 based DI code out there and 330 >> compliant containers, if CDI 2.0 wants to be the defacto std going forwards >> it simply can't afford ignore that. >> >> @Antoine - let's put our heads together and see who we need to get hold >> of in the 330 group, I think CDI 2.0 has strong merits and should be >> explored. >> >> @Werner - your comments about Bob's commitment (considering what he's >> done for the tech community at large, let alone Java) are highly >> inappropriate, please refrain from personal attacks on this or any other >> public forum. >> >> >> Cheers, >> Martijn >> >> >> On 3 July 2014 09:02, Antonio Goncalves >> wrote: >> >>> > To sum up, as a Java EE user (like I have been for 10 years) I?d be >>> happy to see this (scenario 2), but as CDI spec lead I fear that it could >>> lead us in a trap (going to scenario 1 or consuming precious time on >>> AtInject+1 instead of CDI 2.0) >>> >>> Well, I'm not spec lead, I'm just a Java EE user... so I like scenario 2 >>> ;o) >>> >>> But on the other hand, I think there is so much work to be done around >>> CDI 2.0, parts, and taking those parts to other specifications that >>> battling with JSR 330 might be time consuming. I would go for scenario >>> 1.... and cross fingers >>> >>> >>> On Wed, Jul 2, 2014 at 11:18 PM, Werner Keil >>> wrote: >>> >>>> Dear Antoine/all, >>>> >>>> Thanks for the detailed overview and trying to reach out to the former >>>> Spec Leads and EG of JSR 330. I also copied Anatole, Spec Lead of JSR 354, >>>> since Bob Lee is officially in his EG, but has practically never provided >>>> input there either (like we tend to see sometimes from others considered >>>> "Rock Stars" of the Java Community but since then seemingly resting on >>>> their laurels or just too busy counting their stock options?<329.gif>) >>>> >>>> Given CDI already was the public perception of "javax.inject" for most >>>> parts, I don't necessarily see that it had to be an MR to the original JSR, >>>> though as those involved in the EC (Martijn, Badr/MoroccoJUG,..) could >>>> probably check with the PMO how to handle a case where the Maintenance Lead >>>> of a JSR was not in the position to continue. I last met J?rgen H?ller >>>> about a year ago in Copenhagen, so for Pivotal's part as Co Spec Lead, I >>>> guess he or the likes of Josh Long could be best to speak to. Happy to get >>>> you in touch with them if you want. >>>> >>>> Red Hat was also EG member of JSR 330, so Pete, Gavin or whoever else >>>> was there (I remember him from conversations where Mike Keith and I took >>>> part in synergy discussions between 330 and CDI 1.0) at the time could also >>>> help you with this. >>>> >>>> In theory this could also be part of a new JSR (CDI 2) as long as none >>>> of the enhancements you have in mind break the existing API of JSR 330. The >>>> scope of CDI 2 to work in an SE/standalone or more lightweight environment >>>> than Java EE environment raises a good question of package names like " >>>> javax.enterprise.inject.*" So maybe there is room for synergies in a >>>> package namespace other than "javax.enterprise" at least for new things you >>>> have in mind. >>>> >>>> Kind Regards, >>>> >>>> Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead | >>>> Eclipse UOMo Lead, Babel Language Champion | Apache Committer >>>> Twitter @wernerkeil | @UnitAPI | @JSR354 | #EclipseUOMo | #Java_Social >>>> | #DevOps >>>> Skype werner.keil | Google+ gplus.to/wernerkeil >>>> >>>> * Developer Week: 14/15 Jul 2014, N?rnberg, Germany. Werner Keil, JCP >>>> EC Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class >>>> Continuous Delivery", "JSR 363 and IoT" (GER) >>>> >>>> * JavaZone 2014: 9-11 Sep 2014, Oslo, Norway. Werner Keil, JCP EC >>>> Member, JSR 363 Spec Lead will present "JSR 363 - The Answer to Life >>>> Science and the Internet of Everything" >>>> >>>> * JavaOne 2014: Sep 28-Oct 2 2014, San Francisco, USA, Werner Keil, JCP >>>> EC Member, JSR 354 EG Member will host "Java and Digital Currencies, Friend >>>> or FOE" >>>> >>>> * JMaghreb 3.0: 4-6 Nov 2014, Casablanca, Morocco. Werner Keil, JCP EC >>>> Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class >>>> DevOps", "JSR 363" >>>> >>>> * Mobile Developer Conference kompakt: 18 Nov 2014, Hamburg, Germany. >>>> Werner Keil, JCP EC Member, Apache DeviceMap Committer will present "Apache >>>> DeviceMap" (GER) >>>> >>>> >>>> On Wed, Jul 2, 2014 at 10:43 PM, Antoine Sabot-Durand < >>>> antoine at sabot-durand.net> wrote: >>>> >>>>> Hi all, >>>>> >>>>> Since the first mention of CDI 2.0 preparation work, we've received a >>>>> lot of comment about JSR 330 evolution. With the release of the proposal >>>>> draft yesterday, this topic came up again. So let me give my point of view >>>>> on this subject to have an open discussion here. >>>>> >>>>> When we started to discuss about modularity with Pete in last >>>>> november, my first idea was to go see what we could add in JSR 330 to make >>>>> it a true specification that could be the first module of CDI. My idea at >>>>> that time was to discuss with JSR 330 owner to see if we could bring basic >>>>> concept we have in CDI to AtInject spec. In my mind the main features would >>>>> have been: >>>>> - Enhance the javax.inject.Provider interface to bring it at the >>>>> same level than javax.enterprise.inject.Instance. That would have >>>>> included support for AnnotationLiteral and TypeLiteral as well >>>>> - Add a Container interface (a very light BeanManger) in JSR 330 to >>>>> be able to resolve beans instance from outside managed beans >>>>> - Add a mechanism to get this Container from non managed beans (like >>>>> we get access to BeanManager from JNDI or CDI class) >>>>> >>>>> At that time, I contacted Bob Lee without success (didn?t tried >>>>> Pivotal since I don?t have contact there). I checked with JCP what could be >>>>> done if we?d like to see an evolution of JSR 330 and the owner doesn?t >>>>> care, there seems to have solutions but I let it aside since we were in the >>>>> middle of CDI 1.2 MR at that time. >>>>> >>>>> Today I?m a bit torn about this point. Working on opening JSR 330 >>>>> could be like opening pandora box, since I see 2 scenarios : >>>>> >>>>> 1) former JSR 330 owners wake up and are ok to get for a new spec >>>>> version they lead: >>>>> Knowing the history of JSR 330 vs JSR 299 I?m not sure everything we?d >>>>> need would be heard and even if the people leading this would be >>>>> cooperative, a lot of discussion and negotiation would be needed to be sure >>>>> that this new AtInject wouldn?t contain features incompatible with CDI. So >>>>> it?d be very time consuming with no guarantee to get what we?d need at the >>>>> end. >>>>> >>>>> 2) former JSR 330 owner don?t mind others take ownership of their spec >>>>> to enhance it and we (Red Hat) are the one to take this ownership to secure >>>>> CDI: >>>>> The best solution to minimize risk. But leading a new specification is >>>>> a lot more work than just deciding that we have a specific basic inject ? >>>>> part ? in CDI 2.0. Leading a spec is very time consuming, so it could be >>>>> better on the paper but will impact CDI 2.0 new features. >>>>> >>>>> To sum up, as a Java EE user (like I have been for 10 years) I?d be >>>>> happy to see this (scenario 2), but as CDI spec lead I fear that it could >>>>> lead us in a trap (going to scenario 1 or consuming precious time on >>>>> AtInject+1 instead of CDI 2.0) >>>>> >>>>> Your input, solutions or comment would be appreciated on this point. >>>>> >>>>> Antoine >>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> 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/20140703/892b5e64/attachment-0001.html From werner.keil at gmail.com Thu Jul 3 06:46:04 2014 From: werner.keil at gmail.com (Werner Keil) Date: Thu, 3 Jul 2014 12:46:04 +0200 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: <380AE357-A2CF-4949-A6B7-EB21362DC89A@gmail.com> References: <380AE357-A2CF-4949-A6B7-EB21362DC89A@gmail.com> Message-ID: Anatole, Thanks for the input. Being a proposed Co Spec Lead of a future Config JSR (which timewise should correlate with CDI 2 more or less, too;-) it's worth to get you involved which is (aside from your own experienc with both Google and the not so responsive behavior by Bob Lee) why I invited you to this discussion. As mentioned, we need more people like yourself, Antoine, etc. but where former players or Spec Leads can still act as such it would certainly not be bad either. Google while its legal or IP team could hesitate to allow offcial contribution at this stage is other than Red Hat the only legitimate candidate to pick up its old JSR 330 or create a separate new "@Inject" JSR as per 1) Bob Lee is a permanent employee of Square and therefore not able to contribute IP or act as Spec Lead on behalf of Google or as Individual. The last case (those in this list at least casually joining EC or JCP.next calls will know;-) was JSR 170, JCache. There to give the Spec Lead Greg Luck an independent touch, Co Spec Lead Oracle allowed him to remain "Individual Member" despite being permanent employee of at least 2 companies since then, but that was a very old "Legacy JSR" just look at the number. If either Pivotal or Square joined the JCP they could revive the old JSR, otherwise only a similar dodgy deal like with 107 was imaginable, but it would leave a bad taste and considering how many other JSRs, similar Open Source projects (e.g. Eclipse, Maven,...) and commercial products use such technologies, same with CDI, it seems like Oracle Legal, PMO and other involved players including Red Hat would rather prefer a clean slate here than risk something worse than we see between Oracle and Android at the moment. Cheers, Werner On Thu, Jul 3, 2014 at 11:58 AM, Anatole Tresch wrote: > Hi All > > Same from my side. My experience eg with Google guys has been very > positive and constructive. I would expect there is a real chance to turn > the former conflict into a widely accepted standard, which would be very > valuable for any future evolution in the Java eco-system. > > Best > Anatole > > - > Anatole Tresch > Gl?rnischweg 10 > 8620 Wetzikon > Tel +41 (43) 317 05 30 > - > Send from Mobile > > Am 03.07.2014 um 11:02 schrieb Martijn Verburg : > > FYI - I've sent a note to the various folks from Google, Pivotal et al, > I'll let Antoine explain the CDI 2.0 proposal to them and I'm sure they'll > either join this mailing list / discussion or we'll quickly find out > there's no appetite and we can move on. > > Cheers, > Martijn > > > On 3 July 2014 09:51, Martijn Verburg wrote: > >> Hi All, >> >> To be blunt, this is a social/community issue - not a technical one. We >> simply need to get hold of the folks at Pivotal, Google (and other 330 EG >> members) and get them around the virtual table. If they subsequently >> aren't interested then fine, you should forge your own path. >> >> There's an absolute mega ton of 330 based DI code out there and 330 >> compliant containers, if CDI 2.0 wants to be the defacto std going forwards >> it simply can't afford ignore that. >> >> @Antoine - let's put our heads together and see who we need to get hold >> of in the 330 group, I think CDI 2.0 has strong merits and should be >> explored. >> >> @Werner - your comments about Bob's commitment (considering what he's >> done for the tech community at large, let alone Java) are highly >> inappropriate, please refrain from personal attacks on this or any other >> public forum. >> >> >> Cheers, >> Martijn >> >> >> On 3 July 2014 09:02, Antonio Goncalves >> wrote: >> >>> > To sum up, as a Java EE user (like I have been for 10 years) I?d be >>> happy to see this (scenario 2), but as CDI spec lead I fear that it could >>> lead us in a trap (going to scenario 1 or consuming precious time on >>> AtInject+1 instead of CDI 2.0) >>> >>> Well, I'm not spec lead, I'm just a Java EE user... so I like scenario 2 >>> ;o) >>> >>> But on the other hand, I think there is so much work to be done around >>> CDI 2.0, parts, and taking those parts to other specifications that >>> battling with JSR 330 might be time consuming. I would go for scenario >>> 1.... and cross fingers >>> >>> >>> On Wed, Jul 2, 2014 at 11:18 PM, Werner Keil >>> wrote: >>> >>>> Dear Antoine/all, >>>> >>>> Thanks for the detailed overview and trying to reach out to the former >>>> Spec Leads and EG of JSR 330. I also copied Anatole, Spec Lead of JSR 354, >>>> since Bob Lee is officially in his EG, but has practically never provided >>>> input there either (like we tend to see sometimes from others considered >>>> "Rock Stars" of the Java Community but since then seemingly resting on >>>> their laurels or just too busy counting their stock options?<329.gif>) >>>> >>>> Given CDI already was the public perception of "javax.inject" for most >>>> parts, I don't necessarily see that it had to be an MR to the original JSR, >>>> though as those involved in the EC (Martijn, Badr/MoroccoJUG,..) could >>>> probably check with the PMO how to handle a case where the Maintenance Lead >>>> of a JSR was not in the position to continue. I last met J?rgen H?ller >>>> about a year ago in Copenhagen, so for Pivotal's part as Co Spec Lead, I >>>> guess he or the likes of Josh Long could be best to speak to. Happy to get >>>> you in touch with them if you want. >>>> >>>> Red Hat was also EG member of JSR 330, so Pete, Gavin or whoever else >>>> was there (I remember him from conversations where Mike Keith and I took >>>> part in synergy discussions between 330 and CDI 1.0) at the time could also >>>> help you with this. >>>> >>>> In theory this could also be part of a new JSR (CDI 2) as long as none >>>> of the enhancements you have in mind break the existing API of JSR 330. The >>>> scope of CDI 2 to work in an SE/standalone or more lightweight environment >>>> than Java EE environment raises a good question of package names like " >>>> javax.enterprise.inject.*" So maybe there is room for synergies in a >>>> package namespace other than "javax.enterprise" at least for new things you >>>> have in mind. >>>> >>>> Kind Regards, >>>> >>>> Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead | >>>> Eclipse UOMo Lead, Babel Language Champion | Apache Committer >>>> >>>> Twitter @wernerkeil | @UnitAPI | @JSR354 | #EclipseUOMo | #Java_Social >>>> | #DevOps >>>> Skype werner.keil | Google+ gplus.to/wernerkeil >>>> >>>> * Developer Week: 14/15 Jul 2014, N?rnberg, Germany. Werner Keil, JCP >>>> EC Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class >>>> Continuous Delivery", "JSR 363 and IoT" (GER) >>>> >>>> * JavaZone 2014: 9-11 Sep 2014, Oslo, Norway. Werner Keil, JCP EC >>>> Member, JSR 363 Spec Lead will present "JSR 363 - The Answer to Life >>>> Science and the Internet of Everything" >>>> >>>> * JavaOne 2014: Sep 28-Oct 2 2014, San Francisco, USA, Werner Keil, JCP >>>> EC Member, JSR 354 EG Member will host "Java and Digital Currencies, Friend >>>> or FOE" >>>> >>>> * JMaghreb 3.0: 4-6 Nov 2014, Casablanca, Morocco. Werner Keil, JCP EC >>>> Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class >>>> DevOps", "JSR 363" >>>> >>>> * Mobile Developer Conference kompakt: 18 Nov 2014, Hamburg, Germany. >>>> Werner Keil, JCP EC Member, Apache DeviceMap Committer will present "Apache >>>> DeviceMap" (GER) >>>> >>>> >>>> On Wed, Jul 2, 2014 at 10:43 PM, Antoine Sabot-Durand < >>>> antoine at sabot-durand.net> wrote: >>>> >>>>> Hi all, >>>>> >>>>> Since the first mention of CDI 2.0 preparation work, we've received a >>>>> lot of comment about JSR 330 evolution. With the release of the proposal >>>>> draft yesterday, this topic came up again. So let me give my point of view >>>>> on this subject to have an open discussion here. >>>>> >>>>> When we started to discuss about modularity with Pete in last >>>>> november, my first idea was to go see what we could add in JSR 330 to make >>>>> it a true specification that could be the first module of CDI. My idea at >>>>> that time was to discuss with JSR 330 owner to see if we could bring basic >>>>> concept we have in CDI to AtInject spec. In my mind the main features would >>>>> have been: >>>>> - Enhance the javax.inject.Provider interface to bring it at the >>>>> same level than javax.enterprise.inject.Instance. That would have >>>>> included support for AnnotationLiteral and TypeLiteral as well >>>>> - Add a Container interface (a very light BeanManger) in JSR 330 to >>>>> be able to resolve beans instance from outside managed beans >>>>> - Add a mechanism to get this Container from non managed beans (like >>>>> we get access to BeanManager from JNDI or CDI class) >>>>> >>>>> At that time, I contacted Bob Lee without success (didn?t tried >>>>> Pivotal since I don?t have contact there). I checked with JCP what could be >>>>> done if we?d like to see an evolution of JSR 330 and the owner doesn?t >>>>> care, there seems to have solutions but I let it aside since we were in the >>>>> middle of CDI 1.2 MR at that time. >>>>> >>>>> Today I?m a bit torn about this point. Working on opening JSR 330 >>>>> could be like opening pandora box, since I see 2 scenarios : >>>>> >>>>> 1) former JSR 330 owners wake up and are ok to get for a new spec >>>>> version they lead: >>>>> Knowing the history of JSR 330 vs JSR 299 I?m not sure everything we?d >>>>> need would be heard and even if the people leading this would be >>>>> cooperative, a lot of discussion and negotiation would be needed to be sure >>>>> that this new AtInject wouldn?t contain features incompatible with CDI. So >>>>> it?d be very time consuming with no guarantee to get what we?d need at the >>>>> end. >>>>> >>>>> 2) former JSR 330 owner don?t mind others take ownership of their spec >>>>> to enhance it and we (Red Hat) are the one to take this ownership to secure >>>>> CDI: >>>>> The best solution to minimize risk. But leading a new specification is >>>>> a lot more work than just deciding that we have a specific basic inject ? >>>>> part ? in CDI 2.0. Leading a spec is very time consuming, so it could be >>>>> better on the paper but will impact CDI 2.0 new features. >>>>> >>>>> To sum up, as a Java EE user (like I have been for 10 years) I?d be >>>>> happy to see this (scenario 2), but as CDI spec lead I fear that it could >>>>> lead us in a trap (going to scenario 1 or consuming precious time on >>>>> AtInject+1 instead of CDI 2.0) >>>>> >>>>> Your input, solutions or comment would be appreciated on this point. >>>>> >>>>> Antoine >>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> 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/20140703/36021bb7/attachment-0001.html From werner.keil at gmail.com Thu Jul 3 08:30:53 2014 From: werner.keil at gmail.com (Werner Keil) Date: Thu, 3 Jul 2014 14:30:53 +0200 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: References: <25AE3FE1-2FFB-4DE9-82FE-2814E7BE299D@sabot-durand.net> Message-ID: Apology accepted;-) Actually now that Java ME 8 introduced very fine grained modularity and the concept of Liblets, I would not even say Java SE must be the the bottom level of where the JSR 330.next would make sense. This is a strong argument to try keep the two existing JSRs as separate entities and not merge them into a single one. Knowing how sensible Antoine and his collaborators at Agorava treated modularity and being open to different platforms or environments, I trust we'd also find a good path in this case. Werner On Thu, Jul 3, 2014 at 12:31 PM, Martijn Verburg wrote: > Hi Antoine, > > My apologies - I'm like a Bull in a China shop when it comes to trying to > get people together - I always figure that if its a "No" then we should get > to the "No" quickly :-). > > I think CDI 2.0 is important to the community at large - it may pivot > slightly from the original intent, but context aware DI for Java SE would > be a powerful tool in the toolbox (e.g. Oh look I'm writing a Java SE app > that uses websockets......, now I just need to inject a....). > > > > Cheers, > Martijn > > > On 3 July 2014 11:15, Antoine Sabot-Durand > wrote: > >> Martijn, >> >> I started this thread to discuss wether we should do what you?ve just >> done or not . I?d have liked to have Pete input before stepping like this. >> I guess the decision is taken now ;). >> Anyway, thanks for your enthusiasm. It gives good vibes for the coming >> JSR ;). >> >> >> Antoine >> >> >> Le 3 juil. 2014 ? 11:02, Martijn Verburg a >> ?crit : >> >> FYI - I've sent a note to the various folks from Google, Pivotal et al, >> I'll let Antoine explain the CDI 2.0 proposal to them and I'm sure they'll >> either join this mailing list / discussion or we'll quickly find out >> there's no appetite and we can move on. >> >> Cheers, >> Martijn >> >> >> On 3 July 2014 09:51, Martijn Verburg wrote: >> >>> Hi All, >>> >>> To be blunt, this is a social/community issue - not a technical one. We >>> simply need to get hold of the folks at Pivotal, Google (and other 330 EG >>> members) and get them around the virtual table. If they subsequently >>> aren't interested then fine, you should forge your own path. >>> >>> There's an absolute mega ton of 330 based DI code out there and 330 >>> compliant containers, if CDI 2.0 wants to be the defacto std going forwards >>> it simply can't afford ignore that. >>> >>> @Antoine - let's put our heads together and see who we need to get hold >>> of in the 330 group, I think CDI 2.0 has strong merits and should be >>> explored. >>> >>> @Werner - your comments about Bob's commitment (considering what he's >>> done for the tech community at large, let alone Java) are highly >>> inappropriate, please refrain from personal attacks on this or any other >>> public forum. >>> >>> >>> Cheers, >>> Martijn >>> >>> >>> On 3 July 2014 09:02, Antonio Goncalves >>> wrote: >>> >>>> > To sum up, as a Java EE user (like I have been for 10 years) I?d be >>>> happy to see this (scenario 2), but as CDI spec lead I fear that it could >>>> lead us in a trap (going to scenario 1 or consuming precious time on >>>> AtInject+1 instead of CDI 2.0) >>>> >>>> Well, I'm not spec lead, I'm just a Java EE user... so I like scenario >>>> 2 ;o) >>>> >>>> But on the other hand, I think there is so much work to be done around >>>> CDI 2.0, parts, and taking those parts to other specifications that >>>> battling with JSR 330 might be time consuming. I would go for scenario >>>> 1.... and cross fingers >>>> >>>> >>>> On Wed, Jul 2, 2014 at 11:18 PM, Werner Keil >>>> wrote: >>>> >>>>> Dear Antoine/all, >>>>> >>>>> Thanks for the detailed overview and trying to reach out to the former >>>>> Spec Leads and EG of JSR 330. I also copied Anatole, Spec Lead of JSR 354, >>>>> since Bob Lee is officially in his EG, but has practically never provided >>>>> input there either (like we tend to see sometimes from others considered >>>>> "Rock Stars" of the Java Community but since then seemingly resting on >>>>> their laurels or just too busy counting their stock options?<329.gif> >>>>> ) >>>>> >>>>> Given CDI already was the public perception of "javax.inject" for most >>>>> parts, I don't necessarily see that it had to be an MR to the original JSR, >>>>> though as those involved in the EC (Martijn, Badr/MoroccoJUG,..) could >>>>> probably check with the PMO how to handle a case where the Maintenance Lead >>>>> of a JSR was not in the position to continue. I last met J?rgen H?ller >>>>> about a year ago in Copenhagen, so for Pivotal's part as Co Spec Lead, I >>>>> guess he or the likes of Josh Long could be best to speak to. Happy to get >>>>> you in touch with them if you want. >>>>> >>>>> Red Hat was also EG member of JSR 330, so Pete, Gavin or whoever else >>>>> was there (I remember him from conversations where Mike Keith and I took >>>>> part in synergy discussions between 330 and CDI 1.0) at the time could also >>>>> help you with this. >>>>> >>>>> In theory this could also be part of a new JSR (CDI 2) as long as none >>>>> of the enhancements you have in mind break the existing API of JSR 330. The >>>>> scope of CDI 2 to work in an SE/standalone or more lightweight environment >>>>> than Java EE environment raises a good question of package names like " >>>>> javax.enterprise.inject.*" So maybe there is room for synergies in a >>>>> package namespace other than "javax.enterprise" at least for new things you >>>>> have in mind. >>>>> >>>>> Kind Regards, >>>>> >>>>> Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead | >>>>> Eclipse UOMo Lead, Babel Language Champion | Apache Committer >>>>> Twitter @wernerkeil | @UnitAPI | @JSR354 | #EclipseUOMo | #Java_Social >>>>> | #DevOps >>>>> Skype werner.keil | Google+ gplus.to/wernerkeil >>>>> >>>>> * Developer Week: 14/15 Jul 2014, N?rnberg, Germany. Werner Keil, JCP >>>>> EC Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' >>>>> class Continuous Delivery", "JSR 363 and IoT" (GER) >>>>> >>>>> * JavaZone 2014: 9-11 Sep 2014, Oslo, Norway. Werner Keil, JCP EC >>>>> Member, JSR 363 Spec Lead will present "JSR 363 - The Answer to Life >>>>> Science and the Internet of Everything" >>>>> >>>>> * JavaOne 2014: Sep 28-Oct 2 2014, San Francisco, USA, Werner Keil, >>>>> JCP EC Member, JSR 354 EG Member will host "Java and Digital Currencies, >>>>> Friend or FOE" >>>>> >>>>> * JMaghreb 3.0: 4-6 Nov 2014, Casablanca, Morocco. Werner Keil, JCP EC >>>>> Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class >>>>> DevOps", "JSR 363" >>>>> >>>>> * Mobile Developer Conference kompakt: 18 Nov 2014, Hamburg, Germany. >>>>> Werner Keil, JCP EC Member, Apache DeviceMap Committer will present "Apache >>>>> DeviceMap" (GER) >>>>> >>>>> >>>>> On Wed, Jul 2, 2014 at 10:43 PM, Antoine Sabot-Durand < >>>>> antoine at sabot-durand.net> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> Since the first mention of CDI 2.0 preparation work, we've received a >>>>>> lot of comment about JSR 330 evolution. With the release of the proposal >>>>>> draft yesterday, this topic came up again. So let me give my point of view >>>>>> on this subject to have an open discussion here. >>>>>> >>>>>> When we started to discuss about modularity with Pete in last >>>>>> november, my first idea was to go see what we could add in JSR 330 to make >>>>>> it a true specification that could be the first module of CDI. My idea at >>>>>> that time was to discuss with JSR 330 owner to see if we could bring basic >>>>>> concept we have in CDI to AtInject spec. In my mind the main features would >>>>>> have been: >>>>>> - Enhance the javax.inject.Provider interface to bring it at the >>>>>> same level than javax.enterprise.inject.Instance. That would have >>>>>> included support for AnnotationLiteral and TypeLiteral as well >>>>>> - Add a Container interface (a very light BeanManger) in JSR 330 to >>>>>> be able to resolve beans instance from outside managed beans >>>>>> - Add a mechanism to get this Container from non managed beans (like >>>>>> we get access to BeanManager from JNDI or CDI class) >>>>>> >>>>>> At that time, I contacted Bob Lee without success (didn?t tried >>>>>> Pivotal since I don?t have contact there). I checked with JCP what could be >>>>>> done if we?d like to see an evolution of JSR 330 and the owner doesn?t >>>>>> care, there seems to have solutions but I let it aside since we were in the >>>>>> middle of CDI 1.2 MR at that time. >>>>>> >>>>>> Today I?m a bit torn about this point. Working on opening JSR 330 >>>>>> could be like opening pandora box, since I see 2 scenarios : >>>>>> >>>>>> 1) former JSR 330 owners wake up and are ok to get for a new spec >>>>>> version they lead: >>>>>> Knowing the history of JSR 330 vs JSR 299 I?m not sure everything >>>>>> we?d need would be heard and even if the people leading this would be >>>>>> cooperative, a lot of discussion and negotiation would be needed to be sure >>>>>> that this new AtInject wouldn?t contain features incompatible with CDI. So >>>>>> it?d be very time consuming with no guarantee to get what we?d need at the >>>>>> end. >>>>>> >>>>>> 2) former JSR 330 owner don?t mind others take ownership of their >>>>>> spec to enhance it and we (Red Hat) are the one to take this ownership to >>>>>> secure CDI: >>>>>> The best solution to minimize risk. But leading a new specification >>>>>> is a lot more work than just deciding that we have a specific basic inject >>>>>> ? part ? in CDI 2.0. Leading a spec is very time consuming, so it could be >>>>>> better on the paper but will impact CDI 2.0 new features. >>>>>> >>>>>> To sum up, as a Java EE user (like I have been for 10 years) I?d be >>>>>> happy to see this (scenario 2), but as CDI spec lead I fear that it could >>>>>> lead us in a trap (going to scenario 1 or consuming precious time on >>>>>> AtInject+1 instead of CDI 2.0) >>>>>> >>>>>> Your input, solutions or comment would be appreciated on this point. >>>>>> >>>>>> Antoine >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> 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/20140703/0fe67422/attachment-0001.html From pmuir at redhat.com Thu Jul 3 09:03:50 2014 From: pmuir at redhat.com (Pete Muir) Date: Thu, 3 Jul 2014 14:03:50 +0100 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: <25AE3FE1-2FFB-4DE9-82FE-2814E7BE299D@sabot-durand.net> References: <25AE3FE1-2FFB-4DE9-82FE-2814E7BE299D@sabot-durand.net> Message-ID: <13F4DF61-6E2E-408B-83C3-5B6F8EEB07CC@redhat.com> I?m fully supportive of this approach. I would love to work to get more in to JSR-330, I just fear the time sink. On 3 Jul 2014, at 11:15, Antoine Sabot-Durand wrote: > Martijn, > > I started this thread to discuss wether we should do what you?ve just done or not . I?d have liked to have Pete input before stepping like this. I guess the decision is taken now ;). > Anyway, thanks for your enthusiasm. It gives good vibes for the coming JSR ;). > > > Antoine > > > Le 3 juil. 2014 ? 11:02, Martijn Verburg a ?crit : > >> FYI - I've sent a note to the various folks from Google, Pivotal et al, I'll let Antoine explain the CDI 2.0 proposal to them and I'm sure they'll either join this mailing list / discussion or we'll quickly find out there's no appetite and we can move on. >> >> Cheers, >> Martijn >> >> >> On 3 July 2014 09:51, Martijn Verburg wrote: >> Hi All, >> >> To be blunt, this is a social/community issue - not a technical one. We simply need to get hold of the folks at Pivotal, Google (and other 330 EG members) and get them around the virtual table. If they subsequently aren't interested then fine, you should forge your own path. >> >> There's an absolute mega ton of 330 based DI code out there and 330 compliant containers, if CDI 2.0 wants to be the defacto std going forwards it simply can't afford ignore that. >> >> @Antoine - let's put our heads together and see who we need to get hold of in the 330 group, I think CDI 2.0 has strong merits and should be explored. >> >> @Werner - your comments about Bob's commitment (considering what he's done for the tech community at large, let alone Java) are highly inappropriate, please refrain from personal attacks on this or any other public forum. >> >> >> Cheers, >> Martijn >> >> >> On 3 July 2014 09:02, Antonio Goncalves wrote: >> > To sum up, as a Java EE user (like I have been for 10 years) I?d be happy to see this (scenario 2), but as CDI spec lead I fear that it could lead us in a trap (going to scenario 1 or consuming precious time on AtInject+1 instead of CDI 2.0) >> >> Well, I'm not spec lead, I'm just a Java EE user... so I like scenario 2 ;o) >> >> But on the other hand, I think there is so much work to be done around CDI 2.0, parts, and taking those parts to other specifications that battling with JSR 330 might be time consuming. I would go for scenario 1.... and cross fingers >> >> >> On Wed, Jul 2, 2014 at 11:18 PM, Werner Keil wrote: >> Dear Antoine/all, >> >> Thanks for the detailed overview and trying to reach out to the former Spec Leads and EG of JSR 330. I also copied Anatole, Spec Lead of JSR 354, since Bob Lee is officially in his EG, but has practically never provided input there either (like we tend to see sometimes from others considered "Rock Stars" of the Java Community but since then seemingly resting on their laurels or just too busy counting their stock options?<329.gif>) >> >> Given CDI already was the public perception of "javax.inject" for most parts, I don't necessarily see that it had to be an MR to the original JSR, though as those involved in the EC (Martijn, Badr/MoroccoJUG,..) could probably check with the PMO how to handle a case where the Maintenance Lead of a JSR was not in the position to continue. I last met J?rgen H?ller about a year ago in Copenhagen, so for Pivotal's part as Co Spec Lead, I guess he or the likes of Josh Long could be best to speak to. Happy to get you in touch with them if you want. >> >> Red Hat was also EG member of JSR 330, so Pete, Gavin or whoever else was there (I remember him from conversations where Mike Keith and I took part in synergy discussions between 330 and CDI 1.0) at the time could also help you with this. >> >> In theory this could also be part of a new JSR (CDI 2) as long as none of the enhancements you have in mind break the existing API of JSR 330. The scope of CDI 2 to work in an SE/standalone or more lightweight environment than Java EE environment raises a good question of package names like " javax.enterprise.inject.*" So maybe there is room for synergies in a package namespace other than "javax.enterprise" at least for new things you have in mind. >> >> Kind Regards, >> >> Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead | Eclipse UOMo Lead, Babel Language Champion | Apache Committer >> Twitter @wernerkeil | @UnitAPI | @JSR354 | #EclipseUOMo | #Java_Social | #DevOps >> Skype werner.keil | Google+ gplus.to/wernerkeil >> >> * Developer Week: 14/15 Jul 2014, N?rnberg, Germany. Werner Keil, JCP EC Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class Continuous Delivery", "JSR 363 and IoT" (GER) >> >> * JavaZone 2014: 9-11 Sep 2014, Oslo, Norway. Werner Keil, JCP EC Member, JSR 363 Spec Lead will present "JSR 363 - The Answer to Life Science and the Internet of Everything" >> >> * JavaOne 2014: Sep 28-Oct 2 2014, San Francisco, USA, Werner Keil, JCP EC Member, JSR 354 EG Member will host "Java and Digital Currencies, Friend or FOE" >> >> * JMaghreb 3.0: 4-6 Nov 2014, Casablanca, Morocco. Werner Keil, JCP EC Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class DevOps", "JSR 363" >> >> * Mobile Developer Conference kompakt: 18 Nov 2014, Hamburg, Germany. Werner Keil, JCP EC Member, Apache DeviceMap Committer will present "Apache DeviceMap" (GER) >> >> >> On Wed, Jul 2, 2014 at 10:43 PM, Antoine Sabot-Durand wrote: >> Hi all, >> >> Since the first mention of CDI 2.0 preparation work, we've received a lot of comment about JSR 330 evolution. With the release of the proposal draft yesterday, this topic came up again. So let me give my point of view on this subject to have an open discussion here. >> >> When we started to discuss about modularity with Pete in last november, my first idea was to go see what we could add in JSR 330 to make it a true specification that could be the first module of CDI. My idea at that time was to discuss with JSR 330 owner to see if we could bring basic concept we have in CDI to AtInject spec. In my mind the main features would have been: >> - Enhance the javax.inject.Provider interface to bring it at the same level than javax.enterprise.inject.Instance. That would have included support for AnnotationLiteral and TypeLiteral as well >> - Add a Container interface (a very light BeanManger) in JSR 330 to be able to resolve beans instance from outside managed beans >> - Add a mechanism to get this Container from non managed beans (like we get access to BeanManager from JNDI or CDI class) >> >> At that time, I contacted Bob Lee without success (didn?t tried Pivotal since I don?t have contact there). I checked with JCP what could be done if we?d like to see an evolution of JSR 330 and the owner doesn?t care, there seems to have solutions but I let it aside since we were in the middle of CDI 1.2 MR at that time. >> >> Today I?m a bit torn about this point. Working on opening JSR 330 could be like opening pandora box, since I see 2 scenarios : >> >> 1) former JSR 330 owners wake up and are ok to get for a new spec version they lead: >> Knowing the history of JSR 330 vs JSR 299 I?m not sure everything we?d need would be heard and even if the people leading this would be cooperative, a lot of discussion and negotiation would be needed to be sure that this new AtInject wouldn?t contain features incompatible with CDI. So it?d be very time consuming with no guarantee to get what we?d need at the end. >> >> 2) former JSR 330 owner don?t mind others take ownership of their spec to enhance it and we (Red Hat) are the one to take this ownership to secure CDI: >> The best solution to minimize risk. But leading a new specification is a lot more work than just deciding that we have a specific basic inject ? part ? in CDI 2.0. Leading a spec is very time consuming, so it could be better on the paper but will impact CDI 2.0 new features. >> >> To sum up, as a Java EE user (like I have been for 10 years) I?d be happy to see this (scenario 2), but as CDI spec lead I fear that it could lead us in a trap (going to scenario 1 or consuming precious time on AtInject+1 instead of CDI 2.0) >> >> Your input, solutions or comment would be appreciated on this point. >> >> Antoine >> >> >> >> >> >> >> -- >> Antonio Goncalves >> Software architect, Java Champion and Pluralsight author >> >> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France >> >> > From pmuir at redhat.com Thu Jul 3 09:05:32 2014 From: pmuir at redhat.com (Pete Muir) Date: Thu, 3 Jul 2014 14:05:32 +0100 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: References: Message-ID: <1ED74216-CCAC-4093-BF48-EED397C59552@redhat.com> BTW it?s actually Bob Lee who owns JSR-330, he took it with him personally when left Google. On 3 Jul 2014, at 10:02, Martijn Verburg wrote: > FYI - I've sent a note to the various folks from Google, Pivotal et al, I'll let Antoine explain the CDI 2.0 proposal to them and I'm sure they'll either join this mailing list / discussion or we'll quickly find out there's no appetite and we can move on. > > Cheers, > Martijn > > > On 3 July 2014 09:51, Martijn Verburg wrote: > Hi All, > > To be blunt, this is a social/community issue - not a technical one. We simply need to get hold of the folks at Pivotal, Google (and other 330 EG members) and get them around the virtual table. If they subsequently aren't interested then fine, you should forge your own path. > > There's an absolute mega ton of 330 based DI code out there and 330 compliant containers, if CDI 2.0 wants to be the defacto std going forwards it simply can't afford ignore that. > > @Antoine - let's put our heads together and see who we need to get hold of in the 330 group, I think CDI 2.0 has strong merits and should be explored. > > @Werner - your comments about Bob's commitment (considering what he's done for the tech community at large, let alone Java) are highly inappropriate, please refrain from personal attacks on this or any other public forum. > > > Cheers, > Martijn > > > On 3 July 2014 09:02, Antonio Goncalves wrote: > > To sum up, as a Java EE user (like I have been for 10 years) I?d be happy to see this (scenario 2), but as CDI spec lead I fear that it could lead us in a trap (going to scenario 1 or consuming precious time on AtInject+1 instead of CDI 2.0) > > Well, I'm not spec lead, I'm just a Java EE user... so I like scenario 2 ;o) > > But on the other hand, I think there is so much work to be done around CDI 2.0, parts, and taking those parts to other specifications that battling with JSR 330 might be time consuming. I would go for scenario 1.... and cross fingers > > > On Wed, Jul 2, 2014 at 11:18 PM, Werner Keil wrote: > Dear Antoine/all, > > Thanks for the detailed overview and trying to reach out to the former Spec Leads and EG of JSR 330. I also copied Anatole, Spec Lead of JSR 354, since Bob Lee is officially in his EG, but has practically never provided input there either (like we tend to see sometimes from others considered "Rock Stars" of the Java Community but since then seemingly resting on their laurels or just too busy counting their stock options?<329.gif>) > > Given CDI already was the public perception of "javax.inject" for most parts, I don't necessarily see that it had to be an MR to the original JSR, though as those involved in the EC (Martijn, Badr/MoroccoJUG,..) could probably check with the PMO how to handle a case where the Maintenance Lead of a JSR was not in the position to continue. I last met J?rgen H?ller about a year ago in Copenhagen, so for Pivotal's part as Co Spec Lead, I guess he or the likes of Josh Long could be best to speak to. Happy to get you in touch with them if you want. > > Red Hat was also EG member of JSR 330, so Pete, Gavin or whoever else was there (I remember him from conversations where Mike Keith and I took part in synergy discussions between 330 and CDI 1.0) at the time could also help you with this. > > In theory this could also be part of a new JSR (CDI 2) as long as none of the enhancements you have in mind break the existing API of JSR 330. The scope of CDI 2 to work in an SE/standalone or more lightweight environment than Java EE environment raises a good question of package names like " javax.enterprise.inject.*" So maybe there is room for synergies in a package namespace other than "javax.enterprise" at least for new things you have in mind. > > Kind Regards, > > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead | Eclipse UOMo Lead, Babel Language Champion | Apache Committer > Twitter @wernerkeil | @UnitAPI | @JSR354 | #EclipseUOMo | #Java_Social | #DevOps > Skype werner.keil | Google+ gplus.to/wernerkeil > > * Developer Week: 14/15 Jul 2014, N?rnberg, Germany. Werner Keil, JCP EC Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class Continuous Delivery", "JSR 363 and IoT" (GER) > > * JavaZone 2014: 9-11 Sep 2014, Oslo, Norway. Werner Keil, JCP EC Member, JSR 363 Spec Lead will present "JSR 363 - The Answer to Life Science and the Internet of Everything" > > * JavaOne 2014: Sep 28-Oct 2 2014, San Francisco, USA, Werner Keil, JCP EC Member, JSR 354 EG Member will host "Java and Digital Currencies, Friend or FOE" > > * JMaghreb 3.0: 4-6 Nov 2014, Casablanca, Morocco. Werner Keil, JCP EC Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class DevOps", "JSR 363" > > * Mobile Developer Conference kompakt: 18 Nov 2014, Hamburg, Germany. Werner Keil, JCP EC Member, Apache DeviceMap Committer will present "Apache DeviceMap" (GER) > > > On Wed, Jul 2, 2014 at 10:43 PM, Antoine Sabot-Durand wrote: > Hi all, > > Since the first mention of CDI 2.0 preparation work, we've received a lot of comment about JSR 330 evolution. With the release of the proposal draft yesterday, this topic came up again. So let me give my point of view on this subject to have an open discussion here. > > When we started to discuss about modularity with Pete in last november, my first idea was to go see what we could add in JSR 330 to make it a true specification that could be the first module of CDI. My idea at that time was to discuss with JSR 330 owner to see if we could bring basic concept we have in CDI to AtInject spec. In my mind the main features would have been: > - Enhance the javax.inject.Provider interface to bring it at the same level than javax.enterprise.inject.Instance. That would have included support for AnnotationLiteral and TypeLiteral as well > - Add a Container interface (a very light BeanManger) in JSR 330 to be able to resolve beans instance from outside managed beans > - Add a mechanism to get this Container from non managed beans (like we get access to BeanManager from JNDI or CDI class) > > At that time, I contacted Bob Lee without success (didn?t tried Pivotal since I don?t have contact there). I checked with JCP what could be done if we?d like to see an evolution of JSR 330 and the owner doesn?t care, there seems to have solutions but I let it aside since we were in the middle of CDI 1.2 MR at that time. > > Today I?m a bit torn about this point. Working on opening JSR 330 could be like opening pandora box, since I see 2 scenarios : > > 1) former JSR 330 owners wake up and are ok to get for a new spec version they lead: > Knowing the history of JSR 330 vs JSR 299 I?m not sure everything we?d need would be heard and even if the people leading this would be cooperative, a lot of discussion and negotiation would be needed to be sure that this new AtInject wouldn?t contain features incompatible with CDI. So it?d be very time consuming with no guarantee to get what we?d need at the end. > > 2) former JSR 330 owner don?t mind others take ownership of their spec to enhance it and we (Red Hat) are the one to take this ownership to secure CDI: > The best solution to minimize risk. But leading a new specification is a lot more work than just deciding that we have a specific basic inject ? part ? in CDI 2.0. Leading a spec is very time consuming, so it could be better on the paper but will impact CDI 2.0 new features. > > To sum up, as a Java EE user (like I have been for 10 years) I?d be happy to see this (scenario 2), but as CDI spec lead I fear that it could lead us in a trap (going to scenario 1 or consuming precious time on AtInject+1 instead of CDI 2.0) > > Your input, solutions or comment would be appreciated on this point. > > Antoine > > > > > > > -- > 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 From werner.keil at gmail.com Thu Jul 3 09:17:23 2014 From: werner.keil at gmail.com (Werner Keil) Date: Thu, 3 Jul 2014 15:17:23 +0200 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: <1ED74216-CCAC-4093-BF48-EED397C59552@redhat.com> References: <1ED74216-CCAC-4093-BF48-EED397C59552@redhat.com> Message-ID: I know, back then it was sort of legitimate, see Greg Luck and 107, but the whole idea of JCP.next and JSRs between 148 and 164 is to ensure, "Individual Members" contribute only on their own behalf, and in most cases (especially for the Spec Lead Role, it might be a bit less critical if you just submit a pull-request every once in a while or contribute via Gerrit, etc.) that is a conflict if he or others work for another company like Bob does at Square now. On Thu, Jul 3, 2014 at 3:05 PM, Pete Muir wrote: > BTW it?s actually Bob Lee who owns JSR-330, he took it with him personally > when left Google. > > On 3 Jul 2014, at 10:02, Martijn Verburg wrote: > > > FYI - I've sent a note to the various folks from Google, Pivotal et al, > I'll let Antoine explain the CDI 2.0 proposal to them and I'm sure they'll > either join this mailing list / discussion or we'll quickly find out > there's no appetite and we can move on. > > > > Cheers, > > Martijn > > > > > > On 3 July 2014 09:51, Martijn Verburg wrote: > > Hi All, > > > > To be blunt, this is a social/community issue - not a technical one. We > simply need to get hold of the folks at Pivotal, Google (and other 330 EG > members) and get them around the virtual table. If they subsequently > aren't interested then fine, you should forge your own path. > > > > There's an absolute mega ton of 330 based DI code out there and 330 > compliant containers, if CDI 2.0 wants to be the defacto std going forwards > it simply can't afford ignore that. > > > > @Antoine - let's put our heads together and see who we need to get hold > of in the 330 group, I think CDI 2.0 has strong merits and should be > explored. > > > > @Werner - your comments about Bob's commitment (considering what he's > done for the tech community at large, let alone Java) are highly > inappropriate, please refrain from personal attacks on this or any other > public forum. > > > > > > Cheers, > > Martijn > > > > > > On 3 July 2014 09:02, Antonio Goncalves > wrote: > > > To sum up, as a Java EE user (like I have been for 10 years) I?d be > happy to see this (scenario 2), but as CDI spec lead I fear that it could > lead us in a trap (going to scenario 1 or consuming precious time on > AtInject+1 instead of CDI 2.0) > > > > Well, I'm not spec lead, I'm just a Java EE user... so I like scenario 2 > ;o) > > > > But on the other hand, I think there is so much work to be done around > CDI 2.0, parts, and taking those parts to other specifications that > battling with JSR 330 might be time consuming. I would go for scenario > 1.... and cross fingers > > > > > > On Wed, Jul 2, 2014 at 11:18 PM, Werner Keil > wrote: > > Dear Antoine/all, > > > > Thanks for the detailed overview and trying to reach out to the former > Spec Leads and EG of JSR 330. I also copied Anatole, Spec Lead of JSR 354, > since Bob Lee is officially in his EG, but has practically never provided > input there either (like we tend to see sometimes from others considered > "Rock Stars" of the Java Community but since then seemingly resting on > their laurels or just too busy counting their stock options?<329.gif>) > > > > Given CDI already was the public perception of "javax.inject" for most > parts, I don't necessarily see that it had to be an MR to the original JSR, > though as those involved in the EC (Martijn, Badr/MoroccoJUG,..) could > probably check with the PMO how to handle a case where the Maintenance Lead > of a JSR was not in the position to continue. I last met J?rgen H?ller > about a year ago in Copenhagen, so for Pivotal's part as Co Spec Lead, I > guess he or the likes of Josh Long could be best to speak to. Happy to get > you in touch with them if you want. > > > > Red Hat was also EG member of JSR 330, so Pete, Gavin or whoever else > was there (I remember him from conversations where Mike Keith and I took > part in synergy discussions between 330 and CDI 1.0) at the time could also > help you with this. > > > > In theory this could also be part of a new JSR (CDI 2) as long as none > of the enhancements you have in mind break the existing API of JSR 330. The > scope of CDI 2 to work in an SE/standalone or more lightweight environment > than Java EE environment raises a good question of package names like " > javax.enterprise.inject.*" So maybe there is room for synergies in a > package namespace other than "javax.enterprise" at least for new things you > have in mind. > > > > Kind Regards, > > > > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead | > Eclipse UOMo Lead, Babel Language Champion | Apache Committer > > Twitter @wernerkeil | @UnitAPI | @JSR354 | #EclipseUOMo | #Java_Social | > #DevOps > > Skype werner.keil | Google+ gplus.to/wernerkeil > > > > * Developer Week: 14/15 Jul 2014, N?rnberg, Germany. Werner Keil, JCP EC > Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class > Continuous Delivery", "JSR 363 and IoT" (GER) > > > > * JavaZone 2014: 9-11 Sep 2014, Oslo, Norway. Werner Keil, JCP EC > Member, JSR 363 Spec Lead will present "JSR 363 - The Answer to Life > Science and the Internet of Everything" > > > > * JavaOne 2014: Sep 28-Oct 2 2014, San Francisco, USA, Werner Keil, JCP > EC Member, JSR 354 EG Member will host "Java and Digital Currencies, Friend > or FOE" > > > > * JMaghreb 3.0: 4-6 Nov 2014, Casablanca, Morocco. Werner Keil, JCP EC > Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class > DevOps", "JSR 363" > > > > * Mobile Developer Conference kompakt: 18 Nov 2014, Hamburg, Germany. > Werner Keil, JCP EC Member, Apache DeviceMap Committer will present "Apache > DeviceMap" (GER) > > > > > > On Wed, Jul 2, 2014 at 10:43 PM, Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > > Hi all, > > > > Since the first mention of CDI 2.0 preparation work, we've received a > lot of comment about JSR 330 evolution. With the release of the proposal > draft yesterday, this topic came up again. So let me give my point of view > on this subject to have an open discussion here. > > > > When we started to discuss about modularity with Pete in last november, > my first idea was to go see what we could add in JSR 330 to make it a true > specification that could be the first module of CDI. My idea at that time > was to discuss with JSR 330 owner to see if we could bring basic concept we > have in CDI to AtInject spec. In my mind the main features would have been: > > - Enhance the javax.inject.Provider interface to bring it at the > same level than javax.enterprise.inject.Instance. That would have > included support for AnnotationLiteral and TypeLiteral as well > > - Add a Container interface (a very light BeanManger) in JSR 330 to be > able to resolve beans instance from outside managed beans > > - Add a mechanism to get this Container from non managed beans (like we > get access to BeanManager from JNDI or CDI class) > > > > At that time, I contacted Bob Lee without success (didn?t tried Pivotal > since I don?t have contact there). I checked with JCP what could be done if > we?d like to see an evolution of JSR 330 and the owner doesn?t care, there > seems to have solutions but I let it aside since we were in the middle of > CDI 1.2 MR at that time. > > > > Today I?m a bit torn about this point. Working on opening JSR 330 could > be like opening pandora box, since I see 2 scenarios : > > > > 1) former JSR 330 owners wake up and are ok to get for a new spec > version they lead: > > Knowing the history of JSR 330 vs JSR 299 I?m not sure everything we?d > need would be heard and even if the people leading this would be > cooperative, a lot of discussion and negotiation would be needed to be sure > that this new AtInject wouldn?t contain features incompatible with CDI. So > it?d be very time consuming with no guarantee to get what we?d need at the > end. > > > > 2) former JSR 330 owner don?t mind others take ownership of their spec > to enhance it and we (Red Hat) are the one to take this ownership to secure > CDI: > > The best solution to minimize risk. But leading a new specification is a > lot more work than just deciding that we have a specific basic inject ? > part ? in CDI 2.0. Leading a spec is very time consuming, so it could be > better on the paper but will impact CDI 2.0 new features. > > > > To sum up, as a Java EE user (like I have been for 10 years) I?d be > happy to see this (scenario 2), but as CDI spec lead I fear that it could > lead us in a trap (going to scenario 1 or consuming precious time on > AtInject+1 instead of CDI 2.0) > > > > Your input, solutions or comment would be appreciated on this point. > > > > Antoine > > > > > > > > > > > > > > -- > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140703/d121620d/attachment-0001.html From pmuir at redhat.com Thu Jul 3 09:20:27 2014 From: pmuir at redhat.com (Pete Muir) Date: Thu, 3 Jul 2014 14:20:27 +0100 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: References: <1ED74216-CCAC-4093-BF48-EED397C59552@redhat.com> Message-ID: <2C31A12F-6D4B-4FF5-88FF-B7A585E96495@redhat.com> Bob did leave square a few months ago. On 3 Jul 2014, at 14:17, Werner Keil wrote: > I know, back then it was sort of legitimate, see Greg Luck and 107, but the whole idea of JCP.next and JSRs between 148 and 164 is to ensure, "Individual Members" contribute only on their own behalf, and in most cases (especially for the Spec Lead Role, it might be a bit less critical if you just submit a pull-request every once in a while or contribute via Gerrit, etc.) that is a conflict if he or others work for another company like Bob does at Square now. > > On Thu, Jul 3, 2014 at 3:05 PM, Pete Muir wrote: > BTW it?s actually Bob Lee who owns JSR-330, he took it with him personally when left Google. > > On 3 Jul 2014, at 10:02, Martijn Verburg wrote: > > > FYI - I've sent a note to the various folks from Google, Pivotal et al, I'll let Antoine explain the CDI 2.0 proposal to them and I'm sure they'll either join this mailing list / discussion or we'll quickly find out there's no appetite and we can move on. > > > > Cheers, > > Martijn > > > > > > On 3 July 2014 09:51, Martijn Verburg wrote: > > Hi All, > > > > To be blunt, this is a social/community issue - not a technical one. We simply need to get hold of the folks at Pivotal, Google (and other 330 EG members) and get them around the virtual table. If they subsequently aren't interested then fine, you should forge your own path. > > > > There's an absolute mega ton of 330 based DI code out there and 330 compliant containers, if CDI 2.0 wants to be the defacto std going forwards it simply can't afford ignore that. > > > > @Antoine - let's put our heads together and see who we need to get hold of in the 330 group, I think CDI 2.0 has strong merits and should be explored. > > > > @Werner - your comments about Bob's commitment (considering what he's done for the tech community at large, let alone Java) are highly inappropriate, please refrain from personal attacks on this or any other public forum. > > > > > > Cheers, > > Martijn > > > > > > On 3 July 2014 09:02, Antonio Goncalves wrote: > > > To sum up, as a Java EE user (like I have been for 10 years) I?d be happy to see this (scenario 2), but as CDI spec lead I fear that it could lead us in a trap (going to scenario 1 or consuming precious time on AtInject+1 instead of CDI 2.0) > > > > Well, I'm not spec lead, I'm just a Java EE user... so I like scenario 2 ;o) > > > > But on the other hand, I think there is so much work to be done around CDI 2.0, parts, and taking those parts to other specifications that battling with JSR 330 might be time consuming. I would go for scenario 1.... and cross fingers > > > > > > On Wed, Jul 2, 2014 at 11:18 PM, Werner Keil wrote: > > Dear Antoine/all, > > > > Thanks for the detailed overview and trying to reach out to the former Spec Leads and EG of JSR 330. I also copied Anatole, Spec Lead of JSR 354, since Bob Lee is officially in his EG, but has practically never provided input there either (like we tend to see sometimes from others considered "Rock Stars" of the Java Community but since then seemingly resting on their laurels or just too busy counting their stock options?<329.gif>) > > > > Given CDI already was the public perception of "javax.inject" for most parts, I don't necessarily see that it had to be an MR to the original JSR, though as those involved in the EC (Martijn, Badr/MoroccoJUG,..) could probably check with the PMO how to handle a case where the Maintenance Lead of a JSR was not in the position to continue. I last met J?rgen H?ller about a year ago in Copenhagen, so for Pivotal's part as Co Spec Lead, I guess he or the likes of Josh Long could be best to speak to. Happy to get you in touch with them if you want. > > > > Red Hat was also EG member of JSR 330, so Pete, Gavin or whoever else was there (I remember him from conversations where Mike Keith and I took part in synergy discussions between 330 and CDI 1.0) at the time could also help you with this. > > > > In theory this could also be part of a new JSR (CDI 2) as long as none of the enhancements you have in mind break the existing API of JSR 330. The scope of CDI 2 to work in an SE/standalone or more lightweight environment than Java EE environment raises a good question of package names like " javax.enterprise.inject.*" So maybe there is room for synergies in a package namespace other than "javax.enterprise" at least for new things you have in mind. > > > > Kind Regards, > > > > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead | Eclipse UOMo Lead, Babel Language Champion | Apache Committer > > Twitter @wernerkeil | @UnitAPI | @JSR354 | #EclipseUOMo | #Java_Social | #DevOps > > Skype werner.keil | Google+ gplus.to/wernerkeil > > > > * Developer Week: 14/15 Jul 2014, N?rnberg, Germany. Werner Keil, JCP EC Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class Continuous Delivery", "JSR 363 and IoT" (GER) > > > > * JavaZone 2014: 9-11 Sep 2014, Oslo, Norway. Werner Keil, JCP EC Member, JSR 363 Spec Lead will present "JSR 363 - The Answer to Life Science and the Internet of Everything" > > > > * JavaOne 2014: Sep 28-Oct 2 2014, San Francisco, USA, Werner Keil, JCP EC Member, JSR 354 EG Member will host "Java and Digital Currencies, Friend or FOE" > > > > * JMaghreb 3.0: 4-6 Nov 2014, Casablanca, Morocco. Werner Keil, JCP EC Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class DevOps", "JSR 363" > > > > * Mobile Developer Conference kompakt: 18 Nov 2014, Hamburg, Germany. Werner Keil, JCP EC Member, Apache DeviceMap Committer will present "Apache DeviceMap" (GER) > > > > > > On Wed, Jul 2, 2014 at 10:43 PM, Antoine Sabot-Durand wrote: > > Hi all, > > > > Since the first mention of CDI 2.0 preparation work, we've received a lot of comment about JSR 330 evolution. With the release of the proposal draft yesterday, this topic came up again. So let me give my point of view on this subject to have an open discussion here. > > > > When we started to discuss about modularity with Pete in last november, my first idea was to go see what we could add in JSR 330 to make it a true specification that could be the first module of CDI. My idea at that time was to discuss with JSR 330 owner to see if we could bring basic concept we have in CDI to AtInject spec. In my mind the main features would have been: > > - Enhance the javax.inject.Provider interface to bring it at the same level than javax.enterprise.inject.Instance. That would have included support for AnnotationLiteral and TypeLiteral as well > > - Add a Container interface (a very light BeanManger) in JSR 330 to be able to resolve beans instance from outside managed beans > > - Add a mechanism to get this Container from non managed beans (like we get access to BeanManager from JNDI or CDI class) > > > > At that time, I contacted Bob Lee without success (didn?t tried Pivotal since I don?t have contact there). I checked with JCP what could be done if we?d like to see an evolution of JSR 330 and the owner doesn?t care, there seems to have solutions but I let it aside since we were in the middle of CDI 1.2 MR at that time. > > > > Today I?m a bit torn about this point. Working on opening JSR 330 could be like opening pandora box, since I see 2 scenarios : > > > > 1) former JSR 330 owners wake up and are ok to get for a new spec version they lead: > > Knowing the history of JSR 330 vs JSR 299 I?m not sure everything we?d need would be heard and even if the people leading this would be cooperative, a lot of discussion and negotiation would be needed to be sure that this new AtInject wouldn?t contain features incompatible with CDI. So it?d be very time consuming with no guarantee to get what we?d need at the end. > > > > 2) former JSR 330 owner don?t mind others take ownership of their spec to enhance it and we (Red Hat) are the one to take this ownership to secure CDI: > > The best solution to minimize risk. But leading a new specification is a lot more work than just deciding that we have a specific basic inject ? part ? in CDI 2.0. Leading a spec is very time consuming, so it could be better on the paper but will impact CDI 2.0 new features. > > > > To sum up, as a Java EE user (like I have been for 10 years) I?d be happy to see this (scenario 2), but as CDI spec lead I fear that it could lead us in a trap (going to scenario 1 or consuming precious time on AtInject+1 instead of CDI 2.0) > > > > Your input, solutions or comment would be appreciated on this point. > > > > Antoine > > > > > > > > > > > > > > -- > > 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 > > From werner.keil at gmail.com Thu Jul 3 09:37:33 2014 From: werner.keil at gmail.com (Werner Keil) Date: Thu, 3 Jul 2014 15:37:33 +0200 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: <2C31A12F-6D4B-4FF5-88FF-B7A585E96495@redhat.com> References: <1ED74216-CCAC-4093-BF48-EED397C59552@redhat.com> <2C31A12F-6D4B-4FF5-88FF-B7A585E96495@redhat.com> Message-ID: Interesting. Well unless he's self-employed freelancer now, that makes it even more unpredictable as to what his status as JSR 330 MR (or possible Spec Lead of a successor) is or would be... (unless he plans to return to Google or join let's say Red Hat;-) On Thu, Jul 3, 2014 at 3:20 PM, Pete Muir wrote: > Bob did leave square a few months ago. > > On 3 Jul 2014, at 14:17, Werner Keil wrote: > > > I know, back then it was sort of legitimate, see Greg Luck and 107, but > the whole idea of JCP.next and JSRs between 148 and 164 is to ensure, > "Individual Members" contribute only on their own behalf, and in most cases > (especially for the Spec Lead Role, it might be a bit less critical if you > just submit a pull-request every once in a while or contribute via Gerrit, > etc.) that is a conflict if he or others work for another company like Bob > does at Square now. > > > > On Thu, Jul 3, 2014 at 3:05 PM, Pete Muir wrote: > > BTW it?s actually Bob Lee who owns JSR-330, he took it with him > personally when left Google. > > > > On 3 Jul 2014, at 10:02, Martijn Verburg > wrote: > > > > > FYI - I've sent a note to the various folks from Google, Pivotal et > al, I'll let Antoine explain the CDI 2.0 proposal to them and I'm sure > they'll either join this mailing list / discussion or we'll quickly find > out there's no appetite and we can move on. > > > > > > Cheers, > > > Martijn > > > > > > > > > On 3 July 2014 09:51, Martijn Verburg > wrote: > > > Hi All, > > > > > > To be blunt, this is a social/community issue - not a technical one. > We simply need to get hold of the folks at Pivotal, Google (and other 330 > EG members) and get them around the virtual table. If they subsequently > aren't interested then fine, you should forge your own path. > > > > > > There's an absolute mega ton of 330 based DI code out there and 330 > compliant containers, if CDI 2.0 wants to be the defacto std going forwards > it simply can't afford ignore that. > > > > > > @Antoine - let's put our heads together and see who we need to get > hold of in the 330 group, I think CDI 2.0 has strong merits and should be > explored. > > > > > > @Werner - your comments about Bob's commitment (considering what he's > done for the tech community at large, let alone Java) are highly > inappropriate, please refrain from personal attacks on this or any other > public forum. > > > > > > > > > Cheers, > > > Martijn > > > > > > > > > On 3 July 2014 09:02, Antonio Goncalves > wrote: > > > > To sum up, as a Java EE user (like I have been for 10 years) I?d be > happy to see this (scenario 2), but as CDI spec lead I fear that it could > lead us in a trap (going to scenario 1 or consuming precious time on > AtInject+1 instead of CDI 2.0) > > > > > > Well, I'm not spec lead, I'm just a Java EE user... so I like scenario > 2 ;o) > > > > > > But on the other hand, I think there is so much work to be done around > CDI 2.0, parts, and taking those parts to other specifications that > battling with JSR 330 might be time consuming. I would go for scenario > 1.... and cross fingers > > > > > > > > > On Wed, Jul 2, 2014 at 11:18 PM, Werner Keil > wrote: > > > Dear Antoine/all, > > > > > > Thanks for the detailed overview and trying to reach out to the former > Spec Leads and EG of JSR 330. I also copied Anatole, Spec Lead of JSR 354, > since Bob Lee is officially in his EG, but has practically never provided > input there either (like we tend to see sometimes from others considered > "Rock Stars" of the Java Community but since then seemingly resting on > their laurels or just too busy counting their stock options?<329.gif>) > > > > > > Given CDI already was the public perception of "javax.inject" for most > parts, I don't necessarily see that it had to be an MR to the original JSR, > though as those involved in the EC (Martijn, Badr/MoroccoJUG,..) could > probably check with the PMO how to handle a case where the Maintenance Lead > of a JSR was not in the position to continue. I last met J?rgen H?ller > about a year ago in Copenhagen, so for Pivotal's part as Co Spec Lead, I > guess he or the likes of Josh Long could be best to speak to. Happy to get > you in touch with them if you want. > > > > > > Red Hat was also EG member of JSR 330, so Pete, Gavin or whoever else > was there (I remember him from conversations where Mike Keith and I took > part in synergy discussions between 330 and CDI 1.0) at the time could also > help you with this. > > > > > > In theory this could also be part of a new JSR (CDI 2) as long as none > of the enhancements you have in mind break the existing API of JSR 330. The > scope of CDI 2 to work in an SE/standalone or more lightweight environment > than Java EE environment raises a good question of package names like " > javax.enterprise.inject.*" So maybe there is room for synergies in a > package namespace other than "javax.enterprise" at least for new things you > have in mind. > > > > > > Kind Regards, > > > > > > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead | > Eclipse UOMo Lead, Babel Language Champion | Apache Committer > > > Twitter @wernerkeil | @UnitAPI | @JSR354 | #EclipseUOMo | #Java_Social > | #DevOps > > > Skype werner.keil | Google+ gplus.to/wernerkeil > > > > > > * Developer Week: 14/15 Jul 2014, N?rnberg, Germany. Werner Keil, JCP > EC Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class > Continuous Delivery", "JSR 363 and IoT" (GER) > > > > > > * JavaZone 2014: 9-11 Sep 2014, Oslo, Norway. Werner Keil, JCP EC > Member, JSR 363 Spec Lead will present "JSR 363 - The Answer to Life > Science and the Internet of Everything" > > > > > > * JavaOne 2014: Sep 28-Oct 2 2014, San Francisco, USA, Werner Keil, > JCP EC Member, JSR 354 EG Member will host "Java and Digital Currencies, > Friend or FOE" > > > > > > * JMaghreb 3.0: 4-6 Nov 2014, Casablanca, Morocco. Werner Keil, JCP EC > Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class > DevOps", "JSR 363" > > > > > > * Mobile Developer Conference kompakt: 18 Nov 2014, Hamburg, Germany. > Werner Keil, JCP EC Member, Apache DeviceMap Committer will present "Apache > DeviceMap" (GER) > > > > > > > > > On Wed, Jul 2, 2014 at 10:43 PM, Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > > > Hi all, > > > > > > Since the first mention of CDI 2.0 preparation work, we've received a > lot of comment about JSR 330 evolution. With the release of the proposal > draft yesterday, this topic came up again. So let me give my point of view > on this subject to have an open discussion here. > > > > > > When we started to discuss about modularity with Pete in last > november, my first idea was to go see what we could add in JSR 330 to make > it a true specification that could be the first module of CDI. My idea at > that time was to discuss with JSR 330 owner to see if we could bring basic > concept we have in CDI to AtInject spec. In my mind the main features would > have been: > > > - Enhance the javax.inject.Provider interface to bring it at the > same level than javax.enterprise.inject.Instance. That would have > included support for AnnotationLiteral and TypeLiteral as well > > > - Add a Container interface (a very light BeanManger) in JSR 330 to > be able to resolve beans instance from outside managed beans > > > - Add a mechanism to get this Container from non managed beans (like > we get access to BeanManager from JNDI or CDI class) > > > > > > At that time, I contacted Bob Lee without success (didn?t tried > Pivotal since I don?t have contact there). I checked with JCP what could be > done if we?d like to see an evolution of JSR 330 and the owner doesn?t > care, there seems to have solutions but I let it aside since we were in the > middle of CDI 1.2 MR at that time. > > > > > > Today I?m a bit torn about this point. Working on opening JSR 330 > could be like opening pandora box, since I see 2 scenarios : > > > > > > 1) former JSR 330 owners wake up and are ok to get for a new spec > version they lead: > > > Knowing the history of JSR 330 vs JSR 299 I?m not sure everything we?d > need would be heard and even if the people leading this would be > cooperative, a lot of discussion and negotiation would be needed to be sure > that this new AtInject wouldn?t contain features incompatible with CDI. So > it?d be very time consuming with no guarantee to get what we?d need at the > end. > > > > > > 2) former JSR 330 owner don?t mind others take ownership of their spec > to enhance it and we (Red Hat) are the one to take this ownership to secure > CDI: > > > The best solution to minimize risk. But leading a new specification is > a lot more work than just deciding that we have a specific basic inject ? > part ? in CDI 2.0. Leading a spec is very time consuming, so it could be > better on the paper but will impact CDI 2.0 new features. > > > > > > To sum up, as a Java EE user (like I have been for 10 years) I?d be > happy to see this (scenario 2), but as CDI spec lead I fear that it could > lead us in a trap (going to scenario 1 or consuming precious time on > AtInject+1 instead of CDI 2.0) > > > > > > Your input, solutions or comment would be appreciated on this point. > > > > > > Antoine > > > > > > > > > > > > > > > > > > > > > -- > > > 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 > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140703/814a581a/attachment-0001.html From kito-public at virtua.com Thu Jul 3 11:00:04 2014 From: kito-public at virtua.com (Kito Mann) Date: Thu, 3 Jul 2014 11:00:04 -0400 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: References: Message-ID: My $0.02 is that it's worth the effort to evolve JSR-330 for the community as a whole. I've been on projects where they tend to use those annotations even in a CDI environment, and it makes it much easier to switch between Spring and CDI if necessary. On Wed, Jul 2, 2014 at 4:43 PM, Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi all, > > Since the first mention of CDI 2.0 preparation work, we've received a lot > of comment about JSR 330 evolution. With the release of the proposal draft > yesterday, this topic came up again. So let me give my point of view on > this subject to have an open discussion here. > > When we started to discuss about modularity with Pete in last november, my > first idea was to go see what we could add in JSR 330 to make it a true > specification that could be the first module of CDI. My idea at that time > was to discuss with JSR 330 owner to see if we could bring basic concept we > have in CDI to AtInject spec. In my mind the main features would have been: > - Enhance the javax.inject.Provider interface to bring it at the same > level than javax.enterprise.inject.Instance. That would have included > support for AnnotationLiteral and TypeLiteral as well > - Add a Container interface (a very light BeanManger) in JSR 330 to be > able to resolve beans instance from outside managed beans > - Add a mechanism to get this Container from non managed beans (like we > get access to BeanManager from JNDI or CDI class) > > At that time, I contacted Bob Lee without success (didn't tried Pivotal > since I don't have contact there). I checked with JCP what could be done if > we'd like to see an evolution of JSR 330 and the owner doesn't care, there > seems to have solutions but I let it aside since we were in the middle of > CDI 1.2 MR at that time. > > Today I'm a bit torn about this point. Working on opening JSR 330 could be > like opening pandora box, since I see 2 scenarios : > > 1) former JSR 330 owners wake up and are ok to get for a new spec version > they lead: > Knowing the history of JSR 330 vs JSR 299 I'm not sure everything we'd > need would be heard and even if the people leading this would be > cooperative, a lot of discussion and negotiation would be needed to be sure > that this new AtInject wouldn't contain features incompatible with CDI. So > it'd be very time consuming with no guarantee to get what we'd need at the > end. > > 2) former JSR 330 owner don't mind others take ownership of their spec to > enhance it and we (Red Hat) are the one to take this ownership to secure > CDI: > The best solution to minimize risk. But leading a new specification is a > lot more work than just deciding that we have a specific basic inject << > part >> in CDI 2.0. Leading a spec is very time consuming, so it could be > better on the paper but will impact CDI 2.0 new features. > > To sum up, as a Java EE user (like I have been for 10 years) I'd be happy > to see this (scenario 2), but as CDI spec lead I fear that it could lead us > in a trap (going to scenario 1 or consuming precious time on AtInject+1 > instead of CDI 2.0) > > Your input, solutions or comment would be appreciated on this point. > > Antoine > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140703/dc223d88/attachment.html From werner.keil at gmail.com Thu Jul 3 11:35:00 2014 From: werner.keil at gmail.com (Werner Keil) Date: Thu, 3 Jul 2014 17:35:00 +0200 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: References: Message-ID: I guess with only 5 or 6 annotations (and that's all the JSR consists of;-) if changing/improving only one or two of these was what's needed, this could be easiest as MR, otherwise 330 is history as it would require a new JSR. JSR 330 was under JCP 2.7 and for final JSRs they normally stay there, I don't think it can move to a newer version of the JCP: https://jcp.org/en/resources/guide-maintenance#2_7 The trouble is, both Spec Leads seem unresponsive or no longer around (Rod Johnson left Pivotal, Pivotal in its current form does not even seem JCP member and VMware may not be able or interested to step in for them) maybe Pete knows best if Bob was, as until JSR 364 or even a new version of the JSPA are finalized he could probably do it if he wants and has the time for this right now (especially if another JSR like CDI 2 depends on it, that can't be delayed even if this JSR may technically still be unaffected by JCP 2.8+) Except for active corporate members Oracle, Red Hat or IBM the whole EG practically disintegrated. Doug Lea and Tim Peirls may be involved elsewhere (mostly OpenJDK from all I heard) but they have not been active in the JCP or active JSRs recently. Google, we heard gave up the Spec Lead in the first place, so it is unlikely under the current circumstances it will play an active role. Jason VanZyl and Maven I know they at least use JSR 330 quite a bit, so they should at least be interested in its future direction. Thoughtworks I don't recall them to be involved and Martin Fowler himself told me of his "allergy" against such form of standardization, so I would not count on them here either. So assuming a separate @Inject spec shall be maintained there are 3 options: 1. Bob Lee (or the other Spec Lead) responds in a timely manner to contact attempts by Antoine and ultimately the PMO (who needs to handle such situations) in which case a simple MR was possible 2. A replacement of Maintenance Lead, along the lines of https://jcp.org/ja/introduction/faq-speclead#slresigns (it is rarely the case for an MR, but should work pretty much the same way here, so the main candidates to replace a Spec Lead would be in that EG, hence Red Hat, IBM or Oracle for most part;-) If such condition can't be resolved, both PMO and JCP EC would be able to help find a suitable replacement, too 3. A whole new JSR is filed. Although it is often the case that the Spec Lead(s) are the same, that is not necessary, especially if the old ones moved on or can't do this any more right now. HTH, Werner On Thu, Jul 3, 2014 at 5:00 PM, Kito Mann wrote: > My $0.02 is that it's worth the effort to evolve JSR-330 for the community > as a whole. I've been on projects where they tend to use those annotations > even in a CDI environment, and it makes it much easier to switch between > Spring and CDI if necessary. > > > On Wed, Jul 2, 2014 at 4:43 PM, Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > >> Hi all, >> >> Since the first mention of CDI 2.0 preparation work, we've received a lot >> of comment about JSR 330 evolution. With the release of the proposal draft >> yesterday, this topic came up again. So let me give my point of view on >> this subject to have an open discussion here. >> >> When we started to discuss about modularity with Pete in last november, >> my first idea was to go see what we could add in JSR 330 to make it a true >> specification that could be the first module of CDI. My idea at that time >> was to discuss with JSR 330 owner to see if we could bring basic concept we >> have in CDI to AtInject spec. In my mind the main features would have been: >> - Enhance the javax.inject.Provider interface to bring it at the same >> level than javax.enterprise.inject.Instance. That would have included >> support for AnnotationLiteral and TypeLiteral as well >> - Add a Container interface (a very light BeanManger) in JSR 330 to be >> able to resolve beans instance from outside managed beans >> - Add a mechanism to get this Container from non managed beans (like we >> get access to BeanManager from JNDI or CDI class) >> >> At that time, I contacted Bob Lee without success (didn?t tried Pivotal >> since I don?t have contact there). I checked with JCP what could be done if >> we?d like to see an evolution of JSR 330 and the owner doesn?t care, there >> seems to have solutions but I let it aside since we were in the middle of >> CDI 1.2 MR at that time. >> >> Today I?m a bit torn about this point. Working on opening JSR 330 could >> be like opening pandora box, since I see 2 scenarios : >> >> 1) former JSR 330 owners wake up and are ok to get for a new spec version >> they lead: >> Knowing the history of JSR 330 vs JSR 299 I?m not sure everything we?d >> need would be heard and even if the people leading this would be >> cooperative, a lot of discussion and negotiation would be needed to be sure >> that this new AtInject wouldn?t contain features incompatible with CDI. So >> it?d be very time consuming with no guarantee to get what we?d need at the >> end. >> >> 2) former JSR 330 owner don?t mind others take ownership of their spec to >> enhance it and we (Red Hat) are the one to take this ownership to secure >> CDI: >> The best solution to minimize risk. But leading a new specification is a >> lot more work than just deciding that we have a specific basic inject ? >> part ? in CDI 2.0. Leading a spec is very time consuming, so it could be >> better on the paper but will impact CDI 2.0 new features. >> >> To sum up, as a Java EE user (like I have been for 10 years) I?d be happy >> to see this (scenario 2), but as CDI spec lead I fear that it could lead us >> in a trap (going to scenario 1 or consuming precious time on AtInject+1 >> instead of CDI 2.0) >> >> Your input, solutions or comment would be appreciated on this point. >> >> Antoine >> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140703/6b6f0fd2/attachment.html From struberg at yahoo.de Thu Jul 3 14:00:40 2014 From: struberg at yahoo.de (Mark Struberg) Date: Thu, 3 Jul 2014 19:00:40 +0100 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: References: Message-ID: <1404410440.24522.YahooMailNeo@web28903.mail.ir2.yahoo.com> As far as I know the history (and I have been tracking and contributing to JSR-330 back then) most of the people were fed up _because_ they got pushed to change the license from ALv2 to something else (cannot remember anymore what exactly). The original Apache v2 licensed work can be found here: https://code.google.com/p/atinject/ I have no clue why Oracle ?added the 'accept license' radio button on their JSR-330 download page. Maybe just a copy&paste error? The text in this license window is in fact not ALv2 but something else which is wrong information at best.? The good news: ALL the assets in JSR-330 still are ALv2! Thus anyone can take it and enhance it.? Of course it would be good to have Bob and J?rgen on board, but legally it might not even be necessary. LieGrue, strub On Thursday, 3 July 2014, 17:35, Werner Keil wrote: > > >I guess with only 5 or 6 annotations (and that's all the JSR consists of;-) if changing/improving only one or two of these was what's needed, this could be easiest as MR, otherwise 330 is history as it would require a new JSR. JSR 330 was under JCP 2.7 and for final JSRs they normally stay there, I don't think it can move to a newer version of the JCP:?https://jcp.org/en/resources/guide-maintenance#2_7 > > > >The trouble is, both Spec Leads seem unresponsive or no longer around (Rod Johnson left Pivotal, Pivotal in its current form does not even seem JCP member and VMware may not be able or interested to step in for them) maybe Pete knows best if Bob was, as until JSR 364 or even a new version of the JSPA are finalized he could probably do it if he wants and has the time for this right now (especially if another JSR like CDI 2 depends on it, that can't be delayed even if this JSR may technically still be unaffected by JCP 2.8+)? > > >Except for active corporate members Oracle, Red Hat or IBM the whole EG practically disintegrated. Doug Lea and Tim Peirls may be involved elsewhere (mostly OpenJDK from all I heard) but they have not been active in the JCP or active JSRs recently. Google, we heard gave up the Spec Lead in the first place, so it is unlikely under the current circumstances it will play an active role. Jason VanZyl and Maven I know they at least use JSR 330 quite a bit, so they should at least be interested in its future direction. Thoughtworks I don't recall them to be involved and Martin Fowler himself told me of his "allergy" against such form of standardization, so I would not count on them here either. > > >So assuming a separate @Inject spec shall be maintained there are 3 options: > 1. Bob Lee (or the other Spec Lead) responds in a timely manner to contact attempts by Antoine and ultimately the PMO (who needs to handle such situations) in which case a simple MR was possible > 2. A replacement of Maintenance Lead, along the lines of?https://jcp.org/ja/introduction/faq-speclead#slresigns?(it is rarely the case for an MR, but should work pretty much the same way here, so the main candidates to replace a Spec Lead would be in that EG, hence Red Hat, IBM or Oracle for most part;-) If such condition can't be resolved, both PMO and JCP EC would be able to help find a suitable replacement, too > 3. A whole new JSR is filed. Although it is often the case that the Spec Lead(s) are the same, that is not necessary, especially if the old ones moved on or can't do this any more right now. >HTH, >Werner > > > > >On Thu, Jul 3, 2014 at 5:00 PM, Kito Mann wrote: > >My $0.02 is that it's worth the effort to evolve JSR-330 for the community as a whole. I've been on projects where they tend to use those annotations even in a CDI environment, and it makes it much easier to switch between Spring and CDI if necessary. >> >> >> >>On Wed, Jul 2, 2014 at 4:43 PM, Antoine Sabot-Durand wrote: >> >>Hi all, >>> >>>Since the first mention of CDI 2.0 preparation work, we've received a lot of comment about JSR 330 evolution. With the release of the proposal draft yesterday, this topic came up again. So let me give my point of view on this subject to have an open discussion here. >>> >>>When we started to discuss about modularity with Pete in last november, my first idea was to go see what we could add in JSR 330 to make it a true specification that could be the first module of CDI. My idea at that time was to discuss with JSR 330 owner to see if we could bring basic concept we have in CDI to AtInject spec. In my mind the main features would have been: >>>?- Enhance the javax.inject.Provider interface to bring it at the same level than javax.enterprise.inject.Instance. That would have included support for AnnotationLiteral and TypeLiteral as well >>>?- Add a Container interface (a very light BeanManger) in JSR 330 to be able to resolve beans instance from outside managed beans >>>?- Add a mechanism to get this Container from non managed beans (like we get access to BeanManager from JNDI or CDI class) >>> >>>At that time, I contacted Bob Lee without success (didn?t tried Pivotal since I don?t have contact there). I checked with JCP what could be done if we?d like to see an evolution of JSR 330 and the owner doesn?t care, there seems to have solutions but I let it aside since we were in the middle of CDI 1.2 MR at that time. >>> >>>Today I?m a bit torn about this point. Working on opening JSR 330 could be like opening pandora box, since I see 2 scenarios : >>> >>>1) former JSR 330 owners wake up and are ok to get for a new spec version they lead: >>>Knowing the history of JSR 330 vs JSR 299 I?m not sure everything we?d need would be heard and even if the people leading this would be cooperative, a lot of discussion and negotiation would be needed to be sure that this new AtInject wouldn?t contain features incompatible with CDI. So it?d be very time consuming with no guarantee to get what we?d need at the end. >>> >>>2) former JSR 330 owner don?t mind others take ownership of their spec to enhance it and we (Red Hat) are the one to take this ownership to secure CDI: >>>The best solution to minimize risk. But leading a new specification is a lot more work than just deciding that we have a specific basic inject ? part ? in ?CDI 2.0. Leading a spec is very time consuming, so it could be better on the paper but will impact CDI 2.0 new features. >>> >>>To sum up, as a Java EE user (like I have been for 10 years) I?d be happy to see this (scenario 2), but as CDI spec lead I fear that it could lead us in a trap (going to scenario 1 or consuming precious time on AtInject+1 instead of CDI 2.0) >>> >>>Your input, solutions or comment would be appreciated on this point. >>> >>>Antoine >>> >>> >>> >>> >>>_______________________________________________ >>>cdi-dev mailing list >>>cdi-dev at lists.jboss.org >>>https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >> > > >_______________________________________________ >cdi-dev mailing list >cdi-dev at lists.jboss.org >https://lists.jboss.org/mailman/listinfo/cdi-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140703/6fd4053c/attachment-0001.html From werner.keil at gmail.com Thu Jul 3 14:33:53 2014 From: werner.keil at gmail.com (Werner Keil) Date: Thu, 3 Jul 2014 20:33:53 +0200 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: <1404410440.24522.YahooMailNeo@web28903.mail.ir2.yahoo.com> References: <1404410440.24522.YahooMailNeo@web28903.mail.ir2.yahoo.com> Message-ID: I must correct you in the sense, that the license (that "Accept and Download" page) for the Spec is not Apache, though there is practically no spec here for these 6 annotations. So it is a bit of a grey zone, and even EC Members with a large legal department are in ongoing discussions over that. The "Spec" and its Software Manifestation (normally all artifacts under "javax.something" or "java.something" (for the few JSRs like 310 that changed their package name in the course of the lifecycle) in Oracle's (the PMO) understanding is under the Spec License. So strictly speaking annotations under "javax.inject" are the "Spec", not RI or TCK, and therefore they don't fall under Apache 2. Google Guice and the TCK did and still do. Looking at JSRs like 107 https://github.com/jsr107/jsr107spec or 354, you'll notice they all have this in common. Especially the JavaDoc as manifestation of the Spec (and for 330 that is all there is of a Spec) therefore naturally fall under the Spec License, too. Just see Java EE 7: http://docs.oracle.com/javaee/7/api/ the JavaDoc (for all JSRs within that umbrella) is therefore covered by the EE 7 Spec License >Copyright ? 1996-2013, Oracle and/or its affiliates. All Rights Reserved. Use is subject to license terms . see the link under "license terms"[?] JSR 352 poses a stubbern dilemma as its EG and Spec Leads insist on a different license footer in the standalone distribution (Apache 2) as in the overall Java EE 7 umbrella. Which is a nightmare for users, a reason I voted against the MR or abstained from this particular JSR as it denies what is reality at least for the Spec and artifacts like the JavaDoc. CDI refrains from this breach. At least there is no contradicting JavaDoc license pointer. Red Hat considers a "Dual Licensing" option for the Spec, but from all I heard so far, this is not how Oracle and the JCP PMO (or at least Oracle's lawyers) see this. With the proposal of the ULA Oracle tries to get all future JSRs to use a single license for RI and TCK. There's an ongoing discussion over details, but unless Oracle's legal department and PMO make a dramatic turn on these matters, JSRs filed in the near future (including CDI 2 or beyond) would likely fall under Spec and ULA license. Cheers, Werner On Thu, Jul 3, 2014 at 8:00 PM, Mark Struberg wrote: > As far as I know the history (and I have been tracking and contributing to > JSR-330 back then) most of the people were fed up _because_ they got pushed > to change the license from ALv2 to something else (cannot remember anymore > what exactly). > > The original Apache v2 licensed work can be found here: > https://code.google.com/p/atinject/ > > I have no clue why Oracle added the 'accept license' radio button on > their JSR-330 download page. Maybe just a copy&paste error? The text in > this license window is in fact not ALv2 but something else which is wrong > information at best. > > The good news: ALL the assets in JSR-330 still are ALv2! > Thus anyone can take it and enhance it. > Of course it would be good to have Bob and J?rgen on board, but legally it > might not even be necessary. > > LieGrue, > strub > > > > On Thursday, 3 July 2014, 17:35, Werner Keil > wrote: > > > > I guess with only 5 or 6 annotations (and that's all the JSR consists > of;-) if changing/improving only one or two of these was what's needed, > this could be easiest as MR, otherwise 330 is history as it would require a > new JSR. JSR 330 was under JCP 2.7 and for final JSRs they normally stay > there, I don't think it can move to a newer version of the JCP: > https://jcp.org/en/resources/guide-maintenance#2_7 > > The trouble is, both Spec Leads seem unresponsive or no longer around (Rod > Johnson left Pivotal, Pivotal in its current form does not even seem JCP > member and VMware may not be able or interested to step in for them) maybe > Pete knows best if Bob was, as until JSR 364 or even a new version of the > JSPA are finalized he could probably do it if he wants and has the time for > this right now (especially if another JSR like CDI 2 depends on it, that > can't be delayed even if this JSR may technically still be unaffected by > JCP 2.8+) > > Except for active corporate members Oracle, Red Hat or IBM the whole EG > practically disintegrated. Doug Lea and Tim Peirls may be involved > elsewhere (mostly OpenJDK from all I heard) but they have not been active > in the JCP or active JSRs recently. Google, we heard gave up the Spec Lead > in the first place, so it is unlikely under the current circumstances it > will play an active role. Jason VanZyl and Maven I know they at least use > JSR 330 quite a bit, so they should at least be interested in its future > direction. Thoughtworks I don't recall them to be involved and Martin > Fowler himself told me of his "allergy" against such form of > standardization, so I would not count on them here either. > > So assuming a separate @Inject spec shall be maintained there are 3 > options: > > 1. Bob Lee (or the other Spec Lead) responds in a timely manner to > contact attempts by Antoine and ultimately the PMO (who needs to handle > such situations) in which case a simple MR was possible > 2. A replacement of Maintenance Lead, along the lines of > https://jcp.org/ja/introduction/faq-speclead#slresigns (it is rarely > the case for an MR, but should work pretty much the same way here, so the > main candidates to replace a Spec Lead would be in that EG, hence Red Hat, > IBM or Oracle for most part;-) If such condition can't be resolved, both > PMO and JCP EC would be able to help find a suitable replacement, too > 3. A whole new JSR is filed. Although it is often the case that the > Spec Lead(s) are the same, that is not necessary, especially if the old > ones moved on or can't do this any more right now. > > HTH, > Werner > > > On Thu, Jul 3, 2014 at 5:00 PM, Kito Mann wrote: > > My $0.02 is that it's worth the effort to evolve JSR-330 for the community > as a whole. I've been on projects where they tend to use those annotations > even in a CDI environment, and it makes it much easier to switch between > Spring and CDI if necessary. > > > On Wed, Jul 2, 2014 at 4:43 PM, Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > > Hi all, > > Since the first mention of CDI 2.0 preparation work, we've received a lot > of comment about JSR 330 evolution. With the release of the proposal draft > yesterday, this topic came up again. So let me give my point of view on > this subject to have an open discussion here. > > When we started to discuss about modularity with Pete in last november, my > first idea was to go see what we could add in JSR 330 to make it a true > specification that could be the first module of CDI. My idea at that time > was to discuss with JSR 330 owner to see if we could bring basic concept we > have in CDI to AtInject spec. In my mind the main features would have been: > - Enhance the javax.inject.Provider interface to bring it at the same > level than javax.enterprise.inject.Instance. That would have included > support for AnnotationLiteral and TypeLiteral as well > - Add a Container interface (a very light BeanManger) in JSR 330 to be > able to resolve beans instance from outside managed beans > - Add a mechanism to get this Container from non managed beans (like we > get access to BeanManager from JNDI or CDI class) > > At that time, I contacted Bob Lee without success (didn?t tried Pivotal > since I don?t have contact there). I checked with JCP what could be done if > we?d like to see an evolution of JSR 330 and the owner doesn?t care, there > seems to have solutions but I let it aside since we were in the middle of > CDI 1.2 MR at that time. > > Today I?m a bit torn about this point. Working on opening JSR 330 could be > like opening pandora box, since I see 2 scenarios : > > 1) former JSR 330 owners wake up and are ok to get for a new spec version > they lead: > Knowing the history of JSR 330 vs JSR 299 I?m not sure everything we?d > need would be heard and even if the people leading this would be > cooperative, a lot of discussion and negotiation would be needed to be sure > that this new AtInject wouldn?t contain features incompatible with CDI. So > it?d be very time consuming with no guarantee to get what we?d need at the > end. > > 2) former JSR 330 owner don?t mind others take ownership of their spec to > enhance it and we (Red Hat) are the one to take this ownership to secure > CDI: > The best solution to minimize risk. But leading a new specification is a > lot more work than just deciding that we have a specific basic inject ? > part ? in CDI 2.0. Leading a spec is very time consuming, so it could be > better on the paper but will impact CDI 2.0 new features. > > To sum up, as a Java EE user (like I have been for 10 years) I?d be happy > to see this (scenario 2), but as CDI spec lead I fear that it could lead us > in a trap (going to scenario 1 or consuming precious time on AtInject+1 > instead of CDI 2.0) > > Your input, solutions or comment would be appreciated on this point. > > Antoine > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140703/4b1907b3/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 257 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140703/4b1907b3/attachment-0001.gif From struberg at yahoo.de Thu Jul 3 16:47:13 2014 From: struberg at yahoo.de (Mark Struberg) Date: Thu, 3 Jul 2014 21:47:13 +0100 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: References: <1404410440.24522.YahooMailNeo@web28903.mail.ir2.yahoo.com> Message-ID: <1404420433.77837.YahooMailNeo@web28901.mail.ir2.yahoo.com> Hi! > The "Spec" and its Software Manifestation (normally all artifacts > under "javax.something" or "java.something" (for the few JSRs > like 310 that changed their package name in the course of > the lifecycle) in Oracle's (the PMO) understanding is under > the Spec License. Werner, this might be Oracles understanding, but to me and many legally trained colleagues it still seems factually wrong from a purely legal aspect. If I write something under ALv2 and contribute it to the JCP under ALv2, then no one (but me) has the right to change this license without asking me. Not even Oracle. Also the JSPA only talks about sublicensing (which does NOT include re-licensing under a different license!) and even explicitly says 'same license'. It does _not_ say _which_ license, it only defines (in ?5E) "terms and conditions that are non-discriminatory, fair and reasonable". It surely does not allow Sun/Oracle to re-license the original ALv2 work of JSR-330 (and other specs) with any other license. And it also doesn't matter what Oracle defines as 'Spec'. The important legal definition is the term 'work' which is used throughout almost all OSS licenses. And if Oracle provides a download with a zip which only contains ALv2 licensed 'work', then it also must prompt this license on their download page - and not any other license which no single piece of the downloaded archive is licensed under. You can check Androids 'system config -> licenses' page to see how this is done ;)? If you find such a paragraph which would allow such a re-licensing then please tell me. Oracle would have had to refuse that spec and force the EG to pick another one. But now this is too late. This ship has pretty much sailed. Changing or 'reinterpreting' this work as under some different license is simply breaking a law. >Just see Java EE 7: http://docs.oracle.com/javaee/7/api/ > the JavaDoc (for all JSRs within that umbrella) > is therefore covered by the EE 7 Spec License >>Copyright ? 1996-2013, Oracle and/or its affiliates. > All Rights Reserved. Use is subject to license terms. Which is again factually wrong imo! I can also copy random files from the internet and claim that I own all the copyrights. It gets a bit more complex when we go into the legal details. On the one hand JavaDoc is always more complicated as the 'work' of bringing it into a nice representation might constitute own Copyright. And this is also fine as ALv2 allows to add your own 'work' in any license you like. But (often misinterpreted even by lawyers) ALv2 does NOT allow re-licensing: the original work (the parts which were ALv2) are STILL ALv2. This is btw almost always the case - this is what eventual Contributor License Agreements are for... It might also be that the 'collection of work' creates an own originary copyright. Like a prose book might constitute own IP _in addition_ to the original IP. But this 'collection IP' doesn't change the 'meat' content of javax.inject for example as explained above. >CDI refrains from this breach. At least there is no contradicting JavaDoc license pointer. Again wrong: https://github.com/cdi-spec/cdi/blob/master/api/src/main/java/javax/enterprise/inject/spi/BeanManager.java Clearly ALv2... And Oracle also cannot force JBoss to amend or change this license easily. JBoss would have to go to EVERY contributor and ask for permission! Btw, I've talked with a few lawyers who reviewed ULA and they did all not sound happy about it... I also got a bunch of weird answers from Oracle lawyers, e.g. that we must not do a RI which is ALv2, EPL, OSGI, etc because 'they are not compatible with the licenses we use in Glassfish'. Totally sick argument. If that would be true than Oracle would need to remove 50 jars from Glassfish4, including * Weld * Eclipselink * all OSGi * Tomcat (yes, core-web.jar is nothing but a repackaged tomcat) * JNDI (org.apache.naming) to just name a few. Would this make sense? Do we really like to go down this route? To make it clear: Glassfish is dual licensed as CDDL and GPL+CPE. And exactly the ClassPathException is the case why EPL and ALv2 jars inside Glassfish are totally fine and this legal info we got from Oracle legal is imo nuts. I know there is tons of legal b******t going round these days. But repeating it over and over again doesn't make it more true... If you think I have an error in my argumentation then please feel free to correct me and help me understand the problem. LieGrue, strub On Thursday, 3 July 2014, 20:33, Werner Keil wrote: >I must correct you in the sense, that the license (that "Accept and Download" page) for the Spec is not Apache, though there is practically no spec here for these 6 annotations. >So it is a bit of a grey zone, and even EC Members with a large legal department are in ongoing discussions over that. The "Spec" and its Software Manifestation (normally all artifacts under "javax.something" or "java.something" (for the few JSRs like 310 that changed their package name in the course of the lifecycle) in Oracle's (the PMO) understanding is under the Spec License.? > > >So strictly speaking annotations under "javax.inject" are the "Spec", not RI or TCK, and therefore they don't fall under Apache 2. Google Guice and the TCK did and still do. > > >Looking at JSRs like 107?https://github.com/jsr107/jsr107spec or 354, you'll notice they all have this in common.? >Especially the JavaDoc as manifestation of the ?Spec (and for 330 that is all there is of a Spec) therefore naturally fall under the Spec License, too.? > > >Just see Java EE 7:?http://docs.oracle.com/javaee/7/api/ the JavaDoc (for all JSRs within that umbrella) is therefore covered by the EE 7 Spec License >>Copyright ? 1996-2013,?Oracle?and/or its affiliates. All Rights Reserved. Use is subject to?license terms. > >see the link under "license terms" > > >JSR 352 poses a stubbern dilemma as its EG and Spec Leads insist on a different license footer in the standalone distribution (Apache 2) as in the overall Java EE 7 umbrella. >Which is a nightmare for users, a reason I voted against the MR or abstained from this particular JSR as it denies what is reality at least for the Spec and artifacts like the JavaDoc. > > >CDI refrains from this breach. At least there is no contradicting JavaDoc license pointer.? > > >Red Hat considers a "Dual Licensing" option for the Spec, but from all I heard so far, this is not how Oracle and the JCP PMO (or at least Oracle's lawyers) see this.?With the proposal of the ULA Oracle tries to get all future JSRs to use a single license for RI and TCK. > > >There's an ongoing discussion over details, but unless Oracle's legal department and PMO make a dramatic turn on these matters, JSRs filed in the near future (including CDI 2 or beyond) would likely fall under Spec and ULA license. > > >Cheers, >Werner > > >On Thu, Jul 3, 2014 at 8:00 PM, Mark Struberg wrote: > >As far as I know the history (and I have been tracking and contributing to JSR-330 back then) most of the people were fed up _because_ they got pushed to change the license from ALv2 to something else (cannot remember anymore what exactly). >> >> >>The original Apache v2 licensed work can be found here: >>https://code.google.com/p/atinject/ >> >> >> >>I have no clue why Oracle ?added the 'accept license' radio button on their JSR-330 download page. Maybe just a copy&paste error? The text in this license window is in fact not ALv2 but something else which is wrong information at best.? >> >> >>The good news: ALL the assets in JSR-330 still are ALv2! >>Thus anyone can take it and enhance it.? >>Of course it would be good to have Bob and J?rgen on board, but legally it might not even be necessary. >> >> >>LieGrue, >>strub >> >> >> >> >> >>On Thursday, 3 July 2014, 17:35, Werner Keil wrote: >> >> >>> >>> >>>I guess with only 5 or 6 annotations (and that's all the JSR consists of;-) if changing/improving only one or two of these was what's needed, this could be easiest as MR, otherwise 330 is history as it would require a new JSR. JSR 330 was under JCP 2.7 and for final JSRs they normally stay there, I don't think it can move to a newer version of the JCP:?https://jcp.org/en/resources/guide-maintenance#2_7 >>> >>> >>> >>>The trouble is, both Spec Leads seem unresponsive or no longer around (Rod Johnson left Pivotal, Pivotal in its current form does not even seem JCP member and VMware may not be able or interested to step in for them) maybe Pete knows best if Bob was, as until JSR 364 or even a new version of the JSPA are finalized he could probably do it if he wants and has the time for this right now (especially if another JSR like CDI 2 depends on it, that can't be delayed even if this JSR may technically still be unaffected by JCP 2.8+)? >>> >>> >>>Except for active corporate members Oracle, Red Hat or IBM the whole EG practically disintegrated. Doug Lea and Tim Peirls may be involved elsewhere (mostly OpenJDK from all I heard) but they have not been active in the JCP or active JSRs recently. Google, we heard gave up the Spec Lead in the first place, so it is unlikely under the current circumstances it will play an active role. Jason VanZyl and Maven I know they at least use JSR 330 quite a bit, so they should at least be interested in its future direction. Thoughtworks I don't recall them to be involved and Martin Fowler himself told me of his "allergy" against such form of standardization, so I would not count on them here either. >>> >>> >>>So assuming a separate @Inject spec shall be maintained there are 3 options: >>>????1. Bob Lee (or the other Spec Lead) responds in a timely manner to contact attempts by Antoine and ultimately the PMO (who needs to handle such situations) in which case a simple MR was possible >>>????2. A replacement of Maintenance Lead, along the lines of?https://jcp.org/ja/introduction/faq-speclead#slresigns?(it is rarely the case for an MR, but should work pretty much the same way here, so the main candidates to replace a Spec Lead would be in that EG, hence Red Hat, IBM or Oracle for most part;-) If such condition can't be resolved, both PMO and JCP EC would be able to help find a suitable replacement, too >>>????3. A whole new JSR is filed. Although it is often the case that the Spec Lead(s) are the same, that is not necessary, especially if the old ones moved on or can't do this any more right now. >>>HTH, >>>Werner >>> >>> >>> >>> >>>On Thu, Jul 3, 2014 at 5:00 PM, Kito Mann wrote: >>> >>>My $0.02 is that it's worth the effort to evolve JSR-330 for the community as a whole. I've been on projects where they tend to use those annotations even in a CDI environment, and it makes it much easier to switch between Spring and CDI if necessary. >>>> >>>> >>>> >>>>On Wed, Jul 2, 2014 at 4:43 PM, Antoine Sabot-Durand wrote: >>>> >>>>Hi all, >>>>> >>>>>Since the first mention of CDI 2.0 preparation work, we've received a lot of comment about JSR 330 evolution. With the release of the proposal draft yesterday, this topic came up again. So let me give my point of view on this subject to have an open discussion here. >>>>> >>>>>When we started to discuss about modularity with Pete in last november, my first idea was to go see what we could add in JSR 330 to make it a true specification that could be the first module of CDI. My idea at that time was to discuss with JSR 330 owner to see if we could bring basic concept we have in CDI to AtInject spec. In my mind the main features would have been: >>>>>?- Enhance the javax.inject.Provider interface to bring it at the same level than javax.enterprise.inject.Instance. That would have included support for AnnotationLiteral and TypeLiteral as well >>>>>?- Add a Container interface (a very light BeanManger) in JSR 330 to be able to resolve beans instance from outside managed beans >>>>>?- Add a mechanism to get this Container from non managed beans (like we get access to BeanManager from JNDI or CDI class) >>>>> >>>>>At that time, I contacted Bob Lee without success (didn?t tried Pivotal since I don?t have contact there). I checked with JCP what could be done if we?d like to see an evolution of JSR 330 and the owner doesn?t care, there seems to have solutions but I let it aside since we were in the middle of CDI 1.2 MR at that time. >>>>> >>>>>Today I?m a bit torn about this point. Working on opening JSR 330 could be like opening pandora box, since I see 2 scenarios : >>>>> >>>>>1) former JSR 330 owners wake up and are ok to get for a new spec version they lead: >>>>>Knowing the history of JSR 330 vs JSR 299 I?m not sure everything we?d need would be heard and even if the people leading this would be cooperative, a lot of discussion and negotiation would be needed to be sure that this new AtInject wouldn?t contain features incompatible with CDI. So it?d be very time consuming with no guarantee to get what we?d need at the end. >>>>> >>>>>2) former JSR 330 owner don?t mind others take ownership of their spec to enhance it and we (Red Hat) are the one to take this ownership to secure CDI: >>>>>The best solution to minimize risk. But leading a new specification is a lot more work than just deciding that we have a specific basic inject ? part ? in ?CDI 2.0. Leading a spec is very time consuming, so it could be better on the paper but will impact CDI 2.0 new features. >>>>> >>>>>To sum up, as a Java EE user (like I have been for 10 years) I?d be happy to see this (scenario 2), but as CDI spec lead I fear that it could lead us in a trap (going to scenario 1 or consuming precious time on AtInject+1 instead of CDI 2.0) >>>>> >>>>>Your input, solutions or comment would be appreciated on this point. >>>>> >>>>>Antoine >>>>> >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>cdi-dev mailing list >>>>>cdi-dev at lists.jboss.org >>>>>https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>> >>> >>> >>>_______________________________________________ >>>cdi-dev mailing list >>>cdi-dev at lists.jboss.org >>>https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> > > > From werner.keil at gmail.com Thu Jul 3 17:17:11 2014 From: werner.keil at gmail.com (Werner Keil) Date: Thu, 3 Jul 2014 23:17:11 +0200 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: <1404420433.77837.YahooMailNeo@web28901.mail.ir2.yahoo.com> References: <1404410440.24522.YahooMailNeo@web28903.mail.ir2.yahoo.com> <1404420433.77837.YahooMailNeo@web28901.mail.ir2.yahoo.com> Message-ID: Most of this remains to be discussed by a dedicated IP WG of JSR 358. Which I ocasionally join and if you (or others here) have particular interest, transparency means pretty much everything, especially minutes, etc. is available also to those outside the WG or EC. On Thu, Jul 3, 2014 at 10:47 PM, Mark Struberg wrote: > Hi! > > > > The "Spec" and its Software Manifestation (normally all artifacts > > > under "javax.something" or "java.something" (for the few JSRs > > > like 310 that changed their package name in the course of > > > the lifecycle) in Oracle's (the PMO) understanding is under > > > the Spec License. > > > Werner, this might be Oracles understanding, but to me and many legally > trained colleagues it still seems factually wrong from a purely legal > aspect. > > If I write something under ALv2 and contribute it to the JCP under ALv2, > then no one (but me) has the right to change this license without asking > me. Not even Oracle. Also the JSPA only talks about sublicensing (which > does NOT include re-licensing under a different license!) and even > explicitly says 'same license'. It does _not_ say _which_ license, it only > defines (in ?5E) "terms and conditions that are non-discriminatory, fair > and reasonable". > > > It surely does not allow Sun/Oracle to re-license the original ALv2 work > of JSR-330 (and other specs) with any other license. And it also doesn't > matter what Oracle defines as 'Spec'. The important legal definition is the > term 'work' which is used throughout almost all OSS licenses. And if Oracle > provides a download with a zip which only contains ALv2 licensed 'work', > then it also must prompt this license on their download page - and not any > other license which no single piece of the downloaded archive is licensed > under. You can check Androids 'system config -> licenses' page to see how > this is done ;) > > JSR 330 Spec was never ALv2 licensed, see The RI and TCK will be licensed under the Apache 2 license, and the Specification will be licensed under an agreement that satisfies the requirements of the JSPA. under https://jcp.org/en/jsr/detail?id=330 The "agreement that satisfies the requirements of the JSPA" is the Spec License. > If you find such a paragraph which would allow such a re-licensing then > please tell me. > > There isn't any, again, Oracle has never said there would be any other license than the Spec License for these materials, even if you download "jsr XXX.jar" from a different place other than jcp.org. > > Oracle would have had to refuse that spec and force the EG to pick another > one. But now this is too late. This ship has pretty much sailed. Changing > or 'reinterpreting' this work as under some different license is simply > breaking a law. > > > >Just see Java EE 7: http://docs.oracle.com/javaee/7/api/ > > > the JavaDoc (for all JSRs within that umbrella) > > > is therefore covered by the EE 7 Spec License > >>Copyright ? 1996-2013, Oracle and/or its affiliates. > > > All Rights Reserved. Use is subject to license terms. > > Which is again factually wrong imo! > > I can also copy random files from the internet and claim that I own all > the copyrights. > It gets a bit more complex when we go into the legal details. On the one > hand JavaDoc is always more complicated as the 'work' of bringing it into a > nice representation might constitute own Copyright. And this is also fine > as ALv2 allows to add your own 'work' in any license you like. But (often > misinterpreted even by lawyers) ALv2 does NOT allow re-licensing: the > original work (the parts which were ALv2) are STILL ALv2. This is btw > almost always the case - this is what eventual Contributor License > Agreements are for... > > It might also be that the 'collection of work' creates an own originary > copyright. Like a prose book might constitute own IP _in addition_ to the > original IP. But this 'collection IP' doesn't change the 'meat' content of > javax.inject for example as explained above. > > > >CDI refrains from this breach. At least there is no contradicting JavaDoc > license pointer. > > > Again wrong: > https://github.com/cdi-spec/cdi/blob/master/api/src/main/java/javax/enterprise/inject/spi/BeanManager.java > Clearly ALv2... > And Oracle also cannot force JBoss to amend or change this license easily. > JBoss would have to go to EVERY contributor and ask for permission! > > > The license headers in Java files are irrelevant in reality, and nobody (especially not the EC or PMO) cares about them. They are interested in a single license text provided with the JCP page, and again, for CDI you'll find the same as for JSR 330 or others.. Even in the IP savvy circles, people tend to mix up what's "Spec/API" and what's "RI/TCK". IMHO the likes of JSR 107 got this pretty right, also 354 and a few others. Look into each class if you want and you'll find a pointer to the Spec License or a short version. The API is often ignored or misunderstood, but the JSPA is pretty clear about it, though it was phrased with strong emphasis on the JVM itself: 1.10 Java Specification (Specification or Spec): a written specification for some aspect of the Java technology. This includes the language, virtual machine, Platform Editions, Profiles, and* application programming* *interfaces.* https://jcp.org/aboutJava/communityprocess/JSPA2.pdf I assume almost every one of you here signed it, or had your HR/legal department do;-) "application programming interfaces" - API meaning, the JSPA considers them to be part of the Spec under the subsequent license, but the sentence is so vague, that I'm sure, you'll find 3 different oppinions or interpretations if you just ask enough lawyers;-) > Btw, I've talked with a few lawyers who reviewed ULA and they did all not > sound happy about it... > > > > I also got a bunch of weird answers from Oracle lawyers, e.g. that we must > not do a RI which is ALv2, EPL, OSGI, etc because 'they are not compatible > with the licenses we use in Glassfish'. > Totally sick argument. If that would be true than Oracle would need to > remove 50 jars from Glassfish4, including > * Weld > * Eclipselink > * all OSGi > * Tomcat (yes, core-web.jar is nothing but a repackaged tomcat) > > * JNDI (org.apache.naming) > to just name a few. > > > Would this make sense? Do we really like to go down this route? > > > To make it clear: Glassfish is dual licensed as CDDL and GPL+CPE. And > exactly the ClassPathException is the case why EPL and ALv2 jars inside > Glassfish are totally fine and this legal info we got from Oracle legal is > imo nuts. > > > Look into OpenJDK and especially the whole of the (additional) java.time APIs contain BSD licensed material, despite the fact, that JDK as such is licensed under different agreements. I asked the people in the EC and IP WG discussing these things, and only Azul (not a lawyer but also caring a lot about IP) said their understanding was, it should be OK for "Non EG Members" to contribute this under BSD, but EG Members should have contributed all of that either under the Spec License or the one by OpenJDK. None of the classes in question seem to ever have been touched by anybody other than the Spec Leads as there was no other contribution when 310 was still in places like GitHub or SF.net. > > I know there is tons of legal b******t going round these days. But > repeating it over and over again doesn't make it more true... > > If you think I have an error in my argumentation then please feel free to > correct me and help me understand the problem. > > > I think I'd have to leave that to people in the IP circles or legal team of either Oracle, IBM, Red Hat or others, as soon as they find a common understanding about it;-D > LieGrue, > strub > > > Cheers, Werner > > On Thursday, 3 July 2014, 20:33, Werner Keil > wrote: > >I must correct you in the sense, that the license (that "Accept and > Download" page) for the Spec is not Apache, though there is practically no > spec here for these 6 annotations. > >So it is a bit of a grey zone, and even EC Members with a large legal > department are in ongoing discussions over that. The "Spec" and its > Software Manifestation (normally all artifacts under "javax.something" or > "java.something" (for the few JSRs like 310 that changed their package name > in the course of the lifecycle) in Oracle's (the PMO) understanding is > under the Spec License. > > > > > >So strictly speaking annotations under "javax.inject" are the "Spec", not > RI or TCK, and therefore they don't fall under Apache 2. Google Guice and > the TCK did and still do. > > > > > >Looking at JSRs like 107 https://github.com/jsr107/jsr107spec or 354, > you'll notice they all have this in common. > >Especially the JavaDoc as manifestation of the Spec (and for 330 that is > all there is of a Spec) therefore naturally fall under the Spec License, > too. > > > > > >Just see Java EE 7: http://docs.oracle.com/javaee/7/api/ the JavaDoc > (for all JSRs within that umbrella) is therefore covered by the EE 7 Spec > License > >>Copyright ? 1996-2013, Oracle and/or its affiliates. All Rights > Reserved. Use is subject to license terms. > > > >see the link under "license terms" > > > > > >JSR 352 poses a stubbern dilemma as its EG and Spec Leads insist on a > different license footer in the standalone distribution (Apache 2) as in > the overall Java EE 7 umbrella. > >Which is a nightmare for users, a reason I voted against the MR or > abstained from this particular JSR as it denies what is reality at least > for the Spec and artifacts like the JavaDoc. > > > > > >CDI refrains from this breach. At least there is no contradicting JavaDoc > license pointer. > > > > > >Red Hat considers a "Dual Licensing" option for the Spec, but from all I > heard so far, this is not how Oracle and the JCP PMO (or at least Oracle's > lawyers) see this. With the proposal of the ULA Oracle tries to get all > future JSRs to use a single license for RI and TCK. > > > > > >There's an ongoing discussion over details, but unless Oracle's legal > department and PMO make a dramatic turn on these matters, JSRs filed in the > near future (including CDI 2 or beyond) would likely fall under Spec and > ULA license. > > > > > >Cheers, > >Werner > > > > > >On Thu, Jul 3, 2014 at 8:00 PM, Mark Struberg wrote: > > > >As far as I know the history (and I have been tracking and contributing > to JSR-330 back then) most of the people were fed up _because_ they got > pushed to change the license from ALv2 to something else (cannot remember > anymore what exactly). > >> > >> > >>The original Apache v2 licensed work can be found here: > >>https://code.google.com/p/atinject/ > >> > >> > >> > >>I have no clue why Oracle added the 'accept license' radio button on > their JSR-330 download page. Maybe just a copy&paste error? The text in > this license window is in fact not ALv2 but something else which is wrong > information at best. > >> > >> > >>The good news: ALL the assets in JSR-330 still are ALv2! > >>Thus anyone can take it and enhance it. > >>Of course it would be good to have Bob and J?rgen on board, but legally > it might not even be necessary. > >> > >> > >>LieGrue, > >>strub > >> > >> > >> > >> > >> > >>On Thursday, 3 July 2014, 17:35, Werner Keil > wrote: > >> > >> > >>> > >>> > >>>I guess with only 5 or 6 annotations (and that's all the JSR consists > of;-) if changing/improving only one or two of these was what's needed, > this could be easiest as MR, otherwise 330 is history as it would require a > new JSR. JSR 330 was under JCP 2.7 and for final JSRs they normally stay > there, I don't think it can move to a newer version of the JCP: > https://jcp.org/en/resources/guide-maintenance#2_7 > >>> > >>> > >>> > >>>The trouble is, both Spec Leads seem unresponsive or no longer around > (Rod Johnson left Pivotal, Pivotal in its current form does not even seem > JCP member and VMware may not be able or interested to step in for them) > maybe Pete knows best if Bob was, as until JSR 364 or even a new version of > the JSPA are finalized he could probably do it if he wants and has the time > for this right now (especially if another JSR like CDI 2 depends on it, > that can't be delayed even if this JSR may technically still be unaffected > by JCP 2.8+) > >>> > >>> > >>>Except for active corporate members Oracle, Red Hat or IBM the whole EG > practically disintegrated. Doug Lea and Tim Peirls may be involved > elsewhere (mostly OpenJDK from all I heard) but they have not been active > in the JCP or active JSRs recently. Google, we heard gave up the Spec Lead > in the first place, so it is unlikely under the current circumstances it > will play an active role. Jason VanZyl and Maven I know they at least use > JSR 330 quite a bit, so they should at least be interested in its future > direction. Thoughtworks I don't recall them to be involved and Martin > Fowler himself told me of his "allergy" against such form of > standardization, so I would not count on them here either. > >>> > >>> > >>>So assuming a separate @Inject spec shall be maintained there are 3 > options: > >>> 1. Bob Lee (or the other Spec Lead) responds in a timely manner to > contact attempts by Antoine and ultimately the PMO (who needs to handle > such situations) in which case a simple MR was possible > >>> 2. A replacement of Maintenance Lead, along the lines of > https://jcp.org/ja/introduction/faq-speclead#slresigns (it is rarely the > case for an MR, but should work pretty much the same way here, so the main > candidates to replace a Spec Lead would be in that EG, hence Red Hat, IBM > or Oracle for most part;-) If such condition can't be resolved, both PMO > and JCP EC would be able to help find a suitable replacement, too > >>> 3. A whole new JSR is filed. Although it is often the case that the > Spec Lead(s) are the same, that is not necessary, especially if the old > ones moved on or can't do this any more right now. > >>>HTH, > >>>Werner > >>> > >>> > >>> > >>> > >>>On Thu, Jul 3, 2014 at 5:00 PM, Kito Mann > wrote: > >>> > >>>My $0.02 is that it's worth the effort to evolve JSR-330 for the > community as a whole. I've been on projects where they tend to use those > annotations even in a CDI environment, and it makes it much easier to > switch between Spring and CDI if necessary. > >>>> > >>>> > >>>> > >>>>On Wed, Jul 2, 2014 at 4:43 PM, Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > >>>> > >>>>Hi all, > >>>>> > >>>>>Since the first mention of CDI 2.0 preparation work, we've received a > lot of comment about JSR 330 evolution. With the release of the proposal > draft yesterday, this topic came up again. So let me give my point of view > on this subject to have an open discussion here. > >>>>> > >>>>>When we started to discuss about modularity with Pete in last > november, my first idea was to go see what we could add in JSR 330 to make > it a true specification that could be the first module of CDI. My idea at > that time was to discuss with JSR 330 owner to see if we could bring basic > concept we have in CDI to AtInject spec. In my mind the main features would > have been: > >>>>> - Enhance the javax.inject.Provider interface to bring it at the > same level than javax.enterprise.inject.Instance. That would have > included support for AnnotationLiteral and TypeLiteral as well > >>>>> - Add a Container interface (a very light BeanManger) in JSR 330 to > be able to resolve beans instance from outside managed beans > >>>>> - Add a mechanism to get this Container from non managed beans (like > we get access to BeanManager from JNDI or CDI class) > >>>>> > >>>>>At that time, I contacted Bob Lee without success (didn?t tried > Pivotal since I don?t have contact there). I checked with JCP what could be > done if we?d like to see an evolution of JSR 330 and the owner doesn?t > care, there seems to have solutions but I let it aside since we were in the > middle of CDI 1.2 MR at that time. > >>>>> > >>>>>Today I?m a bit torn about this point. Working on opening JSR 330 > could be like opening pandora box, since I see 2 scenarios : > >>>>> > >>>>>1) former JSR 330 owners wake up and are ok to get for a new spec > version they lead: > >>>>>Knowing the history of JSR 330 vs JSR 299 I?m not sure everything > we?d need would be heard and even if the people leading this would be > cooperative, a lot of discussion and negotiation would be needed to be sure > that this new AtInject wouldn?t contain features incompatible with CDI. So > it?d be very time consuming with no guarantee to get what we?d need at the > end. > >>>>> > >>>>>2) former JSR 330 owner don?t mind others take ownership of their > spec to enhance it and we (Red Hat) are the one to take this ownership to > secure CDI: > >>>>>The best solution to minimize risk. But leading a new specification > is a lot more work than just deciding that we have a specific basic inject > ? part ? in CDI 2.0. Leading a spec is very time consuming, so it could be > better on the paper but will impact CDI 2.0 new features. > >>>>> > >>>>>To sum up, as a Java EE user (like I have been for 10 years) I?d be > happy to see this (scenario 2), but as CDI spec lead I fear that it could > lead us in a trap (going to scenario 1 or consuming precious time on > AtInject+1 instead of CDI 2.0) > >>>>> > >>>>>Your input, solutions or comment would be appreciated on this point. > >>>>> > >>>>>Antoine > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>_______________________________________________ > >>>>>cdi-dev mailing list > >>>>>cdi-dev at lists.jboss.org > >>>>>https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>>> > >>>> > >>> > >>> > >>>_______________________________________________ > >>>cdi-dev mailing list > >>>cdi-dev at lists.jboss.org > >>>https://lists.jboss.org/mailman/listinfo/cdi-dev > >>> > >>> > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140703/efd6ba2c/attachment-0001.html From struberg at yahoo.de Thu Jul 3 18:01:42 2014 From: struberg at yahoo.de (Mark Struberg) Date: Thu, 3 Jul 2014 23:01:42 +0100 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: References: <1404410440.24522.YahooMailNeo@web28903.mail.ir2.yahoo.com> <1404420433.77837.YahooMailNeo@web28901.mail.ir2.yahoo.com> Message-ID: <1404424902.51995.YahooMailNeo@web28902.mail.ir2.yahoo.com> Werner, maybe we can talk this over at a beer? It seems evident that our different legal view points are way too far apart for sorting this out via email? As an example I just like to quote from the respective JSP [1]: "The Spec Lead will provide the EC with confirmation of the terms under which the RI and TCK will be licensed at each review period." The JSPA does not define _the_ license. It just defines that the EG must pick a propriat one. Also it's really established thinking that basically ALL what counts are the license headers in the respective source files. And the JavaDoc only being a 'secondary byproduct'. This is nothing I did define and neither did Oracle - this is established IP right. If Oracle lawyers see this different then I would be really worried. LieGrue, strub [1] https://jcp.org/en/procedures/jcp2_7 On Thursday, 3 July 2014, 23:17, Werner Keil wrote: > > >Most of this remains to be discussed by a dedicated IP WG of JSR 358. Which I ocasionally join and if you (or others here) have particular interest, transparency means pretty much everything, especially minutes, etc. is available also to those outside the WG or EC. > > > >On Thu, Jul 3, 2014 at 10:47 PM, Mark Struberg wrote: > >Hi! >> >> >> >>> The "Spec" and its Software Manifestation (normally all artifacts >> >>> under "javax.something" or "java.something" (for the few JSRs >> >>> like 310 that changed their package name in the course of >> >>> the lifecycle) in Oracle's (the PMO) understanding is under >> >>> the Spec License. >> >> >>Werner, this might be Oracles understanding, but to me and many legally trained colleagues it still seems factually wrong from a purely legal aspect. >> >>If I write something under ALv2 and contribute it to the JCP under ALv2, then no one (but me) has the right to change this license without asking me. Not even Oracle. Also the JSPA only talks about sublicensing (which does NOT include re-licensing under a different license!) and even explicitly says 'same license'. It does _not_ say _which_ license, it only defines (in ?5E) "terms and conditions that are non-discriminatory, fair and reasonable". >> >> >>It surely does not allow Sun/Oracle to re-license the original ALv2 work of JSR-330 (and other specs) with any other license. And it also doesn't matter what Oracle defines as 'Spec'. The important legal definition is the term 'work' which is used throughout almost all OSS licenses. And if Oracle provides a download with a zip which only contains ALv2 licensed 'work', then it also must prompt this license on their download page - and not any other license which no single piece of the downloaded archive is licensed under. You can check Androids 'system config -> licenses' page to see how this is done ;)? >> >> > > >JSR 330 Spec was never ALv2 licensed, see >The RI and TCK will be licensed under the Apache 2 license, and the Specification will be licensed under an agreement that satisfies the requirements of the JSPA. > > > >under?https://jcp.org/en/jsr/detail?id=330 >? >The "agreement that satisfies the requirements of the JSPA" is the Spec License.? > > > >>If you find such a paragraph which would allow such a re-licensing then please tell me. >> >> > > >There isn't any, again, Oracle has never said there would be any other license than the Spec License for these materials, even if you download "jsr XXX.jar" from a different place other than jcp.org. >? > >>Oracle would have had to refuse that spec and force the EG to pick another one. But now this is too late. This ship has pretty much sailed. Changing or 'reinterpreting' this work as under some different license is simply breaking a law. >> >> >> >>>Just see Java EE 7: http://docs.oracle.com/javaee/7/api/ >> >>> the JavaDoc (for all JSRs within that umbrella) >> >>> is therefore covered by the EE 7 Spec License >>>>Copyright ? 1996-2013, Oracle and/or its affiliates. >> >>> All Rights Reserved. Use is subject to license terms. >> >>Which is again factually wrong imo! >> >>I can also copy random files from the internet and claim that I own all the copyrights. >>It gets a bit more complex when we go into the legal details. On the one hand JavaDoc is always more complicated as the 'work' of bringing it into a nice representation might constitute own Copyright. And this is also fine as ALv2 allows to add your own 'work' in any license you like. But (often misinterpreted even by lawyers) ALv2 does NOT allow re-licensing: the original work (the parts which were ALv2) are STILL ALv2. This is btw almost always the case - this is what eventual Contributor License Agreements are for... >> >>It might also be that the 'collection of work' creates an own originary copyright. Like a prose book might constitute own IP _in addition_ to the original IP. But this 'collection IP' doesn't change the 'meat' content of javax.inject for example as explained above. >> >> >> >>>CDI refrains from this breach. At least there is no contradicting JavaDoc license pointer. >> >> >>Again wrong: https://github.com/cdi-spec/cdi/blob/master/api/src/main/java/javax/enterprise/inject/spi/BeanManager.java >>Clearly ALv2... >>And Oracle also cannot force JBoss to amend or change this license easily. JBoss would have to go to EVERY contributor and ask for permission! >> >> >> > > >The license headers in Java files are irrelevant in reality, and nobody (especially not the EC or PMO) cares about them. They are interested in a single license text provided with the JCP page, and again, for CDI you'll find the same as for JSR 330 or others.. > > >Even in the IP savvy circles, people tend to mix up what's "Spec/API" and what's "RI/TCK". IMHO the likes of JSR 107 got this pretty right, also 354 and a few others.? >Look into each class if you want and you'll find a pointer to the Spec License or a short version.? > > >The API is often ignored or misunderstood, but the JSPA is pretty clear about it, though it was phrased with strong emphasis on the JVM itself: > > >1.10 Java Specification (Specification or Spec): a written specification for some aspect of the Java technology. >This includes the language, virtual machine, Platform Editions, Profiles, andapplication programming >interfaces. >https://jcp.org/aboutJava/communityprocess/JSPA2.pdf > > > >I assume almost every one of you here signed it, or had your HR/legal department do;-) > > >"application programming interfaces" - API meaning, the JSPA considers them to be part of the Spec under the subsequent license, but the sentence is so vague, that I'm sure, you'll find 3 different oppinions or interpretations if you just ask enough lawyers;-) > > > >>Btw, I've talked with a few lawyers who reviewed ULA and they did all not sound happy about it... >> >> >> >>I also got a bunch of weird answers from Oracle lawyers, e.g. that we must not do a RI which is ALv2, EPL, OSGI, etc because 'they are not compatible with the licenses we use in Glassfish'. >>Totally sick argument. If that would be true than Oracle would need to remove 50 jars from Glassfish4, including >>* Weld >>* Eclipselink >>* all OSGi >>* Tomcat (yes, core-web.jar is nothing but a repackaged tomcat) >> >>* JNDI (org.apache.naming) >>to just name a few. >> >> >>Would this make sense? Do we really like to go down this route? >> >> >>To make it clear: Glassfish is dual licensed as CDDL and GPL+CPE. And exactly the ClassPathException is the case why EPL and ALv2 jars inside Glassfish are totally fine and this legal info we got from Oracle legal is imo nuts. >> >> >> > > >Look into OpenJDK and especially the whole of the (additional) java.time APIs contain BSD licensed material, despite the fact, that JDK as such is licensed under different agreements. I asked the people in the EC and IP WG discussing these things, and only Azul (not a lawyer but also caring a lot about IP) said their understanding was, it should be OK for "Non EG Members" to contribute this under BSD, but EG Members should have contributed all of that either under the Spec License or the one by OpenJDK. None of the classes in question seem to ever have been touched by anybody other than the Spec Leads as there was no other contribution when 310 was still in places like GitHub or SF.net. > > >? > >>I know there is tons of legal b******t going round these days. But repeating it over and over again doesn't make it more true... >> >>If you think I have an error in my argumentation then please feel free to correct me and help me understand the problem. >> >> >> > > >I think I'd have to leave that to people in the IP circles or legal team of either Oracle, IBM, Red Hat or others, as soon as they find a common understanding about it;-D >? >LieGrue, >>strub >> >> >> >> > > >Cheers, >Werner >? > >>On Thursday, 3 July 2014, 20:33, Werner Keil wrote: >>>I must correct you in the sense, that the license (that "Accept and Download" page) for the Spec is not Apache, though there is practically no spec here for these 6 annotations. >>>So it is a bit of a grey zone, and even EC Members with a large legal department are in ongoing discussions over that. The "Spec" and its Software Manifestation (normally all artifacts under "javax.something" or "java.something" (for the few JSRs like 310 that changed their package name in the course of the lifecycle) in Oracle's (the PMO) understanding is under the Spec License.? >>> >>> >>>So strictly speaking annotations under "javax.inject" are the "Spec", not RI or TCK, and therefore they don't fall under Apache 2. Google Guice and the TCK did and still do. >>> >>> >>>Looking at JSRs like 107?https://github.com/jsr107/jsr107spec or 354, you'll notice they all have this in common.? >>>Especially the JavaDoc as manifestation of the ?Spec (and for 330 that is all there is of a Spec) therefore naturally fall under the Spec License, too.? >>> >>> >>>Just see Java EE 7:?http://docs.oracle.com/javaee/7/api/ the JavaDoc (for all JSRs within that umbrella) is therefore covered by the EE 7 Spec License >>>>Copyright ? 1996-2013,?Oracle?and/or its affiliates. All Rights Reserved. Use is subject to?license terms. >>> >>>see the link under "license terms" >>> >>> >>>JSR 352 poses a stubbern dilemma as its EG and Spec Leads insist on a different license footer in the standalone distribution (Apache 2) as in the overall Java EE 7 umbrella. >>>Which is a nightmare for users, a reason I voted against the MR or abstained from this particular JSR as it denies what is reality at least for the Spec and artifacts like the JavaDoc. >>> >>> >>>CDI refrains from this breach. At least there is no contradicting JavaDoc license pointer.? >>> >>> >>>Red Hat considers a "Dual Licensing" option for the Spec, but from all I heard so far, this is not how Oracle and the JCP PMO (or at least Oracle's lawyers) see this.?With the proposal of the ULA Oracle tries to get all future JSRs to use a single license for RI and TCK. >>> >>> >>>There's an ongoing discussion over details, but unless Oracle's legal department and PMO make a dramatic turn on these matters, JSRs filed in the near future (including CDI 2 or beyond) would likely fall under Spec and ULA license. >>> >>> >>>Cheers, >>>Werner >>> >>> >>>On Thu, Jul 3, 2014 at 8:00 PM, Mark Struberg wrote: >>> >>>As far as I know the history (and I have been tracking and contributing to JSR-330 back then) most of the people were fed up _because_ they got pushed to change the license from ALv2 to something else (cannot remember anymore what exactly). >>>> >>>> >>>>The original Apache v2 licensed work can be found here: >>>>https://code.google.com/p/atinject/ >>>> >>>> >>>> >>>>I have no clue why Oracle ?added the 'accept license' radio button on their JSR-330 download page. Maybe just a copy&paste error? The text in this license window is in fact not ALv2 but something else which is wrong information at best.? >>>> >>>> >>>>The good news: ALL the assets in JSR-330 still are ALv2! >>>>Thus anyone can take it and enhance it.? >>>>Of course it would be good to have Bob and J?rgen on board, but legally it might not even be necessary. >>>> >>>> >>>>LieGrue, >>>>strub >>>> >>>> >>>> >>>> >>>> >>>>On Thursday, 3 July 2014, 17:35, Werner Keil wrote: >>>> >>>> >>>>> >>>>> >>>>>I guess with only 5 or 6 annotations (and that's all the JSR consists of;-) if changing/improving only one or two of these was what's needed, this could be easiest as MR, otherwise 330 is history as it would require a new JSR. JSR 330 was under JCP 2.7 and for final JSRs they normally stay there, I don't think it can move to a newer version of the JCP:?https://jcp.org/en/resources/guide-maintenance#2_7 >>>>> >>>>> >>>>> >>>>>The trouble is, both Spec Leads seem unresponsive or no longer around (Rod Johnson left Pivotal, Pivotal in its current form does not even seem JCP member and VMware may not be able or interested to step in for them) maybe Pete knows best if Bob was, as until JSR 364 or even a new version of the JSPA are finalized he could probably do it if he wants and has the time for this right now (especially if another JSR like CDI 2 depends on it, that can't be delayed even if this JSR may technically still be unaffected by JCP 2.8+)? >>>>> >>>>> >>>>>Except for active corporate members Oracle, Red Hat or IBM the whole EG practically disintegrated. Doug Lea and Tim Peirls may be involved elsewhere (mostly OpenJDK from all I heard) but they have not been active in the JCP or active JSRs recently. Google, we heard gave up the Spec Lead in the first place, so it is unlikely under the current circumstances it will play an active role. Jason VanZyl and Maven I know they at least use JSR 330 quite a bit, so they should at least be interested in its future direction. Thoughtworks I don't recall them to be involved and Martin Fowler himself told me of his "allergy" against such form of standardization, so I would not count on them here either. >>>>> >>>>> >>>>>So assuming a separate @Inject spec shall be maintained there are 3 options: >>>>>????1. Bob Lee (or the other Spec Lead) responds in a timely manner to contact attempts by Antoine and ultimately the PMO (who needs to handle such situations) in which case a simple MR was possible >>>>>????2. A replacement of Maintenance Lead, along the lines of?https://jcp.org/ja/introduction/faq-speclead#slresigns?(it is rarely the case for an MR, but should work pretty much the same way here, so the main candidates to replace a Spec Lead would be in that EG, hence Red Hat, IBM or Oracle for most part;-) If such condition can't be resolved, both PMO and JCP EC would be able to help find a suitable replacement, too >>>>>????3. A whole new JSR is filed. Although it is often the case that the Spec Lead(s) are the same, that is not necessary, especially if the old ones moved on or can't do this any more right now. >> >>>>>HTH, >>>>>Werner >>>>> >>>>> >>>>> >>>>> >>>>>On Thu, Jul 3, 2014 at 5:00 PM, Kito Mann wrote: >>>>> >>>>>My $0.02 is that it's worth the effort to evolve JSR-330 for the community as a whole. I've been on projects where they tend to use those annotations even in a CDI environment, and it makes it much easier to switch between Spring and CDI if necessary. >>>>>> >>>>>> >>>>>> >>>>>>On Wed, Jul 2, 2014 at 4:43 PM, Antoine Sabot-Durand wrote: >>>>>> >>>>>>Hi all, >>>>>>> >>>>>>>Since the first mention of CDI 2.0 preparation work, we've received a lot of comment about JSR 330 evolution. With the release of the proposal draft yesterday, this topic came up again. So let me give my point of view on this subject to have an open discussion here. >>>>>>> >>>>>>>When we started to discuss about modularity with Pete in last november, my first idea was to go see what we could add in JSR 330 to make it a true specification that could be the first module of CDI. My idea at that time was to discuss with JSR 330 owner to see if we could bring basic concept we have in CDI to AtInject spec. In my mind the main features would have been: >>>>>>>?- Enhance the javax.inject.Provider interface to bring it at the same level than javax.enterprise.inject.Instance. That would have included support for AnnotationLiteral and TypeLiteral as well >>>>>>>?- Add a Container interface (a very light BeanManger) in JSR 330 to be able to resolve beans instance from outside managed beans >>>>>>>?- Add a mechanism to get this Container from non managed beans (like we get access to BeanManager from JNDI or CDI class) >>>>>>> >>>>>>>At that time, I contacted Bob Lee without success (didn?t tried Pivotal since I don?t have contact there). I checked with JCP what could be done if we?d like to see an evolution of JSR 330 and the owner doesn?t care, there seems to have solutions but I let it aside since we were in the middle of CDI 1.2 MR at that time. >>>>>>> >>>>>>>Today I?m a bit torn about this point. Working on opening JSR 330 could be like opening pandora box, since I see 2 scenarios : >>>>>>> >>>>>>>1) former JSR 330 owners wake up and are ok to get for a new spec version they lead: >>>>>>>Knowing the history of JSR 330 vs JSR 299 I?m not sure everything we?d need would be heard and even if the people leading this would be cooperative, a lot of discussion and negotiation would be needed to be sure that this new AtInject wouldn?t contain features incompatible with CDI. So it?d be very time consuming with no guarantee to get what we?d need at the end. >>>>>>> >>>>>>>2) former JSR 330 owner don?t mind others take ownership of their spec to enhance it and we (Red Hat) are the one to take this ownership to secure CDI: >>>>>>>The best solution to minimize risk. But leading a new specification is a lot more work than just deciding that we have a specific basic inject ? part ? in ?CDI 2.0. Leading a spec is very time consuming, so it could be better on the paper but will impact CDI 2.0 new features. >>>>>>> >>>>>>>To sum up, as a Java EE user (like I have been for 10 years) I?d be happy to see this (scenario 2), but as CDI spec lead I fear that it could lead us in a trap (going to scenario 1 or consuming precious time on AtInject+1 instead of CDI 2.0) >>>>>>> >>>>>>>Your input, solutions or comment would be appreciated on this point. >>>>>>> >>>>>>>Antoine >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>_______________________________________________ >>>>>>>cdi-dev mailing list >>>>>>>cdi-dev at lists.jboss.org >>>>>>>https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>> >>>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>cdi-dev mailing list >>>>>cdi-dev at lists.jboss.org >>>>>https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>> >>> >>> >>> >> > > > > From werner.keil at gmail.com Thu Jul 3 18:33:21 2014 From: werner.keil at gmail.com (Werner Keil) Date: Fri, 4 Jul 2014 00:33:21 +0200 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: <1404424902.51995.YahooMailNeo@web28902.mail.ir2.yahoo.com> References: <1404410440.24522.YahooMailNeo@web28903.mail.ir2.yahoo.com> <1404420433.77837.YahooMailNeo@web28901.mail.ir2.yahoo.com> <1404424902.51995.YahooMailNeo@web28902.mail.ir2.yahoo.com> Message-ID: Mark, I am in Vienna briefly for tomorrow's DemoCamp. Not sure, if you'll have time at such short notice, but feel free to come by tomorrow;-) It's far from "my legal understanding", but as only Individual Member who has been in the EC for some time now from "Sun" days to a "transition" phase if you want or time of inactivity till today, I am among those who need to attend meetings and other responsibilities myself, as there is no "deputy" or "proxy" for Individual Members;-) The JSPA itself does not describe the license, but for the Spec there is only one license, see https://jcp.org/ja/resources/license_reference. The "choice" (also a bit outdated, but Apache was there already) is for RI/TCK, for the Spec it says "the PMO will help" and there's even the notion of "your own license". That has mostly been applied to J2ME licenses, with the effect, that some JSRs including the old Sensor API for J2ME (JSR 256, which a few "requirements" apply to JSR 363, but we certainly won't use anything else) had license constructions so complicated and weird, even Oracle's own lawyers did not want to go there and simply abandoned such JSRs not just from a technical point of view;-D I won't name anybody, but there are several fellow EC members who openly admit, "looking at the code" is not their priority, so I think that answers your question if the LICENCE.txt and license cover page of a Spec document matters to them or license headers in source files?;-) Cheers, Werner On Fri, Jul 4, 2014 at 12:01 AM, Mark Struberg wrote: > Werner, maybe we can talk this over at a beer? It seems evident that our > different legal view points are way too far apart for sorting this out via > email? > > As an example I just like to quote from the respective JSP [1]: > "The Spec Lead will provide the EC with confirmation of the terms under > which the RI and TCK will be licensed at each review period." > > The JSPA does not define _the_ license. It just defines that the EG must > pick a propriat one. > > > Also it's really established thinking that basically ALL what counts are > the license headers in the respective source files. And the JavaDoc only > being a 'secondary byproduct'. This is nothing I did define and neither did > Oracle - this is established IP right. If Oracle lawyers see this different > then I would be really worried. > > > > LieGrue, > strub > > > > [1] https://jcp.org/en/procedures/jcp2_7 > > > > > > On Thursday, 3 July 2014, 23:17, Werner Keil > wrote: > > > > > > > >Most of this remains to be discussed by a dedicated IP WG of JSR 358. > Which I ocasionally join and if you (or others here) have particular > interest, transparency means pretty much everything, especially minutes, > etc. is available also to those outside the WG or EC. > > > > > > > >On Thu, Jul 3, 2014 at 10:47 PM, Mark Struberg wrote: > > > >Hi! > >> > >> > >> > >>> The "Spec" and its Software Manifestation (normally all artifacts > >> > >>> under "javax.something" or "java.something" (for the few JSRs > >> > >>> like 310 that changed their package name in the course of > >> > >>> the lifecycle) in Oracle's (the PMO) understanding is under > >> > >>> the Spec License. > >> > >> > >>Werner, this might be Oracles understanding, but to me and many legally > trained colleagues it still seems factually wrong from a purely legal > aspect. > >> > >>If I write something under ALv2 and contribute it to the JCP under ALv2, > then no one (but me) has the right to change this license without asking > me. Not even Oracle. Also the JSPA only talks about sublicensing (which > does NOT include re-licensing under a different license!) and even > explicitly says 'same license'. It does _not_ say _which_ license, it only > defines (in ?5E) "terms and conditions that are non-discriminatory, fair > and reasonable". > >> > >> > >>It surely does not allow Sun/Oracle to re-license the original ALv2 work > of JSR-330 (and other specs) with any other license. And it also doesn't > matter what Oracle defines as 'Spec'. The important legal definition is the > term 'work' which is used throughout almost all OSS licenses. And if Oracle > provides a download with a zip which only contains ALv2 licensed 'work', > then it also must prompt this license on their download page - and not any > other license which no single piece of the downloaded archive is licensed > under. You can check Androids 'system config -> licenses' page to see how > this is done ;) > >> > >> > > > > > >JSR 330 Spec was never ALv2 licensed, see > >The RI and TCK will be licensed under the Apache 2 license, and the > Specification will be licensed under an agreement that satisfies the > requirements of the JSPA. > > > > > > > >under https://jcp.org/en/jsr/detail?id=330 > > > >The "agreement that satisfies the requirements of the JSPA" is the Spec > License. > > > > > > > >>If you find such a paragraph which would allow such a re-licensing then > please tell me. > >> > >> > > > > > >There isn't any, again, Oracle has never said there would be any other > license than the Spec License for these materials, even if you download > "jsr XXX.jar" from a different place other than jcp.org. > > > > > >>Oracle would have had to refuse that spec and force the EG to pick > another one. But now this is too late. This ship has pretty much sailed. > Changing or 'reinterpreting' this work as under some different license is > simply breaking a law. > >> > >> > >> > >>>Just see Java EE 7: http://docs.oracle.com/javaee/7/api/ > >> > >>> the JavaDoc (for all JSRs within that umbrella) > >> > >>> is therefore covered by the EE 7 Spec License > >>>>Copyright ? 1996-2013, Oracle and/or its affiliates. > >> > >>> All Rights Reserved. Use is subject to license terms. > >> > >>Which is again factually wrong imo! > >> > >>I can also copy random files from the internet and claim that I own all > the copyrights. > >>It gets a bit more complex when we go into the legal details. On the one > hand JavaDoc is always more complicated as the 'work' of bringing it into a > nice representation might constitute own Copyright. And this is also fine > as ALv2 allows to add your own 'work' in any license you like. But (often > misinterpreted even by lawyers) ALv2 does NOT allow re-licensing: the > original work (the parts which were ALv2) are STILL ALv2. This is btw > almost always the case - this is what eventual Contributor License > Agreements are for... > >> > >>It might also be that the 'collection of work' creates an own originary > copyright. Like a prose book might constitute own IP _in addition_ to the > original IP. But this 'collection IP' doesn't change the 'meat' content of > javax.inject for example as explained above. > >> > >> > >> > >>>CDI refrains from this breach. At least there is no contradicting > JavaDoc license pointer. > >> > >> > >>Again wrong: > https://github.com/cdi-spec/cdi/blob/master/api/src/main/java/javax/enterprise/inject/spi/BeanManager.java > >>Clearly ALv2... > >>And Oracle also cannot force JBoss to amend or change this license > easily. JBoss would have to go to EVERY contributor and ask for permission! > >> > >> > >> > > > > > >The license headers in Java files are irrelevant in reality, and nobody > (especially not the EC or PMO) cares about them. They are interested in a > single license text provided with the JCP page, and again, for CDI you'll > find the same as for JSR 330 or others.. > > > > > >Even in the IP savvy circles, people tend to mix up what's "Spec/API" and > what's "RI/TCK". IMHO the likes of JSR 107 got this pretty right, also 354 > and a few others. > >Look into each class if you want and you'll find a pointer to the Spec > License or a short version. > > > > > >The API is often ignored or misunderstood, but the JSPA is pretty clear > about it, though it was phrased with strong emphasis on the JVM itself: > > > > > >1.10 Java Specification (Specification or Spec): a written specification > for some aspect of the Java technology. > >This includes the language, virtual machine, Platform Editions, Profiles, > andapplication programming > >interfaces. > >https://jcp.org/aboutJava/communityprocess/JSPA2.pdf > > > > > > > >I assume almost every one of you here signed it, or had your HR/legal > department do;-) > > > > > >"application programming interfaces" - API meaning, the JSPA considers > them to be part of the Spec under the subsequent license, but the sentence > is so vague, that I'm sure, you'll find 3 different oppinions or > interpretations if you just ask enough lawyers;-) > > > > > > > >>Btw, I've talked with a few lawyers who reviewed ULA and they did all > not sound happy about it... > >> > >> > >> > >>I also got a bunch of weird answers from Oracle lawyers, e.g. that we > must not do a RI which is ALv2, EPL, OSGI, etc because 'they are not > compatible with the licenses we use in Glassfish'. > >>Totally sick argument. If that would be true than Oracle would need to > remove 50 jars from Glassfish4, including > >>* Weld > >>* Eclipselink > >>* all OSGi > >>* Tomcat (yes, core-web.jar is nothing but a repackaged tomcat) > >> > >>* JNDI (org.apache.naming) > >>to just name a few. > >> > >> > >>Would this make sense? Do we really like to go down this route? > >> > >> > >>To make it clear: Glassfish is dual licensed as CDDL and GPL+CPE. And > exactly the ClassPathException is the case why EPL and ALv2 jars inside > Glassfish are totally fine and this legal info we got from Oracle legal is > imo nuts. > >> > >> > >> > > > > > >Look into OpenJDK and especially the whole of the (additional) java.time > APIs contain BSD licensed material, despite the fact, that JDK as such is > licensed under different agreements. I asked the people in the EC and IP WG > discussing these things, and only Azul (not a lawyer but also caring a lot > about IP) said their understanding was, it should be OK for "Non EG > Members" to contribute this under BSD, but EG Members should have > contributed all of that either under the Spec License or the one by > OpenJDK. None of the classes in question seem to ever have been touched by > anybody other than the Spec Leads as there was no other contribution when > 310 was still in places like GitHub or SF.net. > > > > > > > > > >>I know there is tons of legal b******t going round these days. But > repeating it over and over again doesn't make it more true... > >> > >>If you think I have an error in my argumentation then please feel free > to correct me and help me understand the problem. > >> > >> > >> > > > > > >I think I'd have to leave that to people in the IP circles or legal team > of either Oracle, IBM, Red Hat or others, as soon as they find a common > understanding about it;-D > > > >LieGrue, > >>strub > >> > >> > >> > >> > > > > > >Cheers, > >Werner > > > > > >>On Thursday, 3 July 2014, 20:33, Werner Keil > wrote: > >>>I must correct you in the sense, that the license (that "Accept and > Download" page) for the Spec is not Apache, though there is practically no > spec here for these 6 annotations. > >>>So it is a bit of a grey zone, and even EC Members with a large legal > department are in ongoing discussions over that. The "Spec" and its > Software Manifestation (normally all artifacts under "javax.something" or > "java.something" (for the few JSRs like 310 that changed their package name > in the course of the lifecycle) in Oracle's (the PMO) understanding is > under the Spec License. > >>> > >>> > >>>So strictly speaking annotations under "javax.inject" are the "Spec", > not RI or TCK, and therefore they don't fall under Apache 2. Google Guice > and the TCK did and still do. > >>> > >>> > >>>Looking at JSRs like 107 https://github.com/jsr107/jsr107spec or 354, > you'll notice they all have this in common. > >>>Especially the JavaDoc as manifestation of the Spec (and for 330 that > is all there is of a Spec) therefore naturally fall under the Spec License, > too. > >>> > >>> > >>>Just see Java EE 7: http://docs.oracle.com/javaee/7/api/ the JavaDoc > (for all JSRs within that umbrella) is therefore covered by the EE 7 Spec > License > >>>>Copyright ? 1996-2013, Oracle and/or its affiliates. All Rights > Reserved. Use is subject to license terms. > >>> > >>>see the link under "license terms" > >>> > >>> > >>>JSR 352 poses a stubbern dilemma as its EG and Spec Leads insist on a > different license footer in the standalone distribution (Apache 2) as in > the overall Java EE 7 umbrella. > >>>Which is a nightmare for users, a reason I voted against the MR or > abstained from this particular JSR as it denies what is reality at least > for the Spec and artifacts like the JavaDoc. > >>> > >>> > >>>CDI refrains from this breach. At least there is no contradicting > JavaDoc license pointer. > >>> > >>> > >>>Red Hat considers a "Dual Licensing" option for the Spec, but from all > I heard so far, this is not how Oracle and the JCP PMO (or at least > Oracle's lawyers) see this. With the proposal of the ULA Oracle tries to > get all future JSRs to use a single license for RI and TCK. > >>> > >>> > >>>There's an ongoing discussion over details, but unless Oracle's legal > department and PMO make a dramatic turn on these matters, JSRs filed in the > near future (including CDI 2 or beyond) would likely fall under Spec and > ULA license. > >>> > >>> > >>>Cheers, > >>>Werner > >>> > >>> > >>>On Thu, Jul 3, 2014 at 8:00 PM, Mark Struberg > wrote: > >>> > >>>As far as I know the history (and I have been tracking and contributing > to JSR-330 back then) most of the people were fed up _because_ they got > pushed to change the license from ALv2 to something else (cannot remember > anymore what exactly). > >>>> > >>>> > >>>>The original Apache v2 licensed work can be found here: > >>>>https://code.google.com/p/atinject/ > >>>> > >>>> > >>>> > >>>>I have no clue why Oracle added the 'accept license' radio button on > their JSR-330 download page. Maybe just a copy&paste error? The text in > this license window is in fact not ALv2 but something else which is wrong > information at best. > >>>> > >>>> > >>>>The good news: ALL the assets in JSR-330 still are ALv2! > >>>>Thus anyone can take it and enhance it. > >>>>Of course it would be good to have Bob and J?rgen on board, but > legally it might not even be necessary. > >>>> > >>>> > >>>>LieGrue, > >>>>strub > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>On Thursday, 3 July 2014, 17:35, Werner Keil > wrote: > >>>> > >>>> > >>>>> > >>>>> > >>>>>I guess with only 5 or 6 annotations (and that's all the JSR consists > of;-) if changing/improving only one or two of these was what's needed, > this could be easiest as MR, otherwise 330 is history as it would require a > new JSR. JSR 330 was under JCP 2.7 and for final JSRs they normally stay > there, I don't think it can move to a newer version of the JCP: > https://jcp.org/en/resources/guide-maintenance#2_7 > >>>>> > >>>>> > >>>>> > >>>>>The trouble is, both Spec Leads seem unresponsive or no longer around > (Rod Johnson left Pivotal, Pivotal in its current form does not even seem > JCP member and VMware may not be able or interested to step in for them) > maybe Pete knows best if Bob was, as until JSR 364 or even a new version of > the JSPA are finalized he could probably do it if he wants and has the time > for this right now (especially if another JSR like CDI 2 depends on it, > that can't be delayed even if this JSR may technically still be unaffected > by JCP 2.8+) > >>>>> > >>>>> > >>>>>Except for active corporate members Oracle, Red Hat or IBM the whole > EG practically disintegrated. Doug Lea and Tim Peirls may be involved > elsewhere (mostly OpenJDK from all I heard) but they have not been active > in the JCP or active JSRs recently. Google, we heard gave up the Spec Lead > in the first place, so it is unlikely under the current circumstances it > will play an active role. Jason VanZyl and Maven I know they at least use > JSR 330 quite a bit, so they should at least be interested in its future > direction. Thoughtworks I don't recall them to be involved and Martin > Fowler himself told me of his "allergy" against such form of > standardization, so I would not count on them here either. > >>>>> > >>>>> > >>>>>So assuming a separate @Inject spec shall be maintained there are 3 > options: > >>>>> 1. Bob Lee (or the other Spec Lead) responds in a timely manner > to contact attempts by Antoine and ultimately the PMO (who needs to handle > such situations) in which case a simple MR was possible > >>>>> 2. A replacement of Maintenance Lead, along the lines of > https://jcp.org/ja/introduction/faq-speclead#slresigns (it is rarely the > case for an MR, but should work pretty much the same way here, so the main > candidates to replace a Spec Lead would be in that EG, hence Red Hat, IBM > or Oracle for most part;-) If such condition can't be resolved, both PMO > and JCP EC would be able to help find a suitable replacement, too > >>>>> 3. A whole new JSR is filed. Although it is often the case that > the Spec Lead(s) are the same, that is not necessary, especially if the old > ones moved on or can't do this any more right now. > >> > >>>>>HTH, > >>>>>Werner > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>On Thu, Jul 3, 2014 at 5:00 PM, Kito Mann > wrote: > >>>>> > >>>>>My $0.02 is that it's worth the effort to evolve JSR-330 for the > community as a whole. I've been on projects where they tend to use those > annotations even in a CDI environment, and it makes it much easier to > switch between Spring and CDI if necessary. > >>>>>> > >>>>>> > >>>>>> > >>>>>>On Wed, Jul 2, 2014 at 4:43 PM, Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > >>>>>> > >>>>>>Hi all, > >>>>>>> > >>>>>>>Since the first mention of CDI 2.0 preparation work, we've received > a lot of comment about JSR 330 evolution. With the release of the proposal > draft yesterday, this topic came up again. So let me give my point of view > on this subject to have an open discussion here. > >>>>>>> > >>>>>>>When we started to discuss about modularity with Pete in last > november, my first idea was to go see what we could add in JSR 330 to make > it a true specification that could be the first module of CDI. My idea at > that time was to discuss with JSR 330 owner to see if we could bring basic > concept we have in CDI to AtInject spec. In my mind the main features would > have been: > >>>>>>> - Enhance the javax.inject.Provider interface to bring it at > the same level than javax.enterprise.inject.Instance. That would have > included support for AnnotationLiteral and TypeLiteral as well > >>>>>>> - Add a Container interface (a very light BeanManger) in JSR 330 > to be able to resolve beans instance from outside managed beans > >>>>>>> - Add a mechanism to get this Container from non managed beans > (like we get access to BeanManager from JNDI or CDI class) > >>>>>>> > >>>>>>>At that time, I contacted Bob Lee without success (didn?t tried > Pivotal since I don?t have contact there). I checked with JCP what could be > done if we?d like to see an evolution of JSR 330 and the owner doesn?t > care, there seems to have solutions but I let it aside since we were in the > middle of CDI 1.2 MR at that time. > >>>>>>> > >>>>>>>Today I?m a bit torn about this point. Working on opening JSR 330 > could be like opening pandora box, since I see 2 scenarios : > >>>>>>> > >>>>>>>1) former JSR 330 owners wake up and are ok to get for a new spec > version they lead: > >>>>>>>Knowing the history of JSR 330 vs JSR 299 I?m not sure everything > we?d need would be heard and even if the people leading this would be > cooperative, a lot of discussion and negotiation would be needed to be sure > that this new AtInject wouldn?t contain features incompatible with CDI. So > it?d be very time consuming with no guarantee to get what we?d need at the > end. > >>>>>>> > >>>>>>>2) former JSR 330 owner don?t mind others take ownership of their > spec to enhance it and we (Red Hat) are the one to take this ownership to > secure CDI: > >>>>>>>The best solution to minimize risk. But leading a new specification > is a lot more work than just deciding that we have a specific basic inject > ? part ? in CDI 2.0. Leading a spec is very time consuming, so it could be > better on the paper but will impact CDI 2.0 new features. > >>>>>>> > >>>>>>>To sum up, as a Java EE user (like I have been for 10 years) I?d be > happy to see this (scenario 2), but as CDI spec lead I fear that it could > lead us in a trap (going to scenario 1 or consuming precious time on > AtInject+1 instead of CDI 2.0) > >>>>>>> > >>>>>>>Your input, solutions or comment would be appreciated on this point. > >>>>>>> > >>>>>>>Antoine > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>_______________________________________________ > >>>>>>>cdi-dev mailing list > >>>>>>>cdi-dev at lists.jboss.org > >>>>>>>https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>>>_______________________________________________ > >>>>>cdi-dev mailing list > >>>>>cdi-dev at lists.jboss.org > >>>>>https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>>> > >>>>> > >>> > >>> > >>> > >> > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140704/e0f3e692/attachment-0001.html From werner.keil at gmail.com Thu Jul 3 18:46:13 2014 From: werner.keil at gmail.com (Werner Keil) Date: Fri, 4 Jul 2014 00:46:13 +0200 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: References: <1404410440.24522.YahooMailNeo@web28903.mail.ir2.yahoo.com> <1404420433.77837.YahooMailNeo@web28901.mail.ir2.yahoo.com> <1404424902.51995.YahooMailNeo@web28902.mail.ir2.yahoo.com> Message-ID: In a majority of cases, not just Oracle but also other vendors from a legal point still live and practice a "Shrinkwrap mindset", so the only license that counts is the one you see when you "open the box". Or download artifacts from JCP or a similar place. The problem is, in a "Service Oriented" "Cloud" world, you rarely use the file you can manually download in one place. I raised the issue a few times in places like the JCP.next trackers or mailing lists, but there is quite a backlog and for large corporate members often not looking at the code there are other priorities, e.g. defining that new RI/TCK license. Whether portions of the Open Source community is happy with the outcome remains to be seen, also what the result of the "API Patent Case" is, and what effect it could have on the industry and its players. If you wish to define a Spec and there is only one or two licenses to select from, you either have to pick one of them or contribute to something in a different form/place;-) Regards, Werner On Fri, Jul 4, 2014 at 12:33 AM, Werner Keil wrote: > Mark, > > I am in Vienna briefly for tomorrow's DemoCamp. Not sure, if you'll have > time at such short notice, but feel free to come by tomorrow;-) > > It's far from "my legal understanding", but as only Individual Member who > has been in the EC for some time now from "Sun" days to a "transition" > phase if you want or time of inactivity till today, I am among those who > need to attend meetings and other responsibilities myself, as there is no > "deputy" or "proxy" for Individual Members;-) > > The JSPA itself does not describe the license, but for the Spec there is > only one license, see https://jcp.org/ja/resources/license_reference. > The "choice" (also a bit outdated, but Apache was there already) is for > RI/TCK, for the Spec it says "the PMO will help" and there's even the > notion of "your own license". > That has mostly been applied to J2ME licenses, with the effect, that some > JSRs including the old Sensor API for J2ME (JSR 256, which a few > "requirements" apply to JSR 363, but we certainly won't use anything else) > had license constructions so complicated and weird, even Oracle's own > lawyers did not want to go there and simply abandoned such JSRs not just > from a technical point of view;-D > > I won't name anybody, but there are several fellow EC members who openly > admit, "looking at the code" is not their priority, so I think that answers > your question if the LICENCE.txt and license cover page of a Spec document > matters to them or license headers in source files?;-) > > Cheers, > Werner > > On Fri, Jul 4, 2014 at 12:01 AM, Mark Struberg wrote: > >> Werner, maybe we can talk this over at a beer? It seems evident that our >> different legal view points are way too far apart for sorting this out via >> email? >> >> As an example I just like to quote from the respective JSP [1]: >> "The Spec Lead will provide the EC with confirmation of the terms under >> which the RI and TCK will be licensed at each review period." >> >> The JSPA does not define _the_ license. It just defines that the EG must >> pick a propriat one. >> >> >> Also it's really established thinking that basically ALL what counts are >> the license headers in the respective source files. And the JavaDoc only >> being a 'secondary byproduct'. This is nothing I did define and neither did >> Oracle - this is established IP right. If Oracle lawyers see this different >> then I would be really worried. >> >> >> >> LieGrue, >> strub >> >> >> >> [1] https://jcp.org/en/procedures/jcp2_7 >> >> >> >> >> >> On Thursday, 3 July 2014, 23:17, Werner Keil >> wrote: >> >> >> > >> > >> >Most of this remains to be discussed by a dedicated IP WG of JSR 358. >> Which I ocasionally join and if you (or others here) have particular >> interest, transparency means pretty much everything, especially minutes, >> etc. is available also to those outside the WG or EC. >> > >> > >> > >> >On Thu, Jul 3, 2014 at 10:47 PM, Mark Struberg >> wrote: >> > >> >Hi! >> >> >> >> >> >> >> >>> The "Spec" and its Software Manifestation (normally all artifacts >> >> >> >>> under "javax.something" or "java.something" (for the few JSRs >> >> >> >>> like 310 that changed their package name in the course of >> >> >> >>> the lifecycle) in Oracle's (the PMO) understanding is under >> >> >> >>> the Spec License. >> >> >> >> >> >>Werner, this might be Oracles understanding, but to me and many legally >> trained colleagues it still seems factually wrong from a purely legal >> aspect. >> >> >> >>If I write something under ALv2 and contribute it to the JCP under >> ALv2, then no one (but me) has the right to change this license without >> asking me. Not even Oracle. Also the JSPA only talks about sublicensing >> (which does NOT include re-licensing under a different license!) and even >> explicitly says 'same license'. It does _not_ say _which_ license, it only >> defines (in ?5E) "terms and conditions that are non-discriminatory, fair >> and reasonable". >> >> >> >> >> >>It surely does not allow Sun/Oracle to re-license the original ALv2 >> work of JSR-330 (and other specs) with any other license. And it also >> doesn't matter what Oracle defines as 'Spec'. The important legal >> definition is the term 'work' which is used throughout almost all OSS >> licenses. And if Oracle provides a download with a zip which only contains >> ALv2 licensed 'work', then it also must prompt this license on their >> download page - and not any other license which no single piece of the >> downloaded archive is licensed under. You can check Androids 'system config >> -> licenses' page to see how this is done ;) >> >> >> >> >> > >> > >> >JSR 330 Spec was never ALv2 licensed, see >> >The RI and TCK will be licensed under the Apache 2 license, and the >> Specification will be licensed under an agreement that satisfies the >> requirements of the JSPA. >> > >> > >> > >> >under https://jcp.org/en/jsr/detail?id=330 >> > >> >The "agreement that satisfies the requirements of the JSPA" is the Spec >> License. >> > >> > >> > >> >>If you find such a paragraph which would allow such a re-licensing then >> please tell me. >> >> >> >> >> > >> > >> >There isn't any, again, Oracle has never said there would be any other >> license than the Spec License for these materials, even if you download >> "jsr XXX.jar" from a different place other than jcp.org. >> > >> > >> >>Oracle would have had to refuse that spec and force the EG to pick >> another one. But now this is too late. This ship has pretty much sailed. >> Changing or 'reinterpreting' this work as under some different license is >> simply breaking a law. >> >> >> >> >> >> >> >>>Just see Java EE 7: http://docs.oracle.com/javaee/7/api/ >> >> >> >>> the JavaDoc (for all JSRs within that umbrella) >> >> >> >>> is therefore covered by the EE 7 Spec License >> >>>>Copyright ? 1996-2013, Oracle and/or its affiliates. >> >> >> >>> All Rights Reserved. Use is subject to license terms. >> >> >> >>Which is again factually wrong imo! >> >> >> >>I can also copy random files from the internet and claim that I own all >> the copyrights. >> >>It gets a bit more complex when we go into the legal details. On the >> one hand JavaDoc is always more complicated as the 'work' of bringing it >> into a nice representation might constitute own Copyright. And this is also >> fine as ALv2 allows to add your own 'work' in any license you like. But >> (often misinterpreted even by lawyers) ALv2 does NOT allow re-licensing: >> the original work (the parts which were ALv2) are STILL ALv2. This is btw >> almost always the case - this is what eventual Contributor License >> Agreements are for... >> >> >> >>It might also be that the 'collection of work' creates an own originary >> copyright. Like a prose book might constitute own IP _in addition_ to the >> original IP. But this 'collection IP' doesn't change the 'meat' content of >> javax.inject for example as explained above. >> >> >> >> >> >> >> >>>CDI refrains from this breach. At least there is no contradicting >> JavaDoc license pointer. >> >> >> >> >> >>Again wrong: >> https://github.com/cdi-spec/cdi/blob/master/api/src/main/java/javax/enterprise/inject/spi/BeanManager.java >> >>Clearly ALv2... >> >>And Oracle also cannot force JBoss to amend or change this license >> easily. JBoss would have to go to EVERY contributor and ask for permission! >> >> >> >> >> >> >> > >> > >> >The license headers in Java files are irrelevant in reality, and nobody >> (especially not the EC or PMO) cares about them. They are interested in a >> single license text provided with the JCP page, and again, for CDI you'll >> find the same as for JSR 330 or others.. >> > >> > >> >Even in the IP savvy circles, people tend to mix up what's "Spec/API" >> and what's "RI/TCK". IMHO the likes of JSR 107 got this pretty right, also >> 354 and a few others. >> >Look into each class if you want and you'll find a pointer to the Spec >> License or a short version. >> > >> > >> >The API is often ignored or misunderstood, but the JSPA is pretty clear >> about it, though it was phrased with strong emphasis on the JVM itself: >> > >> > >> >1.10 Java Specification (Specification or Spec): a written specification >> for some aspect of the Java technology. >> >This includes the language, virtual machine, Platform Editions, >> Profiles, andapplication programming >> >interfaces. >> >https://jcp.org/aboutJava/communityprocess/JSPA2.pdf >> > >> > >> > >> >I assume almost every one of you here signed it, or had your HR/legal >> department do;-) >> > >> > >> >"application programming interfaces" - API meaning, the JSPA considers >> them to be part of the Spec under the subsequent license, but the sentence >> is so vague, that I'm sure, you'll find 3 different oppinions or >> interpretations if you just ask enough lawyers;-) >> > >> > >> > >> >>Btw, I've talked with a few lawyers who reviewed ULA and they did all >> not sound happy about it... >> >> >> >> >> >> >> >>I also got a bunch of weird answers from Oracle lawyers, e.g. that we >> must not do a RI which is ALv2, EPL, OSGI, etc because 'they are not >> compatible with the licenses we use in Glassfish'. >> >>Totally sick argument. If that would be true than Oracle would need to >> remove 50 jars from Glassfish4, including >> >>* Weld >> >>* Eclipselink >> >>* all OSGi >> >>* Tomcat (yes, core-web.jar is nothing but a repackaged tomcat) >> >> >> >>* JNDI (org.apache.naming) >> >>to just name a few. >> >> >> >> >> >>Would this make sense? Do we really like to go down this route? >> >> >> >> >> >>To make it clear: Glassfish is dual licensed as CDDL and GPL+CPE. And >> exactly the ClassPathException is the case why EPL and ALv2 jars inside >> Glassfish are totally fine and this legal info we got from Oracle legal is >> imo nuts. >> >> >> >> >> >> >> > >> > >> >Look into OpenJDK and especially the whole of the (additional) java.time >> APIs contain BSD licensed material, despite the fact, that JDK as such is >> licensed under different agreements. I asked the people in the EC and IP WG >> discussing these things, and only Azul (not a lawyer but also caring a lot >> about IP) said their understanding was, it should be OK for "Non EG >> Members" to contribute this under BSD, but EG Members should have >> contributed all of that either under the Spec License or the one by >> OpenJDK. None of the classes in question seem to ever have been touched by >> anybody other than the Spec Leads as there was no other contribution when >> 310 was still in places like GitHub or SF.net. >> > >> > >> > >> > >> >>I know there is tons of legal b******t going round these days. But >> repeating it over and over again doesn't make it more true... >> >> >> >>If you think I have an error in my argumentation then please feel free >> to correct me and help me understand the problem. >> >> >> >> >> >> >> > >> > >> >I think I'd have to leave that to people in the IP circles or legal team >> of either Oracle, IBM, Red Hat or others, as soon as they find a common >> understanding about it;-D >> > >> >LieGrue, >> >>strub >> >> >> >> >> >> >> >> >> > >> > >> >Cheers, >> >Werner >> > >> > >> >>On Thursday, 3 July 2014, 20:33, Werner Keil >> wrote: >> >>>I must correct you in the sense, that the license (that "Accept and >> Download" page) for the Spec is not Apache, though there is practically no >> spec here for these 6 annotations. >> >>>So it is a bit of a grey zone, and even EC Members with a large legal >> department are in ongoing discussions over that. The "Spec" and its >> Software Manifestation (normally all artifacts under "javax.something" or >> "java.something" (for the few JSRs like 310 that changed their package name >> in the course of the lifecycle) in Oracle's (the PMO) understanding is >> under the Spec License. >> >>> >> >>> >> >>>So strictly speaking annotations under "javax.inject" are the "Spec", >> not RI or TCK, and therefore they don't fall under Apache 2. Google Guice >> and the TCK did and still do. >> >>> >> >>> >> >>>Looking at JSRs like 107 https://github.com/jsr107/jsr107spec or 354, >> you'll notice they all have this in common. >> >>>Especially the JavaDoc as manifestation of the Spec (and for 330 that >> is all there is of a Spec) therefore naturally fall under the Spec License, >> too. >> >>> >> >>> >> >>>Just see Java EE 7: http://docs.oracle.com/javaee/7/api/ the JavaDoc >> (for all JSRs within that umbrella) is therefore covered by the EE 7 Spec >> License >> >>>>Copyright ? 1996-2013, Oracle and/or its affiliates. All Rights >> Reserved. Use is subject to license terms. >> >>> >> >>>see the link under "license terms" >> >>> >> >>> >> >>>JSR 352 poses a stubbern dilemma as its EG and Spec Leads insist on a >> different license footer in the standalone distribution (Apache 2) as in >> the overall Java EE 7 umbrella. >> >>>Which is a nightmare for users, a reason I voted against the MR or >> abstained from this particular JSR as it denies what is reality at least >> for the Spec and artifacts like the JavaDoc. >> >>> >> >>> >> >>>CDI refrains from this breach. At least there is no contradicting >> JavaDoc license pointer. >> >>> >> >>> >> >>>Red Hat considers a "Dual Licensing" option for the Spec, but from all >> I heard so far, this is not how Oracle and the JCP PMO (or at least >> Oracle's lawyers) see this. With the proposal of the ULA Oracle tries to >> get all future JSRs to use a single license for RI and TCK. >> >>> >> >>> >> >>>There's an ongoing discussion over details, but unless Oracle's legal >> department and PMO make a dramatic turn on these matters, JSRs filed in the >> near future (including CDI 2 or beyond) would likely fall under Spec and >> ULA license. >> >>> >> >>> >> >>>Cheers, >> >>>Werner >> >>> >> >>> >> >>>On Thu, Jul 3, 2014 at 8:00 PM, Mark Struberg >> wrote: >> >>> >> >>>As far as I know the history (and I have been tracking and >> contributing to JSR-330 back then) most of the people were fed up _because_ >> they got pushed to change the license from ALv2 to something else (cannot >> remember anymore what exactly). >> >>>> >> >>>> >> >>>>The original Apache v2 licensed work can be found here: >> >>>>https://code.google.com/p/atinject/ >> >>>> >> >>>> >> >>>> >> >>>>I have no clue why Oracle added the 'accept license' radio button on >> their JSR-330 download page. Maybe just a copy&paste error? The text in >> this license window is in fact not ALv2 but something else which is wrong >> information at best. >> >>>> >> >>>> >> >>>>The good news: ALL the assets in JSR-330 still are ALv2! >> >>>>Thus anyone can take it and enhance it. >> >>>>Of course it would be good to have Bob and J?rgen on board, but >> legally it might not even be necessary. >> >>>> >> >>>> >> >>>>LieGrue, >> >>>>strub >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>>On Thursday, 3 July 2014, 17:35, Werner Keil >> wrote: >> >>>> >> >>>> >> >>>>> >> >>>>> >> >>>>>I guess with only 5 or 6 annotations (and that's all the JSR >> consists of;-) if changing/improving only one or two of these was what's >> needed, this could be easiest as MR, otherwise 330 is history as it would >> require a new JSR. JSR 330 was under JCP 2.7 and for final JSRs they >> normally stay there, I don't think it can move to a newer version of the >> JCP: https://jcp.org/en/resources/guide-maintenance#2_7 >> >>>>> >> >>>>> >> >>>>> >> >>>>>The trouble is, both Spec Leads seem unresponsive or no longer >> around (Rod Johnson left Pivotal, Pivotal in its current form does not even >> seem JCP member and VMware may not be able or interested to step in for >> them) maybe Pete knows best if Bob was, as until JSR 364 or even a new >> version of the JSPA are finalized he could probably do it if he wants and >> has the time for this right now (especially if another JSR like CDI 2 >> depends on it, that can't be delayed even if this JSR may technically still >> be unaffected by JCP 2.8+) >> >>>>> >> >>>>> >> >>>>>Except for active corporate members Oracle, Red Hat or IBM the whole >> EG practically disintegrated. Doug Lea and Tim Peirls may be involved >> elsewhere (mostly OpenJDK from all I heard) but they have not been active >> in the JCP or active JSRs recently. Google, we heard gave up the Spec Lead >> in the first place, so it is unlikely under the current circumstances it >> will play an active role. Jason VanZyl and Maven I know they at least use >> JSR 330 quite a bit, so they should at least be interested in its future >> direction. Thoughtworks I don't recall them to be involved and Martin >> Fowler himself told me of his "allergy" against such form of >> standardization, so I would not count on them here either. >> >>>>> >> >>>>> >> >>>>>So assuming a separate @Inject spec shall be maintained there are 3 >> options: >> >>>>> 1. Bob Lee (or the other Spec Lead) responds in a timely manner >> to contact attempts by Antoine and ultimately the PMO (who needs to handle >> such situations) in which case a simple MR was possible >> >>>>> 2. A replacement of Maintenance Lead, along the lines of >> https://jcp.org/ja/introduction/faq-speclead#slresigns (it is rarely the >> case for an MR, but should work pretty much the same way here, so the main >> candidates to replace a Spec Lead would be in that EG, hence Red Hat, IBM >> or Oracle for most part;-) If such condition can't be resolved, both PMO >> and JCP EC would be able to help find a suitable replacement, too >> >>>>> 3. A whole new JSR is filed. Although it is often the case that >> the Spec Lead(s) are the same, that is not necessary, especially if the old >> ones moved on or can't do this any more right now. >> >> >> >>>>>HTH, >> >>>>>Werner >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>>On Thu, Jul 3, 2014 at 5:00 PM, Kito Mann >> wrote: >> >>>>> >> >>>>>My $0.02 is that it's worth the effort to evolve JSR-330 for the >> community as a whole. I've been on projects where they tend to use those >> annotations even in a CDI environment, and it makes it much easier to >> switch between Spring and CDI if necessary. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>>On Wed, Jul 2, 2014 at 4:43 PM, Antoine Sabot-Durand < >> antoine at sabot-durand.net> wrote: >> >>>>>> >> >>>>>>Hi all, >> >>>>>>> >> >>>>>>>Since the first mention of CDI 2.0 preparation work, we've >> received a lot of comment about JSR 330 evolution. With the release of the >> proposal draft yesterday, this topic came up again. So let me give my point >> of view on this subject to have an open discussion here. >> >>>>>>> >> >>>>>>>When we started to discuss about modularity with Pete in last >> november, my first idea was to go see what we could add in JSR 330 to make >> it a true specification that could be the first module of CDI. My idea at >> that time was to discuss with JSR 330 owner to see if we could bring basic >> concept we have in CDI to AtInject spec. In my mind the main features would >> have been: >> >>>>>>> - Enhance the javax.inject.Provider interface to bring it at >> the same level than javax.enterprise.inject.Instance. That would have >> included support for AnnotationLiteral and TypeLiteral as well >> >>>>>>> - Add a Container interface (a very light BeanManger) in JSR 330 >> to be able to resolve beans instance from outside managed beans >> >>>>>>> - Add a mechanism to get this Container from non managed beans >> (like we get access to BeanManager from JNDI or CDI class) >> >>>>>>> >> >>>>>>>At that time, I contacted Bob Lee without success (didn?t tried >> Pivotal since I don?t have contact there). I checked with JCP what could be >> done if we?d like to see an evolution of JSR 330 and the owner doesn?t >> care, there seems to have solutions but I let it aside since we were in the >> middle of CDI 1.2 MR at that time. >> >>>>>>> >> >>>>>>>Today I?m a bit torn about this point. Working on opening JSR 330 >> could be like opening pandora box, since I see 2 scenarios : >> >>>>>>> >> >>>>>>>1) former JSR 330 owners wake up and are ok to get for a new spec >> version they lead: >> >>>>>>>Knowing the history of JSR 330 vs JSR 299 I?m not sure everything >> we?d need would be heard and even if the people leading this would be >> cooperative, a lot of discussion and negotiation would be needed to be sure >> that this new AtInject wouldn?t contain features incompatible with CDI. So >> it?d be very time consuming with no guarantee to get what we?d need at the >> end. >> >>>>>>> >> >>>>>>>2) former JSR 330 owner don?t mind others take ownership of their >> spec to enhance it and we (Red Hat) are the one to take this ownership to >> secure CDI: >> >>>>>>>The best solution to minimize risk. But leading a new >> specification is a lot more work than just deciding that we have a specific >> basic inject ? part ? in CDI 2.0. Leading a spec is very time consuming, >> so it could be better on the paper but will impact CDI 2.0 new features. >> >>>>>>> >> >>>>>>>To sum up, as a Java EE user (like I have been for 10 years) I?d >> be happy to see this (scenario 2), but as CDI spec lead I fear that it >> could lead us in a trap (going to scenario 1 or consuming precious time on >> AtInject+1 instead of CDI 2.0) >> >>>>>>> >> >>>>>>>Your input, solutions or comment would be appreciated on this >> point. >> >>>>>>> >> >>>>>>>Antoine >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>>_______________________________________________ >> >>>>>>>cdi-dev mailing list >> >>>>>>>cdi-dev at lists.jboss.org >> >>>>>>>https://lists.jboss.org/mailman/listinfo/cdi-dev >> >>>>>>> >> >>>>>> >> >>>>> >> >>>>> >> >>>>>_______________________________________________ >> >>>>>cdi-dev mailing list >> >>>>>cdi-dev at lists.jboss.org >> >>>>>https://lists.jboss.org/mailman/listinfo/cdi-dev >> >>>>> >> >>>>> >> >>> >> >>> >> >>> >> >> >> > >> > >> > >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140704/84ee9b5f/attachment-0001.html From jens.schumann at openknowledge.de Fri Jul 4 02:11:07 2014 From: jens.schumann at openknowledge.de (Jens Schumann) Date: Fri, 4 Jul 2014 06:11:07 +0000 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: References: <1404410440.24522.YahooMailNeo@web28903.mail.ir2.yahoo.com> <1404420433.77837.YahooMailNeo@web28901.mail.ir2.yahoo.com> <1404424902.51995.YahooMailNeo@web28902.mail.ir2.yahoo.com> Message-ID: Von: Werner Keil Datum: Friday 4 July 2014 00:46 An: Mark Struberg Cc: Reza Rahman , Arun Gupta , Badr Elhouari , Adam Bien , CDI-Dev , Eisele Markus Betreff: Re: [cdi-dev] About JSR 330.Next and CDI 2.0 >In a majority of cases, not just Oracle but also other vendors from a >legal point still live and practice a "Shrinkwrap mindset", so the only >license that counts is the one you see when you "open the box". Or >download artifacts from JCP or a similar place. Well, this might be their mindset. However European IP law treats this quite different and has a strict understanding for doing so (I avoid the c-word here on purpose). I assume US IP law is quite similar in this regard - especially in the area of author/copyright owner rights, exploitation rights, etc. I am not familiar with JCP/EC/Oracle/Sun/... internals. Nevertheless I have been in a legal battle that covered both source code disclaimers and "intended contractual purpose that lead to the source". Since both did not match at some point we had to exchange arguments via lawyers. And - at no surprise - it turned out that European/German IP law is pretty simple and works just like Mark wrote in his mails before;). Of course there are issues if source code is created as an result of an specification process (say - paper was first). However it won?t break source code copyrights and attached licenses, particularly in the case of JSR-330. Let?s hope things can be sorted out without lawyers, Jens From werner.keil at gmail.com Fri Jul 4 04:53:41 2014 From: werner.keil at gmail.com (Werner Keil) Date: Fri, 4 Jul 2014 10:53:41 +0200 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: References: <1404410440.24522.YahooMailNeo@web28903.mail.ir2.yahoo.com> <1404420433.77837.YahooMailNeo@web28901.mail.ir2.yahoo.com> <1404424902.51995.YahooMailNeo@web28902.mail.ir2.yahoo.com> Message-ID: In most cases if the Spec Lead is a large company they need to consult their legal team. Regarding the source code vs. attached "shrinkwrap" license, it gets a lot more complex, especially for Umbrella JSRs like Java EE. There the majority of users won't bother looking at hundreds or thousands of source files including JSR 330, CDI or other components including EJB, JSF, etc. or JMS ( https://jcp.org/en/jsr/detail?id=343) There you'll see, even the RI/TCK license is not Apache or GPL/CPE, but a commercial Oracle License that's far more restrictive. Martijn is not in this thread any more, and there is no need to add him, but as he mentioned doing a WebSocket project for SE, it would be interesting to hear, if he uses JSR 356 ( https://jcp.org/en/jsr/detail?id=356) That and a few others have 3-4(!) different licenses for RI/TCK alone, depending on usage or the commercial product it's used in. So from that point of view despite all critical voices (they'll be able to discuss this or try improve points they may find unacceptable) aiming for a single, unified license for ALL RI and TCK seems a good intention and won't put users at risk of surprises if they use an API like WebSockets or JBatch (or even CDI) standalone as opposed to a large platform or umbrella JSR. Werner On Fri, Jul 4, 2014 at 8:11 AM, Jens Schumann < jens.schumann at openknowledge.de> wrote: > Von: Werner Keil > Datum: Friday 4 July 2014 00:46 > An: Mark Struberg > Cc: Reza Rahman , Arun Gupta > , Badr Elhouari , Adam Bien > , CDI-Dev , Eisele Markus > > Betreff: Re: [cdi-dev] About JSR 330.Next and CDI 2.0 > > > >In a majority of cases, not just Oracle but also other vendors from a > >legal point still live and practice a "Shrinkwrap mindset", so the only > >license that counts is the one you see when you "open the box". Or > >download artifacts from JCP or a similar place. > > Well, this might be their mindset. However European IP law treats this > quite different and has a strict understanding for doing so (I avoid the > c-word here on purpose). I assume US IP law is quite similar in this > regard - especially in the area of author/copyright owner rights, > exploitation rights, etc. > > I am not familiar with JCP/EC/Oracle/Sun/... internals. Nevertheless I > have been in a legal battle that covered both source code disclaimers and > "intended contractual purpose that lead to the source". Since both did not > match at some point we had to exchange arguments via lawyers. And - at no > surprise - it turned out that European/German IP law is pretty simple and > works just like Mark wrote in his mails before;). > > Of course there are issues if source code is created as an result of an > specification process (say - paper was first). However it won?t break > source code copyrights and attached licenses, particularly in the case of > JSR-330. > > > Let?s hope things can be sorted out without lawyers, > Jens > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140704/341a955a/attachment.html From pmuir at redhat.com Fri Jul 4 05:46:59 2014 From: pmuir at redhat.com (Pete Muir) Date: Fri, 4 Jul 2014 10:46:59 +0100 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: References: <1404410440.24522.YahooMailNeo@web28903.mail.ir2.yahoo.com> Message-ID: <3CE6FC09-4593-4CE2-8327-32366151DE9E@redhat.com> The CDI spec lead (Red Hat)?s official position for the CDI specification is clearly covered on http://www.cdi-spec.org/download/ If you have any questions regarding this, you will need to contact Red Hat legal. On 3 Jul 2014, at 19:33, Werner Keil wrote: > I must correct you in the sense, that the license (that "Accept and Download" page) for the Spec is not Apache, though there is practically no spec here for these 6 annotations. > So it is a bit of a grey zone, and even EC Members with a large legal department are in ongoing discussions over that. The "Spec" and its Software Manifestation (normally all artifacts under "javax.something" or "java.something" (for the few JSRs like 310 that changed their package name in the course of the lifecycle) in Oracle's (the PMO) understanding is under the Spec License. > > So strictly speaking annotations under "javax.inject" are the "Spec", not RI or TCK, and therefore they don't fall under Apache 2. Google Guice and the TCK did and still do. > > Looking at JSRs like 107 https://github.com/jsr107/jsr107spec or 354, you'll notice they all have this in common. > Especially the JavaDoc as manifestation of the Spec (and for 330 that is all there is of a Spec) therefore naturally fall under the Spec License, too. > > Just see Java EE 7: http://docs.oracle.com/javaee/7/api/ the JavaDoc (for all JSRs within that umbrella) is therefore covered by the EE 7 Spec License > >Copyright ? 1996-2013, Oracle and/or its affiliates. All Rights Reserved. Use is subject to license terms. > see the link under "license terms"<329.gif> > > JSR 352 poses a stubbern dilemma as its EG and Spec Leads insist on a different license footer in the standalone distribution (Apache 2) as in the overall Java EE 7 umbrella. > Which is a nightmare for users, a reason I voted against the MR or abstained from this particular JSR as it denies what is reality at least for the Spec and artifacts like the JavaDoc. > > CDI refrains from this breach. At least there is no contradicting JavaDoc license pointer. > > Red Hat considers a "Dual Licensing" option for the Spec, but from all I heard so far, this is not how Oracle and the JCP PMO (or at least Oracle's lawyers) see this. > With the proposal of the ULA Oracle tries to get all future JSRs to use a single license for RI and TCK. > > There's an ongoing discussion over details, but unless Oracle's legal department and PMO make a dramatic turn on these matters, JSRs filed in the near future (including CDI 2 or beyond) would likely fall under Spec and ULA license. > > Cheers, > Werner > > On Thu, Jul 3, 2014 at 8:00 PM, Mark Struberg wrote: > As far as I know the history (and I have been tracking and contributing to JSR-330 back then) most of the people were fed up _because_ they got pushed to change the license from ALv2 to something else (cannot remember anymore what exactly). > > The original Apache v2 licensed work can be found here: > https://code.google.com/p/atinject/ > > I have no clue why Oracle added the 'accept license' radio button on their JSR-330 download page. Maybe just a copy&paste error? The text in this license window is in fact not ALv2 but something else which is wrong information at best. > > The good news: ALL the assets in JSR-330 still are ALv2! > Thus anyone can take it and enhance it. > Of course it would be good to have Bob and J?rgen on board, but legally it might not even be necessary. > > LieGrue, > strub > > > > On Thursday, 3 July 2014, 17:35, Werner Keil wrote: > > > I guess with only 5 or 6 annotations (and that's all the JSR consists of;-) if changing/improving only one or two of these was what's needed, this could be easiest as MR, otherwise 330 is history as it would require a new JSR. JSR 330 was under JCP 2.7 and for final JSRs they normally stay there, I don't think it can move to a newer version of the JCP: https://jcp.org/en/resources/guide-maintenance#2_7 > > The trouble is, both Spec Leads seem unresponsive or no longer around (Rod Johnson left Pivotal, Pivotal in its current form does not even seem JCP member and VMware may not be able or interested to step in for them) maybe Pete knows best if Bob was, as until JSR 364 or even a new version of the JSPA are finalized he could probably do it if he wants and has the time for this right now (especially if another JSR like CDI 2 depends on it, that can't be delayed even if this JSR may technically still be unaffected by JCP 2.8+) > > Except for active corporate members Oracle, Red Hat or IBM the whole EG practically disintegrated. Doug Lea and Tim Peirls may be involved elsewhere (mostly OpenJDK from all I heard) but they have not been active in the JCP or active JSRs recently. Google, we heard gave up the Spec Lead in the first place, so it is unlikely under the current circumstances it will play an active role. Jason VanZyl and Maven I know they at least use JSR 330 quite a bit, so they should at least be interested in its future direction. Thoughtworks I don't recall them to be involved and Martin Fowler himself told me of his "allergy" against such form of standardization, so I would not count on them here either. > > So assuming a separate @Inject spec shall be maintained there are 3 options: > ? Bob Lee (or the other Spec Lead) responds in a timely manner to contact attempts by Antoine and ultimately the PMO (who needs to handle such situations) in which case a simple MR was possible > ? A replacement of Maintenance Lead, along the lines of https://jcp.org/ja/introduction/faq-speclead#slresigns (it is rarely the case for an MR, but should work pretty much the same way here, so the main candidates to replace a Spec Lead would be in that EG, hence Red Hat, IBM or Oracle for most part;-) If such condition can't be resolved, both PMO and JCP EC would be able to help find a suitable replacement, too > ? A whole new JSR is filed. Although it is often the case that the Spec Lead(s) are the same, that is not necessary, especially if the old ones moved on or can't do this any more right now. > HTH, > Werner > > > On Thu, Jul 3, 2014 at 5:00 PM, Kito Mann wrote: > My $0.02 is that it's worth the effort to evolve JSR-330 for the community as a whole. I've been on projects where they tend to use those annotations even in a CDI environment, and it makes it much easier to switch between Spring and CDI if necessary. > > > On Wed, Jul 2, 2014 at 4:43 PM, Antoine Sabot-Durand wrote: > Hi all, > > Since the first mention of CDI 2.0 preparation work, we've received a lot of comment about JSR 330 evolution. With the release of the proposal draft yesterday, this topic came up again. So let me give my point of view on this subject to have an open discussion here. > > When we started to discuss about modularity with Pete in last november, my first idea was to go see what we could add in JSR 330 to make it a true specification that could be the first module of CDI. My idea at that time was to discuss with JSR 330 owner to see if we could bring basic concept we have in CDI to AtInject spec. In my mind the main features would have been: > - Enhance the javax.inject.Provider interface to bring it at the same level than javax.enterprise.inject.Instance. That would have included support for AnnotationLiteral and TypeLiteral as well > - Add a Container interface (a very light BeanManger) in JSR 330 to be able to resolve beans instance from outside managed beans > - Add a mechanism to get this Container from non managed beans (like we get access to BeanManager from JNDI or CDI class) > > At that time, I contacted Bob Lee without success (didn?t tried Pivotal since I don?t have contact there). I checked with JCP what could be done if we?d like to see an evolution of JSR 330 and the owner doesn?t care, there seems to have solutions but I let it aside since we were in the middle of CDI 1.2 MR at that time. > > Today I?m a bit torn about this point. Working on opening JSR 330 could be like opening pandora box, since I see 2 scenarios : > > 1) former JSR 330 owners wake up and are ok to get for a new spec version they lead: > Knowing the history of JSR 330 vs JSR 299 I?m not sure everything we?d need would be heard and even if the people leading this would be cooperative, a lot of discussion and negotiation would be needed to be sure that this new AtInject wouldn?t contain features incompatible with CDI. So it?d be very time consuming with no guarantee to get what we?d need at the end. > > 2) former JSR 330 owner don?t mind others take ownership of their spec to enhance it and we (Red Hat) are the one to take this ownership to secure CDI: > The best solution to minimize risk. But leading a new specification is a lot more work than just deciding that we have a specific basic inject ? part ? in CDI 2.0. Leading a spec is very time consuming, so it could be better on the paper but will impact CDI 2.0 new features. > > To sum up, as a Java EE user (like I have been for 10 years) I?d be happy to see this (scenario 2), but as CDI spec lead I fear that it could lead us in a trap (going to scenario 1 or consuming precious time on AtInject+1 instead of CDI 2.0) > > Your input, solutions or comment would be appreciated on this point. > > Antoine > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev From mpallas at gmail.com Fri Jul 4 06:34:25 2014 From: mpallas at gmail.com (Nick Mpallas) Date: Fri, 4 Jul 2014 12:34:25 +0200 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: <3CE6FC09-4593-4CE2-8327-32366151DE9E@redhat.com> References: <1404410440.24522.YahooMailNeo@web28903.mail.ir2.yahoo.com> <3CE6FC09-4593-4CE2-8327-32366151DE9E@redhat.com> Message-ID: Hi guys, adding on the discussion of that is the Event mechanism. It would be interesting if we could have the Event injecting mechanism to be injectable by any JSR component. Imagine for example I have a JNDI resource(Another added value here would be allowing JNDI resource handling via annotations) and registering for light CDI events. A pub sub pattern that would imitate something like a bus event mechanism where "components" can register for firing base on events published. The CDI container should provide this lightweight mechanism also in an standalone mode. This would allow for building some nice eventing frameworks on top of CDI that would be available and could integrate really easily with other enterprise components. My 0.00005$ on the discussion. regards Nick On Fri, Jul 4, 2014 at 11:46 AM, Pete Muir wrote: > The CDI spec lead (Red Hat)?s official position for the CDI specification > is clearly covered on http://www.cdi-spec.org/download/ > > If you have any questions regarding this, you will need to contact Red Hat > legal. > > On 3 Jul 2014, at 19:33, Werner Keil wrote: > > > I must correct you in the sense, that the license (that "Accept and > Download" page) for the Spec is not Apache, though there is practically no > spec here for these 6 annotations. > > So it is a bit of a grey zone, and even EC Members with a large legal > department are in ongoing discussions over that. The "Spec" and its > Software Manifestation (normally all artifacts under "javax.something" or > "java.something" (for the few JSRs like 310 that changed their package name > in the course of the lifecycle) in Oracle's (the PMO) understanding is > under the Spec License. > > > > So strictly speaking annotations under "javax.inject" are the "Spec", > not RI or TCK, and therefore they don't fall under Apache 2. Google Guice > and the TCK did and still do. > > > > Looking at JSRs like 107 https://github.com/jsr107/jsr107spec or 354, > you'll notice they all have this in common. > > Especially the JavaDoc as manifestation of the Spec (and for 330 that > is all there is of a Spec) therefore naturally fall under the Spec License, > too. > > > > Just see Java EE 7: http://docs.oracle.com/javaee/7/api/ the JavaDoc > (for all JSRs within that umbrella) is therefore covered by the EE 7 Spec > License > > >Copyright ? 1996-2013, Oracle and/or its affiliates. All Rights > Reserved. Use is subject to license terms. > > see the link under "license terms"<329.gif> > > > > JSR 352 poses a stubbern dilemma as its EG and Spec Leads insist on a > different license footer in the standalone distribution (Apache 2) as in > the overall Java EE 7 umbrella. > > Which is a nightmare for users, a reason I voted against the MR or > abstained from this particular JSR as it denies what is reality at least > for the Spec and artifacts like the JavaDoc. > > > > CDI refrains from this breach. At least there is no contradicting > JavaDoc license pointer. > > > > Red Hat considers a "Dual Licensing" option for the Spec, but from all I > heard so far, this is not how Oracle and the JCP PMO (or at least Oracle's > lawyers) see this. > > With the proposal of the ULA Oracle tries to get all future JSRs to use > a single license for RI and TCK. > > > > There's an ongoing discussion over details, but unless Oracle's legal > department and PMO make a dramatic turn on these matters, JSRs filed in the > near future (including CDI 2 or beyond) would likely fall under Spec and > ULA license. > > > > Cheers, > > Werner > > > > On Thu, Jul 3, 2014 at 8:00 PM, Mark Struberg wrote: > > As far as I know the history (and I have been tracking and contributing > to JSR-330 back then) most of the people were fed up _because_ they got > pushed to change the license from ALv2 to something else (cannot remember > anymore what exactly). > > > > The original Apache v2 licensed work can be found here: > > https://code.google.com/p/atinject/ > > > > I have no clue why Oracle added the 'accept license' radio button on > their JSR-330 download page. Maybe just a copy&paste error? The text in > this license window is in fact not ALv2 but something else which is wrong > information at best. > > > > The good news: ALL the assets in JSR-330 still are ALv2! > > Thus anyone can take it and enhance it. > > Of course it would be good to have Bob and J?rgen on board, but legally > it might not even be necessary. > > > > LieGrue, > > strub > > > > > > > > On Thursday, 3 July 2014, 17:35, Werner Keil > wrote: > > > > > > I guess with only 5 or 6 annotations (and that's all the JSR consists > of;-) if changing/improving only one or two of these was what's needed, > this could be easiest as MR, otherwise 330 is history as it would require a > new JSR. JSR 330 was under JCP 2.7 and for final JSRs they normally stay > there, I don't think it can move to a newer version of the JCP: > https://jcp.org/en/resources/guide-maintenance#2_7 > > > > The trouble is, both Spec Leads seem unresponsive or no longer around > (Rod Johnson left Pivotal, Pivotal in its current form does not even seem > JCP member and VMware may not be able or interested to step in for them) > maybe Pete knows best if Bob was, as until JSR 364 or even a new version of > the JSPA are finalized he could probably do it if he wants and has the time > for this right now (especially if another JSR like CDI 2 depends on it, > that can't be delayed even if this JSR may technically still be unaffected > by JCP 2.8+) > > > > Except for active corporate members Oracle, Red Hat or IBM the whole EG > practically disintegrated. Doug Lea and Tim Peirls may be involved > elsewhere (mostly OpenJDK from all I heard) but they have not been active > in the JCP or active JSRs recently. Google, we heard gave up the Spec Lead > in the first place, so it is unlikely under the current circumstances it > will play an active role. Jason VanZyl and Maven I know they at least use > JSR 330 quite a bit, so they should at least be interested in its future > direction. Thoughtworks I don't recall them to be involved and Martin > Fowler himself told me of his "allergy" against such form of > standardization, so I would not count on them here either. > > > > So assuming a separate @Inject spec shall be maintained there are 3 > options: > > ? Bob Lee (or the other Spec Lead) responds in a timely manner to > contact attempts by Antoine and ultimately the PMO (who needs to handle > such situations) in which case a simple MR was possible > > ? A replacement of Maintenance Lead, along the lines of > https://jcp.org/ja/introduction/faq-speclead#slresigns (it is rarely the > case for an MR, but should work pretty much the same way here, so the main > candidates to replace a Spec Lead would be in that EG, hence Red Hat, IBM > or Oracle for most part;-) If such condition can't be resolved, both PMO > and JCP EC would be able to help find a suitable replacement, too > > ? A whole new JSR is filed. Although it is often the case that the > Spec Lead(s) are the same, that is not necessary, especially if the old > ones moved on or can't do this any more right now. > > HTH, > > Werner > > > > > > On Thu, Jul 3, 2014 at 5:00 PM, Kito Mann > wrote: > > My $0.02 is that it's worth the effort to evolve JSR-330 for the > community as a whole. I've been on projects where they tend to use those > annotations even in a CDI environment, and it makes it much easier to > switch between Spring and CDI if necessary. > > > > > > On Wed, Jul 2, 2014 at 4:43 PM, Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > > Hi all, > > > > Since the first mention of CDI 2.0 preparation work, we've received a > lot of comment about JSR 330 evolution. With the release of the proposal > draft yesterday, this topic came up again. So let me give my point of view > on this subject to have an open discussion here. > > > > When we started to discuss about modularity with Pete in last november, > my first idea was to go see what we could add in JSR 330 to make it a true > specification that could be the first module of CDI. My idea at that time > was to discuss with JSR 330 owner to see if we could bring basic concept we > have in CDI to AtInject spec. In my mind the main features would have been: > > - Enhance the javax.inject.Provider interface to bring it at the > same level than javax.enterprise.inject.Instance. That would have > included support for AnnotationLiteral and TypeLiteral as well > > - Add a Container interface (a very light BeanManger) in JSR 330 to be > able to resolve beans instance from outside managed beans > > - Add a mechanism to get this Container from non managed beans (like we > get access to BeanManager from JNDI or CDI class) > > > > At that time, I contacted Bob Lee without success (didn?t tried Pivotal > since I don?t have contact there). I checked with JCP what could be done if > we?d like to see an evolution of JSR 330 and the owner doesn?t care, there > seems to have solutions but I let it aside since we were in the middle of > CDI 1.2 MR at that time. > > > > Today I?m a bit torn about this point. Working on opening JSR 330 could > be like opening pandora box, since I see 2 scenarios : > > > > 1) former JSR 330 owners wake up and are ok to get for a new spec > version they lead: > > Knowing the history of JSR 330 vs JSR 299 I?m not sure everything we?d > need would be heard and even if the people leading this would be > cooperative, a lot of discussion and negotiation would be needed to be sure > that this new AtInject wouldn?t contain features incompatible with CDI. So > it?d be very time consuming with no guarantee to get what we?d need at the > end. > > > > 2) former JSR 330 owner don?t mind others take ownership of their spec > to enhance it and we (Red Hat) are the one to take this ownership to secure > CDI: > > The best solution to minimize risk. But leading a new specification is a > lot more work than just deciding that we have a specific basic inject ? > part ? in CDI 2.0. Leading a spec is very time consuming, so it could be > better on the paper but will impact CDI 2.0 new features. > > > > To sum up, as a Java EE user (like I have been for 10 years) I?d be > happy to see this (scenario 2), but as CDI spec lead I fear that it could > lead us in a trap (going to scenario 1 or consuming precious time on > AtInject+1 instead of CDI 2.0) > > > > Your input, solutions or comment would be appreciated on this point. > > > > Antoine > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > -- \n\m "camel is a horse made up in a laboratory" -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140704/edc45578/attachment-0001.html From issues at jboss.org Fri Jul 4 06:47:24 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Fri, 4 Jul 2014 06:47:24 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-448) Clarify autoboxing of arrays In-Reply-To: References: Message-ID: Jozef Hartinger created CDI-448: ----------------------------------- Summary: Clarify autoboxing of arrays Key: CDI-448 URL: https://issues.jboss.org/browse/CDI-448 Project: CDI Specification Issues Issue Type: Clarification Affects Versions: 1.2.Final Reporter: Jozef Hartinger Section 2.2.1: {quote} ? A bean type may be an array type. Two array types are considered identical only if the element type is identical. ? A bean type may be a primitive type. Primitive types are considered to be identical to their corresponding wrapper types in java.lang. {quote} When these two rules are combined, autoboxing of arrays is implied. For example, having type A defined as int[] and type B defined as Integer[] then: 1) these two array types are considered identical as long as their element types (int and Integer) are identical 2) int and Integer are considered identical (as primitive types are considered identical to java.lang wrapper types) Thus, A and B are considered identical. This is however in contrast to JLS where array autoboxing is not supported - you cannot do int[] foo = new Integer[0]; It should therefore be clarified if array autoboxing is also unsupported in CDI or whether a CDI implementation should do the extra work to support this (e.g. allocating a new array and copying autboxed values over before injecting) -- This message was sent by Atlassian JIRA (v6.2.6#6264) From struberg at yahoo.de Fri Jul 4 07:01:27 2014 From: struberg at yahoo.de (Mark Struberg) Date: Fri, 4 Jul 2014 12:01:27 +0100 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: <3CE6FC09-4593-4CE2-8327-32366151DE9E@redhat.com> References: <1404410440.24522.YahooMailNeo@web28903.mail.ir2.yahoo.com> <3CE6FC09-4593-4CE2-8327-32366151DE9E@redhat.com> Message-ID: <1404471687.99802.YahooMailNeo@web28901.mail.ir2.yahoo.com> Imo the CDI spec is clean in this regard. It mentions the evaluation license in the pdf itself and also points out that the RI, TCK and API is ALv2. Nothing to complain. I'd also like to remember where all this discussion started: That it is GOOD that the JSR-330 artifacts (which do not contain a separate spec pdf paper) are all ALv2 and thus we are lucky to be able to just maintain this in a new JSR. The other questions regarding JSR-330 is JCP politics... LieGrue, strub On Friday, 4 July 2014, 12:27, Pete Muir wrote: > > >The CDI spec lead (Red Hat)?s official position for the CDI specification is clearly covered on http://www.cdi-spec.org/download/ > >If you have any questions regarding this, you will need to contact Red Hat legal. > >On 3 Jul 2014, at 19:33, Werner Keil wrote: > >> I must correct you in the sense, that the license (that "Accept and Download" page) for the Spec is not Apache, though there is practically no spec here for these 6 annotations. >> So it is a bit of a grey zone, and even EC Members with a large legal department are in ongoing discussions over that. The "Spec" and its Software Manifestation (normally all artifacts under "javax.something" or "java.something" (for the few JSRs like 310 that changed their package name in the course of the lifecycle) in Oracle's (the PMO) understanding is under the Spec License. >> >> So strictly speaking annotations under "javax.inject" are the "Spec", not RI or TCK, and therefore they don't fall under Apache 2. Google Guice and the TCK did and still do. >> >> Looking at JSRs like 107 https://github.com/jsr107/jsr107spec or 354, you'll notice they all have this in common. >> Especially the JavaDoc as manifestation of the? Spec (and for 330 that is all there is of a Spec) therefore naturally fall under the Spec License, too. >> >> Just see Java EE 7: http://docs.oracle.com/javaee/7/api/ the JavaDoc (for all JSRs within that umbrella) is therefore covered by the EE 7 Spec License >> >Copyright ? 1996-2013, Oracle and/or its affiliates. All Rights Reserved. Use is subject to license terms. >> see the link under "license terms"<329.gif> >> >> JSR 352 poses a stubbern dilemma as its EG and Spec Leads insist on a different license footer in the standalone distribution (Apache 2) as in the overall Java EE 7 umbrella. >> Which is a nightmare for users, a reason I voted against the MR or abstained from this particular JSR as it denies what is reality at least for the Spec and artifacts like the JavaDoc. >> >> CDI refrains from this breach. At least there is no contradicting JavaDoc license pointer. >> >> Red Hat considers a "Dual Licensing" option for the Spec, but from all I heard so far, this is not how Oracle and the JCP PMO (or at least Oracle's lawyers) see this. >> With the proposal of the ULA Oracle tries to get all future JSRs to use a single license for RI and TCK. >> >> There's an ongoing discussion over details, but unless Oracle's legal department and PMO make a dramatic turn on these matters, JSRs filed in the near future (including CDI 2 or beyond) would likely fall under Spec and ULA license. >> >> Cheers, >> Werner >> >> On Thu, Jul 3, 2014 at 8:00 PM, Mark Struberg wrote: >> As far as I know the history (and I have been tracking and contributing to JSR-330 back then) most of the people were fed up _because_ they got pushed to change the license from ALv2 to something else (cannot remember anymore what exactly). >> >> The original Apache v2 licensed work can be found here: >> https://code.google.com/p/atinject/ >> >> I have no clue why Oracle? added the 'accept license' radio button on their JSR-330 download page. Maybe just a copy&paste error? The text in this license window is in fact not ALv2 but something else which is wrong information at best. >> >> The good news: ALL the assets in JSR-330 still are ALv2! >> Thus anyone can take it and enhance it. >> Of course it would be good to have Bob and J?rgen on board, but legally it might not even be necessary. >> >> LieGrue, >> strub >> >> >> >> On Thursday, 3 July 2014, 17:35, Werner Keil wrote: >> >> >> I guess with only 5 or 6 annotations (and that's all the JSR consists of;-) if changing/improving only one or two of these was what's needed, this could be easiest as MR, otherwise 330 is history as it would require a new JSR. JSR 330 was under JCP 2.7 and for final JSRs they normally stay there, I don't think it can move to a newer version of the JCP: https://jcp.org/en/resources/guide-maintenance#2_7 >> >> The trouble is, both Spec Leads seem unresponsive or no longer around (Rod Johnson left Pivotal, Pivotal in its current form does not even seem JCP member and VMware may not be able or interested to step in for them) maybe Pete knows best if Bob was, as until JSR 364 or even a new version of the JSPA are finalized he could probably do it if he wants and has the time for this right now (especially if another JSR like CDI 2 depends on it, that can't be delayed even if this JSR may technically still be unaffected by JCP 2.8+) >> >> Except for active corporate members Oracle, Red Hat or IBM the whole EG practically disintegrated. Doug Lea and Tim Peirls may be involved elsewhere (mostly OpenJDK from all I heard) but they have not been active in the JCP or active JSRs recently. Google, we heard gave up the Spec Lead in the first place, so it is unlikely under the current circumstances it will play an active role. Jason VanZyl and Maven I know they at least use JSR 330 quite a bit, so they should at least be interested in its future direction. Thoughtworks I don't recall them to be involved and Martin Fowler himself told me of his "allergy" against such form of standardization, so I would not count on them here either. >> >> So assuming a separate @Inject spec shall be maintained there are 3 options: >> ??? ? Bob Lee (or the other Spec Lead) responds in a timely manner to contact attempts by Antoine and ultimately the PMO (who needs to handle such situations) in which case a simple MR was possible >> ??? ? A replacement of Maintenance Lead, along the lines of https://jcp.org/ja/introduction/faq-speclead#slresigns (it is rarely the case for an MR, but should work pretty much the same way here, so the main candidates to replace a Spec Lead would be in that EG, hence Red Hat, IBM or Oracle for most part;-) If such condition can't be resolved, both PMO and JCP EC would be able to help find a suitable replacement, too >> ??? ? A whole new JSR is filed. Although it is often the case that the Spec Lead(s) are the same, that is not necessary, especially if the old ones moved on or can't do this any more right now. >> HTH, >> Werner >> >> >> On Thu, Jul 3, 2014 at 5:00 PM, Kito Mann wrote: >> My $0.02 is that it's worth the effort to evolve JSR-330 for the community as a whole. I've been on projects where they tend to use those annotations even in a CDI environment, and it makes it much easier to switch between Spring and CDI if necessary. >> >> >> On Wed, Jul 2, 2014 at 4:43 PM, Antoine Sabot-Durand wrote: >> Hi all, >> >> Since the first mention of CDI 2.0 preparation work, we've received a lot of comment about JSR 330 evolution. With the release of the proposal draft yesterday, this topic came up again. So let me give my point of view on this subject to have an open discussion here. >> >> When we started to discuss about modularity with Pete in last november, my first idea was to go see what we could add in JSR 330 to make it a true specification that could be the first module of CDI. My idea at that time was to discuss with JSR 330 owner to see if we could bring basic concept we have in CDI to AtInject spec. In my mind the main features would have been: >>? - Enhance the javax.inject.Provider interface to bring it at the same level than javax.enterprise.inject.Instance. That would have included support for AnnotationLiteral and TypeLiteral as well >>? - Add a Container interface (a very light BeanManger) in JSR 330 to be able to resolve beans instance from outside managed beans >>? - Add a mechanism to get this Container from non managed beans (like we get access to BeanManager from JNDI or CDI class) >> >> At that time, I contacted Bob Lee without success (didn?t tried Pivotal since I don?t have contact there). I checked with JCP what could be done if we?d like to see an evolution of JSR 330 and the owner doesn?t care, there seems to have solutions but I let it aside since we were in the middle of CDI 1.2 MR at that time. >> >> Today I?m a bit torn about this point. Working on opening JSR 330 could be like opening pandora box, since I see 2 scenarios : >> >> 1) former JSR 330 owners wake up and are ok to get for a new spec version they lead: >> Knowing the history of JSR 330 vs JSR 299 I?m not sure everything we?d need would be heard and even if the people leading this would be cooperative, a lot of discussion and negotiation would be needed to be sure that this new AtInject wouldn?t contain features incompatible with CDI. So it?d be very time consuming with no guarantee to get what we?d need at the end. >> >> 2) former JSR 330 owner don?t mind others take ownership of their spec to enhance it and we (Red Hat) are the one to take this ownership to secure CDI: >> The best solution to minimize risk. But leading a new specification is a lot more work than just deciding that we have a specific basic inject ? part ? in? CDI 2.0. Leading a spec is very time consuming, so it could be better on the paper but will impact CDI 2.0 new features. >> >> To sum up, as a Java EE user (like I have been for 10 years) I?d be happy to see this (scenario 2), but as CDI spec lead I fear that it could lead us in a trap (going to scenario 1 or consuming precious time on AtInject+1 instead of CDI 2.0) >> >> Your input, solutions or comment would be appreciated on this point. >> >> Antoine >> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140704/f3f35cce/attachment-0001.html From pmuir at redhat.com Fri Jul 4 07:11:11 2014 From: pmuir at redhat.com (Pete Muir) Date: Fri, 4 Jul 2014 12:11:11 +0100 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: <1404471687.99802.YahooMailNeo@web28901.mail.ir2.yahoo.com> References: <1404410440.24522.YahooMailNeo@web28903.mail.ir2.yahoo.com> <3CE6FC09-4593-4CE2-8327-32366151DE9E@redhat.com> <1404471687.99802.YahooMailNeo@web28901.mail.ir2.yahoo.com> Message-ID: On 4 Jul 2014, at 12:01, Mark Struberg wrote: > Imo the CDI spec is clean in this regard. This is the position of both myself, and Red Hat too :-) > It mentions the evaluation license in the pdf itself and also points out that the RI, TCK and API is ALv2. Nothing to complain. > > I'd also like to remember where all this discussion started: That it is GOOD that the JSR-330 artifacts (which do not contain a separate spec pdf paper) are all ALv2 and thus we are lucky to be able to just maintain this in a new JSR. The other questions regarding JSR-330 is JCP politics... > > > LieGrue, > strub > > > On Friday, 4 July 2014, 12:27, Pete Muir wrote: > > > The CDI spec lead (Red Hat)?s official position for the CDI specification is clearly covered on http://www.cdi-spec.org/download/ > > If you have any questions regarding this, you will need to contact Red Hat legal. > > On 3 Jul 2014, at 19:33, Werner Keil wrote: > > > I must correct you in the sense, that the license (that "Accept and Download" page) for the Spec is not Apache, though there is practically no spec here for these 6 annotations. > > So it is a bit of a grey zone, and even EC Members with a large legal department are in ongoing discussions over that. The "Spec" and its Software Manifestation (normally all artifacts under "javax.something" or "java.something" (for the few JSRs like 310 that changed their package name in the course of the lifecycle) in Oracle's (the PMO) understanding is under the Spec License. > > > > So strictly speaking annotations under "javax.inject" are the "Spec", not RI or TCK, and therefore they don't fall under Apache 2. Google Guice and the TCK did and still do. > > > > Looking at JSRs like 107 https://github.com/jsr107/jsr107spec or 354, you'll notice they all have this in common. > > Especially the JavaDoc as manifestation of the Spec (and for 330 that is all there is of a Spec) therefore naturally fall under the Spec License, too. > > > > Just see Java EE 7: http://docs.oracle.com/javaee/7/api/ the JavaDoc (for all JSRs within that umbrella) is therefore covered by the EE 7 Spec License > > >Copyright ? 1996-2013, Oracle and/or its affiliates. All Rights Reserved. Use is subject to license terms. > > see the link under "license terms"<329.gif> > > > > JSR 352 poses a stubbern dilemma as its EG and Spec Leads insist on a different license footer in the standalone distribution (Apache 2) as in the overall Java EE 7 umbrella. > > Which is a nightmare for users, a reason I voted against the MR or abstained from this particular JSR as it denies what is reality at least for the Spec and artifacts like the JavaDoc. > > > > CDI refrains from this breach. At least there is no contradicting JavaDoc license pointer. > > > > Red Hat considers a "Dual Licensing" option for the Spec, but from all I heard so far, this is not how Oracle and the JCP PMO (or at least Oracle's lawyers) see this. > > With the proposal of the ULA Oracle tries to get all future JSRs to use a single license for RI and TCK. > > > > There's an ongoing discussion over details, but unless Oracle's legal department and PMO make a dramatic turn on these matters, JSRs filed in the near future (including CDI 2 or beyond) would likely fall under Spec and ULA license. > > > > Cheers, > > Werner > > > > On Thu, Jul 3, 2014 at 8:00 PM, Mark Struberg wrote: > > As far as I know the history (and I have been tracking and contributing to JSR-330 back then) most of the people were fed up _because_ they got pushed to change the license from ALv2 to something else (cannot remember anymore what exactly). > > > > The original Apache v2 licensed work can be found here: > > https://code.google.com/p/atinject/ > > > > I have no clue why Oracle added the 'accept license' radio button on their JSR-330 download page. Maybe just a copy&paste error? The text in this license window is in fact not ALv2 but something else which is wrong information at best. > > > > The good news: ALL the assets in JSR-330 still are ALv2! > > Thus anyone can take it and enhance it. > > Of course it would be good to have Bob and J?rgen on board, but legally it might not even be necessary. > > > > LieGrue, > > strub > > > > > > > > On Thursday, 3 July 2014, 17:35, Werner Keil wrote: > > > > > > I guess with only 5 or 6 annotations (and that's all the JSR consists of;-) if changing/improving only one or two of these was what's needed, this could be easiest as MR, otherwise 330 is history as it would require a new JSR. JSR 330 was under JCP 2.7 and for final JSRs they normally stay there, I don't think it can move to a newer version of the JCP: https://jcp.org/en/resources/guide-maintenance#2_7 > > > > The trouble is, both Spec Leads seem unresponsive or no longer around (Rod Johnson left Pivotal, Pivotal in its current form does not even seem JCP member and VMware may not be able or interested to step in for them) maybe Pete knows best if Bob was, as until JSR 364 or even a new version of the JSPA are finalized he could probably do it if he wants and has the time for this right now (especially if another JSR like CDI 2 depends on it, that can't be delayed even if this JSR may technically still be unaffected by JCP 2.8+) > > > > Except for active corporate members Oracle, Red Hat or IBM the whole EG practically disintegrated. Doug Lea and Tim Peirls may be involved elsewhere (mostly OpenJDK from all I heard) but they have not been active in the JCP or active JSRs recently. Google, we heard gave up the Spec Lead in the first place, so it is unlikely under the current circumstances it will play an active role. Jason VanZyl and Maven I know they at least use JSR 330 quite a bit, so they should at least be interested in its future direction. Thoughtworks I don't recall them to be involved and Martin Fowler himself told me of his "allergy" against such form of standardization, so I would not count on them here either. > > > > So assuming a separate @Inject spec shall be maintained there are 3 options: > > ? Bob Lee (or the other Spec Lead) responds in a timely manner to contact attempts by Antoine and ultimately the PMO (who needs to handle such situations) in which case a simple MR was possible > > ? A replacement of Maintenance Lead, along the lines of https://jcp.org/ja/introduction/faq-speclead#slresigns (it is rarely the case for an MR, but should work pretty much the same way here, so the main candidates to replace a Spec Lead would be in that EG, hence Red Hat, IBM or Oracle for most part;-) If such condition can't be resolved, both PMO and JCP EC would be able to help find a suitable replacement, too > > ? A whole new JSR is filed. Although it is often the case that the Spec Lead(s) are the same, that is not necessary, especially if the old ones moved on or can't do this any more right now. > > HTH, > > Werner > > > > > > On Thu, Jul 3, 2014 at 5:00 PM, Kito Mann wrote: > > My $0.02 is that it's worth the effort to evolve JSR-330 for the community as a whole. I've been on projects where they tend to use those annotations even in a CDI environment, and it makes it much easier to switch between Spring and CDI if necessary. > > > > > > On Wed, Jul 2, 2014 at 4:43 PM, Antoine Sabot-Durand wrote: > > Hi all, > > > > Since the first mention of CDI 2.0 preparation work, we've received a lot of comment about JSR 330 evolution. With the release of the proposal draft yesterday, this topic came up again. So let me give my point of view on this subject to have an open discussion here. > > > > When we started to discuss about modularity with Pete in last november, my first idea was to go see what we could add in JSR 330 to make it a true specification that could be the first module of CDI. My idea at that time was to discuss with JSR 330 owner to see if we could bring basic concept we have in CDI to AtInject spec. In my mind the main features would have been: > > - Enhance the javax.inject.Provider interface to bring it at the same level than javax.enterprise.inject.Instance. That would have included support for AnnotationLiteral and TypeLiteral as well > > - Add a Container interface (a very light BeanManger) in JSR 330 to be able to resolve beans instance from outside managed beans > > - Add a mechanism to get this Container from non managed beans (like we get access to BeanManager from JNDI or CDI class) > > > > At that time, I contacted Bob Lee without success (didn?t tried Pivotal since I don?t have contact there). I checked with JCP what could be done if we?d like to see an evolution of JSR 330 and the owner doesn?t care, there seems to have solutions but I let it aside since we were in the middle of CDI 1.2 MR at that time. > > > > Today I?m a bit torn about this point. Working on opening JSR 330 could be like opening pandora box, since I see 2 scenarios : > > > > 1) former JSR 330 owners wake up and are ok to get for a new spec version they lead: > > Knowing the history of JSR 330 vs JSR 299 I?m not sure everything we?d need would be heard and even if the people leading this would be cooperative, a lot of discussion and negotiation would be needed to be sure that this new AtInject wouldn?t contain features incompatible with CDI. So it?d be very time consuming with no guarantee to get what we?d need at the end. > > > > 2) former JSR 330 owner don?t mind others take ownership of their spec to enhance it and we (Red Hat) are the one to take this ownership to secure CDI: > > The best solution to minimize risk. But leading a new specification is a lot more work than just deciding that we have a specific basic inject ? part ? in CDI 2.0. Leading a spec is very time consuming, so it could be better on the paper but will impact CDI 2.0 new features. > > > > To sum up, as a Java EE user (like I have been for 10 years) I?d be happy to see this (scenario 2), but as CDI spec lead I fear that it could lead us in a trap (going to scenario 1 or consuming precious time on AtInject+1 instead of CDI 2.0) > > > > Your input, solutions or comment would be appreciated on this point. > > > > Antoine > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > From antoine at sabot-durand.net Fri Jul 4 07:40:17 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 4 Jul 2014 13:40:17 +0200 Subject: [cdi-dev] Using Event bus outside CDI In-Reply-To: References: <1404410440.24522.YahooMailNeo@web28903.mail.ir2.yahoo.com> <3CE6FC09-4593-4CE2-8327-32366151DE9E@redhat.com> Message-ID: Hi Nick, I changed the topic since you?re not dealing with the JSR 330 issue. If you check the proposal doc : https://docs.google.com/document/d/1al1rdAs3CN34a9zTe3cXsLL4LBfHhzP8EbuDJ2YQ0qc/edit and the companion doc about part (which again is only an idea of what parts could be) : https://docs.google.com/document/d/1jzCuFQjtCSrnZGRAHjn0oknWvEaP3h0KizW1mHB4AZU/edit You?ll see that I propose to have eventing system as a specific part of CDI enabling other JSR to only implement this part. So we could imagine use CDI event mechanism as an universal event bus across Java EE. So your idea will be discussed after the Expert Group will be formed. If you have precise idea I encourage you to write down a doc / article about it so it?ll feed our discussion when it? ll began. And off course, you?re welcome on the EG or if you can?t/don?t want getting that far involve, on this mailing list. Regards, Antoine Le 4 juil. 2014 ? 12:34, Nick Mpallas a ?crit : > Hi guys, > adding on the discussion of that is the Event mechanism. It would be interesting if we could have the Event injecting mechanism to be injectable by any JSR component. Imagine for example I have a JNDI resource(Another added value here would be allowing JNDI resource handling via annotations) and registering for light CDI events. A pub sub pattern that would imitate something like a bus event mechanism where "components" can register for firing base on events published. The CDI container should provide this lightweight mechanism also in an standalone mode. This would allow for building some nice eventing frameworks on top of CDI that would be available and could integrate really easily with other enterprise components. My 0.00005$ on the discussion. > > regards > Nick > > > On Fri, Jul 4, 2014 at 11:46 AM, Pete Muir wrote: > The CDI spec lead (Red Hat)?s official position for the CDI specification is clearly covered on http://www.cdi-spec.org/download/ > > If you have any questions regarding this, you will need to contact Red Hat legal. > > On 3 Jul 2014, at 19:33, Werner Keil wrote: > > > I must correct you in the sense, that the license (that "Accept and Download" page) for the Spec is not Apache, though there is practically no spec here for these 6 annotations. > > So it is a bit of a grey zone, and even EC Members with a large legal department are in ongoing discussions over that. The "Spec" and its Software Manifestation (normally all artifacts under "javax.something" or "java.something" (for the few JSRs like 310 that changed their package name in the course of the lifecycle) in Oracle's (the PMO) understanding is under the Spec License. > > > > So strictly speaking annotations under "javax.inject" are the "Spec", not RI or TCK, and therefore they don't fall under Apache 2. Google Guice and the TCK did and still do. > > > > Looking at JSRs like 107 https://github.com/jsr107/jsr107spec or 354, you'll notice they all have this in common. > > Especially the JavaDoc as manifestation of the Spec (and for 330 that is all there is of a Spec) therefore naturally fall under the Spec License, too. > > > > Just see Java EE 7: http://docs.oracle.com/javaee/7/api/ the JavaDoc (for all JSRs within that umbrella) is therefore covered by the EE 7 Spec License > > >Copyright ? 1996-2013, Oracle and/or its affiliates. All Rights Reserved. Use is subject to license terms. > > see the link under "license terms"<329.gif> > > > > JSR 352 poses a stubbern dilemma as its EG and Spec Leads insist on a different license footer in the standalone distribution (Apache 2) as in the overall Java EE 7 umbrella. > > Which is a nightmare for users, a reason I voted against the MR or abstained from this particular JSR as it denies what is reality at least for the Spec and artifacts like the JavaDoc. > > > > CDI refrains from this breach. At least there is no contradicting JavaDoc license pointer. > > > > Red Hat considers a "Dual Licensing" option for the Spec, but from all I heard so far, this is not how Oracle and the JCP PMO (or at least Oracle's lawyers) see this. > > With the proposal of the ULA Oracle tries to get all future JSRs to use a single license for RI and TCK. > > > > There's an ongoing discussion over details, but unless Oracle's legal department and PMO make a dramatic turn on these matters, JSRs filed in the near future (including CDI 2 or beyond) would likely fall under Spec and ULA license. > > > > Cheers, > > Werner > > > > On Thu, Jul 3, 2014 at 8:00 PM, Mark Struberg wrote: > > As far as I know the history (and I have been tracking and contributing to JSR-330 back then) most of the people were fed up _because_ they got pushed to change the license from ALv2 to something else (cannot remember anymore what exactly). > > > > The original Apache v2 licensed work can be found here: > > https://code.google.com/p/atinject/ > > > > I have no clue why Oracle added the 'accept license' radio button on their JSR-330 download page. Maybe just a copy&paste error? The text in this license window is in fact not ALv2 but something else which is wrong information at best. > > > > The good news: ALL the assets in JSR-330 still are ALv2! > > Thus anyone can take it and enhance it. > > Of course it would be good to have Bob and J?rgen on board, but legally it might not even be necessary. > > > > LieGrue, > > strub > > > > > > > > On Thursday, 3 July 2014, 17:35, Werner Keil wrote: > > > > > > I guess with only 5 or 6 annotations (and that's all the JSR consists of;-) if changing/improving only one or two of these was what's needed, this could be easiest as MR, otherwise 330 is history as it would require a new JSR. JSR 330 was under JCP 2.7 and for final JSRs they normally stay there, I don't think it can move to a newer version of the JCP: https://jcp.org/en/resources/guide-maintenance#2_7 > > > > The trouble is, both Spec Leads seem unresponsive or no longer around (Rod Johnson left Pivotal, Pivotal in its current form does not even seem JCP member and VMware may not be able or interested to step in for them) maybe Pete knows best if Bob was, as until JSR 364 or even a new version of the JSPA are finalized he could probably do it if he wants and has the time for this right now (especially if another JSR like CDI 2 depends on it, that can't be delayed even if this JSR may technically still be unaffected by JCP 2.8+) > > > > Except for active corporate members Oracle, Red Hat or IBM the whole EG practically disintegrated. Doug Lea and Tim Peirls may be involved elsewhere (mostly OpenJDK from all I heard) but they have not been active in the JCP or active JSRs recently. Google, we heard gave up the Spec Lead in the first place, so it is unlikely under the current circumstances it will play an active role. Jason VanZyl and Maven I know they at least use JSR 330 quite a bit, so they should at least be interested in its future direction. Thoughtworks I don't recall them to be involved and Martin Fowler himself told me of his "allergy" against such form of standardization, so I would not count on them here either. > > > > So assuming a separate @Inject spec shall be maintained there are 3 options: > > ? Bob Lee (or the other Spec Lead) responds in a timely manner to contact attempts by Antoine and ultimately the PMO (who needs to handle such situations) in which case a simple MR was possible > > ? A replacement of Maintenance Lead, along the lines of https://jcp.org/ja/introduction/faq-speclead#slresigns (it is rarely the case for an MR, but should work pretty much the same way here, so the main candidates to replace a Spec Lead would be in that EG, hence Red Hat, IBM or Oracle for most part;-) If such condition can't be resolved, both PMO and JCP EC would be able to help find a suitable replacement, too > > ? A whole new JSR is filed. Although it is often the case that the Spec Lead(s) are the same, that is not necessary, especially if the old ones moved on or can't do this any more right now. > > HTH, > > Werner > > > > > > On Thu, Jul 3, 2014 at 5:00 PM, Kito Mann wrote: > > My $0.02 is that it's worth the effort to evolve JSR-330 for the community as a whole. I've been on projects where they tend to use those annotations even in a CDI environment, and it makes it much easier to switch between Spring and CDI if necessary. > > > > > > On Wed, Jul 2, 2014 at 4:43 PM, Antoine Sabot-Durand wrote: > > Hi all, > > > > Since the first mention of CDI 2.0 preparation work, we've received a lot of comment about JSR 330 evolution. With the release of the proposal draft yesterday, this topic came up again. So let me give my point of view on this subject to have an open discussion here. > > > > When we started to discuss about modularity with Pete in last november, my first idea was to go see what we could add in JSR 330 to make it a true specification that could be the first module of CDI. My idea at that time was to discuss with JSR 330 owner to see if we could bring basic concept we have in CDI to AtInject spec. In my mind the main features would have been: > > - Enhance the javax.inject.Provider interface to bring it at the same level than javax.enterprise.inject.Instance. That would have included support for AnnotationLiteral and TypeLiteral as well > > - Add a Container interface (a very light BeanManger) in JSR 330 to be able to resolve beans instance from outside managed beans > > - Add a mechanism to get this Container from non managed beans (like we get access to BeanManager from JNDI or CDI class) > > > > At that time, I contacted Bob Lee without success (didn?t tried Pivotal since I don?t have contact there). I checked with JCP what could be done if we?d like to see an evolution of JSR 330 and the owner doesn?t care, there seems to have solutions but I let it aside since we were in the middle of CDI 1.2 MR at that time. > > > > Today I?m a bit torn about this point. Working on opening JSR 330 could be like opening pandora box, since I see 2 scenarios : > > > > 1) former JSR 330 owners wake up and are ok to get for a new spec version they lead: > > Knowing the history of JSR 330 vs JSR 299 I?m not sure everything we?d need would be heard and even if the people leading this would be cooperative, a lot of discussion and negotiation would be needed to be sure that this new AtInject wouldn?t contain features incompatible with CDI. So it?d be very time consuming with no guarantee to get what we?d need at the end. > > > > 2) former JSR 330 owner don?t mind others take ownership of their spec to enhance it and we (Red Hat) are the one to take this ownership to secure CDI: > > The best solution to minimize risk. But leading a new specification is a lot more work than just deciding that we have a specific basic inject ? part ? in CDI 2.0. Leading a spec is very time consuming, so it could be better on the paper but will impact CDI 2.0 new features. > > > > To sum up, as a Java EE user (like I have been for 10 years) I?d be happy to see this (scenario 2), but as CDI spec lead I fear that it could lead us in a trap (going to scenario 1 or consuming precious time on AtInject+1 instead of CDI 2.0) > > > > Your input, solutions or comment would be appreciated on this point. > > > > Antoine > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > -- > \n\m > "camel is a horse made up in a laboratory" > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140704/74c020ca/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140704/74c020ca/attachment-0001.bin From werner.keil at gmail.com Fri Jul 4 10:20:24 2014 From: werner.keil at gmail.com (Werner Keil) Date: Fri, 4 Jul 2014 16:20:24 +0200 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: <3CE6FC09-4593-4CE2-8327-32366151DE9E@redhat.com> References: <1404410440.24522.YahooMailNeo@web28903.mail.ir2.yahoo.com> <3CE6FC09-4593-4CE2-8327-32366151DE9E@redhat.com> Message-ID: Mark might thank you for that as he asked about such information earlier. As mentioned earlier I'll leave that to PMO and the IP WG to discuss. I raised the ticket especially in the JIRA system. Whether the WG choses to act on it is up to that WG/JSR. I am speaking at Eclipse DemoCamp VIE today, so I won't join that call, but when I can I'll do and did in the past. As for the EE Umbrella Oracle's generated JavaDoc made rather clear it is considered a part of the Spec, not RI/TCK. As there is no obvious conflict between the JavaDoc in a standalone and packaged form, that is OK for me. If PMO or Oracle Legal has any issues with the statement, the IP WG shall decide. On Fri, Jul 4, 2014 at 11:46 AM, Pete Muir wrote: > The CDI spec lead (Red Hat)?s official position for the CDI specification > is clearly covered on http://www.cdi-spec.org/download/ > > If you have any questions regarding this, you will need to contact Red Hat > legal. > > On 3 Jul 2014, at 19:33, Werner Keil wrote: > > > I must correct you in the sense, that the license (that "Accept and > Download" page) for the Spec is not Apache, though there is practically no > spec here for these 6 annotations. > > So it is a bit of a grey zone, and even EC Members with a large legal > department are in ongoing discussions over that. The "Spec" and its > Software Manifestation (normally all artifacts under "javax.something" or > "java.something" (for the few JSRs like 310 that changed their package name > in the course of the lifecycle) in Oracle's (the PMO) understanding is > under the Spec License. > > > > So strictly speaking annotations under "javax.inject" are the "Spec", > not RI or TCK, and therefore they don't fall under Apache 2. Google Guice > and the TCK did and still do. > > > > Looking at JSRs like 107 https://github.com/jsr107/jsr107spec or 354, > you'll notice they all have this in common. > > Especially the JavaDoc as manifestation of the Spec (and for 330 that > is all there is of a Spec) therefore naturally fall under the Spec License, > too. > > > > Just see Java EE 7: http://docs.oracle.com/javaee/7/api/ the JavaDoc > (for all JSRs within that umbrella) is therefore covered by the EE 7 Spec > License > > >Copyright ? 1996-2013, Oracle and/or its affiliates. All Rights > Reserved. Use is subject to license terms. > > see the link under "license terms"<329.gif> > > > > JSR 352 poses a stubbern dilemma as its EG and Spec Leads insist on a > different license footer in the standalone distribution (Apache 2) as in > the overall Java EE 7 umbrella. > > Which is a nightmare for users, a reason I voted against the MR or > abstained from this particular JSR as it denies what is reality at least > for the Spec and artifacts like the JavaDoc. > > > > CDI refrains from this breach. At least there is no contradicting > JavaDoc license pointer. > > > > Red Hat considers a "Dual Licensing" option for the Spec, but from all I > heard so far, this is not how Oracle and the JCP PMO (or at least Oracle's > lawyers) see this. > > With the proposal of the ULA Oracle tries to get all future JSRs to use > a single license for RI and TCK. > > > > There's an ongoing discussion over details, but unless Oracle's legal > department and PMO make a dramatic turn on these matters, JSRs filed in the > near future (including CDI 2 or beyond) would likely fall under Spec and > ULA license. > > > > Cheers, > > Werner > > > > On Thu, Jul 3, 2014 at 8:00 PM, Mark Struberg wrote: > > As far as I know the history (and I have been tracking and contributing > to JSR-330 back then) most of the people were fed up _because_ they got > pushed to change the license from ALv2 to something else (cannot remember > anymore what exactly). > > > > The original Apache v2 licensed work can be found here: > > https://code.google.com/p/atinject/ > > > > I have no clue why Oracle added the 'accept license' radio button on > their JSR-330 download page. Maybe just a copy&paste error? The text in > this license window is in fact not ALv2 but something else which is wrong > information at best. > > > > The good news: ALL the assets in JSR-330 still are ALv2! > > Thus anyone can take it and enhance it. > > Of course it would be good to have Bob and J?rgen on board, but legally > it might not even be necessary. > > > > LieGrue, > > strub > > > > > > > > On Thursday, 3 July 2014, 17:35, Werner Keil > wrote: > > > > > > I guess with only 5 or 6 annotations (and that's all the JSR consists > of;-) if changing/improving only one or two of these was what's needed, > this could be easiest as MR, otherwise 330 is history as it would require a > new JSR. JSR 330 was under JCP 2.7 and for final JSRs they normally stay > there, I don't think it can move to a newer version of the JCP: > https://jcp.org/en/resources/guide-maintenance#2_7 > > > > The trouble is, both Spec Leads seem unresponsive or no longer around > (Rod Johnson left Pivotal, Pivotal in its current form does not even seem > JCP member and VMware may not be able or interested to step in for them) > maybe Pete knows best if Bob was, as until JSR 364 or even a new version of > the JSPA are finalized he could probably do it if he wants and has the time > for this right now (especially if another JSR like CDI 2 depends on it, > that can't be delayed even if this JSR may technically still be unaffected > by JCP 2.8+) > > > > Except for active corporate members Oracle, Red Hat or IBM the whole EG > practically disintegrated. Doug Lea and Tim Peirls may be involved > elsewhere (mostly OpenJDK from all I heard) but they have not been active > in the JCP or active JSRs recently. Google, we heard gave up the Spec Lead > in the first place, so it is unlikely under the current circumstances it > will play an active role. Jason VanZyl and Maven I know they at least use > JSR 330 quite a bit, so they should at least be interested in its future > direction. Thoughtworks I don't recall them to be involved and Martin > Fowler himself told me of his "allergy" against such form of > standardization, so I would not count on them here either. > > > > So assuming a separate @Inject spec shall be maintained there are 3 > options: > > ? Bob Lee (or the other Spec Lead) responds in a timely manner to > contact attempts by Antoine and ultimately the PMO (who needs to handle > such situations) in which case a simple MR was possible > > ? A replacement of Maintenance Lead, along the lines of > https://jcp.org/ja/introduction/faq-speclead#slresigns (it is rarely the > case for an MR, but should work pretty much the same way here, so the main > candidates to replace a Spec Lead would be in that EG, hence Red Hat, IBM > or Oracle for most part;-) If such condition can't be resolved, both PMO > and JCP EC would be able to help find a suitable replacement, too > > ? A whole new JSR is filed. Although it is often the case that the > Spec Lead(s) are the same, that is not necessary, especially if the old > ones moved on or can't do this any more right now. > > HTH, > > Werner > > > > > > On Thu, Jul 3, 2014 at 5:00 PM, Kito Mann > wrote: > > My $0.02 is that it's worth the effort to evolve JSR-330 for the > community as a whole. I've been on projects where they tend to use those > annotations even in a CDI environment, and it makes it much easier to > switch between Spring and CDI if necessary. > > > > > > On Wed, Jul 2, 2014 at 4:43 PM, Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > > Hi all, > > > > Since the first mention of CDI 2.0 preparation work, we've received a > lot of comment about JSR 330 evolution. With the release of the proposal > draft yesterday, this topic came up again. So let me give my point of view > on this subject to have an open discussion here. > > > > When we started to discuss about modularity with Pete in last november, > my first idea was to go see what we could add in JSR 330 to make it a true > specification that could be the first module of CDI. My idea at that time > was to discuss with JSR 330 owner to see if we could bring basic concept we > have in CDI to AtInject spec. In my mind the main features would have been: > > - Enhance the javax.inject.Provider interface to bring it at the > same level than javax.enterprise.inject.Instance. That would have > included support for AnnotationLiteral and TypeLiteral as well > > - Add a Container interface (a very light BeanManger) in JSR 330 to be > able to resolve beans instance from outside managed beans > > - Add a mechanism to get this Container from non managed beans (like we > get access to BeanManager from JNDI or CDI class) > > > > At that time, I contacted Bob Lee without success (didn?t tried Pivotal > since I don?t have contact there). I checked with JCP what could be done if > we?d like to see an evolution of JSR 330 and the owner doesn?t care, there > seems to have solutions but I let it aside since we were in the middle of > CDI 1.2 MR at that time. > > > > Today I?m a bit torn about this point. Working on opening JSR 330 could > be like opening pandora box, since I see 2 scenarios : > > > > 1) former JSR 330 owners wake up and are ok to get for a new spec > version they lead: > > Knowing the history of JSR 330 vs JSR 299 I?m not sure everything we?d > need would be heard and even if the people leading this would be > cooperative, a lot of discussion and negotiation would be needed to be sure > that this new AtInject wouldn?t contain features incompatible with CDI. So > it?d be very time consuming with no guarantee to get what we?d need at the > end. > > > > 2) former JSR 330 owner don?t mind others take ownership of their spec > to enhance it and we (Red Hat) are the one to take this ownership to secure > CDI: > > The best solution to minimize risk. But leading a new specification is a > lot more work than just deciding that we have a specific basic inject ? > part ? in CDI 2.0. Leading a spec is very time consuming, so it could be > better on the paper but will impact CDI 2.0 new features. > > > > To sum up, as a Java EE user (like I have been for 10 years) I?d be > happy to see this (scenario 2), but as CDI spec lead I fear that it could > lead us in a trap (going to scenario 1 or consuming precious time on > AtInject+1 instead of CDI 2.0) > > > > Your input, solutions or comment would be appreciated on this point. > > > > Antoine > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140704/27da1546/attachment.html From werner.keil at gmail.com Fri Jul 4 10:26:16 2014 From: werner.keil at gmail.com (Werner Keil) Date: Fri, 4 Jul 2014 16:26:16 +0200 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: <1404471687.99802.YahooMailNeo@web28901.mail.ir2.yahoo.com> References: <1404410440.24522.YahooMailNeo@web28903.mail.ir2.yahoo.com> <3CE6FC09-4593-4CE2-8327-32366151DE9E@redhat.com> <1404471687.99802.YahooMailNeo@web28901.mail.ir2.yahoo.com> Message-ID: If you file it very soon, see JSR 363 (we also use Apache but only for distinct RI/TCK deliverables, we were told so by PMO for 275 and stick to that, we only changed to Apache for RI/TCK because Spec Lead V2COM recommended it and no EG Members had an issue with that) you might be able to do that. At some point, probably not before JSR 358 concludes JSRs filed than, also CDI 3 or 2.x might have to chose ULA. I can't say how Oracle and PMO treats updates of prior JSRs, maybe they are allowed to stick to their "old" license, maybe Oracle / PMO will force them to migrate. JSPA.next will tell. Werner On Fri, Jul 4, 2014 at 1:01 PM, Mark Struberg wrote: > Imo the CDI spec is clean in this regard. It mentions the evaluation > license in the pdf itself and also points out that the RI, TCK and API is > ALv2. Nothing to complain. > > I'd also like to remember where all this discussion started: That it is > GOOD that the JSR-330 artifacts (which do not contain a separate spec pdf > paper) are all ALv2 and thus we are lucky to be able to just maintain this > in a new JSR. The other questions regarding JSR-330 is JCP politics... > > > LieGrue, > strub > > > On Friday, 4 July 2014, 12:27, Pete Muir wrote: > > > > The CDI spec lead (Red Hat)?s official position for the CDI specification > is clearly covered on http://www.cdi-spec.org/download/ > > If you have any questions regarding this, you will need to contact Red Hat > legal. > > On 3 Jul 2014, at 19:33, Werner Keil wrote: > > > I must correct you in the sense, that the license (that "Accept and > Download" page) for the Spec is not Apache, though there is practically no > spec here for these 6 annotations. > > So it is a bit of a grey zone, and even EC Members with a large legal > department are in ongoing discussions over that. The "Spec" and its > Software Manifestation (normally all artifacts under "javax.something" or > "java.something" (for the few JSRs like 310 that changed their package name > in the course of the lifecycle) in Oracle's (the PMO) understanding is > under the Spec License. > > > > So strictly speaking annotations under "javax.inject" are the "Spec", > not RI or TCK, and therefore they don't fall under Apache 2. Google Guice > and the TCK did and still do. > > > > Looking at JSRs like 107 https://github.com/jsr107/jsr107spec or 354, > you'll notice they all have this in common. > > Especially the JavaDoc as manifestation of the Spec (and for 330 that > is all there is of a Spec) therefore naturally fall under the Spec License, > too. > > > > Just see Java EE 7: http://docs.oracle.com/javaee/7/api/ the JavaDoc > (for all JSRs within that umbrella) is therefore covered by the EE 7 Spec > License > > >Copyright ? 1996-2013, Oracle and/or its affiliates. All Rights > Reserved. Use is subject to license terms. > > see the link under "license terms"<329.gif> > > > > JSR 352 poses a stubbern dilemma as its EG and Spec Leads insist on a > different license footer in the standalone distribution (Apache 2) as in > the overall Java EE 7 umbrella. > > Which is a nightmare for users, a reason I voted against the MR or > abstained from this particular JSR as it denies what is reality at least > for the Spec and artifacts like the JavaDoc. > > > > CDI refrains from this breach. At least there is no contradicting > JavaDoc license pointer. > > > > Red Hat considers a "Dual Licensing" option for the Spec, but from all I > heard so far, this is not how Oracle and the JCP PMO (or at least Oracle's > lawyers) see this. > > With the proposal of the ULA Oracle tries to get all future JSRs to use > a single license for RI and TCK. > > > > There's an ongoing discussion over details, but unless Oracle's legal > department and PMO make a dramatic turn on these matters, JSRs filed in the > near future (including CDI 2 or beyond) would likely fall under Spec and > ULA license. > > > > Cheers, > > Werner > > > > On Thu, Jul 3, 2014 at 8:00 PM, Mark Struberg wrote: > > As far as I know the history (and I have been tracking and contributing > to JSR-330 back then) most of the people were fed up _because_ they got > pushed to change the license from ALv2 to something else (cannot remember > anymore what exactly). > > > > The original Apache v2 licensed work can be found here: > > https://code.google.com/p/atinject/ > > > > I have no clue why Oracle added the 'accept license' radio button on > their JSR-330 download page. Maybe just a copy&paste error? The text in > this license window is in fact not ALv2 but something else which is wrong > information at best. > > > > The good news: ALL the assets in JSR-330 still are ALv2! > > Thus anyone can take it and enhance it. > > Of course it would be good to have Bob and J?rgen on board, but legally > it might not even be necessary. > > > > LieGrue, > > strub > > > > > > > > On Thursday, 3 July 2014, 17:35, Werner Keil > wrote: > > > > > > I guess with only 5 or 6 annotations (and that's all the JSR consists > of;-) if changing/improving only one or two of these was what's needed, > this could be easiest as MR, otherwise 330 is history as it would require a > new JSR. JSR 330 was under JCP 2.7 and for final JSRs they normally stay > there, I don't think it can move to a newer version of the JCP: > https://jcp.org/en/resources/guide-maintenance#2_7 > > > > The trouble is, both Spec Leads seem unresponsive or no longer around > (Rod Johnson left Pivotal, Pivotal in its current form does not even seem > JCP member and VMware may not be able or interested to step in for them) > maybe Pete knows best if Bob was, as until JSR 364 or even a new version of > the JSPA are finalized he could probably do it if he wants and has the time > for this right now (especially if another JSR like CDI 2 depends on it, > that can't be delayed even if this JSR may technically still be unaffected > by JCP 2.8+) > > > > Except for active corporate members Oracle, Red Hat or IBM the whole EG > practically disintegrated. Doug Lea and Tim Peirls may be involved > elsewhere (mostly OpenJDK from all I heard) but they have not been active > in the JCP or active JSRs recently. Google, we heard gave up the Spec Lead > in the first place, so it is unlikely under the current circumstances it > will play an active role. Jason VanZyl and Maven I know they at least use > JSR 330 quite a bit, so they should at least be interested in its future > direction. Thoughtworks I don't recall them to be involved and Martin > Fowler himself told me of his "allergy" against such form of > standardization, so I would not count on them here either. > > > > So assuming a separate @Inject spec shall be maintained there are 3 > options: > > ? Bob Lee (or the other Spec Lead) responds in a timely manner to > contact attempts by Antoine and ultimately the PMO (who needs to handle > such situations) in which case a simple MR was possible > > ? A replacement of Maintenance Lead, along the lines of https://jcp.org/ja/introduction/faq-speclead#slresigns > (it is rarely the case for an MR, but should work pretty much the same way > here, so the main candidates to replace a Spec Lead would be in that EG, > hence Red Hat, IBM or Oracle for most part;-) If such condition can't be > resolved, both PMO and JCP EC would be able to help find a suitable > replacement, too > > ? A whole new JSR is filed. Although it is often the case that the > Spec Lead(s) are the same, that is not necessary, especially if the old > ones moved on or can't do this any more right now. > > HTH, > > Werner > > > > > > On Thu, Jul 3, 2014 at 5:00 PM, Kito Mann > wrote: > > My $0.02 is that it's worth the effort to evolve JSR-330 for the > community as a whole. I've been on projects where they tend to use those > annotations even in a CDI environment, and it makes it much easier to > switch between Spring and CDI if necessary. > > > > > > On Wed, Jul 2, 2014 at 4:43 PM, Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > > Hi all, > > > > Since the first mention of CDI 2.0 preparation work, we've received a > lot of comment about JSR 330 evolution. With the release of the proposal > draft yesterday, this topic came up again. So let me give my point of view > on this subject to have an open discussion here. > > > > When we started to discuss about modularity with Pete in last november, > my first idea was to go see what we could add in JSR 330 to make it a true > specification that could be the first module of CDI. My idea at that time > was to discuss with JSR 330 owner to see if we could bring basic concept we > have in CDI to AtInject spec. In my mind the main features would have been: > > - Enhance the javax.inject.Provider interface to bring it at the > same level than javax.enterprise.inject.Instance. That would have > included support for AnnotationLiteral and TypeLiteral as well > > - Add a Container interface (a very light BeanManger) in JSR 330 to be > able to resolve beans instance from outside managed beans > > - Add a mechanism to get this Container from non managed beans (like we > get access to BeanManager from JNDI or CDI class) > > > > At that time, I contacted Bob Lee without success (didn?t tried Pivotal > since I don?t have contact there). I checked with JCP what could be done if > we?d like to see an evolution of JSR 330 and the owner doesn?t care, there > seems to have solutions but I let it aside since we were in the middle of > CDI 1.2 MR at that time. > > > > Today I?m a bit torn about this point. Working on opening JSR 330 could > be like opening pandora box, since I see 2 scenarios : > > > > 1) former JSR 330 owners wake up and are ok to get for a new spec > version they lead: > > Knowing the history of JSR 330 vs JSR 299 I?m not sure everything we?d > need would be heard and even if the people leading this would be > cooperative, a lot of discussion and negotiation would be needed to be sure > that this new AtInject wouldn?t contain features incompatible with CDI. So > it?d be very time consuming with no guarantee to get what we?d need at the > end. > > > > 2) former JSR 330 owner don?t mind others take ownership of their spec > to enhance it and we (Red Hat) are the one to take this ownership to secure > CDI: > > The best solution to minimize risk. But leading a new specification is a > lot more work than just deciding that we have a specific basic inject ? > part ? in CDI 2.0. Leading a spec is very time consuming, so it could be > better on the paper but will impact CDI 2.0 new features. > > > > To sum up, as a Java EE user (like I have been for 10 years) I?d be > happy to see this (scenario 2), but as CDI spec lead I fear that it could > lead us in a trap (going to scenario 1 or consuming precious time on > AtInject+1 instead of CDI 2.0) > > > > Your input, solutions or comment would be appreciated on this point. > > > > Antoine > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140704/e2b2e7c0/attachment-0001.html From pmuir at redhat.com Fri Jul 4 12:44:14 2014 From: pmuir at redhat.com (Pete Muir) Date: Fri, 4 Jul 2014 17:44:14 +0100 Subject: [cdi-dev] About JSR 330.Next and CDI 2.0 In-Reply-To: References: <1404410440.24522.YahooMailNeo@web28903.mail.ir2.yahoo.com> <3CE6FC09-4593-4CE2-8327-32366151DE9E@redhat.com> <1404471687.99802.YahooMailNeo@web28901.mail.ir2.yahoo.com> Message-ID: <41561E34-7117-4DF1-B97B-F19C6ACCB1D8@redhat.com> Oracle have indicated they support this proposal in it?s current form with it?s current licensing arrangements. I can?t and won?t comment on what may happen it the future. On 4 Jul 2014, at 15:26, Werner Keil wrote: > If you file it very soon, see JSR 363 (we also use Apache but only for distinct RI/TCK deliverables, we were told so by PMO for 275 and stick to that, we only changed to Apache for RI/TCK because Spec Lead V2COM recommended it and no EG Members had an issue with that) you might be able to do that. At some point, probably not before JSR 358 concludes JSRs filed than, also CDI 3 or 2.x might have to chose ULA. I can't say how Oracle and PMO treats updates of prior JSRs, maybe they are allowed to stick to their "old" license, maybe Oracle / PMO will force them to migrate. JSPA.next will tell. > > Werner > > On Fri, Jul 4, 2014 at 1:01 PM, Mark Struberg wrote: > Imo the CDI spec is clean in this regard. It mentions the evaluation license in the pdf itself and also points out that the RI, TCK and API is ALv2. Nothing to complain. > > I'd also like to remember where all this discussion started: That it is GOOD that the JSR-330 artifacts (which do not contain a separate spec pdf paper) are all ALv2 and thus we are lucky to be able to just maintain this in a new JSR. The other questions regarding JSR-330 is JCP politics... > > > LieGrue, > strub > > > On Friday, 4 July 2014, 12:27, Pete Muir wrote: > > > The CDI spec lead (Red Hat)?s official position for the CDI specification is clearly covered on http://www.cdi-spec.org/download/ > > If you have any questions regarding this, you will need to contact Red Hat legal. > > On 3 Jul 2014, at 19:33, Werner Keil wrote: > > > I must correct you in the sense, that the license (that "Accept and Download" page) for the Spec is not Apache, though there is practically no spec here for these 6 annotations. > > So it is a bit of a grey zone, and even EC Members with a large legal department are in ongoing discussions over that. The "Spec" and its Software Manifestation (normally all artifacts under "javax.something" or "java.something" (for the few JSRs like 310 that changed their package name in the course of the lifecycle) in Oracle's (the PMO) understanding is under the Spec License. > > > > So strictly speaking annotations under "javax.inject" are the "Spec", not RI or TCK, and therefore they don't fall under Apache 2. Google Guice and the TCK did and still do. > > > > Looking at JSRs like 107 https://github.com/jsr107/jsr107spec or 354, you'll notice they all have this in common. > > Especially the JavaDoc as manifestation of the Spec (and for 330 that is all there is of a Spec) therefore naturally fall under the Spec License, too. > > > > Just see Java EE 7: http://docs.oracle.com/javaee/7/api/ the JavaDoc (for all JSRs within that umbrella) is therefore covered by the EE 7 Spec License > > >Copyright ? 1996-2013, Oracle and/or its affiliates. All Rights Reserved. Use is subject to license terms. > > see the link under "license terms"<329.gif> > > > > JSR 352 poses a stubbern dilemma as its EG and Spec Leads insist on a different license footer in the standalone distribution (Apache 2) as in the overall Java EE 7 umbrella. > > Which is a nightmare for users, a reason I voted against the MR or abstained from this particular JSR as it denies what is reality at least for the Spec and artifacts like the JavaDoc. > > > > CDI refrains from this breach. At least there is no contradicting JavaDoc license pointer. > > > > Red Hat considers a "Dual Licensing" option for the Spec, but from all I heard so far, this is not how Oracle and the JCP PMO (or at least Oracle's lawyers) see this. > > With the proposal of the ULA Oracle tries to get all future JSRs to use a single license for RI and TCK. > > > > There's an ongoing discussion over details, but unless Oracle's legal department and PMO make a dramatic turn on these matters, JSRs filed in the near future (including CDI 2 or beyond) would likely fall under Spec and ULA license. > > > > Cheers, > > Werner > > > > On Thu, Jul 3, 2014 at 8:00 PM, Mark Struberg wrote: > > As far as I know the history (and I have been tracking and contributing to JSR-330 back then) most of the people were fed up _because_ they got pushed to change the license from ALv2 to something else (cannot remember anymore what exactly). > > > > The original Apache v2 licensed work can be found here: > > https://code.google.com/p/atinject/ > > > > I have no clue why Oracle added the 'accept license' radio button on their JSR-330 download page. Maybe just a copy&paste error? The text in this license window is in fact not ALv2 but something else which is wrong information at best. > > > > The good news: ALL the assets in JSR-330 still are ALv2! > > Thus anyone can take it and enhance it. > > Of course it would be good to have Bob and J?rgen on board, but legally it might not even be necessary. > > > > LieGrue, > > strub > > > > > > > > On Thursday, 3 July 2014, 17:35, Werner Keil wrote: > > > > > > I guess with only 5 or 6 annotations (and that's all the JSR consists of;-) if changing/improving only one or two of these was what's needed, this could be easiest as MR, otherwise 330 is history as it would require a new JSR. JSR 330 was under JCP 2.7 and for final JSRs they normally stay there, I don't think it can move to a newer version of the JCP: https://jcp.org/en/resources/guide-maintenance#2_7 > > > > The trouble is, both Spec Leads seem unresponsive or no longer around (Rod Johnson left Pivotal, Pivotal in its current form does not even seem JCP member and VMware may not be able or interested to step in for them) maybe Pete knows best if Bob was, as until JSR 364 or even a new version of the JSPA are finalized he could probably do it if he wants and has the time for this right now (especially if another JSR like CDI 2 depends on it, that can't be delayed even if this JSR may technically still be unaffected by JCP 2.8+) > > > > Except for active corporate members Oracle, Red Hat or IBM the whole EG practically disintegrated. Doug Lea and Tim Peirls may be involved elsewhere (mostly OpenJDK from all I heard) but they have not been active in the JCP or active JSRs recently. Google, we heard gave up the Spec Lead in the first place, so it is unlikely under the current circumstances it will play an active role. Jason VanZyl and Maven I know they at least use JSR 330 quite a bit, so they should at least be interested in its future direction. Thoughtworks I don't recall them to be involved and Martin Fowler himself told me of his "allergy" against such form of standardization, so I would not count on them here either. > > > > So assuming a separate @Inject spec shall be maintained there are 3 options: > > ? Bob Lee (or the other Spec Lead) responds in a timely manner to contact attempts by Antoine and ultimately the PMO (who needs to handle such situations) in which case a simple MR was possible > > ? A replacement of Maintenance Lead, along the lines of https://jcp.org/ja/introduction/faq-speclead#slresigns (it is rarely the case for an MR, but should work pretty much the same way here, so the main candidates to replace a Spec Lead would be in that EG, hence Red Hat, IBM or Oracle for most part;-) If such condition can't be resolved, both PMO and JCP EC would be able to help find a suitable replacement, too > > ? A whole new JSR is filed. Although it is often the case that the Spec Lead(s) are the same, that is not necessary, especially if the old ones moved on or can't do this any more right now. > > HTH, > > Werner > > > > > > On Thu, Jul 3, 2014 at 5:00 PM, Kito Mann wrote: > > My $0.02 is that it's worth the effort to evolve JSR-330 for the community as a whole. I've been on projects where they tend to use those annotations even in a CDI environment, and it makes it much easier to switch between Spring and CDI if necessary. > > > > > > On Wed, Jul 2, 2014 at 4:43 PM, Antoine Sabot-Durand wrote: > > Hi all, > > > > Since the first mention of CDI 2.0 preparation work, we've received a lot of comment about JSR 330 evolution. With the release of the proposal draft yesterday, this topic came up again. So let me give my point of view on this subject to have an open discussion here. > > > > When we started to discuss about modularity with Pete in last november, my first idea was to go see what we could add in JSR 330 to make it a true specification that could be the first module of CDI. My idea at that time was to discuss with JSR 330 owner to see if we could bring basic concept we have in CDI to AtInject spec. In my mind the main features would have been: > > - Enhance the javax.inject.Provider interface to bring it at the same level than javax.enterprise.inject.Instance. That would have included support for AnnotationLiteral and TypeLiteral as well > > - Add a Container interface (a very light BeanManger) in JSR 330 to be able to resolve beans instance from outside managed beans > > - Add a mechanism to get this Container from non managed beans (like we get access to BeanManager from JNDI or CDI class) > > > > At that time, I contacted Bob Lee without success (didn?t tried Pivotal since I don?t have contact there). I checked with JCP what could be done if we?d like to see an evolution of JSR 330 and the owner doesn?t care, there seems to have solutions but I let it aside since we were in the middle of CDI 1.2 MR at that time. > > > > Today I?m a bit torn about this point. Working on opening JSR 330 could be like opening pandora box, since I see 2 scenarios : > > > > 1) former JSR 330 owners wake up and are ok to get for a new spec version they lead: > > Knowing the history of JSR 330 vs JSR 299 I?m not sure everything we?d need would be heard and even if the people leading this would be cooperative, a lot of discussion and negotiation would be needed to be sure that this new AtInject wouldn?t contain features incompatible with CDI. So it?d be very time consuming with no guarantee to get what we?d need at the end. > > > > 2) former JSR 330 owner don?t mind others take ownership of their spec to enhance it and we (Red Hat) are the one to take this ownership to secure CDI: > > The best solution to minimize risk. But leading a new specification is a lot more work than just deciding that we have a specific basic inject ? part ? in CDI 2.0. Leading a spec is very time consuming, so it could be better on the paper but will impact CDI 2.0 new features. > > > > To sum up, as a Java EE user (like I have been for 10 years) I?d be happy to see this (scenario 2), but as CDI spec lead I fear that it could lead us in a trap (going to scenario 1 or consuming precious time on AtInject+1 instead of CDI 2.0) > > > > Your input, solutions or comment would be appreciated on this point. > > > > Antoine > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > From struberg at yahoo.de Tue Jul 8 02:58:59 2014 From: struberg at yahoo.de (Mark Struberg) Date: Tue, 8 Jul 2014 07:58:59 +0100 Subject: [cdi-dev] InjectionPoint when injecting into Decorators Message-ID: <1404802739.30206.YahooMailNeo@web28903.mail.ir2.yahoo.com> Hi! I struggle with a few TCK tests which assume that in Decorators and Interceptors you can have an @Inject ct which has a valid InjectionPoint. But I cannot find in the spec how this is supposed to work. 5.5.7 defines in which situations the CDI container must create an InjectionPoint: ---- An instance of InjectionPoint may represent: ? an injected field or a parameter of a bean constructor, initializer method, producer method, disposer method or observer method, or ? an instance obtained dynamically using Instance.get(). ---- But if you e.g. look at? ? ? @Inject ? ? public OrderedEventDeliveryDecorator(@Delegate Event delegate, InjectionPoint ip, BeanManager manager, ? ? ? ? ? ? OrderedEventDeliveryExtension extension) ? ? ? ? ? ?? then this does not fit any requirement imo. Because the Decorator is a dependent bean on the decorated contextual instance. Thus it's 'internal' and does not have any InjectionPoint. This would be different if you would @Inject the Decorator into some other bean... The TCK test in question is ComplexEventDecoratorTest#testOrderedEvents Did I overlook something? LieGrue, strub -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140708/8f6c7bc6/attachment.html From jharting at redhat.com Tue Jul 8 03:32:43 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Tue, 08 Jul 2014 09:32:43 +0200 Subject: [cdi-dev] InjectionPoint when injecting into Decorators In-Reply-To: <1404802739.30206.YahooMailNeo@web28903.mail.ir2.yahoo.com> References: <1404802739.30206.YahooMailNeo@web28903.mail.ir2.yahoo.com> Message-ID: <53BB9E9B.6000302@redhat.com> This was supposed to be fixed by https://issues.jboss.org/browse/CDI-78 (see https://github.com/cdi-spec/cdi/pull/21/files) but it seems the proposed changes never actually got to the specification although the issue is marked as resolved :-/ Jozef On 07/08/2014 08:58 AM, Mark Struberg wrote: > Hi! > > I struggle with a few TCK tests which assume that in Decorators and > Interceptors you can have an @Inject ct which has a valid InjectionPoint. > But I cannot find in the spec how this is supposed to work. > > 5.5.7 defines in which situations the CDI container must create an > InjectionPoint: > > ---- > An instance of InjectionPoint may represent: > . an injected field or a parameter of a bean constructor, initializer > method, producer method, disposer method or observer method, or > . an instance obtained dynamically using Instance.get(). > ---- > > But if you e.g. look at > > @Inject > public OrderedEventDeliveryDecorator(@Delegate Event delegate, > InjectionPoint ip, BeanManager manager, > OrderedEventDeliveryExtension extension) > then this does not fit any requirement imo. Because the Decorator is a > dependent bean on the decorated contextual instance. > Thus it's 'internal' and does not have any InjectionPoint. This would > be different if you would @Inject the Decorator into some other bean... > > The TCK test in question is ComplexEventDecoratorTest#testOrderedEvents > > Did I overlook something? > > LieGrue, > strub > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140708/cb19ff7c/attachment-0001.html From issues at jboss.org Tue Jul 8 03:45:26 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Tue, 8 Jul 2014 03:45:26 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-78) Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jozef Hartinger reopened CDI-78: -------------------------------- Reopening as this issue seems to have never actually been resolved. > Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator > ------------------------------------------------------------------------------------------------------------------------ > > Key: CDI-78 > URL: https://issues.jboss.org/browse/CDI-78 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Decorators > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.PFD > > > The InjectionPoint should be that of the injection into the consumer, and isDelegate() should return false. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 03:47:24 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Tue, 8 Jul 2014 03:47:24 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-78) Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jozef Hartinger updated CDI-78: ------------------------------- Fix Version/s: (was: 1.1.PFD) > Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator > ------------------------------------------------------------------------------------------------------------------------ > > Key: CDI-78 > URL: https://issues.jboss.org/browse/CDI-78 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Decorators > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > > The InjectionPoint should be that of the injection into the consumer, and isDelegate() should return false. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 28 10:53:33 2014 From: issues at jboss.org (Rafael Sisto (JIRA)) Date: Mon, 28 Jul 2014 10:53:33 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-414) Support for "self" injection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988341#comment-12988341 ] Rafael Sisto commented on CDI-414: ---------------------------------- I'm facing this limitation right now in JBoss EAP 6.1 The injection actually works, but the aspects (i.e.: Interceptors) are not applied. For example, I have this scenario: @Named @RequestScoped public class MyBean { @Inject private MyBean self; @Interceptors(InterceptorA.class) public void methodA() { self.methodB(); } @Interceptors(InterceptorB.class) public void methodB() { System.out.println("extra"); } } When I call methodA, InterceptorA is called, but when this method calls methodB, the InterceptorB is never called. > Support for "self" injection > ---------------------------- > > Key: CDI-414 > URL: https://issues.jboss.org/browse/CDI-414 > Project: CDI Specification Issues > Issue Type: Bug > Components: Resolution > Reporter: arjan tijms > > Many features of CDI and EJB work by means of a proxy that intercepts calls and adds 'aspects'. In Java it's however not possible to decorate the {{this}} pointer, so methods called on the same bean instance from within a method in the bean do not get their 'aspects' applied. > This is a well known limitation, but in EJB it's possible to work around this by injecting a bean into itself. E.g. > {code} > @Stateless > public class Foo { > @EJB > private Foo self; > // ... > } > {code} > Also see http://adam-bien.com/roller/abien/entry/how_to_self_invoke_ejb > Unfortunately using CDI and {{@Inject}} this doesn't work. Weld for instance fails the deployment and logs: > {noformat} > WELD-001443 Pseudo scoped bean has circular dependencies. > {noformat} > See also: http://adam-bien.com/roller/abien/entry/inject_vs_ejb > Although there are workarounds, it would be great if {{@Inject}} in combination with CDI could support self injection as well. > With that projects migrating from {{@EJB}} to {{@Inject}} can do so more easily and the capability can be convenient for new projects as well (e.g. calling two separate {{@Transactional}} methods from a single method without being required to create a new bean). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 04:48:30 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 29 Jul 2014 04:48:30 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-414) Support for "self" injection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988542#comment-12988542 ] Antoine Sabot-Durand commented on CDI-414: ------------------------------------------ IMO, the best solution would be to support inner call AOP in CDI (instead of crappy self-injection). [~jharting] told me once that it was possible in the RI and that we chose to avoid this behavior to be consistent with EJB. Probably a topic to discuss for CDI 2.0. > Support for "self" injection > ---------------------------- > > Key: CDI-414 > URL: https://issues.jboss.org/browse/CDI-414 > Project: CDI Specification Issues > Issue Type: Bug > Components: Resolution > Reporter: arjan tijms > > Many features of CDI and EJB work by means of a proxy that intercepts calls and adds 'aspects'. In Java it's however not possible to decorate the {{this}} pointer, so methods called on the same bean instance from within a method in the bean do not get their 'aspects' applied. > This is a well known limitation, but in EJB it's possible to work around this by injecting a bean into itself. E.g. > {code} > @Stateless > public class Foo { > @EJB > private Foo self; > // ... > } > {code} > Also see http://adam-bien.com/roller/abien/entry/how_to_self_invoke_ejb > Unfortunately using CDI and {{@Inject}} this doesn't work. Weld for instance fails the deployment and logs: > {noformat} > WELD-001443 Pseudo scoped bean has circular dependencies. > {noformat} > See also: http://adam-bien.com/roller/abien/entry/inject_vs_ejb > Although there are workarounds, it would be great if {{@Inject}} in combination with CDI could support self injection as well. > With that projects migrating from {{@EJB}} to {{@Inject}} can do so more easily and the capability can be convenient for new projects as well (e.g. calling two separate {{@Transactional}} methods from a single method without being required to create a new bean). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 05:24:30 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 29 Jul 2014 05:24:30 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-21) Support PostConstruct callbacks in Extension class In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-21: ------------------------------------ Fix Version/s: 2.0 (discussion) (was: TBD) > Support PostConstruct callbacks in Extension class > -------------------------------------------------- > > Key: CDI-21 > URL: https://issues.jboss.org/browse/CDI-21 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Sivakumar Thyagarajan > Priority: Minor > Fix For: 2.0 (discussion) > > > It is sometimes useful to get to know after a portable extension class has been instantiated, so that the state of the Extension could be initialized [ie not establishing state in the constructor and having it called twice when the Extension is proxied]. Though the 1.0 specification does not require this, it would be useful to support @PostConstruct callback on Extension class in the next version of the specification. > Please see https://jira.jboss.org/browse/WELD-713 for additional information on this issue. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 05:26:29 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 29 Jul 2014 05:26:29 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-8) Decorators are not applied to custom beans In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-8: ----------------------------------- Fix Version/s: 2.0 (discussion) (was: TBD) > Decorators are not applied to custom beans > ------------------------------------------ > > Key: CDI-8 > URL: https://issues.jboss.org/browse/CDI-8 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Decorators, Portable Extensions > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > Beans added with AfterBeanDiscovery.addBean() do not have decorators applied -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 05:28:31 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 29 Jul 2014 05:28:31 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-4) Need a way to provide ordering for Event observers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-4: ----------------------------------- Fix Version/s: 2.0 (discussion) (was: TBD) > Need a way to provide ordering for Event observers > -------------------------------------------------- > > Key: CDI-4 > URL: https://issues.jboss.org/browse/CDI-4 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events, Portable Extensions > Affects Versions: 1.0 > Environment: All > Reporter: Lincoln Baxter III > Assignee: Pete Muir > Fix For: 2.0 (discussion) > > > There needs to be a way to specify some kind of ordering for Event observers. > Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 05:28:34 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 29 Jul 2014 05:28:34 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-9) Interceptors are not applied to custom bean types In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-9: ----------------------------------- Fix Version/s: 2.0 (discussion) (was: TBD) > Interceptors are not applied to custom bean types > ------------------------------------------------- > > Key: CDI-9 > URL: https://issues.jboss.org/browse/CDI-9 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Interceptors, Portable Extensions > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > Beans added through the SPI do not have interceptors applied. > Even though bean does not have a getInterceptorBindings() method, interceptors applied to stereotypes should still work. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 05:42:30 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 29 Jul 2014 05:42:30 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-16) Improve EE 6 Managed Bean integration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand closed CDI-16. ----------------------------------- Fix Version/s: (was: TBD) Resolution: Won't Fix Nothing to do on CDI side > Improve EE 6 Managed Bean integration > ------------------------------------- > > Key: CDI-16 > URL: https://issues.jboss.org/browse/CDI-16 > Project: CDI Specification Issues > Issue Type: Tracker > Components: Java EE integration > Affects Versions: 1.0 > Reporter: Pete Muir > > Try to work out if we can improve on this. > At least, we should clarify what happens if a CDI managed bean is annotated with @ManagedBean -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 05:42:30 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 29 Jul 2014 05:42:30 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-19) Ordering execution on Extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-19: ------------------------------------ Fix Version/s: 2.0 (discussion) (was: TBD) > Ordering execution on Extensions > -------------------------------- > > Key: CDI-19 > URL: https://issues.jboss.org/browse/CDI-19 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Robson Ximenes > Priority: Minor > Fix For: 2.0 (discussion) > > > I believe the cdi portable extension could have the load order of extensions the same as it is registered; > It is possible that one extension expect some previous preparation of beans from another extension -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 05:44:29 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 29 Jul 2014 05:44:29 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-19) Ordering execution on Extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988562#comment-12988562 ] Antoine Sabot-Durand commented on CDI-19: ----------------------------------------- IMO no extension ordering but SPI observers ordering if we provide a solution for CDI-4 > Ordering execution on Extensions > -------------------------------- > > Key: CDI-19 > URL: https://issues.jboss.org/browse/CDI-19 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Robson Ximenes > Priority: Minor > Fix For: 2.0 (discussion) > > > I believe the cdi portable extension could have the load order of extensions the same as it is registered; > It is possible that one extension expect some previous preparation of beans from another extension -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 05:54:30 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 29 Jul 2014 05:54:30 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-20) @Observes(propagate = false) - stop event propagation after being handled by an observer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988568#comment-12988568 ] Antoine Sabot-Durand commented on CDI-20: ----------------------------------------- Useless if observer are not ordered > @Observes(propagate = false) - stop event propagation after being handled by an observer > ---------------------------------------------------------------------------------------- > > Key: CDI-20 > URL: https://issues.jboss.org/browse/CDI-20 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 1.0 > Environment: any > Reporter: Walter White > Fix For: 2.0 (discussion) > > > I would like to have the ability to stop event propagation after it is handled by any observer only for certain situations. Is it possible to add a property to the annotation indicating whether the propagation should continue after being handled by the observer? Alternatively, would it be more concise to add a qualifier annotation which specifies the propagation. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 05:54:30 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 29 Jul 2014 05:54:30 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-20) @Observes(propagate = false) - stop event propagation after being handled by an observer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-20: ------------------------------------ Fix Version/s: 2.0 (discussion) (was: TBD) > @Observes(propagate = false) - stop event propagation after being handled by an observer > ---------------------------------------------------------------------------------------- > > Key: CDI-20 > URL: https://issues.jboss.org/browse/CDI-20 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 1.0 > Environment: any > Reporter: Walter White > Fix For: 2.0 (discussion) > > > I would like to have the ability to stop event propagation after it is handled by any observer only for certain situations. Is it possible to add a property to the annotation indicating whether the propagation should continue after being handled by the observer? Alternatively, would it be more concise to add a qualifier annotation which specifies the propagation. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 06:12:30 2014 From: issues at jboss.org (Jens Schumann (JIRA)) Date: Tue, 29 Jul 2014 06:12:30 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-20) @Observes(propagate = false) - stop event propagation after being handled by an observer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988581#comment-12988581 ] Jens Schumann commented on CDI-20: ---------------------------------- Good point, Antoine. And even with ordered event observers: What would be the meaning of "propagate = false" for transactional event observers? > @Observes(propagate = false) - stop event propagation after being handled by an observer > ---------------------------------------------------------------------------------------- > > Key: CDI-20 > URL: https://issues.jboss.org/browse/CDI-20 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 1.0 > Environment: any > Reporter: Walter White > Fix For: 2.0 (discussion) > > > I would like to have the ability to stop event propagation after it is handled by any observer only for certain situations. Is it possible to add a property to the annotation indicating whether the propagation should continue after being handled by the observer? Alternatively, would it be more concise to add a qualifier annotation which specifies the propagation. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 06:14:30 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 29 Jul 2014 06:14:30 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-25) Support @Inject FacesContext facesContext; In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-25. ------------------------------------- Resolution: Won't Fix Things to be done in JSF > Support @Inject FacesContext facesContext; > ------------------------------------------ > > Key: CDI-25 > URL: https://issues.jboss.org/browse/CDI-25 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: TBD > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 06:22:29 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 29 Jul 2014 06:22:29 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-20) @Observes(propagate = false) - stop event propagation after being handled by an observer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988586#comment-12988586 ] Antoine Sabot-Durand commented on CDI-20: ----------------------------------------- That means that we have a big discussion on events for CDI 2.0, because the question becomes even worse if we introduce asynchronous events: CDI-31 ;) > @Observes(propagate = false) - stop event propagation after being handled by an observer > ---------------------------------------------------------------------------------------- > > Key: CDI-20 > URL: https://issues.jboss.org/browse/CDI-20 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 1.0 > Environment: any > Reporter: Walter White > Fix For: 2.0 (discussion) > > > I would like to have the ability to stop event propagation after it is handled by any observer only for certain situations. Is it possible to add a property to the annotation indicating whether the propagation should continue after being handled by the observer? Alternatively, would it be more concise to add a qualifier annotation which specifies the propagation. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 04:48:31 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 30 Jul 2014 04:48:31 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-26) Bootstrap API for CDI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-26: ------------------------------------ Fix Version/s: 2.0 (discussion) (was: TBD) > Bootstrap API for CDI > --------------------- > > Key: CDI-26 > URL: https://issues.jboss.org/browse/CDI-26 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 2.0 (discussion) > > > Weld and other CDI impls allow an embedded mode. > See http://docs.jboss.org/weld/reference/latest/en-US/html/environments.html#d0e5417 for example -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 04:48:31 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 30 Jul 2014 04:48:31 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-29) Method of accessing contexts regardless of active state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-29: ------------------------------------ Fix Version/s: 2.0 (discussion) (was: TBD) > Method of accessing contexts regardless of active state > ------------------------------------------------------- > > Key: CDI-29 > URL: https://issues.jboss.org/browse/CDI-29 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 1.0 > Reporter: Nicklas Karlsson > Fix For: 2.0 (discussion) > > > It would be practical to have a way of accessing contexts from the BeanManager regardless of their active state. Currently, contexts cannot be activated (e.g. Conversation) in a portable way because there is no way of getting the inactive context in order to activate it. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 04:50:34 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 30 Jul 2014 04:50:34 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-30) An API for managing built in contexts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-30: ------------------------------------ Fix Version/s: 2.0 (discussion) (was: TBD) > An API for managing built in contexts > ------------------------------------- > > Key: CDI-30 > URL: https://issues.jboss.org/browse/CDI-30 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 1.0 > Reporter: Nicklas Karlsson > Fix For: 2.0 (discussion) > > > Add management API for built in contexts allowing them to be reused as needed. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 04:50:36 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 30 Jul 2014 04:50:36 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-31) Asynchronous events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-31: ------------------------------------ Fix Version/s: 2.0 (discussion) (was: TBD) > Asynchronous events > ------------------- > > Key: CDI-31 > URL: https://issues.jboss.org/browse/CDI-31 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 1.0 > Reporter: Nicklas Karlsson > Fix For: 2.0 (discussion) > > > Consider including asynchronous events as their were specified in one of the previous drafts. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 05:06:32 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 30 Jul 2014 05:06:32 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-37) Stateless scope In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988868#comment-12988868 ] Antoine Sabot-Durand commented on CDI-37: ----------------------------------------- Perhaps we should use the {{@Singleton}} pseudo scope. Right now there's absolutely no mention of it in the spec (except in one example). All the occurrences of _singleton_ is to mention EJB (stateless session bean). > Stateless scope > --------------- > > Key: CDI-37 > URL: https://issues.jboss.org/browse/CDI-37 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 1.0 > Reporter: Adam Warski > Fix For: 2.0 (discussion) > > > From a discussion on weld-dev (http://lists.jboss.org/pipermail/weld-dev/2011-January/002825.html): > Here's my use-case: > I have some beans which are inherently stateless, e.g. "services" or factory methods. The only fields they have are injected. I am using these beans in normal-scoped passivation-capable beans, e.g. session or conversation scoped. In such case, they also have to be passivation-capable, which means either > (a) be normal-scoped (proxyable) > (b) implement Serializable and leave the bean dependent-scoped > If I go with (a) this means that I'd have to put my bean in the request, session, conversation or application scope. However none of these choices make much sense, as they indicate the my beans holds request/session/etc-scoped data - which it doesn't, as it is stateless. > So I am left with (b) - implement Serializable + dependent scope. But is that the right thing to do always? Firstly, if I have a lot of such stateless beans, which are injected one into another, serializing a simple session-scope bean may mean that half the beans in my application get serialized. Secondly, a developer looking at such a bean could wonder why is this bean serializable? Esp if it doesn't have any state? > Hence what I'd like in fact is a proxyable scope (normal), which on serialization would only write the proxy information, on de-serialization would inject a new instance of the bean (or from a pool), and on injection would either behave as dependent (new instance), or take beans from a pool. Just as the EJB Stateless scope (except that I don't want to make my bean an EJB). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 05:06:33 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 30 Jul 2014 05:06:33 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-37) Stateless scope In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-37: ------------------------------------ Fix Version/s: 2.0 (discussion) (was: TBD) > Stateless scope > --------------- > > Key: CDI-37 > URL: https://issues.jboss.org/browse/CDI-37 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 1.0 > Reporter: Adam Warski > Fix For: 2.0 (discussion) > > > From a discussion on weld-dev (http://lists.jboss.org/pipermail/weld-dev/2011-January/002825.html): > Here's my use-case: > I have some beans which are inherently stateless, e.g. "services" or factory methods. The only fields they have are injected. I am using these beans in normal-scoped passivation-capable beans, e.g. session or conversation scoped. In such case, they also have to be passivation-capable, which means either > (a) be normal-scoped (proxyable) > (b) implement Serializable and leave the bean dependent-scoped > If I go with (a) this means that I'd have to put my bean in the request, session, conversation or application scope. However none of these choices make much sense, as they indicate the my beans holds request/session/etc-scoped data - which it doesn't, as it is stateless. > So I am left with (b) - implement Serializable + dependent scope. But is that the right thing to do always? Firstly, if I have a lot of such stateless beans, which are injected one into another, serializing a simple session-scope bean may mean that half the beans in my application get serialized. Secondly, a developer looking at such a bean could wonder why is this bean serializable? Esp if it doesn't have any state? > Hence what I'd like in fact is a proxyable scope (normal), which on serialization would only write the proxy information, on de-serialization would inject a new instance of the bean (or from a pool), and on injection would either behave as dependent (new instance), or take beans from a pool. Just as the EJB Stateless scope (except that I don't want to make my bean an EJB). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 05:14:31 2014 From: issues at jboss.org (Arne Limburg (JIRA)) Date: Wed, 30 Jul 2014 05:14:31 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-37) Stateless scope In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988870#comment-12988870 ] Arne Limburg commented on CDI-37: --------------------------------- We have to be careful using @javax.inject.Singleton. We have to be backward compatible with JSR-330. I don't really get, why @ApplicationScoped is a problem in that use case. > Stateless scope > --------------- > > Key: CDI-37 > URL: https://issues.jboss.org/browse/CDI-37 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 1.0 > Reporter: Adam Warski > Fix For: 2.0 (discussion) > > > From a discussion on weld-dev (http://lists.jboss.org/pipermail/weld-dev/2011-January/002825.html): > Here's my use-case: > I have some beans which are inherently stateless, e.g. "services" or factory methods. The only fields they have are injected. I am using these beans in normal-scoped passivation-capable beans, e.g. session or conversation scoped. In such case, they also have to be passivation-capable, which means either > (a) be normal-scoped (proxyable) > (b) implement Serializable and leave the bean dependent-scoped > If I go with (a) this means that I'd have to put my bean in the request, session, conversation or application scope. However none of these choices make much sense, as they indicate the my beans holds request/session/etc-scoped data - which it doesn't, as it is stateless. > So I am left with (b) - implement Serializable + dependent scope. But is that the right thing to do always? Firstly, if I have a lot of such stateless beans, which are injected one into another, serializing a simple session-scope bean may mean that half the beans in my application get serialized. Secondly, a developer looking at such a bean could wonder why is this bean serializable? Esp if it doesn't have any state? > Hence what I'd like in fact is a proxyable scope (normal), which on serialization would only write the proxy information, on de-serialization would inject a new instance of the bean (or from a pool), and on injection would either behave as dependent (new instance), or take beans from a pool. Just as the EJB Stateless scope (except that I don't want to make my bean an EJB). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 05:36:31 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 30 Jul 2014 05:36:31 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-37) Stateless scope In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988875#comment-12988875 ] Martin Kouba commented on CDI-37: --------------------------------- {quote} I don't really get, why @ApplicationScoped is a problem in that use case. {quote} I think that Adam meant something like a "proxied dependent bean", i.e. bound to the to the lifecycle of the injected object but not serialized during passivation - only the proxy is serialized and a new instance is created on demand (probably lazily). I'm not sure "stateless" is a good name though - these instances may be stateless but their scope is another thing. > Stateless scope > --------------- > > Key: CDI-37 > URL: https://issues.jboss.org/browse/CDI-37 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 1.0 > Reporter: Adam Warski > Fix For: 2.0 (discussion) > > > From a discussion on weld-dev (http://lists.jboss.org/pipermail/weld-dev/2011-January/002825.html): > Here's my use-case: > I have some beans which are inherently stateless, e.g. "services" or factory methods. The only fields they have are injected. I am using these beans in normal-scoped passivation-capable beans, e.g. session or conversation scoped. In such case, they also have to be passivation-capable, which means either > (a) be normal-scoped (proxyable) > (b) implement Serializable and leave the bean dependent-scoped > If I go with (a) this means that I'd have to put my bean in the request, session, conversation or application scope. However none of these choices make much sense, as they indicate the my beans holds request/session/etc-scoped data - which it doesn't, as it is stateless. > So I am left with (b) - implement Serializable + dependent scope. But is that the right thing to do always? Firstly, if I have a lot of such stateless beans, which are injected one into another, serializing a simple session-scope bean may mean that half the beans in my application get serialized. Secondly, a developer looking at such a bean could wonder why is this bean serializable? Esp if it doesn't have any state? > Hence what I'd like in fact is a proxyable scope (normal), which on serialization would only write the proxy information, on de-serialization would inject a new instance of the bean (or from a pool), and on injection would either behave as dependent (new instance), or take beans from a pool. Just as the EJB Stateless scope (except that I don't want to make my bean an EJB). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 07:08:29 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 30 Jul 2014 07:08:29 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-449) beans.xml examples are not valid In-Reply-To: References: Message-ID: Martin Kouba created CDI-449: -------------------------------- Summary: beans.xml examples are not valid Key: CDI-449 URL: https://issues.jboss.org/browse/CDI-449 Project: CDI Specification Issues Issue Type: Bug Affects Versions: 1.2.Final Reporter: Martin Kouba The {{beans.xml}} examples in "5.1.1. Declaring selected alternatives", "8.2.2. Decorator enablement and ordering for a bean archive" and "9.4. Interceptor enablement and ordering" (which contain a reference to beans_1_1.xsd) are not valid - {{bean-discovery-mode}} attribute is required. I think it would be appropriate to specify the version attribute as well. The last {{beans.xml}} example in "12.4.2. Exclude filters" does not even define the reference to an XSD. Again, I believe the version and bean-discovery-mode attributes should be specified. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 11:56:29 2014 From: issues at jboss.org (James Strachan (JIRA)) Date: Wed, 30 Jul 2014 11:56:29 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-450) support Dagger 2.x style APT generated bytecode to avoid reflection or proxying for faster injection In-Reply-To: References: Message-ID: James Strachan created CDI-450: ---------------------------------- Summary: support Dagger 2.x style APT generated bytecode to avoid reflection or proxying for faster injection Key: CDI-450 URL: https://issues.jboss.org/browse/CDI-450 Project: CDI Specification Issues Issue Type: Feature Request Reporter: James Strachan this is particularly useful if you wanted to do per-request/per-message/per-operation injection. The Dagger approach to DI lets you code generate the DI wiring code at compile time avoiding any reflection etc. The primary use case driving Dagger is performance on Android but I can see that being generically useful on all Java platforms. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 12:34:30 2014 From: issues at jboss.org (Arne Limburg (JIRA)) Date: Wed, 30 Jul 2014 12:34:30 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-37) Stateless scope In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12989214#comment-12989214 ] Arne Limburg commented on CDI-37: --------------------------------- OK, I understand, what he means, but I don't understand why it is needed. In what way does an @ApplicationScoped bean not fulfill the mentioned requirements > Stateless scope > --------------- > > Key: CDI-37 > URL: https://issues.jboss.org/browse/CDI-37 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 1.0 > Reporter: Adam Warski > Fix For: 2.0 (discussion) > > > From a discussion on weld-dev (http://lists.jboss.org/pipermail/weld-dev/2011-January/002825.html): > Here's my use-case: > I have some beans which are inherently stateless, e.g. "services" or factory methods. The only fields they have are injected. I am using these beans in normal-scoped passivation-capable beans, e.g. session or conversation scoped. In such case, they also have to be passivation-capable, which means either > (a) be normal-scoped (proxyable) > (b) implement Serializable and leave the bean dependent-scoped > If I go with (a) this means that I'd have to put my bean in the request, session, conversation or application scope. However none of these choices make much sense, as they indicate the my beans holds request/session/etc-scoped data - which it doesn't, as it is stateless. > So I am left with (b) - implement Serializable + dependent scope. But is that the right thing to do always? Firstly, if I have a lot of such stateless beans, which are injected one into another, serializing a simple session-scope bean may mean that half the beans in my application get serialized. Secondly, a developer looking at such a bean could wonder why is this bean serializable? Esp if it doesn't have any state? > Hence what I'd like in fact is a proxyable scope (normal), which on serialization would only write the proxy information, on de-serialization would inject a new instance of the bean (or from a pool), and on injection would either behave as dependent (new instance), or take beans from a pool. Just as the EJB Stateless scope (except that I don't want to make my bean an EJB). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 31 03:02:32 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 31 Jul 2014 03:02:32 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-37) Stateless scope In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12989369#comment-12989369 ] Martin Kouba commented on CDI-37: --------------------------------- [~arnelim] Agreed. This does not make much sense if there is no state at all. > Stateless scope > --------------- > > Key: CDI-37 > URL: https://issues.jboss.org/browse/CDI-37 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 1.0 > Reporter: Adam Warski > Fix For: 2.0 (discussion) > > > From a discussion on weld-dev (http://lists.jboss.org/pipermail/weld-dev/2011-January/002825.html): > Here's my use-case: > I have some beans which are inherently stateless, e.g. "services" or factory methods. The only fields they have are injected. I am using these beans in normal-scoped passivation-capable beans, e.g. session or conversation scoped. In such case, they also have to be passivation-capable, which means either > (a) be normal-scoped (proxyable) > (b) implement Serializable and leave the bean dependent-scoped > If I go with (a) this means that I'd have to put my bean in the request, session, conversation or application scope. However none of these choices make much sense, as they indicate the my beans holds request/session/etc-scoped data - which it doesn't, as it is stateless. > So I am left with (b) - implement Serializable + dependent scope. But is that the right thing to do always? Firstly, if I have a lot of such stateless beans, which are injected one into another, serializing a simple session-scope bean may mean that half the beans in my application get serialized. Secondly, a developer looking at such a bean could wonder why is this bean serializable? Esp if it doesn't have any state? > Hence what I'd like in fact is a proxyable scope (normal), which on serialization would only write the proxy information, on de-serialization would inject a new instance of the bean (or from a pool), and on injection would either behave as dependent (new instance), or take beans from a pool. Just as the EJB Stateless scope (except that I don't want to make my bean an EJB). -- This message was sent by Atlassian JIRA (v6.2.6#6264)