Hi Luigi! I'm not aware of any private mailing list for the CDI-1.1 EG. And if there is one, then I have forgotten about it because we never used it :)

As you can see in the pretty long discussions inside some Jira issues (checkout CDI-18 or 129 if you like to have some fun), most of the discussions happen either there or sometimes (for sorting out the really controversial stuff) on the #jsr346 IRC channel on irc.freenode.net. Just a few quick notes from my private pov: > - CDI-160 Split the specification into "Core" and "EE integrations". This is _now_ mostly a wording issue. In the past, this was really a very politically explosive topic. But now the dust has settled and CDI in general has shown that it's definitely the right way to go - also fore SE! > - CDI-26 Provide a bootstrap API for the CDI container outside of an EE container. > Do you think these will make it into CDI 1.1? I hope so, but please don't underestimate the work which needs to be done to integrate CDI into a server. Regardless if it's just SE (where some features like 'Session', JNDI, etc needs to be emulated) or EE. Imo we could definitely need some feedback in this area.

> - CDI-30 An API for managing built in contexts also neat but could be pretty complex without integration code. But should be doable. In OWB we have such a stuff already. For Arquillian we also could use this.

> - CDI-51 Support static injection > Static injection would still not be allowed for final fields, just as for the non-static case, right? Basically. final fields are always problematic, because some VMs make assumptions and optimize stuff. I made this observation when changing final fields in unit tests via reflection - this only works under pretty restricted conditions. LieGrue, strub > ________________________________ > From: Luigi Bitonti <uknadors(a)yahoo.com&gt; > To: &quot;cdi-dev(a)lists.jboss.org&quot; <cdi-dev(a)lists.jboss.org&gt; > Sent: Wednesday, January 25, 2012 3:54 PM > Subject: [cdi-dev] LJC comments/questions > > > Hi All, > > My name is Luigi Bitonti and I am a member of the London Java Community (LJC). We are interested in the CDI 1.1 specification and would like to help by contributing our point of view as developers. We are also keen to help with any tasks you feel like assigning to us. We have read the latest draft specification and put together a first round of comments and questions: > > All the discussions and development are being tracked on Jira (https://issues.jboss.org/browse/CDI). The whole process seems very transparent and easy to follow which is a very good thing. We view very positively the adoption of JCP 2.8. > It looks like there is also a private mailing list the EG uses. Is that in use? What's its purpose? > > It looks like good work is being done and some interesting new addition have already made it into this new version of the specification, such as: > - CDI-86 Support firing general purpose lifecycle events in Java EE environments > - CDI-129 Clarify behaviour of @ApplicationScoped in EARs > > What we would like to see going forward is an "easier and clearer" specification, so the current efforts seem to be going in the right direction. Hopefully more good proposals will be implemented as part of the final version. > > The lack of clear separation between the SE and EE parts of the specification seems to be an issue that limits adoption. This is also related to the lack of a standard way of bootstrapping the DI container in SE. In this respect we believe the following planned changes will bring improvements: > - CDI-160 Split the specification into "Core" and "EE integrations". > - CDI-26 Provide a bootstrap API for the CDI container outside of an EE container. > Do you think these will make it into CDI 1.1? > > Other interesting proposals we would like to see implemented are: > - CDI-139 Support for unmanaged instances. > - CDI-110 Provide support for binding an invocation handler to an interface or abstract class > - CDI-30 An API for managing built in contexts > I've noticed the first 2 have been voted at the top of the most popular issues. I suppose they are very likely to make it into CDI 1.1. Is that correct?

> > Regarding the following issue, we have a question: > - CDI-51 Support static injection > Static injection would still not be allowed for final fields, just as for the non-static case, right? > > Thanks for all your work on the specification. I hope we'll be able to help your efforts going forward. > > Cheers, > Luigi > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev

Hi Luigi! I'm not aware of any private mailing list for the CDI-1.1 EG. And if there is one, then I have forgotten about it because we never used it :)

As you can see in the pretty long discussions inside some Jira issues (checkout CDI-18 or 129 if you like to have some fun), most of the discussions happen either there or sometimes (for sorting out the really controversial stuff) on the #jsr346 IRC channel on irc.freenode.net. Just a few quick notes from my private pov: > - CDI-160 Split the specification into "Core" and "EE integrations". This is _now_ mostly a wording issue. In the past, this was really a very politically explosive topic. But now the dust has settled and CDI in general has shown that it's definitely the right way to go - also fore SE! > - CDI-26 Provide a bootstrap API for the CDI container outside of an EE container. > Do you think these will make it into CDI 1.1? I hope so, but please don't underestimate the work which needs to be done to integrate CDI into a server. Regardless if it's just SE (where some features like 'Session', JNDI, etc needs to be emulated) or EE. Imo we could definitely need some feedback in this area.

> - CDI-30 An API for managing built in contexts also neat but could be pretty complex without integration code. But should be doable. In OWB we have such a stuff already. For Arquillian we also could use this.

> - CDI-51 Support static injection > Static injection would still not be allowed for final fields, just as for the non-static case, right? Basically. final fields are always problematic, because some VMs make assumptions and optimize stuff. I made this observation when changing final fields in unit tests via reflection - this only works under pretty restricted conditions. LieGrue, strub > ________________________________ > From: Luigi Bitonti <uknadors(a)yahoo.com&gt; > To: &quot;cdi-dev(a)lists.jboss.org&quot; <cdi-dev(a)lists.jboss.org&gt; > Sent: Wednesday, January 25, 2012 3:54 PM > Subject: [cdi-dev] LJC comments/questions > > > Hi All, > > My name is Luigi Bitonti and I am a member of the London Java Community (LJC). We are interested in the CDI 1.1 specification and would like to help by contributing our point of view as developers. We are also keen to help with any tasks you feel like assigning to us. We have read the latest draft specification and put together a first round of comments and questions: > > All the discussions and development are being tracked on Jira (https://issues.jboss.org/browse/CDI). The whole process seems very transparent and easy to follow which is a very good thing. We view very positively the adoption of JCP 2.8. > It looks like there is also a private mailing list the EG uses. Is that in use? What's its purpose? > > It looks like good work is being done and some interesting new addition have already made it into this new version of the specification, such as: > - CDI-86 Support firing general purpose lifecycle events in Java EE environments > - CDI-129 Clarify behaviour of @ApplicationScoped in EARs > > What we would like to see going forward is an "easier and clearer" specification, so the current efforts seem to be going in the right direction. Hopefully more good proposals will be implemented as part of the final version. > > The lack of clear separation between the SE and EE parts of the specification seems to be an issue that limits adoption. This is also related to the lack of a standard way of bootstrapping the DI container in SE. In this respect we believe the following planned changes will bring improvements: > - CDI-160 Split the specification into "Core" and "EE integrations". > - CDI-26 Provide a bootstrap API for the CDI container outside of an EE container. > Do you think these will make it into CDI 1.1? > > Other interesting proposals we would like to see implemented are: > - CDI-139 Support for unmanaged instances. > - CDI-110 Provide support for binding an invocation handler to an interface or abstract class > - CDI-30 An API for managing built in contexts > I've noticed the first 2 have been voted at the top of the most popular issues. I suppose they are very likely to make it into CDI 1.1. Is that correct?

> > Regarding the following issue, we have a question: > - CDI-51 Support static injection > Static injection would still not be allowed for final fields, just as for the non-static case, right? > > Thanks for all your work on the specification. I hope we'll be able to help your efforts going forward. > > Cheers, > Luigi > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev

Hi all, I hope all is well. I've sent an update to the LJC (London Java Community) saying that work on JSR346 is progressing, recently at a slower rate but, as when I wrote the first review, in the right direction it seems to me. By the way, congratulations for reaching 90% test coverage. Also I've put together a CDI extension module that implements the enhancement documented at: http://www.seamframework.org/Weld/PortableExtensionsPackage#H-GuicestyleC... Not completely sure it's also what's mentioned here, but it looks so: https://issues.jboss.org/browse/CDI-161?_sscc=t ([CDI-161]) It's a DSL that provides guice-like syntax for composing applications, on top of CDI. It's a bit rough, but it works for the use cases I've come up with so far. The code is available at: http://github.com/lbitonti/CdiDsl/tree/master/cdi-dsl in case it could be of any interest. Apologies if this is not the right mailing list for this. Cheers, Luigi From: Pete Muir <pmuir(a)redhat.com&gt; To: Mark Struberg <struberg(a)yahoo.de&gt; Cc: Luigi Bitonti <uknadors(a)yahoo.com>; &quot;cdi-dev(a)lists.jboss.org&quot; <cdi-dev(a)lists.jboss.org&gt; Sent: Thursday, January 26, 2012 11:50 AM Subject: Re: [cdi-dev] LJC comments/questions Hi Luigi On 25 Jan 2012, at 20:00, Mark Struberg wrote: > Hi Luigi! > > I'm not aware of any private mailing list for the CDI-1.1 EG. And if there is one, then I have forgotten about it because we never used it :) We had one originally, as it seemed standard under the old JCP rules. As part of the JCP 2.8 change, it was closed down by the JCP PMO. This is the only ml. > > As you can see in the pretty long discussions inside some Jira issues (checkout CDI-18 or 129 if you like to have some fun), most of the discussions happen either there or sometimes (for sorting out the really controversial stuff) on the #jsr346 IRC channel on irc.freenode.net. > > > Just a few quick notes from my private pov: > >> - CDI-160 Split the specification into "Core" and "EE integrations". > > This is _now_ mostly a wording issue. In the past, this was really a very politically explosive topic. But now the dust has settled and CDI in general has shown that it's definitely the right way to go - also fore SE! > > >> - CDI-26 Provide a bootstrap API for the CDI container outside of an EE container. >> Do you think these will make it into CDI 1.1? > I hope so, but please don't underestimate the work which needs to be done to integrate CDI into a server. Regardless if it's just SE (where some features like 'Session', JNDI, etc needs to be emulated) or EE. Imo we could definitely need some feedback in this area. Yes, they will. I'm hopeful I can look more at CDI 1.1 again in Feb. > > >> - CDI-30 An API for managing built in contexts > also neat but could be pretty complex without integration code. But should be doable. In OWB we have such a stuff already. For Arquillian we also could use this. Yeah, this I'm personally fond of. The hard part will be aligning what Weld has and what OWB has I guess ;-) > > >> - CDI-51 Support static injection >> Static injection would still not be allowed for final fields, just as for the non-static case, right? > Basically. final fields are always problematic, because some VMs make assumptions and optimize stuff. > > I made this observation when changing final fields in unit tests via reflection - this only works under pretty restricted conditions. > > > LieGrue, > strub > > >> ________________________________ >> From: Luigi Bitonti <uknadors(a)yahoo.com&gt; >> To: &quot;cdi-dev(a)lists.jboss.org&quot; <cdi-dev(a)lists.jboss.org&gt; >> Sent: Wednesday, January 25, 2012 3:54 PM >> Subject: [cdi-dev] LJC comments/questions >> >> >> Hi All, >> >> My name is Luigi Bitonti and I am a member of the London Java Community (LJC). We are interested in the CDI 1.1 specification and would like to help by contributing our point of view as developers. We are also keen to help with any tasks you feel like assigning to us. We have read the latest draft specification and put together a first round of comments and questions: >> >> All the discussions and development are being tracked on Jira (https://issues.jboss.org/browse/CDI). The whole process seems very transparent and easy to follow which is a very good thing. We view very positively the adoption of JCP 2.8. >> It looks like there is also a private mailing list the EG uses. Is that in use? What's its purpose? >> >> It looks like good work is being done and some interesting new addition have already made it > into this new version of the specification, such as: >> - CDI-86 Support firing general purpose lifecycle events in Java EE environments >> - CDI-129 Clarify behaviour of @ApplicationScoped in EARs >> >> What we would like to see going forward is an "easier and clearer" specification, so the current efforts seem to be going in the right direction. Hopefully more good proposals will be implemented as part of the final version. >> >> The lack of clear separation between the SE and EE parts of the specification seems to be an issue that limits adoption. This is also related to the lack of a standard way of bootstrapping the DI container in SE. In this respect we believe the following planned changes will bring improvements: >> - CDI-160 Split the specification into "Core" and "EE integrations". >> - CDI-26 Provide a bootstrap API for the CDI container outside of an EE container. >> Do you think these will make it into CDI 1.1? >> >> Other interesting > proposals we would like to see implemented are: >> - CDI-139 Support for unmanaged instances. >> - CDI-110 Provide support for binding an invocation handler to an interface or abstract class >> - CDI-30 An API for managing built in contexts >> I've noticed the first 2 have been voted at the top of the most popular issues. I suppose they are very likely to make it into CDI 1.1. Is that correct? Yes. George owns the second, so he can comment on his progress there. >> >> Regarding the following issue, we have a question: >> - CDI-51 Support static injection >> Static injection would still not be allowed for final fields, just as for the non-static case, right? >> >> Thanks for all your work on the specification. I hope we'll be able to help your efforts going forward. >> >> Cheers, >> Luigi >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> >> > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev