From john.d.ament at gmail.com Sun Mar 1 08:31:56 2015 From: john.d.ament at gmail.com (John D. Ament) Date: Sun, 01 Mar 2015 13:31:56 +0000 Subject: [cdi-dev] Upgrading the Felix plugin Message-ID: All, I found that the current version of the felix plugin used in the CDI project doesn't support lambdas. I'm planning to upgrade it to the latest, and wanted to confirm This section of the pom should now read 2.0 right? not 1.1? javax.decorator;version=1.1, javax.enterprise.*;version=1.1, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150301/e6430c1b/attachment.html From issues at jboss.org Sun Mar 1 08:46:48 2015 From: issues at jboss.org (John Ament (JIRA)) Date: Sun, 1 Mar 2015 08:46:48 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-509) Upgrade to latest felix plugin in API JAR In-Reply-To: References: Message-ID: John Ament created CDI-509: ------------------------------ Summary: Upgrade to latest felix plugin in API JAR Key: CDI-509 URL: https://issues.jboss.org/browse/CDI-509 Project: CDI Specification Issues Issue Type: Feature Request Reporter: John Ament Assignee: John Ament Upgrade to the latest felix plugin in the API JAR to allow the API to include lambdas (version 2.5.3) -- This message was sent by Atlassian JIRA (v6.3.11#6341) From john.d.ament at gmail.com Sun Mar 1 09:13:20 2015 From: john.d.ament at gmail.com (John D. Ament) Date: Sun, 01 Mar 2015 14:13:20 +0000 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) References: <54DB1F2B.1020609@redhat.com> <54DC61D9.701@redhat.com> <54EECC20.6040600@redhat.com> <54EF396E.20805@redhat.com> <54F01720.3080802@redhat.com> Message-ID: So, I think I've gathered enough feedback at this point, and seen some of the API changes. I'll hopefully be including some doc changes this week, but one question - do we want to start the SE specific stuff as its own asciidoc file? Changes made: - Changed return value to CDI to provide better capability out of the box. - Added AutoCloseable to CDIContainer, provided default implementation of calling shutdown. - Added synchronization support to the method body that retrieves the singleton instance (BTW, I'm not sure if this is even useful TBH as each impl, including the RI, needs to provide this class in its own format). - Made the params map typed to @Romain Your case isn't really supportable yet, until we have static injection support. You'd still have to have a managed version of Runner to work against. John On Sat, Feb 28, 2015 at 4:11 PM Romain Manni-Bucau wrote: > Yes but not the way to get an instance. Even Unmanaged does it. > > What can be awesome is to have static inject for it: > > public class Runner { > > @Inject > private static MyMain main; > > public static void main(String[] arg) { > try (CDIContainer c = CDIContainer.newContainer()) { > main.doWork(); > } > } > > } > > And not a single additional line :). > Le 28 f?vr. 2015 19:05, "John D. Ament" a ?crit > : > > Maybe I'm misreading, but I don't see us adding another API to do the same >> thing here - we're introducing new functionality. >> >> CDIContainer/Loader on startup/shutdown of the application >> >> CDI for runtime usage within the application to interact with the >> container. >> >> John >> >> On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau >> wrote: >> >>> sure I fully agree excepted I think introducing yet another API to do >>> the same thing is not good so super tempting to skip it and wait for >>> feedbacks rather than introducing it eagerly. >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau >>> http://www.tomitribe.com >>> http://rmannibucau.wordpress.com >>> https://github.com/rmannibucau >>> >>> >>> 2015-02-27 8:05 GMT+01:00 Jozef Hartinger : >>> > My point is that from the application perspective, the user obtains one >>> > container handle for eventual shutdown (CDIContainer) and then looks >>> up a >>> > different container handle (CDI) that they can use for real work >>> (lookup / >>> > event dispatch / etc.) It would be cleaner if the container gave away a >>> > single handle that can do all of that. >>> > >>> > >>> > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: >>> > >>> > Not sure I get how a CDI instance can help. >>> > >>> > But container.getBeanManager() sounds nice is not a shortcut for >>> > CDI.current().getBm() otherwise it looks like duplication to me. >>> > >>> > Can we make container not contextual - dont think so? If so it makes >>> sense >>> > otherwise I fear it doesnt add much. >>> > >>> > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" a >>> ?crit : >>> >> >>> >> I like the initialize + close() combination and the try-with-resources >>> >> usage. >>> >> What looks weird to me is that at line one you obtain a container >>> handle: >>> >> >>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>> >> CDI.current().getBeanManager() ... >>> >> >>> >> and then at line two you call a static method to perform a container >>> >> lookup :-/ >>> >> >>> >> An API that allows you to use the container handle you already got is >>> way >>> >> better IMO, e.g.: >>> >> >>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>> >> container.getBeanManager() >>> >> >>> >> If CDIContainer.newCDIContainer() returns an CDI instance or its >>> subclass, >>> >> we get this easily. >>> >> >>> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: >>> >>> >>> >>> Hi guys >>> >>> >>> >>> why note keeping it simple? >>> >>> >>> >>> try (CDIContainer container = CDIContainer.newCDIContainer(/* >>> optional >>> >>> map to configure vendor features */)) { >>> >>> CDI.current().getBeanManager().... >>> >>> } >>> >>> >>> >>> Not sure the point having initialize() + having shutdown = close >>> >>> really makes the API more fluent and modern IMO. >>> >>> >>> >>> Also to be fully SE I guess provider() method would be needed even if >>> >>> optional (SPI usage by default): >>> >>> >>> >>> try (CDIContainer container = >>> >>> >>> >>> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider"). >>> newCDIContainer()) >>> >>> { >>> >>> CDI.current().getBeanManager().... >>> >>> } >>> >>> >>> >>> Finally I think having a kind of getInstance shortcut could be a >>> plus for >>> >>> SE: >>> >>> >>> >>> try (CDIContainer container = CDIContainer.newCDIContainer()) { >>> >>> container.newInstance(MyAppRunner.class /* optional >>> qualifiers */ >>> >>> ).run(args); >>> >>> } >>> >>> >>> >>> Using container to get an instance would create the instance and bind >>> >>> it to the container lifecycle (mainly for predestroy) avoiding this >>> >>> boilerplate code in all main which will surely only be used to launch >>> >>> a soft. >>> >>> >>> >>> wdyt? >>> >>> >>> >>> >>> >>> >>> >>> Romain Manni-Bucau >>> >>> @rmannibucau >>> >>> http://www.tomitribe.com >>> >>> http://rmannibucau.wordpress.com >>> >>> https://github.com/rmannibucau >>> >>> >>> >>> >>> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger : >>> >>>> >>> >>>> Comments inline >>> >>>> >>> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: >>> >>>> >>> >>>> Sorry Jozef, your email fell into the pits of google inbox's "smart >>> >>>> sorting" >>> >>>> features. >>> >>>> >>> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger < >>> jharting at redhat.com> >>> >>>> wrote: >>> >>>>> >>> >>>>> Hi John, comments inline: >>> >>>>> >>> >>>>> >>> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >>> >>>>> >>> >>>>> Jozef, >>> >>>>> >>> >>>>> Most of what you see there is taken from the original doc, since >>> >>>>> everyone >>> >>>>> seemed to be in agreement. I think the map is just a safeguard in >>> case >>> >>>>> of >>> >>>>> additional boot options available in some implementations (e.g. I >>> think >>> >>>>> OWB/OpenEJB have some options.. currently OpenEJB supports an >>> embedded >>> >>>>> CDI >>> >>>>> boot mode). >>> >>>>> >>> >>>>> No, I am fine with the map. What I am questioning is the type of >>> the >>> >>>>> map. >>> >>>>> Usually, data structures with a similar purpose use Strings as >>> their >>> >>>>> keys. >>> >>>>> This applies to ServletContext attributes, InvocationContext data, >>> >>>>> Servlet >>> >>>>> request/session attributes and others. I am therefore wondering >>> whether >>> >>>>> there is a usecase for the proposed unbound key signature or not. >>> >>>> >>> >>>> >>> >>>> I think that's more of a placeholder, I was assuming it would be >>> >>>> Map once we clarify everything. >>> >>>> >>> >>>>> >>> >>>>> >>> >>>>> We spoke a few times about BeanManager vs CDI. BeanManager was >>> >>>>> preferable >>> >>>>> since there's no easy way to get the the instance, CDI is easier >>> to get >>> >>>>> and >>> >>>>> more aligned with how you would get it. Usually people expect the >>> >>>>> BeanManager to be injected or available via JNDI, neither would be >>> the >>> >>>>> case >>> >>>>> here. >>> >>>>> >>> >>>>> If CDI 2.0 targets Java SE then this container initialization API >>> will >>> >>>>> become something that ordinary application developers use to >>> start/stop >>> >>>>> CDI >>> >>>>> in their applications. It therefore cannot be considered an SPI but >>> >>>>> instead >>> >>>>> should be something easy to use. On the other hand, BeanManager is >>> >>>>> definitely an SPI. It is used in extension, frameworks and >>> generally >>> >>>>> for >>> >>>>> integration. Not much by applications directly. Therefore, I don't >>> see >>> >>>>> how >>> >>>>> the container bootstrap API and BeanManager fit together. IMO the >>> >>>>> bootstrap >>> >>>>> API should expose something that makes common tasks (obtaining a >>> >>>>> contextual >>> >>>>> reference and firing and event) easy, which the CDI class does. >>> >>>>> >>> >>>>> Plus do not forget that BeanManager can be obtained easily using >>> >>>>> CDI.getBeanManager(). >>> >>>> >>> >>>> >>> >>>> I'm not disagreeing. There's a few things I'd consider: >>> >>>> >>> >>>> - Is this mostly for new apps or existing? If existing, it's >>> probably >>> >>>> using >>> >>>> some internal API, if new it can use whatever API we give. >>> >>>> - I don't want to return void, we should give some kind of reference >>> >>>> into >>> >>>> the container when we're done booting. >>> >>>> >>> >>>> Agreed, we should not be returning void. >>> >>>> >>> >>>> - CDI is a one step retrievable reference, where as BeanManager is >>> a two >>> >>>> step reference. With that said, BeanManager makes more sense to >>> return >>> >>>> here. Another thought could be we invent some new class that has >>> both, >>> >>>> but >>> >>>> that's really redundant. >>> >>>> >>> >>>> Why do you think BeanManager makes more sense here? Especially >>> given the >>> >>>> assumption that application code is going to call this init/shutdown >>> >>>> API, I >>> >>>> don't see BeanManager as making more sense. >>> >>>> >>> >>>> >>> >>>>> >>> >>>>> >>> >>>>> Yes, this is the container start API. Sounds like you have some >>> good >>> >>>>> ideas for things like XML configuration or programmatic >>> configuration, >>> >>>>> both >>> >>>>> of which are being tracked under separate tickets. One idea might >>> be >>> >>>>> for an >>> >>>>> optional param in the map to control packages to scan/ignore, in >>> that >>> >>>>> map. >>> >>>>> >>> >>>>> I am wondering whether this configuration should be something >>> optional >>> >>>>> built on top of the bootstrap API or whether we should consider >>> making >>> >>>>> it >>> >>>>> mandatory. Either way, we cannot add the bootstrap API to the spec >>> >>>>> without >>> >>>>> explicitly defining how it behaves. My implicit assumption of the >>> >>>>> proposal >>> >>>>> is that the container is supposed to scan the entire classpath for >>> >>>>> explicit >>> >>>>> or implicit bean archives (including e.g. rt.jar), discover beans, >>> fire >>> >>>>> extensions, etc. This worries me as this default behavior is far >>> from >>> >>>>> being >>> >>>>> lightweight, which CDI for Java SE initially aimed to be. >>> >>>> >>> >>>> >>> >>>> Yes, the spec must be updated to reflect the behavior of SE mode. I >>> >>>> plan to >>> >>>> get that completely into the google doc before opening any spec >>> changes >>> >>>> in a >>> >>>> PR. >>> >>>> >>> >>>>> >>> >>>>> >>> >>>>> We didn't want to over load the CDI interface. It already does a >>> lot. >>> >>>>> This is really SPI code, CDI even though it's in the spi package is >>> >>>>> used in >>> >>>>> a lot of application code. >>> >>>>> >>> >>>>> I would personally prefer to have it all in one place. Having >>> >>>>> CDIContainer, CDIContainerLoader, CDI and CDIProvider makes it more >>> >>>>> difficult to know when to use what. >>> >>>> >>> >>>> >>> >>>> The problem is that most CDI (the interface) operations are against >>> a >>> >>>> running container. I think we spoke about leveraging CDIProvider >>> at one >>> >>>> point (in fact, I mistakenly called CDIContainer CDIProvider not >>> even >>> >>>> realizing it was there). I doubt that most app developers use it >>> >>>> currently, >>> >>>> there's not even a way to get a reference to it that I'm aware of. >>> It's >>> >>>> used by the implementor only. >>> >>>> >>> >>>> I don't think there's a conflict. CDI class would still only provide >>> >>>> methods >>> >>>> to be run against a running container. The difference is that there >>> >>>> would be >>> >>>> additional static methods to get this running container (CDI class) >>> to >>> >>>> you >>> >>>> by starting the container. >>> >>>> >>> >>>> Either way, I agree that reusing CDIProvider is a must. There is no >>> >>>> reason >>> >>>> to define a new class for the same purpose. >>> >>>> >>> >>>> >>> >>>> I expect that my changes in the CDI spec around this will state, >>> along >>> >>>> the >>> >>>> lines of: >>> >>>> >>> >>>> To retrieve a CDIContainer to launch, do this: >>> >>>> >>> >>>> CDIContainer container = CDIContainerLocator.getCDIContainer(); >>> >>>> container.initialize(); >>> >>>> ... do work >>> >>>> >>> >>>> Once you want to shutdown the container, do this: >>> >>>> >>> >>>> container.shutdown(); >>> >>>> >>> >>>> (we may want to consider implementing AutoCloseable, an oversight >>> on my >>> >>>> part) >>> >>>> >>> >>>> and then later on >>> >>>> >>> >>>> - What happens if I call CDIContainerLocator in an app server >>> >>>> >>> >>>> - It throws an IllegalStateException. >>> >>>> >>> >>>> - The container provides no beans of type CDIContainer, it is >>> managed >>> >>>> outside of the CDI container. >>> >>>> >>> >>>> >>> >>>>> >>> >>>>> >>> >>>>> John >>> >>>>> >>> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger < >>> jharting at redhat.com> >>> >>>>> wrote: >>> >>>>>> >>> >>>>>> Hi John, some thoughts: >>> >>>>>> >>> >>>>>> - instead of using BeanManager it makes more sense to me to >>> return a >>> >>>>>> CDI >>> >>>>>> instance, which is a more user-friendly API (and it also exposes >>> >>>>>> access to >>> >>>>>> BeanManager) >>> >>>>>> - is there a usecase for arbitrary keys of the "params" map or is >>> >>>>>> Map sufficient? >>> >>>>>> - if we could move the shutdown() method from CDIContainer to the >>> >>>>>> actual >>> >>>>>> container handle that we obtain from initialize(), that would look >>> >>>>>> more >>> >>>>>> object-oriented >>> >>>>>> - what exactly is initialize() supposed to do? Is it supposed to >>> start >>> >>>>>> scanning the entire classpath for CDI beans? That could be a >>> problem >>> >>>>>> especially with spring-boot-like fat jars. I think we need an API >>> to >>> >>>>>> tell >>> >>>>>> the container which classes / packages to consider. Something like >>> >>>>>> Guice's >>> >>>>>> binding API perhaps? >>> >>>>>> >>> >>>>>> - the proposal makes me wonder whether retrofitting this >>> functionality >>> >>>>>> to >>> >>>>>> the CDI class wouldn't be a better option. It could look like: >>> >>>>>> >>> >>>>>> CDI container = CDI.initialize(); >>> >>>>>> container.select(Foo.class).get(); >>> >>>>>> container.shutdown(); >>> >>>>>> >>> >>>>>> compare it to: >>> >>>>>> >>> >>>>>> CDIContainer container = CDIContainerLoader. getCDIContainer(); >>> >>>>>> BeanManager manager = container.initialize(); >>> >>>>>> manager.getBeans(...); >>> >>>>>> container.shutdown(manager); >>> >>>>>> >>> >>>>>> >>> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >>> >>>>>> >>> >>>>>> All, >>> >>>>>> >>> >>>>>> I have the updated API here, and wanted to solicit any final >>> feedback >>> >>>>>> before updating the google doc and spec pages. >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> https://github.com/johnament/cdi/commit/ >>> 2c362161e18dd521f8e83c27151ddad467a1c01c >>> >>>>>> >>> >>>>>> Let me know your thoughts. >>> >>>>>> >>> >>>>>> Thanks, >>> >>>>>> >>> >>>>>> John >>> >>>>>> >>> >>>>>> >>> >>>>>> _______________________________________________ >>> >>>>>> cdi-dev mailing list >>> >>>>>> cdi-dev at lists.jboss.org >>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>>>>> >>> >>>>>> Note that for all code provided on this list, the provider >>> licenses >>> >>>>>> the >>> >>>>>> code under the Apache License, Version 2 >>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>> ideas >>> >>>>>> provided on this list, the provider waives all patent and other >>> >>>>>> intellectual >>> >>>>>> property rights inherent in such information. >>> >>>>>> >>> >>>>>> >>> >>>> >>> >>>> _______________________________________________ >>> >>>> cdi-dev mailing list >>> >>>> cdi-dev at lists.jboss.org >>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>>> >>> >>>> Note that for all code provided on this list, the provider licenses >>> the >>> >>>> code >>> >>>> under the Apache License, Version 2 >>> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>> ideas >>> >>>> provided on this list, the provider waives all patent and other >>> >>>> intellectual >>> >>>> property rights inherent in such information. >>> >> >>> >> >>> > >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150301/5c77081f/attachment-0001.html From issues at jboss.org Sun Mar 1 09:23:48 2015 From: issues at jboss.org (John Ament (JIRA)) Date: Sun, 1 Mar 2015 09:23:48 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-510) Update JCP license In-Reply-To: References: Message-ID: John Ament created CDI-510: ------------------------------ Summary: Update JCP license Key: CDI-510 URL: https://issues.jboss.org/browse/CDI-510 Project: CDI Specification Issues Issue Type: Bug Reporter: John Ament Update the JCP license file to reflect CDI 2.0, JSR 365 (instead of JSR 346) -- This message was sent by Atlassian JIRA (v6.3.11#6341) From rmannibucau at gmail.com Sun Mar 1 09:41:13 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sun, 1 Mar 2015 15:41:13 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: References: <54DB1F2B.1020609@redhat.com> <54DC61D9.701@redhat.com> <54EECC20.6040600@redhat.com> <54EF396E.20805@redhat.com> <54F01720.3080802@redhat.com> Message-ID: No technical reason AFAIK. Le 1 mars 2015 15:13, "John D. Ament" a ?crit : > So, I think I've gathered enough feedback at this point, and seen some of > the API changes. I'll hopefully be including some doc changes this week, > but one question - do we want to start the SE specific stuff as its own > asciidoc file? > > Changes made: > > - Changed return value to CDI to provide better capability out of > the box. > - Added AutoCloseable to CDIContainer, provided default implementation of > calling shutdown. > - Added synchronization support to the method body that retrieves the > singleton instance (BTW, I'm not sure if this is even useful TBH as each > impl, including the RI, needs to provide this class in its own format). > - Made the params map typed to > > @Romain Your case isn't really supportable yet, until we have static > injection support. You'd still have to have a managed version of Runner to > work against. > > John > > On Sat, Feb 28, 2015 at 4:11 PM Romain Manni-Bucau > wrote: > >> Yes but not the way to get an instance. Even Unmanaged does it. >> >> What can be awesome is to have static inject for it: >> >> public class Runner { >> >> @Inject >> private static MyMain main; >> >> public static void main(String[] arg) { >> try (CDIContainer c = CDIContainer.newContainer()) { >> main.doWork(); >> } >> } >> >> } >> >> And not a single additional line :). >> Le 28 f?vr. 2015 19:05, "John D. Ament" a >> ?crit : >> >> Maybe I'm misreading, but I don't see us adding another API to do the >>> same thing here - we're introducing new functionality. >>> >>> CDIContainer/Loader on startup/shutdown of the application >>> >>> CDI for runtime usage within the application to interact with the >>> container. >>> >>> John >>> >>> On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau < >>> rmannibucau at gmail.com> wrote: >>> >>>> sure I fully agree excepted I think introducing yet another API to do >>>> the same thing is not good so super tempting to skip it and wait for >>>> feedbacks rather than introducing it eagerly. >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau >>>> http://www.tomitribe.com >>>> http://rmannibucau.wordpress.com >>>> https://github.com/rmannibucau >>>> >>>> >>>> 2015-02-27 8:05 GMT+01:00 Jozef Hartinger : >>>> > My point is that from the application perspective, the user obtains >>>> one >>>> > container handle for eventual shutdown (CDIContainer) and then looks >>>> up a >>>> > different container handle (CDI) that they can use for real work >>>> (lookup / >>>> > event dispatch / etc.) It would be cleaner if the container gave away >>>> a >>>> > single handle that can do all of that. >>>> > >>>> > >>>> > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: >>>> > >>>> > Not sure I get how a CDI instance can help. >>>> > >>>> > But container.getBeanManager() sounds nice is not a shortcut for >>>> > CDI.current().getBm() otherwise it looks like duplication to me. >>>> > >>>> > Can we make container not contextual - dont think so? If so it makes >>>> sense >>>> > otherwise I fear it doesnt add much. >>>> > >>>> > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" a >>>> ?crit : >>>> >> >>>> >> I like the initialize + close() combination and the >>>> try-with-resources >>>> >> usage. >>>> >> What looks weird to me is that at line one you obtain a container >>>> handle: >>>> >> >>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>> >> CDI.current().getBeanManager() ... >>>> >> >>>> >> and then at line two you call a static method to perform a container >>>> >> lookup :-/ >>>> >> >>>> >> An API that allows you to use the container handle you already got >>>> is way >>>> >> better IMO, e.g.: >>>> >> >>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>> >> container.getBeanManager() >>>> >> >>>> >> If CDIContainer.newCDIContainer() returns an CDI instance or its >>>> subclass, >>>> >> we get this easily. >>>> >> >>>> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: >>>> >>> >>>> >>> Hi guys >>>> >>> >>>> >>> why note keeping it simple? >>>> >>> >>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer(/* >>>> optional >>>> >>> map to configure vendor features */)) { >>>> >>> CDI.current().getBeanManager().... >>>> >>> } >>>> >>> >>>> >>> Not sure the point having initialize() + having shutdown = close >>>> >>> really makes the API more fluent and modern IMO. >>>> >>> >>>> >>> Also to be fully SE I guess provider() method would be needed even >>>> if >>>> >>> optional (SPI usage by default): >>>> >>> >>>> >>> try (CDIContainer container = >>>> >>> >>>> >>> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider"). >>>> newCDIContainer()) >>>> >>> { >>>> >>> CDI.current().getBeanManager().... >>>> >>> } >>>> >>> >>>> >>> Finally I think having a kind of getInstance shortcut could be a >>>> plus for >>>> >>> SE: >>>> >>> >>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer()) { >>>> >>> container.newInstance(MyAppRunner.class /* optional >>>> qualifiers */ >>>> >>> ).run(args); >>>> >>> } >>>> >>> >>>> >>> Using container to get an instance would create the instance and >>>> bind >>>> >>> it to the container lifecycle (mainly for predestroy) avoiding this >>>> >>> boilerplate code in all main which will surely only be used to >>>> launch >>>> >>> a soft. >>>> >>> >>>> >>> wdyt? >>>> >>> >>>> >>> >>>> >>> >>>> >>> Romain Manni-Bucau >>>> >>> @rmannibucau >>>> >>> http://www.tomitribe.com >>>> >>> http://rmannibucau.wordpress.com >>>> >>> https://github.com/rmannibucau >>>> >>> >>>> >>> >>>> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger : >>>> >>>> >>>> >>>> Comments inline >>>> >>>> >>>> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: >>>> >>>> >>>> >>>> Sorry Jozef, your email fell into the pits of google inbox's "smart >>>> >>>> sorting" >>>> >>>> features. >>>> >>>> >>>> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger < >>>> jharting at redhat.com> >>>> >>>> wrote: >>>> >>>>> >>>> >>>>> Hi John, comments inline: >>>> >>>>> >>>> >>>>> >>>> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >>>> >>>>> >>>> >>>>> Jozef, >>>> >>>>> >>>> >>>>> Most of what you see there is taken from the original doc, since >>>> >>>>> everyone >>>> >>>>> seemed to be in agreement. I think the map is just a safeguard >>>> in case >>>> >>>>> of >>>> >>>>> additional boot options available in some implementations (e.g. I >>>> think >>>> >>>>> OWB/OpenEJB have some options.. currently OpenEJB supports an >>>> embedded >>>> >>>>> CDI >>>> >>>>> boot mode). >>>> >>>>> >>>> >>>>> No, I am fine with the map. What I am questioning is the type of >>>> the >>>> >>>>> map. >>>> >>>>> Usually, data structures with a similar purpose use Strings as >>>> their >>>> >>>>> keys. >>>> >>>>> This applies to ServletContext attributes, InvocationContext data, >>>> >>>>> Servlet >>>> >>>>> request/session attributes and others. I am therefore wondering >>>> whether >>>> >>>>> there is a usecase for the proposed unbound key signature or not. >>>> >>>> >>>> >>>> >>>> >>>> I think that's more of a placeholder, I was assuming it would be >>>> >>>> Map once we clarify everything. >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> We spoke a few times about BeanManager vs CDI. BeanManager was >>>> >>>>> preferable >>>> >>>>> since there's no easy way to get the the instance, CDI is easier >>>> to get >>>> >>>>> and >>>> >>>>> more aligned with how you would get it. Usually people expect the >>>> >>>>> BeanManager to be injected or available via JNDI, neither would >>>> be the >>>> >>>>> case >>>> >>>>> here. >>>> >>>>> >>>> >>>>> If CDI 2.0 targets Java SE then this container initialization API >>>> will >>>> >>>>> become something that ordinary application developers use to >>>> start/stop >>>> >>>>> CDI >>>> >>>>> in their applications. It therefore cannot be considered an SPI >>>> but >>>> >>>>> instead >>>> >>>>> should be something easy to use. On the other hand, BeanManager is >>>> >>>>> definitely an SPI. It is used in extension, frameworks and >>>> generally >>>> >>>>> for >>>> >>>>> integration. Not much by applications directly. Therefore, I >>>> don't see >>>> >>>>> how >>>> >>>>> the container bootstrap API and BeanManager fit together. IMO the >>>> >>>>> bootstrap >>>> >>>>> API should expose something that makes common tasks (obtaining a >>>> >>>>> contextual >>>> >>>>> reference and firing and event) easy, which the CDI class does. >>>> >>>>> >>>> >>>>> Plus do not forget that BeanManager can be obtained easily using >>>> >>>>> CDI.getBeanManager(). >>>> >>>> >>>> >>>> >>>> >>>> I'm not disagreeing. There's a few things I'd consider: >>>> >>>> >>>> >>>> - Is this mostly for new apps or existing? If existing, it's >>>> probably >>>> >>>> using >>>> >>>> some internal API, if new it can use whatever API we give. >>>> >>>> - I don't want to return void, we should give some kind of >>>> reference >>>> >>>> into >>>> >>>> the container when we're done booting. >>>> >>>> >>>> >>>> Agreed, we should not be returning void. >>>> >>>> >>>> >>>> - CDI is a one step retrievable reference, where as BeanManager is >>>> a two >>>> >>>> step reference. With that said, BeanManager makes more sense to >>>> return >>>> >>>> here. Another thought could be we invent some new class that has >>>> both, >>>> >>>> but >>>> >>>> that's really redundant. >>>> >>>> >>>> >>>> Why do you think BeanManager makes more sense here? Especially >>>> given the >>>> >>>> assumption that application code is going to call this >>>> init/shutdown >>>> >>>> API, I >>>> >>>> don't see BeanManager as making more sense. >>>> >>>> >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> Yes, this is the container start API. Sounds like you have some >>>> good >>>> >>>>> ideas for things like XML configuration or programmatic >>>> configuration, >>>> >>>>> both >>>> >>>>> of which are being tracked under separate tickets. One idea >>>> might be >>>> >>>>> for an >>>> >>>>> optional param in the map to control packages to scan/ignore, in >>>> that >>>> >>>>> map. >>>> >>>>> >>>> >>>>> I am wondering whether this configuration should be something >>>> optional >>>> >>>>> built on top of the bootstrap API or whether we should consider >>>> making >>>> >>>>> it >>>> >>>>> mandatory. Either way, we cannot add the bootstrap API to the spec >>>> >>>>> without >>>> >>>>> explicitly defining how it behaves. My implicit assumption of the >>>> >>>>> proposal >>>> >>>>> is that the container is supposed to scan the entire classpath for >>>> >>>>> explicit >>>> >>>>> or implicit bean archives (including e.g. rt.jar), discover >>>> beans, fire >>>> >>>>> extensions, etc. This worries me as this default behavior is far >>>> from >>>> >>>>> being >>>> >>>>> lightweight, which CDI for Java SE initially aimed to be. >>>> >>>> >>>> >>>> >>>> >>>> Yes, the spec must be updated to reflect the behavior of SE mode. >>>> I >>>> >>>> plan to >>>> >>>> get that completely into the google doc before opening any spec >>>> changes >>>> >>>> in a >>>> >>>> PR. >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> We didn't want to over load the CDI interface. It already does a >>>> lot. >>>> >>>>> This is really SPI code, CDI even though it's in the spi package >>>> is >>>> >>>>> used in >>>> >>>>> a lot of application code. >>>> >>>>> >>>> >>>>> I would personally prefer to have it all in one place. Having >>>> >>>>> CDIContainer, CDIContainerLoader, CDI and CDIProvider makes it >>>> more >>>> >>>>> difficult to know when to use what. >>>> >>>> >>>> >>>> >>>> >>>> The problem is that most CDI (the interface) operations are >>>> against a >>>> >>>> running container. I think we spoke about leveraging CDIProvider >>>> at one >>>> >>>> point (in fact, I mistakenly called CDIContainer CDIProvider not >>>> even >>>> >>>> realizing it was there). I doubt that most app developers use it >>>> >>>> currently, >>>> >>>> there's not even a way to get a reference to it that I'm aware >>>> of. It's >>>> >>>> used by the implementor only. >>>> >>>> >>>> >>>> I don't think there's a conflict. CDI class would still only >>>> provide >>>> >>>> methods >>>> >>>> to be run against a running container. The difference is that there >>>> >>>> would be >>>> >>>> additional static methods to get this running container (CDI >>>> class) to >>>> >>>> you >>>> >>>> by starting the container. >>>> >>>> >>>> >>>> Either way, I agree that reusing CDIProvider is a must. There is no >>>> >>>> reason >>>> >>>> to define a new class for the same purpose. >>>> >>>> >>>> >>>> >>>> >>>> I expect that my changes in the CDI spec around this will state, >>>> along >>>> >>>> the >>>> >>>> lines of: >>>> >>>> >>>> >>>> To retrieve a CDIContainer to launch, do this: >>>> >>>> >>>> >>>> CDIContainer container = CDIContainerLocator.getCDIContainer(); >>>> >>>> container.initialize(); >>>> >>>> ... do work >>>> >>>> >>>> >>>> Once you want to shutdown the container, do this: >>>> >>>> >>>> >>>> container.shutdown(); >>>> >>>> >>>> >>>> (we may want to consider implementing AutoCloseable, an oversight >>>> on my >>>> >>>> part) >>>> >>>> >>>> >>>> and then later on >>>> >>>> >>>> >>>> - What happens if I call CDIContainerLocator in an app server >>>> >>>> >>>> >>>> - It throws an IllegalStateException. >>>> >>>> >>>> >>>> - The container provides no beans of type CDIContainer, it is >>>> managed >>>> >>>> outside of the CDI container. >>>> >>>> >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> John >>>> >>>>> >>>> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger < >>>> jharting at redhat.com> >>>> >>>>> wrote: >>>> >>>>>> >>>> >>>>>> Hi John, some thoughts: >>>> >>>>>> >>>> >>>>>> - instead of using BeanManager it makes more sense to me to >>>> return a >>>> >>>>>> CDI >>>> >>>>>> instance, which is a more user-friendly API (and it also exposes >>>> >>>>>> access to >>>> >>>>>> BeanManager) >>>> >>>>>> - is there a usecase for arbitrary keys of the "params" map or is >>>> >>>>>> Map sufficient? >>>> >>>>>> - if we could move the shutdown() method from CDIContainer to the >>>> >>>>>> actual >>>> >>>>>> container handle that we obtain from initialize(), that would >>>> look >>>> >>>>>> more >>>> >>>>>> object-oriented >>>> >>>>>> - what exactly is initialize() supposed to do? Is it supposed to >>>> start >>>> >>>>>> scanning the entire classpath for CDI beans? That could be a >>>> problem >>>> >>>>>> especially with spring-boot-like fat jars. I think we need an >>>> API to >>>> >>>>>> tell >>>> >>>>>> the container which classes / packages to consider. Something >>>> like >>>> >>>>>> Guice's >>>> >>>>>> binding API perhaps? >>>> >>>>>> >>>> >>>>>> - the proposal makes me wonder whether retrofitting this >>>> functionality >>>> >>>>>> to >>>> >>>>>> the CDI class wouldn't be a better option. It could look like: >>>> >>>>>> >>>> >>>>>> CDI container = CDI.initialize(); >>>> >>>>>> container.select(Foo.class).get(); >>>> >>>>>> container.shutdown(); >>>> >>>>>> >>>> >>>>>> compare it to: >>>> >>>>>> >>>> >>>>>> CDIContainer container = CDIContainerLoader. getCDIContainer(); >>>> >>>>>> BeanManager manager = container.initialize(); >>>> >>>>>> manager.getBeans(...); >>>> >>>>>> container.shutdown(manager); >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >>>> >>>>>> >>>> >>>>>> All, >>>> >>>>>> >>>> >>>>>> I have the updated API here, and wanted to solicit any final >>>> feedback >>>> >>>>>> before updating the google doc and spec pages. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> https://github.com/johnament/cdi/commit/ >>>> 2c362161e18dd521f8e83c27151ddad467a1c01c >>>> >>>>>> >>>> >>>>>> Let me know your thoughts. >>>> >>>>>> >>>> >>>>>> Thanks, >>>> >>>>>> >>>> >>>>>> John >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> _______________________________________________ >>>> >>>>>> cdi-dev mailing list >>>> >>>>>> cdi-dev at lists.jboss.org >>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>>>> >>>> >>>>>> Note that for all code provided on this list, the provider >>>> licenses >>>> >>>>>> the >>>> >>>>>> code under the Apache License, Version 2 >>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all >>>> other ideas >>>> >>>>>> provided on this list, the provider waives all patent and other >>>> >>>>>> intellectual >>>> >>>>>> property rights inherent in such information. >>>> >>>>>> >>>> >>>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> cdi-dev mailing list >>>> >>>> cdi-dev at lists.jboss.org >>>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> >>>> >>>> Note that for all code provided on this list, the provider >>>> licenses the >>>> >>>> code >>>> >>>> under the Apache License, Version 2 >>>> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>>> ideas >>>> >>>> provided on this list, the provider waives all patent and other >>>> >>>> intellectual >>>> >>>> property rights inherent in such information. >>>> >> >>>> >> >>>> > >>>> >>> > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150301/7da32d3c/attachment-0001.html From john.d.ament at gmail.com Sun Mar 1 09:54:15 2015 From: john.d.ament at gmail.com (John D. Ament) Date: Sun, 01 Mar 2015 14:54:15 +0000 Subject: [cdi-dev] Bean Discovery Mode in SE Message-ID: All, I'd like to propose in my doc changes for CDI-26 that if a classpath entry does not contain a META-INF/beans.xml that it is treated as if it were bean-discovery-mode=none, e.g. no beans will be scanned in that entry. (BTW, I'm using classpath entry rather than archive in the document to account for cases where someone does -cp "./classes:./extra-classes:./lib/*" to define their classpath) It's a bit different than how EE works, but I could imagine it causing fewer headaches when running on SE classpaths. Any thoughts/comments? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150301/a03a9972/attachment.html From issues at jboss.org Sun Mar 1 09:59:49 2015 From: issues at jboss.org (John Ament (JIRA)) Date: Sun, 1 Mar 2015 09:59:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-511) Java SE bootstrap parameter to disable extension loading In-Reply-To: References: Message-ID: John Ament created CDI-511: ------------------------------ Summary: Java SE bootstrap parameter to disable extension loading Key: CDI-511 URL: https://issues.jboss.org/browse/CDI-511 Project: CDI Specification Issues Issue Type: Feature Request Components: Java SE Integration Reporter: John Ament Assignee: John Ament We should define a standard parameter when initializing a CDIContainer that allows a user to not load any portable extensions defined in META-INF/services/javax.enterprise.inject.spi.Extension -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Mar 1 10:05:48 2015 From: issues at jboss.org (John Ament (JIRA)) Date: Sun, 1 Mar 2015 10:05:48 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-512) Initialization parameter to specify loaded Extensions In-Reply-To: References: Message-ID: John Ament created CDI-512: ------------------------------ Summary: Initialization parameter to specify loaded Extensions Key: CDI-512 URL: https://issues.jboss.org/browse/CDI-512 Project: CDI Specification Issues Issue Type: Feature Request Components: Java SE Integration Reporter: John Ament Assignee: John Ament As a tie in for CDI-511, define a initialization parameter that can specify the list of extensions to be enabled. The parameter should accept any Collection, however if a duplicate entry is found it is ignored. The collection should support either Classes or Strings representing the FQCN of the extension itself, or the extension instance. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From rmannibucau at gmail.com Sun Mar 1 10:10:52 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sun, 1 Mar 2015 16:10:52 +0100 Subject: [cdi-dev] Bean Discovery Mode in SE In-Reply-To: References: Message-ID: For me it is 100% the same as ee where you have the same issues so keeping them aligned is better IMO. That said configuring globally the scanning would be nice. Le 1 mars 2015 15:54, "John D. Ament" a ?crit : > All, > > I'd like to propose in my doc changes for CDI-26 that if a classpath entry > does not contain a META-INF/beans.xml that it is treated as if it were > bean-discovery-mode=none, e.g. no beans will be scanned in that entry. > (BTW, I'm using classpath entry rather than archive in the document to > account for cases where someone does -cp > "./classes:./extra-classes:./lib/*" to define their classpath) > > It's a bit different than how EE works, but I could imagine it causing > fewer headaches when running on SE classpaths. > > Any thoughts/comments? > > John > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150301/b1318ee9/attachment.html From john.d.ament at gmail.com Sun Mar 1 10:18:16 2015 From: john.d.ament at gmail.com (John D. Ament) Date: Sun, 01 Mar 2015 15:18:16 +0000 Subject: [cdi-dev] Bean Discovery Mode in SE References: Message-ID: Yeah actually you're right. For some reason I had in my head that "all" was the default. It's very clearly not. Too early for some of this :-) So let me rephrase. "annotated" will be the default bean discovery mode if a classpath entry contains no META-INF/beans.xml, based on the exact same rules used in EE. Any concerns with that? John On Sun, Mar 1, 2015 at 10:10 AM Romain Manni-Bucau wrote: > For me it is 100% the same as ee where you have the same issues so keeping > them aligned is better IMO. That said configuring globally the scanning > would be nice. > Le 1 mars 2015 15:54, "John D. Ament" a ?crit : > >> All, >> >> I'd like to propose in my doc changes for CDI-26 that if a classpath >> entry does not contain a META-INF/beans.xml that it is treated as if it >> were bean-discovery-mode=none, e.g. no beans will be scanned in that entry. >> (BTW, I'm using classpath entry rather than archive in the document to >> account for cases where someone does -cp >> "./classes:./extra-classes:./lib/*" to define their classpath) >> >> It's a bit different than how EE works, but I could imagine it causing >> fewer headaches when running on SE classpaths. >> >> Any thoughts/comments? >> >> John >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150301/c860a559/attachment.html From rmannibucau at gmail.com Sun Mar 1 11:27:45 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sun, 1 Mar 2015 17:27:45 +0100 Subject: [cdi-dev] Bean Discovery Mode in SE In-Reply-To: References: Message-ID: It is consistent so ok. Wonder if we can get some rule we could pass to the container to say "dont scan jackson*jar" - issue begin we have to suppose we run with a classpath we dont control. Or the opposite "scan myapp*jar". wdyt? Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-03-01 16:18 GMT+01:00 John D. Ament : > Yeah actually you're right. For some reason I had in my head that "all" > was the default. It's very clearly not. Too early for some of this :-) > > So let me rephrase. "annotated" will be the default bean discovery mode > if a classpath entry contains no META-INF/beans.xml, based on the exact > same rules used in EE. > > Any concerns with that? > > John > > > On Sun, Mar 1, 2015 at 10:10 AM Romain Manni-Bucau > wrote: > >> For me it is 100% the same as ee where you have the same issues so >> keeping them aligned is better IMO. That said configuring globally the >> scanning would be nice. >> Le 1 mars 2015 15:54, "John D. Ament" a ?crit : >> >>> All, >>> >>> I'd like to propose in my doc changes for CDI-26 that if a classpath >>> entry does not contain a META-INF/beans.xml that it is treated as if it >>> were bean-discovery-mode=none, e.g. no beans will be scanned in that entry. >>> (BTW, I'm using classpath entry rather than archive in the document to >>> account for cases where someone does -cp >>> "./classes:./extra-classes:./lib/*" to define their classpath) >>> >>> It's a bit different than how EE works, but I could imagine it causing >>> fewer headaches when running on SE classpaths. >>> >>> Any thoughts/comments? >>> >>> John >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>> provided on this list, the provider waives all patent and other >>> intellectual property rights inherent in such information. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150301/6b10a609/attachment.html From john.d.ament at gmail.com Sun Mar 1 11:49:33 2015 From: john.d.ament at gmail.com (John D. Ament) Date: Sun, 01 Mar 2015 16:49:33 +0000 Subject: [cdi-dev] Bean Discovery Mode in SE References: Message-ID: So that's one of the benefits from my point of view of having that extra initialize w/ map options. We can start to define some standard parameters to control SE mode for some SE specific issues that may pop up. I'm just not sure how that'll apply yet, as ideally the issues should be in both SE and EE. I think your case is mostly an SE problem, but the other issues I'm thinking of are EE as well. - Additional scanning configuration on a global scale (package level and classpath entry name [like you mentioned]). Package level since the beans.xml files all end up at the same level. - How to specify additional Bean Defining Annotations (for bean-discovery-mode=annotated) - Disable extension loading/Explicitly list extensions to load. There will probably be more options that come up as well. Maybe to fix the SE/EE discrepancies, we allow the definition of a bean that returns a Map that can be loaded in either SE or EE, and instead of the default being an empty map we read this via a service loader or something. John On Sun, Mar 1, 2015 at 11:28 AM Romain Manni-Bucau wrote: > It is consistent so ok. > > Wonder if we can get some rule we could pass to the container to say "dont > scan jackson*jar" - issue begin we have to suppose we run with a classpath > we dont control. Or the opposite "scan myapp*jar". > > wdyt? > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2015-03-01 16:18 GMT+01:00 John D. Ament : > >> Yeah actually you're right. For some reason I had in my head that "all" >> was the default. It's very clearly not. Too early for some of this :-) >> >> So let me rephrase. "annotated" will be the default bean discovery mode >> if a classpath entry contains no META-INF/beans.xml, based on the exact >> same rules used in EE. >> >> Any concerns with that? >> >> John >> >> >> On Sun, Mar 1, 2015 at 10:10 AM Romain Manni-Bucau >> wrote: >> >>> For me it is 100% the same as ee where you have the same issues so >>> keeping them aligned is better IMO. That said configuring globally the >>> scanning would be nice. >>> Le 1 mars 2015 15:54, "John D. Ament" a ?crit : >>> >>>> All, >>>> >>>> I'd like to propose in my doc changes for CDI-26 that if a classpath >>>> entry does not contain a META-INF/beans.xml that it is treated as if it >>>> were bean-discovery-mode=none, e.g. no beans will be scanned in that entry. >>>> (BTW, I'm using classpath entry rather than archive in the document to >>>> account for cases where someone does -cp >>>> "./classes:./extra-classes:./lib/*" to define their classpath) >>>> >>>> It's a bit different than how EE works, but I could imagine it causing >>>> fewer headaches when running on SE classpaths. >>>> >>>> Any thoughts/comments? >>>> >>>> John >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider licenses the >>>> code under the Apache License, Version 2 ( >>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>>> provided on this list, the provider waives all patent and other >>>> intellectual property rights inherent in such information. >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150301/5fbb8b2a/attachment-0001.html From rmannibucau at gmail.com Sun Mar 1 11:52:57 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sun, 1 Mar 2015 17:52:57 +0100 Subject: [cdi-dev] Bean Discovery Mode in SE In-Reply-To: References: Message-ID: well having a map as parameter is IMO mandatory at least for vendor features. about scanning we cant use it for EE but we could use a standard parameter. Issue we'll get here (EE) is we dont know when the container scans so not sure we can standardize it so easily, would maybe need some integration with other specs like a META-INF/scan.xml or something like that. I guess we can ignore EE short term to avoid another "by spec" solution - keeping vendor features for it in the mid term. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-03-01 17:49 GMT+01:00 John D. Ament : > So that's one of the benefits from my point of view of having that extra > initialize w/ map options. We can start to define some standard parameters > to control SE mode for some SE specific issues that may pop up. > > I'm just not sure how that'll apply yet, as ideally the issues should be > in both SE and EE. I think your case is mostly an SE problem, but the > other issues I'm thinking of are EE as well. > > - Additional scanning configuration on a global scale (package level and > classpath entry name [like you mentioned]). Package level since the > beans.xml files all end up at the same level. > - How to specify additional Bean Defining Annotations (for > bean-discovery-mode=annotated) > - Disable extension loading/Explicitly list extensions to load. > > There will probably be more options that come up as well. Maybe to fix > the SE/EE discrepancies, we allow the definition of a bean that returns a > Map that can be loaded in either SE or EE, and instead of > the default being an empty map we read this via a service loader or > something. > > John > > > On Sun, Mar 1, 2015 at 11:28 AM Romain Manni-Bucau > wrote: > >> It is consistent so ok. >> >> Wonder if we can get some rule we could pass to the container to say >> "dont scan jackson*jar" - issue begin we have to suppose we run with a >> classpath we dont control. Or the opposite "scan myapp*jar". >> >> wdyt? >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> 2015-03-01 16:18 GMT+01:00 John D. Ament : >> >>> Yeah actually you're right. For some reason I had in my head that "all" >>> was the default. It's very clearly not. Too early for some of this :-) >>> >>> So let me rephrase. "annotated" will be the default bean discovery mode >>> if a classpath entry contains no META-INF/beans.xml, based on the exact >>> same rules used in EE. >>> >>> Any concerns with that? >>> >>> John >>> >>> >>> On Sun, Mar 1, 2015 at 10:10 AM Romain Manni-Bucau < >>> rmannibucau at gmail.com> wrote: >>> >>>> For me it is 100% the same as ee where you have the same issues so >>>> keeping them aligned is better IMO. That said configuring globally the >>>> scanning would be nice. >>>> Le 1 mars 2015 15:54, "John D. Ament" a ?crit >>>> : >>>> >>>>> All, >>>>> >>>>> I'd like to propose in my doc changes for CDI-26 that if a classpath >>>>> entry does not contain a META-INF/beans.xml that it is treated as if it >>>>> were bean-discovery-mode=none, e.g. no beans will be scanned in that entry. >>>>> (BTW, I'm using classpath entry rather than archive in the document to >>>>> account for cases where someone does -cp >>>>> "./classes:./extra-classes:./lib/*" to define their classpath) >>>>> >>>>> It's a bit different than how EE works, but I could imagine it causing >>>>> fewer headaches when running on SE classpaths. >>>>> >>>>> Any thoughts/comments? >>>>> >>>>> John >>>>> >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>> Note that for all code provided on this list, the provider licenses >>>>> the code under the Apache License, Version 2 ( >>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>>>> provided on this list, the provider waives all patent and other >>>>> intellectual property rights inherent in such information. >>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150301/2f32bc6b/attachment.html From john.d.ament at gmail.com Sun Mar 1 12:34:21 2015 From: john.d.ament at gmail.com (John D. Ament) Date: Sun, 01 Mar 2015 17:34:21 +0000 Subject: [cdi-dev] Bean Discovery Mode in SE References: Message-ID: I would avoid adding yet another xml file. It'll be a bit hard to decide which XML files take precendence. For those looking to comment, the CDI SE page of the spec can be seen here, for comments: https://github.com/johnament/cdi/blob/CDI-26-docs/spec/src/main/doc/cdi-se.asciidoc John On Sun, Mar 1, 2015 at 11:53 AM Romain Manni-Bucau wrote: > well having a map as parameter is IMO mandatory at least for vendor > features. > > about scanning we cant use it for EE but we could use a standard > parameter. Issue we'll get here (EE) is we dont know when the container > scans so not sure we can standardize it so easily, would maybe need some > integration with other specs like a META-INF/scan.xml or something like > that. I guess we can ignore EE short term to avoid another "by spec" > solution - keeping vendor features for it in the mid term. > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2015-03-01 17:49 GMT+01:00 John D. Ament : > >> So that's one of the benefits from my point of view of having that extra >> initialize w/ map options. We can start to define some standard parameters >> to control SE mode for some SE specific issues that may pop up. >> >> I'm just not sure how that'll apply yet, as ideally the issues should be >> in both SE and EE. I think your case is mostly an SE problem, but the >> other issues I'm thinking of are EE as well. >> >> - Additional scanning configuration on a global scale (package level and >> classpath entry name [like you mentioned]). Package level since the >> beans.xml files all end up at the same level. >> - How to specify additional Bean Defining Annotations (for >> bean-discovery-mode=annotated) >> - Disable extension loading/Explicitly list extensions to load. >> >> There will probably be more options that come up as well. Maybe to fix >> the SE/EE discrepancies, we allow the definition of a bean that returns a >> Map that can be loaded in either SE or EE, and instead of >> the default being an empty map we read this via a service loader or >> something. >> >> John >> >> >> On Sun, Mar 1, 2015 at 11:28 AM Romain Manni-Bucau >> wrote: >> >>> It is consistent so ok. >>> >>> Wonder if we can get some rule we could pass to the container to say >>> "dont scan jackson*jar" - issue begin we have to suppose we run with a >>> classpath we dont control. Or the opposite "scan myapp*jar". >>> >>> wdyt? >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog >>> | Github >>> | LinkedIn >>> | Tomitriber >>> >>> >>> 2015-03-01 16:18 GMT+01:00 John D. Ament : >>> >>>> Yeah actually you're right. For some reason I had in my head that >>>> "all" was the default. It's very clearly not. Too early for some of this >>>> :-) >>>> >>>> So let me rephrase. "annotated" will be the default bean discovery >>>> mode if a classpath entry contains no META-INF/beans.xml, based on the >>>> exact same rules used in EE. >>>> >>>> Any concerns with that? >>>> >>>> John >>>> >>>> >>>> On Sun, Mar 1, 2015 at 10:10 AM Romain Manni-Bucau < >>>> rmannibucau at gmail.com> wrote: >>>> >>>>> For me it is 100% the same as ee where you have the same issues so >>>>> keeping them aligned is better IMO. That said configuring globally the >>>>> scanning would be nice. >>>>> Le 1 mars 2015 15:54, "John D. Ament" a >>>>> ?crit : >>>>> >>>>>> All, >>>>>> >>>>>> I'd like to propose in my doc changes for CDI-26 that if a classpath >>>>>> entry does not contain a META-INF/beans.xml that it is treated as if it >>>>>> were bean-discovery-mode=none, e.g. no beans will be scanned in that entry. >>>>>> (BTW, I'm using classpath entry rather than archive in the document to >>>>>> account for cases where someone does -cp >>>>>> "./classes:./extra-classes:./lib/*" to define their classpath) >>>>>> >>>>>> It's a bit different than how EE works, but I could imagine it >>>>>> causing fewer headaches when running on SE classpaths. >>>>>> >>>>>> Any thoughts/comments? >>>>>> >>>>>> John >>>>>> >>>>>> _______________________________________________ >>>>>> cdi-dev mailing list >>>>>> cdi-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>> >>>>>> Note that for all code provided on this list, the provider licenses >>>>>> the code under the Apache License, Version 2 ( >>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>>>>> ideas provided on this list, the provider waives all patent and other >>>>>> intellectual property rights inherent in such information. >>>>>> >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150301/d41d331c/attachment-0001.html From rmannibucau at gmail.com Sun Mar 1 12:40:04 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sun, 1 Mar 2015 18:40:04 +0100 Subject: [cdi-dev] Bean Discovery Mode in SE In-Reply-To: References: Message-ID: @John: I agree so we have to use web.xml or application.xml which doesn't fit CDI since we can't use any CDI descriptor ATM. A solution would be however maybe easy: master beans.xml (ie WEB-INF/beans.xml or META-INF/beans.xml for war/ear and a beans.xml given to container in standalone) Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-03-01 18:34 GMT+01:00 John D. Ament : > I would avoid adding yet another xml file. It'll be a bit hard to decide > which XML files take precendence. > > For those looking to comment, the CDI SE page of the spec can be seen > here, for comments: > > > https://github.com/johnament/cdi/blob/CDI-26-docs/spec/src/main/doc/cdi-se.asciidoc > > John > > On Sun, Mar 1, 2015 at 11:53 AM Romain Manni-Bucau > wrote: > >> well having a map as parameter is IMO mandatory at least for vendor >> features. >> >> about scanning we cant use it for EE but we could use a standard >> parameter. Issue we'll get here (EE) is we dont know when the container >> scans so not sure we can standardize it so easily, would maybe need some >> integration with other specs like a META-INF/scan.xml or something like >> that. I guess we can ignore EE short term to avoid another "by spec" >> solution - keeping vendor features for it in the mid term. >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> 2015-03-01 17:49 GMT+01:00 John D. Ament : >> >>> So that's one of the benefits from my point of view of having that extra >>> initialize w/ map options. We can start to define some standard parameters >>> to control SE mode for some SE specific issues that may pop up. >>> >>> I'm just not sure how that'll apply yet, as ideally the issues should be >>> in both SE and EE. I think your case is mostly an SE problem, but the >>> other issues I'm thinking of are EE as well. >>> >>> - Additional scanning configuration on a global scale (package level and >>> classpath entry name [like you mentioned]). Package level since the >>> beans.xml files all end up at the same level. >>> - How to specify additional Bean Defining Annotations (for >>> bean-discovery-mode=annotated) >>> - Disable extension loading/Explicitly list extensions to load. >>> >>> There will probably be more options that come up as well. Maybe to fix >>> the SE/EE discrepancies, we allow the definition of a bean that returns a >>> Map that can be loaded in either SE or EE, and instead of >>> the default being an empty map we read this via a service loader or >>> something. >>> >>> John >>> >>> >>> On Sun, Mar 1, 2015 at 11:28 AM Romain Manni-Bucau < >>> rmannibucau at gmail.com> wrote: >>> >>>> It is consistent so ok. >>>> >>>> Wonder if we can get some rule we could pass to the container to say >>>> "dont scan jackson*jar" - issue begin we have to suppose we run with a >>>> classpath we dont control. Or the opposite "scan myapp*jar". >>>> >>>> wdyt? >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau | Blog >>>> | Github >>>> | LinkedIn >>>> | Tomitriber >>>> >>>> >>>> 2015-03-01 16:18 GMT+01:00 John D. Ament : >>>> >>>>> Yeah actually you're right. For some reason I had in my head that >>>>> "all" was the default. It's very clearly not. Too early for some of this >>>>> :-) >>>>> >>>>> So let me rephrase. "annotated" will be the default bean discovery >>>>> mode if a classpath entry contains no META-INF/beans.xml, based on the >>>>> exact same rules used in EE. >>>>> >>>>> Any concerns with that? >>>>> >>>>> John >>>>> >>>>> >>>>> On Sun, Mar 1, 2015 at 10:10 AM Romain Manni-Bucau < >>>>> rmannibucau at gmail.com> wrote: >>>>> >>>>>> For me it is 100% the same as ee where you have the same issues so >>>>>> keeping them aligned is better IMO. That said configuring globally the >>>>>> scanning would be nice. >>>>>> Le 1 mars 2015 15:54, "John D. Ament" a >>>>>> ?crit : >>>>>> >>>>>>> All, >>>>>>> >>>>>>> I'd like to propose in my doc changes for CDI-26 that if a classpath >>>>>>> entry does not contain a META-INF/beans.xml that it is treated as if it >>>>>>> were bean-discovery-mode=none, e.g. no beans will be scanned in that entry. >>>>>>> (BTW, I'm using classpath entry rather than archive in the document to >>>>>>> account for cases where someone does -cp >>>>>>> "./classes:./extra-classes:./lib/*" to define their classpath) >>>>>>> >>>>>>> It's a bit different than how EE works, but I could imagine it >>>>>>> causing fewer headaches when running on SE classpaths. >>>>>>> >>>>>>> Any thoughts/comments? >>>>>>> >>>>>>> John >>>>>>> >>>>>>> _______________________________________________ >>>>>>> cdi-dev mailing list >>>>>>> cdi-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>> >>>>>>> Note that for all code provided on this list, the provider licenses >>>>>>> the code under the Apache License, Version 2 ( >>>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>>>>>> ideas provided on this list, the provider waives all patent and other >>>>>>> intellectual property rights inherent in such information. >>>>>>> >>>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150301/3d299aab/attachment.html From struberg at yahoo.de Tue Mar 3 08:54:42 2015 From: struberg at yahoo.de (Mark Struberg) Date: Tue, 3 Mar 2015 14:54:42 +0100 Subject: [cdi-dev] DefinitionException vs DeploymentException Message-ID: <6204D71F-B5CC-48C6-B0C7-62030EFD1342@yahoo.de> Hi! I think we currently fail to have a clean notion about what should be a DefinitionException and what should be a DeploymentException. It seems like most of the TCK in this regard is just modelling Weld behaviour and follows no whatever logic. E.,g. we have 2 tests doing almost the same: org.jboss.cdi.tck.tests.extensions.lifecycle.bbd.broken.passivatingScope.AddingPassivatingScopeTest Which according to the TCK should throw a DefinitionException and org.jboss.cdi.tck.tests.context.passivating.broken.NonPassivationManagedBeanHasPassivatingScopeTest which according to the TCK should throw a DeploymentException But BOTH actually do the same: they test if some managed bean implements Serializable. And both do this during bootstrap. Am I blind and don?t see the difference, or is all this just madly broken? LieGrue, strub From rmannibucau at gmail.com Tue Mar 3 08:56:32 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 3 Mar 2015 14:56:32 +0100 Subject: [cdi-dev] DefinitionException vs DeploymentException In-Reply-To: <6204D71F-B5CC-48C6-B0C7-62030EFD1342@yahoo.de> References: <6204D71F-B5CC-48C6-B0C7-62030EFD1342@yahoo.de> Message-ID: +1 saw the same as well working on cdi TCKs + with Instance and Provider not sure splitting it means anything Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-03-03 14:54 GMT+01:00 Mark Struberg : > Hi! > > I think we currently fail to have a clean notion about what should be a > DefinitionException and what should be a DeploymentException. > > It seems like most of the TCK in this regard is just modelling Weld > behaviour and follows no whatever logic. > > E.,g. we have 2 tests doing almost the same: > > org.jboss.cdi.tck.tests.extensions.lifecycle.bbd.broken.passivatingScope.AddingPassivatingScopeTest > Which according to the TCK should throw a DefinitionException > > and > > > org.jboss.cdi.tck.tests.context.passivating.broken.NonPassivationManagedBeanHasPassivatingScopeTest > which according to the TCK should throw a DeploymentException > > But BOTH actually do the same: they test if some managed bean implements > Serializable. And both do this during bootstrap. > > > Am I blind and don?t see the difference, or is all this just madly broken? > > LieGrue, > strub > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150303/f75d9f7d/attachment.html From jharting at redhat.com Tue Mar 3 09:46:21 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Tue, 03 Mar 2015 15:46:21 +0100 Subject: [cdi-dev] DefinitionException vs DeploymentException In-Reply-To: <6204D71F-B5CC-48C6-B0C7-62030EFD1342@yahoo.de> References: <6204D71F-B5CC-48C6-B0C7-62030EFD1342@yahoo.de> Message-ID: <54F5C93D.5050701@redhat.com> If a given scenario is well defined in the specification such as this one: "If a managed bean which declares a passivating scope is not passivation capable then the container automatically detects the problem and treats it as a deployment problem." then the RI should be firing DeploymentException and the TCK should require DeploymentException. If this does not happen then it is a bug. Please file an issue for each such bug you find. Jozef On 03/03/2015 02:54 PM, Mark Struberg wrote: > Hi! > > I think we currently fail to have a clean notion about what should be a DefinitionException and what should be a DeploymentException. > > It seems like most of the TCK in this regard is just modelling Weld behaviour and follows no whatever logic. > > E.,g. we have 2 tests doing almost the same: > org.jboss.cdi.tck.tests.extensions.lifecycle.bbd.broken.passivatingScope.AddingPassivatingScopeTest > Which according to the TCK should throw a DefinitionException > > and > > org.jboss.cdi.tck.tests.context.passivating.broken.NonPassivationManagedBeanHasPassivatingScopeTest > which according to the TCK should throw a DeploymentException > > But BOTH actually do the same: they test if some managed bean implements Serializable. And both do this during bootstrap. > > > Am I blind and don?t see the difference, or is all this just madly broken? > > LieGrue, > strub > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From issues at jboss.org Tue Mar 3 10:16:50 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Tue, 3 Mar 2015 10:16:50 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-513) AddingPassivatingScopeTest is illegal as addScope for passivating non-normalscopes is perfectly fine In-Reply-To: References: Message-ID: Mark Struberg created CDI-513: --------------------------------- Summary: AddingPassivatingScopeTest is illegal as addScope for passivating non-normalscopes is perfectly fine Key: CDI-513 URL: https://issues.jboss.org/browse/CDI-513 Project: CDI Specification Issues Issue Type: Clarification Affects Versions: 1.2.Final Reporter: Mark Struberg On behalf of Jozef I copied this to a CDI ticket... See CDITCK-466 I personally think it is clear as there is no single word which forbids this and there is a very vocal description about the single flags. ----- AddingPassivatingScopeTest is illegal as addScope for passivating non-normalscopes is perfectly fine. There is nothing in the spec which says that a non-normalscope cannot be passivating. The practical use case for this is e.g. when bridging over to Spring. Those beans might need to get checked for Serializable BUT spring brings it's own proxies. So we do not need to wrap it into just another normalscoping proxy. Actually the test should come in 2 flavours: 1.) RomanEmpire being Serializable -> all fine must work 2.) RomainEmpire not Serializable -> DefinitionException -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Mar 3 10:33:49 2015 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Tue, 3 Mar 2015 10:33:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-513) AddingPassivatingScopeTest is illegal as addScope for passivating non-normalscopes is perfectly fine In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045684#comment-13045684 ] Jozef Hartinger commented on CDI-513: ------------------------------------- Dear EG, please clarify whether the notion of a passivating pseudo-scope is valid in CDI. The following indirect evidence seems to contradict this: 1) There is no way to mark a pseudo-scope as passivating using annotations. Using BeforeBeanDiscovery.addScope(annotation, false, true) therefore looks like a possible hack (misuse of lenient signature) instead of an intended use case. 2) The author of the BeforeBeanDiscovery API himself implemented a check which treats passivating pseudo-scopes as invalid. See https://issues.jboss.org/browse/WELD-307 for details. The same author implemented the TCK test mentioned in https://issues.jboss.org/browse/CDITCK-466 3) 6.6.4 says: {quote} Passivating scopes must be explicitly declared @NormalScope(passivating=true). {quote} On the other hand, if passivating pseudoscopes were allowed it should not conflict with anything and this feature may be useful for certain use cases. > AddingPassivatingScopeTest is illegal as addScope for passivating non-normalscopes is perfectly fine > ---------------------------------------------------------------------------------------------------- > > Key: CDI-513 > URL: https://issues.jboss.org/browse/CDI-513 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Mark Struberg > > On behalf of Jozef I copied this to a CDI ticket... See CDITCK-466 > I personally think it is clear as there is no single word which forbids this and there is a very vocal description about the single flags. > ----- > AddingPassivatingScopeTest is illegal as addScope for passivating non-normalscopes is perfectly fine. > There is nothing in the spec which says that a non-normalscope cannot be passivating. > The practical use case for this is e.g. when bridging over to Spring. Those beans might need to get checked for Serializable BUT spring brings it's own proxies. So we do not need to wrap it into just another normalscoping proxy. > Actually the test should come in 2 flavours: > 1.) RomanEmpire being Serializable -> all fine must work > 2.) RomainEmpire not Serializable -> DefinitionException -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Mar 3 10:34:49 2015 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Tue, 3 Mar 2015 10:34:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-513) Clarify whether passivating pseudo-scopes are valid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jozef Hartinger updated CDI-513: -------------------------------- Summary: Clarify whether passivating pseudo-scopes are valid (was: AddingPassivatingScopeTest is illegal as addScope for passivating non-normalscopes is perfectly fine) > Clarify whether passivating pseudo-scopes are valid > --------------------------------------------------- > > Key: CDI-513 > URL: https://issues.jboss.org/browse/CDI-513 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Mark Struberg > > On behalf of Jozef I copied this to a CDI ticket... See CDITCK-466 > I personally think it is clear as there is no single word which forbids this and there is a very vocal description about the single flags. > ----- > AddingPassivatingScopeTest is illegal as addScope for passivating non-normalscopes is perfectly fine. > There is nothing in the spec which says that a non-normalscope cannot be passivating. > The practical use case for this is e.g. when bridging over to Spring. Those beans might need to get checked for Serializable BUT spring brings it's own proxies. So we do not need to wrap it into just another normalscoping proxy. > Actually the test should come in 2 flavours: > 1.) RomanEmpire being Serializable -> all fine must work > 2.) RomainEmpire not Serializable -> DefinitionException -- This message was sent by Atlassian JIRA (v6.3.11#6341) From struberg at yahoo.de Tue Mar 3 10:35:23 2015 From: struberg at yahoo.de (Mark Struberg) Date: Tue, 3 Mar 2015 16:35:23 +0100 Subject: [cdi-dev] DefinitionException vs DeploymentException In-Reply-To: <54F5C93D.5050701@redhat.com> References: <6204D71F-B5CC-48C6-B0C7-62030EFD1342@yahoo.de> <54F5C93D.5050701@redhat.com> Message-ID: After further investigation I found out that Weld forbids an imo valid use case. And this is what gets tested in AddingPassivatingScopeTest. Imo a.) the TCK test is wrong and b.) Weld should even support this case. See CDI-513 LieGrue, strub > Am 03.03.2015 um 15:46 schrieb Jozef Hartinger : > > If a given scenario is well defined in the specification such as this one: > > "If a managed bean which declares a passivating scope is not passivation capable then the container automatically detects the problem and treats it as a deployment problem." > > then the RI should be firing DeploymentException and the TCK should require DeploymentException. If this does not happen then it is a bug. Please file an issue for each such bug you find. > > Jozef > > On 03/03/2015 02:54 PM, Mark Struberg wrote: >> Hi! >> >> I think we currently fail to have a clean notion about what should be a DefinitionException and what should be a DeploymentException. >> >> It seems like most of the TCK in this regard is just modelling Weld behaviour and follows no whatever logic. >> >> E.,g. we have 2 tests doing almost the same: >> org.jboss.cdi.tck.tests.extensions.lifecycle.bbd.broken.passivatingScope.AddingPassivatingScopeTest >> Which according to the TCK should throw a DefinitionException >> >> and >> >> org.jboss.cdi.tck.tests.context.passivating.broken.NonPassivationManagedBeanHasPassivatingScopeTest >> which according to the TCK should throw a DeploymentException >> >> But BOTH actually do the same: they test if some managed bean implements Serializable. And both do this during bootstrap. >> >> >> Am I blind and don?t see the difference, or is all this just madly broken? >> >> LieGrue, >> strub >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > From issues at jboss.org Tue Mar 3 10:40:49 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Tue, 3 Mar 2015 10:40:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-513) Clarify whether passivating pseudo-scopes are valid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045687#comment-13045687 ] Mark Struberg commented on CDI-513: ----------------------------------- {quote} Passivating scopes must be explicitly declared @NormalScope(passivating=true). {quote} This would effectively render the whole addScope Extension method useless... How would you add a scope for the JSF @ViewScoped annotation in that case? (This annotation is neither @NormalScoped nor @Scope). I suggest we remove this whole sentence as it contradicts other spec parts. > Clarify whether passivating pseudo-scopes are valid > --------------------------------------------------- > > Key: CDI-513 > URL: https://issues.jboss.org/browse/CDI-513 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Mark Struberg > > On behalf of Jozef I copied this to a CDI ticket... See CDITCK-466 > I personally think it is clear as there is no single word which forbids this and there is a very vocal description about the single flags. > ----- > AddingPassivatingScopeTest is illegal as addScope for passivating non-normalscopes is perfectly fine. > There is nothing in the spec which says that a non-normalscope cannot be passivating. > The practical use case for this is e.g. when bridging over to Spring. Those beans might need to get checked for Serializable BUT spring brings it's own proxies. So we do not need to wrap it into just another normalscoping proxy. > Actually the test should come in 2 flavours: > 1.) RomanEmpire being Serializable -> all fine must work > 2.) RomainEmpire not Serializable -> DefinitionException -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Mar 3 10:45:51 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Tue, 3 Mar 2015 10:45:51 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-513) Clarify whether passivating pseudo-scopes are valid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045688#comment-13045688 ] Mark Struberg commented on CDI-513: ----------------------------------- Let's approach it from a different angle: does the combination non-normalscope AND passivating make sense? Imo it does. This are all the use cases where CDI does not handle the lifecycle (nor applies a proxy) but we would like to get the Serializable check. If anyone comes up with a blocker for this case then I'm perfectly happy to add a check that addScope(Xxx.class, false, true) is an illegal situation. If not then it must get supported. > Clarify whether passivating pseudo-scopes are valid > --------------------------------------------------- > > Key: CDI-513 > URL: https://issues.jboss.org/browse/CDI-513 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Mark Struberg > > On behalf of Jozef I copied this to a CDI ticket... See CDITCK-466 > I personally think it is clear as there is no single word which forbids this and there is a very vocal description about the single flags. > ----- > AddingPassivatingScopeTest is illegal as addScope for passivating non-normalscopes is perfectly fine. > There is nothing in the spec which says that a non-normalscope cannot be passivating. > The practical use case for this is e.g. when bridging over to Spring. Those beans might need to get checked for Serializable BUT spring brings it's own proxies. So we do not need to wrap it into just another normalscoping proxy. > Actually the test should come in 2 flavours: > 1.) RomanEmpire being Serializable -> all fine must work > 2.) RomainEmpire not Serializable -> DefinitionException -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Mar 3 12:24:49 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Tue, 3 Mar 2015 12:24:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-514) FireEventTest#testDuplicateBindingsToFireEventFails() is wrong In-Reply-To: References: Message-ID: Mark Struberg created CDI-514: --------------------------------- Summary: FireEventTest#testDuplicateBindingsToFireEventFails() is wrong Key: CDI-514 URL: https://issues.jboss.org/browse/CDI-514 Project: CDI Specification Issues Issue Type: Clarification Affects Versions: 1.2.Final Reporter: Mark Struberg testDuplicateBindingsToFireEventFails() tests for 2 Lifted literals with different values. But this is perfectly fine as value is NOT annotated as @Nonbinding. Thus the 2 literals are NOT equals according to CDI rules. They are essentially 2 different annotations... Plz remove this test. It also makes no sense to add all those very performance costly tests at runtime. The worst case which can happen is that the 2 annotations make no sense. But they don't break anything. Wheras checking all the nasty conditions each and every time is really mad from a performance aspect. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Mar 3 12:27:49 2015 From: issues at jboss.org (Sven Linstaedt (JIRA)) Date: Tue, 3 Mar 2015 12:27:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-513) Clarify whether passivating pseudo-scopes are valid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045774#comment-13045774 ] Sven Linstaedt commented on CDI-513: ------------------------------------ ...and having a PassivationCapable implementing returned by the container, which might be used by custom pseudo scopes. > Clarify whether passivating pseudo-scopes are valid > --------------------------------------------------- > > Key: CDI-513 > URL: https://issues.jboss.org/browse/CDI-513 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Mark Struberg > > On behalf of Jozef I copied this to a CDI ticket... See CDITCK-466 > I personally think it is clear as there is no single word which forbids this and there is a very vocal description about the single flags. > ----- > AddingPassivatingScopeTest is illegal as addScope for passivating non-normalscopes is perfectly fine. > There is nothing in the spec which says that a non-normalscope cannot be passivating. > The practical use case for this is e.g. when bridging over to Spring. Those beans might need to get checked for Serializable BUT spring brings it's own proxies. So we do not need to wrap it into just another normalscoping proxy. > Actually the test should come in 2 flavours: > 1.) RomanEmpire being Serializable -> all fine must work > 2.) RomainEmpire not Serializable -> DefinitionException -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Mar 3 12:30:49 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Tue, 3 Mar 2015 12:30:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-514) FireEventTest#testDuplicateBindingsToFireEventFails() is wrong In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045775#comment-13045775 ] Mark Struberg commented on CDI-514: ----------------------------------- the very same applies to org.jboss.cdi.tck.tests.event.select.SelectEventTest#testEventSelectWithSubtypeThrowsExceptionForDuplicateBindingType > FireEventTest#testDuplicateBindingsToFireEventFails() is wrong > -------------------------------------------------------------- > > Key: CDI-514 > URL: https://issues.jboss.org/browse/CDI-514 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Mark Struberg > > testDuplicateBindingsToFireEventFails() tests for 2 Lifted literals with different values. But this is perfectly fine as value is NOT annotated as @Nonbinding. Thus the 2 literals are NOT equals according to CDI rules. They are essentially 2 different annotations... > Plz remove this test. It also makes no sense to add all those very performance costly tests at runtime. The worst case which can happen is that the 2 annotations make no sense. But they don't break anything. Wheras checking all the nasty conditions each and every time is really mad from a performance aspect. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Mar 3 12:54:49 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Tue, 3 Mar 2015 12:54:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-514) FireEventTest#testDuplicateBindingsToFireEventFails() is wrong In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045785#comment-13045785 ] Mark Struberg commented on CDI-514: ----------------------------------- and in org.jboss.cdi.tck.tests.extensions.bean.bytype.BeanByTypeTest > FireEventTest#testDuplicateBindingsToFireEventFails() is wrong > -------------------------------------------------------------- > > Key: CDI-514 > URL: https://issues.jboss.org/browse/CDI-514 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Mark Struberg > > testDuplicateBindingsToFireEventFails() tests for 2 Lifted literals with different values. But this is perfectly fine as value is NOT annotated as @Nonbinding. Thus the 2 literals are NOT equals according to CDI rules. They are essentially 2 different annotations... > Plz remove this test. It also makes no sense to add all those very performance costly tests at runtime. The worst case which can happen is that the 2 annotations make no sense. But they don't break anything. Wheras checking all the nasty conditions each and every time is really mad from a performance aspect. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Mar 4 02:03:49 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 4 Mar 2015 02:03:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-515) Allow to obtain Bean metadata from javax.enterprise.inject.Instance In-Reply-To: References: Message-ID: Martin Kouba created CDI-515: -------------------------------- Summary: Allow to obtain Bean metadata from javax.enterprise.inject.Instance Key: CDI-515 URL: https://issues.jboss.org/browse/CDI-515 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Martin Kouba Sometimes it might be useful to obtain Bean metadata from the {{javax.enterprise.inject.Instance}} (similarly as 5.5.8. Bean metadata). The method could be named {{getBean()}} and should have similar restrictions like {{get()}} (e.g. throw {{UnsatisfiedResolutionException}} if appropriate). -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Mar 4 02:03:49 2015 From: issues at jboss.org (SBS JIRA Integration (JIRA)) Date: Wed, 4 Mar 2015 02:03:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-515) Allow to obtain Bean metadata from javax.enterprise.inject.Instance In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SBS JIRA Integration updated CDI-515: ------------------------------------- Forum Reference: https://developer.jboss.org/message/920438#920438 > Allow to obtain Bean metadata from javax.enterprise.inject.Instance > ------------------------------------------------------------------- > > Key: CDI-515 > URL: https://issues.jboss.org/browse/CDI-515 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > > Sometimes it might be useful to obtain Bean metadata from the {{javax.enterprise.inject.Instance}} (similarly as 5.5.8. Bean metadata). The method could be named {{getBean()}} and should have similar restrictions like {{get()}} (e.g. throw {{UnsatisfiedResolutionException}} if appropriate). -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Mar 4 02:54:49 2015 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Wed, 4 Mar 2015 02:54:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-514) FireEventTest#testDuplicateBindingsToFireEventFails() is wrong In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046030#comment-13046030 ] Tomas Remes commented on CDI-514: --------------------------------- This should be TCK issue right? Yes the instances are not equal but the types are so it seems to fine. It reflects given assertion IMO. > FireEventTest#testDuplicateBindingsToFireEventFails() is wrong > -------------------------------------------------------------- > > Key: CDI-514 > URL: https://issues.jboss.org/browse/CDI-514 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Mark Struberg > > testDuplicateBindingsToFireEventFails() tests for 2 Lifted literals with different values. But this is perfectly fine as value is NOT annotated as @Nonbinding. Thus the 2 literals are NOT equals according to CDI rules. They are essentially 2 different annotations... > Plz remove this test. It also makes no sense to add all those very performance costly tests at runtime. The worst case which can happen is that the 2 annotations make no sense. But they don't break anything. Wheras checking all the nasty conditions each and every time is really mad from a performance aspect. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Mar 4 02:56:48 2015 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Wed, 4 Mar 2015 02:56:48 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-514) FireEventTest#testDuplicateBindingsToFireEventFails() is wrong In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046030#comment-13046030 ] Tomas Remes edited comment on CDI-514 at 3/4/15 2:56 AM: --------------------------------------------------------- This should be TCK issue right? Yes the instances are not equal but the types are so it seems to me fine. It reflects given assertion IMO. was (Author: tremes): This should be TCK issue right? Yes the instances are not equal but the types are so it seems to fine. It reflects given assertion IMO. > FireEventTest#testDuplicateBindingsToFireEventFails() is wrong > -------------------------------------------------------------- > > Key: CDI-514 > URL: https://issues.jboss.org/browse/CDI-514 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Mark Struberg > > testDuplicateBindingsToFireEventFails() tests for 2 Lifted literals with different values. But this is perfectly fine as value is NOT annotated as @Nonbinding. Thus the 2 literals are NOT equals according to CDI rules. They are essentially 2 different annotations... > Plz remove this test. It also makes no sense to add all those very performance costly tests at runtime. The worst case which can happen is that the 2 annotations make no sense. But they don't break anything. Wheras checking all the nasty conditions each and every time is really mad from a performance aspect. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Mar 4 03:13:49 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Wed, 4 Mar 2015 03:13:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-514) FireEventTest#testDuplicateBindingsToFireEventFails() is wrong In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046043#comment-13046043 ] Mark Struberg commented on CDI-514: ----------------------------------- it seems the TCK tests what the spec wording says. But the very paragraph in the spec is broken. Will create a spec issue for it. > FireEventTest#testDuplicateBindingsToFireEventFails() is wrong > -------------------------------------------------------------- > > Key: CDI-514 > URL: https://issues.jboss.org/browse/CDI-514 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Mark Struberg > > testDuplicateBindingsToFireEventFails() tests for 2 Lifted literals with different values. But this is perfectly fine as value is NOT annotated as @Nonbinding. Thus the 2 literals are NOT equals according to CDI rules. They are essentially 2 different annotations... > Plz remove this test. It also makes no sense to add all those very performance costly tests at runtime. The worst case which can happen is that the 2 annotations make no sense. But they don't break anything. Wheras checking all the nasty conditions each and every time is really mad from a performance aspect. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Mar 4 03:33:49 2015 From: issues at jboss.org (Sven Linstaedt (JIRA)) Date: Wed, 4 Mar 2015 03:33:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-513) Clarify whether passivating pseudo-scopes are valid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045774#comment-13045774 ] Sven Linstaedt edited comment on CDI-513 at 3/4/15 3:33 AM: ------------------------------------------------------------ ...and having a PassivationCapable implementing bean returned by the container, which might be used by custom pseudo scopes. was (Author: tzwoenn): ...and having a PassivationCapable implementing returned by the container, which might be used by custom pseudo scopes. > Clarify whether passivating pseudo-scopes are valid > --------------------------------------------------- > > Key: CDI-513 > URL: https://issues.jboss.org/browse/CDI-513 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Mark Struberg > > On behalf of Jozef I copied this to a CDI ticket... See CDITCK-466 > I personally think it is clear as there is no single word which forbids this and there is a very vocal description about the single flags. > ----- > AddingPassivatingScopeTest is illegal as addScope for passivating non-normalscopes is perfectly fine. > There is nothing in the spec which says that a non-normalscope cannot be passivating. > The practical use case for this is e.g. when bridging over to Spring. Those beans might need to get checked for Serializable BUT spring brings it's own proxies. So we do not need to wrap it into just another normalscoping proxy. > Actually the test should come in 2 flavours: > 1.) RomanEmpire being Serializable -> all fine must work > 2.) RomainEmpire not Serializable -> DefinitionException -- This message was sent by Atlassian JIRA (v6.3.11#6341) From jharting at redhat.com Wed Mar 4 04:05:17 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 04 Mar 2015 10:05:17 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: References: <54DB1F2B.1020609@redhat.com> <54DC61D9.701@redhat.com> <54EECC20.6040600@redhat.com> <54EF396E.20805@redhat.com> <54F01720.3080802@redhat.com> Message-ID: <54F6CACD.6080507@redhat.com> Well it's nowhere given that we must have two separate interfaces for this. We can combine the start/stop API with the existing one to provide an application with a single reference representing the CDI container. On 02/28/2015 07:05 PM, John D. Ament wrote: > Maybe I'm misreading, but I don't see us adding another API to do the > same thing here - we're introducing new functionality. > > CDIContainer/Loader on startup/shutdown of the application > > CDI for runtime usage within the application to interact with the > container. > > John > > On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau > > wrote: > > sure I fully agree excepted I think introducing yet another API to do > the same thing is not good so super tempting to skip it and wait for > feedbacks rather than introducing it eagerly. > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-02-27 8:05 GMT+01:00 Jozef Hartinger >: > > My point is that from the application perspective, the user > obtains one > > container handle for eventual shutdown (CDIContainer) and then > looks up a > > different container handle (CDI) that they can use for real work > (lookup / > > event dispatch / etc.) It would be cleaner if the container gave > away a > > single handle that can do all of that. > > > > > > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: > > > > Not sure I get how a CDI instance can help. > > > > But container.getBeanManager() sounds nice is not a shortcut for > > CDI.current().getBm() otherwise it looks like duplication to me. > > > > Can we make container not contextual - dont think so? If so it > makes sense > > otherwise I fear it doesnt add much. > > > > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" > a ?crit : > >> > >> I like the initialize + close() combination and the > try-with-resources > >> usage. > >> What looks weird to me is that at line one you obtain a > container handle: > >> > >> try (CDIContainer container = CDIContainer.newCDIContai... > >> CDI.current().getBeanManager() ... > >> > >> and then at line two you call a static method to perform a > container > >> lookup :-/ > >> > >> An API that allows you to use the container handle you already > got is way > >> better IMO, e.g.: > >> > >> try (CDIContainer container = CDIContainer.newCDIContai... > >> container.getBeanManager() > >> > >> If CDIContainer.newCDIContainer() returns an CDI instance or > its subclass, > >> we get this easily. > >> > >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: > >>> > >>> Hi guys > >>> > >>> why note keeping it simple? > >>> > >>> try (CDIContainer container = CDIContainer.newCDIContainer(/* > optional > >>> map to configure vendor features */)) { > >>> CDI.current().getBeanManager().... > >>> } > >>> > >>> Not sure the point having initialize() + having shutdown = close > >>> really makes the API more fluent and modern IMO. > >>> > >>> Also to be fully SE I guess provider() method would be needed > even if > >>> optional (SPI usage by default): > >>> > >>> try (CDIContainer container = > >>> > >>> > CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider").newCDIContainer()) > >>> { > >>> CDI.current().getBeanManager().... > >>> } > >>> > >>> Finally I think having a kind of getInstance shortcut could be > a plus for > >>> SE: > >>> > >>> try (CDIContainer container = CDIContainer.newCDIContainer()) { > >>> container.newInstance(MyAppRunner.class /* optional > qualifiers */ > >>> ).run(args); > >>> } > >>> > >>> Using container to get an instance would create the instance > and bind > >>> it to the container lifecycle (mainly for predestroy) avoiding > this > >>> boilerplate code in all main which will surely only be used to > launch > >>> a soft. > >>> > >>> wdyt? > >>> > >>> > >>> > >>> Romain Manni-Bucau > >>> @rmannibucau > >>> http://www.tomitribe.com > >>> http://rmannibucau.wordpress.com > >>> https://github.com/rmannibucau > >>> > >>> > >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger >: > >>>> > >>>> Comments inline > >>>> > >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: > >>>> > >>>> Sorry Jozef, your email fell into the pits of google inbox's > "smart > >>>> sorting" > >>>> features. > >>>> > >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger > > > >>>> wrote: > >>>>> > >>>>> Hi John, comments inline: > >>>>> > >>>>> > >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: > >>>>> > >>>>> Jozef, > >>>>> > >>>>> Most of what you see there is taken from the original doc, since > >>>>> everyone > >>>>> seemed to be in agreement. I think the map is just a > safeguard in case > >>>>> of > >>>>> additional boot options available in some implementations > (e.g. I think > >>>>> OWB/OpenEJB have some options.. currently OpenEJB supports > an embedded > >>>>> CDI > >>>>> boot mode). > >>>>> > >>>>> No, I am fine with the map. What I am questioning is the > type of the > >>>>> map. > >>>>> Usually, data structures with a similar purpose use Strings > as their > >>>>> keys. > >>>>> This applies to ServletContext attributes, InvocationContext > data, > >>>>> Servlet > >>>>> request/session attributes and others. I am therefore > wondering whether > >>>>> there is a usecase for the proposed unbound key signature or > not. > >>>> > >>>> > >>>> I think that's more of a placeholder, I was assuming it would be > >>>> Map once we clarify everything. > >>>> > >>>>> > >>>>> > >>>>> We spoke a few times about BeanManager vs CDI. BeanManager was > >>>>> preferable > >>>>> since there's no easy way to get the the instance, CDI is > easier to get > >>>>> and > >>>>> more aligned with how you would get it. Usually people > expect the > >>>>> BeanManager to be injected or available via JNDI, neither > would be the > >>>>> case > >>>>> here. > >>>>> > >>>>> If CDI 2.0 targets Java SE then this container > initialization API will > >>>>> become something that ordinary application developers use to > start/stop > >>>>> CDI > >>>>> in their applications. It therefore cannot be considered an > SPI but > >>>>> instead > >>>>> should be something easy to use. On the other hand, > BeanManager is > >>>>> definitely an SPI. It is used in extension, frameworks and > generally > >>>>> for > >>>>> integration. Not much by applications directly. Therefore, I > don't see > >>>>> how > >>>>> the container bootstrap API and BeanManager fit together. > IMO the > >>>>> bootstrap > >>>>> API should expose something that makes common tasks (obtaining a > >>>>> contextual > >>>>> reference and firing and event) easy, which the CDI class does. > >>>>> > >>>>> Plus do not forget that BeanManager can be obtained easily using > >>>>> CDI.getBeanManager(). > >>>> > >>>> > >>>> I'm not disagreeing. There's a few things I'd consider: > >>>> > >>>> - Is this mostly for new apps or existing? If existing, it's > probably > >>>> using > >>>> some internal API, if new it can use whatever API we give. > >>>> - I don't want to return void, we should give some kind of > reference > >>>> into > >>>> the container when we're done booting. > >>>> > >>>> Agreed, we should not be returning void. > >>>> > >>>> - CDI is a one step retrievable reference, where as > BeanManager is a two > >>>> step reference. With that said, BeanManager makes more sense > to return > >>>> here. Another thought could be we invent some new class that > has both, > >>>> but > >>>> that's really redundant. > >>>> > >>>> Why do you think BeanManager makes more sense here? > Especially given the > >>>> assumption that application code is going to call this > init/shutdown > >>>> API, I > >>>> don't see BeanManager as making more sense. > >>>> > >>>> > >>>>> > >>>>> > >>>>> Yes, this is the container start API. Sounds like you have > some good > >>>>> ideas for things like XML configuration or programmatic > configuration, > >>>>> both > >>>>> of which are being tracked under separate tickets. One idea > might be > >>>>> for an > >>>>> optional param in the map to control packages to > scan/ignore, in that > >>>>> map. > >>>>> > >>>>> I am wondering whether this configuration should be > something optional > >>>>> built on top of the bootstrap API or whether we should > consider making > >>>>> it > >>>>> mandatory. Either way, we cannot add the bootstrap API to > the spec > >>>>> without > >>>>> explicitly defining how it behaves. My implicit assumption > of the > >>>>> proposal > >>>>> is that the container is supposed to scan the entire > classpath for > >>>>> explicit > >>>>> or implicit bean archives (including e.g. rt.jar), discover > beans, fire > >>>>> extensions, etc. This worries me as this default behavior is > far from > >>>>> being > >>>>> lightweight, which CDI for Java SE initially aimed to be. > >>>> > >>>> > >>>> Yes, the spec must be updated to reflect the behavior of SE > mode. I > >>>> plan to > >>>> get that completely into the google doc before opening any > spec changes > >>>> in a > >>>> PR. > >>>> > >>>>> > >>>>> > >>>>> We didn't want to over load the CDI interface. It already > does a lot. > >>>>> This is really SPI code, CDI even though it's in the spi > package is > >>>>> used in > >>>>> a lot of application code. > >>>>> > >>>>> I would personally prefer to have it all in one place. Having > >>>>> CDIContainer, CDIContainerLoader, CDI and CDIProvider makes > it more > >>>>> difficult to know when to use what. > >>>> > >>>> > >>>> The problem is that most CDI (the interface) operations are > against a > >>>> running container. I think we spoke about leveraging > CDIProvider at one > >>>> point (in fact, I mistakenly called CDIContainer CDIProvider > not even > >>>> realizing it was there). I doubt that most app developers use it > >>>> currently, > >>>> there's not even a way to get a reference to it that I'm > aware of. It's > >>>> used by the implementor only. > >>>> > >>>> I don't think there's a conflict. CDI class would still only > provide > >>>> methods > >>>> to be run against a running container. The difference is that > there > >>>> would be > >>>> additional static methods to get this running container (CDI > class) to > >>>> you > >>>> by starting the container. > >>>> > >>>> Either way, I agree that reusing CDIProvider is a must. There > is no > >>>> reason > >>>> to define a new class for the same purpose. > >>>> > >>>> > >>>> I expect that my changes in the CDI spec around this will > state, along > >>>> the > >>>> lines of: > >>>> > >>>> To retrieve a CDIContainer to launch, do this: > >>>> > >>>> CDIContainer container = CDIContainerLocator.getCDIContainer(); > >>>> container.initialize(); > >>>> ... do work > >>>> > >>>> Once you want to shutdown the container, do this: > >>>> > >>>> container.shutdown(); > >>>> > >>>> (we may want to consider implementing AutoCloseable, an > oversight on my > >>>> part) > >>>> > >>>> and then later on > >>>> > >>>> - What happens if I call CDIContainerLocator in an app server > >>>> > >>>> - It throws an IllegalStateException. > >>>> > >>>> - The container provides no beans of type CDIContainer, it is > managed > >>>> outside of the CDI container. > >>>> > >>>> > >>>>> > >>>>> > >>>>> John > >>>>> > >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger > > > >>>>> wrote: > >>>>>> > >>>>>> Hi John, some thoughts: > >>>>>> > >>>>>> - instead of using BeanManager it makes more sense to me to > return a > >>>>>> CDI > >>>>>> instance, which is a more user-friendly API (and it also > exposes > >>>>>> access to > >>>>>> BeanManager) > >>>>>> - is there a usecase for arbitrary keys of the "params" map > or is > >>>>>> Map sufficient? > >>>>>> - if we could move the shutdown() method from CDIContainer > to the > >>>>>> actual > >>>>>> container handle that we obtain from initialize(), that > would look > >>>>>> more > >>>>>> object-oriented > >>>>>> - what exactly is initialize() supposed to do? Is it > supposed to start > >>>>>> scanning the entire classpath for CDI beans? That could be > a problem > >>>>>> especially with spring-boot-like fat jars. I think we need > an API to > >>>>>> tell > >>>>>> the container which classes / packages to consider. > Something like > >>>>>> Guice's > >>>>>> binding API perhaps? > >>>>>> > >>>>>> - the proposal makes me wonder whether retrofitting this > functionality > >>>>>> to > >>>>>> the CDI class wouldn't be a better option. It could look like: > >>>>>> > >>>>>> CDI container = CDI.initialize(); > >>>>>> container.select(Foo.class).get(); > >>>>>> container.shutdown(); > >>>>>> > >>>>>> compare it to: > >>>>>> > >>>>>> CDIContainer container = CDIContainerLoader. getCDIContainer(); > >>>>>> BeanManager manager = container.initialize(); > >>>>>> manager.getBeans(...); > >>>>>> container.shutdown(manager); > >>>>>> > >>>>>> > >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: > >>>>>> > >>>>>> All, > >>>>>> > >>>>>> I have the updated API here, and wanted to solicit any > final feedback > >>>>>> before updating the google doc and spec pages. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c > >>>>>> > >>>>>> Let me know your thoughts. > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> John > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> cdi-dev mailing list > >>>>>> cdi-dev at lists.jboss.org > >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>>>> > >>>>>> Note that for all code provided on this list, the provider > licenses > >>>>>> the > >>>>>> code under the Apache License, Version 2 > >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all > other ideas > >>>>>> provided on this list, the provider waives all patent and other > >>>>>> intellectual > >>>>>> property rights inherent in such information. > >>>>>> > >>>>>> > >>>> > >>>> _______________________________________________ > >>>> cdi-dev mailing list > >>>> cdi-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>> > >>>> Note that for all code provided on this list, the provider > licenses the > >>>> code > >>>> under the Apache License, Version 2 > >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all > other ideas > >>>> provided on this list, the provider waives all patent and other > >>>> intellectual > >>>> property rights inherent in such information. > >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/8e4c37fc/attachment-0001.html From jharting at redhat.com Wed Mar 4 04:06:51 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 04 Mar 2015 10:06:51 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: References: <54DB1F2B.1020609@redhat.com> <54DC61D9.701@redhat.com> <54EECC20.6040600@redhat.com> <54EF396E.20805@redhat.com> <54F01720.3080802@redhat.com> Message-ID: <54F6CB2B.5080909@redhat.com> What exactly is the static inject supposed to do? Would that be the same as c.select(MyMain.class).get().doWork()? On 02/28/2015 10:11 PM, Romain Manni-Bucau wrote: > > Yes but not the way to get an instance. Even Unmanaged does it. > > What can be awesome is to have static inject for it: > > public class Runner { > > @Inject > private static MyMain main; > > public static void main(String[] arg) { > try (CDIContainer c = CDIContainer.newContainer()) { > main.doWork(); > } > } > > } > > And not a single additional line :). > > Le 28 f?vr. 2015 19:05, "John D. Ament" > a ?crit : > > Maybe I'm misreading, but I don't see us adding another API to do > the same thing here - we're introducing new functionality. > > CDIContainer/Loader on startup/shutdown of the application > > CDI for runtime usage within the application to interact with the > container. > > John > > On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau > > wrote: > > sure I fully agree excepted I think introducing yet another > API to do > the same thing is not good so super tempting to skip it and > wait for > feedbacks rather than introducing it eagerly. > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-02-27 8:05 GMT+01:00 Jozef Hartinger >: > > My point is that from the application perspective, the user > obtains one > > container handle for eventual shutdown (CDIContainer) and > then looks up a > > different container handle (CDI) that they can use for real > work (lookup / > > event dispatch / etc.) It would be cleaner if the container > gave away a > > single handle that can do all of that. > > > > > > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: > > > > Not sure I get how a CDI instance can help. > > > > But container.getBeanManager() sounds nice is not a shortcut for > > CDI.current().getBm() otherwise it looks like duplication to me. > > > > Can we make container not contextual - dont think so? If so > it makes sense > > otherwise I fear it doesnt add much. > > > > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" > > a ?crit : > >> > >> I like the initialize + close() combination and the > try-with-resources > >> usage. > >> What looks weird to me is that at line one you obtain a > container handle: > >> > >> try (CDIContainer container = CDIContainer.newCDIContai... > >> CDI.current().getBeanManager() ... > >> > >> and then at line two you call a static method to perform a > container > >> lookup :-/ > >> > >> An API that allows you to use the container handle you > already got is way > >> better IMO, e.g.: > >> > >> try (CDIContainer container = CDIContainer.newCDIContai... > >> container.getBeanManager() > >> > >> If CDIContainer.newCDIContainer() returns an CDI instance > or its subclass, > >> we get this easily. > >> > >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: > >>> > >>> Hi guys > >>> > >>> why note keeping it simple? > >>> > >>> try (CDIContainer container = > CDIContainer.newCDIContainer(/* optional > >>> map to configure vendor features */)) { > >>> CDI.current().getBeanManager().... > >>> } > >>> > >>> Not sure the point having initialize() + having shutdown = > close > >>> really makes the API more fluent and modern IMO. > >>> > >>> Also to be fully SE I guess provider() method would be > needed even if > >>> optional (SPI usage by default): > >>> > >>> try (CDIContainer container = > >>> > >>> > CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider").newCDIContainer()) > >>> { > >>> CDI.current().getBeanManager().... > >>> } > >>> > >>> Finally I think having a kind of getInstance shortcut > could be a plus for > >>> SE: > >>> > >>> try (CDIContainer container = > CDIContainer.newCDIContainer()) { > >>> container.newInstance(MyAppRunner.class /* optional > qualifiers */ > >>> ).run(args); > >>> } > >>> > >>> Using container to get an instance would create the > instance and bind > >>> it to the container lifecycle (mainly for predestroy) > avoiding this > >>> boilerplate code in all main which will surely only be > used to launch > >>> a soft. > >>> > >>> wdyt? > >>> > >>> > >>> > >>> Romain Manni-Bucau > >>> @rmannibucau > >>> http://www.tomitribe.com > >>> http://rmannibucau.wordpress.com > >>> https://github.com/rmannibucau > >>> > >>> > >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger > >: > >>>> > >>>> Comments inline > >>>> > >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: > >>>> > >>>> Sorry Jozef, your email fell into the pits of google > inbox's "smart > >>>> sorting" > >>>> features. > >>>> > >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger > > > >>>> wrote: > >>>>> > >>>>> Hi John, comments inline: > >>>>> > >>>>> > >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: > >>>>> > >>>>> Jozef, > >>>>> > >>>>> Most of what you see there is taken from the original > doc, since > >>>>> everyone > >>>>> seemed to be in agreement. I think the map is just a > safeguard in case > >>>>> of > >>>>> additional boot options available in some > implementations (e.g. I think > >>>>> OWB/OpenEJB have some options.. currently OpenEJB > supports an embedded > >>>>> CDI > >>>>> boot mode). > >>>>> > >>>>> No, I am fine with the map. What I am questioning is the > type of the > >>>>> map. > >>>>> Usually, data structures with a similar purpose use > Strings as their > >>>>> keys. > >>>>> This applies to ServletContext attributes, > InvocationContext data, > >>>>> Servlet > >>>>> request/session attributes and others. I am therefore > wondering whether > >>>>> there is a usecase for the proposed unbound key > signature or not. > >>>> > >>>> > >>>> I think that's more of a placeholder, I was assuming it > would be > >>>> Map once we clarify everything. > >>>> > >>>>> > >>>>> > >>>>> We spoke a few times about BeanManager vs CDI. > BeanManager was > >>>>> preferable > >>>>> since there's no easy way to get the the instance, CDI > is easier to get > >>>>> and > >>>>> more aligned with how you would get it. Usually people > expect the > >>>>> BeanManager to be injected or available via JNDI, > neither would be the > >>>>> case > >>>>> here. > >>>>> > >>>>> If CDI 2.0 targets Java SE then this container > initialization API will > >>>>> become something that ordinary application developers > use to start/stop > >>>>> CDI > >>>>> in their applications. It therefore cannot be considered > an SPI but > >>>>> instead > >>>>> should be something easy to use. On the other hand, > BeanManager is > >>>>> definitely an SPI. It is used in extension, frameworks > and generally > >>>>> for > >>>>> integration. Not much by applications directly. > Therefore, I don't see > >>>>> how > >>>>> the container bootstrap API and BeanManager fit > together. IMO the > >>>>> bootstrap > >>>>> API should expose something that makes common tasks > (obtaining a > >>>>> contextual > >>>>> reference and firing and event) easy, which the CDI > class does. > >>>>> > >>>>> Plus do not forget that BeanManager can be obtained > easily using > >>>>> CDI.getBeanManager(). > >>>> > >>>> > >>>> I'm not disagreeing. There's a few things I'd consider: > >>>> > >>>> - Is this mostly for new apps or existing? If existing, > it's probably > >>>> using > >>>> some internal API, if new it can use whatever API we give. > >>>> - I don't want to return void, we should give some kind > of reference > >>>> into > >>>> the container when we're done booting. > >>>> > >>>> Agreed, we should not be returning void. > >>>> > >>>> - CDI is a one step retrievable reference, where as > BeanManager is a two > >>>> step reference. With that said, BeanManager makes more > sense to return > >>>> here. Another thought could be we invent some new class > that has both, > >>>> but > >>>> that's really redundant. > >>>> > >>>> Why do you think BeanManager makes more sense here? > Especially given the > >>>> assumption that application code is going to call this > init/shutdown > >>>> API, I > >>>> don't see BeanManager as making more sense. > >>>> > >>>> > >>>>> > >>>>> > >>>>> Yes, this is the container start API. Sounds like you > have some good > >>>>> ideas for things like XML configuration or programmatic > configuration, > >>>>> both > >>>>> of which are being tracked under separate tickets. One > idea might be > >>>>> for an > >>>>> optional param in the map to control packages to > scan/ignore, in that > >>>>> map. > >>>>> > >>>>> I am wondering whether this configuration should be > something optional > >>>>> built on top of the bootstrap API or whether we should > consider making > >>>>> it > >>>>> mandatory. Either way, we cannot add the bootstrap API > to the spec > >>>>> without > >>>>> explicitly defining how it behaves. My implicit > assumption of the > >>>>> proposal > >>>>> is that the container is supposed to scan the entire > classpath for > >>>>> explicit > >>>>> or implicit bean archives (including e.g. rt.jar), > discover beans, fire > >>>>> extensions, etc. This worries me as this default > behavior is far from > >>>>> being > >>>>> lightweight, which CDI for Java SE initially aimed to be. > >>>> > >>>> > >>>> Yes, the spec must be updated to reflect the behavior of > SE mode. I > >>>> plan to > >>>> get that completely into the google doc before opening > any spec changes > >>>> in a > >>>> PR. > >>>> > >>>>> > >>>>> > >>>>> We didn't want to over load the CDI interface. It > already does a lot. > >>>>> This is really SPI code, CDI even though it's in the spi > package is > >>>>> used in > >>>>> a lot of application code. > >>>>> > >>>>> I would personally prefer to have it all in one place. > Having > >>>>> CDIContainer, CDIContainerLoader, CDI and CDIProvider > makes it more > >>>>> difficult to know when to use what. > >>>> > >>>> > >>>> The problem is that most CDI (the interface) operations > are against a > >>>> running container. I think we spoke about leveraging > CDIProvider at one > >>>> point (in fact, I mistakenly called CDIContainer > CDIProvider not even > >>>> realizing it was there). I doubt that most app > developers use it > >>>> currently, > >>>> there's not even a way to get a reference to it that I'm > aware of. It's > >>>> used by the implementor only. > >>>> > >>>> I don't think there's a conflict. CDI class would still > only provide > >>>> methods > >>>> to be run against a running container. The difference is > that there > >>>> would be > >>>> additional static methods to get this running container > (CDI class) to > >>>> you > >>>> by starting the container. > >>>> > >>>> Either way, I agree that reusing CDIProvider is a must. > There is no > >>>> reason > >>>> to define a new class for the same purpose. > >>>> > >>>> > >>>> I expect that my changes in the CDI spec around this will > state, along > >>>> the > >>>> lines of: > >>>> > >>>> To retrieve a CDIContainer to launch, do this: > >>>> > >>>> CDIContainer container = > CDIContainerLocator.getCDIContainer(); > >>>> container.initialize(); > >>>> ... do work > >>>> > >>>> Once you want to shutdown the container, do this: > >>>> > >>>> container.shutdown(); > >>>> > >>>> (we may want to consider implementing AutoCloseable, an > oversight on my > >>>> part) > >>>> > >>>> and then later on > >>>> > >>>> - What happens if I call CDIContainerLocator in an app server > >>>> > >>>> - It throws an IllegalStateException. > >>>> > >>>> - The container provides no beans of type CDIContainer, > it is managed > >>>> outside of the CDI container. > >>>> > >>>> > >>>>> > >>>>> > >>>>> John > >>>>> > >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger > > > >>>>> wrote: > >>>>>> > >>>>>> Hi John, some thoughts: > >>>>>> > >>>>>> - instead of using BeanManager it makes more sense to > me to return a > >>>>>> CDI > >>>>>> instance, which is a more user-friendly API (and it > also exposes > >>>>>> access to > >>>>>> BeanManager) > >>>>>> - is there a usecase for arbitrary keys of the "params" > map or is > >>>>>> Map sufficient? > >>>>>> - if we could move the shutdown() method from > CDIContainer to the > >>>>>> actual > >>>>>> container handle that we obtain from initialize(), that > would look > >>>>>> more > >>>>>> object-oriented > >>>>>> - what exactly is initialize() supposed to do? Is it > supposed to start > >>>>>> scanning the entire classpath for CDI beans? That could > be a problem > >>>>>> especially with spring-boot-like fat jars. I think we > need an API to > >>>>>> tell > >>>>>> the container which classes / packages to consider. > Something like > >>>>>> Guice's > >>>>>> binding API perhaps? > >>>>>> > >>>>>> - the proposal makes me wonder whether retrofitting > this functionality > >>>>>> to > >>>>>> the CDI class wouldn't be a better option. It could > look like: > >>>>>> > >>>>>> CDI container = CDI.initialize(); > >>>>>> container.select(Foo.class).get(); > >>>>>> container.shutdown(); > >>>>>> > >>>>>> compare it to: > >>>>>> > >>>>>> CDIContainer container = CDIContainerLoader. > getCDIContainer(); > >>>>>> BeanManager manager = container.initialize(); > >>>>>> manager.getBeans(...); > >>>>>> container.shutdown(manager); > >>>>>> > >>>>>> > >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: > >>>>>> > >>>>>> All, > >>>>>> > >>>>>> I have the updated API here, and wanted to solicit any > final feedback > >>>>>> before updating the google doc and spec pages. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c > >>>>>> > >>>>>> Let me know your thoughts. > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> John > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> cdi-dev mailing list > >>>>>> cdi-dev at lists.jboss.org > >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>>>> > >>>>>> Note that for all code provided on this list, the > provider licenses > >>>>>> the > >>>>>> code under the Apache License, Version 2 > >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For > all other ideas > >>>>>> provided on this list, the provider waives all patent > and other > >>>>>> intellectual > >>>>>> property rights inherent in such information. > >>>>>> > >>>>>> > >>>> > >>>> _______________________________________________ > >>>> cdi-dev mailing list > >>>> cdi-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>> > >>>> Note that for all code provided on this list, the > provider licenses the > >>>> code > >>>> under the Apache License, Version 2 > >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For > all other ideas > >>>> provided on this list, the provider waives all patent and > other > >>>> intellectual > >>>> property rights inherent in such information. > >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/45cad730/attachment-0001.html From rmannibucau at gmail.com Wed Mar 4 04:12:51 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 4 Mar 2015 10:12:51 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: <54F6CB2B.5080909@redhat.com> References: <54DB1F2B.1020609@redhat.com> <54DC61D9.701@redhat.com> <54EECC20.6040600@redhat.com> <54EF396E.20805@redhat.com> <54F01720.3080802@redhat.com> <54F6CB2B.5080909@redhat.com> Message-ID: @Jozef: yes but without having to programmatically use anything: "keep it smooth" Alternative and maybe cleaner would be to support boot class in Container API: public class MyMain { @Inject SuperService service; @Start public void run() { ...} } and in the real main: try (CDIContainer container = CDIContainer.Builder.withBooter(MyMain.class) .newCDIContainer(/* optional map to configure vendor features */)) { // wait } PS: if we have @Startup no need of anything then Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-03-04 10:06 GMT+01:00 Jozef Hartinger : > What exactly is the static inject supposed to do? > Would that be the same as c.select(MyMain.class).get().doWork()? > > > On 02/28/2015 10:11 PM, Romain Manni-Bucau wrote: > > Yes but not the way to get an instance. Even Unmanaged does it. > > What can be awesome is to have static inject for it: > > public class Runner { > > @Inject > private static MyMain main; > > public static void main(String[] arg) { > try (CDIContainer c = CDIContainer.newContainer()) { > main.doWork(); > } > } > > } > > And not a single additional line :). > Le 28 f?vr. 2015 19:05, "John D. Ament" a ?crit > : > >> Maybe I'm misreading, but I don't see us adding another API to do the >> same thing here - we're introducing new functionality. >> >> CDIContainer/Loader on startup/shutdown of the application >> >> CDI for runtime usage within the application to interact with the >> container. >> >> John >> >> On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau >> wrote: >> >>> sure I fully agree excepted I think introducing yet another API to do >>> the same thing is not good so super tempting to skip it and wait for >>> feedbacks rather than introducing it eagerly. >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau >>> http://www.tomitribe.com >>> http://rmannibucau.wordpress.com >>> https://github.com/rmannibucau >>> >>> >>> 2015-02-27 8:05 GMT+01:00 Jozef Hartinger : >>> > My point is that from the application perspective, the user obtains one >>> > container handle for eventual shutdown (CDIContainer) and then looks >>> up a >>> > different container handle (CDI) that they can use for real work >>> (lookup / >>> > event dispatch / etc.) It would be cleaner if the container gave away a >>> > single handle that can do all of that. >>> > >>> > >>> > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: >>> > >>> > Not sure I get how a CDI instance can help. >>> > >>> > But container.getBeanManager() sounds nice is not a shortcut for >>> > CDI.current().getBm() otherwise it looks like duplication to me. >>> > >>> > Can we make container not contextual - dont think so? If so it makes >>> sense >>> > otherwise I fear it doesnt add much. >>> > >>> > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" a >>> ?crit : >>> >> >>> >> I like the initialize + close() combination and the try-with-resources >>> >> usage. >>> >> What looks weird to me is that at line one you obtain a container >>> handle: >>> >> >>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>> >> CDI.current().getBeanManager() ... >>> >> >>> >> and then at line two you call a static method to perform a container >>> >> lookup :-/ >>> >> >>> >> An API that allows you to use the container handle you already got is >>> way >>> >> better IMO, e.g.: >>> >> >>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>> >> container.getBeanManager() >>> >> >>> >> If CDIContainer.newCDIContainer() returns an CDI instance or its >>> subclass, >>> >> we get this easily. >>> >> >>> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: >>> >>> >>> >>> Hi guys >>> >>> >>> >>> why note keeping it simple? >>> >>> >>> >>> try (CDIContainer container = CDIContainer.newCDIContainer(/* >>> optional >>> >>> map to configure vendor features */)) { >>> >>> CDI.current().getBeanManager().... >>> >>> } >>> >>> >>> >>> Not sure the point having initialize() + having shutdown = close >>> >>> really makes the API more fluent and modern IMO. >>> >>> >>> >>> Also to be fully SE I guess provider() method would be needed even if >>> >>> optional (SPI usage by default): >>> >>> >>> >>> try (CDIContainer container = >>> >>> >>> >>> >>> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider").newCDIContainer()) >>> >>> { >>> >>> CDI.current().getBeanManager().... >>> >>> } >>> >>> >>> >>> Finally I think having a kind of getInstance shortcut could be a >>> plus for >>> >>> SE: >>> >>> >>> >>> try (CDIContainer container = CDIContainer.newCDIContainer()) { >>> >>> container.newInstance(MyAppRunner.class /* optional qualifiers >>> */ >>> >>> ).run(args); >>> >>> } >>> >>> >>> >>> Using container to get an instance would create the instance and bind >>> >>> it to the container lifecycle (mainly for predestroy) avoiding this >>> >>> boilerplate code in all main which will surely only be used to launch >>> >>> a soft. >>> >>> >>> >>> wdyt? >>> >>> >>> >>> >>> >>> >>> >>> Romain Manni-Bucau >>> >>> @rmannibucau >>> >>> http://www.tomitribe.com >>> >>> http://rmannibucau.wordpress.com >>> >>> https://github.com/rmannibucau >>> >>> >>> >>> >>> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger : >>> >>>> >>> >>>> Comments inline >>> >>>> >>> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: >>> >>>> >>> >>>> Sorry Jozef, your email fell into the pits of google inbox's "smart >>> >>>> sorting" >>> >>>> features. >>> >>>> >>> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger < >>> jharting at redhat.com> >>> >>>> wrote: >>> >>>>> >>> >>>>> Hi John, comments inline: >>> >>>>> >>> >>>>> >>> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >>> >>>>> >>> >>>>> Jozef, >>> >>>>> >>> >>>>> Most of what you see there is taken from the original doc, since >>> >>>>> everyone >>> >>>>> seemed to be in agreement. I think the map is just a safeguard in >>> case >>> >>>>> of >>> >>>>> additional boot options available in some implementations (e.g. I >>> think >>> >>>>> OWB/OpenEJB have some options.. currently OpenEJB supports an >>> embedded >>> >>>>> CDI >>> >>>>> boot mode). >>> >>>>> >>> >>>>> No, I am fine with the map. What I am questioning is the type of >>> the >>> >>>>> map. >>> >>>>> Usually, data structures with a similar purpose use Strings as >>> their >>> >>>>> keys. >>> >>>>> This applies to ServletContext attributes, InvocationContext data, >>> >>>>> Servlet >>> >>>>> request/session attributes and others. I am therefore wondering >>> whether >>> >>>>> there is a usecase for the proposed unbound key signature or not. >>> >>>> >>> >>>> >>> >>>> I think that's more of a placeholder, I was assuming it would be >>> >>>> Map once we clarify everything. >>> >>>> >>> >>>>> >>> >>>>> >>> >>>>> We spoke a few times about BeanManager vs CDI. BeanManager was >>> >>>>> preferable >>> >>>>> since there's no easy way to get the the instance, CDI is easier >>> to get >>> >>>>> and >>> >>>>> more aligned with how you would get it. Usually people expect the >>> >>>>> BeanManager to be injected or available via JNDI, neither would be >>> the >>> >>>>> case >>> >>>>> here. >>> >>>>> >>> >>>>> If CDI 2.0 targets Java SE then this container initialization API >>> will >>> >>>>> become something that ordinary application developers use to >>> start/stop >>> >>>>> CDI >>> >>>>> in their applications. It therefore cannot be considered an SPI but >>> >>>>> instead >>> >>>>> should be something easy to use. On the other hand, BeanManager is >>> >>>>> definitely an SPI. It is used in extension, frameworks and >>> generally >>> >>>>> for >>> >>>>> integration. Not much by applications directly. Therefore, I don't >>> see >>> >>>>> how >>> >>>>> the container bootstrap API and BeanManager fit together. IMO the >>> >>>>> bootstrap >>> >>>>> API should expose something that makes common tasks (obtaining a >>> >>>>> contextual >>> >>>>> reference and firing and event) easy, which the CDI class does. >>> >>>>> >>> >>>>> Plus do not forget that BeanManager can be obtained easily using >>> >>>>> CDI.getBeanManager(). >>> >>>> >>> >>>> >>> >>>> I'm not disagreeing. There's a few things I'd consider: >>> >>>> >>> >>>> - Is this mostly for new apps or existing? If existing, it's >>> probably >>> >>>> using >>> >>>> some internal API, if new it can use whatever API we give. >>> >>>> - I don't want to return void, we should give some kind of reference >>> >>>> into >>> >>>> the container when we're done booting. >>> >>>> >>> >>>> Agreed, we should not be returning void. >>> >>>> >>> >>>> - CDI is a one step retrievable reference, where as BeanManager is >>> a two >>> >>>> step reference. With that said, BeanManager makes more sense to >>> return >>> >>>> here. Another thought could be we invent some new class that has >>> both, >>> >>>> but >>> >>>> that's really redundant. >>> >>>> >>> >>>> Why do you think BeanManager makes more sense here? Especially >>> given the >>> >>>> assumption that application code is going to call this init/shutdown >>> >>>> API, I >>> >>>> don't see BeanManager as making more sense. >>> >>>> >>> >>>> >>> >>>>> >>> >>>>> >>> >>>>> Yes, this is the container start API. Sounds like you have some >>> good >>> >>>>> ideas for things like XML configuration or programmatic >>> configuration, >>> >>>>> both >>> >>>>> of which are being tracked under separate tickets. One idea might >>> be >>> >>>>> for an >>> >>>>> optional param in the map to control packages to scan/ignore, in >>> that >>> >>>>> map. >>> >>>>> >>> >>>>> I am wondering whether this configuration should be something >>> optional >>> >>>>> built on top of the bootstrap API or whether we should consider >>> making >>> >>>>> it >>> >>>>> mandatory. Either way, we cannot add the bootstrap API to the spec >>> >>>>> without >>> >>>>> explicitly defining how it behaves. My implicit assumption of the >>> >>>>> proposal >>> >>>>> is that the container is supposed to scan the entire classpath for >>> >>>>> explicit >>> >>>>> or implicit bean archives (including e.g. rt.jar), discover beans, >>> fire >>> >>>>> extensions, etc. This worries me as this default behavior is far >>> from >>> >>>>> being >>> >>>>> lightweight, which CDI for Java SE initially aimed to be. >>> >>>> >>> >>>> >>> >>>> Yes, the spec must be updated to reflect the behavior of SE mode. I >>> >>>> plan to >>> >>>> get that completely into the google doc before opening any spec >>> changes >>> >>>> in a >>> >>>> PR. >>> >>>> >>> >>>>> >>> >>>>> >>> >>>>> We didn't want to over load the CDI interface. It already does a >>> lot. >>> >>>>> This is really SPI code, CDI even though it's in the spi package is >>> >>>>> used in >>> >>>>> a lot of application code. >>> >>>>> >>> >>>>> I would personally prefer to have it all in one place. Having >>> >>>>> CDIContainer, CDIContainerLoader, CDI and CDIProvider makes it more >>> >>>>> difficult to know when to use what. >>> >>>> >>> >>>> >>> >>>> The problem is that most CDI (the interface) operations are against >>> a >>> >>>> running container. I think we spoke about leveraging CDIProvider >>> at one >>> >>>> point (in fact, I mistakenly called CDIContainer CDIProvider not >>> even >>> >>>> realizing it was there). I doubt that most app developers use it >>> >>>> currently, >>> >>>> there's not even a way to get a reference to it that I'm aware of. >>> It's >>> >>>> used by the implementor only. >>> >>>> >>> >>>> I don't think there's a conflict. CDI class would still only provide >>> >>>> methods >>> >>>> to be run against a running container. The difference is that there >>> >>>> would be >>> >>>> additional static methods to get this running container (CDI class) >>> to >>> >>>> you >>> >>>> by starting the container. >>> >>>> >>> >>>> Either way, I agree that reusing CDIProvider is a must. There is no >>> >>>> reason >>> >>>> to define a new class for the same purpose. >>> >>>> >>> >>>> >>> >>>> I expect that my changes in the CDI spec around this will state, >>> along >>> >>>> the >>> >>>> lines of: >>> >>>> >>> >>>> To retrieve a CDIContainer to launch, do this: >>> >>>> >>> >>>> CDIContainer container = CDIContainerLocator.getCDIContainer(); >>> >>>> container.initialize(); >>> >>>> ... do work >>> >>>> >>> >>>> Once you want to shutdown the container, do this: >>> >>>> >>> >>>> container.shutdown(); >>> >>>> >>> >>>> (we may want to consider implementing AutoCloseable, an oversight >>> on my >>> >>>> part) >>> >>>> >>> >>>> and then later on >>> >>>> >>> >>>> - What happens if I call CDIContainerLocator in an app server >>> >>>> >>> >>>> - It throws an IllegalStateException. >>> >>>> >>> >>>> - The container provides no beans of type CDIContainer, it is >>> managed >>> >>>> outside of the CDI container. >>> >>>> >>> >>>> >>> >>>>> >>> >>>>> >>> >>>>> John >>> >>>>> >>> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger < >>> jharting at redhat.com> >>> >>>>> wrote: >>> >>>>>> >>> >>>>>> Hi John, some thoughts: >>> >>>>>> >>> >>>>>> - instead of using BeanManager it makes more sense to me to >>> return a >>> >>>>>> CDI >>> >>>>>> instance, which is a more user-friendly API (and it also exposes >>> >>>>>> access to >>> >>>>>> BeanManager) >>> >>>>>> - is there a usecase for arbitrary keys of the "params" map or is >>> >>>>>> Map sufficient? >>> >>>>>> - if we could move the shutdown() method from CDIContainer to the >>> >>>>>> actual >>> >>>>>> container handle that we obtain from initialize(), that would look >>> >>>>>> more >>> >>>>>> object-oriented >>> >>>>>> - what exactly is initialize() supposed to do? Is it supposed to >>> start >>> >>>>>> scanning the entire classpath for CDI beans? That could be a >>> problem >>> >>>>>> especially with spring-boot-like fat jars. I think we need an API >>> to >>> >>>>>> tell >>> >>>>>> the container which classes / packages to consider. Something like >>> >>>>>> Guice's >>> >>>>>> binding API perhaps? >>> >>>>>> >>> >>>>>> - the proposal makes me wonder whether retrofitting this >>> functionality >>> >>>>>> to >>> >>>>>> the CDI class wouldn't be a better option. It could look like: >>> >>>>>> >>> >>>>>> CDI container = CDI.initialize(); >>> >>>>>> container.select(Foo.class).get(); >>> >>>>>> container.shutdown(); >>> >>>>>> >>> >>>>>> compare it to: >>> >>>>>> >>> >>>>>> CDIContainer container = CDIContainerLoader. getCDIContainer(); >>> >>>>>> BeanManager manager = container.initialize(); >>> >>>>>> manager.getBeans(...); >>> >>>>>> container.shutdown(manager); >>> >>>>>> >>> >>>>>> >>> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >>> >>>>>> >>> >>>>>> All, >>> >>>>>> >>> >>>>>> I have the updated API here, and wanted to solicit any final >>> feedback >>> >>>>>> before updating the google doc and spec pages. >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c >>> >>>>>> >>> >>>>>> Let me know your thoughts. >>> >>>>>> >>> >>>>>> Thanks, >>> >>>>>> >>> >>>>>> John >>> >>>>>> >>> >>>>>> >>> >>>>>> _______________________________________________ >>> >>>>>> cdi-dev mailing list >>> >>>>>> cdi-dev at lists.jboss.org >>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>>>>> >>> >>>>>> Note that for all code provided on this list, the provider >>> licenses >>> >>>>>> the >>> >>>>>> code under the Apache License, Version 2 >>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>> ideas >>> >>>>>> provided on this list, the provider waives all patent and other >>> >>>>>> intellectual >>> >>>>>> property rights inherent in such information. >>> >>>>>> >>> >>>>>> >>> >>>> >>> >>>> _______________________________________________ >>> >>>> cdi-dev mailing list >>> >>>> cdi-dev at lists.jboss.org >>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>>> >>> >>>> Note that for all code provided on this list, the provider licenses >>> the >>> >>>> code >>> >>>> under the Apache License, Version 2 >>> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>> ideas >>> >>>> provided on this list, the provider waives all patent and other >>> >>>> intellectual >>> >>>> property rights inherent in such information. >>> >> >>> >> >>> > >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/adbfcd51/attachment-0001.html From jharting at redhat.com Wed Mar 4 04:14:41 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 04 Mar 2015 10:14:41 +0100 Subject: [cdi-dev] Bean Discovery Mode in SE In-Reply-To: References: Message-ID: <54F6CD01.5080806@redhat.com> For EE assuming bean-discovery-mode="annotated" by default if no beans.xml is found is OK as the scope of scanning is limited by the deployment. In SE however this would require that we scan the entire classpath for scope annotations, stereotypes, etc. I am therefore concerned about the performance implications of this. On 03/01/2015 04:18 PM, John D. Ament wrote: > Yeah actually you're right. For some reason I had in my head that > "all" was the default. It's very clearly not. Too early for some of > this :-) > > So let me rephrase. "annotated" will be the default bean discovery > mode if a classpath entry contains no META-INF/beans.xml, based on the > exact same rules used in EE. > > Any concerns with that? > > John > > On Sun, Mar 1, 2015 at 10:10 AM Romain Manni-Bucau > > wrote: > > For me it is 100% the same as ee where you have the same issues so > keeping them aligned is better IMO. That said configuring globally > the scanning would be nice. > > Le 1 mars 2015 15:54, "John D. Ament" > a ?crit : > > All, > > I'd like to propose in my doc changes for CDI-26 that if a > classpath entry does not contain a META-INF/beans.xml that it > is treated as if it were bean-discovery-mode=none, e.g. no > beans will be scanned in that entry. (BTW, I'm using classpath > entry rather than archive in the document to account for cases > where someone does -cp "./classes:./extra-classes:./lib/*" to > define their classpath) > > It's a bit different than how EE works, but I could imagine it > causing fewer headaches when running on SE classpaths. > > Any thoughts/comments? > > John > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider > licenses the code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all > other ideas provided on this list, the provider waives all > patent and other intellectual property rights inherent in such > information. > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/9342b71f/attachment.html From issues at jboss.org Wed Mar 4 04:27:49 2015 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Wed, 4 Mar 2015 04:27:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-514) FireEventTest#testDuplicateBindingsToFireEventFails() is wrong In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046062#comment-13046062 ] Jozef Hartinger commented on CDI-514: ------------------------------------- Right, the spec is very clear about this and the TCK follows that. As for the spec being "broken" it seems that the spec just enforces that the SPI usage is consistent with what the language allows regarding annotations (at most one annotation of a type on a given location). > FireEventTest#testDuplicateBindingsToFireEventFails() is wrong > -------------------------------------------------------------- > > Key: CDI-514 > URL: https://issues.jboss.org/browse/CDI-514 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Mark Struberg > > testDuplicateBindingsToFireEventFails() tests for 2 Lifted literals with different values. But this is perfectly fine as value is NOT annotated as @Nonbinding. Thus the 2 literals are NOT equals according to CDI rules. They are essentially 2 different annotations... > Plz remove this test. It also makes no sense to add all those very performance costly tests at runtime. The worst case which can happen is that the 2 annotations make no sense. But they don't break anything. Wheras checking all the nasty conditions each and every time is really mad from a performance aspect. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From jharting at redhat.com Wed Mar 4 04:33:45 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 04 Mar 2015 10:33:45 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: References: <54DB1F2B.1020609@redhat.com> <54DC61D9.701@redhat.com> <54EECC20.6040600@redhat.com> <54EF396E.20805@redhat.com> <54F01720.3080802@redhat.com> Message-ID: <54F6D179.2070109@redhat.com> I am wondering if we need to expose both CDIContainer and CDIContainerLoader to the user. Could we instead follow what CDI does where CDI is the only class exposed and CDIProvider is a not-exposed SPI? Also, given that CDIProvider is kind of an SPI what about reusing it as a provider of CDIContainer also? Another though: What about changing the signature to something like: public class CDIContainer extends CDI implements AutoCloseable Jozef On 03/01/2015 03:13 PM, John D. Ament wrote: > So, I think I've gathered enough feedback at this point, and seen some > of the API changes. I'll hopefully be including some doc changes this > week, but one question - do we want to start the SE specific stuff as > its own asciidoc file? > > Changes made: > > - Changed return value to CDI to provide better capability out > of the box. > - Added AutoCloseable to CDIContainer, provided default implementation > of calling shutdown. > - Added synchronization support to the method body that retrieves the > singleton instance (BTW, I'm not sure if this is even useful TBH as > each impl, including the RI, needs to provide this class in its own > format). > - Made the params map typed to > > @Romain Your case isn't really supportable yet, until we have static > injection support. You'd still have to have a managed version of > Runner to work against. > > John > > On Sat, Feb 28, 2015 at 4:11 PM Romain Manni-Bucau > > wrote: > > Yes but not the way to get an instance. Even Unmanaged does it. > > What can be awesome is to have static inject for it: > > public class Runner { > > @Inject > private static MyMain main; > > public static void main(String[] arg) { > try (CDIContainer c = CDIContainer.newContainer()) { > main.doWork(); > } > } > > } > > And not a single additional line :). > > Le 28 f?vr. 2015 19:05, "John D. Ament" > a ?crit : > > Maybe I'm misreading, but I don't see us adding another API to > do the same thing here - we're introducing new functionality. > > CDIContainer/Loader on startup/shutdown of the application > > CDI for runtime usage within the application to interact with > the container. > > John > > On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau > > wrote: > > sure I fully agree excepted I think introducing yet > another API to do > the same thing is not good so super tempting to skip it > and wait for > feedbacks rather than introducing it eagerly. > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-02-27 8:05 GMT+01:00 Jozef Hartinger > >: > > My point is that from the application perspective, the > user obtains one > > container handle for eventual shutdown (CDIContainer) > and then looks up a > > different container handle (CDI) that they can use for > real work (lookup / > > event dispatch / etc.) It would be cleaner if the > container gave away a > > single handle that can do all of that. > > > > > > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: > > > > Not sure I get how a CDI instance can help. > > > > But container.getBeanManager() sounds nice is not a > shortcut for > > CDI.current().getBm() otherwise it looks like > duplication to me. > > > > Can we make container not contextual - dont think so? If > so it makes sense > > otherwise I fear it doesnt add much. > > > > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" > > a ?crit : > >> > >> I like the initialize + close() combination and the > try-with-resources > >> usage. > >> What looks weird to me is that at line one you obtain a > container handle: > >> > >> try (CDIContainer container = CDIContainer.newCDIContai... > >> CDI.current().getBeanManager() ... > >> > >> and then at line two you call a static method to > perform a container > >> lookup :-/ > >> > >> An API that allows you to use the container handle you > already got is way > >> better IMO, e.g.: > >> > >> try (CDIContainer container = CDIContainer.newCDIContai... > >> container.getBeanManager() > >> > >> If CDIContainer.newCDIContainer() returns an CDI > instance or its subclass, > >> we get this easily. > >> > >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: > >>> > >>> Hi guys > >>> > >>> why note keeping it simple? > >>> > >>> try (CDIContainer container = > CDIContainer.newCDIContainer(/* optional > >>> map to configure vendor features */)) { > >>> CDI.current().getBeanManager().... > >>> } > >>> > >>> Not sure the point having initialize() + having > shutdown = close > >>> really makes the API more fluent and modern IMO. > >>> > >>> Also to be fully SE I guess provider() method would be > needed even if > >>> optional (SPI usage by default): > >>> > >>> try (CDIContainer container = > >>> > >>> > CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider").newCDIContainer()) > >>> { > >>> CDI.current().getBeanManager().... > >>> } > >>> > >>> Finally I think having a kind of getInstance shortcut > could be a plus for > >>> SE: > >>> > >>> try (CDIContainer container = > CDIContainer.newCDIContainer()) { > >>> container.newInstance(MyAppRunner.class /* > optional qualifiers */ > >>> ).run(args); > >>> } > >>> > >>> Using container to get an instance would create the > instance and bind > >>> it to the container lifecycle (mainly for predestroy) > avoiding this > >>> boilerplate code in all main which will surely only be > used to launch > >>> a soft. > >>> > >>> wdyt? > >>> > >>> > >>> > >>> Romain Manni-Bucau > >>> @rmannibucau > >>> http://www.tomitribe.com > >>> http://rmannibucau.wordpress.com > >>> https://github.com/rmannibucau > >>> > >>> > >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger > >: > >>>> > >>>> Comments inline > >>>> > >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: > >>>> > >>>> Sorry Jozef, your email fell into the pits of google > inbox's "smart > >>>> sorting" > >>>> features. > >>>> > >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger > > > >>>> wrote: > >>>>> > >>>>> Hi John, comments inline: > >>>>> > >>>>> > >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: > >>>>> > >>>>> Jozef, > >>>>> > >>>>> Most of what you see there is taken from the > original doc, since > >>>>> everyone > >>>>> seemed to be in agreement. I think the map is just > a safeguard in case > >>>>> of > >>>>> additional boot options available in some > implementations (e.g. I think > >>>>> OWB/OpenEJB have some options.. currently OpenEJB > supports an embedded > >>>>> CDI > >>>>> boot mode). > >>>>> > >>>>> No, I am fine with the map. What I am questioning is > the type of the > >>>>> map. > >>>>> Usually, data structures with a similar purpose use > Strings as their > >>>>> keys. > >>>>> This applies to ServletContext attributes, > InvocationContext data, > >>>>> Servlet > >>>>> request/session attributes and others. I am > therefore wondering whether > >>>>> there is a usecase for the proposed unbound key > signature or not. > >>>> > >>>> > >>>> I think that's more of a placeholder, I was assuming > it would be > >>>> Map once we clarify everything. > >>>> > >>>>> > >>>>> > >>>>> We spoke a few times about BeanManager vs CDI. > BeanManager was > >>>>> preferable > >>>>> since there's no easy way to get the the instance, > CDI is easier to get > >>>>> and > >>>>> more aligned with how you would get it. Usually > people expect the > >>>>> BeanManager to be injected or available via JNDI, > neither would be the > >>>>> case > >>>>> here. > >>>>> > >>>>> If CDI 2.0 targets Java SE then this container > initialization API will > >>>>> become something that ordinary application > developers use to start/stop > >>>>> CDI > >>>>> in their applications. It therefore cannot be > considered an SPI but > >>>>> instead > >>>>> should be something easy to use. On the other hand, > BeanManager is > >>>>> definitely an SPI. It is used in extension, > frameworks and generally > >>>>> for > >>>>> integration. Not much by applications directly. > Therefore, I don't see > >>>>> how > >>>>> the container bootstrap API and BeanManager fit > together. IMO the > >>>>> bootstrap > >>>>> API should expose something that makes common tasks > (obtaining a > >>>>> contextual > >>>>> reference and firing and event) easy, which the CDI > class does. > >>>>> > >>>>> Plus do not forget that BeanManager can be obtained > easily using > >>>>> CDI.getBeanManager(). > >>>> > >>>> > >>>> I'm not disagreeing. There's a few things I'd consider: > >>>> > >>>> - Is this mostly for new apps or existing? If > existing, it's probably > >>>> using > >>>> some internal API, if new it can use whatever API we > give. > >>>> - I don't want to return void, we should give some > kind of reference > >>>> into > >>>> the container when we're done booting. > >>>> > >>>> Agreed, we should not be returning void. > >>>> > >>>> - CDI is a one step retrievable reference, where as > BeanManager is a two > >>>> step reference. With that said, BeanManager makes > more sense to return > >>>> here. Another thought could be we invent some new > class that has both, > >>>> but > >>>> that's really redundant. > >>>> > >>>> Why do you think BeanManager makes more sense here? > Especially given the > >>>> assumption that application code is going to call > this init/shutdown > >>>> API, I > >>>> don't see BeanManager as making more sense. > >>>> > >>>> > >>>>> > >>>>> > >>>>> Yes, this is the container start API. Sounds like > you have some good > >>>>> ideas for things like XML configuration or > programmatic configuration, > >>>>> both > >>>>> of which are being tracked under separate tickets. > One idea might be > >>>>> for an > >>>>> optional param in the map to control packages to > scan/ignore, in that > >>>>> map. > >>>>> > >>>>> I am wondering whether this configuration should be > something optional > >>>>> built on top of the bootstrap API or whether we > should consider making > >>>>> it > >>>>> mandatory. Either way, we cannot add the bootstrap > API to the spec > >>>>> without > >>>>> explicitly defining how it behaves. My implicit > assumption of the > >>>>> proposal > >>>>> is that the container is supposed to scan the entire > classpath for > >>>>> explicit > >>>>> or implicit bean archives (including e.g. rt.jar), > discover beans, fire > >>>>> extensions, etc. This worries me as this default > behavior is far from > >>>>> being > >>>>> lightweight, which CDI for Java SE initially aimed > to be. > >>>> > >>>> > >>>> Yes, the spec must be updated to reflect the behavior > of SE mode. I > >>>> plan to > >>>> get that completely into the google doc before > opening any spec changes > >>>> in a > >>>> PR. > >>>> > >>>>> > >>>>> > >>>>> We didn't want to over load the CDI interface. It > already does a lot. > >>>>> This is really SPI code, CDI even though it's in the > spi package is > >>>>> used in > >>>>> a lot of application code. > >>>>> > >>>>> I would personally prefer to have it all in one > place. Having > >>>>> CDIContainer, CDIContainerLoader, CDI and > CDIProvider makes it more > >>>>> difficult to know when to use what. > >>>> > >>>> > >>>> The problem is that most CDI (the interface) > operations are against a > >>>> running container. I think we spoke about leveraging > CDIProvider at one > >>>> point (in fact, I mistakenly called CDIContainer > CDIProvider not even > >>>> realizing it was there). I doubt that most app > developers use it > >>>> currently, > >>>> there's not even a way to get a reference to it that > I'm aware of. It's > >>>> used by the implementor only. > >>>> > >>>> I don't think there's a conflict. CDI class would > still only provide > >>>> methods > >>>> to be run against a running container. The difference > is that there > >>>> would be > >>>> additional static methods to get this running > container (CDI class) to > >>>> you > >>>> by starting the container. > >>>> > >>>> Either way, I agree that reusing CDIProvider is a > must. There is no > >>>> reason > >>>> to define a new class for the same purpose. > >>>> > >>>> > >>>> I expect that my changes in the CDI spec around this > will state, along > >>>> the > >>>> lines of: > >>>> > >>>> To retrieve a CDIContainer to launch, do this: > >>>> > >>>> CDIContainer container = > CDIContainerLocator.getCDIContainer(); > >>>> container.initialize(); > >>>> ... do work > >>>> > >>>> Once you want to shutdown the container, do this: > >>>> > >>>> container.shutdown(); > >>>> > >>>> (we may want to consider implementing AutoCloseable, > an oversight on my > >>>> part) > >>>> > >>>> and then later on > >>>> > >>>> - What happens if I call CDIContainerLocator in an > app server > >>>> > >>>> - It throws an IllegalStateException. > >>>> > >>>> - The container provides no beans of type > CDIContainer, it is managed > >>>> outside of the CDI container. > >>>> > >>>> > >>>>> > >>>>> > >>>>> John > >>>>> > >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger > > > >>>>> wrote: > >>>>>> > >>>>>> Hi John, some thoughts: > >>>>>> > >>>>>> - instead of using BeanManager it makes more sense > to me to return a > >>>>>> CDI > >>>>>> instance, which is a more user-friendly API (and it > also exposes > >>>>>> access to > >>>>>> BeanManager) > >>>>>> - is there a usecase for arbitrary keys of the > "params" map or is > >>>>>> Map sufficient? > >>>>>> - if we could move the shutdown() method from > CDIContainer to the > >>>>>> actual > >>>>>> container handle that we obtain from initialize(), > that would look > >>>>>> more > >>>>>> object-oriented > >>>>>> - what exactly is initialize() supposed to do? Is > it supposed to start > >>>>>> scanning the entire classpath for CDI beans? That > could be a problem > >>>>>> especially with spring-boot-like fat jars. I think > we need an API to > >>>>>> tell > >>>>>> the container which classes / packages to consider. > Something like > >>>>>> Guice's > >>>>>> binding API perhaps? > >>>>>> > >>>>>> - the proposal makes me wonder whether retrofitting > this functionality > >>>>>> to > >>>>>> the CDI class wouldn't be a better option. It could > look like: > >>>>>> > >>>>>> CDI container = CDI.initialize(); > >>>>>> container.select(Foo.class).get(); > >>>>>> container.shutdown(); > >>>>>> > >>>>>> compare it to: > >>>>>> > >>>>>> CDIContainer container = CDIContainerLoader. > getCDIContainer(); > >>>>>> BeanManager manager = container.initialize(); > >>>>>> manager.getBeans(...); > >>>>>> container.shutdown(manager); > >>>>>> > >>>>>> > >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: > >>>>>> > >>>>>> All, > >>>>>> > >>>>>> I have the updated API here, and wanted to solicit > any final feedback > >>>>>> before updating the google doc and spec pages. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c > >>>>>> > >>>>>> Let me know your thoughts. > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> John > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> cdi-dev mailing list > >>>>>> cdi-dev at lists.jboss.org > > >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>>>> > >>>>>> Note that for all code provided on this list, the > provider licenses > >>>>>> the > >>>>>> code under the Apache License, Version 2 > >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). > For all other ideas > >>>>>> provided on this list, the provider waives all > patent and other > >>>>>> intellectual > >>>>>> property rights inherent in such information. > >>>>>> > >>>>>> > >>>> > >>>> _______________________________________________ > >>>> cdi-dev mailing list > >>>> cdi-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>> > >>>> Note that for all code provided on this list, the > provider licenses the > >>>> code > >>>> under the Apache License, Version 2 > >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). > For all other ideas > >>>> provided on this list, the provider waives all patent > and other > >>>> intellectual > >>>> property rights inherent in such information. > >> > >> > > > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/1e8bd149/attachment-0001.html From jharting at redhat.com Wed Mar 4 04:36:32 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 04 Mar 2015 10:36:32 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: References: <54DB1F2B.1020609@redhat.com> <54DC61D9.701@redhat.com> <54EECC20.6040600@redhat.com> <54EF396E.20805@redhat.com> <54F01720.3080802@redhat.com> <54F6CB2B.5080909@redhat.com> Message-ID: <54F6D220.3030408@redhat.com> You can already do: static void run(@Observes @Initialized(ApplicationScoped.class) Object event, InjectAnythingElseINeedHere object) { } On 03/04/2015 10:12 AM, Romain Manni-Bucau wrote: > @Jozef: yes but without having to programmatically use anything: "keep > it smooth" > > Alternative and maybe cleaner would be to support boot class in > Container API: > > public class MyMain { > @Inject SuperService service; > > @Start > public void run() { ...} > } > > and in the real main: > > try (CDIContainer container = > CDIContainer.Builder.withBooter(MyMain.class).newCDIContainer(/* optional > map to configure vendor features */)) { > // wait > } > > PS: if we have @Startup no need of anything then > > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2015-03-04 10:06 GMT+01:00 Jozef Hartinger >: > > What exactly is the static inject supposed to do? > Would that be the same as c.select(MyMain.class).get().doWork()? > > > On 02/28/2015 10:11 PM, Romain Manni-Bucau wrote: >> >> Yes but not the way to get an instance. Even Unmanaged does it. >> >> What can be awesome is to have static inject for it: >> >> public class Runner { >> >> @Inject >> private static MyMain main; >> >> public static void main(String[] arg) { >> try (CDIContainer c = CDIContainer.newContainer()) { >> main.doWork(); >> } >> } >> >> } >> >> And not a single additional line :). >> >> Le 28 f?vr. 2015 19:05, "John D. Ament" > > a ?crit : >> >> Maybe I'm misreading, but I don't see us adding another API >> to do the same thing here - we're introducing new functionality. >> >> CDIContainer/Loader on startup/shutdown of the application >> >> CDI for runtime usage within the application to interact with >> the container. >> >> John >> >> On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau >> > wrote: >> >> sure I fully agree excepted I think introducing yet >> another API to do >> the same thing is not good so super tempting to skip it >> and wait for >> feedbacks rather than introducing it eagerly. >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-02-27 8:05 GMT+01:00 Jozef Hartinger >> >: >> > My point is that from the application perspective, the >> user obtains one >> > container handle for eventual shutdown (CDIContainer) >> and then looks up a >> > different container handle (CDI) that they can use for >> real work (lookup / >> > event dispatch / etc.) It would be cleaner if the >> container gave away a >> > single handle that can do all of that. >> > >> > >> > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: >> > >> > Not sure I get how a CDI instance can help. >> > >> > But container.getBeanManager() sounds nice is not a >> shortcut for >> > CDI.current().getBm() otherwise it looks like >> duplication to me. >> > >> > Can we make container not contextual - dont think so? >> If so it makes sense >> > otherwise I fear it doesnt add much. >> > >> > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" >> > a ?crit : >> >> >> >> I like the initialize + close() combination and the >> try-with-resources >> >> usage. >> >> What looks weird to me is that at line one you obtain >> a container handle: >> >> >> >> try (CDIContainer container = CDIContainer.newCDIContai... >> >> CDI.current().getBeanManager() ... >> >> >> >> and then at line two you call a static method to >> perform a container >> >> lookup :-/ >> >> >> >> An API that allows you to use the container handle you >> already got is way >> >> better IMO, e.g.: >> >> >> >> try (CDIContainer container = CDIContainer.newCDIContai... >> >> container.getBeanManager() >> >> >> >> If CDIContainer.newCDIContainer() returns an CDI >> instance or its subclass, >> >> we get this easily. >> >> >> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: >> >>> >> >>> Hi guys >> >>> >> >>> why note keeping it simple? >> >>> >> >>> try (CDIContainer container = >> CDIContainer.newCDIContainer(/* optional >> >>> map to configure vendor features */)) { >> >>> CDI.current().getBeanManager().... >> >>> } >> >>> >> >>> Not sure the point having initialize() + having >> shutdown = close >> >>> really makes the API more fluent and modern IMO. >> >>> >> >>> Also to be fully SE I guess provider() method would >> be needed even if >> >>> optional (SPI usage by default): >> >>> >> >>> try (CDIContainer container = >> >>> >> >>> >> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider").newCDIContainer()) >> >>> { >> >>> CDI.current().getBeanManager().... >> >>> } >> >>> >> >>> Finally I think having a kind of getInstance shortcut >> could be a plus for >> >>> SE: >> >>> >> >>> try (CDIContainer container = >> CDIContainer.newCDIContainer()) { >> >>> container.newInstance(MyAppRunner.class /* optional >> qualifiers */ >> >>> ).run(args); >> >>> } >> >>> >> >>> Using container to get an instance would create the >> instance and bind >> >>> it to the container lifecycle (mainly for predestroy) >> avoiding this >> >>> boilerplate code in all main which will surely only >> be used to launch >> >>> a soft. >> >>> >> >>> wdyt? >> >>> >> >>> >> >>> >> >>> Romain Manni-Bucau >> >>> @rmannibucau >> >>> http://www.tomitribe.com >> >>> http://rmannibucau.wordpress.com >> >>> https://github.com/rmannibucau >> >>> >> >>> >> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger >> >: >> >>>> >> >>>> Comments inline >> >>>> >> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: >> >>>> >> >>>> Sorry Jozef, your email fell into the pits of google >> inbox's "smart >> >>>> sorting" >> >>>> features. >> >>>> >> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger >> > >> >>>> wrote: >> >>>>> >> >>>>> Hi John, comments inline: >> >>>>> >> >>>>> >> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >> >>>>> >> >>>>> Jozef, >> >>>>> >> >>>>> Most of what you see there is taken from the >> original doc, since >> >>>>> everyone >> >>>>> seemed to be in agreement. I think the map is just >> a safeguard in case >> >>>>> of >> >>>>> additional boot options available in some >> implementations (e.g. I think >> >>>>> OWB/OpenEJB have some options.. currently OpenEJB >> supports an embedded >> >>>>> CDI >> >>>>> boot mode). >> >>>>> >> >>>>> No, I am fine with the map. What I am questioning >> is the type of the >> >>>>> map. >> >>>>> Usually, data structures with a similar purpose use >> Strings as their >> >>>>> keys. >> >>>>> This applies to ServletContext attributes, >> InvocationContext data, >> >>>>> Servlet >> >>>>> request/session attributes and others. I am >> therefore wondering whether >> >>>>> there is a usecase for the proposed unbound key >> signature or not. >> >>>> >> >>>> >> >>>> I think that's more of a placeholder, I was assuming >> it would be >> >>>> Map once we clarify everything. >> >>>> >> >>>>> >> >>>>> >> >>>>> We spoke a few times about BeanManager vs CDI. >> BeanManager was >> >>>>> preferable >> >>>>> since there's no easy way to get the the instance, >> CDI is easier to get >> >>>>> and >> >>>>> more aligned with how you would get it. Usually >> people expect the >> >>>>> BeanManager to be injected or available via JNDI, >> neither would be the >> >>>>> case >> >>>>> here. >> >>>>> >> >>>>> If CDI 2.0 targets Java SE then this container >> initialization API will >> >>>>> become something that ordinary application >> developers use to start/stop >> >>>>> CDI >> >>>>> in their applications. It therefore cannot be >> considered an SPI but >> >>>>> instead >> >>>>> should be something easy to use. On the other hand, >> BeanManager is >> >>>>> definitely an SPI. It is used in extension, >> frameworks and generally >> >>>>> for >> >>>>> integration. Not much by applications directly. >> Therefore, I don't see >> >>>>> how >> >>>>> the container bootstrap API and BeanManager fit >> together. IMO the >> >>>>> bootstrap >> >>>>> API should expose something that makes common tasks >> (obtaining a >> >>>>> contextual >> >>>>> reference and firing and event) easy, which the CDI >> class does. >> >>>>> >> >>>>> Plus do not forget that BeanManager can be obtained >> easily using >> >>>>> CDI.getBeanManager(). >> >>>> >> >>>> >> >>>> I'm not disagreeing. There's a few things I'd consider: >> >>>> >> >>>> - Is this mostly for new apps or existing? If >> existing, it's probably >> >>>> using >> >>>> some internal API, if new it can use whatever API we >> give. >> >>>> - I don't want to return void, we should give some >> kind of reference >> >>>> into >> >>>> the container when we're done booting. >> >>>> >> >>>> Agreed, we should not be returning void. >> >>>> >> >>>> - CDI is a one step retrievable reference, where as >> BeanManager is a two >> >>>> step reference. With that said, BeanManager makes >> more sense to return >> >>>> here. Another thought could be we invent some new >> class that has both, >> >>>> but >> >>>> that's really redundant. >> >>>> >> >>>> Why do you think BeanManager makes more sense here? >> Especially given the >> >>>> assumption that application code is going to call >> this init/shutdown >> >>>> API, I >> >>>> don't see BeanManager as making more sense. >> >>>> >> >>>> >> >>>>> >> >>>>> >> >>>>> Yes, this is the container start API. Sounds like >> you have some good >> >>>>> ideas for things like XML configuration or >> programmatic configuration, >> >>>>> both >> >>>>> of which are being tracked under separate tickets. >> One idea might be >> >>>>> for an >> >>>>> optional param in the map to control packages to >> scan/ignore, in that >> >>>>> map. >> >>>>> >> >>>>> I am wondering whether this configuration should be >> something optional >> >>>>> built on top of the bootstrap API or whether we >> should consider making >> >>>>> it >> >>>>> mandatory. Either way, we cannot add the bootstrap >> API to the spec >> >>>>> without >> >>>>> explicitly defining how it behaves. My implicit >> assumption of the >> >>>>> proposal >> >>>>> is that the container is supposed to scan the >> entire classpath for >> >>>>> explicit >> >>>>> or implicit bean archives (including e.g. rt.jar), >> discover beans, fire >> >>>>> extensions, etc. This worries me as this default >> behavior is far from >> >>>>> being >> >>>>> lightweight, which CDI for Java SE initially aimed >> to be. >> >>>> >> >>>> >> >>>> Yes, the spec must be updated to reflect the >> behavior of SE mode. I >> >>>> plan to >> >>>> get that completely into the google doc before >> opening any spec changes >> >>>> in a >> >>>> PR. >> >>>> >> >>>>> >> >>>>> >> >>>>> We didn't want to over load the CDI interface. It >> already does a lot. >> >>>>> This is really SPI code, CDI even though it's in >> the spi package is >> >>>>> used in >> >>>>> a lot of application code. >> >>>>> >> >>>>> I would personally prefer to have it all in one >> place. Having >> >>>>> CDIContainer, CDIContainerLoader, CDI and >> CDIProvider makes it more >> >>>>> difficult to know when to use what. >> >>>> >> >>>> >> >>>> The problem is that most CDI (the interface) >> operations are against a >> >>>> running container. I think we spoke about >> leveraging CDIProvider at one >> >>>> point (in fact, I mistakenly called CDIContainer >> CDIProvider not even >> >>>> realizing it was there). I doubt that most app >> developers use it >> >>>> currently, >> >>>> there's not even a way to get a reference to it that >> I'm aware of. It's >> >>>> used by the implementor only. >> >>>> >> >>>> I don't think there's a conflict. CDI class would >> still only provide >> >>>> methods >> >>>> to be run against a running container. The >> difference is that there >> >>>> would be >> >>>> additional static methods to get this running >> container (CDI class) to >> >>>> you >> >>>> by starting the container. >> >>>> >> >>>> Either way, I agree that reusing CDIProvider is a >> must. There is no >> >>>> reason >> >>>> to define a new class for the same purpose. >> >>>> >> >>>> >> >>>> I expect that my changes in the CDI spec around this >> will state, along >> >>>> the >> >>>> lines of: >> >>>> >> >>>> To retrieve a CDIContainer to launch, do this: >> >>>> >> >>>> CDIContainer container = >> CDIContainerLocator.getCDIContainer(); >> >>>> container.initialize(); >> >>>> ... do work >> >>>> >> >>>> Once you want to shutdown the container, do this: >> >>>> >> >>>> container.shutdown(); >> >>>> >> >>>> (we may want to consider implementing AutoCloseable, >> an oversight on my >> >>>> part) >> >>>> >> >>>> and then later on >> >>>> >> >>>> - What happens if I call CDIContainerLocator in an >> app server >> >>>> >> >>>> - It throws an IllegalStateException. >> >>>> >> >>>> - The container provides no beans of type >> CDIContainer, it is managed >> >>>> outside of the CDI container. >> >>>> >> >>>> >> >>>>> >> >>>>> >> >>>>> John >> >>>>> >> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger >> > >> >>>>> wrote: >> >>>>>> >> >>>>>> Hi John, some thoughts: >> >>>>>> >> >>>>>> - instead of using BeanManager it makes more sense >> to me to return a >> >>>>>> CDI >> >>>>>> instance, which is a more user-friendly API (and >> it also exposes >> >>>>>> access to >> >>>>>> BeanManager) >> >>>>>> - is there a usecase for arbitrary keys of the >> "params" map or is >> >>>>>> Map sufficient? >> >>>>>> - if we could move the shutdown() method from >> CDIContainer to the >> >>>>>> actual >> >>>>>> container handle that we obtain from initialize(), >> that would look >> >>>>>> more >> >>>>>> object-oriented >> >>>>>> - what exactly is initialize() supposed to do? Is >> it supposed to start >> >>>>>> scanning the entire classpath for CDI beans? That >> could be a problem >> >>>>>> especially with spring-boot-like fat jars. I think >> we need an API to >> >>>>>> tell >> >>>>>> the container which classes / packages to >> consider. Something like >> >>>>>> Guice's >> >>>>>> binding API perhaps? >> >>>>>> >> >>>>>> - the proposal makes me wonder whether >> retrofitting this functionality >> >>>>>> to >> >>>>>> the CDI class wouldn't be a better option. It >> could look like: >> >>>>>> >> >>>>>> CDI container = CDI.initialize(); >> >>>>>> container.select(Foo.class).get(); >> >>>>>> container.shutdown(); >> >>>>>> >> >>>>>> compare it to: >> >>>>>> >> >>>>>> CDIContainer container = CDIContainerLoader. >> getCDIContainer(); >> >>>>>> BeanManager manager = container.initialize(); >> >>>>>> manager.getBeans(...); >> >>>>>> container.shutdown(manager); >> >>>>>> >> >>>>>> >> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >> >>>>>> >> >>>>>> All, >> >>>>>> >> >>>>>> I have the updated API here, and wanted to solicit >> any final feedback >> >>>>>> before updating the google doc and spec pages. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c >> >>>>>> >> >>>>>> Let me know your thoughts. >> >>>>>> >> >>>>>> Thanks, >> >>>>>> >> >>>>>> John >> >>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> cdi-dev mailing list >> >>>>>> cdi-dev at lists.jboss.org >> >> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >>>>>> >> >>>>>> Note that for all code provided on this list, the >> provider licenses >> >>>>>> the >> >>>>>> code under the Apache License, Version 2 >> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). >> For all other ideas >> >>>>>> provided on this list, the provider waives all >> patent and other >> >>>>>> intellectual >> >>>>>> property rights inherent in such information. >> >>>>>> >> >>>>>> >> >>>> >> >>>> _______________________________________________ >> >>>> cdi-dev mailing list >> >>>> cdi-dev at lists.jboss.org >> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >>>> >> >>>> Note that for all code provided on this list, the >> provider licenses the >> >>>> code >> >>>> under the Apache License, Version 2 >> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). >> For all other ideas >> >>>> provided on this list, the provider waives all >> patent and other >> >>>> intellectual >> >>>> property rights inherent in such information. >> >> >> >> >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/4d8e300f/attachment-0001.html From rmannibucau at gmail.com Wed Mar 4 04:36:53 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 4 Mar 2015 10:36:53 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: <54F6D179.2070109@redhat.com> References: <54DB1F2B.1020609@redhat.com> <54DC61D9.701@redhat.com> <54EECC20.6040600@redhat.com> <54EF396E.20805@redhat.com> <54F01720.3080802@redhat.com> <54F6D179.2070109@redhat.com> Message-ID: Hmm CDI supposes the container is running so a container being a CDI is weird IMO - even if I get the big shortcut you want to introduce which makes sense? +1 to hide CDIContainerLoader Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-03-04 10:33 GMT+01:00 Jozef Hartinger : > I am wondering if we need to expose both CDIContainer and > CDIContainerLoader to the user. Could we instead follow what CDI does where > CDI is the only class exposed and CDIProvider is a not-exposed SPI? Also, > given that CDIProvider is kind of an SPI what about reusing it as a > provider of CDIContainer also? > > Another though: What about changing the signature to something like: > > public class CDIContainer extends CDI implements AutoCloseable > > Jozef > > > On 03/01/2015 03:13 PM, John D. Ament wrote: > > So, I think I've gathered enough feedback at this point, and seen some of > the API changes. I'll hopefully be including some doc changes this week, > but one question - do we want to start the SE specific stuff as its own > asciidoc file? > > Changes made: > > - Changed return value to CDI to provide better capability out > of the box. > - Added AutoCloseable to CDIContainer, provided default implementation of > calling shutdown. > - Added synchronization support to the method body that retrieves the > singleton instance (BTW, I'm not sure if this is even useful TBH as each > impl, including the RI, needs to provide this class in its own format). > - Made the params map typed to > > @Romain Your case isn't really supportable yet, until we have static > injection support. You'd still have to have a managed version of Runner to > work against. > > John > > On Sat, Feb 28, 2015 at 4:11 PM Romain Manni-Bucau > wrote: > >> Yes but not the way to get an instance. Even Unmanaged does it. >> >> What can be awesome is to have static inject for it: >> >> public class Runner { >> >> @Inject >> private static MyMain main; >> >> public static void main(String[] arg) { >> try (CDIContainer c = CDIContainer.newContainer()) { >> main.doWork(); >> } >> } >> >> } >> >> And not a single additional line :). >> Le 28 f?vr. 2015 19:05, "John D. Ament" a >> ?crit : >> >> Maybe I'm misreading, but I don't see us adding another API to do the >>> same thing here - we're introducing new functionality. >>> >>> CDIContainer/Loader on startup/shutdown of the application >>> >>> CDI for runtime usage within the application to interact with the >>> container. >>> >>> John >>> >>> On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau < >>> rmannibucau at gmail.com> wrote: >>> >>>> sure I fully agree excepted I think introducing yet another API to do >>>> the same thing is not good so super tempting to skip it and wait for >>>> feedbacks rather than introducing it eagerly. >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau >>>> http://www.tomitribe.com >>>> http://rmannibucau.wordpress.com >>>> https://github.com/rmannibucau >>>> >>>> >>>> 2015-02-27 8:05 GMT+01:00 Jozef Hartinger : >>>> > My point is that from the application perspective, the user obtains >>>> one >>>> > container handle for eventual shutdown (CDIContainer) and then looks >>>> up a >>>> > different container handle (CDI) that they can use for real work >>>> (lookup / >>>> > event dispatch / etc.) It would be cleaner if the container gave away >>>> a >>>> > single handle that can do all of that. >>>> > >>>> > >>>> > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: >>>> > >>>> > Not sure I get how a CDI instance can help. >>>> > >>>> > But container.getBeanManager() sounds nice is not a shortcut for >>>> > CDI.current().getBm() otherwise it looks like duplication to me. >>>> > >>>> > Can we make container not contextual - dont think so? If so it makes >>>> sense >>>> > otherwise I fear it doesnt add much. >>>> > >>>> > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" a >>>> ?crit : >>>> >> >>>> >> I like the initialize + close() combination and the >>>> try-with-resources >>>> >> usage. >>>> >> What looks weird to me is that at line one you obtain a container >>>> handle: >>>> >> >>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>> >> CDI.current().getBeanManager() ... >>>> >> >>>> >> and then at line two you call a static method to perform a container >>>> >> lookup :-/ >>>> >> >>>> >> An API that allows you to use the container handle you already got >>>> is way >>>> >> better IMO, e.g.: >>>> >> >>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>> >> container.getBeanManager() >>>> >> >>>> >> If CDIContainer.newCDIContainer() returns an CDI instance or its >>>> subclass, >>>> >> we get this easily. >>>> >> >>>> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: >>>> >>> >>>> >>> Hi guys >>>> >>> >>>> >>> why note keeping it simple? >>>> >>> >>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer(/* >>>> optional >>>> >>> map to configure vendor features */)) { >>>> >>> CDI.current().getBeanManager().... >>>> >>> } >>>> >>> >>>> >>> Not sure the point having initialize() + having shutdown = close >>>> >>> really makes the API more fluent and modern IMO. >>>> >>> >>>> >>> Also to be fully SE I guess provider() method would be needed even >>>> if >>>> >>> optional (SPI usage by default): >>>> >>> >>>> >>> try (CDIContainer container = >>>> >>> >>>> >>> >>>> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider").newCDIContainer()) >>>> >>> { >>>> >>> CDI.current().getBeanManager().... >>>> >>> } >>>> >>> >>>> >>> Finally I think having a kind of getInstance shortcut could be a >>>> plus for >>>> >>> SE: >>>> >>> >>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer()) { >>>> >>> container.newInstance(MyAppRunner.class /* optional >>>> qualifiers */ >>>> >>> ).run(args); >>>> >>> } >>>> >>> >>>> >>> Using container to get an instance would create the instance and >>>> bind >>>> >>> it to the container lifecycle (mainly for predestroy) avoiding this >>>> >>> boilerplate code in all main which will surely only be used to >>>> launch >>>> >>> a soft. >>>> >>> >>>> >>> wdyt? >>>> >>> >>>> >>> >>>> >>> >>>> >>> Romain Manni-Bucau >>>> >>> @rmannibucau >>>> >>> http://www.tomitribe.com >>>> >>> http://rmannibucau.wordpress.com >>>> >>> https://github.com/rmannibucau >>>> >>> >>>> >>> >>>> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger : >>>> >>>> >>>> >>>> Comments inline >>>> >>>> >>>> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: >>>> >>>> >>>> >>>> Sorry Jozef, your email fell into the pits of google inbox's "smart >>>> >>>> sorting" >>>> >>>> features. >>>> >>>> >>>> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger < >>>> jharting at redhat.com> >>>> >>>> wrote: >>>> >>>>> >>>> >>>>> Hi John, comments inline: >>>> >>>>> >>>> >>>>> >>>> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >>>> >>>>> >>>> >>>>> Jozef, >>>> >>>>> >>>> >>>>> Most of what you see there is taken from the original doc, since >>>> >>>>> everyone >>>> >>>>> seemed to be in agreement. I think the map is just a safeguard >>>> in case >>>> >>>>> of >>>> >>>>> additional boot options available in some implementations (e.g. I >>>> think >>>> >>>>> OWB/OpenEJB have some options.. currently OpenEJB supports an >>>> embedded >>>> >>>>> CDI >>>> >>>>> boot mode). >>>> >>>>> >>>> >>>>> No, I am fine with the map. What I am questioning is the type of >>>> the >>>> >>>>> map. >>>> >>>>> Usually, data structures with a similar purpose use Strings as >>>> their >>>> >>>>> keys. >>>> >>>>> This applies to ServletContext attributes, InvocationContext data, >>>> >>>>> Servlet >>>> >>>>> request/session attributes and others. I am therefore wondering >>>> whether >>>> >>>>> there is a usecase for the proposed unbound key signature or not. >>>> >>>> >>>> >>>> >>>> >>>> I think that's more of a placeholder, I was assuming it would be >>>> >>>> Map once we clarify everything. >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> We spoke a few times about BeanManager vs CDI. BeanManager was >>>> >>>>> preferable >>>> >>>>> since there's no easy way to get the the instance, CDI is easier >>>> to get >>>> >>>>> and >>>> >>>>> more aligned with how you would get it. Usually people expect the >>>> >>>>> BeanManager to be injected or available via JNDI, neither would >>>> be the >>>> >>>>> case >>>> >>>>> here. >>>> >>>>> >>>> >>>>> If CDI 2.0 targets Java SE then this container initialization API >>>> will >>>> >>>>> become something that ordinary application developers use to >>>> start/stop >>>> >>>>> CDI >>>> >>>>> in their applications. It therefore cannot be considered an SPI >>>> but >>>> >>>>> instead >>>> >>>>> should be something easy to use. On the other hand, BeanManager is >>>> >>>>> definitely an SPI. It is used in extension, frameworks and >>>> generally >>>> >>>>> for >>>> >>>>> integration. Not much by applications directly. Therefore, I >>>> don't see >>>> >>>>> how >>>> >>>>> the container bootstrap API and BeanManager fit together. IMO the >>>> >>>>> bootstrap >>>> >>>>> API should expose something that makes common tasks (obtaining a >>>> >>>>> contextual >>>> >>>>> reference and firing and event) easy, which the CDI class does. >>>> >>>>> >>>> >>>>> Plus do not forget that BeanManager can be obtained easily using >>>> >>>>> CDI.getBeanManager(). >>>> >>>> >>>> >>>> >>>> >>>> I'm not disagreeing. There's a few things I'd consider: >>>> >>>> >>>> >>>> - Is this mostly for new apps or existing? If existing, it's >>>> probably >>>> >>>> using >>>> >>>> some internal API, if new it can use whatever API we give. >>>> >>>> - I don't want to return void, we should give some kind of >>>> reference >>>> >>>> into >>>> >>>> the container when we're done booting. >>>> >>>> >>>> >>>> Agreed, we should not be returning void. >>>> >>>> >>>> >>>> - CDI is a one step retrievable reference, where as BeanManager is >>>> a two >>>> >>>> step reference. With that said, BeanManager makes more sense to >>>> return >>>> >>>> here. Another thought could be we invent some new class that has >>>> both, >>>> >>>> but >>>> >>>> that's really redundant. >>>> >>>> >>>> >>>> Why do you think BeanManager makes more sense here? Especially >>>> given the >>>> >>>> assumption that application code is going to call this >>>> init/shutdown >>>> >>>> API, I >>>> >>>> don't see BeanManager as making more sense. >>>> >>>> >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> Yes, this is the container start API. Sounds like you have some >>>> good >>>> >>>>> ideas for things like XML configuration or programmatic >>>> configuration, >>>> >>>>> both >>>> >>>>> of which are being tracked under separate tickets. One idea >>>> might be >>>> >>>>> for an >>>> >>>>> optional param in the map to control packages to scan/ignore, in >>>> that >>>> >>>>> map. >>>> >>>>> >>>> >>>>> I am wondering whether this configuration should be something >>>> optional >>>> >>>>> built on top of the bootstrap API or whether we should consider >>>> making >>>> >>>>> it >>>> >>>>> mandatory. Either way, we cannot add the bootstrap API to the spec >>>> >>>>> without >>>> >>>>> explicitly defining how it behaves. My implicit assumption of the >>>> >>>>> proposal >>>> >>>>> is that the container is supposed to scan the entire classpath for >>>> >>>>> explicit >>>> >>>>> or implicit bean archives (including e.g. rt.jar), discover >>>> beans, fire >>>> >>>>> extensions, etc. This worries me as this default behavior is far >>>> from >>>> >>>>> being >>>> >>>>> lightweight, which CDI for Java SE initially aimed to be. >>>> >>>> >>>> >>>> >>>> >>>> Yes, the spec must be updated to reflect the behavior of SE mode. >>>> I >>>> >>>> plan to >>>> >>>> get that completely into the google doc before opening any spec >>>> changes >>>> >>>> in a >>>> >>>> PR. >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> We didn't want to over load the CDI interface. It already does a >>>> lot. >>>> >>>>> This is really SPI code, CDI even though it's in the spi package >>>> is >>>> >>>>> used in >>>> >>>>> a lot of application code. >>>> >>>>> >>>> >>>>> I would personally prefer to have it all in one place. Having >>>> >>>>> CDIContainer, CDIContainerLoader, CDI and CDIProvider makes it >>>> more >>>> >>>>> difficult to know when to use what. >>>> >>>> >>>> >>>> >>>> >>>> The problem is that most CDI (the interface) operations are >>>> against a >>>> >>>> running container. I think we spoke about leveraging CDIProvider >>>> at one >>>> >>>> point (in fact, I mistakenly called CDIContainer CDIProvider not >>>> even >>>> >>>> realizing it was there). I doubt that most app developers use it >>>> >>>> currently, >>>> >>>> there's not even a way to get a reference to it that I'm aware >>>> of. It's >>>> >>>> used by the implementor only. >>>> >>>> >>>> >>>> I don't think there's a conflict. CDI class would still only >>>> provide >>>> >>>> methods >>>> >>>> to be run against a running container. The difference is that there >>>> >>>> would be >>>> >>>> additional static methods to get this running container (CDI >>>> class) to >>>> >>>> you >>>> >>>> by starting the container. >>>> >>>> >>>> >>>> Either way, I agree that reusing CDIProvider is a must. There is no >>>> >>>> reason >>>> >>>> to define a new class for the same purpose. >>>> >>>> >>>> >>>> >>>> >>>> I expect that my changes in the CDI spec around this will state, >>>> along >>>> >>>> the >>>> >>>> lines of: >>>> >>>> >>>> >>>> To retrieve a CDIContainer to launch, do this: >>>> >>>> >>>> >>>> CDIContainer container = CDIContainerLocator.getCDIContainer(); >>>> >>>> container.initialize(); >>>> >>>> ... do work >>>> >>>> >>>> >>>> Once you want to shutdown the container, do this: >>>> >>>> >>>> >>>> container.shutdown(); >>>> >>>> >>>> >>>> (we may want to consider implementing AutoCloseable, an oversight >>>> on my >>>> >>>> part) >>>> >>>> >>>> >>>> and then later on >>>> >>>> >>>> >>>> - What happens if I call CDIContainerLocator in an app server >>>> >>>> >>>> >>>> - It throws an IllegalStateException. >>>> >>>> >>>> >>>> - The container provides no beans of type CDIContainer, it is >>>> managed >>>> >>>> outside of the CDI container. >>>> >>>> >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> John >>>> >>>>> >>>> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger < >>>> jharting at redhat.com> >>>> >>>>> wrote: >>>> >>>>>> >>>> >>>>>> Hi John, some thoughts: >>>> >>>>>> >>>> >>>>>> - instead of using BeanManager it makes more sense to me to >>>> return a >>>> >>>>>> CDI >>>> >>>>>> instance, which is a more user-friendly API (and it also exposes >>>> >>>>>> access to >>>> >>>>>> BeanManager) >>>> >>>>>> - is there a usecase for arbitrary keys of the "params" map or is >>>> >>>>>> Map sufficient? >>>> >>>>>> - if we could move the shutdown() method from CDIContainer to the >>>> >>>>>> actual >>>> >>>>>> container handle that we obtain from initialize(), that would >>>> look >>>> >>>>>> more >>>> >>>>>> object-oriented >>>> >>>>>> - what exactly is initialize() supposed to do? Is it supposed to >>>> start >>>> >>>>>> scanning the entire classpath for CDI beans? That could be a >>>> problem >>>> >>>>>> especially with spring-boot-like fat jars. I think we need an >>>> API to >>>> >>>>>> tell >>>> >>>>>> the container which classes / packages to consider. Something >>>> like >>>> >>>>>> Guice's >>>> >>>>>> binding API perhaps? >>>> >>>>>> >>>> >>>>>> - the proposal makes me wonder whether retrofitting this >>>> functionality >>>> >>>>>> to >>>> >>>>>> the CDI class wouldn't be a better option. It could look like: >>>> >>>>>> >>>> >>>>>> CDI container = CDI.initialize(); >>>> >>>>>> container.select(Foo.class).get(); >>>> >>>>>> container.shutdown(); >>>> >>>>>> >>>> >>>>>> compare it to: >>>> >>>>>> >>>> >>>>>> CDIContainer container = CDIContainerLoader. getCDIContainer(); >>>> >>>>>> BeanManager manager = container.initialize(); >>>> >>>>>> manager.getBeans(...); >>>> >>>>>> container.shutdown(manager); >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >>>> >>>>>> >>>> >>>>>> All, >>>> >>>>>> >>>> >>>>>> I have the updated API here, and wanted to solicit any final >>>> feedback >>>> >>>>>> before updating the google doc and spec pages. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c >>>> >>>>>> >>>> >>>>>> Let me know your thoughts. >>>> >>>>>> >>>> >>>>>> Thanks, >>>> >>>>>> >>>> >>>>>> John >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> _______________________________________________ >>>> >>>>>> cdi-dev mailing list >>>> >>>>>> cdi-dev at lists.jboss.org >>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>>>> >>>> >>>>>> Note that for all code provided on this list, the provider >>>> licenses >>>> >>>>>> the >>>> >>>>>> code under the Apache License, Version 2 >>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all >>>> other ideas >>>> >>>>>> provided on this list, the provider waives all patent and other >>>> >>>>>> intellectual >>>> >>>>>> property rights inherent in such information. >>>> >>>>>> >>>> >>>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> cdi-dev mailing list >>>> >>>> cdi-dev at lists.jboss.org >>>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> >>>> >>>> Note that for all code provided on this list, the provider >>>> licenses the >>>> >>>> code >>>> >>>> under the Apache License, Version 2 >>>> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>>> ideas >>>> >>>> provided on this list, the provider waives all patent and other >>>> >>>> intellectual >>>> >>>> property rights inherent in such information. >>>> >> >>>> >> >>>> > >>>> >>> > > _______________________________________________ > cdi-dev mailing listcdi-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/07dc9611/attachment-0001.html From rmannibucau at gmail.com Wed Mar 4 04:37:44 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 4 Mar 2015 10:37:44 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: References: <54DB1F2B.1020609@redhat.com> <54DC61D9.701@redhat.com> <54EECC20.6040600@redhat.com> <54EF396E.20805@redhat.com> <54F01720.3080802@redhat.com> <54F6D179.2070109@redhat.com> Message-ID: @Jozef: you are right, this observer can solve most of the issues, just need a sample in the spec IMO Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-03-04 10:36 GMT+01:00 Romain Manni-Bucau : > Hmm CDI supposes the container is running so a container being a CDI is > weird IMO - even if I get the big shortcut you want to introduce which > makes sense? > > +1 to hide CDIContainerLoader > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2015-03-04 10:33 GMT+01:00 Jozef Hartinger : > >> I am wondering if we need to expose both CDIContainer and >> CDIContainerLoader to the user. Could we instead follow what CDI does where >> CDI is the only class exposed and CDIProvider is a not-exposed SPI? Also, >> given that CDIProvider is kind of an SPI what about reusing it as a >> provider of CDIContainer also? >> >> Another though: What about changing the signature to something like: >> >> public class CDIContainer extends CDI implements AutoCloseable >> >> Jozef >> >> >> On 03/01/2015 03:13 PM, John D. Ament wrote: >> >> So, I think I've gathered enough feedback at this point, and seen some of >> the API changes. I'll hopefully be including some doc changes this week, >> but one question - do we want to start the SE specific stuff as its own >> asciidoc file? >> >> Changes made: >> >> - Changed return value to CDI to provide better capability out >> of the box. >> - Added AutoCloseable to CDIContainer, provided default implementation of >> calling shutdown. >> - Added synchronization support to the method body that retrieves the >> singleton instance (BTW, I'm not sure if this is even useful TBH as each >> impl, including the RI, needs to provide this class in its own format). >> - Made the params map typed to >> >> @Romain Your case isn't really supportable yet, until we have static >> injection support. You'd still have to have a managed version of Runner to >> work against. >> >> John >> >> On Sat, Feb 28, 2015 at 4:11 PM Romain Manni-Bucau >> wrote: >> >>> Yes but not the way to get an instance. Even Unmanaged does it. >>> >>> What can be awesome is to have static inject for it: >>> >>> public class Runner { >>> >>> @Inject >>> private static MyMain main; >>> >>> public static void main(String[] arg) { >>> try (CDIContainer c = CDIContainer.newContainer()) { >>> main.doWork(); >>> } >>> } >>> >>> } >>> >>> And not a single additional line :). >>> Le 28 f?vr. 2015 19:05, "John D. Ament" a >>> ?crit : >>> >>> Maybe I'm misreading, but I don't see us adding another API to do the >>>> same thing here - we're introducing new functionality. >>>> >>>> CDIContainer/Loader on startup/shutdown of the application >>>> >>>> CDI for runtime usage within the application to interact with the >>>> container. >>>> >>>> John >>>> >>>> On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau < >>>> rmannibucau at gmail.com> wrote: >>>> >>>>> sure I fully agree excepted I think introducing yet another API to do >>>>> the same thing is not good so super tempting to skip it and wait for >>>>> feedbacks rather than introducing it eagerly. >>>>> >>>>> >>>>> Romain Manni-Bucau >>>>> @rmannibucau >>>>> http://www.tomitribe.com >>>>> http://rmannibucau.wordpress.com >>>>> https://github.com/rmannibucau >>>>> >>>>> >>>>> 2015-02-27 8:05 GMT+01:00 Jozef Hartinger : >>>>> > My point is that from the application perspective, the user obtains >>>>> one >>>>> > container handle for eventual shutdown (CDIContainer) and then looks >>>>> up a >>>>> > different container handle (CDI) that they can use for real work >>>>> (lookup / >>>>> > event dispatch / etc.) It would be cleaner if the container gave >>>>> away a >>>>> > single handle that can do all of that. >>>>> > >>>>> > >>>>> > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: >>>>> > >>>>> > Not sure I get how a CDI instance can help. >>>>> > >>>>> > But container.getBeanManager() sounds nice is not a shortcut for >>>>> > CDI.current().getBm() otherwise it looks like duplication to me. >>>>> > >>>>> > Can we make container not contextual - dont think so? If so it makes >>>>> sense >>>>> > otherwise I fear it doesnt add much. >>>>> > >>>>> > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" a >>>>> ?crit : >>>>> >> >>>>> >> I like the initialize + close() combination and the >>>>> try-with-resources >>>>> >> usage. >>>>> >> What looks weird to me is that at line one you obtain a container >>>>> handle: >>>>> >> >>>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>>> >> CDI.current().getBeanManager() ... >>>>> >> >>>>> >> and then at line two you call a static method to perform a container >>>>> >> lookup :-/ >>>>> >> >>>>> >> An API that allows you to use the container handle you already got >>>>> is way >>>>> >> better IMO, e.g.: >>>>> >> >>>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>>> >> container.getBeanManager() >>>>> >> >>>>> >> If CDIContainer.newCDIContainer() returns an CDI instance or its >>>>> subclass, >>>>> >> we get this easily. >>>>> >> >>>>> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: >>>>> >>> >>>>> >>> Hi guys >>>>> >>> >>>>> >>> why note keeping it simple? >>>>> >>> >>>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer(/* >>>>> optional >>>>> >>> map to configure vendor features */)) { >>>>> >>> CDI.current().getBeanManager().... >>>>> >>> } >>>>> >>> >>>>> >>> Not sure the point having initialize() + having shutdown = close >>>>> >>> really makes the API more fluent and modern IMO. >>>>> >>> >>>>> >>> Also to be fully SE I guess provider() method would be needed even >>>>> if >>>>> >>> optional (SPI usage by default): >>>>> >>> >>>>> >>> try (CDIContainer container = >>>>> >>> >>>>> >>> >>>>> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider").newCDIContainer()) >>>>> >>> { >>>>> >>> CDI.current().getBeanManager().... >>>>> >>> } >>>>> >>> >>>>> >>> Finally I think having a kind of getInstance shortcut could be a >>>>> plus for >>>>> >>> SE: >>>>> >>> >>>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer()) { >>>>> >>> container.newInstance(MyAppRunner.class /* optional >>>>> qualifiers */ >>>>> >>> ).run(args); >>>>> >>> } >>>>> >>> >>>>> >>> Using container to get an instance would create the instance and >>>>> bind >>>>> >>> it to the container lifecycle (mainly for predestroy) avoiding this >>>>> >>> boilerplate code in all main which will surely only be used to >>>>> launch >>>>> >>> a soft. >>>>> >>> >>>>> >>> wdyt? >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> Romain Manni-Bucau >>>>> >>> @rmannibucau >>>>> >>> http://www.tomitribe.com >>>>> >>> http://rmannibucau.wordpress.com >>>>> >>> https://github.com/rmannibucau >>>>> >>> >>>>> >>> >>>>> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger : >>>>> >>>> >>>>> >>>> Comments inline >>>>> >>>> >>>>> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: >>>>> >>>> >>>>> >>>> Sorry Jozef, your email fell into the pits of google inbox's >>>>> "smart >>>>> >>>> sorting" >>>>> >>>> features. >>>>> >>>> >>>>> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger < >>>>> jharting at redhat.com> >>>>> >>>> wrote: >>>>> >>>>> >>>>> >>>>> Hi John, comments inline: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >>>>> >>>>> >>>>> >>>>> Jozef, >>>>> >>>>> >>>>> >>>>> Most of what you see there is taken from the original doc, since >>>>> >>>>> everyone >>>>> >>>>> seemed to be in agreement. I think the map is just a safeguard >>>>> in case >>>>> >>>>> of >>>>> >>>>> additional boot options available in some implementations (e.g. >>>>> I think >>>>> >>>>> OWB/OpenEJB have some options.. currently OpenEJB supports an >>>>> embedded >>>>> >>>>> CDI >>>>> >>>>> boot mode). >>>>> >>>>> >>>>> >>>>> No, I am fine with the map. What I am questioning is the type of >>>>> the >>>>> >>>>> map. >>>>> >>>>> Usually, data structures with a similar purpose use Strings as >>>>> their >>>>> >>>>> keys. >>>>> >>>>> This applies to ServletContext attributes, InvocationContext >>>>> data, >>>>> >>>>> Servlet >>>>> >>>>> request/session attributes and others. I am therefore wondering >>>>> whether >>>>> >>>>> there is a usecase for the proposed unbound key signature or not. >>>>> >>>> >>>>> >>>> >>>>> >>>> I think that's more of a placeholder, I was assuming it would be >>>>> >>>> Map once we clarify everything. >>>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> We spoke a few times about BeanManager vs CDI. BeanManager was >>>>> >>>>> preferable >>>>> >>>>> since there's no easy way to get the the instance, CDI is easier >>>>> to get >>>>> >>>>> and >>>>> >>>>> more aligned with how you would get it. Usually people expect >>>>> the >>>>> >>>>> BeanManager to be injected or available via JNDI, neither would >>>>> be the >>>>> >>>>> case >>>>> >>>>> here. >>>>> >>>>> >>>>> >>>>> If CDI 2.0 targets Java SE then this container initialization >>>>> API will >>>>> >>>>> become something that ordinary application developers use to >>>>> start/stop >>>>> >>>>> CDI >>>>> >>>>> in their applications. It therefore cannot be considered an SPI >>>>> but >>>>> >>>>> instead >>>>> >>>>> should be something easy to use. On the other hand, BeanManager >>>>> is >>>>> >>>>> definitely an SPI. It is used in extension, frameworks and >>>>> generally >>>>> >>>>> for >>>>> >>>>> integration. Not much by applications directly. Therefore, I >>>>> don't see >>>>> >>>>> how >>>>> >>>>> the container bootstrap API and BeanManager fit together. IMO the >>>>> >>>>> bootstrap >>>>> >>>>> API should expose something that makes common tasks (obtaining a >>>>> >>>>> contextual >>>>> >>>>> reference and firing and event) easy, which the CDI class does. >>>>> >>>>> >>>>> >>>>> Plus do not forget that BeanManager can be obtained easily using >>>>> >>>>> CDI.getBeanManager(). >>>>> >>>> >>>>> >>>> >>>>> >>>> I'm not disagreeing. There's a few things I'd consider: >>>>> >>>> >>>>> >>>> - Is this mostly for new apps or existing? If existing, it's >>>>> probably >>>>> >>>> using >>>>> >>>> some internal API, if new it can use whatever API we give. >>>>> >>>> - I don't want to return void, we should give some kind of >>>>> reference >>>>> >>>> into >>>>> >>>> the container when we're done booting. >>>>> >>>> >>>>> >>>> Agreed, we should not be returning void. >>>>> >>>> >>>>> >>>> - CDI is a one step retrievable reference, where as BeanManager >>>>> is a two >>>>> >>>> step reference. With that said, BeanManager makes more sense to >>>>> return >>>>> >>>> here. Another thought could be we invent some new class that has >>>>> both, >>>>> >>>> but >>>>> >>>> that's really redundant. >>>>> >>>> >>>>> >>>> Why do you think BeanManager makes more sense here? Especially >>>>> given the >>>>> >>>> assumption that application code is going to call this >>>>> init/shutdown >>>>> >>>> API, I >>>>> >>>> don't see BeanManager as making more sense. >>>>> >>>> >>>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Yes, this is the container start API. Sounds like you have some >>>>> good >>>>> >>>>> ideas for things like XML configuration or programmatic >>>>> configuration, >>>>> >>>>> both >>>>> >>>>> of which are being tracked under separate tickets. One idea >>>>> might be >>>>> >>>>> for an >>>>> >>>>> optional param in the map to control packages to scan/ignore, in >>>>> that >>>>> >>>>> map. >>>>> >>>>> >>>>> >>>>> I am wondering whether this configuration should be something >>>>> optional >>>>> >>>>> built on top of the bootstrap API or whether we should consider >>>>> making >>>>> >>>>> it >>>>> >>>>> mandatory. Either way, we cannot add the bootstrap API to the >>>>> spec >>>>> >>>>> without >>>>> >>>>> explicitly defining how it behaves. My implicit assumption of the >>>>> >>>>> proposal >>>>> >>>>> is that the container is supposed to scan the entire classpath >>>>> for >>>>> >>>>> explicit >>>>> >>>>> or implicit bean archives (including e.g. rt.jar), discover >>>>> beans, fire >>>>> >>>>> extensions, etc. This worries me as this default behavior is far >>>>> from >>>>> >>>>> being >>>>> >>>>> lightweight, which CDI for Java SE initially aimed to be. >>>>> >>>> >>>>> >>>> >>>>> >>>> Yes, the spec must be updated to reflect the behavior of SE >>>>> mode. I >>>>> >>>> plan to >>>>> >>>> get that completely into the google doc before opening any spec >>>>> changes >>>>> >>>> in a >>>>> >>>> PR. >>>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> We didn't want to over load the CDI interface. It already does >>>>> a lot. >>>>> >>>>> This is really SPI code, CDI even though it's in the spi package >>>>> is >>>>> >>>>> used in >>>>> >>>>> a lot of application code. >>>>> >>>>> >>>>> >>>>> I would personally prefer to have it all in one place. Having >>>>> >>>>> CDIContainer, CDIContainerLoader, CDI and CDIProvider makes it >>>>> more >>>>> >>>>> difficult to know when to use what. >>>>> >>>> >>>>> >>>> >>>>> >>>> The problem is that most CDI (the interface) operations are >>>>> against a >>>>> >>>> running container. I think we spoke about leveraging CDIProvider >>>>> at one >>>>> >>>> point (in fact, I mistakenly called CDIContainer CDIProvider not >>>>> even >>>>> >>>> realizing it was there). I doubt that most app developers use it >>>>> >>>> currently, >>>>> >>>> there's not even a way to get a reference to it that I'm aware >>>>> of. It's >>>>> >>>> used by the implementor only. >>>>> >>>> >>>>> >>>> I don't think there's a conflict. CDI class would still only >>>>> provide >>>>> >>>> methods >>>>> >>>> to be run against a running container. The difference is that >>>>> there >>>>> >>>> would be >>>>> >>>> additional static methods to get this running container (CDI >>>>> class) to >>>>> >>>> you >>>>> >>>> by starting the container. >>>>> >>>> >>>>> >>>> Either way, I agree that reusing CDIProvider is a must. There is >>>>> no >>>>> >>>> reason >>>>> >>>> to define a new class for the same purpose. >>>>> >>>> >>>>> >>>> >>>>> >>>> I expect that my changes in the CDI spec around this will state, >>>>> along >>>>> >>>> the >>>>> >>>> lines of: >>>>> >>>> >>>>> >>>> To retrieve a CDIContainer to launch, do this: >>>>> >>>> >>>>> >>>> CDIContainer container = CDIContainerLocator.getCDIContainer(); >>>>> >>>> container.initialize(); >>>>> >>>> ... do work >>>>> >>>> >>>>> >>>> Once you want to shutdown the container, do this: >>>>> >>>> >>>>> >>>> container.shutdown(); >>>>> >>>> >>>>> >>>> (we may want to consider implementing AutoCloseable, an oversight >>>>> on my >>>>> >>>> part) >>>>> >>>> >>>>> >>>> and then later on >>>>> >>>> >>>>> >>>> - What happens if I call CDIContainerLocator in an app server >>>>> >>>> >>>>> >>>> - It throws an IllegalStateException. >>>>> >>>> >>>>> >>>> - The container provides no beans of type CDIContainer, it is >>>>> managed >>>>> >>>> outside of the CDI container. >>>>> >>>> >>>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> John >>>>> >>>>> >>>>> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger < >>>>> jharting at redhat.com> >>>>> >>>>> wrote: >>>>> >>>>>> >>>>> >>>>>> Hi John, some thoughts: >>>>> >>>>>> >>>>> >>>>>> - instead of using BeanManager it makes more sense to me to >>>>> return a >>>>> >>>>>> CDI >>>>> >>>>>> instance, which is a more user-friendly API (and it also exposes >>>>> >>>>>> access to >>>>> >>>>>> BeanManager) >>>>> >>>>>> - is there a usecase for arbitrary keys of the "params" map or >>>>> is >>>>> >>>>>> Map sufficient? >>>>> >>>>>> - if we could move the shutdown() method from CDIContainer to >>>>> the >>>>> >>>>>> actual >>>>> >>>>>> container handle that we obtain from initialize(), that would >>>>> look >>>>> >>>>>> more >>>>> >>>>>> object-oriented >>>>> >>>>>> - what exactly is initialize() supposed to do? Is it supposed >>>>> to start >>>>> >>>>>> scanning the entire classpath for CDI beans? That could be a >>>>> problem >>>>> >>>>>> especially with spring-boot-like fat jars. I think we need an >>>>> API to >>>>> >>>>>> tell >>>>> >>>>>> the container which classes / packages to consider. Something >>>>> like >>>>> >>>>>> Guice's >>>>> >>>>>> binding API perhaps? >>>>> >>>>>> >>>>> >>>>>> - the proposal makes me wonder whether retrofitting this >>>>> functionality >>>>> >>>>>> to >>>>> >>>>>> the CDI class wouldn't be a better option. It could look like: >>>>> >>>>>> >>>>> >>>>>> CDI container = CDI.initialize(); >>>>> >>>>>> container.select(Foo.class).get(); >>>>> >>>>>> container.shutdown(); >>>>> >>>>>> >>>>> >>>>>> compare it to: >>>>> >>>>>> >>>>> >>>>>> CDIContainer container = CDIContainerLoader. getCDIContainer(); >>>>> >>>>>> BeanManager manager = container.initialize(); >>>>> >>>>>> manager.getBeans(...); >>>>> >>>>>> container.shutdown(manager); >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >>>>> >>>>>> >>>>> >>>>>> All, >>>>> >>>>>> >>>>> >>>>>> I have the updated API here, and wanted to solicit any final >>>>> feedback >>>>> >>>>>> before updating the google doc and spec pages. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c >>>>> >>>>>> >>>>> >>>>>> Let me know your thoughts. >>>>> >>>>>> >>>>> >>>>>> Thanks, >>>>> >>>>>> >>>>> >>>>>> John >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> _______________________________________________ >>>>> >>>>>> cdi-dev mailing list >>>>> >>>>>> cdi-dev at lists.jboss.org >>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>>> >>>>> >>>>>> Note that for all code provided on this list, the provider >>>>> licenses >>>>> >>>>>> the >>>>> >>>>>> code under the Apache License, Version 2 >>>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all >>>>> other ideas >>>>> >>>>>> provided on this list, the provider waives all patent and other >>>>> >>>>>> intellectual >>>>> >>>>>> property rights inherent in such information. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>> >>>>> >>>> _______________________________________________ >>>>> >>>> cdi-dev mailing list >>>>> >>>> cdi-dev at lists.jboss.org >>>>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>> >>>>> >>>> Note that for all code provided on this list, the provider >>>>> licenses the >>>>> >>>> code >>>>> >>>> under the Apache License, Version 2 >>>>> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>>>> ideas >>>>> >>>> provided on this list, the provider waives all patent and other >>>>> >>>> intellectual >>>>> >>>> property rights inherent in such information. >>>>> >> >>>>> >> >>>>> > >>>>> >>>> >> >> _______________________________________________ >> cdi-dev mailing listcdi-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/c1a158dc/attachment-0001.html From issues at jboss.org Wed Mar 4 04:44:49 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Wed, 4 Mar 2015 04:44:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-514) FireEventTest#testDuplicateBindingsToFireEventFails() is wrong In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046071#comment-13046071 ] Mark Struberg commented on CDI-514: ----------------------------------- well thats not true with Java8 anymore... Also testing this at runtime just doesn't help and just makes the container slower... > FireEventTest#testDuplicateBindingsToFireEventFails() is wrong > -------------------------------------------------------------- > > Key: CDI-514 > URL: https://issues.jboss.org/browse/CDI-514 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Mark Struberg > > testDuplicateBindingsToFireEventFails() tests for 2 Lifted literals with different values. But this is perfectly fine as value is NOT annotated as @Nonbinding. Thus the 2 literals are NOT equals according to CDI rules. They are essentially 2 different annotations... > Plz remove this test. It also makes no sense to add all those very performance costly tests at runtime. The worst case which can happen is that the 2 annotations make no sense. But they don't break anything. Wheras checking all the nasty conditions each and every time is really mad from a performance aspect. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From antoine at sabot-durand.net Wed Mar 4 04:49:17 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 4 Mar 2015 10:49:17 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: References: <54DB1F2B.1020609@redhat.com> <54DC61D9.701@redhat.com> <54EECC20.6040600@redhat.com> <54EF396E.20805@redhat.com> <54F01720.3080802@redhat.com> Message-ID: Hi John, I think it could be a good idea to write down all of these to have a more stable doc for discussion. You should update the google doc with the result of this discussion. I agree with the following points in this thread : - Minimize the number of new Class / Interface. CDI and CDIProvider usage is still not very clear for end user so we should add the strict minimum and try to enhance existing API / SPI when possible - Be able to bootstrap CDI without returning BeanManager (env if the API give possibility to access it if needed). End user don?t need that : CDI app can start with an observer for instance Something not dealt with but that we should keep in mind : - Providing a Java SE solution that could be easily used for a servlet bootstrap of CDI. I don?t know if we?ll standardize this but we definitely should keep this use case in mind and my bonus, it?s out of scope but I didn?t see anytime there that prevent this nice to have: - support the possibility to boot multiple BeanManager in Java SE. Antoine > Le 1 mars 2015 ? 15:13, John D. Ament a ?crit : > > So, I think I've gathered enough feedback at this point, and seen some of the API changes. I'll hopefully be including some doc changes this week, but one question - do we want to start the SE specific stuff as its own asciidoc file? > > Changes made: > > - Changed return value to CDI to provide better capability out of the box. > - Added AutoCloseable to CDIContainer, provided default implementation of calling shutdown. > - Added synchronization support to the method body that retrieves the singleton instance (BTW, I'm not sure if this is even useful TBH as each impl, including the RI, needs to provide this class in its own format). > - Made the params map typed to > > @Romain Your case isn't really supportable yet, until we have static injection support. You'd still have to have a managed version of Runner to work against. > > John > > On Sat, Feb 28, 2015 at 4:11 PM Romain Manni-Bucau > wrote: > Yes but not the way to get an instance. Even Unmanaged does it. > > What can be awesome is to have static inject for it: > > public class Runner { > > @Inject > private static MyMain main; > > public static void main(String[] arg) { > try (CDIContainer c = CDIContainer.newContainer()) { > main.doWork(); > } > } > > } > > And not a single additional line :). > Le 28 f?vr. 2015 19:05, "John D. Ament" > a ?crit : > > Maybe I'm misreading, but I don't see us adding another API to do the same thing here - we're introducing new functionality. > > CDIContainer/Loader on startup/shutdown of the application > > CDI for runtime usage within the application to interact with the container. > > John > > On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau > wrote: > sure I fully agree excepted I think introducing yet another API to do > the same thing is not good so super tempting to skip it and wait for > feedbacks rather than introducing it eagerly. > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-02-27 8:05 GMT+01:00 Jozef Hartinger >: > > My point is that from the application perspective, the user obtains one > > container handle for eventual shutdown (CDIContainer) and then looks up a > > different container handle (CDI) that they can use for real work (lookup / > > event dispatch / etc.) It would be cleaner if the container gave away a > > single handle that can do all of that. > > > > > > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: > > > > Not sure I get how a CDI instance can help. > > > > But container.getBeanManager() sounds nice is not a shortcut for > > CDI.current().getBm() otherwise it looks like duplication to me. > > > > Can we make container not contextual - dont think so? If so it makes sense > > otherwise I fear it doesnt add much. > > > > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" > a ?crit : > >> > >> I like the initialize + close() combination and the try-with-resources > >> usage. > >> What looks weird to me is that at line one you obtain a container handle: > >> > >> try (CDIContainer container = CDIContainer.newCDIContai... > >> CDI.current().getBeanManager() ... > >> > >> and then at line two you call a static method to perform a container > >> lookup :-/ > >> > >> An API that allows you to use the container handle you already got is way > >> better IMO, e.g.: > >> > >> try (CDIContainer container = CDIContainer.newCDIContai... > >> container.getBeanManager() > >> > >> If CDIContainer.newCDIContainer() returns an CDI instance or its subclass, > >> we get this easily. > >> > >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: > >>> > >>> Hi guys > >>> > >>> why note keeping it simple? > >>> > >>> try (CDIContainer container = CDIContainer.newCDIContainer(/* optional > >>> map to configure vendor features */)) { > >>> CDI.current().getBeanManager().... > >>> } > >>> > >>> Not sure the point having initialize() + having shutdown = close > >>> really makes the API more fluent and modern IMO. > >>> > >>> Also to be fully SE I guess provider() method would be needed even if > >>> optional (SPI usage by default): > >>> > >>> try (CDIContainer container = > >>> > >>> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider").newCDIContainer()) > >>> { > >>> CDI.current().getBeanManager().... > >>> } > >>> > >>> Finally I think having a kind of getInstance shortcut could be a plus for > >>> SE: > >>> > >>> try (CDIContainer container = CDIContainer.newCDIContainer()) { > >>> container.newInstance(MyAppRunner.class /* optional qualifiers */ > >>> ).run(args); > >>> } > >>> > >>> Using container to get an instance would create the instance and bind > >>> it to the container lifecycle (mainly for predestroy) avoiding this > >>> boilerplate code in all main which will surely only be used to launch > >>> a soft. > >>> > >>> wdyt? > >>> > >>> > >>> > >>> Romain Manni-Bucau > >>> @rmannibucau > >>> http://www.tomitribe.com > >>> http://rmannibucau.wordpress.com > >>> https://github.com/rmannibucau > >>> > >>> > >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger >: > >>>> > >>>> Comments inline > >>>> > >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: > >>>> > >>>> Sorry Jozef, your email fell into the pits of google inbox's "smart > >>>> sorting" > >>>> features. > >>>> > >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger > > >>>> wrote: > >>>>> > >>>>> Hi John, comments inline: > >>>>> > >>>>> > >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: > >>>>> > >>>>> Jozef, > >>>>> > >>>>> Most of what you see there is taken from the original doc, since > >>>>> everyone > >>>>> seemed to be in agreement. I think the map is just a safeguard in case > >>>>> of > >>>>> additional boot options available in some implementations (e.g. I think > >>>>> OWB/OpenEJB have some options.. currently OpenEJB supports an embedded > >>>>> CDI > >>>>> boot mode). > >>>>> > >>>>> No, I am fine with the map. What I am questioning is the type of the > >>>>> map. > >>>>> Usually, data structures with a similar purpose use Strings as their > >>>>> keys. > >>>>> This applies to ServletContext attributes, InvocationContext data, > >>>>> Servlet > >>>>> request/session attributes and others. I am therefore wondering whether > >>>>> there is a usecase for the proposed unbound key signature or not. > >>>> > >>>> > >>>> I think that's more of a placeholder, I was assuming it would be > >>>> Map once we clarify everything. > >>>> > >>>>> > >>>>> > >>>>> We spoke a few times about BeanManager vs CDI. BeanManager was > >>>>> preferable > >>>>> since there's no easy way to get the the instance, CDI is easier to get > >>>>> and > >>>>> more aligned with how you would get it. Usually people expect the > >>>>> BeanManager to be injected or available via JNDI, neither would be the > >>>>> case > >>>>> here. > >>>>> > >>>>> If CDI 2.0 targets Java SE then this container initialization API will > >>>>> become something that ordinary application developers use to start/stop > >>>>> CDI > >>>>> in their applications. It therefore cannot be considered an SPI but > >>>>> instead > >>>>> should be something easy to use. On the other hand, BeanManager is > >>>>> definitely an SPI. It is used in extension, frameworks and generally > >>>>> for > >>>>> integration. Not much by applications directly. Therefore, I don't see > >>>>> how > >>>>> the container bootstrap API and BeanManager fit together. IMO the > >>>>> bootstrap > >>>>> API should expose something that makes common tasks (obtaining a > >>>>> contextual > >>>>> reference and firing and event) easy, which the CDI class does. > >>>>> > >>>>> Plus do not forget that BeanManager can be obtained easily using > >>>>> CDI.getBeanManager(). > >>>> > >>>> > >>>> I'm not disagreeing. There's a few things I'd consider: > >>>> > >>>> - Is this mostly for new apps or existing? If existing, it's probably > >>>> using > >>>> some internal API, if new it can use whatever API we give. > >>>> - I don't want to return void, we should give some kind of reference > >>>> into > >>>> the container when we're done booting. > >>>> > >>>> Agreed, we should not be returning void. > >>>> > >>>> - CDI is a one step retrievable reference, where as BeanManager is a two > >>>> step reference. With that said, BeanManager makes more sense to return > >>>> here. Another thought could be we invent some new class that has both, > >>>> but > >>>> that's really redundant. > >>>> > >>>> Why do you think BeanManager makes more sense here? Especially given the > >>>> assumption that application code is going to call this init/shutdown > >>>> API, I > >>>> don't see BeanManager as making more sense. > >>>> > >>>> > >>>>> > >>>>> > >>>>> Yes, this is the container start API. Sounds like you have some good > >>>>> ideas for things like XML configuration or programmatic configuration, > >>>>> both > >>>>> of which are being tracked under separate tickets. One idea might be > >>>>> for an > >>>>> optional param in the map to control packages to scan/ignore, in that > >>>>> map. > >>>>> > >>>>> I am wondering whether this configuration should be something optional > >>>>> built on top of the bootstrap API or whether we should consider making > >>>>> it > >>>>> mandatory. Either way, we cannot add the bootstrap API to the spec > >>>>> without > >>>>> explicitly defining how it behaves. My implicit assumption of the > >>>>> proposal > >>>>> is that the container is supposed to scan the entire classpath for > >>>>> explicit > >>>>> or implicit bean archives (including e.g. rt.jar), discover beans, fire > >>>>> extensions, etc. This worries me as this default behavior is far from > >>>>> being > >>>>> lightweight, which CDI for Java SE initially aimed to be. > >>>> > >>>> > >>>> Yes, the spec must be updated to reflect the behavior of SE mode. I > >>>> plan to > >>>> get that completely into the google doc before opening any spec changes > >>>> in a > >>>> PR. > >>>> > >>>>> > >>>>> > >>>>> We didn't want to over load the CDI interface. It already does a lot. > >>>>> This is really SPI code, CDI even though it's in the spi package is > >>>>> used in > >>>>> a lot of application code. > >>>>> > >>>>> I would personally prefer to have it all in one place. Having > >>>>> CDIContainer, CDIContainerLoader, CDI and CDIProvider makes it more > >>>>> difficult to know when to use what. > >>>> > >>>> > >>>> The problem is that most CDI (the interface) operations are against a > >>>> running container. I think we spoke about leveraging CDIProvider at one > >>>> point (in fact, I mistakenly called CDIContainer CDIProvider not even > >>>> realizing it was there). I doubt that most app developers use it > >>>> currently, > >>>> there's not even a way to get a reference to it that I'm aware of. It's > >>>> used by the implementor only. > >>>> > >>>> I don't think there's a conflict. CDI class would still only provide > >>>> methods > >>>> to be run against a running container. The difference is that there > >>>> would be > >>>> additional static methods to get this running container (CDI class) to > >>>> you > >>>> by starting the container. > >>>> > >>>> Either way, I agree that reusing CDIProvider is a must. There is no > >>>> reason > >>>> to define a new class for the same purpose. > >>>> > >>>> > >>>> I expect that my changes in the CDI spec around this will state, along > >>>> the > >>>> lines of: > >>>> > >>>> To retrieve a CDIContainer to launch, do this: > >>>> > >>>> CDIContainer container = CDIContainerLocator.getCDIContainer(); > >>>> container.initialize(); > >>>> ... do work > >>>> > >>>> Once you want to shutdown the container, do this: > >>>> > >>>> container.shutdown(); > >>>> > >>>> (we may want to consider implementing AutoCloseable, an oversight on my > >>>> part) > >>>> > >>>> and then later on > >>>> > >>>> - What happens if I call CDIContainerLocator in an app server > >>>> > >>>> - It throws an IllegalStateException. > >>>> > >>>> - The container provides no beans of type CDIContainer, it is managed > >>>> outside of the CDI container. > >>>> > >>>> > >>>>> > >>>>> > >>>>> John > >>>>> > >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger > > >>>>> wrote: > >>>>>> > >>>>>> Hi John, some thoughts: > >>>>>> > >>>>>> - instead of using BeanManager it makes more sense to me to return a > >>>>>> CDI > >>>>>> instance, which is a more user-friendly API (and it also exposes > >>>>>> access to > >>>>>> BeanManager) > >>>>>> - is there a usecase for arbitrary keys of the "params" map or is > >>>>>> Map sufficient? > >>>>>> - if we could move the shutdown() method from CDIContainer to the > >>>>>> actual > >>>>>> container handle that we obtain from initialize(), that would look > >>>>>> more > >>>>>> object-oriented > >>>>>> - what exactly is initialize() supposed to do? Is it supposed to start > >>>>>> scanning the entire classpath for CDI beans? That could be a problem > >>>>>> especially with spring-boot-like fat jars. I think we need an API to > >>>>>> tell > >>>>>> the container which classes / packages to consider. Something like > >>>>>> Guice's > >>>>>> binding API perhaps? > >>>>>> > >>>>>> - the proposal makes me wonder whether retrofitting this functionality > >>>>>> to > >>>>>> the CDI class wouldn't be a better option. It could look like: > >>>>>> > >>>>>> CDI container = CDI.initialize(); > >>>>>> container.select(Foo.class).get(); > >>>>>> container.shutdown(); > >>>>>> > >>>>>> compare it to: > >>>>>> > >>>>>> CDIContainer container = CDIContainerLoader. getCDIContainer(); > >>>>>> BeanManager manager = container.initialize(); > >>>>>> manager.getBeans(...); > >>>>>> container.shutdown(manager); > >>>>>> > >>>>>> > >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: > >>>>>> > >>>>>> All, > >>>>>> > >>>>>> I have the updated API here, and wanted to solicit any final feedback > >>>>>> before updating the google doc and spec pages. > >>>>>> > >>>>>> > >>>>>> > >>>>>> https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c > >>>>>> > >>>>>> Let me know your thoughts. > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> John > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> cdi-dev mailing list > >>>>>> cdi-dev at lists.jboss.org > >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>>>> > >>>>>> Note that for all code provided on this list, the provider licenses > >>>>>> the > >>>>>> code under the Apache License, Version 2 > >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas > >>>>>> provided on this list, the provider waives all patent and other > >>>>>> intellectual > >>>>>> property rights inherent in such information. > >>>>>> > >>>>>> > >>>> > >>>> _______________________________________________ > >>>> cdi-dev mailing list > >>>> cdi-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>> > >>>> Note that for all code provided on this list, the provider licenses the > >>>> code > >>>> under the Apache License, Version 2 > >>>> (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas > >>>> provided on this list, the provider waives all patent and other > >>>> intellectual > >>>> property rights inherent in such information. > >> > >> > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/d90fb940/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/20150304/d90fb940/attachment-0001.bin From rmannibucau at gmail.com Wed Mar 4 04:52:26 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 4 Mar 2015 10:52:26 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: References: <54DB1F2B.1020609@redhat.com> <54DC61D9.701@redhat.com> <54EECC20.6040600@redhat.com> <54EF396E.20805@redhat.com> <54F01720.3080802@redhat.com> Message-ID: @Antoine: to boot multiple BM it would need to break contextuality of CDI, one way being to forbid any serialization (not a big constraint in SE). In this case container is bound to a bean manager which changes the API Jozef propose Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-03-04 10:49 GMT+01:00 Antoine Sabot-Durand : > Hi John, > > I think it could be a good idea to write down all of these to have a more > stable doc for discussion. You should update the google doc with the result > of this discussion. > > I agree with the following points in this thread : > > - Minimize the number of new Class / Interface. CDI and CDIProvider usage > is still not very clear for end user so we should add the strict minimum > and try to enhance existing API / SPI when possible > - Be able to bootstrap CDI without returning BeanManager (env if the API > give possibility to access it if needed). End user don?t need that : CDI > app can start with an observer for instance > > Something not dealt with but that we should keep in mind : > - Providing a Java SE solution that could be easily used for a servlet > bootstrap of CDI. I don?t know if we?ll standardize this but we definitely > should keep this use case in mind > > and my bonus, it?s out of scope but I didn?t see anytime there that > prevent this nice to have: > - support the possibility to boot multiple BeanManager in Java SE. > > Antoine > > > Le 1 mars 2015 ? 15:13, John D. Ament a ?crit : > > So, I think I've gathered enough feedback at this point, and seen some of > the API changes. I'll hopefully be including some doc changes this week, > but one question - do we want to start the SE specific stuff as its own > asciidoc file? > > Changes made: > > - Changed return value to CDI to provide better capability out of > the box. > - Added AutoCloseable to CDIContainer, provided default implementation of > calling shutdown. > - Added synchronization support to the method body that retrieves the > singleton instance (BTW, I'm not sure if this is even useful TBH as each > impl, including the RI, needs to provide this class in its own format). > - Made the params map typed to > > @Romain Your case isn't really supportable yet, until we have static > injection support. You'd still have to have a managed version of Runner to > work against. > > John > > On Sat, Feb 28, 2015 at 4:11 PM Romain Manni-Bucau > wrote: > >> Yes but not the way to get an instance. Even Unmanaged does it. >> >> What can be awesome is to have static inject for it: >> >> public class Runner { >> >> @Inject >> private static MyMain main; >> >> public static void main(String[] arg) { >> try (CDIContainer c = CDIContainer.newContainer()) { >> main.doWork(); >> } >> } >> >> } >> >> And not a single additional line :). >> Le 28 f?vr. 2015 19:05, "John D. Ament" a >> ?crit : >> >> Maybe I'm misreading, but I don't see us adding another API to do the >>> same thing here - we're introducing new functionality. >>> >>> CDIContainer/Loader on startup/shutdown of the application >>> >>> CDI for runtime usage within the application to interact with the >>> container. >>> >>> John >>> >>> On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau < >>> rmannibucau at gmail.com> wrote: >>> >>>> sure I fully agree excepted I think introducing yet another API to do >>>> the same thing is not good so super tempting to skip it and wait for >>>> feedbacks rather than introducing it eagerly. >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau >>>> http://www.tomitribe.com >>>> http://rmannibucau.wordpress.com >>>> https://github.com/rmannibucau >>>> >>>> >>>> 2015-02-27 8:05 GMT+01:00 Jozef Hartinger : >>>> > My point is that from the application perspective, the user obtains >>>> one >>>> > container handle for eventual shutdown (CDIContainer) and then looks >>>> up a >>>> > different container handle (CDI) that they can use for real work >>>> (lookup / >>>> > event dispatch / etc.) It would be cleaner if the container gave away >>>> a >>>> > single handle that can do all of that. >>>> > >>>> > >>>> > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: >>>> > >>>> > Not sure I get how a CDI instance can help. >>>> > >>>> > But container.getBeanManager() sounds nice is not a shortcut for >>>> > CDI.current().getBm() otherwise it looks like duplication to me. >>>> > >>>> > Can we make container not contextual - dont think so? If so it makes >>>> sense >>>> > otherwise I fear it doesnt add much. >>>> > >>>> > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" a >>>> ?crit : >>>> >> >>>> >> I like the initialize + close() combination and the >>>> try-with-resources >>>> >> usage. >>>> >> What looks weird to me is that at line one you obtain a container >>>> handle: >>>> >> >>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>> >> CDI.current().getBeanManager() ... >>>> >> >>>> >> and then at line two you call a static method to perform a container >>>> >> lookup :-/ >>>> >> >>>> >> An API that allows you to use the container handle you already got >>>> is way >>>> >> better IMO, e.g.: >>>> >> >>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>> >> container.getBeanManager() >>>> >> >>>> >> If CDIContainer.newCDIContainer() returns an CDI instance or its >>>> subclass, >>>> >> we get this easily. >>>> >> >>>> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: >>>> >>> >>>> >>> Hi guys >>>> >>> >>>> >>> why note keeping it simple? >>>> >>> >>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer(/* >>>> optional >>>> >>> map to configure vendor features */)) { >>>> >>> CDI.current().getBeanManager().... >>>> >>> } >>>> >>> >>>> >>> Not sure the point having initialize() + having shutdown = close >>>> >>> really makes the API more fluent and modern IMO. >>>> >>> >>>> >>> Also to be fully SE I guess provider() method would be needed even >>>> if >>>> >>> optional (SPI usage by default): >>>> >>> >>>> >>> try (CDIContainer container = >>>> >>> >>>> >>> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider"). >>>> newCDIContainer()) >>>> >>> { >>>> >>> CDI.current().getBeanManager().... >>>> >>> } >>>> >>> >>>> >>> Finally I think having a kind of getInstance shortcut could be a >>>> plus for >>>> >>> SE: >>>> >>> >>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer()) { >>>> >>> container.newInstance(MyAppRunner.class /* optional >>>> qualifiers */ >>>> >>> ).run(args); >>>> >>> } >>>> >>> >>>> >>> Using container to get an instance would create the instance and >>>> bind >>>> >>> it to the container lifecycle (mainly for predestroy) avoiding this >>>> >>> boilerplate code in all main which will surely only be used to >>>> launch >>>> >>> a soft. >>>> >>> >>>> >>> wdyt? >>>> >>> >>>> >>> >>>> >>> >>>> >>> Romain Manni-Bucau >>>> >>> @rmannibucau >>>> >>> http://www.tomitribe.com >>>> >>> http://rmannibucau.wordpress.com >>>> >>> https://github.com/rmannibucau >>>> >>> >>>> >>> >>>> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger : >>>> >>>> >>>> >>>> Comments inline >>>> >>>> >>>> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: >>>> >>>> >>>> >>>> Sorry Jozef, your email fell into the pits of google inbox's "smart >>>> >>>> sorting" >>>> >>>> features. >>>> >>>> >>>> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger < >>>> jharting at redhat.com> >>>> >>>> wrote: >>>> >>>>> >>>> >>>>> Hi John, comments inline: >>>> >>>>> >>>> >>>>> >>>> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >>>> >>>>> >>>> >>>>> Jozef, >>>> >>>>> >>>> >>>>> Most of what you see there is taken from the original doc, since >>>> >>>>> everyone >>>> >>>>> seemed to be in agreement. I think the map is just a safeguard >>>> in case >>>> >>>>> of >>>> >>>>> additional boot options available in some implementations (e.g. I >>>> think >>>> >>>>> OWB/OpenEJB have some options.. currently OpenEJB supports an >>>> embedded >>>> >>>>> CDI >>>> >>>>> boot mode). >>>> >>>>> >>>> >>>>> No, I am fine with the map. What I am questioning is the type of >>>> the >>>> >>>>> map. >>>> >>>>> Usually, data structures with a similar purpose use Strings as >>>> their >>>> >>>>> keys. >>>> >>>>> This applies to ServletContext attributes, InvocationContext data, >>>> >>>>> Servlet >>>> >>>>> request/session attributes and others. I am therefore wondering >>>> whether >>>> >>>>> there is a usecase for the proposed unbound key signature or not. >>>> >>>> >>>> >>>> >>>> >>>> I think that's more of a placeholder, I was assuming it would be >>>> >>>> Map once we clarify everything. >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> We spoke a few times about BeanManager vs CDI. BeanManager was >>>> >>>>> preferable >>>> >>>>> since there's no easy way to get the the instance, CDI is easier >>>> to get >>>> >>>>> and >>>> >>>>> more aligned with how you would get it. Usually people expect the >>>> >>>>> BeanManager to be injected or available via JNDI, neither would >>>> be the >>>> >>>>> case >>>> >>>>> here. >>>> >>>>> >>>> >>>>> If CDI 2.0 targets Java SE then this container initialization API >>>> will >>>> >>>>> become something that ordinary application developers use to >>>> start/stop >>>> >>>>> CDI >>>> >>>>> in their applications. It therefore cannot be considered an SPI >>>> but >>>> >>>>> instead >>>> >>>>> should be something easy to use. On the other hand, BeanManager is >>>> >>>>> definitely an SPI. It is used in extension, frameworks and >>>> generally >>>> >>>>> for >>>> >>>>> integration. Not much by applications directly. Therefore, I >>>> don't see >>>> >>>>> how >>>> >>>>> the container bootstrap API and BeanManager fit together. IMO the >>>> >>>>> bootstrap >>>> >>>>> API should expose something that makes common tasks (obtaining a >>>> >>>>> contextual >>>> >>>>> reference and firing and event) easy, which the CDI class does. >>>> >>>>> >>>> >>>>> Plus do not forget that BeanManager can be obtained easily using >>>> >>>>> CDI.getBeanManager(). >>>> >>>> >>>> >>>> >>>> >>>> I'm not disagreeing. There's a few things I'd consider: >>>> >>>> >>>> >>>> - Is this mostly for new apps or existing? If existing, it's >>>> probably >>>> >>>> using >>>> >>>> some internal API, if new it can use whatever API we give. >>>> >>>> - I don't want to return void, we should give some kind of >>>> reference >>>> >>>> into >>>> >>>> the container when we're done booting. >>>> >>>> >>>> >>>> Agreed, we should not be returning void. >>>> >>>> >>>> >>>> - CDI is a one step retrievable reference, where as BeanManager is >>>> a two >>>> >>>> step reference. With that said, BeanManager makes more sense to >>>> return >>>> >>>> here. Another thought could be we invent some new class that has >>>> both, >>>> >>>> but >>>> >>>> that's really redundant. >>>> >>>> >>>> >>>> Why do you think BeanManager makes more sense here? Especially >>>> given the >>>> >>>> assumption that application code is going to call this >>>> init/shutdown >>>> >>>> API, I >>>> >>>> don't see BeanManager as making more sense. >>>> >>>> >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> Yes, this is the container start API. Sounds like you have some >>>> good >>>> >>>>> ideas for things like XML configuration or programmatic >>>> configuration, >>>> >>>>> both >>>> >>>>> of which are being tracked under separate tickets. One idea >>>> might be >>>> >>>>> for an >>>> >>>>> optional param in the map to control packages to scan/ignore, in >>>> that >>>> >>>>> map. >>>> >>>>> >>>> >>>>> I am wondering whether this configuration should be something >>>> optional >>>> >>>>> built on top of the bootstrap API or whether we should consider >>>> making >>>> >>>>> it >>>> >>>>> mandatory. Either way, we cannot add the bootstrap API to the spec >>>> >>>>> without >>>> >>>>> explicitly defining how it behaves. My implicit assumption of the >>>> >>>>> proposal >>>> >>>>> is that the container is supposed to scan the entire classpath for >>>> >>>>> explicit >>>> >>>>> or implicit bean archives (including e.g. rt.jar), discover >>>> beans, fire >>>> >>>>> extensions, etc. This worries me as this default behavior is far >>>> from >>>> >>>>> being >>>> >>>>> lightweight, which CDI for Java SE initially aimed to be. >>>> >>>> >>>> >>>> >>>> >>>> Yes, the spec must be updated to reflect the behavior of SE mode. >>>> I >>>> >>>> plan to >>>> >>>> get that completely into the google doc before opening any spec >>>> changes >>>> >>>> in a >>>> >>>> PR. >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> We didn't want to over load the CDI interface. It already does a >>>> lot. >>>> >>>>> This is really SPI code, CDI even though it's in the spi package >>>> is >>>> >>>>> used in >>>> >>>>> a lot of application code. >>>> >>>>> >>>> >>>>> I would personally prefer to have it all in one place. Having >>>> >>>>> CDIContainer, CDIContainerLoader, CDI and CDIProvider makes it >>>> more >>>> >>>>> difficult to know when to use what. >>>> >>>> >>>> >>>> >>>> >>>> The problem is that most CDI (the interface) operations are >>>> against a >>>> >>>> running container. I think we spoke about leveraging CDIProvider >>>> at one >>>> >>>> point (in fact, I mistakenly called CDIContainer CDIProvider not >>>> even >>>> >>>> realizing it was there). I doubt that most app developers use it >>>> >>>> currently, >>>> >>>> there's not even a way to get a reference to it that I'm aware >>>> of. It's >>>> >>>> used by the implementor only. >>>> >>>> >>>> >>>> I don't think there's a conflict. CDI class would still only >>>> provide >>>> >>>> methods >>>> >>>> to be run against a running container. The difference is that there >>>> >>>> would be >>>> >>>> additional static methods to get this running container (CDI >>>> class) to >>>> >>>> you >>>> >>>> by starting the container. >>>> >>>> >>>> >>>> Either way, I agree that reusing CDIProvider is a must. There is no >>>> >>>> reason >>>> >>>> to define a new class for the same purpose. >>>> >>>> >>>> >>>> >>>> >>>> I expect that my changes in the CDI spec around this will state, >>>> along >>>> >>>> the >>>> >>>> lines of: >>>> >>>> >>>> >>>> To retrieve a CDIContainer to launch, do this: >>>> >>>> >>>> >>>> CDIContainer container = CDIContainerLocator.getCDIContainer(); >>>> >>>> container.initialize(); >>>> >>>> ... do work >>>> >>>> >>>> >>>> Once you want to shutdown the container, do this: >>>> >>>> >>>> >>>> container.shutdown(); >>>> >>>> >>>> >>>> (we may want to consider implementing AutoCloseable, an oversight >>>> on my >>>> >>>> part) >>>> >>>> >>>> >>>> and then later on >>>> >>>> >>>> >>>> - What happens if I call CDIContainerLocator in an app server >>>> >>>> >>>> >>>> - It throws an IllegalStateException. >>>> >>>> >>>> >>>> - The container provides no beans of type CDIContainer, it is >>>> managed >>>> >>>> outside of the CDI container. >>>> >>>> >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> John >>>> >>>>> >>>> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger < >>>> jharting at redhat.com> >>>> >>>>> wrote: >>>> >>>>>> >>>> >>>>>> Hi John, some thoughts: >>>> >>>>>> >>>> >>>>>> - instead of using BeanManager it makes more sense to me to >>>> return a >>>> >>>>>> CDI >>>> >>>>>> instance, which is a more user-friendly API (and it also exposes >>>> >>>>>> access to >>>> >>>>>> BeanManager) >>>> >>>>>> - is there a usecase for arbitrary keys of the "params" map or is >>>> >>>>>> Map sufficient? >>>> >>>>>> - if we could move the shutdown() method from CDIContainer to the >>>> >>>>>> actual >>>> >>>>>> container handle that we obtain from initialize(), that would >>>> look >>>> >>>>>> more >>>> >>>>>> object-oriented >>>> >>>>>> - what exactly is initialize() supposed to do? Is it supposed to >>>> start >>>> >>>>>> scanning the entire classpath for CDI beans? That could be a >>>> problem >>>> >>>>>> especially with spring-boot-like fat jars. I think we need an >>>> API to >>>> >>>>>> tell >>>> >>>>>> the container which classes / packages to consider. Something >>>> like >>>> >>>>>> Guice's >>>> >>>>>> binding API perhaps? >>>> >>>>>> >>>> >>>>>> - the proposal makes me wonder whether retrofitting this >>>> functionality >>>> >>>>>> to >>>> >>>>>> the CDI class wouldn't be a better option. It could look like: >>>> >>>>>> >>>> >>>>>> CDI container = CDI.initialize(); >>>> >>>>>> container.select(Foo.class).get(); >>>> >>>>>> container.shutdown(); >>>> >>>>>> >>>> >>>>>> compare it to: >>>> >>>>>> >>>> >>>>>> CDIContainer container = CDIContainerLoader. getCDIContainer(); >>>> >>>>>> BeanManager manager = container.initialize(); >>>> >>>>>> manager.getBeans(...); >>>> >>>>>> container.shutdown(manager); >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >>>> >>>>>> >>>> >>>>>> All, >>>> >>>>>> >>>> >>>>>> I have the updated API here, and wanted to solicit any final >>>> feedback >>>> >>>>>> before updating the google doc and spec pages. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> https://github.com/johnament/cdi/commit/ >>>> 2c362161e18dd521f8e83c27151ddad467a1c01c >>>> >>>>>> >>>> >>>>>> Let me know your thoughts. >>>> >>>>>> >>>> >>>>>> Thanks, >>>> >>>>>> >>>> >>>>>> John >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> _______________________________________________ >>>> >>>>>> cdi-dev mailing list >>>> >>>>>> cdi-dev at lists.jboss.org >>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>>>> >>>> >>>>>> Note that for all code provided on this list, the provider >>>> licenses >>>> >>>>>> the >>>> >>>>>> code under the Apache License, Version 2 >>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all >>>> other ideas >>>> >>>>>> provided on this list, the provider waives all patent and other >>>> >>>>>> intellectual >>>> >>>>>> property rights inherent in such information. >>>> >>>>>> >>>> >>>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> cdi-dev mailing list >>>> >>>> cdi-dev at lists.jboss.org >>>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> >>>> >>>> Note that for all code provided on this list, the provider >>>> licenses the >>>> >>>> code >>>> >>>> under the Apache License, Version 2 >>>> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>>> ideas >>>> >>>> provided on this list, the provider waives all patent and other >>>> >>>> intellectual >>>> >>>> property rights inherent in such information. >>>> >> >>>> >> >>>> > >>>> >>> _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/a77cf511/attachment-0001.html From issues at jboss.org Wed Mar 4 04:54:49 2015 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Wed, 4 Mar 2015 04:54:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-514) FireEventTest#testDuplicateBindingsToFireEventFails() is wrong In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046077#comment-13046077 ] Jozef Hartinger commented on CDI-514: ------------------------------------- Right, for CDI 2.0 this will need to be revisited. As for the performance impact I don't really buy this. How much time does it take to do a instanceof or class identity check? Especially given that method is usually called with 0, 1 or 2 qualifiers? We should prefer correctness over dubious performance optimizations. > FireEventTest#testDuplicateBindingsToFireEventFails() is wrong > -------------------------------------------------------------- > > Key: CDI-514 > URL: https://issues.jboss.org/browse/CDI-514 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Mark Struberg > > testDuplicateBindingsToFireEventFails() tests for 2 Lifted literals with different values. But this is perfectly fine as value is NOT annotated as @Nonbinding. Thus the 2 literals are NOT equals according to CDI rules. They are essentially 2 different annotations... > Plz remove this test. It also makes no sense to add all those very performance costly tests at runtime. The worst case which can happen is that the 2 annotations make no sense. But they don't break anything. Wheras checking all the nasty conditions each and every time is really mad from a performance aspect. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From antoine at sabot-durand.net Wed Mar 4 05:27:11 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 4 Mar 2015 11:27:11 +0100 Subject: [cdi-dev] Today's meeting agenda Message-ID: Hi all, I?d like to focus on Java SE support in today?s meeting. We had a lot of discussion around these api (thanks John, Jozef and Romain), now we can start going forward. John already worked on a doc here : https://github.com/johnament/cdi/blob/CDI-26-docs/spec/src/main/doc/cdi-se.asciidoc The points I see to discuss here are : - New API/SPI to introduce vs enhance exiting one (using CDIProvider vs CDIContainerLoader) - Exposition of BeanManager in the SE boot API vs CDI - Container shutdown Your other points are welcome. 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/20150304/62a7a88a/attachment.bin From jharting at redhat.com Wed Mar 4 05:34:31 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 04 Mar 2015 11:34:31 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: References: <54DB1F2B.1020609@redhat.com> <54DC61D9.701@redhat.com> <54EECC20.6040600@redhat.com> <54EF396E.20805@redhat.com> <54F01720.3080802@redhat.com> Message-ID: <54F6DFB7.80503@redhat.com> Let me fix the terminology here: "Multiple BeanManagers" is a misleading expression because it is not clear if we are talking about multiple BM within a single CDI container or separate containers. What Antoine had in mind (I think) is multiple CDI container instances. Therefore, let's use "multiple CDI container instances" hereafter in order not to get confused. This topic was discussed before. There are a few tricky parts that can be resolved more or less (e.g. CDI.current()). We may not necessarily need to specify this but we should make sure we do not anyhow prevent or make it unnecessarily difficult for CDI implementations to implement "multiple CDI container instances" running in parallel. On 03/04/2015 10:52 AM, Romain Manni-Bucau wrote: > @Antoine: to boot multiple BM it would need to break contextuality of > CDI, one way being to forbid any serialization (not a big constraint > in SE). In this case container is bound to a bean manager which > changes the API Jozef propose > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2015-03-04 10:49 GMT+01:00 Antoine Sabot-Durand > >: > > Hi John, > > I think it could be a good idea to write down all of these to have > a more stable doc for discussion. You should update the google doc > with the result of this discussion. > > I agree with the following points in this thread : > > - Minimize the number of new Class / Interface. CDI and > CDIProvider usage is still not very clear for end user so we > should add the strict minimum and try to enhance existing API / > SPI when possible > - Be able to bootstrap CDI without returning BeanManager (env if > the API give possibility to access it if needed). End user don?t > need that : CDI app can start with an observer for instance > > Something not dealt with but that we should keep in mind : > - Providing a Java SE solution that could be easily used for a > servlet bootstrap of CDI. I don?t know if we?ll standardize this > but we definitely should keep this use case in mind > > and my bonus, it?s out of scope but I didn?t see anytime there > that prevent this nice to have: > - support the possibility to boot multiple BeanManager in Java SE. > > Antoine > > >> Le 1 mars 2015 ? 15:13, John D. Ament > > a ?crit : >> >> So, I think I've gathered enough feedback at this point, and seen >> some of the API changes. I'll hopefully be including some doc >> changes this week, but one question - do we want to start the SE >> specific stuff as its own asciidoc file? >> >> Changes made: >> >> - Changed return value to CDI to provide better >> capability out of the box. >> - Added AutoCloseable to CDIContainer, provided default >> implementation of calling shutdown. >> - Added synchronization support to the method body that retrieves >> the singleton instance (BTW, I'm not sure if this is even useful >> TBH as each impl, including the RI, needs to provide this class >> in its own format). >> - Made the params map typed to >> >> @Romain Your case isn't really supportable yet, until we have >> static injection support. You'd still have to have a managed >> version of Runner to work against. >> >> John >> >> On Sat, Feb 28, 2015 at 4:11 PM Romain Manni-Bucau >> > wrote: >> >> Yes but not the way to get an instance. Even Unmanaged does it. >> >> What can be awesome is to have static inject for it: >> >> public class Runner { >> >> @Inject >> private static MyMain main; >> >> public static void main(String[] arg) { >> try (CDIContainer c = CDIContainer.newContainer()) { >> main.doWork(); >> } >> } >> >> } >> >> And not a single additional line :). >> >> Le 28 f?vr. 2015 19:05, "John D. Ament" >> > a >> ?crit : >> >> Maybe I'm misreading, but I don't see us adding another >> API to do the same thing here - we're introducing new >> functionality. >> >> CDIContainer/Loader on startup/shutdown of the application >> >> CDI for runtime usage within the application to interact >> with the container. >> >> John >> >> On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau >> > wrote: >> >> sure I fully agree excepted I think introducing yet >> another API to do >> the same thing is not good so super tempting to skip >> it and wait for >> feedbacks rather than introducing it eagerly. >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> >> https://github.com/rmannibucau >> >> >> 2015-02-27 8:05 GMT+01:00 Jozef Hartinger >> >: >> > My point is that from the application perspective, >> the user obtains one >> > container handle for eventual shutdown >> (CDIContainer) and then looks up a >> > different container handle (CDI) that they can use >> for real work (lookup / >> > event dispatch / etc.) It would be cleaner if the >> container gave away a >> > single handle that can do all of that. >> > >> > >> > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: >> > >> > Not sure I get how a CDI instance can help. >> > >> > But container.getBeanManager() sounds nice is not a >> shortcut for >> > CDI.current().getBm() otherwise it looks like >> duplication to me. >> > >> > Can we make container not contextual - dont think >> so? If so it makes sense >> > otherwise I fear it doesnt add much. >> > >> > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" >> > a >> ?crit : >> >> >> >> I like the initialize + close() combination and >> the try-with-resources >> >> usage. >> >> What looks weird to me is that at line one you >> obtain a container handle: >> >> >> >> try (CDIContainer container = >> CDIContainer.newCDIContai... >> >> CDI.current().getBeanManager() ... >> >> >> >> and then at line two you call a static method to >> perform a container >> >> lookup :-/ >> >> >> >> An API that allows you to use the container handle >> you already got is way >> >> better IMO, e.g.: >> >> >> >> try (CDIContainer container = >> CDIContainer.newCDIContai... >> >> container.getBeanManager() >> >> >> >> If CDIContainer.newCDIContainer() returns an CDI >> instance or its subclass, >> >> we get this easily. >> >> >> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: >> >>> >> >>> Hi guys >> >>> >> >>> why note keeping it simple? >> >>> >> >>> try (CDIContainer container = >> CDIContainer.newCDIContainer(/* optional >> >>> map to configure vendor features */)) { >> >>> CDI.current().getBeanManager().... >> >>> } >> >>> >> >>> Not sure the point having initialize() + having >> shutdown = close >> >>> really makes the API more fluent and modern IMO. >> >>> >> >>> Also to be fully SE I guess provider() method >> would be needed even if >> >>> optional (SPI usage by default): >> >>> >> >>> try (CDIContainer container = >> >>> >> >>> >> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider").newCDIContainer()) >> >>> { >> >>> CDI.current().getBeanManager().... >> >>> } >> >>> >> >>> Finally I think having a kind of getInstance >> shortcut could be a plus for >> >>> SE: >> >>> >> >>> try (CDIContainer container = >> CDIContainer.newCDIContainer()) { >> >>> container.newInstance(MyAppRunner.class /* >> optional qualifiers */ >> >>> ).run(args); >> >>> } >> >>> >> >>> Using container to get an instance would create >> the instance and bind >> >>> it to the container lifecycle (mainly for >> predestroy) avoiding this >> >>> boilerplate code in all main which will surely >> only be used to launch >> >>> a soft. >> >>> >> >>> wdyt? >> >>> >> >>> >> >>> >> >>> Romain Manni-Bucau >> >>> @rmannibucau >> >>> http://www.tomitribe.com >> >>> http://rmannibucau.wordpress.com >> >> >>> https://github.com/rmannibucau >> >>> >> >>> >> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger >> >: >> >>>> >> >>>> Comments inline >> >>>> >> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: >> >>>> >> >>>> Sorry Jozef, your email fell into the pits of >> google inbox's "smart >> >>>> sorting" >> >>>> features. >> >>>> >> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger >> > >> >>>> wrote: >> >>>>> >> >>>>> Hi John, comments inline: >> >>>>> >> >>>>> >> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >> >>>>> >> >>>>> Jozef, >> >>>>> >> >>>>> Most of what you see there is taken from the >> original doc, since >> >>>>> everyone >> >>>>> seemed to be in agreement. I think the map is >> just a safeguard in case >> >>>>> of >> >>>>> additional boot options available in some >> implementations (e.g. I think >> >>>>> OWB/OpenEJB have some options.. currently >> OpenEJB supports an embedded >> >>>>> CDI >> >>>>> boot mode). >> >>>>> >> >>>>> No, I am fine with the map. What I am >> questioning is the type of the >> >>>>> map. >> >>>>> Usually, data structures with a similar purpose >> use Strings as their >> >>>>> keys. >> >>>>> This applies to ServletContext attributes, >> InvocationContext data, >> >>>>> Servlet >> >>>>> request/session attributes and others. I am >> therefore wondering whether >> >>>>> there is a usecase for the proposed unbound key >> signature or not. >> >>>> >> >>>> >> >>>> I think that's more of a placeholder, I was >> assuming it would be >> >>>> Map once we clarify everything. >> >>>> >> >>>>> >> >>>>> >> >>>>> We spoke a few times about BeanManager vs CDI. >> BeanManager was >> >>>>> preferable >> >>>>> since there's no easy way to get the the >> instance, CDI is easier to get >> >>>>> and >> >>>>> more aligned with how you would get it. >> Usually people expect the >> >>>>> BeanManager to be injected or available via >> JNDI, neither would be the >> >>>>> case >> >>>>> here. >> >>>>> >> >>>>> If CDI 2.0 targets Java SE then this container >> initialization API will >> >>>>> become something that ordinary application >> developers use to start/stop >> >>>>> CDI >> >>>>> in their applications. It therefore cannot be >> considered an SPI but >> >>>>> instead >> >>>>> should be something easy to use. On the other >> hand, BeanManager is >> >>>>> definitely an SPI. It is used in extension, >> frameworks and generally >> >>>>> for >> >>>>> integration. Not much by applications directly. >> Therefore, I don't see >> >>>>> how >> >>>>> the container bootstrap API and BeanManager fit >> together. IMO the >> >>>>> bootstrap >> >>>>> API should expose something that makes common >> tasks (obtaining a >> >>>>> contextual >> >>>>> reference and firing and event) easy, which the >> CDI class does. >> >>>>> >> >>>>> Plus do not forget that BeanManager can be >> obtained easily using >> >>>>> CDI.getBeanManager(). >> >>>> >> >>>> >> >>>> I'm not disagreeing. There's a few things I'd >> consider: >> >>>> >> >>>> - Is this mostly for new apps or existing? If >> existing, it's probably >> >>>> using >> >>>> some internal API, if new it can use whatever >> API we give. >> >>>> - I don't want to return void, we should give >> some kind of reference >> >>>> into >> >>>> the container when we're done booting. >> >>>> >> >>>> Agreed, we should not be returning void. >> >>>> >> >>>> - CDI is a one step retrievable reference, where >> as BeanManager is a two >> >>>> step reference. With that said, BeanManager >> makes more sense to return >> >>>> here. Another thought could be we invent some >> new class that has both, >> >>>> but >> >>>> that's really redundant. >> >>>> >> >>>> Why do you think BeanManager makes more sense >> here? Especially given the >> >>>> assumption that application code is going to >> call this init/shutdown >> >>>> API, I >> >>>> don't see BeanManager as making more sense. >> >>>> >> >>>> >> >>>>> >> >>>>> >> >>>>> Yes, this is the container start API. Sounds >> like you have some good >> >>>>> ideas for things like XML configuration or >> programmatic configuration, >> >>>>> both >> >>>>> of which are being tracked under separate >> tickets. One idea might be >> >>>>> for an >> >>>>> optional param in the map to control packages >> to scan/ignore, in that >> >>>>> map. >> >>>>> >> >>>>> I am wondering whether this configuration >> should be something optional >> >>>>> built on top of the bootstrap API or whether we >> should consider making >> >>>>> it >> >>>>> mandatory. Either way, we cannot add the >> bootstrap API to the spec >> >>>>> without >> >>>>> explicitly defining how it behaves. My implicit >> assumption of the >> >>>>> proposal >> >>>>> is that the container is supposed to scan the >> entire classpath for >> >>>>> explicit >> >>>>> or implicit bean archives (including e.g. >> rt.jar), discover beans, fire >> >>>>> extensions, etc. This worries me as this >> default behavior is far from >> >>>>> being >> >>>>> lightweight, which CDI for Java SE initially >> aimed to be. >> >>>> >> >>>> >> >>>> Yes, the spec must be updated to reflect the >> behavior of SE mode. I >> >>>> plan to >> >>>> get that completely into the google doc before >> opening any spec changes >> >>>> in a >> >>>> PR. >> >>>> >> >>>>> >> >>>>> >> >>>>> We didn't want to over load the CDI interface. >> It already does a lot. >> >>>>> This is really SPI code, CDI even though it's >> in the spi package is >> >>>>> used in >> >>>>> a lot of application code. >> >>>>> >> >>>>> I would personally prefer to have it all in one >> place. Having >> >>>>> CDIContainer, CDIContainerLoader, CDI and >> CDIProvider makes it more >> >>>>> difficult to know when to use what. >> >>>> >> >>>> >> >>>> The problem is that most CDI (the interface) >> operations are against a >> >>>> running container. I think we spoke about >> leveraging CDIProvider at one >> >>>> point (in fact, I mistakenly called CDIContainer >> CDIProvider not even >> >>>> realizing it was there). I doubt that most app >> developers use it >> >>>> currently, >> >>>> there's not even a way to get a reference to it >> that I'm aware of. It's >> >>>> used by the implementor only. >> >>>> >> >>>> I don't think there's a conflict. CDI class >> would still only provide >> >>>> methods >> >>>> to be run against a running container. The >> difference is that there >> >>>> would be >> >>>> additional static methods to get this running >> container (CDI class) to >> >>>> you >> >>>> by starting the container. >> >>>> >> >>>> Either way, I agree that reusing CDIProvider is >> a must. There is no >> >>>> reason >> >>>> to define a new class for the same purpose. >> >>>> >> >>>> >> >>>> I expect that my changes in the CDI spec around >> this will state, along >> >>>> the >> >>>> lines of: >> >>>> >> >>>> To retrieve a CDIContainer to launch, do this: >> >>>> >> >>>> CDIContainer container = >> CDIContainerLocator.getCDIContainer(); >> >>>> container.initialize(); >> >>>> ... do work >> >>>> >> >>>> Once you want to shutdown the container, do this: >> >>>> >> >>>> container.shutdown(); >> >>>> >> >>>> (we may want to consider implementing >> AutoCloseable, an oversight on my >> >>>> part) >> >>>> >> >>>> and then later on >> >>>> >> >>>> - What happens if I call CDIContainerLocator in >> an app server >> >>>> >> >>>> - It throws an IllegalStateException. >> >>>> >> >>>> - The container provides no beans of type >> CDIContainer, it is managed >> >>>> outside of the CDI container. >> >>>> >> >>>> >> >>>>> >> >>>>> >> >>>>> John >> >>>>> >> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef >> Hartinger > > >> >>>>> wrote: >> >>>>>> >> >>>>>> Hi John, some thoughts: >> >>>>>> >> >>>>>> - instead of using BeanManager it makes more >> sense to me to return a >> >>>>>> CDI >> >>>>>> instance, which is a more user-friendly API >> (and it also exposes >> >>>>>> access to >> >>>>>> BeanManager) >> >>>>>> - is there a usecase for arbitrary keys of the >> "params" map or is >> >>>>>> Map sufficient? >> >>>>>> - if we could move the shutdown() method from >> CDIContainer to the >> >>>>>> actual >> >>>>>> container handle that we obtain from >> initialize(), that would look >> >>>>>> more >> >>>>>> object-oriented >> >>>>>> - what exactly is initialize() supposed to do? >> Is it supposed to start >> >>>>>> scanning the entire classpath for CDI beans? >> That could be a problem >> >>>>>> especially with spring-boot-like fat jars. I >> think we need an API to >> >>>>>> tell >> >>>>>> the container which classes / packages to >> consider. Something like >> >>>>>> Guice's >> >>>>>> binding API perhaps? >> >>>>>> >> >>>>>> - the proposal makes me wonder whether >> retrofitting this functionality >> >>>>>> to >> >>>>>> the CDI class wouldn't be a better option. It >> could look like: >> >>>>>> >> >>>>>> CDI container = CDI.initialize(); >> >>>>>> container.select(Foo.class).get(); >> >>>>>> container.shutdown(); >> >>>>>> >> >>>>>> compare it to: >> >>>>>> >> >>>>>> CDIContainer container = CDIContainerLoader. >> getCDIContainer(); >> >>>>>> BeanManager manager = container.initialize(); >> >>>>>> manager.getBeans(...); >> >>>>>> container.shutdown(manager); >> >>>>>> >> >>>>>> >> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >> >>>>>> >> >>>>>> All, >> >>>>>> >> >>>>>> I have the updated API here, and wanted to >> solicit any final feedback >> >>>>>> before updating the google doc and spec pages. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c >> >>>>>> >> >>>>>> Let me know your thoughts. >> >>>>>> >> >>>>>> Thanks, >> >>>>>> >> >>>>>> John >> >>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> cdi-dev mailing list >> >>>>>> cdi-dev at lists.jboss.org >> >> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >>>>>> >> >>>>>> Note that for all code provided on this list, >> the provider licenses >> >>>>>> the >> >>>>>> code under the Apache License, Version 2 >> >>>>>> >> (http://www.apache.org/licenses/LICENSE-2.0.html). >> For all other ideas >> >>>>>> provided on this list, the provider waives all >> patent and other >> >>>>>> intellectual >> >>>>>> property rights inherent in such information. >> >>>>>> >> >>>>>> >> >>>> >> >>>> _______________________________________________ >> >>>> cdi-dev mailing list >> >>>> cdi-dev at lists.jboss.org >> >> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >>>> >> >>>> Note that for all code provided on this list, >> the provider licenses the >> >>>> code >> >>>> under the Apache License, Version 2 >> >>>> >> (http://www.apache.org/licenses/LICENSE-2.0.html). >> For all other ideas >> >>>> provided on this list, the provider waives all >> patent and other >> >>>> intellectual >> >>>> property rights inherent in such information. >> >> >> >> >> > >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider >> licenses the code under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >> ideas provided on this list, the provider waives all patent and >> other intellectual property rights inherent in such information. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider > licenses the code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > ideas provided on this list, the provider waives all patent and > other intellectual property rights inherent in such information. > > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/e100622b/attachment-0001.html From issues at jboss.org Wed Mar 4 05:35:49 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Wed, 4 Mar 2015 05:35:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-514) FireEventTest#testDuplicateBindingsToFireEventFails() is wrong In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046100#comment-13046100 ] Mark Struberg commented on CDI-514: ----------------------------------- correctness? of what? This is currently preventing a perfectly valid use case. IF then it would need to be check for Qualifier equality (taking binding params into account). But even if not - what happens if a user queries with n times the same qualifier? Nothing, nada, njente. There is just no impact! You will always get back the same Bean. So it DOES break valid use cases and it DOES NOT prevent some broken cases -> totally useless, and we should fix this. > FireEventTest#testDuplicateBindingsToFireEventFails() is wrong > -------------------------------------------------------------- > > Key: CDI-514 > URL: https://issues.jboss.org/browse/CDI-514 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Mark Struberg > > testDuplicateBindingsToFireEventFails() tests for 2 Lifted literals with different values. But this is perfectly fine as value is NOT annotated as @Nonbinding. Thus the 2 literals are NOT equals according to CDI rules. They are essentially 2 different annotations... > Plz remove this test. It also makes no sense to add all those very performance costly tests at runtime. The worst case which can happen is that the 2 annotations make no sense. But they don't break anything. Wheras checking all the nasty conditions each and every time is really mad from a performance aspect. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From antoine at sabot-durand.net Wed Mar 4 06:05:54 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 4 Mar 2015 12:05:54 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: <54F6DFB7.80503@redhat.com> References: <54DB1F2B.1020609@redhat.com> <54DC61D9.701@redhat.com> <54EECC20.6040600@redhat.com> <54EF396E.20805@redhat.com> <54F01720.3080802@redhat.com> <54F6DFB7.80503@redhat.com> Message-ID: <530BF7F9-12D3-473F-B65E-0419ABEBE163@sabot-durand.net> You?re reading my mind (and correcting my vocabulary) Jozef. Will you be there at today?s meeting? Your POV will be helpful to go forward on the subject. Antoine > Le 4 mars 2015 ? 11:34, Jozef Hartinger a ?crit : > > Let me fix the terminology here: "Multiple BeanManagers" is a misleading expression because it is not clear if we are talking about multiple BM within a single CDI container or separate containers. What Antoine had in mind (I think) is multiple CDI container instances. Therefore, let's use "multiple CDI container instances" hereafter in order not to get confused. > > This topic was discussed before. There are a few tricky parts that can be resolved more or less (e.g. CDI.current()). We may not necessarily need to specify this but we should make sure we do not anyhow prevent or make it unnecessarily difficult for CDI implementations to implement "multiple CDI container instances" running in parallel. > > > > On 03/04/2015 10:52 AM, Romain Manni-Bucau wrote: >> @Antoine: to boot multiple BM it would need to break contextuality of CDI, one way being to forbid any serialization (not a big constraint in SE). In this case container is bound to a bean manager which changes the API Jozef propose >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >> 2015-03-04 10:49 GMT+01:00 Antoine Sabot-Durand >: >> Hi John, >> >> I think it could be a good idea to write down all of these to have a more stable doc for discussion. You should update the google doc with the result of this discussion. >> >> I agree with the following points in this thread : >> >> - Minimize the number of new Class / Interface. CDI and CDIProvider usage is still not very clear for end user so we should add the strict minimum and try to enhance existing API / SPI when possible >> - Be able to bootstrap CDI without returning BeanManager (env if the API give possibility to access it if needed). End user don?t need that : CDI app can start with an observer for instance >> >> Something not dealt with but that we should keep in mind : >> - Providing a Java SE solution that could be easily used for a servlet bootstrap of CDI. I don?t know if we?ll standardize this but we definitely should keep this use case in mind >> >> and my bonus, it?s out of scope but I didn?t see anytime there that prevent this nice to have: >> - support the possibility to boot multiple BeanManager in Java SE. >> >> Antoine >> >> >>> Le 1 mars 2015 ? 15:13, John D. Ament > a ?crit : >>> >>> So, I think I've gathered enough feedback at this point, and seen some of the API changes. I'll hopefully be including some doc changes this week, but one question - do we want to start the SE specific stuff as its own asciidoc file? >>> >>> Changes made: >>> >>> - Changed return value to CDI to provide better capability out of the box. >>> - Added AutoCloseable to CDIContainer, provided default implementation of calling shutdown. >>> - Added synchronization support to the method body that retrieves the singleton instance (BTW, I'm not sure if this is even useful TBH as each impl, including the RI, needs to provide this class in its own format). >>> - Made the params map typed to >>> >>> @Romain Your case isn't really supportable yet, until we have static injection support. You'd still have to have a managed version of Runner to work against. >>> >>> John >>> >>> On Sat, Feb 28, 2015 at 4:11 PM Romain Manni-Bucau > wrote: >>> Yes but not the way to get an instance. Even Unmanaged does it. >>> >>> What can be awesome is to have static inject for it: >>> >>> public class Runner { >>> >>> @Inject >>> private static MyMain main; >>> >>> public static void main(String[] arg) { >>> try (CDIContainer c = CDIContainer.newContainer()) { >>> main.doWork(); >>> } >>> } >>> >>> } >>> >>> And not a single additional line :). >>> Le 28 f?vr. 2015 19:05, "John D. Ament" > a ?crit : >>> >>> Maybe I'm misreading, but I don't see us adding another API to do the same thing here - we're introducing new functionality. >>> >>> CDIContainer/Loader on startup/shutdown of the application >>> >>> CDI for runtime usage within the application to interact with the container. >>> >>> John >>> >>> On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau > wrote: >>> sure I fully agree excepted I think introducing yet another API to do >>> the same thing is not good so super tempting to skip it and wait for >>> feedbacks rather than introducing it eagerly. >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau >>> http://www.tomitribe.com >>> http://rmannibucau.wordpress.com >>> https://github.com/rmannibucau >>> >>> >>> 2015-02-27 8:05 GMT+01:00 Jozef Hartinger >: >>> > My point is that from the application perspective, the user obtains one >>> > container handle for eventual shutdown (CDIContainer) and then looks up a >>> > different container handle (CDI) that they can use for real work (lookup / >>> > event dispatch / etc.) It would be cleaner if the container gave away a >>> > single handle that can do all of that. >>> > >>> > >>> > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: >>> > >>> > Not sure I get how a CDI instance can help. >>> > >>> > But container.getBeanManager() sounds nice is not a shortcut for >>> > CDI.current().getBm() otherwise it looks like duplication to me. >>> > >>> > Can we make container not contextual - dont think so? If so it makes sense >>> > otherwise I fear it doesnt add much. >>> > >>> > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" > a ?crit : >>> >> >>> >> I like the initialize + close() combination and the try-with-resources >>> >> usage. >>> >> What looks weird to me is that at line one you obtain a container handle: >>> >> >>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>> >> CDI.current().getBeanManager() ... >>> >> >>> >> and then at line two you call a static method to perform a container >>> >> lookup :-/ >>> >> >>> >> An API that allows you to use the container handle you already got is way >>> >> better IMO, e.g.: >>> >> >>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>> >> container.getBeanManager() >>> >> >>> >> If CDIContainer.newCDIContainer() returns an CDI instance or its subclass, >>> >> we get this easily. >>> >> >>> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: >>> >>> >>> >>> Hi guys >>> >>> >>> >>> why note keeping it simple? >>> >>> >>> >>> try (CDIContainer container = CDIContainer.newCDIContainer(/* optional >>> >>> map to configure vendor features */)) { >>> >>> CDI.current().getBeanManager().... >>> >>> } >>> >>> >>> >>> Not sure the point having initialize() + having shutdown = close >>> >>> really makes the API more fluent and modern IMO. >>> >>> >>> >>> Also to be fully SE I guess provider() method would be needed even if >>> >>> optional (SPI usage by default): >>> >>> >>> >>> try (CDIContainer container = >>> >>> >>> >>> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider").newCDIContainer()) >>> >>> { >>> >>> CDI.current().getBeanManager().... >>> >>> } >>> >>> >>> >>> Finally I think having a kind of getInstance shortcut could be a plus for >>> >>> SE: >>> >>> >>> >>> try (CDIContainer container = CDIContainer.newCDIContainer()) { >>> >>> container.newInstance(MyAppRunner.class /* optional qualifiers */ >>> >>> ).run(args); >>> >>> } >>> >>> >>> >>> Using container to get an instance would create the instance and bind >>> >>> it to the container lifecycle (mainly for predestroy) avoiding this >>> >>> boilerplate code in all main which will surely only be used to launch >>> >>> a soft. >>> >>> >>> >>> wdyt? >>> >>> >>> >>> >>> >>> >>> >>> Romain Manni-Bucau >>> >>> @rmannibucau >>> >>> http://www.tomitribe.com >>> >>> http://rmannibucau.wordpress.com >>> >>> https://github.com/rmannibucau >>> >>> >>> >>> >>> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger >: >>> >>>> >>> >>>> Comments inline >>> >>>> >>> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: >>> >>>> >>> >>>> Sorry Jozef, your email fell into the pits of google inbox's "smart >>> >>>> sorting" >>> >>>> features. >>> >>>> >>> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger > >>> >>>> wrote: >>> >>>>> >>> >>>>> Hi John, comments inline: >>> >>>>> >>> >>>>> >>> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >>> >>>>> >>> >>>>> Jozef, >>> >>>>> >>> >>>>> Most of what you see there is taken from the original doc, since >>> >>>>> everyone >>> >>>>> seemed to be in agreement. I think the map is just a safeguard in case >>> >>>>> of >>> >>>>> additional boot options available in some implementations (e.g. I think >>> >>>>> OWB/OpenEJB have some options.. currently OpenEJB supports an embedded >>> >>>>> CDI >>> >>>>> boot mode). >>> >>>>> >>> >>>>> No, I am fine with the map. What I am questioning is the type of the >>> >>>>> map. >>> >>>>> Usually, data structures with a similar purpose use Strings as their >>> >>>>> keys. >>> >>>>> This applies to ServletContext attributes, InvocationContext data, >>> >>>>> Servlet >>> >>>>> request/session attributes and others. I am therefore wondering whether >>> >>>>> there is a usecase for the proposed unbound key signature or not. >>> >>>> >>> >>>> >>> >>>> I think that's more of a placeholder, I was assuming it would be >>> >>>> Map once we clarify everything. >>> >>>> >>> >>>>> >>> >>>>> >>> >>>>> We spoke a few times about BeanManager vs CDI. BeanManager was >>> >>>>> preferable >>> >>>>> since there's no easy way to get the the instance, CDI is easier to get >>> >>>>> and >>> >>>>> more aligned with how you would get it. Usually people expect the >>> >>>>> BeanManager to be injected or available via JNDI, neither would be the >>> >>>>> case >>> >>>>> here. >>> >>>>> >>> >>>>> If CDI 2.0 targets Java SE then this container initialization API will >>> >>>>> become something that ordinary application developers use to start/stop >>> >>>>> CDI >>> >>>>> in their applications. It therefore cannot be considered an SPI but >>> >>>>> instead >>> >>>>> should be something easy to use. On the other hand, BeanManager is >>> >>>>> definitely an SPI. It is used in extension, frameworks and generally >>> >>>>> for >>> >>>>> integration. Not much by applications directly. Therefore, I don't see >>> >>>>> how >>> >>>>> the container bootstrap API and BeanManager fit together. IMO the >>> >>>>> bootstrap >>> >>>>> API should expose something that makes common tasks (obtaining a >>> >>>>> contextual >>> >>>>> reference and firing and event) easy, which the CDI class does. >>> >>>>> >>> >>>>> Plus do not forget that BeanManager can be obtained easily using >>> >>>>> CDI.getBeanManager(). >>> >>>> >>> >>>> >>> >>>> I'm not disagreeing. There's a few things I'd consider: >>> >>>> >>> >>>> - Is this mostly for new apps or existing? If existing, it's probably >>> >>>> using >>> >>>> some internal API, if new it can use whatever API we give. >>> >>>> - I don't want to return void, we should give some kind of reference >>> >>>> into >>> >>>> the container when we're done booting. >>> >>>> >>> >>>> Agreed, we should not be returning void. >>> >>>> >>> >>>> - CDI is a one step retrievable reference, where as BeanManager is a two >>> >>>> step reference. With that said, BeanManager makes more sense to return >>> >>>> here. Another thought could be we invent some new class that has both, >>> >>>> but >>> >>>> that's really redundant. >>> >>>> >>> >>>> Why do you think BeanManager makes more sense here? Especially given the >>> >>>> assumption that application code is going to call this init/shutdown >>> >>>> API, I >>> >>>> don't see BeanManager as making more sense. >>> >>>> >>> >>>> >>> >>>>> >>> >>>>> >>> >>>>> Yes, this is the container start API. Sounds like you have some good >>> >>>>> ideas for things like XML configuration or programmatic configuration, >>> >>>>> both >>> >>>>> of which are being tracked under separate tickets. One idea might be >>> >>>>> for an >>> >>>>> optional param in the map to control packages to scan/ignore, in that >>> >>>>> map. >>> >>>>> >>> >>>>> I am wondering whether this configuration should be something optional >>> >>>>> built on top of the bootstrap API or whether we should consider making >>> >>>>> it >>> >>>>> mandatory. Either way, we cannot add the bootstrap API to the spec >>> >>>>> without >>> >>>>> explicitly defining how it behaves. My implicit assumption of the >>> >>>>> proposal >>> >>>>> is that the container is supposed to scan the entire classpath for >>> >>>>> explicit >>> >>>>> or implicit bean archives (including e.g. rt.jar), discover beans, fire >>> >>>>> extensions, etc. This worries me as this default behavior is far from >>> >>>>> being >>> >>>>> lightweight, which CDI for Java SE initially aimed to be. >>> >>>> >>> >>>> >>> >>>> Yes, the spec must be updated to reflect the behavior of SE mode. I >>> >>>> plan to >>> >>>> get that completely into the google doc before opening any spec changes >>> >>>> in a >>> >>>> PR. >>> >>>> >>> >>>>> >>> >>>>> >>> >>>>> We didn't want to over load the CDI interface. It already does a lot. >>> >>>>> This is really SPI code, CDI even though it's in the spi package is >>> >>>>> used in >>> >>>>> a lot of application code. >>> >>>>> >>> >>>>> I would personally prefer to have it all in one place. Having >>> >>>>> CDIContainer, CDIContainerLoader, CDI and CDIProvider makes it more >>> >>>>> difficult to know when to use what. >>> >>>> >>> >>>> >>> >>>> The problem is that most CDI (the interface) operations are against a >>> >>>> running container. I think we spoke about leveraging CDIProvider at one >>> >>>> point (in fact, I mistakenly called CDIContainer CDIProvider not even >>> >>>> realizing it was there). I doubt that most app developers use it >>> >>>> currently, >>> >>>> there's not even a way to get a reference to it that I'm aware of. It's >>> >>>> used by the implementor only. >>> >>>> >>> >>>> I don't think there's a conflict. CDI class would still only provide >>> >>>> methods >>> >>>> to be run against a running container. The difference is that there >>> >>>> would be >>> >>>> additional static methods to get this running container (CDI class) to >>> >>>> you >>> >>>> by starting the container. >>> >>>> >>> >>>> Either way, I agree that reusing CDIProvider is a must. There is no >>> >>>> reason >>> >>>> to define a new class for the same purpose. >>> >>>> >>> >>>> >>> >>>> I expect that my changes in the CDI spec around this will state, along >>> >>>> the >>> >>>> lines of: >>> >>>> >>> >>>> To retrieve a CDIContainer to launch, do this: >>> >>>> >>> >>>> CDIContainer container = CDIContainerLocator.getCDIContainer(); >>> >>>> container.initialize(); >>> >>>> ... do work >>> >>>> >>> >>>> Once you want to shutdown the container, do this: >>> >>>> >>> >>>> container.shutdown(); >>> >>>> >>> >>>> (we may want to consider implementing AutoCloseable, an oversight on my >>> >>>> part) >>> >>>> >>> >>>> and then later on >>> >>>> >>> >>>> - What happens if I call CDIContainerLocator in an app server >>> >>>> >>> >>>> - It throws an IllegalStateException. >>> >>>> >>> >>>> - The container provides no beans of type CDIContainer, it is managed >>> >>>> outside of the CDI container. >>> >>>> >>> >>>> >>> >>>>> >>> >>>>> >>> >>>>> John >>> >>>>> >>> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger > >>> >>>>> wrote: >>> >>>>>> >>> >>>>>> Hi John, some thoughts: >>> >>>>>> >>> >>>>>> - instead of using BeanManager it makes more sense to me to return a >>> >>>>>> CDI >>> >>>>>> instance, which is a more user-friendly API (and it also exposes >>> >>>>>> access to >>> >>>>>> BeanManager) >>> >>>>>> - is there a usecase for arbitrary keys of the "params" map or is >>> >>>>>> Map sufficient? >>> >>>>>> - if we could move the shutdown() method from CDIContainer to the >>> >>>>>> actual >>> >>>>>> container handle that we obtain from initialize(), that would look >>> >>>>>> more >>> >>>>>> object-oriented >>> >>>>>> - what exactly is initialize() supposed to do? Is it supposed to start >>> >>>>>> scanning the entire classpath for CDI beans? That could be a problem >>> >>>>>> especially with spring-boot-like fat jars. I think we need an API to >>> >>>>>> tell >>> >>>>>> the container which classes / packages to consider. Something like >>> >>>>>> Guice's >>> >>>>>> binding API perhaps? >>> >>>>>> >>> >>>>>> - the proposal makes me wonder whether retrofitting this functionality >>> >>>>>> to >>> >>>>>> the CDI class wouldn't be a better option. It could look like: >>> >>>>>> >>> >>>>>> CDI container = CDI.initialize(); >>> >>>>>> container.select(Foo.class).get(); >>> >>>>>> container.shutdown(); >>> >>>>>> >>> >>>>>> compare it to: >>> >>>>>> >>> >>>>>> CDIContainer container = CDIContainerLoader. getCDIContainer(); >>> >>>>>> BeanManager manager = container.initialize(); >>> >>>>>> manager.getBeans(...); >>> >>>>>> container.shutdown(manager); >>> >>>>>> >>> >>>>>> >>> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >>> >>>>>> >>> >>>>>> All, >>> >>>>>> >>> >>>>>> I have the updated API here, and wanted to solicit any final feedback >>> >>>>>> before updating the google doc and spec pages. >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c >>> >>>>>> >>> >>>>>> Let me know your thoughts. >>> >>>>>> >>> >>>>>> Thanks, >>> >>>>>> >>> >>>>>> John >>> >>>>>> >>> >>>>>> >>> >>>>>> _______________________________________________ >>> >>>>>> cdi-dev mailing list >>> >>>>>> cdi-dev at lists.jboss.org >>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>>>>> >>> >>>>>> Note that for all code provided on this list, the provider licenses >>> >>>>>> the >>> >>>>>> code under the Apache License, Version 2 >>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas >>> >>>>>> provided on this list, the provider waives all patent and other >>> >>>>>> intellectual >>> >>>>>> property rights inherent in such information. >>> >>>>>> >>> >>>>>> >>> >>>> >>> >>>> _______________________________________________ >>> >>>> cdi-dev mailing list >>> >>>> cdi-dev at lists.jboss.org >>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>>> >>> >>>> Note that for all code provided on this list, the provider licenses the >>> >>>> code >>> >>>> under the Apache License, Version 2 >>> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas >>> >>>> provided on this list, the provider waives all patent and other >>> >>>> intellectual >>> >>>> property rights inherent in such information. >>> >> >>> >> >>> > >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/174c9257/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/20150304/174c9257/attachment-0001.bin From jharting at redhat.com Wed Mar 4 06:11:51 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 04 Mar 2015 12:11:51 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: <530BF7F9-12D3-473F-B65E-0419ABEBE163@sabot-durand.net> References: <54DB1F2B.1020609@redhat.com> <54DC61D9.701@redhat.com> <54EECC20.6040600@redhat.com> <54EF396E.20805@redhat.com> <54F01720.3080802@redhat.com> <54F6DFB7.80503@redhat.com> <530BF7F9-12D3-473F-B65E-0419ABEBE163@sabot-durand.net> Message-ID: <54F6E877.8010000@redhat.com> No, sorry, I won't be available in the evening. On 03/04/2015 12:05 PM, Antoine Sabot-Durand wrote: > You?re reading my mind (and correcting my vocabulary) Jozef. Will you > be there at today?s meeting? Your POV will be helpful to go forward on > the subject. > > Antoine > > >> Le 4 mars 2015 ? 11:34, Jozef Hartinger > > a ?crit : >> >> Let me fix the terminology here: "Multiple BeanManagers" is a >> misleading expression because it is not clear if we are talking about >> multiple BM within a single CDI container or separate containers. >> What Antoine had in mind (I think) is multiple CDI container >> instances. Therefore, let's use "multiple CDI container instances" >> hereafter in order not to get confused. >> >> This topic was discussed before. There are a few tricky parts that >> can be resolved more or less (e.g. CDI.current()). We may not >> necessarily need to specify this but we should make sure we do not >> anyhow prevent or make it unnecessarily difficult for CDI >> implementations to implement "multiple CDI container instances" >> running in parallel. >> >> >> >> On 03/04/2015 10:52 AM, Romain Manni-Bucau wrote: >>> @Antoine: to boot multiple BM it would need to break contextuality >>> of CDI, one way being to forbid any serialization (not a big >>> constraint in SE). In this case container is bound to a bean manager >>> which changes the API Jozef propose >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog >>> | Github >>> | LinkedIn >>> | Tomitriber >>> >>> >>> 2015-03-04 10:49 GMT+01:00 Antoine Sabot-Durand >>> >: >>> >>> Hi John, >>> >>> I think it could be a good idea to write down all of these to >>> have a more stable doc for discussion. You should update the >>> google doc with the result of this discussion. >>> >>> I agree with the following points in this thread : >>> >>> - Minimize the number of new Class / Interface. CDI and >>> CDIProvider usage is still not very clear for end user so we >>> should add the strict minimum and try to enhance existing API / >>> SPI when possible >>> - Be able to bootstrap CDI without returning BeanManager (env if >>> the API give possibility to access it if needed). End user don?t >>> need that : CDI app can start with an observer for instance >>> >>> Something not dealt with but that we should keep in mind : >>> - Providing a Java SE solution that could be easily used for a >>> servlet bootstrap of CDI. I don?t know if we?ll standardize this >>> but we definitely should keep this use case in mind >>> >>> and my bonus, it?s out of scope but I didn?t see anytime there >>> that prevent this nice to have: >>> - support the possibility to boot multiple BeanManager in Java SE. >>> >>> Antoine >>> >>> >>>> Le 1 mars 2015 ? 15:13, John D. Ament >>> > a ?crit : >>>> >>>> So, I think I've gathered enough feedback at this point, and >>>> seen some of the API changes. I'll hopefully be including some >>>> doc changes this week, but one question - do we want to start >>>> the SE specific stuff as its own asciidoc file? >>>> >>>> Changes made: >>>> >>>> - Changed return value to CDI to provide better >>>> capability out of the box. >>>> - Added AutoCloseable to CDIContainer, provided default >>>> implementation of calling shutdown. >>>> - Added synchronization support to the method body that >>>> retrieves the singleton instance (BTW, I'm not sure if this is >>>> even useful TBH as each impl, including the RI, needs to >>>> provide this class in its own format). >>>> - Made the params map typed to >>>> >>>> @Romain Your case isn't really supportable yet, until we have >>>> static injection support. You'd still have to have a managed >>>> version of Runner to work against. >>>> >>>> John >>>> >>>> On Sat, Feb 28, 2015 at 4:11 PM Romain Manni-Bucau >>>> > wrote: >>>> >>>> Yes but not the way to get an instance. Even Unmanaged does it. >>>> >>>> What can be awesome is to have static inject for it: >>>> >>>> public class Runner { >>>> >>>> @Inject >>>> private static MyMain main; >>>> >>>> public static void main(String[] arg) { >>>> try (CDIContainer c = CDIContainer.newContainer()) { >>>> main.doWork(); >>>> } >>>> } >>>> >>>> } >>>> >>>> And not a single additional line :). >>>> >>>> Le 28 f?vr. 2015 19:05, "John D. Ament" >>>> > a >>>> ?crit : >>>> >>>> Maybe I'm misreading, but I don't see us adding another >>>> API to do the same thing here - we're introducing new >>>> functionality. >>>> >>>> CDIContainer/Loader on startup/shutdown of the application >>>> >>>> CDI for runtime usage within the application to >>>> interact with the container. >>>> >>>> John >>>> >>>> On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau >>>> > >>>> wrote: >>>> >>>> sure I fully agree excepted I think introducing yet >>>> another API to do >>>> the same thing is not good so super tempting to >>>> skip it and wait for >>>> feedbacks rather than introducing it eagerly. >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau >>>> http://www.tomitribe.com >>>> http://rmannibucau.wordpress.com >>>> >>>> https://github.com/rmannibucau >>>> >>>> >>>> 2015-02-27 8:05 GMT+01:00 Jozef Hartinger >>>> >: >>>> > My point is that from the application >>>> perspective, the user obtains one >>>> > container handle for eventual shutdown >>>> (CDIContainer) and then looks up a >>>> > different container handle (CDI) that they can >>>> use for real work (lookup / >>>> > event dispatch / etc.) It would be cleaner if the >>>> container gave away a >>>> > single handle that can do all of that. >>>> > >>>> > >>>> > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: >>>> > >>>> > Not sure I get how a CDI instance can help. >>>> > >>>> > But container.getBeanManager() sounds nice is not >>>> a shortcut for >>>> > CDI.current().getBm() otherwise it looks like >>>> duplication to me. >>>> > >>>> > Can we make container not contextual - dont think >>>> so? If so it makes sense >>>> > otherwise I fear it doesnt add much. >>>> > >>>> > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" >>>> > >>>> a ?crit : >>>> >> >>>> >> I like the initialize + close() combination and >>>> the try-with-resources >>>> >> usage. >>>> >> What looks weird to me is that at line one you >>>> obtain a container handle: >>>> >> >>>> >> try (CDIContainer container = >>>> CDIContainer.newCDIContai... >>>> >> CDI.current().getBeanManager() ... >>>> >> >>>> >> and then at line two you call a static method to >>>> perform a container >>>> >> lookup :-/ >>>> >> >>>> >> An API that allows you to use the container >>>> handle you already got is way >>>> >> better IMO, e.g.: >>>> >> >>>> >> try (CDIContainer container = >>>> CDIContainer.newCDIContai... >>>> >> container.getBeanManager() >>>> >> >>>> >> If CDIContainer.newCDIContainer() returns an CDI >>>> instance or its subclass, >>>> >> we get this easily. >>>> >> >>>> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: >>>> >>> >>>> >>> Hi guys >>>> >>> >>>> >>> why note keeping it simple? >>>> >>> >>>> >>> try (CDIContainer container = >>>> CDIContainer.newCDIContainer(/* optional >>>> >>> map to configure vendor features */)) { >>>> >>> CDI.current().getBeanManager().... >>>> >>> } >>>> >>> >>>> >>> Not sure the point having initialize() + having >>>> shutdown = close >>>> >>> really makes the API more fluent and modern IMO. >>>> >>> >>>> >>> Also to be fully SE I guess provider() method >>>> would be needed even if >>>> >>> optional (SPI usage by default): >>>> >>> >>>> >>> try (CDIContainer container = >>>> >>> >>>> >>> >>>> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider").newCDIContainer()) >>>> >>> { >>>> >>> CDI.current().getBeanManager().... >>>> >>> } >>>> >>> >>>> >>> Finally I think having a kind of getInstance >>>> shortcut could be a plus for >>>> >>> SE: >>>> >>> >>>> >>> try (CDIContainer container = >>>> CDIContainer.newCDIContainer()) { >>>> >>> container.newInstance(MyAppRunner.class /* >>>> optional qualifiers */ >>>> >>> ).run(args); >>>> >>> } >>>> >>> >>>> >>> Using container to get an instance would create >>>> the instance and bind >>>> >>> it to the container lifecycle (mainly for >>>> predestroy) avoiding this >>>> >>> boilerplate code in all main which will surely >>>> only be used to launch >>>> >>> a soft. >>>> >>> >>>> >>> wdyt? >>>> >>> >>>> >>> >>>> >>> >>>> >>> Romain Manni-Bucau >>>> >>> @rmannibucau >>>> >>> http://www.tomitribe.com >>>> >>>> >>> http://rmannibucau.wordpress.com >>>> >>>> >>> https://github.com/rmannibucau >>>> >>> >>>> >>> >>>> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger >>>> >: >>>> >>>> >>>> >>>> Comments inline >>>> >>>> >>>> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: >>>> >>>> >>>> >>>> Sorry Jozef, your email fell into the pits of >>>> google inbox's "smart >>>> >>>> sorting" >>>> >>>> features. >>>> >>>> >>>> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef >>>> Hartinger >>> > >>>> >>>> wrote: >>>> >>>>> >>>> >>>>> Hi John, comments inline: >>>> >>>>> >>>> >>>>> >>>> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >>>> >>>>> >>>> >>>>> Jozef, >>>> >>>>> >>>> >>>>> Most of what you see there is taken from the >>>> original doc, since >>>> >>>>> everyone >>>> >>>>> seemed to be in agreement. I think the map >>>> is just a safeguard in case >>>> >>>>> of >>>> >>>>> additional boot options available in some >>>> implementations (e.g. I think >>>> >>>>> OWB/OpenEJB have some options.. currently >>>> OpenEJB supports an embedded >>>> >>>>> CDI >>>> >>>>> boot mode). >>>> >>>>> >>>> >>>>> No, I am fine with the map. What I am >>>> questioning is the type of the >>>> >>>>> map. >>>> >>>>> Usually, data structures with a similar >>>> purpose use Strings as their >>>> >>>>> keys. >>>> >>>>> This applies to ServletContext attributes, >>>> InvocationContext data, >>>> >>>>> Servlet >>>> >>>>> request/session attributes and others. I am >>>> therefore wondering whether >>>> >>>>> there is a usecase for the proposed unbound >>>> key signature or not. >>>> >>>> >>>> >>>> >>>> >>>> I think that's more of a placeholder, I was >>>> assuming it would be >>>> >>>> Map once we clarify everything. >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> We spoke a few times about BeanManager vs >>>> CDI. BeanManager was >>>> >>>>> preferable >>>> >>>>> since there's no easy way to get the the >>>> instance, CDI is easier to get >>>> >>>>> and >>>> >>>>> more aligned with how you would get it. >>>> Usually people expect the >>>> >>>>> BeanManager to be injected or available via >>>> JNDI, neither would be the >>>> >>>>> case >>>> >>>>> here. >>>> >>>>> >>>> >>>>> If CDI 2.0 targets Java SE then this >>>> container initialization API will >>>> >>>>> become something that ordinary application >>>> developers use to start/stop >>>> >>>>> CDI >>>> >>>>> in their applications. It therefore cannot be >>>> considered an SPI but >>>> >>>>> instead >>>> >>>>> should be something easy to use. On the other >>>> hand, BeanManager is >>>> >>>>> definitely an SPI. It is used in extension, >>>> frameworks and generally >>>> >>>>> for >>>> >>>>> integration. Not much by applications >>>> directly. Therefore, I don't see >>>> >>>>> how >>>> >>>>> the container bootstrap API and BeanManager >>>> fit together. IMO the >>>> >>>>> bootstrap >>>> >>>>> API should expose something that makes common >>>> tasks (obtaining a >>>> >>>>> contextual >>>> >>>>> reference and firing and event) easy, which >>>> the CDI class does. >>>> >>>>> >>>> >>>>> Plus do not forget that BeanManager can be >>>> obtained easily using >>>> >>>>> CDI.getBeanManager(). >>>> >>>> >>>> >>>> >>>> >>>> I'm not disagreeing. There's a few things I'd >>>> consider: >>>> >>>> >>>> >>>> - Is this mostly for new apps or existing? If >>>> existing, it's probably >>>> >>>> using >>>> >>>> some internal API, if new it can use whatever >>>> API we give. >>>> >>>> - I don't want to return void, we should give >>>> some kind of reference >>>> >>>> into >>>> >>>> the container when we're done booting. >>>> >>>> >>>> >>>> Agreed, we should not be returning void. >>>> >>>> >>>> >>>> - CDI is a one step retrievable reference, >>>> where as BeanManager is a two >>>> >>>> step reference. With that said, BeanManager >>>> makes more sense to return >>>> >>>> here. Another thought could be we invent some >>>> new class that has both, >>>> >>>> but >>>> >>>> that's really redundant. >>>> >>>> >>>> >>>> Why do you think BeanManager makes more sense >>>> here? Especially given the >>>> >>>> assumption that application code is going to >>>> call this init/shutdown >>>> >>>> API, I >>>> >>>> don't see BeanManager as making more sense. >>>> >>>> >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> Yes, this is the container start API. Sounds >>>> like you have some good >>>> >>>>> ideas for things like XML configuration or >>>> programmatic configuration, >>>> >>>>> both >>>> >>>>> of which are being tracked under separate >>>> tickets. One idea might be >>>> >>>>> for an >>>> >>>>> optional param in the map to control packages >>>> to scan/ignore, in that >>>> >>>>> map. >>>> >>>>> >>>> >>>>> I am wondering whether this configuration >>>> should be something optional >>>> >>>>> built on top of the bootstrap API or whether >>>> we should consider making >>>> >>>>> it >>>> >>>>> mandatory. Either way, we cannot add the >>>> bootstrap API to the spec >>>> >>>>> without >>>> >>>>> explicitly defining how it behaves. My >>>> implicit assumption of the >>>> >>>>> proposal >>>> >>>>> is that the container is supposed to scan the >>>> entire classpath for >>>> >>>>> explicit >>>> >>>>> or implicit bean archives (including e.g. >>>> rt.jar), discover beans, fire >>>> >>>>> extensions, etc. This worries me as this >>>> default behavior is far from >>>> >>>>> being >>>> >>>>> lightweight, which CDI for Java SE initially >>>> aimed to be. >>>> >>>> >>>> >>>> >>>> >>>> Yes, the spec must be updated to reflect the >>>> behavior of SE mode. I >>>> >>>> plan to >>>> >>>> get that completely into the google doc before >>>> opening any spec changes >>>> >>>> in a >>>> >>>> PR. >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> We didn't want to over load the CDI >>>> interface. It already does a lot. >>>> >>>>> This is really SPI code, CDI even though it's >>>> in the spi package is >>>> >>>>> used in >>>> >>>>> a lot of application code. >>>> >>>>> >>>> >>>>> I would personally prefer to have it all in >>>> one place. Having >>>> >>>>> CDIContainer, CDIContainerLoader, CDI and >>>> CDIProvider makes it more >>>> >>>>> difficult to know when to use what. >>>> >>>> >>>> >>>> >>>> >>>> The problem is that most CDI (the interface) >>>> operations are against a >>>> >>>> running container. I think we spoke about >>>> leveraging CDIProvider at one >>>> >>>> point (in fact, I mistakenly called >>>> CDIContainer CDIProvider not even >>>> >>>> realizing it was there). I doubt that most >>>> app developers use it >>>> >>>> currently, >>>> >>>> there's not even a way to get a reference to >>>> it that I'm aware of. It's >>>> >>>> used by the implementor only. >>>> >>>> >>>> >>>> I don't think there's a conflict. CDI class >>>> would still only provide >>>> >>>> methods >>>> >>>> to be run against a running container. The >>>> difference is that there >>>> >>>> would be >>>> >>>> additional static methods to get this running >>>> container (CDI class) to >>>> >>>> you >>>> >>>> by starting the container. >>>> >>>> >>>> >>>> Either way, I agree that reusing CDIProvider >>>> is a must. There is no >>>> >>>> reason >>>> >>>> to define a new class for the same purpose. >>>> >>>> >>>> >>>> >>>> >>>> I expect that my changes in the CDI spec >>>> around this will state, along >>>> >>>> the >>>> >>>> lines of: >>>> >>>> >>>> >>>> To retrieve a CDIContainer to launch, do this: >>>> >>>> >>>> >>>> CDIContainer container = >>>> CDIContainerLocator.getCDIContainer(); >>>> >>>> container.initialize(); >>>> >>>> ... do work >>>> >>>> >>>> >>>> Once you want to shutdown the container, do this: >>>> >>>> >>>> >>>> container.shutdown(); >>>> >>>> >>>> >>>> (we may want to consider implementing >>>> AutoCloseable, an oversight on my >>>> >>>> part) >>>> >>>> >>>> >>>> and then later on >>>> >>>> >>>> >>>> - What happens if I call CDIContainerLocator >>>> in an app server >>>> >>>> >>>> >>>> - It throws an IllegalStateException. >>>> >>>> >>>> >>>> - The container provides no beans of type >>>> CDIContainer, it is managed >>>> >>>> outside of the CDI container. >>>> >>>> >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> John >>>> >>>>> >>>> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef >>>> Hartinger >>> > >>>> >>>>> wrote: >>>> >>>>>> >>>> >>>>>> Hi John, some thoughts: >>>> >>>>>> >>>> >>>>>> - instead of using BeanManager it makes more >>>> sense to me to return a >>>> >>>>>> CDI >>>> >>>>>> instance, which is a more user-friendly API >>>> (and it also exposes >>>> >>>>>> access to >>>> >>>>>> BeanManager) >>>> >>>>>> - is there a usecase for arbitrary keys of >>>> the "params" map or is >>>> >>>>>> Map sufficient? >>>> >>>>>> - if we could move the shutdown() method >>>> from CDIContainer to the >>>> >>>>>> actual >>>> >>>>>> container handle that we obtain from >>>> initialize(), that would look >>>> >>>>>> more >>>> >>>>>> object-oriented >>>> >>>>>> - what exactly is initialize() supposed to >>>> do? Is it supposed to start >>>> >>>>>> scanning the entire classpath for CDI beans? >>>> That could be a problem >>>> >>>>>> especially with spring-boot-like fat jars. I >>>> think we need an API to >>>> >>>>>> tell >>>> >>>>>> the container which classes / packages to >>>> consider. Something like >>>> >>>>>> Guice's >>>> >>>>>> binding API perhaps? >>>> >>>>>> >>>> >>>>>> - the proposal makes me wonder whether >>>> retrofitting this functionality >>>> >>>>>> to >>>> >>>>>> the CDI class wouldn't be a better option. >>>> It could look like: >>>> >>>>>> >>>> >>>>>> CDI container = CDI.initialize(); >>>> >>>>>> container.select(Foo.class).get(); >>>> >>>>>> container.shutdown(); >>>> >>>>>> >>>> >>>>>> compare it to: >>>> >>>>>> >>>> >>>>>> CDIContainer container = CDIContainerLoader. >>>> getCDIContainer(); >>>> >>>>>> BeanManager manager = container.initialize(); >>>> >>>>>> manager.getBeans(...); >>>> >>>>>> container.shutdown(manager); >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >>>> >>>>>> >>>> >>>>>> All, >>>> >>>>>> >>>> >>>>>> I have the updated API here, and wanted to >>>> solicit any final feedback >>>> >>>>>> before updating the google doc and spec pages. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c >>>> >>>>>> >>>> >>>>>> Let me know your thoughts. >>>> >>>>>> >>>> >>>>>> Thanks, >>>> >>>>>> >>>> >>>>>> John >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> _______________________________________________ >>>> >>>>>> cdi-dev mailing list >>>> >>>>>> cdi-dev at lists.jboss.org >>>> >>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>>>> >>>> >>>>>> Note that for all code provided on this >>>> list, the provider licenses >>>> >>>>>> the >>>> >>>>>> code under the Apache License, Version 2 >>>> >>>>>> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). >>>> For all other ideas >>>> >>>>>> provided on this list, the provider waives >>>> all patent and other >>>> >>>>>> intellectual >>>> >>>>>> property rights inherent in such information. >>>> >>>>>> >>>> >>>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> cdi-dev mailing list >>>> >>>> cdi-dev at lists.jboss.org >>>> >>>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> >>>> >>>> Note that for all code provided on this list, >>>> the provider licenses the >>>> >>>> code >>>> >>>> under the Apache License, Version 2 >>>> >>>> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). >>>> For all other ideas >>>> >>>> provided on this list, the provider waives all >>>> patent and other >>>> >>>> intellectual >>>> >>>> property rights inherent in such information. >>>> >> >>>> >> >>>> > >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider >>>> licenses the code under the Apache License, Version 2 >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all >>>> other ideas provided on this list, the provider waives all >>>> patent and other intellectual property rights inherent in such >>>> information. >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider >>> licenses the code under the Apache License, Version 2 >>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>> ideas provided on this list, the provider waives all patent and >>> other intellectual property rights inherent in such information. >>> >>> >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/ab469e06/attachment-0001.html From john.d.ament at gmail.com Wed Mar 4 06:24:14 2015 From: john.d.ament at gmail.com (John D. Ament) Date: Wed, 04 Mar 2015 11:24:14 +0000 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) References: <54DB1F2B.1020609@redhat.com> <54DC61D9.701@redhat.com> <54EECC20.6040600@redhat.com> <54EF396E.20805@redhat.com> <54F01720.3080802@redhat.com> <54F6CACD.6080507@redhat.com> Message-ID: This is actually based on what we discussed in one of the EG meetings http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-01-14-17.04.log.html John On Wed, Mar 4, 2015 at 4:05 AM Jozef Hartinger wrote: > Well it's nowhere given that we must have two separate interfaces for > this. We can combine the start/stop API with the existing one to provide an > application with a single reference representing the CDI container. > > > On 02/28/2015 07:05 PM, John D. Ament wrote: > > Maybe I'm misreading, but I don't see us adding another API to do the same > thing here - we're introducing new functionality. > > CDIContainer/Loader on startup/shutdown of the application > > CDI for runtime usage within the application to interact with the > container. > > John > > On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau > wrote: > >> sure I fully agree excepted I think introducing yet another API to do >> the same thing is not good so super tempting to skip it and wait for >> feedbacks rather than introducing it eagerly. >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-02-27 8:05 GMT+01:00 Jozef Hartinger : >> > My point is that from the application perspective, the user obtains one >> > container handle for eventual shutdown (CDIContainer) and then looks up >> a >> > different container handle (CDI) that they can use for real work >> (lookup / >> > event dispatch / etc.) It would be cleaner if the container gave away a >> > single handle that can do all of that. >> > >> > >> > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: >> > >> > Not sure I get how a CDI instance can help. >> > >> > But container.getBeanManager() sounds nice is not a shortcut for >> > CDI.current().getBm() otherwise it looks like duplication to me. >> > >> > Can we make container not contextual - dont think so? If so it makes >> sense >> > otherwise I fear it doesnt add much. >> > >> > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" a >> ?crit : >> >> >> >> I like the initialize + close() combination and the try-with-resources >> >> usage. >> >> What looks weird to me is that at line one you obtain a container >> handle: >> >> >> >> try (CDIContainer container = CDIContainer.newCDIContai... >> >> CDI.current().getBeanManager() ... >> >> >> >> and then at line two you call a static method to perform a container >> >> lookup :-/ >> >> >> >> An API that allows you to use the container handle you already got is >> way >> >> better IMO, e.g.: >> >> >> >> try (CDIContainer container = CDIContainer.newCDIContai... >> >> container.getBeanManager() >> >> >> >> If CDIContainer.newCDIContainer() returns an CDI instance or its >> subclass, >> >> we get this easily. >> >> >> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: >> >>> >> >>> Hi guys >> >>> >> >>> why note keeping it simple? >> >>> >> >>> try (CDIContainer container = CDIContainer.newCDIContainer(/* optional >> >>> map to configure vendor features */)) { >> >>> CDI.current().getBeanManager().... >> >>> } >> >>> >> >>> Not sure the point having initialize() + having shutdown = close >> >>> really makes the API more fluent and modern IMO. >> >>> >> >>> Also to be fully SE I guess provider() method would be needed even if >> >>> optional (SPI usage by default): >> >>> >> >>> try (CDIContainer container = >> >>> >> >>> >> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider").newCDIContainer()) >> >>> { >> >>> CDI.current().getBeanManager().... >> >>> } >> >>> >> >>> Finally I think having a kind of getInstance shortcut could be a plus >> for >> >>> SE: >> >>> >> >>> try (CDIContainer container = CDIContainer.newCDIContainer()) { >> >>> container.newInstance(MyAppRunner.class /* optional qualifiers >> */ >> >>> ).run(args); >> >>> } >> >>> >> >>> Using container to get an instance would create the instance and bind >> >>> it to the container lifecycle (mainly for predestroy) avoiding this >> >>> boilerplate code in all main which will surely only be used to launch >> >>> a soft. >> >>> >> >>> wdyt? >> >>> >> >>> >> >>> >> >>> Romain Manni-Bucau >> >>> @rmannibucau >> >>> http://www.tomitribe.com >> >>> http://rmannibucau.wordpress.com >> >>> https://github.com/rmannibucau >> >>> >> >>> >> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger : >> >>>> >> >>>> Comments inline >> >>>> >> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: >> >>>> >> >>>> Sorry Jozef, your email fell into the pits of google inbox's "smart >> >>>> sorting" >> >>>> features. >> >>>> >> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger > > >> >>>> wrote: >> >>>>> >> >>>>> Hi John, comments inline: >> >>>>> >> >>>>> >> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >> >>>>> >> >>>>> Jozef, >> >>>>> >> >>>>> Most of what you see there is taken from the original doc, since >> >>>>> everyone >> >>>>> seemed to be in agreement. I think the map is just a safeguard in >> case >> >>>>> of >> >>>>> additional boot options available in some implementations (e.g. I >> think >> >>>>> OWB/OpenEJB have some options.. currently OpenEJB supports an >> embedded >> >>>>> CDI >> >>>>> boot mode). >> >>>>> >> >>>>> No, I am fine with the map. What I am questioning is the type of the >> >>>>> map. >> >>>>> Usually, data structures with a similar purpose use Strings as their >> >>>>> keys. >> >>>>> This applies to ServletContext attributes, InvocationContext data, >> >>>>> Servlet >> >>>>> request/session attributes and others. I am therefore wondering >> whether >> >>>>> there is a usecase for the proposed unbound key signature or not. >> >>>> >> >>>> >> >>>> I think that's more of a placeholder, I was assuming it would be >> >>>> Map once we clarify everything. >> >>>> >> >>>>> >> >>>>> >> >>>>> We spoke a few times about BeanManager vs CDI. BeanManager was >> >>>>> preferable >> >>>>> since there's no easy way to get the the instance, CDI is easier to >> get >> >>>>> and >> >>>>> more aligned with how you would get it. Usually people expect the >> >>>>> BeanManager to be injected or available via JNDI, neither would be >> the >> >>>>> case >> >>>>> here. >> >>>>> >> >>>>> If CDI 2.0 targets Java SE then this container initialization API >> will >> >>>>> become something that ordinary application developers use to >> start/stop >> >>>>> CDI >> >>>>> in their applications. It therefore cannot be considered an SPI but >> >>>>> instead >> >>>>> should be something easy to use. On the other hand, BeanManager is >> >>>>> definitely an SPI. It is used in extension, frameworks and generally >> >>>>> for >> >>>>> integration. Not much by applications directly. Therefore, I don't >> see >> >>>>> how >> >>>>> the container bootstrap API and BeanManager fit together. IMO the >> >>>>> bootstrap >> >>>>> API should expose something that makes common tasks (obtaining a >> >>>>> contextual >> >>>>> reference and firing and event) easy, which the CDI class does. >> >>>>> >> >>>>> Plus do not forget that BeanManager can be obtained easily using >> >>>>> CDI.getBeanManager(). >> >>>> >> >>>> >> >>>> I'm not disagreeing. There's a few things I'd consider: >> >>>> >> >>>> - Is this mostly for new apps or existing? If existing, it's >> probably >> >>>> using >> >>>> some internal API, if new it can use whatever API we give. >> >>>> - I don't want to return void, we should give some kind of reference >> >>>> into >> >>>> the container when we're done booting. >> >>>> >> >>>> Agreed, we should not be returning void. >> >>>> >> >>>> - CDI is a one step retrievable reference, where as BeanManager is a >> two >> >>>> step reference. With that said, BeanManager makes more sense to >> return >> >>>> here. Another thought could be we invent some new class that has >> both, >> >>>> but >> >>>> that's really redundant. >> >>>> >> >>>> Why do you think BeanManager makes more sense here? Especially given >> the >> >>>> assumption that application code is going to call this init/shutdown >> >>>> API, I >> >>>> don't see BeanManager as making more sense. >> >>>> >> >>>> >> >>>>> >> >>>>> >> >>>>> Yes, this is the container start API. Sounds like you have some >> good >> >>>>> ideas for things like XML configuration or programmatic >> configuration, >> >>>>> both >> >>>>> of which are being tracked under separate tickets. One idea might >> be >> >>>>> for an >> >>>>> optional param in the map to control packages to scan/ignore, in >> that >> >>>>> map. >> >>>>> >> >>>>> I am wondering whether this configuration should be something >> optional >> >>>>> built on top of the bootstrap API or whether we should consider >> making >> >>>>> it >> >>>>> mandatory. Either way, we cannot add the bootstrap API to the spec >> >>>>> without >> >>>>> explicitly defining how it behaves. My implicit assumption of the >> >>>>> proposal >> >>>>> is that the container is supposed to scan the entire classpath for >> >>>>> explicit >> >>>>> or implicit bean archives (including e.g. rt.jar), discover beans, >> fire >> >>>>> extensions, etc. This worries me as this default behavior is far >> from >> >>>>> being >> >>>>> lightweight, which CDI for Java SE initially aimed to be. >> >>>> >> >>>> >> >>>> Yes, the spec must be updated to reflect the behavior of SE mode. I >> >>>> plan to >> >>>> get that completely into the google doc before opening any spec >> changes >> >>>> in a >> >>>> PR. >> >>>> >> >>>>> >> >>>>> >> >>>>> We didn't want to over load the CDI interface. It already does a >> lot. >> >>>>> This is really SPI code, CDI even though it's in the spi package is >> >>>>> used in >> >>>>> a lot of application code. >> >>>>> >> >>>>> I would personally prefer to have it all in one place. Having >> >>>>> CDIContainer, CDIContainerLoader, CDI and CDIProvider makes it more >> >>>>> difficult to know when to use what. >> >>>> >> >>>> >> >>>> The problem is that most CDI (the interface) operations are against a >> >>>> running container. I think we spoke about leveraging CDIProvider at >> one >> >>>> point (in fact, I mistakenly called CDIContainer CDIProvider not even >> >>>> realizing it was there). I doubt that most app developers use it >> >>>> currently, >> >>>> there's not even a way to get a reference to it that I'm aware of. >> It's >> >>>> used by the implementor only. >> >>>> >> >>>> I don't think there's a conflict. CDI class would still only provide >> >>>> methods >> >>>> to be run against a running container. The difference is that there >> >>>> would be >> >>>> additional static methods to get this running container (CDI class) >> to >> >>>> you >> >>>> by starting the container. >> >>>> >> >>>> Either way, I agree that reusing CDIProvider is a must. There is no >> >>>> reason >> >>>> to define a new class for the same purpose. >> >>>> >> >>>> >> >>>> I expect that my changes in the CDI spec around this will state, >> along >> >>>> the >> >>>> lines of: >> >>>> >> >>>> To retrieve a CDIContainer to launch, do this: >> >>>> >> >>>> CDIContainer container = CDIContainerLocator.getCDIContainer(); >> >>>> container.initialize(); >> >>>> ... do work >> >>>> >> >>>> Once you want to shutdown the container, do this: >> >>>> >> >>>> container.shutdown(); >> >>>> >> >>>> (we may want to consider implementing AutoCloseable, an oversight on >> my >> >>>> part) >> >>>> >> >>>> and then later on >> >>>> >> >>>> - What happens if I call CDIContainerLocator in an app server >> >>>> >> >>>> - It throws an IllegalStateException. >> >>>> >> >>>> - The container provides no beans of type CDIContainer, it is managed >> >>>> outside of the CDI container. >> >>>> >> >>>> >> >>>>> >> >>>>> >> >>>>> John >> >>>>> >> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger < >> jharting at redhat.com> >> >>>>> wrote: >> >>>>>> >> >>>>>> Hi John, some thoughts: >> >>>>>> >> >>>>>> - instead of using BeanManager it makes more sense to me to return >> a >> >>>>>> CDI >> >>>>>> instance, which is a more user-friendly API (and it also exposes >> >>>>>> access to >> >>>>>> BeanManager) >> >>>>>> - is there a usecase for arbitrary keys of the "params" map or is >> >>>>>> Map sufficient? >> >>>>>> - if we could move the shutdown() method from CDIContainer to the >> >>>>>> actual >> >>>>>> container handle that we obtain from initialize(), that would look >> >>>>>> more >> >>>>>> object-oriented >> >>>>>> - what exactly is initialize() supposed to do? Is it supposed to >> start >> >>>>>> scanning the entire classpath for CDI beans? That could be a >> problem >> >>>>>> especially with spring-boot-like fat jars. I think we need an API >> to >> >>>>>> tell >> >>>>>> the container which classes / packages to consider. Something like >> >>>>>> Guice's >> >>>>>> binding API perhaps? >> >>>>>> >> >>>>>> - the proposal makes me wonder whether retrofitting this >> functionality >> >>>>>> to >> >>>>>> the CDI class wouldn't be a better option. It could look like: >> >>>>>> >> >>>>>> CDI container = CDI.initialize(); >> >>>>>> container.select(Foo.class).get(); >> >>>>>> container.shutdown(); >> >>>>>> >> >>>>>> compare it to: >> >>>>>> >> >>>>>> CDIContainer container = CDIContainerLoader. getCDIContainer(); >> >>>>>> BeanManager manager = container.initialize(); >> >>>>>> manager.getBeans(...); >> >>>>>> container.shutdown(manager); >> >>>>>> >> >>>>>> >> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >> >>>>>> >> >>>>>> All, >> >>>>>> >> >>>>>> I have the updated API here, and wanted to solicit any final >> feedback >> >>>>>> before updating the google doc and spec pages. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c >> >>>>>> >> >>>>>> Let me know your thoughts. >> >>>>>> >> >>>>>> Thanks, >> >>>>>> >> >>>>>> John >> >>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> cdi-dev mailing list >> >>>>>> cdi-dev at lists.jboss.org >> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >>>>>> >> >>>>>> Note that for all code provided on this list, the provider licenses >> >>>>>> the >> >>>>>> code under the Apache License, Version 2 >> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >> ideas >> >>>>>> provided on this list, the provider waives all patent and other >> >>>>>> intellectual >> >>>>>> property rights inherent in such information. >> >>>>>> >> >>>>>> >> >>>> >> >>>> _______________________________________________ >> >>>> cdi-dev mailing list >> >>>> cdi-dev at lists.jboss.org >> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >>>> >> >>>> Note that for all code provided on this list, the provider licenses >> the >> >>>> code >> >>>> under the Apache License, Version 2 >> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >> ideas >> >>>> provided on this list, the provider waives all patent and other >> >>>> intellectual >> >>>> property rights inherent in such information. >> >> >> >> >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/ec0f2db3/attachment-0001.html From john.d.ament at gmail.com Wed Mar 4 06:29:33 2015 From: john.d.ament at gmail.com (John D. Ament) Date: Wed, 04 Mar 2015 11:29:33 +0000 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) Message-ID: Hmm.. comments in line. On Wed, Mar 4, 2015 at 4:49 AM Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi John, > > I think it could be a good idea to write down all of these to have a more > stable doc for discussion. You should update the google doc with the result > of this discussion. > > I agree with the following points in this thread : > > - Minimize the number of new Class / Interface. CDI and CDIProvider usage > is still not very clear for end user so we should add the strict minimum > and try to enhance existing API / SPI when possible > It seems odd to me that we're rehashing decisions made during the EG meetings. Not putting it in CDI was discussed in several meetings at the beginning of the year, and it seemed like the agreement was putting it in CDI was a bad idea. > - Be able to bootstrap CDI without returning BeanManager (env if the API > give possibility to access it if needed). End user don?t need that : CDI > app can start with an observer for instance > Agreed, but I think we need to provide some entry point to allow those who aren't comfortable with programming with events to leverage it. Returning the CDI instance makes that easier to do than returning the BeanManager. > > Something not dealt with but that we should keep in mind : > - Providing a Java SE solution that could be easily used for a servlet > bootstrap of CDI. I don?t know if we?ll standardize this but we definitely > should keep this use case in mind > > and my bonus, it?s out of scope but I didn?t see anytime there that > prevent this nice to have: > - support the possibility to boot multiple BeanManager in Java SE. > > We talked about this one as well on the EG, either this year or late last year. I thought the decision at that time was that we wouldn't allow multiple containers at once in SE. > Antoine > > > Le 1 mars 2015 ? 15:13, John D. Ament a ?crit : > > > So, I think I've gathered enough feedback at this point, and seen some of > the API changes. I'll hopefully be including some doc changes this week, > but one question - do we want to start the SE specific stuff as its own > asciidoc file? > > Changes made: > > - Changed return value to CDI to provide better capability out of > the box. > - Added AutoCloseable to CDIContainer, provided default implementation of > calling shutdown. > - Added synchronization support to the method body that retrieves the > singleton instance (BTW, I'm not sure if this is even useful TBH as each > impl, including the RI, needs to provide this class in its own format). > - Made the params map typed to > > @Romain Your case isn't really supportable yet, until we have static > injection support. You'd still have to have a managed version of Runner to > work against. > > John > > On Sat, Feb 28, 2015 at 4:11 PM Romain Manni-Bucau > wrote: > >> Yes but not the way to get an instance. Even Unmanaged does it. >> >> What can be awesome is to have static inject for it: >> >> public class Runner { >> >> @Inject >> private static MyMain main; >> >> public static void main(String[] arg) { >> try (CDIContainer c = CDIContainer.newContainer()) { >> main.doWork(); >> } >> } >> >> } >> >> And not a single additional line :). >> Le 28 f?vr. 2015 19:05, "John D. Ament" a >> ?crit : >> >> Maybe I'm misreading, but I don't see us adding another API to do the >>> same thing here - we're introducing new functionality. >>> >>> CDIContainer/Loader on startup/shutdown of the application >>> >>> CDI for runtime usage within the application to interact with the >>> container. >>> >>> John >>> >>> On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau < >>> rmannibucau at gmail.com> wrote: >>> >>>> sure I fully agree excepted I think introducing yet another API to do >>>> the same thing is not good so super tempting to skip it and wait for >>>> feedbacks rather than introducing it eagerly. >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau >>>> http://www.tomitribe.com >>>> http://rmannibucau.wordpress.com >>>> https://github.com/rmannibucau >>>> >>>> >>>> 2015-02-27 8:05 GMT+01:00 Jozef Hartinger : >>>> > My point is that from the application perspective, the user obtains >>>> one >>>> > container handle for eventual shutdown (CDIContainer) and then looks >>>> up a >>>> > different container handle (CDI) that they can use for real work >>>> (lookup / >>>> > event dispatch / etc.) It would be cleaner if the container gave away >>>> a >>>> > single handle that can do all of that. >>>> > >>>> > >>>> > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: >>>> > >>>> > Not sure I get how a CDI instance can help. >>>> > >>>> > But container.getBeanManager() sounds nice is not a shortcut for >>>> > CDI.current().getBm() otherwise it looks like duplication to me. >>>> > >>>> > Can we make container not contextual - dont think so? If so it makes >>>> sense >>>> > otherwise I fear it doesnt add much. >>>> > >>>> > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" a >>>> ?crit : >>>> >> >>>> >> I like the initialize + close() combination and the >>>> try-with-resources >>>> >> usage. >>>> >> What looks weird to me is that at line one you obtain a container >>>> handle: >>>> >> >>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>> >> CDI.current().getBeanManager() ... >>>> >> >>>> >> and then at line two you call a static method to perform a container >>>> >> lookup :-/ >>>> >> >>>> >> An API that allows you to use the container handle you already got >>>> is way >>>> >> better IMO, e.g.: >>>> >> >>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>> >> container.getBeanManager() >>>> >> >>>> >> If CDIContainer.newCDIContainer() returns an CDI instance or its >>>> subclass, >>>> >> we get this easily. >>>> >> >>>> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: >>>> >>> >>>> >>> Hi guys >>>> >>> >>>> >>> why note keeping it simple? >>>> >>> >>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer(/* >>>> optional >>>> >>> map to configure vendor features */)) { >>>> >>> CDI.current().getBeanManager().... >>>> >>> } >>>> >>> >>>> >>> Not sure the point having initialize() + having shutdown = close >>>> >>> really makes the API more fluent and modern IMO. >>>> >>> >>>> >>> Also to be fully SE I guess provider() method would be needed even >>>> if >>>> >>> optional (SPI usage by default): >>>> >>> >>>> >>> try (CDIContainer container = >>>> >>> >>>> >>> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider"). >>>> newCDIContainer()) >>>> >>> { >>>> >>> CDI.current().getBeanManager().... >>>> >>> } >>>> >>> >>>> >>> Finally I think having a kind of getInstance shortcut could be a >>>> plus for >>>> >>> SE: >>>> >>> >>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer()) { >>>> >>> container.newInstance(MyAppRunner.class /* optional >>>> qualifiers */ >>>> >>> ).run(args); >>>> >>> } >>>> >>> >>>> >>> Using container to get an instance would create the instance and >>>> bind >>>> >>> it to the container lifecycle (mainly for predestroy) avoiding this >>>> >>> boilerplate code in all main which will surely only be used to >>>> launch >>>> >>> a soft. >>>> >>> >>>> >>> wdyt? >>>> >>> >>>> >>> >>>> >>> >>>> >>> Romain Manni-Bucau >>>> >>> @rmannibucau >>>> >>> http://www.tomitribe.com >>>> >>> http://rmannibucau.wordpress.com >>>> >>> https://github.com/rmannibucau >>>> >>> >>>> >>> >>>> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger : >>>> >>>> >>>> >>>> Comments inline >>>> >>>> >>>> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: >>>> >>>> >>>> >>>> Sorry Jozef, your email fell into the pits of google inbox's "smart >>>> >>>> sorting" >>>> >>>> features. >>>> >>>> >>>> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger < >>>> jharting at redhat.com> >>>> >>>> wrote: >>>> >>>>> >>>> >>>>> Hi John, comments inline: >>>> >>>>> >>>> >>>>> >>>> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >>>> >>>>> >>>> >>>>> Jozef, >>>> >>>>> >>>> >>>>> Most of what you see there is taken from the original doc, since >>>> >>>>> everyone >>>> >>>>> seemed to be in agreement. I think the map is just a safeguard >>>> in case >>>> >>>>> of >>>> >>>>> additional boot options available in some implementations (e.g. I >>>> think >>>> >>>>> OWB/OpenEJB have some options.. currently OpenEJB supports an >>>> embedded >>>> >>>>> CDI >>>> >>>>> boot mode). >>>> >>>>> >>>> >>>>> No, I am fine with the map. What I am questioning is the type of >>>> the >>>> >>>>> map. >>>> >>>>> Usually, data structures with a similar purpose use Strings as >>>> their >>>> >>>>> keys. >>>> >>>>> This applies to ServletContext attributes, InvocationContext data, >>>> >>>>> Servlet >>>> >>>>> request/session attributes and others. I am therefore wondering >>>> whether >>>> >>>>> there is a usecase for the proposed unbound key signature or not. >>>> >>>> >>>> >>>> >>>> >>>> I think that's more of a placeholder, I was assuming it would be >>>> >>>> Map once we clarify everything. >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> We spoke a few times about BeanManager vs CDI. BeanManager was >>>> >>>>> preferable >>>> >>>>> since there's no easy way to get the the instance, CDI is easier >>>> to get >>>> >>>>> and >>>> >>>>> more aligned with how you would get it. Usually people expect the >>>> >>>>> BeanManager to be injected or available via JNDI, neither would >>>> be the >>>> >>>>> case >>>> >>>>> here. >>>> >>>>> >>>> >>>>> If CDI 2.0 targets Java SE then this container initialization API >>>> will >>>> >>>>> become something that ordinary application developers use to >>>> start/stop >>>> >>>>> CDI >>>> >>>>> in their applications. It therefore cannot be considered an SPI >>>> but >>>> >>>>> instead >>>> >>>>> should be something easy to use. On the other hand, BeanManager is >>>> >>>>> definitely an SPI. It is used in extension, frameworks and >>>> generally >>>> >>>>> for >>>> >>>>> integration. Not much by applications directly. Therefore, I >>>> don't see >>>> >>>>> how >>>> >>>>> the container bootstrap API and BeanManager fit together. IMO the >>>> >>>>> bootstrap >>>> >>>>> API should expose something that makes common tasks (obtaining a >>>> >>>>> contextual >>>> >>>>> reference and firing and event) easy, which the CDI class does. >>>> >>>>> >>>> >>>>> Plus do not forget that BeanManager can be obtained easily using >>>> >>>>> CDI.getBeanManager(). >>>> >>>> >>>> >>>> >>>> >>>> I'm not disagreeing. There's a few things I'd consider: >>>> >>>> >>>> >>>> - Is this mostly for new apps or existing? If existing, it's >>>> probably >>>> >>>> using >>>> >>>> some internal API, if new it can use whatever API we give. >>>> >>>> - I don't want to return void, we should give some kind of >>>> reference >>>> >>>> into >>>> >>>> the container when we're done booting. >>>> >>>> >>>> >>>> Agreed, we should not be returning void. >>>> >>>> >>>> >>>> - CDI is a one step retrievable reference, where as BeanManager is >>>> a two >>>> >>>> step reference. With that said, BeanManager makes more sense to >>>> return >>>> >>>> here. Another thought could be we invent some new class that has >>>> both, >>>> >>>> but >>>> >>>> that's really redundant. >>>> >>>> >>>> >>>> Why do you think BeanManager makes more sense here? Especially >>>> given the >>>> >>>> assumption that application code is going to call this >>>> init/shutdown >>>> >>>> API, I >>>> >>>> don't see BeanManager as making more sense. >>>> >>>> >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> Yes, this is the container start API. Sounds like you have some >>>> good >>>> >>>>> ideas for things like XML configuration or programmatic >>>> configuration, >>>> >>>>> both >>>> >>>>> of which are being tracked under separate tickets. One idea >>>> might be >>>> >>>>> for an >>>> >>>>> optional param in the map to control packages to scan/ignore, in >>>> that >>>> >>>>> map. >>>> >>>>> >>>> >>>>> I am wondering whether this configuration should be something >>>> optional >>>> >>>>> built on top of the bootstrap API or whether we should consider >>>> making >>>> >>>>> it >>>> >>>>> mandatory. Either way, we cannot add the bootstrap API to the spec >>>> >>>>> without >>>> >>>>> explicitly defining how it behaves. My implicit assumption of the >>>> >>>>> proposal >>>> >>>>> is that the container is supposed to scan the entire classpath for >>>> >>>>> explicit >>>> >>>>> or implicit bean archives (including e.g. rt.jar), discover >>>> beans, fire >>>> >>>>> extensions, etc. This worries me as this default behavior is far >>>> from >>>> >>>>> being >>>> >>>>> lightweight, which CDI for Java SE initially aimed to be. >>>> >>>> >>>> >>>> >>>> >>>> Yes, the spec must be updated to reflect the behavior of SE mode. >>>> I >>>> >>>> plan to >>>> >>>> get that completely into the google doc before opening any spec >>>> changes >>>> >>>> in a >>>> >>>> PR. >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> We didn't want to over load the CDI interface. It already does a >>>> lot. >>>> >>>>> This is really SPI code, CDI even though it's in the spi package >>>> is >>>> >>>>> used in >>>> >>>>> a lot of application code. >>>> >>>>> >>>> >>>>> I would personally prefer to have it all in one place. Having >>>> >>>>> CDIContainer, CDIContainerLoader, CDI and CDIProvider makes it >>>> more >>>> >>>>> difficult to know when to use what. >>>> >>>> >>>> >>>> >>>> >>>> The problem is that most CDI (the interface) operations are >>>> against a >>>> >>>> running container. I think we spoke about leveraging CDIProvider >>>> at one >>>> >>>> point (in fact, I mistakenly called CDIContainer CDIProvider not >>>> even >>>> >>>> realizing it was there). I doubt that most app developers use it >>>> >>>> currently, >>>> >>>> there's not even a way to get a reference to it that I'm aware >>>> of. It's >>>> >>>> used by the implementor only. >>>> >>>> >>>> >>>> I don't think there's a conflict. CDI class would still only >>>> provide >>>> >>>> methods >>>> >>>> to be run against a running container. The difference is that there >>>> >>>> would be >>>> >>>> additional static methods to get this running container (CDI >>>> class) to >>>> >>>> you >>>> >>>> by starting the container. >>>> >>>> >>>> >>>> Either way, I agree that reusing CDIProvider is a must. There is no >>>> >>>> reason >>>> >>>> to define a new class for the same purpose. >>>> >>>> >>>> >>>> >>>> >>>> I expect that my changes in the CDI spec around this will state, >>>> along >>>> >>>> the >>>> >>>> lines of: >>>> >>>> >>>> >>>> To retrieve a CDIContainer to launch, do this: >>>> >>>> >>>> >>>> CDIContainer container = CDIContainerLocator.getCDIContainer(); >>>> >>>> container.initialize(); >>>> >>>> ... do work >>>> >>>> >>>> >>>> Once you want to shutdown the container, do this: >>>> >>>> >>>> >>>> container.shutdown(); >>>> >>>> >>>> >>>> (we may want to consider implementing AutoCloseable, an oversight >>>> on my >>>> >>>> part) >>>> >>>> >>>> >>>> and then later on >>>> >>>> >>>> >>>> - What happens if I call CDIContainerLocator in an app server >>>> >>>> >>>> >>>> - It throws an IllegalStateException. >>>> >>>> >>>> >>>> - The container provides no beans of type CDIContainer, it is >>>> managed >>>> >>>> outside of the CDI container. >>>> >>>> >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> John >>>> >>>>> >>>> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger < >>>> jharting at redhat.com> >>>> >>>>> wrote: >>>> >>>>>> >>>> >>>>>> Hi John, some thoughts: >>>> >>>>>> >>>> >>>>>> - instead of using BeanManager it makes more sense to me to >>>> return a >>>> >>>>>> CDI >>>> >>>>>> instance, which is a more user-friendly API (and it also exposes >>>> >>>>>> access to >>>> >>>>>> BeanManager) >>>> >>>>>> - is there a usecase for arbitrary keys of the "params" map or is >>>> >>>>>> Map sufficient? >>>> >>>>>> - if we could move the shutdown() method from CDIContainer to the >>>> >>>>>> actual >>>> >>>>>> container handle that we obtain from initialize(), that would >>>> look >>>> >>>>>> more >>>> >>>>>> object-oriented >>>> >>>>>> - what exactly is initialize() supposed to do? Is it supposed to >>>> start >>>> >>>>>> scanning the entire classpath for CDI beans? That could be a >>>> problem >>>> >>>>>> especially with spring-boot-like fat jars. I think we need an >>>> API to >>>> >>>>>> tell >>>> >>>>>> the container which classes / packages to consider. Something >>>> like >>>> >>>>>> Guice's >>>> >>>>>> binding API perhaps? >>>> >>>>>> >>>> >>>>>> - the proposal makes me wonder whether retrofitting this >>>> functionality >>>> >>>>>> to >>>> >>>>>> the CDI class wouldn't be a better option. It could look like: >>>> >>>>>> >>>> >>>>>> CDI container = CDI.initialize(); >>>> >>>>>> container.select(Foo.class).get(); >>>> >>>>>> container.shutdown(); >>>> >>>>>> >>>> >>>>>> compare it to: >>>> >>>>>> >>>> >>>>>> CDIContainer container = CDIContainerLoader. getCDIContainer(); >>>> >>>>>> BeanManager manager = container.initialize(); >>>> >>>>>> manager.getBeans(...); >>>> >>>>>> container.shutdown(manager); >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >>>> >>>>>> >>>> >>>>>> All, >>>> >>>>>> >>>> >>>>>> I have the updated API here, and wanted to solicit any final >>>> feedback >>>> >>>>>> before updating the google doc and spec pages. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> https://github.com/johnament/cdi/commit/2c362161e18dd521f8e8 >>>> 3c27151ddad467a1c01c >>>> >>>>>> >>>> >>>>>> Let me know your thoughts. >>>> >>>>>> >>>> >>>>>> Thanks, >>>> >>>>>> >>>> >>>>>> John >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> _______________________________________________ >>>> >>>>>> cdi-dev mailing list >>>> >>>>>> cdi-dev at lists.jboss.org >>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>>>> >>>> >>>>>> Note that for all code provided on this list, the provider >>>> licenses >>>> >>>>>> the >>>> >>>>>> code under the Apache License, Version 2 >>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all >>>> other ideas >>>> >>>>>> provided on this list, the provider waives all patent and other >>>> >>>>>> intellectual >>>> >>>>>> property rights inherent in such information. >>>> >>>>>> >>>> >>>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> cdi-dev mailing list >>>> >>>> cdi-dev at lists.jboss.org >>>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> >>>> >>>> Note that for all code provided on this list, the provider >>>> licenses the >>>> >>>> code >>>> >>>> under the Apache License, Version 2 >>>> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>>> ideas >>>> >>>> provided on this list, the provider waives all patent and other >>>> >>>> intellectual >>>> >>>> property rights inherent in such information. >>>> >> >>>> >> >>>> > >>>> >>> _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 (http://www.apache.org/ > licenses/LICENSE-2.0.html). For all other ideas provided on this list, > the provider waives all patent and other intellectual property rights > inherent in such information. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/d6ecd4ae/attachment-0001.html From rmannibucau at gmail.com Wed Mar 4 06:34:50 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 4 Mar 2015 12:34:50 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: References: Message-ID: 2015-03-04 12:29 GMT+01:00 John D. Ament : > Hmm.. comments in line. > > On Wed, Mar 4, 2015 at 4:49 AM Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > >> Hi John, >> >> I think it could be a good idea to write down all of these to have a more >> stable doc for discussion. You should update the google doc with the result >> of this discussion. >> >> I agree with the following points in this thread : >> >> - Minimize the number of new Class / Interface. CDI and CDIProvider usage >> is still not very clear for end user so we should add the strict minimum >> and try to enhance existing API / SPI when possible >> > > It seems odd to me that we're rehashing decisions made during the EG > meetings. Not putting it in CDI was discussed in several meetings at the > beginning of the year, and it seemed like the agreement was putting it in > CDI was a bad idea. > > >> - Be able to bootstrap CDI without returning BeanManager (env if the API >> give possibility to access it if needed). End user don?t need that : CDI >> app can start with an observer for instance >> > > Agreed, but I think we need to provide some entry point to allow those who > aren't comfortable with programming with events to leverage it. Returning > the CDI instance makes that easier to do than returning the BeanManager. > > Can you detail it please? CDI value is only its getBeanManager() method IMO so it sounds like it is 1-1 for me. > >> Something not dealt with but that we should keep in mind : >> - Providing a Java SE solution that could be easily used for a servlet >> bootstrap of CDI. I don?t know if we?ll standardize this but we definitely >> should keep this use case in mind >> >> and my bonus, it?s out of scope but I didn?t see anytime there that >> prevent this nice to have: >> - support the possibility to boot multiple BeanManager in Java SE. >> >> > We talked about this one as well on the EG, either this year or late last > year. I thought the decision at that time was that we wouldn't allow > multiple containers at once in SE. > > wouldn't specify rather than wouldn't allow I think > Antoine >> >> >> Le 1 mars 2015 ? 15:13, John D. Ament a ?crit : >> >> >> So, I think I've gathered enough feedback at this point, and seen some of >> the API changes. I'll hopefully be including some doc changes this week, >> but one question - do we want to start the SE specific stuff as its own >> asciidoc file? >> >> Changes made: >> >> - Changed return value to CDI to provide better capability out of >> the box. >> - Added AutoCloseable to CDIContainer, provided default implementation of >> calling shutdown. >> - Added synchronization support to the method body that retrieves the >> singleton instance (BTW, I'm not sure if this is even useful TBH as each >> impl, including the RI, needs to provide this class in its own format). >> - Made the params map typed to >> >> @Romain Your case isn't really supportable yet, until we have static >> injection support. You'd still have to have a managed version of Runner to >> work against. >> >> John >> >> On Sat, Feb 28, 2015 at 4:11 PM Romain Manni-Bucau >> wrote: >> >>> Yes but not the way to get an instance. Even Unmanaged does it. >>> >>> What can be awesome is to have static inject for it: >>> >>> public class Runner { >>> >>> @Inject >>> private static MyMain main; >>> >>> public static void main(String[] arg) { >>> try (CDIContainer c = CDIContainer.newContainer()) { >>> main.doWork(); >>> } >>> } >>> >>> } >>> >>> And not a single additional line :). >>> Le 28 f?vr. 2015 19:05, "John D. Ament" a >>> ?crit : >>> >>> Maybe I'm misreading, but I don't see us adding another API to do the >>>> same thing here - we're introducing new functionality. >>>> >>>> CDIContainer/Loader on startup/shutdown of the application >>>> >>>> CDI for runtime usage within the application to interact with the >>>> container. >>>> >>>> John >>>> >>>> On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau < >>>> rmannibucau at gmail.com> wrote: >>>> >>>>> sure I fully agree excepted I think introducing yet another API to do >>>>> the same thing is not good so super tempting to skip it and wait for >>>>> feedbacks rather than introducing it eagerly. >>>>> >>>>> >>>>> Romain Manni-Bucau >>>>> @rmannibucau >>>>> http://www.tomitribe.com >>>>> http://rmannibucau.wordpress.com >>>>> https://github.com/rmannibucau >>>>> >>>>> >>>>> 2015-02-27 8:05 GMT+01:00 Jozef Hartinger : >>>>> > My point is that from the application perspective, the user obtains >>>>> one >>>>> > container handle for eventual shutdown (CDIContainer) and then looks >>>>> up a >>>>> > different container handle (CDI) that they can use for real work >>>>> (lookup / >>>>> > event dispatch / etc.) It would be cleaner if the container gave >>>>> away a >>>>> > single handle that can do all of that. >>>>> > >>>>> > >>>>> > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: >>>>> > >>>>> > Not sure I get how a CDI instance can help. >>>>> > >>>>> > But container.getBeanManager() sounds nice is not a shortcut for >>>>> > CDI.current().getBm() otherwise it looks like duplication to me. >>>>> > >>>>> > Can we make container not contextual - dont think so? If so it makes >>>>> sense >>>>> > otherwise I fear it doesnt add much. >>>>> > >>>>> > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" a >>>>> ?crit : >>>>> >> >>>>> >> I like the initialize + close() combination and the >>>>> try-with-resources >>>>> >> usage. >>>>> >> What looks weird to me is that at line one you obtain a container >>>>> handle: >>>>> >> >>>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>>> >> CDI.current().getBeanManager() ... >>>>> >> >>>>> >> and then at line two you call a static method to perform a container >>>>> >> lookup :-/ >>>>> >> >>>>> >> An API that allows you to use the container handle you already got >>>>> is way >>>>> >> better IMO, e.g.: >>>>> >> >>>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>>> >> container.getBeanManager() >>>>> >> >>>>> >> If CDIContainer.newCDIContainer() returns an CDI instance or its >>>>> subclass, >>>>> >> we get this easily. >>>>> >> >>>>> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: >>>>> >>> >>>>> >>> Hi guys >>>>> >>> >>>>> >>> why note keeping it simple? >>>>> >>> >>>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer(/* >>>>> optional >>>>> >>> map to configure vendor features */)) { >>>>> >>> CDI.current().getBeanManager().... >>>>> >>> } >>>>> >>> >>>>> >>> Not sure the point having initialize() + having shutdown = close >>>>> >>> really makes the API more fluent and modern IMO. >>>>> >>> >>>>> >>> Also to be fully SE I guess provider() method would be needed even >>>>> if >>>>> >>> optional (SPI usage by default): >>>>> >>> >>>>> >>> try (CDIContainer container = >>>>> >>> >>>>> >>> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider"). >>>>> newCDIContainer()) >>>>> >>> { >>>>> >>> CDI.current().getBeanManager().... >>>>> >>> } >>>>> >>> >>>>> >>> Finally I think having a kind of getInstance shortcut could be a >>>>> plus for >>>>> >>> SE: >>>>> >>> >>>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer()) { >>>>> >>> container.newInstance(MyAppRunner.class /* optional >>>>> qualifiers */ >>>>> >>> ).run(args); >>>>> >>> } >>>>> >>> >>>>> >>> Using container to get an instance would create the instance and >>>>> bind >>>>> >>> it to the container lifecycle (mainly for predestroy) avoiding this >>>>> >>> boilerplate code in all main which will surely only be used to >>>>> launch >>>>> >>> a soft. >>>>> >>> >>>>> >>> wdyt? >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> Romain Manni-Bucau >>>>> >>> @rmannibucau >>>>> >>> http://www.tomitribe.com >>>>> >>> http://rmannibucau.wordpress.com >>>>> >>> https://github.com/rmannibucau >>>>> >>> >>>>> >>> >>>>> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger : >>>>> >>>> >>>>> >>>> Comments inline >>>>> >>>> >>>>> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: >>>>> >>>> >>>>> >>>> Sorry Jozef, your email fell into the pits of google inbox's >>>>> "smart >>>>> >>>> sorting" >>>>> >>>> features. >>>>> >>>> >>>>> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger < >>>>> jharting at redhat.com> >>>>> >>>> wrote: >>>>> >>>>> >>>>> >>>>> Hi John, comments inline: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >>>>> >>>>> >>>>> >>>>> Jozef, >>>>> >>>>> >>>>> >>>>> Most of what you see there is taken from the original doc, since >>>>> >>>>> everyone >>>>> >>>>> seemed to be in agreement. I think the map is just a safeguard >>>>> in case >>>>> >>>>> of >>>>> >>>>> additional boot options available in some implementations (e.g. >>>>> I think >>>>> >>>>> OWB/OpenEJB have some options.. currently OpenEJB supports an >>>>> embedded >>>>> >>>>> CDI >>>>> >>>>> boot mode). >>>>> >>>>> >>>>> >>>>> No, I am fine with the map. What I am questioning is the type of >>>>> the >>>>> >>>>> map. >>>>> >>>>> Usually, data structures with a similar purpose use Strings as >>>>> their >>>>> >>>>> keys. >>>>> >>>>> This applies to ServletContext attributes, InvocationContext >>>>> data, >>>>> >>>>> Servlet >>>>> >>>>> request/session attributes and others. I am therefore wondering >>>>> whether >>>>> >>>>> there is a usecase for the proposed unbound key signature or not. >>>>> >>>> >>>>> >>>> >>>>> >>>> I think that's more of a placeholder, I was assuming it would be >>>>> >>>> Map once we clarify everything. >>>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> We spoke a few times about BeanManager vs CDI. BeanManager was >>>>> >>>>> preferable >>>>> >>>>> since there's no easy way to get the the instance, CDI is easier >>>>> to get >>>>> >>>>> and >>>>> >>>>> more aligned with how you would get it. Usually people expect >>>>> the >>>>> >>>>> BeanManager to be injected or available via JNDI, neither would >>>>> be the >>>>> >>>>> case >>>>> >>>>> here. >>>>> >>>>> >>>>> >>>>> If CDI 2.0 targets Java SE then this container initialization >>>>> API will >>>>> >>>>> become something that ordinary application developers use to >>>>> start/stop >>>>> >>>>> CDI >>>>> >>>>> in their applications. It therefore cannot be considered an SPI >>>>> but >>>>> >>>>> instead >>>>> >>>>> should be something easy to use. On the other hand, BeanManager >>>>> is >>>>> >>>>> definitely an SPI. It is used in extension, frameworks and >>>>> generally >>>>> >>>>> for >>>>> >>>>> integration. Not much by applications directly. Therefore, I >>>>> don't see >>>>> >>>>> how >>>>> >>>>> the container bootstrap API and BeanManager fit together. IMO the >>>>> >>>>> bootstrap >>>>> >>>>> API should expose something that makes common tasks (obtaining a >>>>> >>>>> contextual >>>>> >>>>> reference and firing and event) easy, which the CDI class does. >>>>> >>>>> >>>>> >>>>> Plus do not forget that BeanManager can be obtained easily using >>>>> >>>>> CDI.getBeanManager(). >>>>> >>>> >>>>> >>>> >>>>> >>>> I'm not disagreeing. There's a few things I'd consider: >>>>> >>>> >>>>> >>>> - Is this mostly for new apps or existing? If existing, it's >>>>> probably >>>>> >>>> using >>>>> >>>> some internal API, if new it can use whatever API we give. >>>>> >>>> - I don't want to return void, we should give some kind of >>>>> reference >>>>> >>>> into >>>>> >>>> the container when we're done booting. >>>>> >>>> >>>>> >>>> Agreed, we should not be returning void. >>>>> >>>> >>>>> >>>> - CDI is a one step retrievable reference, where as BeanManager >>>>> is a two >>>>> >>>> step reference. With that said, BeanManager makes more sense to >>>>> return >>>>> >>>> here. Another thought could be we invent some new class that has >>>>> both, >>>>> >>>> but >>>>> >>>> that's really redundant. >>>>> >>>> >>>>> >>>> Why do you think BeanManager makes more sense here? Especially >>>>> given the >>>>> >>>> assumption that application code is going to call this >>>>> init/shutdown >>>>> >>>> API, I >>>>> >>>> don't see BeanManager as making more sense. >>>>> >>>> >>>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Yes, this is the container start API. Sounds like you have some >>>>> good >>>>> >>>>> ideas for things like XML configuration or programmatic >>>>> configuration, >>>>> >>>>> both >>>>> >>>>> of which are being tracked under separate tickets. One idea >>>>> might be >>>>> >>>>> for an >>>>> >>>>> optional param in the map to control packages to scan/ignore, in >>>>> that >>>>> >>>>> map. >>>>> >>>>> >>>>> >>>>> I am wondering whether this configuration should be something >>>>> optional >>>>> >>>>> built on top of the bootstrap API or whether we should consider >>>>> making >>>>> >>>>> it >>>>> >>>>> mandatory. Either way, we cannot add the bootstrap API to the >>>>> spec >>>>> >>>>> without >>>>> >>>>> explicitly defining how it behaves. My implicit assumption of the >>>>> >>>>> proposal >>>>> >>>>> is that the container is supposed to scan the entire classpath >>>>> for >>>>> >>>>> explicit >>>>> >>>>> or implicit bean archives (including e.g. rt.jar), discover >>>>> beans, fire >>>>> >>>>> extensions, etc. This worries me as this default behavior is far >>>>> from >>>>> >>>>> being >>>>> >>>>> lightweight, which CDI for Java SE initially aimed to be. >>>>> >>>> >>>>> >>>> >>>>> >>>> Yes, the spec must be updated to reflect the behavior of SE >>>>> mode. I >>>>> >>>> plan to >>>>> >>>> get that completely into the google doc before opening any spec >>>>> changes >>>>> >>>> in a >>>>> >>>> PR. >>>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> We didn't want to over load the CDI interface. It already does >>>>> a lot. >>>>> >>>>> This is really SPI code, CDI even though it's in the spi package >>>>> is >>>>> >>>>> used in >>>>> >>>>> a lot of application code. >>>>> >>>>> >>>>> >>>>> I would personally prefer to have it all in one place. Having >>>>> >>>>> CDIContainer, CDIContainerLoader, CDI and CDIProvider makes it >>>>> more >>>>> >>>>> difficult to know when to use what. >>>>> >>>> >>>>> >>>> >>>>> >>>> The problem is that most CDI (the interface) operations are >>>>> against a >>>>> >>>> running container. I think we spoke about leveraging CDIProvider >>>>> at one >>>>> >>>> point (in fact, I mistakenly called CDIContainer CDIProvider not >>>>> even >>>>> >>>> realizing it was there). I doubt that most app developers use it >>>>> >>>> currently, >>>>> >>>> there's not even a way to get a reference to it that I'm aware >>>>> of. It's >>>>> >>>> used by the implementor only. >>>>> >>>> >>>>> >>>> I don't think there's a conflict. CDI class would still only >>>>> provide >>>>> >>>> methods >>>>> >>>> to be run against a running container. The difference is that >>>>> there >>>>> >>>> would be >>>>> >>>> additional static methods to get this running container (CDI >>>>> class) to >>>>> >>>> you >>>>> >>>> by starting the container. >>>>> >>>> >>>>> >>>> Either way, I agree that reusing CDIProvider is a must. There is >>>>> no >>>>> >>>> reason >>>>> >>>> to define a new class for the same purpose. >>>>> >>>> >>>>> >>>> >>>>> >>>> I expect that my changes in the CDI spec around this will state, >>>>> along >>>>> >>>> the >>>>> >>>> lines of: >>>>> >>>> >>>>> >>>> To retrieve a CDIContainer to launch, do this: >>>>> >>>> >>>>> >>>> CDIContainer container = CDIContainerLocator.getCDIContainer(); >>>>> >>>> container.initialize(); >>>>> >>>> ... do work >>>>> >>>> >>>>> >>>> Once you want to shutdown the container, do this: >>>>> >>>> >>>>> >>>> container.shutdown(); >>>>> >>>> >>>>> >>>> (we may want to consider implementing AutoCloseable, an oversight >>>>> on my >>>>> >>>> part) >>>>> >>>> >>>>> >>>> and then later on >>>>> >>>> >>>>> >>>> - What happens if I call CDIContainerLocator in an app server >>>>> >>>> >>>>> >>>> - It throws an IllegalStateException. >>>>> >>>> >>>>> >>>> - The container provides no beans of type CDIContainer, it is >>>>> managed >>>>> >>>> outside of the CDI container. >>>>> >>>> >>>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> John >>>>> >>>>> >>>>> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger < >>>>> jharting at redhat.com> >>>>> >>>>> wrote: >>>>> >>>>>> >>>>> >>>>>> Hi John, some thoughts: >>>>> >>>>>> >>>>> >>>>>> - instead of using BeanManager it makes more sense to me to >>>>> return a >>>>> >>>>>> CDI >>>>> >>>>>> instance, which is a more user-friendly API (and it also exposes >>>>> >>>>>> access to >>>>> >>>>>> BeanManager) >>>>> >>>>>> - is there a usecase for arbitrary keys of the "params" map or >>>>> is >>>>> >>>>>> Map sufficient? >>>>> >>>>>> - if we could move the shutdown() method from CDIContainer to >>>>> the >>>>> >>>>>> actual >>>>> >>>>>> container handle that we obtain from initialize(), that would >>>>> look >>>>> >>>>>> more >>>>> >>>>>> object-oriented >>>>> >>>>>> - what exactly is initialize() supposed to do? Is it supposed >>>>> to start >>>>> >>>>>> scanning the entire classpath for CDI beans? That could be a >>>>> problem >>>>> >>>>>> especially with spring-boot-like fat jars. I think we need an >>>>> API to >>>>> >>>>>> tell >>>>> >>>>>> the container which classes / packages to consider. Something >>>>> like >>>>> >>>>>> Guice's >>>>> >>>>>> binding API perhaps? >>>>> >>>>>> >>>>> >>>>>> - the proposal makes me wonder whether retrofitting this >>>>> functionality >>>>> >>>>>> to >>>>> >>>>>> the CDI class wouldn't be a better option. It could look like: >>>>> >>>>>> >>>>> >>>>>> CDI container = CDI.initialize(); >>>>> >>>>>> container.select(Foo.class).get(); >>>>> >>>>>> container.shutdown(); >>>>> >>>>>> >>>>> >>>>>> compare it to: >>>>> >>>>>> >>>>> >>>>>> CDIContainer container = CDIContainerLoader. getCDIContainer(); >>>>> >>>>>> BeanManager manager = container.initialize(); >>>>> >>>>>> manager.getBeans(...); >>>>> >>>>>> container.shutdown(manager); >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >>>>> >>>>>> >>>>> >>>>>> All, >>>>> >>>>>> >>>>> >>>>>> I have the updated API here, and wanted to solicit any final >>>>> feedback >>>>> >>>>>> before updating the google doc and spec pages. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> https://github.com/johnament/cdi/commit/2c362161e18dd521f8e8 >>>>> 3c27151ddad467a1c01c >>>>> >>>>>> >>>>> >>>>>> Let me know your thoughts. >>>>> >>>>>> >>>>> >>>>>> Thanks, >>>>> >>>>>> >>>>> >>>>>> John >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> _______________________________________________ >>>>> >>>>>> cdi-dev mailing list >>>>> >>>>>> cdi-dev at lists.jboss.org >>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>>> >>>>> >>>>>> Note that for all code provided on this list, the provider >>>>> licenses >>>>> >>>>>> the >>>>> >>>>>> code under the Apache License, Version 2 >>>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all >>>>> other ideas >>>>> >>>>>> provided on this list, the provider waives all patent and other >>>>> >>>>>> intellectual >>>>> >>>>>> property rights inherent in such information. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>> >>>>> >>>> _______________________________________________ >>>>> >>>> cdi-dev mailing list >>>>> >>>> cdi-dev at lists.jboss.org >>>>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>> >>>>> >>>> Note that for all code provided on this list, the provider >>>>> licenses the >>>>> >>>> code >>>>> >>>> under the Apache License, Version 2 >>>>> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>>>> ideas >>>>> >>>> provided on this list, the provider waives all patent and other >>>>> >>>> intellectual >>>>> >>>> property rights inherent in such information. >>>>> >> >>>>> >> >>>>> > >>>>> >>>> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 (http://www.apache.org/ >> licenses/LICENSE-2.0.html). For all other ideas provided on this list, >> the provider waives all patent and other intellectual property rights >> inherent in such information. >> >> > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/9e96e919/attachment-0001.html From john.d.ament at gmail.com Wed Mar 4 06:37:59 2015 From: john.d.ament at gmail.com (John D. Ament) Date: Wed, 04 Mar 2015 11:37:59 +0000 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) References: Message-ID: On Wed, Mar 4, 2015 at 6:35 AM Romain Manni-Bucau wrote: > 2015-03-04 12:29 GMT+01:00 John D. Ament : > >> Hmm.. comments in line. >> >> On Wed, Mar 4, 2015 at 4:49 AM Antoine Sabot-Durand < >> antoine at sabot-durand.net> wrote: >> >>> Hi John, >>> >>> I think it could be a good idea to write down all of these to have a >>> more stable doc for discussion. You should update the google doc with the >>> result of this discussion. >>> >>> I agree with the following points in this thread : >>> >>> - Minimize the number of new Class / Interface. CDI and CDIProvider >>> usage is still not very clear for end user so we should add the strict >>> minimum and try to enhance existing API / SPI when possible >>> >> >> It seems odd to me that we're rehashing decisions made during the EG >> meetings. Not putting it in CDI was discussed in several meetings at the >> beginning of the year, and it seemed like the agreement was putting it in >> CDI was a bad idea. >> >> >>> - Be able to bootstrap CDI without returning BeanManager (env if the API >>> give possibility to access it if needed). End user don?t need that : CDI >>> app can start with an observer for instance >>> >> >> Agreed, but I think we need to provide some entry point to allow those >> who aren't comfortable with programming with events to leverage it. >> Returning the CDI instance makes that easier to do than returning the >> BeanManager. >> >> > > Can you detail it please? CDI value is only its getBeanManager() method > IMO so it sounds like it is 1-1 for me. > Taken from the docs I"m working on: MyBean myBean = container.initialize().select(MyBean.class).get(); myBean.doWork(); Vs the 3-4 lines it takes to get a reference using just BeanManager. > > >> >>> Something not dealt with but that we should keep in mind : >>> - Providing a Java SE solution that could be easily used for a servlet >>> bootstrap of CDI. I don?t know if we?ll standardize this but we definitely >>> should keep this use case in mind >>> >>> and my bonus, it?s out of scope but I didn?t see anytime there that >>> prevent this nice to have: >>> - support the possibility to boot multiple BeanManager in Java SE. >>> >>> >> We talked about this one as well on the EG, either this year or late last >> year. I thought the decision at that time was that we wouldn't allow >> multiple containers at once in SE. >> >> > > wouldn't specify rather than wouldn't allow I think > > >> Antoine >>> >>> >>> Le 1 mars 2015 ? 15:13, John D. Ament a ?crit : >>> >>> >>> So, I think I've gathered enough feedback at this point, and seen some >>> of the API changes. I'll hopefully be including some doc changes this >>> week, but one question - do we want to start the SE specific stuff as its >>> own asciidoc file? >>> >>> Changes made: >>> >>> - Changed return value to CDI to provide better capability out >>> of the box. >>> - Added AutoCloseable to CDIContainer, provided default implementation >>> of calling shutdown. >>> - Added synchronization support to the method body that retrieves the >>> singleton instance (BTW, I'm not sure if this is even useful TBH as each >>> impl, including the RI, needs to provide this class in its own format). >>> - Made the params map typed to >>> >>> @Romain Your case isn't really supportable yet, until we have static >>> injection support. You'd still have to have a managed version of Runner to >>> work against. >>> >>> John >>> >>> On Sat, Feb 28, 2015 at 4:11 PM Romain Manni-Bucau < >>> rmannibucau at gmail.com> wrote: >>> >>>> Yes but not the way to get an instance. Even Unmanaged does it. >>>> >>>> What can be awesome is to have static inject for it: >>>> >>>> public class Runner { >>>> >>>> @Inject >>>> private static MyMain main; >>>> >>>> public static void main(String[] arg) { >>>> try (CDIContainer c = CDIContainer.newContainer()) { >>>> main.doWork(); >>>> } >>>> } >>>> >>>> } >>>> >>>> And not a single additional line :). >>>> Le 28 f?vr. 2015 19:05, "John D. Ament" a >>>> ?crit : >>>> >>>> Maybe I'm misreading, but I don't see us adding another API to do the >>>>> same thing here - we're introducing new functionality. >>>>> >>>>> CDIContainer/Loader on startup/shutdown of the application >>>>> >>>>> CDI for runtime usage within the application to interact with the >>>>> container. >>>>> >>>>> John >>>>> >>>>> On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau < >>>>> rmannibucau at gmail.com> wrote: >>>>> >>>>>> sure I fully agree excepted I think introducing yet another API to do >>>>>> the same thing is not good so super tempting to skip it and wait for >>>>>> feedbacks rather than introducing it eagerly. >>>>>> >>>>>> >>>>>> Romain Manni-Bucau >>>>>> @rmannibucau >>>>>> http://www.tomitribe.com >>>>>> http://rmannibucau.wordpress.com >>>>>> https://github.com/rmannibucau >>>>>> >>>>>> >>>>>> 2015-02-27 8:05 GMT+01:00 Jozef Hartinger : >>>>>> > My point is that from the application perspective, the user obtains >>>>>> one >>>>>> > container handle for eventual shutdown (CDIContainer) and then >>>>>> looks up a >>>>>> > different container handle (CDI) that they can use for real work >>>>>> (lookup / >>>>>> > event dispatch / etc.) It would be cleaner if the container gave >>>>>> away a >>>>>> > single handle that can do all of that. >>>>>> > >>>>>> > >>>>>> > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: >>>>>> > >>>>>> > Not sure I get how a CDI instance can help. >>>>>> > >>>>>> > But container.getBeanManager() sounds nice is not a shortcut for >>>>>> > CDI.current().getBm() otherwise it looks like duplication to me. >>>>>> > >>>>>> > Can we make container not contextual - dont think so? If so it >>>>>> makes sense >>>>>> > otherwise I fear it doesnt add much. >>>>>> > >>>>>> > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" a >>>>>> ?crit : >>>>>> >> >>>>>> >> I like the initialize + close() combination and the >>>>>> try-with-resources >>>>>> >> usage. >>>>>> >> What looks weird to me is that at line one you obtain a container >>>>>> handle: >>>>>> >> >>>>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>>>> >> CDI.current().getBeanManager() ... >>>>>> >> >>>>>> >> and then at line two you call a static method to perform a >>>>>> container >>>>>> >> lookup :-/ >>>>>> >> >>>>>> >> An API that allows you to use the container handle you already got >>>>>> is way >>>>>> >> better IMO, e.g.: >>>>>> >> >>>>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>>>> >> container.getBeanManager() >>>>>> >> >>>>>> >> If CDIContainer.newCDIContainer() returns an CDI instance or its >>>>>> subclass, >>>>>> >> we get this easily. >>>>>> >> >>>>>> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: >>>>>> >>> >>>>>> >>> Hi guys >>>>>> >>> >>>>>> >>> why note keeping it simple? >>>>>> >>> >>>>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer(/* >>>>>> optional >>>>>> >>> map to configure vendor features */)) { >>>>>> >>> CDI.current().getBeanManager().... >>>>>> >>> } >>>>>> >>> >>>>>> >>> Not sure the point having initialize() + having shutdown = close >>>>>> >>> really makes the API more fluent and modern IMO. >>>>>> >>> >>>>>> >>> Also to be fully SE I guess provider() method would be needed >>>>>> even if >>>>>> >>> optional (SPI usage by default): >>>>>> >>> >>>>>> >>> try (CDIContainer container = >>>>>> >>> >>>>>> >>> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider"). >>>>>> newCDIContainer()) >>>>>> >>> { >>>>>> >>> CDI.current().getBeanManager().... >>>>>> >>> } >>>>>> >>> >>>>>> >>> Finally I think having a kind of getInstance shortcut could be a >>>>>> plus for >>>>>> >>> SE: >>>>>> >>> >>>>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer()) { >>>>>> >>> container.newInstance(MyAppRunner.class /* optional >>>>>> qualifiers */ >>>>>> >>> ).run(args); >>>>>> >>> } >>>>>> >>> >>>>>> >>> Using container to get an instance would create the instance and >>>>>> bind >>>>>> >>> it to the container lifecycle (mainly for predestroy) avoiding >>>>>> this >>>>>> >>> boilerplate code in all main which will surely only be used to >>>>>> launch >>>>>> >>> a soft. >>>>>> >>> >>>>>> >>> wdyt? >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> Romain Manni-Bucau >>>>>> >>> @rmannibucau >>>>>> >>> http://www.tomitribe.com >>>>>> >>> http://rmannibucau.wordpress.com >>>>>> >>> https://github.com/rmannibucau >>>>>> >>> >>>>>> >>> >>>>>> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger : >>>>>> >>>> >>>>>> >>>> Comments inline >>>>>> >>>> >>>>>> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: >>>>>> >>>> >>>>>> >>>> Sorry Jozef, your email fell into the pits of google inbox's >>>>>> "smart >>>>>> >>>> sorting" >>>>>> >>>> features. >>>>>> >>>> >>>>>> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger < >>>>>> jharting at redhat.com> >>>>>> >>>> wrote: >>>>>> >>>>> >>>>>> >>>>> Hi John, comments inline: >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >>>>>> >>>>> >>>>>> >>>>> Jozef, >>>>>> >>>>> >>>>>> >>>>> Most of what you see there is taken from the original doc, since >>>>>> >>>>> everyone >>>>>> >>>>> seemed to be in agreement. I think the map is just a safeguard >>>>>> in case >>>>>> >>>>> of >>>>>> >>>>> additional boot options available in some implementations (e.g. >>>>>> I think >>>>>> >>>>> OWB/OpenEJB have some options.. currently OpenEJB supports an >>>>>> embedded >>>>>> >>>>> CDI >>>>>> >>>>> boot mode). >>>>>> >>>>> >>>>>> >>>>> No, I am fine with the map. What I am questioning is the type >>>>>> of the >>>>>> >>>>> map. >>>>>> >>>>> Usually, data structures with a similar purpose use Strings as >>>>>> their >>>>>> >>>>> keys. >>>>>> >>>>> This applies to ServletContext attributes, InvocationContext >>>>>> data, >>>>>> >>>>> Servlet >>>>>> >>>>> request/session attributes and others. I am therefore wondering >>>>>> whether >>>>>> >>>>> there is a usecase for the proposed unbound key signature or >>>>>> not. >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> I think that's more of a placeholder, I was assuming it would be >>>>>> >>>> Map once we clarify everything. >>>>>> >>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> We spoke a few times about BeanManager vs CDI. BeanManager was >>>>>> >>>>> preferable >>>>>> >>>>> since there's no easy way to get the the instance, CDI is >>>>>> easier to get >>>>>> >>>>> and >>>>>> >>>>> more aligned with how you would get it. Usually people expect >>>>>> the >>>>>> >>>>> BeanManager to be injected or available via JNDI, neither would >>>>>> be the >>>>>> >>>>> case >>>>>> >>>>> here. >>>>>> >>>>> >>>>>> >>>>> If CDI 2.0 targets Java SE then this container initialization >>>>>> API will >>>>>> >>>>> become something that ordinary application developers use to >>>>>> start/stop >>>>>> >>>>> CDI >>>>>> >>>>> in their applications. It therefore cannot be considered an SPI >>>>>> but >>>>>> >>>>> instead >>>>>> >>>>> should be something easy to use. On the other hand, BeanManager >>>>>> is >>>>>> >>>>> definitely an SPI. It is used in extension, frameworks and >>>>>> generally >>>>>> >>>>> for >>>>>> >>>>> integration. Not much by applications directly. Therefore, I >>>>>> don't see >>>>>> >>>>> how >>>>>> >>>>> the container bootstrap API and BeanManager fit together. IMO >>>>>> the >>>>>> >>>>> bootstrap >>>>>> >>>>> API should expose something that makes common tasks (obtaining a >>>>>> >>>>> contextual >>>>>> >>>>> reference and firing and event) easy, which the CDI class does. >>>>>> >>>>> >>>>>> >>>>> Plus do not forget that BeanManager can be obtained easily using >>>>>> >>>>> CDI.getBeanManager(). >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> I'm not disagreeing. There's a few things I'd consider: >>>>>> >>>> >>>>>> >>>> - Is this mostly for new apps or existing? If existing, it's >>>>>> probably >>>>>> >>>> using >>>>>> >>>> some internal API, if new it can use whatever API we give. >>>>>> >>>> - I don't want to return void, we should give some kind of >>>>>> reference >>>>>> >>>> into >>>>>> >>>> the container when we're done booting. >>>>>> >>>> >>>>>> >>>> Agreed, we should not be returning void. >>>>>> >>>> >>>>>> >>>> - CDI is a one step retrievable reference, where as BeanManager >>>>>> is a two >>>>>> >>>> step reference. With that said, BeanManager makes more sense to >>>>>> return >>>>>> >>>> here. Another thought could be we invent some new class that >>>>>> has both, >>>>>> >>>> but >>>>>> >>>> that's really redundant. >>>>>> >>>> >>>>>> >>>> Why do you think BeanManager makes more sense here? Especially >>>>>> given the >>>>>> >>>> assumption that application code is going to call this >>>>>> init/shutdown >>>>>> >>>> API, I >>>>>> >>>> don't see BeanManager as making more sense. >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> Yes, this is the container start API. Sounds like you have >>>>>> some good >>>>>> >>>>> ideas for things like XML configuration or programmatic >>>>>> configuration, >>>>>> >>>>> both >>>>>> >>>>> of which are being tracked under separate tickets. One idea >>>>>> might be >>>>>> >>>>> for an >>>>>> >>>>> optional param in the map to control packages to scan/ignore, >>>>>> in that >>>>>> >>>>> map. >>>>>> >>>>> >>>>>> >>>>> I am wondering whether this configuration should be something >>>>>> optional >>>>>> >>>>> built on top of the bootstrap API or whether we should consider >>>>>> making >>>>>> >>>>> it >>>>>> >>>>> mandatory. Either way, we cannot add the bootstrap API to the >>>>>> spec >>>>>> >>>>> without >>>>>> >>>>> explicitly defining how it behaves. My implicit assumption of >>>>>> the >>>>>> >>>>> proposal >>>>>> >>>>> is that the container is supposed to scan the entire classpath >>>>>> for >>>>>> >>>>> explicit >>>>>> >>>>> or implicit bean archives (including e.g. rt.jar), discover >>>>>> beans, fire >>>>>> >>>>> extensions, etc. This worries me as this default behavior is >>>>>> far from >>>>>> >>>>> being >>>>>> >>>>> lightweight, which CDI for Java SE initially aimed to be. >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> Yes, the spec must be updated to reflect the behavior of SE >>>>>> mode. I >>>>>> >>>> plan to >>>>>> >>>> get that completely into the google doc before opening any spec >>>>>> changes >>>>>> >>>> in a >>>>>> >>>> PR. >>>>>> >>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> We didn't want to over load the CDI interface. It already does >>>>>> a lot. >>>>>> >>>>> This is really SPI code, CDI even though it's in the spi >>>>>> package is >>>>>> >>>>> used in >>>>>> >>>>> a lot of application code. >>>>>> >>>>> >>>>>> >>>>> I would personally prefer to have it all in one place. Having >>>>>> >>>>> CDIContainer, CDIContainerLoader, CDI and CDIProvider makes it >>>>>> more >>>>>> >>>>> difficult to know when to use what. >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> The problem is that most CDI (the interface) operations are >>>>>> against a >>>>>> >>>> running container. I think we spoke about leveraging >>>>>> CDIProvider at one >>>>>> >>>> point (in fact, I mistakenly called CDIContainer CDIProvider not >>>>>> even >>>>>> >>>> realizing it was there). I doubt that most app developers use it >>>>>> >>>> currently, >>>>>> >>>> there's not even a way to get a reference to it that I'm aware >>>>>> of. It's >>>>>> >>>> used by the implementor only. >>>>>> >>>> >>>>>> >>>> I don't think there's a conflict. CDI class would still only >>>>>> provide >>>>>> >>>> methods >>>>>> >>>> to be run against a running container. The difference is that >>>>>> there >>>>>> >>>> would be >>>>>> >>>> additional static methods to get this running container (CDI >>>>>> class) to >>>>>> >>>> you >>>>>> >>>> by starting the container. >>>>>> >>>> >>>>>> >>>> Either way, I agree that reusing CDIProvider is a must. There is >>>>>> no >>>>>> >>>> reason >>>>>> >>>> to define a new class for the same purpose. >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> I expect that my changes in the CDI spec around this will state, >>>>>> along >>>>>> >>>> the >>>>>> >>>> lines of: >>>>>> >>>> >>>>>> >>>> To retrieve a CDIContainer to launch, do this: >>>>>> >>>> >>>>>> >>>> CDIContainer container = CDIContainerLocator.getCDIContainer(); >>>>>> >>>> container.initialize(); >>>>>> >>>> ... do work >>>>>> >>>> >>>>>> >>>> Once you want to shutdown the container, do this: >>>>>> >>>> >>>>>> >>>> container.shutdown(); >>>>>> >>>> >>>>>> >>>> (we may want to consider implementing AutoCloseable, an >>>>>> oversight on my >>>>>> >>>> part) >>>>>> >>>> >>>>>> >>>> and then later on >>>>>> >>>> >>>>>> >>>> - What happens if I call CDIContainerLocator in an app server >>>>>> >>>> >>>>>> >>>> - It throws an IllegalStateException. >>>>>> >>>> >>>>>> >>>> - The container provides no beans of type CDIContainer, it is >>>>>> managed >>>>>> >>>> outside of the CDI container. >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> John >>>>>> >>>>> >>>>>> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger < >>>>>> jharting at redhat.com> >>>>>> >>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> Hi John, some thoughts: >>>>>> >>>>>> >>>>>> >>>>>> - instead of using BeanManager it makes more sense to me to >>>>>> return a >>>>>> >>>>>> CDI >>>>>> >>>>>> instance, which is a more user-friendly API (and it also >>>>>> exposes >>>>>> >>>>>> access to >>>>>> >>>>>> BeanManager) >>>>>> >>>>>> - is there a usecase for arbitrary keys of the "params" map or >>>>>> is >>>>>> >>>>>> Map sufficient? >>>>>> >>>>>> - if we could move the shutdown() method from CDIContainer to >>>>>> the >>>>>> >>>>>> actual >>>>>> >>>>>> container handle that we obtain from initialize(), that would >>>>>> look >>>>>> >>>>>> more >>>>>> >>>>>> object-oriented >>>>>> >>>>>> - what exactly is initialize() supposed to do? Is it supposed >>>>>> to start >>>>>> >>>>>> scanning the entire classpath for CDI beans? That could be a >>>>>> problem >>>>>> >>>>>> especially with spring-boot-like fat jars. I think we need an >>>>>> API to >>>>>> >>>>>> tell >>>>>> >>>>>> the container which classes / packages to consider. Something >>>>>> like >>>>>> >>>>>> Guice's >>>>>> >>>>>> binding API perhaps? >>>>>> >>>>>> >>>>>> >>>>>> - the proposal makes me wonder whether retrofitting this >>>>>> functionality >>>>>> >>>>>> to >>>>>> >>>>>> the CDI class wouldn't be a better option. It could look like: >>>>>> >>>>>> >>>>>> >>>>>> CDI container = CDI.initialize(); >>>>>> >>>>>> container.select(Foo.class).get(); >>>>>> >>>>>> container.shutdown(); >>>>>> >>>>>> >>>>>> >>>>>> compare it to: >>>>>> >>>>>> >>>>>> >>>>>> CDIContainer container = CDIContainerLoader. getCDIContainer(); >>>>>> >>>>>> BeanManager manager = container.initialize(); >>>>>> >>>>>> manager.getBeans(...); >>>>>> >>>>>> container.shutdown(manager); >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >>>>>> >>>>>> >>>>>> >>>>>> All, >>>>>> >>>>>> >>>>>> >>>>>> I have the updated API here, and wanted to solicit any final >>>>>> feedback >>>>>> >>>>>> before updating the google doc and spec pages. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> https://github.com/johnament/cdi/commit/2c362161e18dd521f8e8 >>>>>> 3c27151ddad467a1c01c >>>>>> >>>>>> >>>>>> >>>>>> Let me know your thoughts. >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> >>>>>> >>>>>> John >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> >>>>>> cdi-dev mailing list >>>>>> >>>>>> cdi-dev at lists.jboss.org >>>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>> >>>>>> >>>>>> >>>>>> Note that for all code provided on this list, the provider >>>>>> licenses >>>>>> >>>>>> the >>>>>> >>>>>> code under the Apache License, Version 2 >>>>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all >>>>>> other ideas >>>>>> >>>>>> provided on this list, the provider waives all patent and other >>>>>> >>>>>> intellectual >>>>>> >>>>>> property rights inherent in such information. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>>>> >>>> _______________________________________________ >>>>>> >>>> cdi-dev mailing list >>>>>> >>>> cdi-dev at lists.jboss.org >>>>>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>> >>>> >>>>>> >>>> Note that for all code provided on this list, the provider >>>>>> licenses the >>>>>> >>>> code >>>>>> >>>> under the Apache License, Version 2 >>>>>> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all >>>>>> other ideas >>>>>> >>>> provided on this list, the provider waives all patent and other >>>>>> >>>> intellectual >>>>>> >>>> property rights inherent in such information. >>>>>> >> >>>>>> >> >>>>>> > >>>>>> >>>>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 (http://www.apache.org/ >>> licenses/LICENSE-2.0.html). For all other ideas provided on this list, >>> the provider waives all patent and other intellectual property rights >>> inherent in such information. >>> >>> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/58f451f2/attachment-0001.html From john.d.ament at gmail.com Wed Mar 4 06:42:36 2015 From: john.d.ament at gmail.com (John D. Ament) Date: Wed, 04 Mar 2015 11:42:36 +0000 Subject: [cdi-dev] Bean Discovery Mode in SE References: <54F6CD01.5080806@redhat.com> Message-ID: Jozef, How does Weld SE deal with it right now? I run two components, one using WildFly 8.2 and the other just SE mode w/ Weld SE. I don't notice much of a difference in scanning, even though the SE one needs to scan 50 mb of classpath. John On Wed, Mar 4, 2015 at 4:14 AM Jozef Hartinger wrote: > For EE assuming bean-discovery-mode="annotated" by default if no > beans.xml is found is OK as the scope of scanning is limited by the > deployment. In SE however this would require that we scan the entire > classpath for scope annotations, stereotypes, etc. I am therefore concerned > about the performance implications of this. > > > On 03/01/2015 04:18 PM, John D. Ament wrote: > > Yeah actually you're right. For some reason I had in my head that "all" > was the default. It's very clearly not. Too early for some of this :-) > > So let me rephrase. "annotated" will be the default bean discovery mode > if a classpath entry contains no META-INF/beans.xml, based on the exact > same rules used in EE. > > Any concerns with that? > > John > > On Sun, Mar 1, 2015 at 10:10 AM Romain Manni-Bucau > wrote: > >> For me it is 100% the same as ee where you have the same issues so >> keeping them aligned is better IMO. That said configuring globally the >> scanning would be nice. >> Le 1 mars 2015 15:54, "John D. Ament" a ?crit : >> >>> All, >>> >>> I'd like to propose in my doc changes for CDI-26 that if a classpath >>> entry does not contain a META-INF/beans.xml that it is treated as if it >>> were bean-discovery-mode=none, e.g. no beans will be scanned in that entry. >>> (BTW, I'm using classpath entry rather than archive in the document to >>> account for cases where someone does -cp >>> "./classes:./extra-classes:./lib/*" to define their classpath) >>> >>> It's a bit different than how EE works, but I could imagine it causing >>> fewer headaches when running on SE classpaths. >>> >>> Any thoughts/comments? >>> >>> John >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>> provided on this list, the provider waives all patent and other >>> intellectual property rights inherent in such information. >>> >> > > _______________________________________________ > cdi-dev mailing listcdi-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/e1f32376/attachment.html From rmannibucau at gmail.com Wed Mar 4 06:43:42 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 4 Mar 2015 12:43:42 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: References: Message-ID: hmm, and if the bean is @Dependent? how do you release it? Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-03-04 12:37 GMT+01:00 John D. Ament : > > > On Wed, Mar 4, 2015 at 6:35 AM Romain Manni-Bucau > wrote: > >> 2015-03-04 12:29 GMT+01:00 John D. Ament : >> >>> Hmm.. comments in line. >>> >>> On Wed, Mar 4, 2015 at 4:49 AM Antoine Sabot-Durand < >>> antoine at sabot-durand.net> wrote: >>> >>>> Hi John, >>>> >>>> I think it could be a good idea to write down all of these to have a >>>> more stable doc for discussion. You should update the google doc with the >>>> result of this discussion. >>>> >>>> I agree with the following points in this thread : >>>> >>>> - Minimize the number of new Class / Interface. CDI and CDIProvider >>>> usage is still not very clear for end user so we should add the strict >>>> minimum and try to enhance existing API / SPI when possible >>>> >>> >>> It seems odd to me that we're rehashing decisions made during the EG >>> meetings. Not putting it in CDI was discussed in several meetings at the >>> beginning of the year, and it seemed like the agreement was putting it in >>> CDI was a bad idea. >>> >>> >>>> - Be able to bootstrap CDI without returning BeanManager (env if the >>>> API give possibility to access it if needed). End user don?t need that : >>>> CDI app can start with an observer for instance >>>> >>> >>> Agreed, but I think we need to provide some entry point to allow those >>> who aren't comfortable with programming with events to leverage it. >>> Returning the CDI instance makes that easier to do than returning the >>> BeanManager. >>> >>> >> >> Can you detail it please? CDI value is only its getBeanManager() method >> IMO so it sounds like it is 1-1 for me. >> > > > Taken from the docs I"m working on: > > MyBean myBean = container.initialize().select(MyBean.class).get(); > myBean.doWork(); > > Vs the 3-4 lines it takes to get a reference using just BeanManager. > > >> >> >>> >>>> Something not dealt with but that we should keep in mind : >>>> - Providing a Java SE solution that could be easily used for a servlet >>>> bootstrap of CDI. I don?t know if we?ll standardize this but we definitely >>>> should keep this use case in mind >>>> >>>> and my bonus, it?s out of scope but I didn?t see anytime there that >>>> prevent this nice to have: >>>> - support the possibility to boot multiple BeanManager in Java SE. >>>> >>>> >>> We talked about this one as well on the EG, either this year or late >>> last year. I thought the decision at that time was that we wouldn't allow >>> multiple containers at once in SE. >>> >>> >> >> wouldn't specify rather than wouldn't allow I think >> >> >>> Antoine >>>> >>>> >>>> Le 1 mars 2015 ? 15:13, John D. Ament a ?crit >>>> : >>>> >>>> >>>> So, I think I've gathered enough feedback at this point, and seen some >>>> of the API changes. I'll hopefully be including some doc changes this >>>> week, but one question - do we want to start the SE specific stuff as its >>>> own asciidoc file? >>>> >>>> Changes made: >>>> >>>> - Changed return value to CDI to provide better capability out >>>> of the box. >>>> - Added AutoCloseable to CDIContainer, provided default implementation >>>> of calling shutdown. >>>> - Added synchronization support to the method body that retrieves the >>>> singleton instance (BTW, I'm not sure if this is even useful TBH as each >>>> impl, including the RI, needs to provide this class in its own format). >>>> - Made the params map typed to >>>> >>>> @Romain Your case isn't really supportable yet, until we have static >>>> injection support. You'd still have to have a managed version of Runner to >>>> work against. >>>> >>>> John >>>> >>>> On Sat, Feb 28, 2015 at 4:11 PM Romain Manni-Bucau < >>>> rmannibucau at gmail.com> wrote: >>>> >>>>> Yes but not the way to get an instance. Even Unmanaged does it. >>>>> >>>>> What can be awesome is to have static inject for it: >>>>> >>>>> public class Runner { >>>>> >>>>> @Inject >>>>> private static MyMain main; >>>>> >>>>> public static void main(String[] arg) { >>>>> try (CDIContainer c = CDIContainer.newContainer()) { >>>>> main.doWork(); >>>>> } >>>>> } >>>>> >>>>> } >>>>> >>>>> And not a single additional line :). >>>>> Le 28 f?vr. 2015 19:05, "John D. Ament" a >>>>> ?crit : >>>>> >>>>> Maybe I'm misreading, but I don't see us adding another API to do the >>>>>> same thing here - we're introducing new functionality. >>>>>> >>>>>> CDIContainer/Loader on startup/shutdown of the application >>>>>> >>>>>> CDI for runtime usage within the application to interact with the >>>>>> container. >>>>>> >>>>>> John >>>>>> >>>>>> On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau < >>>>>> rmannibucau at gmail.com> wrote: >>>>>> >>>>>>> sure I fully agree excepted I think introducing yet another API to do >>>>>>> the same thing is not good so super tempting to skip it and wait for >>>>>>> feedbacks rather than introducing it eagerly. >>>>>>> >>>>>>> >>>>>>> Romain Manni-Bucau >>>>>>> @rmannibucau >>>>>>> http://www.tomitribe.com >>>>>>> http://rmannibucau.wordpress.com >>>>>>> https://github.com/rmannibucau >>>>>>> >>>>>>> >>>>>>> 2015-02-27 8:05 GMT+01:00 Jozef Hartinger : >>>>>>> > My point is that from the application perspective, the user >>>>>>> obtains one >>>>>>> > container handle for eventual shutdown (CDIContainer) and then >>>>>>> looks up a >>>>>>> > different container handle (CDI) that they can use for real work >>>>>>> (lookup / >>>>>>> > event dispatch / etc.) It would be cleaner if the container gave >>>>>>> away a >>>>>>> > single handle that can do all of that. >>>>>>> > >>>>>>> > >>>>>>> > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: >>>>>>> > >>>>>>> > Not sure I get how a CDI instance can help. >>>>>>> > >>>>>>> > But container.getBeanManager() sounds nice is not a shortcut for >>>>>>> > CDI.current().getBm() otherwise it looks like duplication to me. >>>>>>> > >>>>>>> > Can we make container not contextual - dont think so? If so it >>>>>>> makes sense >>>>>>> > otherwise I fear it doesnt add much. >>>>>>> > >>>>>>> > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" a >>>>>>> ?crit : >>>>>>> >> >>>>>>> >> I like the initialize + close() combination and the >>>>>>> try-with-resources >>>>>>> >> usage. >>>>>>> >> What looks weird to me is that at line one you obtain a container >>>>>>> handle: >>>>>>> >> >>>>>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>>>>> >> CDI.current().getBeanManager() ... >>>>>>> >> >>>>>>> >> and then at line two you call a static method to perform a >>>>>>> container >>>>>>> >> lookup :-/ >>>>>>> >> >>>>>>> >> An API that allows you to use the container handle you already >>>>>>> got is way >>>>>>> >> better IMO, e.g.: >>>>>>> >> >>>>>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>>>>> >> container.getBeanManager() >>>>>>> >> >>>>>>> >> If CDIContainer.newCDIContainer() returns an CDI instance or its >>>>>>> subclass, >>>>>>> >> we get this easily. >>>>>>> >> >>>>>>> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: >>>>>>> >>> >>>>>>> >>> Hi guys >>>>>>> >>> >>>>>>> >>> why note keeping it simple? >>>>>>> >>> >>>>>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer(/* >>>>>>> optional >>>>>>> >>> map to configure vendor features */)) { >>>>>>> >>> CDI.current().getBeanManager().... >>>>>>> >>> } >>>>>>> >>> >>>>>>> >>> Not sure the point having initialize() + having shutdown = close >>>>>>> >>> really makes the API more fluent and modern IMO. >>>>>>> >>> >>>>>>> >>> Also to be fully SE I guess provider() method would be needed >>>>>>> even if >>>>>>> >>> optional (SPI usage by default): >>>>>>> >>> >>>>>>> >>> try (CDIContainer container = >>>>>>> >>> >>>>>>> >>> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvid >>>>>>> er").newCDIContainer()) >>>>>>> >>> { >>>>>>> >>> CDI.current().getBeanManager().... >>>>>>> >>> } >>>>>>> >>> >>>>>>> >>> Finally I think having a kind of getInstance shortcut could be a >>>>>>> plus for >>>>>>> >>> SE: >>>>>>> >>> >>>>>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer()) { >>>>>>> >>> container.newInstance(MyAppRunner.class /* optional >>>>>>> qualifiers */ >>>>>>> >>> ).run(args); >>>>>>> >>> } >>>>>>> >>> >>>>>>> >>> Using container to get an instance would create the instance and >>>>>>> bind >>>>>>> >>> it to the container lifecycle (mainly for predestroy) avoiding >>>>>>> this >>>>>>> >>> boilerplate code in all main which will surely only be used to >>>>>>> launch >>>>>>> >>> a soft. >>>>>>> >>> >>>>>>> >>> wdyt? >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> Romain Manni-Bucau >>>>>>> >>> @rmannibucau >>>>>>> >>> http://www.tomitribe.com >>>>>>> >>> http://rmannibucau.wordpress.com >>>>>>> >>> https://github.com/rmannibucau >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger : >>>>>>> >>>> >>>>>>> >>>> Comments inline >>>>>>> >>>> >>>>>>> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: >>>>>>> >>>> >>>>>>> >>>> Sorry Jozef, your email fell into the pits of google inbox's >>>>>>> "smart >>>>>>> >>>> sorting" >>>>>>> >>>> features. >>>>>>> >>>> >>>>>>> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger < >>>>>>> jharting at redhat.com> >>>>>>> >>>> wrote: >>>>>>> >>>>> >>>>>>> >>>>> Hi John, comments inline: >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >>>>>>> >>>>> >>>>>>> >>>>> Jozef, >>>>>>> >>>>> >>>>>>> >>>>> Most of what you see there is taken from the original doc, >>>>>>> since >>>>>>> >>>>> everyone >>>>>>> >>>>> seemed to be in agreement. I think the map is just a >>>>>>> safeguard in case >>>>>>> >>>>> of >>>>>>> >>>>> additional boot options available in some implementations >>>>>>> (e.g. I think >>>>>>> >>>>> OWB/OpenEJB have some options.. currently OpenEJB supports an >>>>>>> embedded >>>>>>> >>>>> CDI >>>>>>> >>>>> boot mode). >>>>>>> >>>>> >>>>>>> >>>>> No, I am fine with the map. What I am questioning is the type >>>>>>> of the >>>>>>> >>>>> map. >>>>>>> >>>>> Usually, data structures with a similar purpose use Strings as >>>>>>> their >>>>>>> >>>>> keys. >>>>>>> >>>>> This applies to ServletContext attributes, InvocationContext >>>>>>> data, >>>>>>> >>>>> Servlet >>>>>>> >>>>> request/session attributes and others. I am therefore >>>>>>> wondering whether >>>>>>> >>>>> there is a usecase for the proposed unbound key signature or >>>>>>> not. >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> I think that's more of a placeholder, I was assuming it would be >>>>>>> >>>> Map once we clarify everything. >>>>>>> >>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> We spoke a few times about BeanManager vs CDI. BeanManager was >>>>>>> >>>>> preferable >>>>>>> >>>>> since there's no easy way to get the the instance, CDI is >>>>>>> easier to get >>>>>>> >>>>> and >>>>>>> >>>>> more aligned with how you would get it. Usually people expect >>>>>>> the >>>>>>> >>>>> BeanManager to be injected or available via JNDI, neither >>>>>>> would be the >>>>>>> >>>>> case >>>>>>> >>>>> here. >>>>>>> >>>>> >>>>>>> >>>>> If CDI 2.0 targets Java SE then this container initialization >>>>>>> API will >>>>>>> >>>>> become something that ordinary application developers use to >>>>>>> start/stop >>>>>>> >>>>> CDI >>>>>>> >>>>> in their applications. It therefore cannot be considered an >>>>>>> SPI but >>>>>>> >>>>> instead >>>>>>> >>>>> should be something easy to use. On the other hand, >>>>>>> BeanManager is >>>>>>> >>>>> definitely an SPI. It is used in extension, frameworks and >>>>>>> generally >>>>>>> >>>>> for >>>>>>> >>>>> integration. Not much by applications directly. Therefore, I >>>>>>> don't see >>>>>>> >>>>> how >>>>>>> >>>>> the container bootstrap API and BeanManager fit together. IMO >>>>>>> the >>>>>>> >>>>> bootstrap >>>>>>> >>>>> API should expose something that makes common tasks (obtaining >>>>>>> a >>>>>>> >>>>> contextual >>>>>>> >>>>> reference and firing and event) easy, which the CDI class does. >>>>>>> >>>>> >>>>>>> >>>>> Plus do not forget that BeanManager can be obtained easily >>>>>>> using >>>>>>> >>>>> CDI.getBeanManager(). >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> I'm not disagreeing. There's a few things I'd consider: >>>>>>> >>>> >>>>>>> >>>> - Is this mostly for new apps or existing? If existing, it's >>>>>>> probably >>>>>>> >>>> using >>>>>>> >>>> some internal API, if new it can use whatever API we give. >>>>>>> >>>> - I don't want to return void, we should give some kind of >>>>>>> reference >>>>>>> >>>> into >>>>>>> >>>> the container when we're done booting. >>>>>>> >>>> >>>>>>> >>>> Agreed, we should not be returning void. >>>>>>> >>>> >>>>>>> >>>> - CDI is a one step retrievable reference, where as BeanManager >>>>>>> is a two >>>>>>> >>>> step reference. With that said, BeanManager makes more sense >>>>>>> to return >>>>>>> >>>> here. Another thought could be we invent some new class that >>>>>>> has both, >>>>>>> >>>> but >>>>>>> >>>> that's really redundant. >>>>>>> >>>> >>>>>>> >>>> Why do you think BeanManager makes more sense here? Especially >>>>>>> given the >>>>>>> >>>> assumption that application code is going to call this >>>>>>> init/shutdown >>>>>>> >>>> API, I >>>>>>> >>>> don't see BeanManager as making more sense. >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> Yes, this is the container start API. Sounds like you have >>>>>>> some good >>>>>>> >>>>> ideas for things like XML configuration or programmatic >>>>>>> configuration, >>>>>>> >>>>> both >>>>>>> >>>>> of which are being tracked under separate tickets. One idea >>>>>>> might be >>>>>>> >>>>> for an >>>>>>> >>>>> optional param in the map to control packages to scan/ignore, >>>>>>> in that >>>>>>> >>>>> map. >>>>>>> >>>>> >>>>>>> >>>>> I am wondering whether this configuration should be something >>>>>>> optional >>>>>>> >>>>> built on top of the bootstrap API or whether we should >>>>>>> consider making >>>>>>> >>>>> it >>>>>>> >>>>> mandatory. Either way, we cannot add the bootstrap API to the >>>>>>> spec >>>>>>> >>>>> without >>>>>>> >>>>> explicitly defining how it behaves. My implicit assumption of >>>>>>> the >>>>>>> >>>>> proposal >>>>>>> >>>>> is that the container is supposed to scan the entire classpath >>>>>>> for >>>>>>> >>>>> explicit >>>>>>> >>>>> or implicit bean archives (including e.g. rt.jar), discover >>>>>>> beans, fire >>>>>>> >>>>> extensions, etc. This worries me as this default behavior is >>>>>>> far from >>>>>>> >>>>> being >>>>>>> >>>>> lightweight, which CDI for Java SE initially aimed to be. >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> Yes, the spec must be updated to reflect the behavior of SE >>>>>>> mode. I >>>>>>> >>>> plan to >>>>>>> >>>> get that completely into the google doc before opening any spec >>>>>>> changes >>>>>>> >>>> in a >>>>>>> >>>> PR. >>>>>>> >>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> We didn't want to over load the CDI interface. It already >>>>>>> does a lot. >>>>>>> >>>>> This is really SPI code, CDI even though it's in the spi >>>>>>> package is >>>>>>> >>>>> used in >>>>>>> >>>>> a lot of application code. >>>>>>> >>>>> >>>>>>> >>>>> I would personally prefer to have it all in one place. Having >>>>>>> >>>>> CDIContainer, CDIContainerLoader, CDI and CDIProvider makes it >>>>>>> more >>>>>>> >>>>> difficult to know when to use what. >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> The problem is that most CDI (the interface) operations are >>>>>>> against a >>>>>>> >>>> running container. I think we spoke about leveraging >>>>>>> CDIProvider at one >>>>>>> >>>> point (in fact, I mistakenly called CDIContainer CDIProvider >>>>>>> not even >>>>>>> >>>> realizing it was there). I doubt that most app developers use >>>>>>> it >>>>>>> >>>> currently, >>>>>>> >>>> there's not even a way to get a reference to it that I'm aware >>>>>>> of. It's >>>>>>> >>>> used by the implementor only. >>>>>>> >>>> >>>>>>> >>>> I don't think there's a conflict. CDI class would still only >>>>>>> provide >>>>>>> >>>> methods >>>>>>> >>>> to be run against a running container. The difference is that >>>>>>> there >>>>>>> >>>> would be >>>>>>> >>>> additional static methods to get this running container (CDI >>>>>>> class) to >>>>>>> >>>> you >>>>>>> >>>> by starting the container. >>>>>>> >>>> >>>>>>> >>>> Either way, I agree that reusing CDIProvider is a must. There >>>>>>> is no >>>>>>> >>>> reason >>>>>>> >>>> to define a new class for the same purpose. >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> I expect that my changes in the CDI spec around this will >>>>>>> state, along >>>>>>> >>>> the >>>>>>> >>>> lines of: >>>>>>> >>>> >>>>>>> >>>> To retrieve a CDIContainer to launch, do this: >>>>>>> >>>> >>>>>>> >>>> CDIContainer container = CDIContainerLocator.getCDIContainer(); >>>>>>> >>>> container.initialize(); >>>>>>> >>>> ... do work >>>>>>> >>>> >>>>>>> >>>> Once you want to shutdown the container, do this: >>>>>>> >>>> >>>>>>> >>>> container.shutdown(); >>>>>>> >>>> >>>>>>> >>>> (we may want to consider implementing AutoCloseable, an >>>>>>> oversight on my >>>>>>> >>>> part) >>>>>>> >>>> >>>>>>> >>>> and then later on >>>>>>> >>>> >>>>>>> >>>> - What happens if I call CDIContainerLocator in an app server >>>>>>> >>>> >>>>>>> >>>> - It throws an IllegalStateException. >>>>>>> >>>> >>>>>>> >>>> - The container provides no beans of type CDIContainer, it is >>>>>>> managed >>>>>>> >>>> outside of the CDI container. >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> John >>>>>>> >>>>> >>>>>>> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger < >>>>>>> jharting at redhat.com> >>>>>>> >>>>> wrote: >>>>>>> >>>>>> >>>>>>> >>>>>> Hi John, some thoughts: >>>>>>> >>>>>> >>>>>>> >>>>>> - instead of using BeanManager it makes more sense to me to >>>>>>> return a >>>>>>> >>>>>> CDI >>>>>>> >>>>>> instance, which is a more user-friendly API (and it also >>>>>>> exposes >>>>>>> >>>>>> access to >>>>>>> >>>>>> BeanManager) >>>>>>> >>>>>> - is there a usecase for arbitrary keys of the "params" map >>>>>>> or is >>>>>>> >>>>>> Map sufficient? >>>>>>> >>>>>> - if we could move the shutdown() method from CDIContainer to >>>>>>> the >>>>>>> >>>>>> actual >>>>>>> >>>>>> container handle that we obtain from initialize(), that would >>>>>>> look >>>>>>> >>>>>> more >>>>>>> >>>>>> object-oriented >>>>>>> >>>>>> - what exactly is initialize() supposed to do? Is it supposed >>>>>>> to start >>>>>>> >>>>>> scanning the entire classpath for CDI beans? That could be a >>>>>>> problem >>>>>>> >>>>>> especially with spring-boot-like fat jars. I think we need an >>>>>>> API to >>>>>>> >>>>>> tell >>>>>>> >>>>>> the container which classes / packages to consider. Something >>>>>>> like >>>>>>> >>>>>> Guice's >>>>>>> >>>>>> binding API perhaps? >>>>>>> >>>>>> >>>>>>> >>>>>> - the proposal makes me wonder whether retrofitting this >>>>>>> functionality >>>>>>> >>>>>> to >>>>>>> >>>>>> the CDI class wouldn't be a better option. It could look like: >>>>>>> >>>>>> >>>>>>> >>>>>> CDI container = CDI.initialize(); >>>>>>> >>>>>> container.select(Foo.class).get(); >>>>>>> >>>>>> container.shutdown(); >>>>>>> >>>>>> >>>>>>> >>>>>> compare it to: >>>>>>> >>>>>> >>>>>>> >>>>>> CDIContainer container = CDIContainerLoader. >>>>>>> getCDIContainer(); >>>>>>> >>>>>> BeanManager manager = container.initialize(); >>>>>>> >>>>>> manager.getBeans(...); >>>>>>> >>>>>> container.shutdown(manager); >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >>>>>>> >>>>>> >>>>>>> >>>>>> All, >>>>>>> >>>>>> >>>>>>> >>>>>> I have the updated API here, and wanted to solicit any final >>>>>>> feedback >>>>>>> >>>>>> before updating the google doc and spec pages. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> https://github.com/johnament/cdi/commit/2c362161e18dd521f8e8 >>>>>>> 3c27151ddad467a1c01c >>>>>>> >>>>>> >>>>>>> >>>>>> Let me know your thoughts. >>>>>>> >>>>>> >>>>>>> >>>>>> Thanks, >>>>>>> >>>>>> >>>>>>> >>>>>> John >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>>> >>>>>> cdi-dev mailing list >>>>>>> >>>>>> cdi-dev at lists.jboss.org >>>>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>> >>>>>> >>>>>>> >>>>>> Note that for all code provided on this list, the provider >>>>>>> licenses >>>>>>> >>>>>> the >>>>>>> >>>>>> code under the Apache License, Version 2 >>>>>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all >>>>>>> other ideas >>>>>>> >>>>>> provided on this list, the provider waives all patent and >>>>>>> other >>>>>>> >>>>>> intellectual >>>>>>> >>>>>> property rights inherent in such information. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>> >>>>>>> >>>> _______________________________________________ >>>>>>> >>>> cdi-dev mailing list >>>>>>> >>>> cdi-dev at lists.jboss.org >>>>>>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>> >>>> >>>>>>> >>>> Note that for all code provided on this list, the provider >>>>>>> licenses the >>>>>>> >>>> code >>>>>>> >>>> under the Apache License, Version 2 >>>>>>> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all >>>>>>> other ideas >>>>>>> >>>> provided on this list, the provider waives all patent and other >>>>>>> >>>> intellectual >>>>>>> >>>> property rights inherent in such information. >>>>>>> >> >>>>>>> >> >>>>>>> > >>>>>>> >>>>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider licenses the >>>> code under the Apache License, Version 2 (http://www.apache.org/ >>>> licenses/LICENSE-2.0.html). For all other ideas provided on this list, >>>> the provider waives all patent and other intellectual property rights >>>> inherent in such information. >>>> >>>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>> provided on this list, the provider waives all patent and other >>> intellectual property rights inherent in such information. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/c55879c4/attachment-0001.html From john.d.ament at gmail.com Wed Mar 4 07:09:35 2015 From: john.d.ament at gmail.com (John D. Ament) Date: Wed, 04 Mar 2015 12:09:35 +0000 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) References: Message-ID: Same way as defined in the spec CDI.current().destroy(..) On Wed, Mar 4, 2015 at 6:44 AM Romain Manni-Bucau wrote: > hmm, and if the bean is @Dependent? how do you release it? > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2015-03-04 12:37 GMT+01:00 John D. Ament : > >> >> >> On Wed, Mar 4, 2015 at 6:35 AM Romain Manni-Bucau >> wrote: >> >>> 2015-03-04 12:29 GMT+01:00 John D. Ament : >>> >>>> Hmm.. comments in line. >>>> >>>> On Wed, Mar 4, 2015 at 4:49 AM Antoine Sabot-Durand < >>>> antoine at sabot-durand.net> wrote: >>>> >>>>> Hi John, >>>>> >>>>> I think it could be a good idea to write down all of these to have a >>>>> more stable doc for discussion. You should update the google doc with the >>>>> result of this discussion. >>>>> >>>>> I agree with the following points in this thread : >>>>> >>>>> - Minimize the number of new Class / Interface. CDI and CDIProvider >>>>> usage is still not very clear for end user so we should add the strict >>>>> minimum and try to enhance existing API / SPI when possible >>>>> >>>> >>>> It seems odd to me that we're rehashing decisions made during the EG >>>> meetings. Not putting it in CDI was discussed in several meetings at the >>>> beginning of the year, and it seemed like the agreement was putting it in >>>> CDI was a bad idea. >>>> >>>> >>>>> - Be able to bootstrap CDI without returning BeanManager (env if the >>>>> API give possibility to access it if needed). End user don?t need that : >>>>> CDI app can start with an observer for instance >>>>> >>>> >>>> Agreed, but I think we need to provide some entry point to allow those >>>> who aren't comfortable with programming with events to leverage it. >>>> Returning the CDI instance makes that easier to do than returning the >>>> BeanManager. >>>> >>>> >>> >>> Can you detail it please? CDI value is only its getBeanManager() method >>> IMO so it sounds like it is 1-1 for me. >>> >> >> >> Taken from the docs I"m working on: >> >> MyBean myBean = container.initialize().select(MyBean.class).get(); >> myBean.doWork(); >> >> Vs the 3-4 lines it takes to get a reference using just BeanManager. >> >> >>> >>> >>>> >>>>> Something not dealt with but that we should keep in mind : >>>>> - Providing a Java SE solution that could be easily used for a servlet >>>>> bootstrap of CDI. I don?t know if we?ll standardize this but we definitely >>>>> should keep this use case in mind >>>>> >>>>> and my bonus, it?s out of scope but I didn?t see anytime there that >>>>> prevent this nice to have: >>>>> - support the possibility to boot multiple BeanManager in Java SE. >>>>> >>>>> >>>> We talked about this one as well on the EG, either this year or late >>>> last year. I thought the decision at that time was that we wouldn't allow >>>> multiple containers at once in SE. >>>> >>>> >>> >>> wouldn't specify rather than wouldn't allow I think >>> >>> >>>> Antoine >>>>> >>>>> >>>>> Le 1 mars 2015 ? 15:13, John D. Ament a >>>>> ?crit : >>>>> >>>>> >>>>> So, I think I've gathered enough feedback at this point, and seen some >>>>> of the API changes. I'll hopefully be including some doc changes this >>>>> week, but one question - do we want to start the SE specific stuff as its >>>>> own asciidoc file? >>>>> >>>>> Changes made: >>>>> >>>>> - Changed return value to CDI to provide better capability out >>>>> of the box. >>>>> - Added AutoCloseable to CDIContainer, provided default implementation >>>>> of calling shutdown. >>>>> - Added synchronization support to the method body that retrieves the >>>>> singleton instance (BTW, I'm not sure if this is even useful TBH as each >>>>> impl, including the RI, needs to provide this class in its own format). >>>>> - Made the params map typed to >>>>> >>>>> @Romain Your case isn't really supportable yet, until we have static >>>>> injection support. You'd still have to have a managed version of Runner to >>>>> work against. >>>>> >>>>> John >>>>> >>>>> On Sat, Feb 28, 2015 at 4:11 PM Romain Manni-Bucau < >>>>> rmannibucau at gmail.com> wrote: >>>>> >>>>>> Yes but not the way to get an instance. Even Unmanaged does it. >>>>>> >>>>>> What can be awesome is to have static inject for it: >>>>>> >>>>>> public class Runner { >>>>>> >>>>>> @Inject >>>>>> private static MyMain main; >>>>>> >>>>>> public static void main(String[] arg) { >>>>>> try (CDIContainer c = CDIContainer.newContainer()) { >>>>>> main.doWork(); >>>>>> } >>>>>> } >>>>>> >>>>>> } >>>>>> >>>>>> And not a single additional line :). >>>>>> Le 28 f?vr. 2015 19:05, "John D. Ament" a >>>>>> ?crit : >>>>>> >>>>>> Maybe I'm misreading, but I don't see us adding another API to do the >>>>>>> same thing here - we're introducing new functionality. >>>>>>> >>>>>>> CDIContainer/Loader on startup/shutdown of the application >>>>>>> >>>>>>> CDI for runtime usage within the application to interact with the >>>>>>> container. >>>>>>> >>>>>>> John >>>>>>> >>>>>>> On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau < >>>>>>> rmannibucau at gmail.com> wrote: >>>>>>> >>>>>>>> sure I fully agree excepted I think introducing yet another API to >>>>>>>> do >>>>>>>> the same thing is not good so super tempting to skip it and wait for >>>>>>>> feedbacks rather than introducing it eagerly. >>>>>>>> >>>>>>>> >>>>>>>> Romain Manni-Bucau >>>>>>>> @rmannibucau >>>>>>>> http://www.tomitribe.com >>>>>>>> http://rmannibucau.wordpress.com >>>>>>>> https://github.com/rmannibucau >>>>>>>> >>>>>>>> >>>>>>>> 2015-02-27 8:05 GMT+01:00 Jozef Hartinger : >>>>>>>> > My point is that from the application perspective, the user >>>>>>>> obtains one >>>>>>>> > container handle for eventual shutdown (CDIContainer) and then >>>>>>>> looks up a >>>>>>>> > different container handle (CDI) that they can use for real work >>>>>>>> (lookup / >>>>>>>> > event dispatch / etc.) It would be cleaner if the container gave >>>>>>>> away a >>>>>>>> > single handle that can do all of that. >>>>>>>> > >>>>>>>> > >>>>>>>> > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: >>>>>>>> > >>>>>>>> > Not sure I get how a CDI instance can help. >>>>>>>> > >>>>>>>> > But container.getBeanManager() sounds nice is not a shortcut for >>>>>>>> > CDI.current().getBm() otherwise it looks like duplication to me. >>>>>>>> > >>>>>>>> > Can we make container not contextual - dont think so? If so it >>>>>>>> makes sense >>>>>>>> > otherwise I fear it doesnt add much. >>>>>>>> > >>>>>>>> > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" >>>>>>>> a ?crit : >>>>>>>> >> >>>>>>>> >> I like the initialize + close() combination and the >>>>>>>> try-with-resources >>>>>>>> >> usage. >>>>>>>> >> What looks weird to me is that at line one you obtain a >>>>>>>> container handle: >>>>>>>> >> >>>>>>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>>>>>> >> CDI.current().getBeanManager() ... >>>>>>>> >> >>>>>>>> >> and then at line two you call a static method to perform a >>>>>>>> container >>>>>>>> >> lookup :-/ >>>>>>>> >> >>>>>>>> >> An API that allows you to use the container handle you already >>>>>>>> got is way >>>>>>>> >> better IMO, e.g.: >>>>>>>> >> >>>>>>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>>>>>> >> container.getBeanManager() >>>>>>>> >> >>>>>>>> >> If CDIContainer.newCDIContainer() returns an CDI instance or its >>>>>>>> subclass, >>>>>>>> >> we get this easily. >>>>>>>> >> >>>>>>>> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: >>>>>>>> >>> >>>>>>>> >>> Hi guys >>>>>>>> >>> >>>>>>>> >>> why note keeping it simple? >>>>>>>> >>> >>>>>>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer(/* >>>>>>>> optional >>>>>>>> >>> map to configure vendor features */)) { >>>>>>>> >>> CDI.current().getBeanManager().... >>>>>>>> >>> } >>>>>>>> >>> >>>>>>>> >>> Not sure the point having initialize() + having shutdown = close >>>>>>>> >>> really makes the API more fluent and modern IMO. >>>>>>>> >>> >>>>>>>> >>> Also to be fully SE I guess provider() method would be needed >>>>>>>> even if >>>>>>>> >>> optional (SPI usage by default): >>>>>>>> >>> >>>>>>>> >>> try (CDIContainer container = >>>>>>>> >>> >>>>>>>> >>> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvid >>>>>>>> er").newCDIContainer()) >>>>>>>> >>> { >>>>>>>> >>> CDI.current().getBeanManager().... >>>>>>>> >>> } >>>>>>>> >>> >>>>>>>> >>> Finally I think having a kind of getInstance shortcut could be >>>>>>>> a plus for >>>>>>>> >>> SE: >>>>>>>> >>> >>>>>>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer()) { >>>>>>>> >>> container.newInstance(MyAppRunner.class /* optional >>>>>>>> qualifiers */ >>>>>>>> >>> ).run(args); >>>>>>>> >>> } >>>>>>>> >>> >>>>>>>> >>> Using container to get an instance would create the instance >>>>>>>> and bind >>>>>>>> >>> it to the container lifecycle (mainly for predestroy) avoiding >>>>>>>> this >>>>>>>> >>> boilerplate code in all main which will surely only be used to >>>>>>>> launch >>>>>>>> >>> a soft. >>>>>>>> >>> >>>>>>>> >>> wdyt? >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> Romain Manni-Bucau >>>>>>>> >>> @rmannibucau >>>>>>>> >>> http://www.tomitribe.com >>>>>>>> >>> http://rmannibucau.wordpress.com >>>>>>>> >>> https://github.com/rmannibucau >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger >>>>>>> >: >>>>>>>> >>>> >>>>>>>> >>>> Comments inline >>>>>>>> >>>> >>>>>>>> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: >>>>>>>> >>>> >>>>>>>> >>>> Sorry Jozef, your email fell into the pits of google inbox's >>>>>>>> "smart >>>>>>>> >>>> sorting" >>>>>>>> >>>> features. >>>>>>>> >>>> >>>>>>>> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger < >>>>>>>> jharting at redhat.com> >>>>>>>> >>>> wrote: >>>>>>>> >>>>> >>>>>>>> >>>>> Hi John, comments inline: >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >>>>>>>> >>>>> >>>>>>>> >>>>> Jozef, >>>>>>>> >>>>> >>>>>>>> >>>>> Most of what you see there is taken from the original doc, >>>>>>>> since >>>>>>>> >>>>> everyone >>>>>>>> >>>>> seemed to be in agreement. I think the map is just a >>>>>>>> safeguard in case >>>>>>>> >>>>> of >>>>>>>> >>>>> additional boot options available in some implementations >>>>>>>> (e.g. I think >>>>>>>> >>>>> OWB/OpenEJB have some options.. currently OpenEJB supports an >>>>>>>> embedded >>>>>>>> >>>>> CDI >>>>>>>> >>>>> boot mode). >>>>>>>> >>>>> >>>>>>>> >>>>> No, I am fine with the map. What I am questioning is the type >>>>>>>> of the >>>>>>>> >>>>> map. >>>>>>>> >>>>> Usually, data structures with a similar purpose use Strings >>>>>>>> as their >>>>>>>> >>>>> keys. >>>>>>>> >>>>> This applies to ServletContext attributes, InvocationContext >>>>>>>> data, >>>>>>>> >>>>> Servlet >>>>>>>> >>>>> request/session attributes and others. I am therefore >>>>>>>> wondering whether >>>>>>>> >>>>> there is a usecase for the proposed unbound key signature or >>>>>>>> not. >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> I think that's more of a placeholder, I was assuming it would >>>>>>>> be >>>>>>>> >>>> Map once we clarify everything. >>>>>>>> >>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> We spoke a few times about BeanManager vs CDI. BeanManager >>>>>>>> was >>>>>>>> >>>>> preferable >>>>>>>> >>>>> since there's no easy way to get the the instance, CDI is >>>>>>>> easier to get >>>>>>>> >>>>> and >>>>>>>> >>>>> more aligned with how you would get it. Usually people >>>>>>>> expect the >>>>>>>> >>>>> BeanManager to be injected or available via JNDI, neither >>>>>>>> would be the >>>>>>>> >>>>> case >>>>>>>> >>>>> here. >>>>>>>> >>>>> >>>>>>>> >>>>> If CDI 2.0 targets Java SE then this container initialization >>>>>>>> API will >>>>>>>> >>>>> become something that ordinary application developers use to >>>>>>>> start/stop >>>>>>>> >>>>> CDI >>>>>>>> >>>>> in their applications. It therefore cannot be considered an >>>>>>>> SPI but >>>>>>>> >>>>> instead >>>>>>>> >>>>> should be something easy to use. On the other hand, >>>>>>>> BeanManager is >>>>>>>> >>>>> definitely an SPI. It is used in extension, frameworks and >>>>>>>> generally >>>>>>>> >>>>> for >>>>>>>> >>>>> integration. Not much by applications directly. Therefore, I >>>>>>>> don't see >>>>>>>> >>>>> how >>>>>>>> >>>>> the container bootstrap API and BeanManager fit together. IMO >>>>>>>> the >>>>>>>> >>>>> bootstrap >>>>>>>> >>>>> API should expose something that makes common tasks >>>>>>>> (obtaining a >>>>>>>> >>>>> contextual >>>>>>>> >>>>> reference and firing and event) easy, which the CDI class >>>>>>>> does. >>>>>>>> >>>>> >>>>>>>> >>>>> Plus do not forget that BeanManager can be obtained easily >>>>>>>> using >>>>>>>> >>>>> CDI.getBeanManager(). >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> I'm not disagreeing. There's a few things I'd consider: >>>>>>>> >>>> >>>>>>>> >>>> - Is this mostly for new apps or existing? If existing, it's >>>>>>>> probably >>>>>>>> >>>> using >>>>>>>> >>>> some internal API, if new it can use whatever API we give. >>>>>>>> >>>> - I don't want to return void, we should give some kind of >>>>>>>> reference >>>>>>>> >>>> into >>>>>>>> >>>> the container when we're done booting. >>>>>>>> >>>> >>>>>>>> >>>> Agreed, we should not be returning void. >>>>>>>> >>>> >>>>>>>> >>>> - CDI is a one step retrievable reference, where as >>>>>>>> BeanManager is a two >>>>>>>> >>>> step reference. With that said, BeanManager makes more sense >>>>>>>> to return >>>>>>>> >>>> here. Another thought could be we invent some new class that >>>>>>>> has both, >>>>>>>> >>>> but >>>>>>>> >>>> that's really redundant. >>>>>>>> >>>> >>>>>>>> >>>> Why do you think BeanManager makes more sense here? Especially >>>>>>>> given the >>>>>>>> >>>> assumption that application code is going to call this >>>>>>>> init/shutdown >>>>>>>> >>>> API, I >>>>>>>> >>>> don't see BeanManager as making more sense. >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> Yes, this is the container start API. Sounds like you have >>>>>>>> some good >>>>>>>> >>>>> ideas for things like XML configuration or programmatic >>>>>>>> configuration, >>>>>>>> >>>>> both >>>>>>>> >>>>> of which are being tracked under separate tickets. One idea >>>>>>>> might be >>>>>>>> >>>>> for an >>>>>>>> >>>>> optional param in the map to control packages to scan/ignore, >>>>>>>> in that >>>>>>>> >>>>> map. >>>>>>>> >>>>> >>>>>>>> >>>>> I am wondering whether this configuration should be something >>>>>>>> optional >>>>>>>> >>>>> built on top of the bootstrap API or whether we should >>>>>>>> consider making >>>>>>>> >>>>> it >>>>>>>> >>>>> mandatory. Either way, we cannot add the bootstrap API to the >>>>>>>> spec >>>>>>>> >>>>> without >>>>>>>> >>>>> explicitly defining how it behaves. My implicit assumption of >>>>>>>> the >>>>>>>> >>>>> proposal >>>>>>>> >>>>> is that the container is supposed to scan the entire >>>>>>>> classpath for >>>>>>>> >>>>> explicit >>>>>>>> >>>>> or implicit bean archives (including e.g. rt.jar), discover >>>>>>>> beans, fire >>>>>>>> >>>>> extensions, etc. This worries me as this default behavior is >>>>>>>> far from >>>>>>>> >>>>> being >>>>>>>> >>>>> lightweight, which CDI for Java SE initially aimed to be. >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> Yes, the spec must be updated to reflect the behavior of SE >>>>>>>> mode. I >>>>>>>> >>>> plan to >>>>>>>> >>>> get that completely into the google doc before opening any >>>>>>>> spec changes >>>>>>>> >>>> in a >>>>>>>> >>>> PR. >>>>>>>> >>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> We didn't want to over load the CDI interface. It already >>>>>>>> does a lot. >>>>>>>> >>>>> This is really SPI code, CDI even though it's in the spi >>>>>>>> package is >>>>>>>> >>>>> used in >>>>>>>> >>>>> a lot of application code. >>>>>>>> >>>>> >>>>>>>> >>>>> I would personally prefer to have it all in one place. Having >>>>>>>> >>>>> CDIContainer, CDIContainerLoader, CDI and CDIProvider makes >>>>>>>> it more >>>>>>>> >>>>> difficult to know when to use what. >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> The problem is that most CDI (the interface) operations are >>>>>>>> against a >>>>>>>> >>>> running container. I think we spoke about leveraging >>>>>>>> CDIProvider at one >>>>>>>> >>>> point (in fact, I mistakenly called CDIContainer CDIProvider >>>>>>>> not even >>>>>>>> >>>> realizing it was there). I doubt that most app developers use >>>>>>>> it >>>>>>>> >>>> currently, >>>>>>>> >>>> there's not even a way to get a reference to it that I'm aware >>>>>>>> of. It's >>>>>>>> >>>> used by the implementor only. >>>>>>>> >>>> >>>>>>>> >>>> I don't think there's a conflict. CDI class would still only >>>>>>>> provide >>>>>>>> >>>> methods >>>>>>>> >>>> to be run against a running container. The difference is that >>>>>>>> there >>>>>>>> >>>> would be >>>>>>>> >>>> additional static methods to get this running container (CDI >>>>>>>> class) to >>>>>>>> >>>> you >>>>>>>> >>>> by starting the container. >>>>>>>> >>>> >>>>>>>> >>>> Either way, I agree that reusing CDIProvider is a must. There >>>>>>>> is no >>>>>>>> >>>> reason >>>>>>>> >>>> to define a new class for the same purpose. >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> I expect that my changes in the CDI spec around this will >>>>>>>> state, along >>>>>>>> >>>> the >>>>>>>> >>>> lines of: >>>>>>>> >>>> >>>>>>>> >>>> To retrieve a CDIContainer to launch, do this: >>>>>>>> >>>> >>>>>>>> >>>> CDIContainer container = CDIContainerLocator.getCDICont >>>>>>>> ainer(); >>>>>>>> >>>> container.initialize(); >>>>>>>> >>>> ... do work >>>>>>>> >>>> >>>>>>>> >>>> Once you want to shutdown the container, do this: >>>>>>>> >>>> >>>>>>>> >>>> container.shutdown(); >>>>>>>> >>>> >>>>>>>> >>>> (we may want to consider implementing AutoCloseable, an >>>>>>>> oversight on my >>>>>>>> >>>> part) >>>>>>>> >>>> >>>>>>>> >>>> and then later on >>>>>>>> >>>> >>>>>>>> >>>> - What happens if I call CDIContainerLocator in an app server >>>>>>>> >>>> >>>>>>>> >>>> - It throws an IllegalStateException. >>>>>>>> >>>> >>>>>>>> >>>> - The container provides no beans of type CDIContainer, it is >>>>>>>> managed >>>>>>>> >>>> outside of the CDI container. >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> John >>>>>>>> >>>>> >>>>>>>> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger < >>>>>>>> jharting at redhat.com> >>>>>>>> >>>>> wrote: >>>>>>>> >>>>>> >>>>>>>> >>>>>> Hi John, some thoughts: >>>>>>>> >>>>>> >>>>>>>> >>>>>> - instead of using BeanManager it makes more sense to me to >>>>>>>> return a >>>>>>>> >>>>>> CDI >>>>>>>> >>>>>> instance, which is a more user-friendly API (and it also >>>>>>>> exposes >>>>>>>> >>>>>> access to >>>>>>>> >>>>>> BeanManager) >>>>>>>> >>>>>> - is there a usecase for arbitrary keys of the "params" map >>>>>>>> or is >>>>>>>> >>>>>> Map sufficient? >>>>>>>> >>>>>> - if we could move the shutdown() method from CDIContainer >>>>>>>> to the >>>>>>>> >>>>>> actual >>>>>>>> >>>>>> container handle that we obtain from initialize(), that >>>>>>>> would look >>>>>>>> >>>>>> more >>>>>>>> >>>>>> object-oriented >>>>>>>> >>>>>> - what exactly is initialize() supposed to do? Is it >>>>>>>> supposed to start >>>>>>>> >>>>>> scanning the entire classpath for CDI beans? That could be a >>>>>>>> problem >>>>>>>> >>>>>> especially with spring-boot-like fat jars. I think we need >>>>>>>> an API to >>>>>>>> >>>>>> tell >>>>>>>> >>>>>> the container which classes / packages to consider. >>>>>>>> Something like >>>>>>>> >>>>>> Guice's >>>>>>>> >>>>>> binding API perhaps? >>>>>>>> >>>>>> >>>>>>>> >>>>>> - the proposal makes me wonder whether retrofitting this >>>>>>>> functionality >>>>>>>> >>>>>> to >>>>>>>> >>>>>> the CDI class wouldn't be a better option. It could look >>>>>>>> like: >>>>>>>> >>>>>> >>>>>>>> >>>>>> CDI container = CDI.initialize(); >>>>>>>> >>>>>> container.select(Foo.class).get(); >>>>>>>> >>>>>> container.shutdown(); >>>>>>>> >>>>>> >>>>>>>> >>>>>> compare it to: >>>>>>>> >>>>>> >>>>>>>> >>>>>> CDIContainer container = CDIContainerLoader. >>>>>>>> getCDIContainer(); >>>>>>>> >>>>>> BeanManager manager = container.initialize(); >>>>>>>> >>>>>> manager.getBeans(...); >>>>>>>> >>>>>> container.shutdown(manager); >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >>>>>>>> >>>>>> >>>>>>>> >>>>>> All, >>>>>>>> >>>>>> >>>>>>>> >>>>>> I have the updated API here, and wanted to solicit any final >>>>>>>> feedback >>>>>>>> >>>>>> before updating the google doc and spec pages. >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> https://github.com/johnament/cdi/commit/2c362161e18dd521f8e8 >>>>>>>> 3c27151ddad467a1c01c >>>>>>>> >>>>>> >>>>>>>> >>>>>> Let me know your thoughts. >>>>>>>> >>>>>> >>>>>>>> >>>>>> Thanks, >>>>>>>> >>>>>> >>>>>>>> >>>>>> John >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> _______________________________________________ >>>>>>>> >>>>>> cdi-dev mailing list >>>>>>>> >>>>>> cdi-dev at lists.jboss.org >>>>>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>> >>>>>> >>>>>>>> >>>>>> Note that for all code provided on this list, the provider >>>>>>>> licenses >>>>>>>> >>>>>> the >>>>>>>> >>>>>> code under the Apache License, Version 2 >>>>>>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all >>>>>>>> other ideas >>>>>>>> >>>>>> provided on this list, the provider waives all patent and >>>>>>>> other >>>>>>>> >>>>>> intellectual >>>>>>>> >>>>>> property rights inherent in such information. >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>> >>>>>>>> >>>> _______________________________________________ >>>>>>>> >>>> cdi-dev mailing list >>>>>>>> >>>> cdi-dev at lists.jboss.org >>>>>>>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>> >>>> >>>>>>>> >>>> Note that for all code provided on this list, the provider >>>>>>>> licenses the >>>>>>>> >>>> code >>>>>>>> >>>> under the Apache License, Version 2 >>>>>>>> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all >>>>>>>> other ideas >>>>>>>> >>>> provided on this list, the provider waives all patent and other >>>>>>>> >>>> intellectual >>>>>>>> >>>> property rights inherent in such information. >>>>>>>> >> >>>>>>>> >> >>>>>>>> > >>>>>>>> >>>>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>> Note that for all code provided on this list, the provider licenses >>>>> the code under the Apache License, Version 2 (http://www.apache.org/ >>>>> licenses/LICENSE-2.0.html). For all other ideas provided on this >>>>> list, the provider waives all patent and other intellectual property rights >>>>> inherent in such information. >>>>> >>>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider licenses the >>>> code under the Apache License, Version 2 ( >>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>>> provided on this list, the provider waives all patent and other >>>> intellectual property rights inherent in such information. >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/bcbaeed5/attachment-0001.html From rmannibucau at gmail.com Wed Mar 4 07:28:30 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 4 Mar 2015 13:28:30 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: References: Message-ID: ok, initialize was returning a CDI instance then. If CDI instance is so present why bothering container api with it? Just looks like another Unmanaged. In this case I would enhance Unmanaged to have shortcut like create() (shortcut for produce()/inject()/postConstruct() ) and destroy (preDestroy()/dispose()). Said otherwise: the need is already in the API so why not letting EE getting these enhancement as well? Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-03-04 13:09 GMT+01:00 John D. Ament : > Same way as defined in the spec > > CDI.current().destroy(..) > > On Wed, Mar 4, 2015 at 6:44 AM Romain Manni-Bucau > wrote: > >> hmm, and if the bean is @Dependent? how do you release it? >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> 2015-03-04 12:37 GMT+01:00 John D. Ament : >> >>> >>> >>> On Wed, Mar 4, 2015 at 6:35 AM Romain Manni-Bucau >>> wrote: >>> >>>> 2015-03-04 12:29 GMT+01:00 John D. Ament : >>>> >>>>> Hmm.. comments in line. >>>>> >>>>> On Wed, Mar 4, 2015 at 4:49 AM Antoine Sabot-Durand < >>>>> antoine at sabot-durand.net> wrote: >>>>> >>>>>> Hi John, >>>>>> >>>>>> I think it could be a good idea to write down all of these to have a >>>>>> more stable doc for discussion. You should update the google doc with the >>>>>> result of this discussion. >>>>>> >>>>>> I agree with the following points in this thread : >>>>>> >>>>>> - Minimize the number of new Class / Interface. CDI and CDIProvider >>>>>> usage is still not very clear for end user so we should add the strict >>>>>> minimum and try to enhance existing API / SPI when possible >>>>>> >>>>> >>>>> It seems odd to me that we're rehashing decisions made during the EG >>>>> meetings. Not putting it in CDI was discussed in several meetings at the >>>>> beginning of the year, and it seemed like the agreement was putting it in >>>>> CDI was a bad idea. >>>>> >>>>> >>>>>> - Be able to bootstrap CDI without returning BeanManager (env if the >>>>>> API give possibility to access it if needed). End user don?t need that : >>>>>> CDI app can start with an observer for instance >>>>>> >>>>> >>>>> Agreed, but I think we need to provide some entry point to allow those >>>>> who aren't comfortable with programming with events to leverage it. >>>>> Returning the CDI instance makes that easier to do than returning the >>>>> BeanManager. >>>>> >>>>> >>>> >>>> Can you detail it please? CDI value is only its getBeanManager() method >>>> IMO so it sounds like it is 1-1 for me. >>>> >>> >>> >>> Taken from the docs I"m working on: >>> >>> MyBean myBean = container.initialize().select(MyBean.class).get(); >>> myBean.doWork(); >>> >>> Vs the 3-4 lines it takes to get a reference using just BeanManager. >>> >>> >>>> >>>> >>>>> >>>>>> Something not dealt with but that we should keep in mind : >>>>>> - Providing a Java SE solution that could be easily used for a >>>>>> servlet bootstrap of CDI. I don?t know if we?ll standardize this but we >>>>>> definitely should keep this use case in mind >>>>>> >>>>>> and my bonus, it?s out of scope but I didn?t see anytime there that >>>>>> prevent this nice to have: >>>>>> - support the possibility to boot multiple BeanManager in Java SE. >>>>>> >>>>>> >>>>> We talked about this one as well on the EG, either this year or late >>>>> last year. I thought the decision at that time was that we wouldn't allow >>>>> multiple containers at once in SE. >>>>> >>>>> >>>> >>>> wouldn't specify rather than wouldn't allow I think >>>> >>>> >>>>> Antoine >>>>>> >>>>>> >>>>>> Le 1 mars 2015 ? 15:13, John D. Ament a >>>>>> ?crit : >>>>>> >>>>>> >>>>>> So, I think I've gathered enough feedback at this point, and seen >>>>>> some of the API changes. I'll hopefully be including some doc changes this >>>>>> week, but one question - do we want to start the SE specific stuff as its >>>>>> own asciidoc file? >>>>>> >>>>>> Changes made: >>>>>> >>>>>> - Changed return value to CDI to provide better capability >>>>>> out of the box. >>>>>> - Added AutoCloseable to CDIContainer, provided default >>>>>> implementation of calling shutdown. >>>>>> - Added synchronization support to the method body that retrieves the >>>>>> singleton instance (BTW, I'm not sure if this is even useful TBH as each >>>>>> impl, including the RI, needs to provide this class in its own format). >>>>>> - Made the params map typed to >>>>>> >>>>>> @Romain Your case isn't really supportable yet, until we have static >>>>>> injection support. You'd still have to have a managed version of Runner to >>>>>> work against. >>>>>> >>>>>> John >>>>>> >>>>>> On Sat, Feb 28, 2015 at 4:11 PM Romain Manni-Bucau < >>>>>> rmannibucau at gmail.com> wrote: >>>>>> >>>>>>> Yes but not the way to get an instance. Even Unmanaged does it. >>>>>>> >>>>>>> What can be awesome is to have static inject for it: >>>>>>> >>>>>>> public class Runner { >>>>>>> >>>>>>> @Inject >>>>>>> private static MyMain main; >>>>>>> >>>>>>> public static void main(String[] arg) { >>>>>>> try (CDIContainer c = CDIContainer.newContainer()) { >>>>>>> main.doWork(); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> } >>>>>>> >>>>>>> And not a single additional line :). >>>>>>> Le 28 f?vr. 2015 19:05, "John D. Ament" a >>>>>>> ?crit : >>>>>>> >>>>>>> Maybe I'm misreading, but I don't see us adding another API to do >>>>>>>> the same thing here - we're introducing new functionality. >>>>>>>> >>>>>>>> CDIContainer/Loader on startup/shutdown of the application >>>>>>>> >>>>>>>> CDI for runtime usage within the application to interact with the >>>>>>>> container. >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>>> On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau < >>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>> >>>>>>>>> sure I fully agree excepted I think introducing yet another API to >>>>>>>>> do >>>>>>>>> the same thing is not good so super tempting to skip it and wait >>>>>>>>> for >>>>>>>>> feedbacks rather than introducing it eagerly. >>>>>>>>> >>>>>>>>> >>>>>>>>> Romain Manni-Bucau >>>>>>>>> @rmannibucau >>>>>>>>> http://www.tomitribe.com >>>>>>>>> http://rmannibucau.wordpress.com >>>>>>>>> https://github.com/rmannibucau >>>>>>>>> >>>>>>>>> >>>>>>>>> 2015-02-27 8:05 GMT+01:00 Jozef Hartinger : >>>>>>>>> > My point is that from the application perspective, the user >>>>>>>>> obtains one >>>>>>>>> > container handle for eventual shutdown (CDIContainer) and then >>>>>>>>> looks up a >>>>>>>>> > different container handle (CDI) that they can use for real work >>>>>>>>> (lookup / >>>>>>>>> > event dispatch / etc.) It would be cleaner if the container gave >>>>>>>>> away a >>>>>>>>> > single handle that can do all of that. >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: >>>>>>>>> > >>>>>>>>> > Not sure I get how a CDI instance can help. >>>>>>>>> > >>>>>>>>> > But container.getBeanManager() sounds nice is not a shortcut for >>>>>>>>> > CDI.current().getBm() otherwise it looks like duplication to me. >>>>>>>>> > >>>>>>>>> > Can we make container not contextual - dont think so? If so it >>>>>>>>> makes sense >>>>>>>>> > otherwise I fear it doesnt add much. >>>>>>>>> > >>>>>>>>> > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" >>>>>>>>> a ?crit : >>>>>>>>> >> >>>>>>>>> >> I like the initialize + close() combination and the >>>>>>>>> try-with-resources >>>>>>>>> >> usage. >>>>>>>>> >> What looks weird to me is that at line one you obtain a >>>>>>>>> container handle: >>>>>>>>> >> >>>>>>>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>>>>>>> >> CDI.current().getBeanManager() ... >>>>>>>>> >> >>>>>>>>> >> and then at line two you call a static method to perform a >>>>>>>>> container >>>>>>>>> >> lookup :-/ >>>>>>>>> >> >>>>>>>>> >> An API that allows you to use the container handle you already >>>>>>>>> got is way >>>>>>>>> >> better IMO, e.g.: >>>>>>>>> >> >>>>>>>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>>>>>>> >> container.getBeanManager() >>>>>>>>> >> >>>>>>>>> >> If CDIContainer.newCDIContainer() returns an CDI instance or >>>>>>>>> its subclass, >>>>>>>>> >> we get this easily. >>>>>>>>> >> >>>>>>>>> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: >>>>>>>>> >>> >>>>>>>>> >>> Hi guys >>>>>>>>> >>> >>>>>>>>> >>> why note keeping it simple? >>>>>>>>> >>> >>>>>>>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer(/* >>>>>>>>> optional >>>>>>>>> >>> map to configure vendor features */)) { >>>>>>>>> >>> CDI.current().getBeanManager().... >>>>>>>>> >>> } >>>>>>>>> >>> >>>>>>>>> >>> Not sure the point having initialize() + having shutdown = >>>>>>>>> close >>>>>>>>> >>> really makes the API more fluent and modern IMO. >>>>>>>>> >>> >>>>>>>>> >>> Also to be fully SE I guess provider() method would be needed >>>>>>>>> even if >>>>>>>>> >>> optional (SPI usage by default): >>>>>>>>> >>> >>>>>>>>> >>> try (CDIContainer container = >>>>>>>>> >>> >>>>>>>>> >>> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvid >>>>>>>>> er").newCDIContainer()) >>>>>>>>> >>> { >>>>>>>>> >>> CDI.current().getBeanManager().... >>>>>>>>> >>> } >>>>>>>>> >>> >>>>>>>>> >>> Finally I think having a kind of getInstance shortcut could be >>>>>>>>> a plus for >>>>>>>>> >>> SE: >>>>>>>>> >>> >>>>>>>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer()) >>>>>>>>> { >>>>>>>>> >>> container.newInstance(MyAppRunner.class /* optional >>>>>>>>> qualifiers */ >>>>>>>>> >>> ).run(args); >>>>>>>>> >>> } >>>>>>>>> >>> >>>>>>>>> >>> Using container to get an instance would create the instance >>>>>>>>> and bind >>>>>>>>> >>> it to the container lifecycle (mainly for predestroy) avoiding >>>>>>>>> this >>>>>>>>> >>> boilerplate code in all main which will surely only be used to >>>>>>>>> launch >>>>>>>>> >>> a soft. >>>>>>>>> >>> >>>>>>>>> >>> wdyt? >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> Romain Manni-Bucau >>>>>>>>> >>> @rmannibucau >>>>>>>>> >>> http://www.tomitribe.com >>>>>>>>> >>> http://rmannibucau.wordpress.com >>>>>>>>> >>> https://github.com/rmannibucau >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger >>>>>>>> >: >>>>>>>>> >>>> >>>>>>>>> >>>> Comments inline >>>>>>>>> >>>> >>>>>>>>> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: >>>>>>>>> >>>> >>>>>>>>> >>>> Sorry Jozef, your email fell into the pits of google inbox's >>>>>>>>> "smart >>>>>>>>> >>>> sorting" >>>>>>>>> >>>> features. >>>>>>>>> >>>> >>>>>>>>> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger < >>>>>>>>> jharting at redhat.com> >>>>>>>>> >>>> wrote: >>>>>>>>> >>>>> >>>>>>>>> >>>>> Hi John, comments inline: >>>>>>>>> >>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >>>>>>>>> >>>>> >>>>>>>>> >>>>> Jozef, >>>>>>>>> >>>>> >>>>>>>>> >>>>> Most of what you see there is taken from the original doc, >>>>>>>>> since >>>>>>>>> >>>>> everyone >>>>>>>>> >>>>> seemed to be in agreement. I think the map is just a >>>>>>>>> safeguard in case >>>>>>>>> >>>>> of >>>>>>>>> >>>>> additional boot options available in some implementations >>>>>>>>> (e.g. I think >>>>>>>>> >>>>> OWB/OpenEJB have some options.. currently OpenEJB supports >>>>>>>>> an embedded >>>>>>>>> >>>>> CDI >>>>>>>>> >>>>> boot mode). >>>>>>>>> >>>>> >>>>>>>>> >>>>> No, I am fine with the map. What I am questioning is the >>>>>>>>> type of the >>>>>>>>> >>>>> map. >>>>>>>>> >>>>> Usually, data structures with a similar purpose use Strings >>>>>>>>> as their >>>>>>>>> >>>>> keys. >>>>>>>>> >>>>> This applies to ServletContext attributes, InvocationContext >>>>>>>>> data, >>>>>>>>> >>>>> Servlet >>>>>>>>> >>>>> request/session attributes and others. I am therefore >>>>>>>>> wondering whether >>>>>>>>> >>>>> there is a usecase for the proposed unbound key signature or >>>>>>>>> not. >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> I think that's more of a placeholder, I was assuming it would >>>>>>>>> be >>>>>>>>> >>>> Map once we clarify everything. >>>>>>>>> >>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>> We spoke a few times about BeanManager vs CDI. BeanManager >>>>>>>>> was >>>>>>>>> >>>>> preferable >>>>>>>>> >>>>> since there's no easy way to get the the instance, CDI is >>>>>>>>> easier to get >>>>>>>>> >>>>> and >>>>>>>>> >>>>> more aligned with how you would get it. Usually people >>>>>>>>> expect the >>>>>>>>> >>>>> BeanManager to be injected or available via JNDI, neither >>>>>>>>> would be the >>>>>>>>> >>>>> case >>>>>>>>> >>>>> here. >>>>>>>>> >>>>> >>>>>>>>> >>>>> If CDI 2.0 targets Java SE then this container >>>>>>>>> initialization API will >>>>>>>>> >>>>> become something that ordinary application developers use to >>>>>>>>> start/stop >>>>>>>>> >>>>> CDI >>>>>>>>> >>>>> in their applications. It therefore cannot be considered an >>>>>>>>> SPI but >>>>>>>>> >>>>> instead >>>>>>>>> >>>>> should be something easy to use. On the other hand, >>>>>>>>> BeanManager is >>>>>>>>> >>>>> definitely an SPI. It is used in extension, frameworks and >>>>>>>>> generally >>>>>>>>> >>>>> for >>>>>>>>> >>>>> integration. Not much by applications directly. Therefore, I >>>>>>>>> don't see >>>>>>>>> >>>>> how >>>>>>>>> >>>>> the container bootstrap API and BeanManager fit together. >>>>>>>>> IMO the >>>>>>>>> >>>>> bootstrap >>>>>>>>> >>>>> API should expose something that makes common tasks >>>>>>>>> (obtaining a >>>>>>>>> >>>>> contextual >>>>>>>>> >>>>> reference and firing and event) easy, which the CDI class >>>>>>>>> does. >>>>>>>>> >>>>> >>>>>>>>> >>>>> Plus do not forget that BeanManager can be obtained easily >>>>>>>>> using >>>>>>>>> >>>>> CDI.getBeanManager(). >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> I'm not disagreeing. There's a few things I'd consider: >>>>>>>>> >>>> >>>>>>>>> >>>> - Is this mostly for new apps or existing? If existing, it's >>>>>>>>> probably >>>>>>>>> >>>> using >>>>>>>>> >>>> some internal API, if new it can use whatever API we give. >>>>>>>>> >>>> - I don't want to return void, we should give some kind of >>>>>>>>> reference >>>>>>>>> >>>> into >>>>>>>>> >>>> the container when we're done booting. >>>>>>>>> >>>> >>>>>>>>> >>>> Agreed, we should not be returning void. >>>>>>>>> >>>> >>>>>>>>> >>>> - CDI is a one step retrievable reference, where as >>>>>>>>> BeanManager is a two >>>>>>>>> >>>> step reference. With that said, BeanManager makes more sense >>>>>>>>> to return >>>>>>>>> >>>> here. Another thought could be we invent some new class that >>>>>>>>> has both, >>>>>>>>> >>>> but >>>>>>>>> >>>> that's really redundant. >>>>>>>>> >>>> >>>>>>>>> >>>> Why do you think BeanManager makes more sense here? >>>>>>>>> Especially given the >>>>>>>>> >>>> assumption that application code is going to call this >>>>>>>>> init/shutdown >>>>>>>>> >>>> API, I >>>>>>>>> >>>> don't see BeanManager as making more sense. >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>> Yes, this is the container start API. Sounds like you have >>>>>>>>> some good >>>>>>>>> >>>>> ideas for things like XML configuration or programmatic >>>>>>>>> configuration, >>>>>>>>> >>>>> both >>>>>>>>> >>>>> of which are being tracked under separate tickets. One idea >>>>>>>>> might be >>>>>>>>> >>>>> for an >>>>>>>>> >>>>> optional param in the map to control packages to >>>>>>>>> scan/ignore, in that >>>>>>>>> >>>>> map. >>>>>>>>> >>>>> >>>>>>>>> >>>>> I am wondering whether this configuration should be >>>>>>>>> something optional >>>>>>>>> >>>>> built on top of the bootstrap API or whether we should >>>>>>>>> consider making >>>>>>>>> >>>>> it >>>>>>>>> >>>>> mandatory. Either way, we cannot add the bootstrap API to >>>>>>>>> the spec >>>>>>>>> >>>>> without >>>>>>>>> >>>>> explicitly defining how it behaves. My implicit assumption >>>>>>>>> of the >>>>>>>>> >>>>> proposal >>>>>>>>> >>>>> is that the container is supposed to scan the entire >>>>>>>>> classpath for >>>>>>>>> >>>>> explicit >>>>>>>>> >>>>> or implicit bean archives (including e.g. rt.jar), discover >>>>>>>>> beans, fire >>>>>>>>> >>>>> extensions, etc. This worries me as this default behavior is >>>>>>>>> far from >>>>>>>>> >>>>> being >>>>>>>>> >>>>> lightweight, which CDI for Java SE initially aimed to be. >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> Yes, the spec must be updated to reflect the behavior of SE >>>>>>>>> mode. I >>>>>>>>> >>>> plan to >>>>>>>>> >>>> get that completely into the google doc before opening any >>>>>>>>> spec changes >>>>>>>>> >>>> in a >>>>>>>>> >>>> PR. >>>>>>>>> >>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>> We didn't want to over load the CDI interface. It already >>>>>>>>> does a lot. >>>>>>>>> >>>>> This is really SPI code, CDI even though it's in the spi >>>>>>>>> package is >>>>>>>>> >>>>> used in >>>>>>>>> >>>>> a lot of application code. >>>>>>>>> >>>>> >>>>>>>>> >>>>> I would personally prefer to have it all in one place. Having >>>>>>>>> >>>>> CDIContainer, CDIContainerLoader, CDI and CDIProvider makes >>>>>>>>> it more >>>>>>>>> >>>>> difficult to know when to use what. >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> The problem is that most CDI (the interface) operations are >>>>>>>>> against a >>>>>>>>> >>>> running container. I think we spoke about leveraging >>>>>>>>> CDIProvider at one >>>>>>>>> >>>> point (in fact, I mistakenly called CDIContainer CDIProvider >>>>>>>>> not even >>>>>>>>> >>>> realizing it was there). I doubt that most app developers >>>>>>>>> use it >>>>>>>>> >>>> currently, >>>>>>>>> >>>> there's not even a way to get a reference to it that I'm >>>>>>>>> aware of. It's >>>>>>>>> >>>> used by the implementor only. >>>>>>>>> >>>> >>>>>>>>> >>>> I don't think there's a conflict. CDI class would still only >>>>>>>>> provide >>>>>>>>> >>>> methods >>>>>>>>> >>>> to be run against a running container. The difference is that >>>>>>>>> there >>>>>>>>> >>>> would be >>>>>>>>> >>>> additional static methods to get this running container (CDI >>>>>>>>> class) to >>>>>>>>> >>>> you >>>>>>>>> >>>> by starting the container. >>>>>>>>> >>>> >>>>>>>>> >>>> Either way, I agree that reusing CDIProvider is a must. There >>>>>>>>> is no >>>>>>>>> >>>> reason >>>>>>>>> >>>> to define a new class for the same purpose. >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> I expect that my changes in the CDI spec around this will >>>>>>>>> state, along >>>>>>>>> >>>> the >>>>>>>>> >>>> lines of: >>>>>>>>> >>>> >>>>>>>>> >>>> To retrieve a CDIContainer to launch, do this: >>>>>>>>> >>>> >>>>>>>>> >>>> CDIContainer container = CDIContainerLocator.getCDICont >>>>>>>>> ainer(); >>>>>>>>> >>>> container.initialize(); >>>>>>>>> >>>> ... do work >>>>>>>>> >>>> >>>>>>>>> >>>> Once you want to shutdown the container, do this: >>>>>>>>> >>>> >>>>>>>>> >>>> container.shutdown(); >>>>>>>>> >>>> >>>>>>>>> >>>> (we may want to consider implementing AutoCloseable, an >>>>>>>>> oversight on my >>>>>>>>> >>>> part) >>>>>>>>> >>>> >>>>>>>>> >>>> and then later on >>>>>>>>> >>>> >>>>>>>>> >>>> - What happens if I call CDIContainerLocator in an app server >>>>>>>>> >>>> >>>>>>>>> >>>> - It throws an IllegalStateException. >>>>>>>>> >>>> >>>>>>>>> >>>> - The container provides no beans of type CDIContainer, it is >>>>>>>>> managed >>>>>>>>> >>>> outside of the CDI container. >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>> John >>>>>>>>> >>>>> >>>>>>>>> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger < >>>>>>>>> jharting at redhat.com> >>>>>>>>> >>>>> wrote: >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> Hi John, some thoughts: >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> - instead of using BeanManager it makes more sense to me to >>>>>>>>> return a >>>>>>>>> >>>>>> CDI >>>>>>>>> >>>>>> instance, which is a more user-friendly API (and it also >>>>>>>>> exposes >>>>>>>>> >>>>>> access to >>>>>>>>> >>>>>> BeanManager) >>>>>>>>> >>>>>> - is there a usecase for arbitrary keys of the "params" map >>>>>>>>> or is >>>>>>>>> >>>>>> Map sufficient? >>>>>>>>> >>>>>> - if we could move the shutdown() method from CDIContainer >>>>>>>>> to the >>>>>>>>> >>>>>> actual >>>>>>>>> >>>>>> container handle that we obtain from initialize(), that >>>>>>>>> would look >>>>>>>>> >>>>>> more >>>>>>>>> >>>>>> object-oriented >>>>>>>>> >>>>>> - what exactly is initialize() supposed to do? Is it >>>>>>>>> supposed to start >>>>>>>>> >>>>>> scanning the entire classpath for CDI beans? That could be >>>>>>>>> a problem >>>>>>>>> >>>>>> especially with spring-boot-like fat jars. I think we need >>>>>>>>> an API to >>>>>>>>> >>>>>> tell >>>>>>>>> >>>>>> the container which classes / packages to consider. >>>>>>>>> Something like >>>>>>>>> >>>>>> Guice's >>>>>>>>> >>>>>> binding API perhaps? >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> - the proposal makes me wonder whether retrofitting this >>>>>>>>> functionality >>>>>>>>> >>>>>> to >>>>>>>>> >>>>>> the CDI class wouldn't be a better option. It could look >>>>>>>>> like: >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> CDI container = CDI.initialize(); >>>>>>>>> >>>>>> container.select(Foo.class).get(); >>>>>>>>> >>>>>> container.shutdown(); >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> compare it to: >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> CDIContainer container = CDIContainerLoader. >>>>>>>>> getCDIContainer(); >>>>>>>>> >>>>>> BeanManager manager = container.initialize(); >>>>>>>>> >>>>>> manager.getBeans(...); >>>>>>>>> >>>>>> container.shutdown(manager); >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> All, >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> I have the updated API here, and wanted to solicit any >>>>>>>>> final feedback >>>>>>>>> >>>>>> before updating the google doc and spec pages. >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> https://github.com/johnament/cdi/commit/ >>>>>>>>> 2c362161e18dd521f8e83c27151ddad467a1c01c >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> Let me know your thoughts. >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> Thanks, >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> John >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> _______________________________________________ >>>>>>>>> >>>>>> cdi-dev mailing list >>>>>>>>> >>>>>> cdi-dev at lists.jboss.org >>>>>>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> Note that for all code provided on this list, the provider >>>>>>>>> licenses >>>>>>>>> >>>>>> the >>>>>>>>> >>>>>> code under the Apache License, Version 2 >>>>>>>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all >>>>>>>>> other ideas >>>>>>>>> >>>>>> provided on this list, the provider waives all patent and >>>>>>>>> other >>>>>>>>> >>>>>> intellectual >>>>>>>>> >>>>>> property rights inherent in such information. >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> >>>> >>>>>>>>> >>>> _______________________________________________ >>>>>>>>> >>>> cdi-dev mailing list >>>>>>>>> >>>> cdi-dev at lists.jboss.org >>>>>>>>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>>> >>>> >>>>>>>>> >>>> Note that for all code provided on this list, the provider >>>>>>>>> licenses the >>>>>>>>> >>>> code >>>>>>>>> >>>> under the Apache License, Version 2 >>>>>>>>> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all >>>>>>>>> other ideas >>>>>>>>> >>>> provided on this list, the provider waives all patent and >>>>>>>>> other >>>>>>>>> >>>> intellectual >>>>>>>>> >>>> property rights inherent in such information. >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> > >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>> cdi-dev mailing list >>>>>> cdi-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>> >>>>>> Note that for all code provided on this list, the provider licenses >>>>>> the code under the Apache License, Version 2 (http://www.apache.org/ >>>>>> licenses/LICENSE-2.0.html). For all other ideas provided on this >>>>>> list, the provider waives all patent and other intellectual property rights >>>>>> inherent in such information. >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>> Note that for all code provided on this list, the provider licenses >>>>> the code under the Apache License, Version 2 ( >>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>>>> provided on this list, the provider waives all patent and other >>>>> intellectual property rights inherent in such information. >>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/347d70fd/attachment-0001.html From john.d.ament at gmail.com Wed Mar 4 07:31:53 2015 From: john.d.ament at gmail.com (John D. Ament) Date: Wed, 04 Mar 2015 12:31:53 +0000 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) References: Message-ID: Get what enhancements? On Wed, Mar 4, 2015 at 7:28 AM Romain Manni-Bucau wrote: > ok, initialize was returning a CDI instance then. > > If CDI instance is so present why bothering container api with it? Just > looks like another Unmanaged. In this case I would enhance Unmanaged to > have shortcut like create() (shortcut for > produce()/inject()/postConstruct()) and destroy (preDestroy()/dispose()). > Said otherwise: the need is already in the API so why not letting EE > getting these enhancement as well? > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2015-03-04 13:09 GMT+01:00 John D. Ament : > >> Same way as defined in the spec >> >> CDI.current().destroy(..) >> >> On Wed, Mar 4, 2015 at 6:44 AM Romain Manni-Bucau >> wrote: >> >>> hmm, and if the bean is @Dependent? how do you release it? >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog >>> | Github >>> | LinkedIn >>> | Tomitriber >>> >>> >>> 2015-03-04 12:37 GMT+01:00 John D. Ament : >>> >>>> >>>> >>>> On Wed, Mar 4, 2015 at 6:35 AM Romain Manni-Bucau < >>>> rmannibucau at gmail.com> wrote: >>>> >>>>> 2015-03-04 12:29 GMT+01:00 John D. Ament : >>>>> >>>>>> Hmm.. comments in line. >>>>>> >>>>>> On Wed, Mar 4, 2015 at 4:49 AM Antoine Sabot-Durand < >>>>>> antoine at sabot-durand.net> wrote: >>>>>> >>>>>>> Hi John, >>>>>>> >>>>>>> I think it could be a good idea to write down all of these to have a >>>>>>> more stable doc for discussion. You should update the google doc with the >>>>>>> result of this discussion. >>>>>>> >>>>>>> I agree with the following points in this thread : >>>>>>> >>>>>>> - Minimize the number of new Class / Interface. CDI and CDIProvider >>>>>>> usage is still not very clear for end user so we should add the strict >>>>>>> minimum and try to enhance existing API / SPI when possible >>>>>>> >>>>>> >>>>>> It seems odd to me that we're rehashing decisions made during the EG >>>>>> meetings. Not putting it in CDI was discussed in several meetings at the >>>>>> beginning of the year, and it seemed like the agreement was putting it in >>>>>> CDI was a bad idea. >>>>>> >>>>>> >>>>>>> - Be able to bootstrap CDI without returning BeanManager (env if the >>>>>>> API give possibility to access it if needed). End user don?t need that : >>>>>>> CDI app can start with an observer for instance >>>>>>> >>>>>> >>>>>> Agreed, but I think we need to provide some entry point to allow >>>>>> those who aren't comfortable with programming with events to leverage it. >>>>>> Returning the CDI instance makes that easier to do than returning the >>>>>> BeanManager. >>>>>> >>>>>> >>>>> >>>>> Can you detail it please? CDI value is only its getBeanManager() >>>>> method IMO so it sounds like it is 1-1 for me. >>>>> >>>> >>>> >>>> Taken from the docs I"m working on: >>>> >>>> MyBean myBean = container.initialize().select(MyBean.class).get(); >>>> myBean.doWork(); >>>> >>>> Vs the 3-4 lines it takes to get a reference using just BeanManager. >>>> >>>> >>>>> >>>>> >>>>>> >>>>>>> Something not dealt with but that we should keep in mind : >>>>>>> - Providing a Java SE solution that could be easily used for a >>>>>>> servlet bootstrap of CDI. I don?t know if we?ll standardize this but we >>>>>>> definitely should keep this use case in mind >>>>>>> >>>>>>> and my bonus, it?s out of scope but I didn?t see anytime there that >>>>>>> prevent this nice to have: >>>>>>> - support the possibility to boot multiple BeanManager in Java SE. >>>>>>> >>>>>>> >>>>>> We talked about this one as well on the EG, either this year or late >>>>>> last year. I thought the decision at that time was that we wouldn't allow >>>>>> multiple containers at once in SE. >>>>>> >>>>>> >>>>> >>>>> wouldn't specify rather than wouldn't allow I think >>>>> >>>>> >>>>>> Antoine >>>>>>> >>>>>>> >>>>>>> Le 1 mars 2015 ? 15:13, John D. Ament a >>>>>>> ?crit : >>>>>>> >>>>>>> >>>>>>> So, I think I've gathered enough feedback at this point, and seen >>>>>>> some of the API changes. I'll hopefully be including some doc changes this >>>>>>> week, but one question - do we want to start the SE specific stuff as its >>>>>>> own asciidoc file? >>>>>>> >>>>>>> Changes made: >>>>>>> >>>>>>> - Changed return value to CDI to provide better capability >>>>>>> out of the box. >>>>>>> - Added AutoCloseable to CDIContainer, provided default >>>>>>> implementation of calling shutdown. >>>>>>> - Added synchronization support to the method body that retrieves >>>>>>> the singleton instance (BTW, I'm not sure if this is even useful TBH as >>>>>>> each impl, including the RI, needs to provide this class in its own format). >>>>>>> - Made the params map typed to >>>>>>> >>>>>>> @Romain Your case isn't really supportable yet, until we have static >>>>>>> injection support. You'd still have to have a managed version of Runner to >>>>>>> work against. >>>>>>> >>>>>>> John >>>>>>> >>>>>>> On Sat, Feb 28, 2015 at 4:11 PM Romain Manni-Bucau < >>>>>>> rmannibucau at gmail.com> wrote: >>>>>>> >>>>>>>> Yes but not the way to get an instance. Even Unmanaged does it. >>>>>>>> >>>>>>>> What can be awesome is to have static inject for it: >>>>>>>> >>>>>>>> public class Runner { >>>>>>>> >>>>>>>> @Inject >>>>>>>> private static MyMain main; >>>>>>>> >>>>>>>> public static void main(String[] arg) { >>>>>>>> try (CDIContainer c = CDIContainer.newContainer()) { >>>>>>>> main.doWork(); >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> } >>>>>>>> >>>>>>>> And not a single additional line :). >>>>>>>> Le 28 f?vr. 2015 19:05, "John D. Ament" >>>>>>>> a ?crit : >>>>>>>> >>>>>>>> Maybe I'm misreading, but I don't see us adding another API to do >>>>>>>>> the same thing here - we're introducing new functionality. >>>>>>>>> >>>>>>>>> CDIContainer/Loader on startup/shutdown of the application >>>>>>>>> >>>>>>>>> CDI for runtime usage within the application to interact with the >>>>>>>>> container. >>>>>>>>> >>>>>>>>> John >>>>>>>>> >>>>>>>>> On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau < >>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> sure I fully agree excepted I think introducing yet another API >>>>>>>>>> to do >>>>>>>>>> the same thing is not good so super tempting to skip it and wait >>>>>>>>>> for >>>>>>>>>> feedbacks rather than introducing it eagerly. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Romain Manni-Bucau >>>>>>>>>> @rmannibucau >>>>>>>>>> http://www.tomitribe.com >>>>>>>>>> http://rmannibucau.wordpress.com >>>>>>>>>> https://github.com/rmannibucau >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2015-02-27 8:05 GMT+01:00 Jozef Hartinger : >>>>>>>>>> > My point is that from the application perspective, the user >>>>>>>>>> obtains one >>>>>>>>>> > container handle for eventual shutdown (CDIContainer) and then >>>>>>>>>> looks up a >>>>>>>>>> > different container handle (CDI) that they can use for real >>>>>>>>>> work (lookup / >>>>>>>>>> > event dispatch / etc.) It would be cleaner if the container >>>>>>>>>> gave away a >>>>>>>>>> > single handle that can do all of that. >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: >>>>>>>>>> > >>>>>>>>>> > Not sure I get how a CDI instance can help. >>>>>>>>>> > >>>>>>>>>> > But container.getBeanManager() sounds nice is not a shortcut for >>>>>>>>>> > CDI.current().getBm() otherwise it looks like duplication to me. >>>>>>>>>> > >>>>>>>>>> > Can we make container not contextual - dont think so? If so it >>>>>>>>>> makes sense >>>>>>>>>> > otherwise I fear it doesnt add much. >>>>>>>>>> > >>>>>>>>>> > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" >>>>>>>>>> a ?crit : >>>>>>>>>> >> >>>>>>>>>> >> I like the initialize + close() combination and the >>>>>>>>>> try-with-resources >>>>>>>>>> >> usage. >>>>>>>>>> >> What looks weird to me is that at line one you obtain a >>>>>>>>>> container handle: >>>>>>>>>> >> >>>>>>>>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>>>>>>>> >> CDI.current().getBeanManager() ... >>>>>>>>>> >> >>>>>>>>>> >> and then at line two you call a static method to perform a >>>>>>>>>> container >>>>>>>>>> >> lookup :-/ >>>>>>>>>> >> >>>>>>>>>> >> An API that allows you to use the container handle you already >>>>>>>>>> got is way >>>>>>>>>> >> better IMO, e.g.: >>>>>>>>>> >> >>>>>>>>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>>>>>>>> >> container.getBeanManager() >>>>>>>>>> >> >>>>>>>>>> >> If CDIContainer.newCDIContainer() returns an CDI instance or >>>>>>>>>> its subclass, >>>>>>>>>> >> we get this easily. >>>>>>>>>> >> >>>>>>>>>> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: >>>>>>>>>> >>> >>>>>>>>>> >>> Hi guys >>>>>>>>>> >>> >>>>>>>>>> >>> why note keeping it simple? >>>>>>>>>> >>> >>>>>>>>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer(/* >>>>>>>>>> optional >>>>>>>>>> >>> map to configure vendor features */)) { >>>>>>>>>> >>> CDI.current().getBeanManager().... >>>>>>>>>> >>> } >>>>>>>>>> >>> >>>>>>>>>> >>> Not sure the point having initialize() + having shutdown = >>>>>>>>>> close >>>>>>>>>> >>> really makes the API more fluent and modern IMO. >>>>>>>>>> >>> >>>>>>>>>> >>> Also to be fully SE I guess provider() method would be needed >>>>>>>>>> even if >>>>>>>>>> >>> optional (SPI usage by default): >>>>>>>>>> >>> >>>>>>>>>> >>> try (CDIContainer container = >>>>>>>>>> >>> >>>>>>>>>> >>> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvid >>>>>>>>>> er").newCDIContainer()) >>>>>>>>>> >>> { >>>>>>>>>> >>> CDI.current().getBeanManager().... >>>>>>>>>> >>> } >>>>>>>>>> >>> >>>>>>>>>> >>> Finally I think having a kind of getInstance shortcut could >>>>>>>>>> be a plus for >>>>>>>>>> >>> SE: >>>>>>>>>> >>> >>>>>>>>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer()) >>>>>>>>>> { >>>>>>>>>> >>> container.newInstance(MyAppRunner.class /* optional >>>>>>>>>> qualifiers */ >>>>>>>>>> >>> ).run(args); >>>>>>>>>> >>> } >>>>>>>>>> >>> >>>>>>>>>> >>> Using container to get an instance would create the instance >>>>>>>>>> and bind >>>>>>>>>> >>> it to the container lifecycle (mainly for predestroy) >>>>>>>>>> avoiding this >>>>>>>>>> >>> boilerplate code in all main which will surely only be used >>>>>>>>>> to launch >>>>>>>>>> >>> a soft. >>>>>>>>>> >>> >>>>>>>>>> >>> wdyt? >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> >>> Romain Manni-Bucau >>>>>>>>>> >>> @rmannibucau >>>>>>>>>> >>> http://www.tomitribe.com >>>>>>>>>> >>> http://rmannibucau.wordpress.com >>>>>>>>>> >>> https://github.com/rmannibucau >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger < >>>>>>>>>> jharting at redhat.com>: >>>>>>>>>> >>>> >>>>>>>>>> >>>> Comments inline >>>>>>>>>> >>>> >>>>>>>>>> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: >>>>>>>>>> >>>> >>>>>>>>>> >>>> Sorry Jozef, your email fell into the pits of google inbox's >>>>>>>>>> "smart >>>>>>>>>> >>>> sorting" >>>>>>>>>> >>>> features. >>>>>>>>>> >>>> >>>>>>>>>> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger < >>>>>>>>>> jharting at redhat.com> >>>>>>>>>> >>>> wrote: >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> Hi John, comments inline: >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> Jozef, >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> Most of what you see there is taken from the original doc, >>>>>>>>>> since >>>>>>>>>> >>>>> everyone >>>>>>>>>> >>>>> seemed to be in agreement. I think the map is just a >>>>>>>>>> safeguard in case >>>>>>>>>> >>>>> of >>>>>>>>>> >>>>> additional boot options available in some implementations >>>>>>>>>> (e.g. I think >>>>>>>>>> >>>>> OWB/OpenEJB have some options.. currently OpenEJB supports >>>>>>>>>> an embedded >>>>>>>>>> >>>>> CDI >>>>>>>>>> >>>>> boot mode). >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> No, I am fine with the map. What I am questioning is the >>>>>>>>>> type of the >>>>>>>>>> >>>>> map. >>>>>>>>>> >>>>> Usually, data structures with a similar purpose use Strings >>>>>>>>>> as their >>>>>>>>>> >>>>> keys. >>>>>>>>>> >>>>> This applies to ServletContext attributes, >>>>>>>>>> InvocationContext data, >>>>>>>>>> >>>>> Servlet >>>>>>>>>> >>>>> request/session attributes and others. I am therefore >>>>>>>>>> wondering whether >>>>>>>>>> >>>>> there is a usecase for the proposed unbound key signature >>>>>>>>>> or not. >>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>>> >>>> I think that's more of a placeholder, I was assuming it >>>>>>>>>> would be >>>>>>>>>> >>>> Map once we clarify everything. >>>>>>>>>> >>>> >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> We spoke a few times about BeanManager vs CDI. BeanManager >>>>>>>>>> was >>>>>>>>>> >>>>> preferable >>>>>>>>>> >>>>> since there's no easy way to get the the instance, CDI is >>>>>>>>>> easier to get >>>>>>>>>> >>>>> and >>>>>>>>>> >>>>> more aligned with how you would get it. Usually people >>>>>>>>>> expect the >>>>>>>>>> >>>>> BeanManager to be injected or available via JNDI, neither >>>>>>>>>> would be the >>>>>>>>>> >>>>> case >>>>>>>>>> >>>>> here. >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> If CDI 2.0 targets Java SE then this container >>>>>>>>>> initialization API will >>>>>>>>>> >>>>> become something that ordinary application developers use >>>>>>>>>> to start/stop >>>>>>>>>> >>>>> CDI >>>>>>>>>> >>>>> in their applications. It therefore cannot be considered an >>>>>>>>>> SPI but >>>>>>>>>> >>>>> instead >>>>>>>>>> >>>>> should be something easy to use. On the other hand, >>>>>>>>>> BeanManager is >>>>>>>>>> >>>>> definitely an SPI. It is used in extension, frameworks and >>>>>>>>>> generally >>>>>>>>>> >>>>> for >>>>>>>>>> >>>>> integration. Not much by applications directly. Therefore, >>>>>>>>>> I don't see >>>>>>>>>> >>>>> how >>>>>>>>>> >>>>> the container bootstrap API and BeanManager fit together. >>>>>>>>>> IMO the >>>>>>>>>> >>>>> bootstrap >>>>>>>>>> >>>>> API should expose something that makes common tasks >>>>>>>>>> (obtaining a >>>>>>>>>> >>>>> contextual >>>>>>>>>> >>>>> reference and firing and event) easy, which the CDI class >>>>>>>>>> does. >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> Plus do not forget that BeanManager can be obtained easily >>>>>>>>>> using >>>>>>>>>> >>>>> CDI.getBeanManager(). >>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>>> >>>> I'm not disagreeing. There's a few things I'd consider: >>>>>>>>>> >>>> >>>>>>>>>> >>>> - Is this mostly for new apps or existing? If existing, >>>>>>>>>> it's probably >>>>>>>>>> >>>> using >>>>>>>>>> >>>> some internal API, if new it can use whatever API we give. >>>>>>>>>> >>>> - I don't want to return void, we should give some kind of >>>>>>>>>> reference >>>>>>>>>> >>>> into >>>>>>>>>> >>>> the container when we're done booting. >>>>>>>>>> >>>> >>>>>>>>>> >>>> Agreed, we should not be returning void. >>>>>>>>>> >>>> >>>>>>>>>> >>>> - CDI is a one step retrievable reference, where as >>>>>>>>>> BeanManager is a two >>>>>>>>>> >>>> step reference. With that said, BeanManager makes more >>>>>>>>>> sense to return >>>>>>>>>> >>>> here. Another thought could be we invent some new class >>>>>>>>>> that has both, >>>>>>>>>> >>>> but >>>>>>>>>> >>>> that's really redundant. >>>>>>>>>> >>>> >>>>>>>>>> >>>> Why do you think BeanManager makes more sense here? >>>>>>>>>> Especially given the >>>>>>>>>> >>>> assumption that application code is going to call this >>>>>>>>>> init/shutdown >>>>>>>>>> >>>> API, I >>>>>>>>>> >>>> don't see BeanManager as making more sense. >>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> Yes, this is the container start API. Sounds like you have >>>>>>>>>> some good >>>>>>>>>> >>>>> ideas for things like XML configuration or programmatic >>>>>>>>>> configuration, >>>>>>>>>> >>>>> both >>>>>>>>>> >>>>> of which are being tracked under separate tickets. One >>>>>>>>>> idea might be >>>>>>>>>> >>>>> for an >>>>>>>>>> >>>>> optional param in the map to control packages to >>>>>>>>>> scan/ignore, in that >>>>>>>>>> >>>>> map. >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> I am wondering whether this configuration should be >>>>>>>>>> something optional >>>>>>>>>> >>>>> built on top of the bootstrap API or whether we should >>>>>>>>>> consider making >>>>>>>>>> >>>>> it >>>>>>>>>> >>>>> mandatory. Either way, we cannot add the bootstrap API to >>>>>>>>>> the spec >>>>>>>>>> >>>>> without >>>>>>>>>> >>>>> explicitly defining how it behaves. My implicit assumption >>>>>>>>>> of the >>>>>>>>>> >>>>> proposal >>>>>>>>>> >>>>> is that the container is supposed to scan the entire >>>>>>>>>> classpath for >>>>>>>>>> >>>>> explicit >>>>>>>>>> >>>>> or implicit bean archives (including e.g. rt.jar), discover >>>>>>>>>> beans, fire >>>>>>>>>> >>>>> extensions, etc. This worries me as this default behavior >>>>>>>>>> is far from >>>>>>>>>> >>>>> being >>>>>>>>>> >>>>> lightweight, which CDI for Java SE initially aimed to be. >>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>>> >>>> Yes, the spec must be updated to reflect the behavior of SE >>>>>>>>>> mode. I >>>>>>>>>> >>>> plan to >>>>>>>>>> >>>> get that completely into the google doc before opening any >>>>>>>>>> spec changes >>>>>>>>>> >>>> in a >>>>>>>>>> >>>> PR. >>>>>>>>>> >>>> >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> We didn't want to over load the CDI interface. It already >>>>>>>>>> does a lot. >>>>>>>>>> >>>>> This is really SPI code, CDI even though it's in the spi >>>>>>>>>> package is >>>>>>>>>> >>>>> used in >>>>>>>>>> >>>>> a lot of application code. >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> I would personally prefer to have it all in one place. >>>>>>>>>> Having >>>>>>>>>> >>>>> CDIContainer, CDIContainerLoader, CDI and CDIProvider makes >>>>>>>>>> it more >>>>>>>>>> >>>>> difficult to know when to use what. >>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>>> >>>> The problem is that most CDI (the interface) operations are >>>>>>>>>> against a >>>>>>>>>> >>>> running container. I think we spoke about leveraging >>>>>>>>>> CDIProvider at one >>>>>>>>>> >>>> point (in fact, I mistakenly called CDIContainer CDIProvider >>>>>>>>>> not even >>>>>>>>>> >>>> realizing it was there). I doubt that most app developers >>>>>>>>>> use it >>>>>>>>>> >>>> currently, >>>>>>>>>> >>>> there's not even a way to get a reference to it that I'm >>>>>>>>>> aware of. It's >>>>>>>>>> >>>> used by the implementor only. >>>>>>>>>> >>>> >>>>>>>>>> >>>> I don't think there's a conflict. CDI class would still only >>>>>>>>>> provide >>>>>>>>>> >>>> methods >>>>>>>>>> >>>> to be run against a running container. The difference is >>>>>>>>>> that there >>>>>>>>>> >>>> would be >>>>>>>>>> >>>> additional static methods to get this running container (CDI >>>>>>>>>> class) to >>>>>>>>>> >>>> you >>>>>>>>>> >>>> by starting the container. >>>>>>>>>> >>>> >>>>>>>>>> >>>> Either way, I agree that reusing CDIProvider is a must. >>>>>>>>>> There is no >>>>>>>>>> >>>> reason >>>>>>>>>> >>>> to define a new class for the same purpose. >>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>>> >>>> I expect that my changes in the CDI spec around this will >>>>>>>>>> state, along >>>>>>>>>> >>>> the >>>>>>>>>> >>>> lines of: >>>>>>>>>> >>>> >>>>>>>>>> >>>> To retrieve a CDIContainer to launch, do this: >>>>>>>>>> >>>> >>>>>>>>>> >>>> CDIContainer container = CDIContainerLocator.getCDICont >>>>>>>>>> ainer(); >>>>>>>>>> >>>> container.initialize(); >>>>>>>>>> >>>> ... do work >>>>>>>>>> >>>> >>>>>>>>>> >>>> Once you want to shutdown the container, do this: >>>>>>>>>> >>>> >>>>>>>>>> >>>> container.shutdown(); >>>>>>>>>> >>>> >>>>>>>>>> >>>> (we may want to consider implementing AutoCloseable, an >>>>>>>>>> oversight on my >>>>>>>>>> >>>> part) >>>>>>>>>> >>>> >>>>>>>>>> >>>> and then later on >>>>>>>>>> >>>> >>>>>>>>>> >>>> - What happens if I call CDIContainerLocator in an app server >>>>>>>>>> >>>> >>>>>>>>>> >>>> - It throws an IllegalStateException. >>>>>>>>>> >>>> >>>>>>>>>> >>>> - The container provides no beans of type CDIContainer, it >>>>>>>>>> is managed >>>>>>>>>> >>>> outside of the CDI container. >>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> John >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger < >>>>>>>>>> jharting at redhat.com> >>>>>>>>>> >>>>> wrote: >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> Hi John, some thoughts: >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> - instead of using BeanManager it makes more sense to me >>>>>>>>>> to return a >>>>>>>>>> >>>>>> CDI >>>>>>>>>> >>>>>> instance, which is a more user-friendly API (and it also >>>>>>>>>> exposes >>>>>>>>>> >>>>>> access to >>>>>>>>>> >>>>>> BeanManager) >>>>>>>>>> >>>>>> - is there a usecase for arbitrary keys of the "params" >>>>>>>>>> map or is >>>>>>>>>> >>>>>> Map sufficient? >>>>>>>>>> >>>>>> - if we could move the shutdown() method from CDIContainer >>>>>>>>>> to the >>>>>>>>>> >>>>>> actual >>>>>>>>>> >>>>>> container handle that we obtain from initialize(), that >>>>>>>>>> would look >>>>>>>>>> >>>>>> more >>>>>>>>>> >>>>>> object-oriented >>>>>>>>>> >>>>>> - what exactly is initialize() supposed to do? Is it >>>>>>>>>> supposed to start >>>>>>>>>> >>>>>> scanning the entire classpath for CDI beans? That could be >>>>>>>>>> a problem >>>>>>>>>> >>>>>> especially with spring-boot-like fat jars. I think we need >>>>>>>>>> an API to >>>>>>>>>> >>>>>> tell >>>>>>>>>> >>>>>> the container which classes / packages to consider. >>>>>>>>>> Something like >>>>>>>>>> >>>>>> Guice's >>>>>>>>>> >>>>>> binding API perhaps? >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> - the proposal makes me wonder whether retrofitting this >>>>>>>>>> functionality >>>>>>>>>> >>>>>> to >>>>>>>>>> >>>>>> the CDI class wouldn't be a better option. It could look >>>>>>>>>> like: >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> CDI container = CDI.initialize(); >>>>>>>>>> >>>>>> container.select(Foo.class).get(); >>>>>>>>>> >>>>>> container.shutdown(); >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> compare it to: >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> CDIContainer container = CDIContainerLoader. >>>>>>>>>> getCDIContainer(); >>>>>>>>>> >>>>>> BeanManager manager = container.initialize(); >>>>>>>>>> >>>>>> manager.getBeans(...); >>>>>>>>>> >>>>>> container.shutdown(manager); >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> All, >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> I have the updated API here, and wanted to solicit any >>>>>>>>>> final feedback >>>>>>>>>> >>>>>> before updating the google doc and spec pages. >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> https://github.com/johnament/cdi/commit/ >>>>>>>>>> 2c362161e18dd521f8e83c27151ddad467a1c01c >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> Let me know your thoughts. >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> Thanks, >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> John >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> _______________________________________________ >>>>>>>>>> >>>>>> cdi-dev mailing list >>>>>>>>>> >>>>>> cdi-dev at lists.jboss.org >>>>>>>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> Note that for all code provided on this list, the provider >>>>>>>>>> licenses >>>>>>>>>> >>>>>> the >>>>>>>>>> >>>>>> code under the Apache License, Version 2 >>>>>>>>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For >>>>>>>>>> all other ideas >>>>>>>>>> >>>>>> provided on this list, the provider waives all patent and >>>>>>>>>> other >>>>>>>>>> >>>>>> intellectual >>>>>>>>>> >>>>>> property rights inherent in such information. >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>> >>>>>>>>>> >>>> _______________________________________________ >>>>>>>>>> >>>> cdi-dev mailing list >>>>>>>>>> >>>> cdi-dev at lists.jboss.org >>>>>>>>>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>>>> >>>> >>>>>>>>>> >>>> Note that for all code provided on this list, the provider >>>>>>>>>> licenses the >>>>>>>>>> >>>> code >>>>>>>>>> >>>> under the Apache License, Version 2 >>>>>>>>>> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all >>>>>>>>>> other ideas >>>>>>>>>> >>>> provided on this list, the provider waives all patent and >>>>>>>>>> other >>>>>>>>>> >>>> intellectual >>>>>>>>>> >>>> property rights inherent in such information. >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> > >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>> cdi-dev mailing list >>>>>>> cdi-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>> >>>>>>> Note that for all code provided on this list, the provider licenses >>>>>>> the code under the Apache License, Version 2 (http://www.apache.org/ >>>>>>> licenses/LICENSE-2.0.html). For all other ideas provided on this >>>>>>> list, the provider waives all patent and other intellectual property rights >>>>>>> inherent in such information. >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> cdi-dev mailing list >>>>>> cdi-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>> >>>>>> Note that for all code provided on this list, the provider licenses >>>>>> the code under the Apache License, Version 2 ( >>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>>>>> ideas provided on this list, the provider waives all patent and other >>>>>> intellectual property rights inherent in such information. >>>>>> >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/08f2815d/attachment-0001.html From rmannibucau at gmail.com Wed Mar 4 07:33:38 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 4 Mar 2015 13:33:38 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: References: Message-ID: instead of Unmanaged unmanagedFoo = new Unmanaged(Foo.class); UnmanagedInstance fooInstance = unmanagedFoo.newInstance(); Foo foo = fooInstance.produce().inject().postConstruct().get(); ... // Use the foo instance fooInstance.preDestroy().dispose(); just doing UnmanagedInstance fooInstance = new Unmanaged(Foo.class).create(); ... // Use the foo instance fooInstance.destroy(); Would make the main then quite trivial and more user friendly IMO Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-03-04 13:31 GMT+01:00 John D. Ament : > Get what enhancements? > > On Wed, Mar 4, 2015 at 7:28 AM Romain Manni-Bucau > wrote: > >> ok, initialize was returning a CDI instance then. >> >> If CDI instance is so present why bothering container api with it? Just >> looks like another Unmanaged. In this case I would enhance Unmanaged to >> have shortcut like create() (shortcut for >> produce()/inject()/postConstruct()) and destroy >> (preDestroy()/dispose()). Said otherwise: the need is already in the API so >> why not letting EE getting these enhancement as well? >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> 2015-03-04 13:09 GMT+01:00 John D. Ament : >> >>> Same way as defined in the spec >>> >>> CDI.current().destroy(..) >>> >>> On Wed, Mar 4, 2015 at 6:44 AM Romain Manni-Bucau >>> wrote: >>> >>>> hmm, and if the bean is @Dependent? how do you release it? >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau | Blog >>>> | Github >>>> | LinkedIn >>>> | Tomitriber >>>> >>>> >>>> 2015-03-04 12:37 GMT+01:00 John D. Ament : >>>> >>>>> >>>>> >>>>> On Wed, Mar 4, 2015 at 6:35 AM Romain Manni-Bucau < >>>>> rmannibucau at gmail.com> wrote: >>>>> >>>>>> 2015-03-04 12:29 GMT+01:00 John D. Ament : >>>>>> >>>>>>> Hmm.. comments in line. >>>>>>> >>>>>>> On Wed, Mar 4, 2015 at 4:49 AM Antoine Sabot-Durand < >>>>>>> antoine at sabot-durand.net> wrote: >>>>>>> >>>>>>>> Hi John, >>>>>>>> >>>>>>>> I think it could be a good idea to write down all of these to have >>>>>>>> a more stable doc for discussion. You should update the google doc with the >>>>>>>> result of this discussion. >>>>>>>> >>>>>>>> I agree with the following points in this thread : >>>>>>>> >>>>>>>> - Minimize the number of new Class / Interface. CDI and CDIProvider >>>>>>>> usage is still not very clear for end user so we should add the strict >>>>>>>> minimum and try to enhance existing API / SPI when possible >>>>>>>> >>>>>>> >>>>>>> It seems odd to me that we're rehashing decisions made during the EG >>>>>>> meetings. Not putting it in CDI was discussed in several meetings at the >>>>>>> beginning of the year, and it seemed like the agreement was putting it in >>>>>>> CDI was a bad idea. >>>>>>> >>>>>>> >>>>>>>> - Be able to bootstrap CDI without returning BeanManager (env if >>>>>>>> the API give possibility to access it if needed). End user don?t need that >>>>>>>> : CDI app can start with an observer for instance >>>>>>>> >>>>>>> >>>>>>> Agreed, but I think we need to provide some entry point to allow >>>>>>> those who aren't comfortable with programming with events to leverage it. >>>>>>> Returning the CDI instance makes that easier to do than returning the >>>>>>> BeanManager. >>>>>>> >>>>>>> >>>>>> >>>>>> Can you detail it please? CDI value is only its getBeanManager() >>>>>> method IMO so it sounds like it is 1-1 for me. >>>>>> >>>>> >>>>> >>>>> Taken from the docs I"m working on: >>>>> >>>>> MyBean myBean = container.initialize().select(MyBean.class).get(); >>>>> myBean.doWork(); >>>>> >>>>> Vs the 3-4 lines it takes to get a reference using just BeanManager. >>>>> >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>>> Something not dealt with but that we should keep in mind : >>>>>>>> - Providing a Java SE solution that could be easily used for a >>>>>>>> servlet bootstrap of CDI. I don?t know if we?ll standardize this but we >>>>>>>> definitely should keep this use case in mind >>>>>>>> >>>>>>>> and my bonus, it?s out of scope but I didn?t see anytime there that >>>>>>>> prevent this nice to have: >>>>>>>> - support the possibility to boot multiple BeanManager in Java SE. >>>>>>>> >>>>>>>> >>>>>>> We talked about this one as well on the EG, either this year or late >>>>>>> last year. I thought the decision at that time was that we wouldn't allow >>>>>>> multiple containers at once in SE. >>>>>>> >>>>>>> >>>>>> >>>>>> wouldn't specify rather than wouldn't allow I think >>>>>> >>>>>> >>>>>>> Antoine >>>>>>>> >>>>>>>> >>>>>>>> Le 1 mars 2015 ? 15:13, John D. Ament a >>>>>>>> ?crit : >>>>>>>> >>>>>>>> >>>>>>>> So, I think I've gathered enough feedback at this point, and seen >>>>>>>> some of the API changes. I'll hopefully be including some doc changes this >>>>>>>> week, but one question - do we want to start the SE specific stuff as its >>>>>>>> own asciidoc file? >>>>>>>> >>>>>>>> Changes made: >>>>>>>> >>>>>>>> - Changed return value to CDI to provide better capability >>>>>>>> out of the box. >>>>>>>> - Added AutoCloseable to CDIContainer, provided default >>>>>>>> implementation of calling shutdown. >>>>>>>> - Added synchronization support to the method body that retrieves >>>>>>>> the singleton instance (BTW, I'm not sure if this is even useful TBH as >>>>>>>> each impl, including the RI, needs to provide this class in its own format). >>>>>>>> - Made the params map typed to >>>>>>>> >>>>>>>> @Romain Your case isn't really supportable yet, until we have >>>>>>>> static injection support. You'd still have to have a managed version of >>>>>>>> Runner to work against. >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>>> On Sat, Feb 28, 2015 at 4:11 PM Romain Manni-Bucau < >>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>> >>>>>>>>> Yes but not the way to get an instance. Even Unmanaged does it. >>>>>>>>> >>>>>>>>> What can be awesome is to have static inject for it: >>>>>>>>> >>>>>>>>> public class Runner { >>>>>>>>> >>>>>>>>> @Inject >>>>>>>>> private static MyMain main; >>>>>>>>> >>>>>>>>> public static void main(String[] arg) { >>>>>>>>> try (CDIContainer c = CDIContainer.newContainer()) { >>>>>>>>> main.doWork(); >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> } >>>>>>>>> >>>>>>>>> And not a single additional line :). >>>>>>>>> Le 28 f?vr. 2015 19:05, "John D. Ament" >>>>>>>>> a ?crit : >>>>>>>>> >>>>>>>>> Maybe I'm misreading, but I don't see us adding another API to do >>>>>>>>>> the same thing here - we're introducing new functionality. >>>>>>>>>> >>>>>>>>>> CDIContainer/Loader on startup/shutdown of the application >>>>>>>>>> >>>>>>>>>> CDI for runtime usage within the application to interact with the >>>>>>>>>> container. >>>>>>>>>> >>>>>>>>>> John >>>>>>>>>> >>>>>>>>>> On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau < >>>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> sure I fully agree excepted I think introducing yet another API >>>>>>>>>>> to do >>>>>>>>>>> the same thing is not good so super tempting to skip it and wait >>>>>>>>>>> for >>>>>>>>>>> feedbacks rather than introducing it eagerly. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>> @rmannibucau >>>>>>>>>>> http://www.tomitribe.com >>>>>>>>>>> http://rmannibucau.wordpress.com >>>>>>>>>>> https://github.com/rmannibucau >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2015-02-27 8:05 GMT+01:00 Jozef Hartinger : >>>>>>>>>>> > My point is that from the application perspective, the user >>>>>>>>>>> obtains one >>>>>>>>>>> > container handle for eventual shutdown (CDIContainer) and then >>>>>>>>>>> looks up a >>>>>>>>>>> > different container handle (CDI) that they can use for real >>>>>>>>>>> work (lookup / >>>>>>>>>>> > event dispatch / etc.) It would be cleaner if the container >>>>>>>>>>> gave away a >>>>>>>>>>> > single handle that can do all of that. >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: >>>>>>>>>>> > >>>>>>>>>>> > Not sure I get how a CDI instance can help. >>>>>>>>>>> > >>>>>>>>>>> > But container.getBeanManager() sounds nice is not a shortcut >>>>>>>>>>> for >>>>>>>>>>> > CDI.current().getBm() otherwise it looks like duplication to >>>>>>>>>>> me. >>>>>>>>>>> > >>>>>>>>>>> > Can we make container not contextual - dont think so? If so it >>>>>>>>>>> makes sense >>>>>>>>>>> > otherwise I fear it doesnt add much. >>>>>>>>>>> > >>>>>>>>>>> > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" >>>>>>>>>>> a ?crit : >>>>>>>>>>> >> >>>>>>>>>>> >> I like the initialize + close() combination and the >>>>>>>>>>> try-with-resources >>>>>>>>>>> >> usage. >>>>>>>>>>> >> What looks weird to me is that at line one you obtain a >>>>>>>>>>> container handle: >>>>>>>>>>> >> >>>>>>>>>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>>>>>>>>> >> CDI.current().getBeanManager() ... >>>>>>>>>>> >> >>>>>>>>>>> >> and then at line two you call a static method to perform a >>>>>>>>>>> container >>>>>>>>>>> >> lookup :-/ >>>>>>>>>>> >> >>>>>>>>>>> >> An API that allows you to use the container handle you >>>>>>>>>>> already got is way >>>>>>>>>>> >> better IMO, e.g.: >>>>>>>>>>> >> >>>>>>>>>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>>>>>>>>> >> container.getBeanManager() >>>>>>>>>>> >> >>>>>>>>>>> >> If CDIContainer.newCDIContainer() returns an CDI instance or >>>>>>>>>>> its subclass, >>>>>>>>>>> >> we get this easily. >>>>>>>>>>> >> >>>>>>>>>>> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: >>>>>>>>>>> >>> >>>>>>>>>>> >>> Hi guys >>>>>>>>>>> >>> >>>>>>>>>>> >>> why note keeping it simple? >>>>>>>>>>> >>> >>>>>>>>>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer(/* >>>>>>>>>>> optional >>>>>>>>>>> >>> map to configure vendor features */)) { >>>>>>>>>>> >>> CDI.current().getBeanManager().... >>>>>>>>>>> >>> } >>>>>>>>>>> >>> >>>>>>>>>>> >>> Not sure the point having initialize() + having shutdown = >>>>>>>>>>> close >>>>>>>>>>> >>> really makes the API more fluent and modern IMO. >>>>>>>>>>> >>> >>>>>>>>>>> >>> Also to be fully SE I guess provider() method would be >>>>>>>>>>> needed even if >>>>>>>>>>> >>> optional (SPI usage by default): >>>>>>>>>>> >>> >>>>>>>>>>> >>> try (CDIContainer container = >>>>>>>>>>> >>> >>>>>>>>>>> >>> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvid >>>>>>>>>>> er").newCDIContainer()) >>>>>>>>>>> >>> { >>>>>>>>>>> >>> CDI.current().getBeanManager().... >>>>>>>>>>> >>> } >>>>>>>>>>> >>> >>>>>>>>>>> >>> Finally I think having a kind of getInstance shortcut could >>>>>>>>>>> be a plus for >>>>>>>>>>> >>> SE: >>>>>>>>>>> >>> >>>>>>>>>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer()) >>>>>>>>>>> { >>>>>>>>>>> >>> container.newInstance(MyAppRunner.class /* optional >>>>>>>>>>> qualifiers */ >>>>>>>>>>> >>> ).run(args); >>>>>>>>>>> >>> } >>>>>>>>>>> >>> >>>>>>>>>>> >>> Using container to get an instance would create the instance >>>>>>>>>>> and bind >>>>>>>>>>> >>> it to the container lifecycle (mainly for predestroy) >>>>>>>>>>> avoiding this >>>>>>>>>>> >>> boilerplate code in all main which will surely only be used >>>>>>>>>>> to launch >>>>>>>>>>> >>> a soft. >>>>>>>>>>> >>> >>>>>>>>>>> >>> wdyt? >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> Romain Manni-Bucau >>>>>>>>>>> >>> @rmannibucau >>>>>>>>>>> >>> http://www.tomitribe.com >>>>>>>>>>> >>> http://rmannibucau.wordpress.com >>>>>>>>>>> >>> https://github.com/rmannibucau >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger < >>>>>>>>>>> jharting at redhat.com>: >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> Comments inline >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> Sorry Jozef, your email fell into the pits of google >>>>>>>>>>> inbox's "smart >>>>>>>>>>> >>>> sorting" >>>>>>>>>>> >>>> features. >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger < >>>>>>>>>>> jharting at redhat.com> >>>>>>>>>>> >>>> wrote: >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> Hi John, comments inline: >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> Jozef, >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> Most of what you see there is taken from the original doc, >>>>>>>>>>> since >>>>>>>>>>> >>>>> everyone >>>>>>>>>>> >>>>> seemed to be in agreement. I think the map is just a >>>>>>>>>>> safeguard in case >>>>>>>>>>> >>>>> of >>>>>>>>>>> >>>>> additional boot options available in some implementations >>>>>>>>>>> (e.g. I think >>>>>>>>>>> >>>>> OWB/OpenEJB have some options.. currently OpenEJB supports >>>>>>>>>>> an embedded >>>>>>>>>>> >>>>> CDI >>>>>>>>>>> >>>>> boot mode). >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> No, I am fine with the map. What I am questioning is the >>>>>>>>>>> type of the >>>>>>>>>>> >>>>> map. >>>>>>>>>>> >>>>> Usually, data structures with a similar purpose use >>>>>>>>>>> Strings as their >>>>>>>>>>> >>>>> keys. >>>>>>>>>>> >>>>> This applies to ServletContext attributes, >>>>>>>>>>> InvocationContext data, >>>>>>>>>>> >>>>> Servlet >>>>>>>>>>> >>>>> request/session attributes and others. I am therefore >>>>>>>>>>> wondering whether >>>>>>>>>>> >>>>> there is a usecase for the proposed unbound key signature >>>>>>>>>>> or not. >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> I think that's more of a placeholder, I was assuming it >>>>>>>>>>> would be >>>>>>>>>>> >>>> Map once we clarify everything. >>>>>>>>>>> >>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> We spoke a few times about BeanManager vs CDI. >>>>>>>>>>> BeanManager was >>>>>>>>>>> >>>>> preferable >>>>>>>>>>> >>>>> since there's no easy way to get the the instance, CDI is >>>>>>>>>>> easier to get >>>>>>>>>>> >>>>> and >>>>>>>>>>> >>>>> more aligned with how you would get it. Usually people >>>>>>>>>>> expect the >>>>>>>>>>> >>>>> BeanManager to be injected or available via JNDI, neither >>>>>>>>>>> would be the >>>>>>>>>>> >>>>> case >>>>>>>>>>> >>>>> here. >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> If CDI 2.0 targets Java SE then this container >>>>>>>>>>> initialization API will >>>>>>>>>>> >>>>> become something that ordinary application developers use >>>>>>>>>>> to start/stop >>>>>>>>>>> >>>>> CDI >>>>>>>>>>> >>>>> in their applications. It therefore cannot be considered >>>>>>>>>>> an SPI but >>>>>>>>>>> >>>>> instead >>>>>>>>>>> >>>>> should be something easy to use. On the other hand, >>>>>>>>>>> BeanManager is >>>>>>>>>>> >>>>> definitely an SPI. It is used in extension, frameworks and >>>>>>>>>>> generally >>>>>>>>>>> >>>>> for >>>>>>>>>>> >>>>> integration. Not much by applications directly. Therefore, >>>>>>>>>>> I don't see >>>>>>>>>>> >>>>> how >>>>>>>>>>> >>>>> the container bootstrap API and BeanManager fit together. >>>>>>>>>>> IMO the >>>>>>>>>>> >>>>> bootstrap >>>>>>>>>>> >>>>> API should expose something that makes common tasks >>>>>>>>>>> (obtaining a >>>>>>>>>>> >>>>> contextual >>>>>>>>>>> >>>>> reference and firing and event) easy, which the CDI class >>>>>>>>>>> does. >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> Plus do not forget that BeanManager can be obtained easily >>>>>>>>>>> using >>>>>>>>>>> >>>>> CDI.getBeanManager(). >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> I'm not disagreeing. There's a few things I'd consider: >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> - Is this mostly for new apps or existing? If existing, >>>>>>>>>>> it's probably >>>>>>>>>>> >>>> using >>>>>>>>>>> >>>> some internal API, if new it can use whatever API we give. >>>>>>>>>>> >>>> - I don't want to return void, we should give some kind of >>>>>>>>>>> reference >>>>>>>>>>> >>>> into >>>>>>>>>>> >>>> the container when we're done booting. >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> Agreed, we should not be returning void. >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> - CDI is a one step retrievable reference, where as >>>>>>>>>>> BeanManager is a two >>>>>>>>>>> >>>> step reference. With that said, BeanManager makes more >>>>>>>>>>> sense to return >>>>>>>>>>> >>>> here. Another thought could be we invent some new class >>>>>>>>>>> that has both, >>>>>>>>>>> >>>> but >>>>>>>>>>> >>>> that's really redundant. >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> Why do you think BeanManager makes more sense here? >>>>>>>>>>> Especially given the >>>>>>>>>>> >>>> assumption that application code is going to call this >>>>>>>>>>> init/shutdown >>>>>>>>>>> >>>> API, I >>>>>>>>>>> >>>> don't see BeanManager as making more sense. >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> Yes, this is the container start API. Sounds like you >>>>>>>>>>> have some good >>>>>>>>>>> >>>>> ideas for things like XML configuration or programmatic >>>>>>>>>>> configuration, >>>>>>>>>>> >>>>> both >>>>>>>>>>> >>>>> of which are being tracked under separate tickets. One >>>>>>>>>>> idea might be >>>>>>>>>>> >>>>> for an >>>>>>>>>>> >>>>> optional param in the map to control packages to >>>>>>>>>>> scan/ignore, in that >>>>>>>>>>> >>>>> map. >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> I am wondering whether this configuration should be >>>>>>>>>>> something optional >>>>>>>>>>> >>>>> built on top of the bootstrap API or whether we should >>>>>>>>>>> consider making >>>>>>>>>>> >>>>> it >>>>>>>>>>> >>>>> mandatory. Either way, we cannot add the bootstrap API to >>>>>>>>>>> the spec >>>>>>>>>>> >>>>> without >>>>>>>>>>> >>>>> explicitly defining how it behaves. My implicit assumption >>>>>>>>>>> of the >>>>>>>>>>> >>>>> proposal >>>>>>>>>>> >>>>> is that the container is supposed to scan the entire >>>>>>>>>>> classpath for >>>>>>>>>>> >>>>> explicit >>>>>>>>>>> >>>>> or implicit bean archives (including e.g. rt.jar), >>>>>>>>>>> discover beans, fire >>>>>>>>>>> >>>>> extensions, etc. This worries me as this default behavior >>>>>>>>>>> is far from >>>>>>>>>>> >>>>> being >>>>>>>>>>> >>>>> lightweight, which CDI for Java SE initially aimed to be. >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> Yes, the spec must be updated to reflect the behavior of SE >>>>>>>>>>> mode. I >>>>>>>>>>> >>>> plan to >>>>>>>>>>> >>>> get that completely into the google doc before opening any >>>>>>>>>>> spec changes >>>>>>>>>>> >>>> in a >>>>>>>>>>> >>>> PR. >>>>>>>>>>> >>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> We didn't want to over load the CDI interface. It already >>>>>>>>>>> does a lot. >>>>>>>>>>> >>>>> This is really SPI code, CDI even though it's in the spi >>>>>>>>>>> package is >>>>>>>>>>> >>>>> used in >>>>>>>>>>> >>>>> a lot of application code. >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> I would personally prefer to have it all in one place. >>>>>>>>>>> Having >>>>>>>>>>> >>>>> CDIContainer, CDIContainerLoader, CDI and CDIProvider >>>>>>>>>>> makes it more >>>>>>>>>>> >>>>> difficult to know when to use what. >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> The problem is that most CDI (the interface) operations are >>>>>>>>>>> against a >>>>>>>>>>> >>>> running container. I think we spoke about leveraging >>>>>>>>>>> CDIProvider at one >>>>>>>>>>> >>>> point (in fact, I mistakenly called CDIContainer >>>>>>>>>>> CDIProvider not even >>>>>>>>>>> >>>> realizing it was there). I doubt that most app developers >>>>>>>>>>> use it >>>>>>>>>>> >>>> currently, >>>>>>>>>>> >>>> there's not even a way to get a reference to it that I'm >>>>>>>>>>> aware of. It's >>>>>>>>>>> >>>> used by the implementor only. >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> I don't think there's a conflict. CDI class would still >>>>>>>>>>> only provide >>>>>>>>>>> >>>> methods >>>>>>>>>>> >>>> to be run against a running container. The difference is >>>>>>>>>>> that there >>>>>>>>>>> >>>> would be >>>>>>>>>>> >>>> additional static methods to get this running container >>>>>>>>>>> (CDI class) to >>>>>>>>>>> >>>> you >>>>>>>>>>> >>>> by starting the container. >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> Either way, I agree that reusing CDIProvider is a must. >>>>>>>>>>> There is no >>>>>>>>>>> >>>> reason >>>>>>>>>>> >>>> to define a new class for the same purpose. >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> I expect that my changes in the CDI spec around this will >>>>>>>>>>> state, along >>>>>>>>>>> >>>> the >>>>>>>>>>> >>>> lines of: >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> To retrieve a CDIContainer to launch, do this: >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> CDIContainer container = CDIContainerLocator.getCDICont >>>>>>>>>>> ainer(); >>>>>>>>>>> >>>> container.initialize(); >>>>>>>>>>> >>>> ... do work >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> Once you want to shutdown the container, do this: >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> container.shutdown(); >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> (we may want to consider implementing AutoCloseable, an >>>>>>>>>>> oversight on my >>>>>>>>>>> >>>> part) >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> and then later on >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> - What happens if I call CDIContainerLocator in an app >>>>>>>>>>> server >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> - It throws an IllegalStateException. >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> - The container provides no beans of type CDIContainer, it >>>>>>>>>>> is managed >>>>>>>>>>> >>>> outside of the CDI container. >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> John >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger < >>>>>>>>>>> jharting at redhat.com> >>>>>>>>>>> >>>>> wrote: >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> Hi John, some thoughts: >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> - instead of using BeanManager it makes more sense to me >>>>>>>>>>> to return a >>>>>>>>>>> >>>>>> CDI >>>>>>>>>>> >>>>>> instance, which is a more user-friendly API (and it also >>>>>>>>>>> exposes >>>>>>>>>>> >>>>>> access to >>>>>>>>>>> >>>>>> BeanManager) >>>>>>>>>>> >>>>>> - is there a usecase for arbitrary keys of the "params" >>>>>>>>>>> map or is >>>>>>>>>>> >>>>>> Map sufficient? >>>>>>>>>>> >>>>>> - if we could move the shutdown() method from >>>>>>>>>>> CDIContainer to the >>>>>>>>>>> >>>>>> actual >>>>>>>>>>> >>>>>> container handle that we obtain from initialize(), that >>>>>>>>>>> would look >>>>>>>>>>> >>>>>> more >>>>>>>>>>> >>>>>> object-oriented >>>>>>>>>>> >>>>>> - what exactly is initialize() supposed to do? Is it >>>>>>>>>>> supposed to start >>>>>>>>>>> >>>>>> scanning the entire classpath for CDI beans? That could >>>>>>>>>>> be a problem >>>>>>>>>>> >>>>>> especially with spring-boot-like fat jars. I think we >>>>>>>>>>> need an API to >>>>>>>>>>> >>>>>> tell >>>>>>>>>>> >>>>>> the container which classes / packages to consider. >>>>>>>>>>> Something like >>>>>>>>>>> >>>>>> Guice's >>>>>>>>>>> >>>>>> binding API perhaps? >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> - the proposal makes me wonder whether retrofitting this >>>>>>>>>>> functionality >>>>>>>>>>> >>>>>> to >>>>>>>>>>> >>>>>> the CDI class wouldn't be a better option. It could look >>>>>>>>>>> like: >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> CDI container = CDI.initialize(); >>>>>>>>>>> >>>>>> container.select(Foo.class).get(); >>>>>>>>>>> >>>>>> container.shutdown(); >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> compare it to: >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> CDIContainer container = CDIContainerLoader. >>>>>>>>>>> getCDIContainer(); >>>>>>>>>>> >>>>>> BeanManager manager = container.initialize(); >>>>>>>>>>> >>>>>> manager.getBeans(...); >>>>>>>>>>> >>>>>> container.shutdown(manager); >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> All, >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> I have the updated API here, and wanted to solicit any >>>>>>>>>>> final feedback >>>>>>>>>>> >>>>>> before updating the google doc and spec pages. >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> https://github.com/johnament/cdi/commit/ >>>>>>>>>>> 2c362161e18dd521f8e83c27151ddad467a1c01c >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> Let me know your thoughts. >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> Thanks, >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> John >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> _______________________________________________ >>>>>>>>>>> >>>>>> cdi-dev mailing list >>>>>>>>>>> >>>>>> cdi-dev at lists.jboss.org >>>>>>>>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> Note that for all code provided on this list, the >>>>>>>>>>> provider licenses >>>>>>>>>>> >>>>>> the >>>>>>>>>>> >>>>>> code under the Apache License, Version 2 >>>>>>>>>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For >>>>>>>>>>> all other ideas >>>>>>>>>>> >>>>>> provided on this list, the provider waives all patent and >>>>>>>>>>> other >>>>>>>>>>> >>>>>> intellectual >>>>>>>>>>> >>>>>> property rights inherent in such information. >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> _______________________________________________ >>>>>>>>>>> >>>> cdi-dev mailing list >>>>>>>>>>> >>>> cdi-dev at lists.jboss.org >>>>>>>>>>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> Note that for all code provided on this list, the provider >>>>>>>>>>> licenses the >>>>>>>>>>> >>>> code >>>>>>>>>>> >>>> under the Apache License, Version 2 >>>>>>>>>>> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all >>>>>>>>>>> other ideas >>>>>>>>>>> >>>> provided on this list, the provider waives all patent and >>>>>>>>>>> other >>>>>>>>>>> >>>> intellectual >>>>>>>>>>> >>>> property rights inherent in such information. >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>> cdi-dev mailing list >>>>>>>> cdi-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>> >>>>>>>> Note that for all code provided on this list, the provider licenses >>>>>>>> the code under the Apache License, Version 2 ( >>>>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>>>>>>> ideas provided on this list, the provider waives all patent and other >>>>>>>> intellectual property rights inherent in such information. >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> cdi-dev mailing list >>>>>>> cdi-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>> >>>>>>> Note that for all code provided on this list, the provider licenses >>>>>>> the code under the Apache License, Version 2 ( >>>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>>>>>> ideas provided on this list, the provider waives all patent and other >>>>>>> intellectual property rights inherent in such information. >>>>>>> >>>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/1e68bc15/attachment-0001.html From john.d.ament at gmail.com Wed Mar 4 07:35:59 2015 From: john.d.ament at gmail.com (John D. Ament) Date: Wed, 04 Mar 2015 12:35:59 +0000 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) References: Message-ID: I don't understand the relationship to Java SE mode. On Wed, Mar 4, 2015 at 7:33 AM Romain Manni-Bucau wrote: > instead of > > Unmanaged unmanagedFoo = new Unmanaged(Foo.class); > UnmanagedInstance fooInstance = unmanagedFoo.newInstance(); > Foo foo = fooInstance.produce().inject().postConstruct().get(); > ... // Use the foo instance > fooInstance.preDestroy().dispose(); > > > just doing > > > UnmanagedInstance fooInstance = new Unmanaged(Foo.class).create(); > ... // Use the foo instance > fooInstance.destroy(); > > > Would make the main then quite trivial and more user friendly IMO > > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2015-03-04 13:31 GMT+01:00 John D. Ament : > >> Get what enhancements? >> >> On Wed, Mar 4, 2015 at 7:28 AM Romain Manni-Bucau >> wrote: >> >>> ok, initialize was returning a CDI instance then. >>> >>> If CDI instance is so present why bothering container api with it? Just >>> looks like another Unmanaged. In this case I would enhance Unmanaged to >>> have shortcut like create() (shortcut for >>> produce()/inject()/postConstruct()) and destroy >>> (preDestroy()/dispose()). Said otherwise: the need is already in the API so >>> why not letting EE getting these enhancement as well? >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog >>> | Github >>> | LinkedIn >>> | Tomitriber >>> >>> >>> 2015-03-04 13:09 GMT+01:00 John D. Ament : >>> >>>> Same way as defined in the spec >>>> >>>> CDI.current().destroy(..) >>>> >>>> On Wed, Mar 4, 2015 at 6:44 AM Romain Manni-Bucau < >>>> rmannibucau at gmail.com> wrote: >>>> >>>>> hmm, and if the bean is @Dependent? how do you release it? >>>>> >>>>> >>>>> Romain Manni-Bucau >>>>> @rmannibucau | Blog >>>>> | Github >>>>> | LinkedIn >>>>> | Tomitriber >>>>> >>>>> >>>>> 2015-03-04 12:37 GMT+01:00 John D. Ament : >>>>> >>>>>> >>>>>> >>>>>> On Wed, Mar 4, 2015 at 6:35 AM Romain Manni-Bucau < >>>>>> rmannibucau at gmail.com> wrote: >>>>>> >>>>>>> 2015-03-04 12:29 GMT+01:00 John D. Ament : >>>>>>> >>>>>>>> Hmm.. comments in line. >>>>>>>> >>>>>>>> On Wed, Mar 4, 2015 at 4:49 AM Antoine Sabot-Durand < >>>>>>>> antoine at sabot-durand.net> wrote: >>>>>>>> >>>>>>>>> Hi John, >>>>>>>>> >>>>>>>>> I think it could be a good idea to write down all of these to have >>>>>>>>> a more stable doc for discussion. You should update the google doc with the >>>>>>>>> result of this discussion. >>>>>>>>> >>>>>>>>> I agree with the following points in this thread : >>>>>>>>> >>>>>>>>> - Minimize the number of new Class / Interface. CDI and >>>>>>>>> CDIProvider usage is still not very clear for end user so we should add the >>>>>>>>> strict minimum and try to enhance existing API / SPI when possible >>>>>>>>> >>>>>>>> >>>>>>>> It seems odd to me that we're rehashing decisions made during the >>>>>>>> EG meetings. Not putting it in CDI was discussed in several meetings at >>>>>>>> the beginning of the year, and it seemed like the agreement was putting it >>>>>>>> in CDI was a bad idea. >>>>>>>> >>>>>>>> >>>>>>>>> - Be able to bootstrap CDI without returning BeanManager (env if >>>>>>>>> the API give possibility to access it if needed). End user don?t need that >>>>>>>>> : CDI app can start with an observer for instance >>>>>>>>> >>>>>>>> >>>>>>>> Agreed, but I think we need to provide some entry point to allow >>>>>>>> those who aren't comfortable with programming with events to leverage it. >>>>>>>> Returning the CDI instance makes that easier to do than returning the >>>>>>>> BeanManager. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Can you detail it please? CDI value is only its getBeanManager() >>>>>>> method IMO so it sounds like it is 1-1 for me. >>>>>>> >>>>>> >>>>>> >>>>>> Taken from the docs I"m working on: >>>>>> >>>>>> MyBean myBean = container.initialize().select(MyBean.class).get(); >>>>>> myBean.doWork(); >>>>>> >>>>>> Vs the 3-4 lines it takes to get a reference using just BeanManager. >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>> Something not dealt with but that we should keep in mind : >>>>>>>>> - Providing a Java SE solution that could be easily used for a >>>>>>>>> servlet bootstrap of CDI. I don?t know if we?ll standardize this but we >>>>>>>>> definitely should keep this use case in mind >>>>>>>>> >>>>>>>>> and my bonus, it?s out of scope but I didn?t see anytime there >>>>>>>>> that prevent this nice to have: >>>>>>>>> - support the possibility to boot multiple BeanManager in Java SE. >>>>>>>>> >>>>>>>>> >>>>>>>> We talked about this one as well on the EG, either this year or >>>>>>>> late last year. I thought the decision at that time was that we wouldn't >>>>>>>> allow multiple containers at once in SE. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> wouldn't specify rather than wouldn't allow I think >>>>>>> >>>>>>> >>>>>>>> Antoine >>>>>>>>> >>>>>>>>> >>>>>>>>> Le 1 mars 2015 ? 15:13, John D. Ament a >>>>>>>>> ?crit : >>>>>>>>> >>>>>>>>> >>>>>>>>> So, I think I've gathered enough feedback at this point, and seen >>>>>>>>> some of the API changes. I'll hopefully be including some doc changes this >>>>>>>>> week, but one question - do we want to start the SE specific stuff as its >>>>>>>>> own asciidoc file? >>>>>>>>> >>>>>>>>> Changes made: >>>>>>>>> >>>>>>>>> - Changed return value to CDI to provide better capability >>>>>>>>> out of the box. >>>>>>>>> - Added AutoCloseable to CDIContainer, provided default >>>>>>>>> implementation of calling shutdown. >>>>>>>>> - Added synchronization support to the method body that retrieves >>>>>>>>> the singleton instance (BTW, I'm not sure if this is even useful TBH as >>>>>>>>> each impl, including the RI, needs to provide this class in its own format). >>>>>>>>> - Made the params map typed to >>>>>>>>> >>>>>>>>> @Romain Your case isn't really supportable yet, until we have >>>>>>>>> static injection support. You'd still have to have a managed version of >>>>>>>>> Runner to work against. >>>>>>>>> >>>>>>>>> John >>>>>>>>> >>>>>>>>> On Sat, Feb 28, 2015 at 4:11 PM Romain Manni-Bucau < >>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Yes but not the way to get an instance. Even Unmanaged does it. >>>>>>>>>> >>>>>>>>>> What can be awesome is to have static inject for it: >>>>>>>>>> >>>>>>>>>> public class Runner { >>>>>>>>>> >>>>>>>>>> @Inject >>>>>>>>>> private static MyMain main; >>>>>>>>>> >>>>>>>>>> public static void main(String[] arg) { >>>>>>>>>> try (CDIContainer c = CDIContainer.newContainer()) { >>>>>>>>>> main.doWork(); >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> And not a single additional line :). >>>>>>>>>> Le 28 f?vr. 2015 19:05, "John D. Ament" >>>>>>>>>> a ?crit : >>>>>>>>>> >>>>>>>>>> Maybe I'm misreading, but I don't see us adding another API to do >>>>>>>>>>> the same thing here - we're introducing new functionality. >>>>>>>>>>> >>>>>>>>>>> CDIContainer/Loader on startup/shutdown of the application >>>>>>>>>>> >>>>>>>>>>> CDI for runtime usage within the application to interact with >>>>>>>>>>> the container. >>>>>>>>>>> >>>>>>>>>>> John >>>>>>>>>>> >>>>>>>>>>> On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau < >>>>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> sure I fully agree excepted I think introducing yet another API >>>>>>>>>>>> to do >>>>>>>>>>>> the same thing is not good so super tempting to skip it and >>>>>>>>>>>> wait for >>>>>>>>>>>> feedbacks rather than introducing it eagerly. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>> @rmannibucau >>>>>>>>>>>> http://www.tomitribe.com >>>>>>>>>>>> http://rmannibucau.wordpress.com >>>>>>>>>>>> https://github.com/rmannibucau >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2015-02-27 8:05 GMT+01:00 Jozef Hartinger >>>>>>>>>>> >: >>>>>>>>>>>> > My point is that from the application perspective, the user >>>>>>>>>>>> obtains one >>>>>>>>>>>> > container handle for eventual shutdown (CDIContainer) and >>>>>>>>>>>> then looks up a >>>>>>>>>>>> > different container handle (CDI) that they can use for real >>>>>>>>>>>> work (lookup / >>>>>>>>>>>> > event dispatch / etc.) It would be cleaner if the container >>>>>>>>>>>> gave away a >>>>>>>>>>>> > single handle that can do all of that. >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: >>>>>>>>>>>> > >>>>>>>>>>>> > Not sure I get how a CDI instance can help. >>>>>>>>>>>> > >>>>>>>>>>>> > But container.getBeanManager() sounds nice is not a shortcut >>>>>>>>>>>> for >>>>>>>>>>>> > CDI.current().getBm() otherwise it looks like duplication to >>>>>>>>>>>> me. >>>>>>>>>>>> > >>>>>>>>>>>> > Can we make container not contextual - dont think so? If so >>>>>>>>>>>> it makes sense >>>>>>>>>>>> > otherwise I fear it doesnt add much. >>>>>>>>>>>> > >>>>>>>>>>>> > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" < >>>>>>>>>>>> jharting at redhat.com> a ?crit : >>>>>>>>>>>> >> >>>>>>>>>>>> >> I like the initialize + close() combination and the >>>>>>>>>>>> try-with-resources >>>>>>>>>>>> >> usage. >>>>>>>>>>>> >> What looks weird to me is that at line one you obtain a >>>>>>>>>>>> container handle: >>>>>>>>>>>> >> >>>>>>>>>>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>>>>>>>>>> >> CDI.current().getBeanManager() ... >>>>>>>>>>>> >> >>>>>>>>>>>> >> and then at line two you call a static method to perform a >>>>>>>>>>>> container >>>>>>>>>>>> >> lookup :-/ >>>>>>>>>>>> >> >>>>>>>>>>>> >> An API that allows you to use the container handle you >>>>>>>>>>>> already got is way >>>>>>>>>>>> >> better IMO, e.g.: >>>>>>>>>>>> >> >>>>>>>>>>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>>>>>>>>>> >> container.getBeanManager() >>>>>>>>>>>> >> >>>>>>>>>>>> >> If CDIContainer.newCDIContainer() returns an CDI instance or >>>>>>>>>>>> its subclass, >>>>>>>>>>>> >> we get this easily. >>>>>>>>>>>> >> >>>>>>>>>>>> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> Hi guys >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> why note keeping it simple? >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer(/* >>>>>>>>>>>> optional >>>>>>>>>>>> >>> map to configure vendor features */)) { >>>>>>>>>>>> >>> CDI.current().getBeanManager().... >>>>>>>>>>>> >>> } >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> Not sure the point having initialize() + having shutdown = >>>>>>>>>>>> close >>>>>>>>>>>> >>> really makes the API more fluent and modern IMO. >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> Also to be fully SE I guess provider() method would be >>>>>>>>>>>> needed even if >>>>>>>>>>>> >>> optional (SPI usage by default): >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> try (CDIContainer container = >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> CDIContainer.provider("org.jboss.weld. >>>>>>>>>>>> WeldCdiContainerProvider").newCDIContainer()) >>>>>>>>>>>> >>> { >>>>>>>>>>>> >>> CDI.current().getBeanManager().... >>>>>>>>>>>> >>> } >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> Finally I think having a kind of getInstance shortcut could >>>>>>>>>>>> be a plus for >>>>>>>>>>>> >>> SE: >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer()) >>>>>>>>>>>> { >>>>>>>>>>>> >>> container.newInstance(MyAppRunner.class /* optional >>>>>>>>>>>> qualifiers */ >>>>>>>>>>>> >>> ).run(args); >>>>>>>>>>>> >>> } >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> Using container to get an instance would create the >>>>>>>>>>>> instance and bind >>>>>>>>>>>> >>> it to the container lifecycle (mainly for predestroy) >>>>>>>>>>>> avoiding this >>>>>>>>>>>> >>> boilerplate code in all main which will surely only be used >>>>>>>>>>>> to launch >>>>>>>>>>>> >>> a soft. >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> wdyt? >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> Romain Manni-Bucau >>>>>>>>>>>> >>> @rmannibucau >>>>>>>>>>>> >>> http://www.tomitribe.com >>>>>>>>>>>> >>> http://rmannibucau.wordpress.com >>>>>>>>>>>> >>> https://github.com/rmannibucau >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger < >>>>>>>>>>>> jharting at redhat.com>: >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> Comments inline >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> Sorry Jozef, your email fell into the pits of google >>>>>>>>>>>> inbox's "smart >>>>>>>>>>>> >>>> sorting" >>>>>>>>>>>> >>>> features. >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger < >>>>>>>>>>>> jharting at redhat.com> >>>>>>>>>>>> >>>> wrote: >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> Hi John, comments inline: >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> Jozef, >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> Most of what you see there is taken from the original >>>>>>>>>>>> doc, since >>>>>>>>>>>> >>>>> everyone >>>>>>>>>>>> >>>>> seemed to be in agreement. I think the map is just a >>>>>>>>>>>> safeguard in case >>>>>>>>>>>> >>>>> of >>>>>>>>>>>> >>>>> additional boot options available in some implementations >>>>>>>>>>>> (e.g. I think >>>>>>>>>>>> >>>>> OWB/OpenEJB have some options.. currently OpenEJB >>>>>>>>>>>> supports an embedded >>>>>>>>>>>> >>>>> CDI >>>>>>>>>>>> >>>>> boot mode). >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> No, I am fine with the map. What I am questioning is the >>>>>>>>>>>> type of the >>>>>>>>>>>> >>>>> map. >>>>>>>>>>>> >>>>> Usually, data structures with a similar purpose use >>>>>>>>>>>> Strings as their >>>>>>>>>>>> >>>>> keys. >>>>>>>>>>>> >>>>> This applies to ServletContext attributes, >>>>>>>>>>>> InvocationContext data, >>>>>>>>>>>> >>>>> Servlet >>>>>>>>>>>> >>>>> request/session attributes and others. I am therefore >>>>>>>>>>>> wondering whether >>>>>>>>>>>> >>>>> there is a usecase for the proposed unbound key signature >>>>>>>>>>>> or not. >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> I think that's more of a placeholder, I was assuming it >>>>>>>>>>>> would be >>>>>>>>>>>> >>>> Map once we clarify everything. >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> We spoke a few times about BeanManager vs CDI. >>>>>>>>>>>> BeanManager was >>>>>>>>>>>> >>>>> preferable >>>>>>>>>>>> >>>>> since there's no easy way to get the the instance, CDI is >>>>>>>>>>>> easier to get >>>>>>>>>>>> >>>>> and >>>>>>>>>>>> >>>>> more aligned with how you would get it. Usually people >>>>>>>>>>>> expect the >>>>>>>>>>>> >>>>> BeanManager to be injected or available via JNDI, neither >>>>>>>>>>>> would be the >>>>>>>>>>>> >>>>> case >>>>>>>>>>>> >>>>> here. >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> If CDI 2.0 targets Java SE then this container >>>>>>>>>>>> initialization API will >>>>>>>>>>>> >>>>> become something that ordinary application developers use >>>>>>>>>>>> to start/stop >>>>>>>>>>>> >>>>> CDI >>>>>>>>>>>> >>>>> in their applications. It therefore cannot be considered >>>>>>>>>>>> an SPI but >>>>>>>>>>>> >>>>> instead >>>>>>>>>>>> >>>>> should be something easy to use. On the other hand, >>>>>>>>>>>> BeanManager is >>>>>>>>>>>> >>>>> definitely an SPI. It is used in extension, frameworks >>>>>>>>>>>> and generally >>>>>>>>>>>> >>>>> for >>>>>>>>>>>> >>>>> integration. Not much by applications directly. >>>>>>>>>>>> Therefore, I don't see >>>>>>>>>>>> >>>>> how >>>>>>>>>>>> >>>>> the container bootstrap API and BeanManager fit together. >>>>>>>>>>>> IMO the >>>>>>>>>>>> >>>>> bootstrap >>>>>>>>>>>> >>>>> API should expose something that makes common tasks >>>>>>>>>>>> (obtaining a >>>>>>>>>>>> >>>>> contextual >>>>>>>>>>>> >>>>> reference and firing and event) easy, which the CDI class >>>>>>>>>>>> does. >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> Plus do not forget that BeanManager can be obtained >>>>>>>>>>>> easily using >>>>>>>>>>>> >>>>> CDI.getBeanManager(). >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> I'm not disagreeing. There's a few things I'd consider: >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> - Is this mostly for new apps or existing? If existing, >>>>>>>>>>>> it's probably >>>>>>>>>>>> >>>> using >>>>>>>>>>>> >>>> some internal API, if new it can use whatever API we give. >>>>>>>>>>>> >>>> - I don't want to return void, we should give some kind of >>>>>>>>>>>> reference >>>>>>>>>>>> >>>> into >>>>>>>>>>>> >>>> the container when we're done booting. >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> Agreed, we should not be returning void. >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> - CDI is a one step retrievable reference, where as >>>>>>>>>>>> BeanManager is a two >>>>>>>>>>>> >>>> step reference. With that said, BeanManager makes more >>>>>>>>>>>> sense to return >>>>>>>>>>>> >>>> here. Another thought could be we invent some new class >>>>>>>>>>>> that has both, >>>>>>>>>>>> >>>> but >>>>>>>>>>>> >>>> that's really redundant. >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> Why do you think BeanManager makes more sense here? >>>>>>>>>>>> Especially given the >>>>>>>>>>>> >>>> assumption that application code is going to call this >>>>>>>>>>>> init/shutdown >>>>>>>>>>>> >>>> API, I >>>>>>>>>>>> >>>> don't see BeanManager as making more sense. >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> Yes, this is the container start API. Sounds like you >>>>>>>>>>>> have some good >>>>>>>>>>>> >>>>> ideas for things like XML configuration or programmatic >>>>>>>>>>>> configuration, >>>>>>>>>>>> >>>>> both >>>>>>>>>>>> >>>>> of which are being tracked under separate tickets. One >>>>>>>>>>>> idea might be >>>>>>>>>>>> >>>>> for an >>>>>>>>>>>> >>>>> optional param in the map to control packages to >>>>>>>>>>>> scan/ignore, in that >>>>>>>>>>>> >>>>> map. >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> I am wondering whether this configuration should be >>>>>>>>>>>> something optional >>>>>>>>>>>> >>>>> built on top of the bootstrap API or whether we should >>>>>>>>>>>> consider making >>>>>>>>>>>> >>>>> it >>>>>>>>>>>> >>>>> mandatory. Either way, we cannot add the bootstrap API to >>>>>>>>>>>> the spec >>>>>>>>>>>> >>>>> without >>>>>>>>>>>> >>>>> explicitly defining how it behaves. My implicit >>>>>>>>>>>> assumption of the >>>>>>>>>>>> >>>>> proposal >>>>>>>>>>>> >>>>> is that the container is supposed to scan the entire >>>>>>>>>>>> classpath for >>>>>>>>>>>> >>>>> explicit >>>>>>>>>>>> >>>>> or implicit bean archives (including e.g. rt.jar), >>>>>>>>>>>> discover beans, fire >>>>>>>>>>>> >>>>> extensions, etc. This worries me as this default behavior >>>>>>>>>>>> is far from >>>>>>>>>>>> >>>>> being >>>>>>>>>>>> >>>>> lightweight, which CDI for Java SE initially aimed to be. >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> Yes, the spec must be updated to reflect the behavior of >>>>>>>>>>>> SE mode. I >>>>>>>>>>>> >>>> plan to >>>>>>>>>>>> >>>> get that completely into the google doc before opening any >>>>>>>>>>>> spec changes >>>>>>>>>>>> >>>> in a >>>>>>>>>>>> >>>> PR. >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> We didn't want to over load the CDI interface. It >>>>>>>>>>>> already does a lot. >>>>>>>>>>>> >>>>> This is really SPI code, CDI even though it's in the spi >>>>>>>>>>>> package is >>>>>>>>>>>> >>>>> used in >>>>>>>>>>>> >>>>> a lot of application code. >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> I would personally prefer to have it all in one place. >>>>>>>>>>>> Having >>>>>>>>>>>> >>>>> CDIContainer, CDIContainerLoader, CDI and CDIProvider >>>>>>>>>>>> makes it more >>>>>>>>>>>> >>>>> difficult to know when to use what. >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> The problem is that most CDI (the interface) operations >>>>>>>>>>>> are against a >>>>>>>>>>>> >>>> running container. I think we spoke about leveraging >>>>>>>>>>>> CDIProvider at one >>>>>>>>>>>> >>>> point (in fact, I mistakenly called CDIContainer >>>>>>>>>>>> CDIProvider not even >>>>>>>>>>>> >>>> realizing it was there). I doubt that most app developers >>>>>>>>>>>> use it >>>>>>>>>>>> >>>> currently, >>>>>>>>>>>> >>>> there's not even a way to get a reference to it that I'm >>>>>>>>>>>> aware of. It's >>>>>>>>>>>> >>>> used by the implementor only. >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> I don't think there's a conflict. CDI class would still >>>>>>>>>>>> only provide >>>>>>>>>>>> >>>> methods >>>>>>>>>>>> >>>> to be run against a running container. The difference is >>>>>>>>>>>> that there >>>>>>>>>>>> >>>> would be >>>>>>>>>>>> >>>> additional static methods to get this running container >>>>>>>>>>>> (CDI class) to >>>>>>>>>>>> >>>> you >>>>>>>>>>>> >>>> by starting the container. >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> Either way, I agree that reusing CDIProvider is a must. >>>>>>>>>>>> There is no >>>>>>>>>>>> >>>> reason >>>>>>>>>>>> >>>> to define a new class for the same purpose. >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> I expect that my changes in the CDI spec around this will >>>>>>>>>>>> state, along >>>>>>>>>>>> >>>> the >>>>>>>>>>>> >>>> lines of: >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> To retrieve a CDIContainer to launch, do this: >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> CDIContainer container = CDIContainerLocator.getCDICont >>>>>>>>>>>> ainer(); >>>>>>>>>>>> >>>> container.initialize(); >>>>>>>>>>>> >>>> ... do work >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> Once you want to shutdown the container, do this: >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> container.shutdown(); >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> (we may want to consider implementing AutoCloseable, an >>>>>>>>>>>> oversight on my >>>>>>>>>>>> >>>> part) >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> and then later on >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> - What happens if I call CDIContainerLocator in an app >>>>>>>>>>>> server >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> - It throws an IllegalStateException. >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> - The container provides no beans of type CDIContainer, it >>>>>>>>>>>> is managed >>>>>>>>>>>> >>>> outside of the CDI container. >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> John >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger < >>>>>>>>>>>> jharting at redhat.com> >>>>>>>>>>>> >>>>> wrote: >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> Hi John, some thoughts: >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> - instead of using BeanManager it makes more sense to me >>>>>>>>>>>> to return a >>>>>>>>>>>> >>>>>> CDI >>>>>>>>>>>> >>>>>> instance, which is a more user-friendly API (and it also >>>>>>>>>>>> exposes >>>>>>>>>>>> >>>>>> access to >>>>>>>>>>>> >>>>>> BeanManager) >>>>>>>>>>>> >>>>>> - is there a usecase for arbitrary keys of the "params" >>>>>>>>>>>> map or is >>>>>>>>>>>> >>>>>> Map sufficient? >>>>>>>>>>>> >>>>>> - if we could move the shutdown() method from >>>>>>>>>>>> CDIContainer to the >>>>>>>>>>>> >>>>>> actual >>>>>>>>>>>> >>>>>> container handle that we obtain from initialize(), that >>>>>>>>>>>> would look >>>>>>>>>>>> >>>>>> more >>>>>>>>>>>> >>>>>> object-oriented >>>>>>>>>>>> >>>>>> - what exactly is initialize() supposed to do? Is it >>>>>>>>>>>> supposed to start >>>>>>>>>>>> >>>>>> scanning the entire classpath for CDI beans? That could >>>>>>>>>>>> be a problem >>>>>>>>>>>> >>>>>> especially with spring-boot-like fat jars. I think we >>>>>>>>>>>> need an API to >>>>>>>>>>>> >>>>>> tell >>>>>>>>>>>> >>>>>> the container which classes / packages to consider. >>>>>>>>>>>> Something like >>>>>>>>>>>> >>>>>> Guice's >>>>>>>>>>>> >>>>>> binding API perhaps? >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> - the proposal makes me wonder whether retrofitting this >>>>>>>>>>>> functionality >>>>>>>>>>>> >>>>>> to >>>>>>>>>>>> >>>>>> the CDI class wouldn't be a better option. It could look >>>>>>>>>>>> like: >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> CDI container = CDI.initialize(); >>>>>>>>>>>> >>>>>> container.select(Foo.class).get(); >>>>>>>>>>>> >>>>>> container.shutdown(); >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> compare it to: >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> CDIContainer container = CDIContainerLoader. >>>>>>>>>>>> getCDIContainer(); >>>>>>>>>>>> >>>>>> BeanManager manager = container.initialize(); >>>>>>>>>>>> >>>>>> manager.getBeans(...); >>>>>>>>>>>> >>>>>> container.shutdown(manager); >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> All, >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> I have the updated API here, and wanted to solicit any >>>>>>>>>>>> final feedback >>>>>>>>>>>> >>>>>> before updating the google doc and spec pages. >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> https://github.com/johnament/cdi/commit/ >>>>>>>>>>>> 2c362161e18dd521f8e83c27151ddad467a1c01c >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> Let me know your thoughts. >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> Thanks, >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> John >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> _______________________________________________ >>>>>>>>>>>> >>>>>> cdi-dev mailing list >>>>>>>>>>>> >>>>>> cdi-dev at lists.jboss.org >>>>>>>>>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> Note that for all code provided on this list, the >>>>>>>>>>>> provider licenses >>>>>>>>>>>> >>>>>> the >>>>>>>>>>>> >>>>>> code under the Apache License, Version 2 >>>>>>>>>>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For >>>>>>>>>>>> all other ideas >>>>>>>>>>>> >>>>>> provided on this list, the provider waives all patent >>>>>>>>>>>> and other >>>>>>>>>>>> >>>>>> intellectual >>>>>>>>>>>> >>>>>> property rights inherent in such information. >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> _______________________________________________ >>>>>>>>>>>> >>>> cdi-dev mailing list >>>>>>>>>>>> >>>> cdi-dev at lists.jboss.org >>>>>>>>>>>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> Note that for all code provided on this list, the provider >>>>>>>>>>>> licenses the >>>>>>>>>>>> >>>> code >>>>>>>>>>>> >>>> under the Apache License, Version 2 >>>>>>>>>>>> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For >>>>>>>>>>>> all other ideas >>>>>>>>>>>> >>>> provided on this list, the provider waives all patent and >>>>>>>>>>>> other >>>>>>>>>>>> >>>> intellectual >>>>>>>>>>>> >>>> property rights inherent in such information. >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> > >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>> cdi-dev mailing list >>>>>>>>> cdi-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>>> >>>>>>>>> Note that for all code provided on this list, the provider >>>>>>>>> licenses the code under the Apache License, Version 2 ( >>>>>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>>>>>>>> ideas provided on this list, the provider waives all patent and other >>>>>>>>> intellectual property rights inherent in such information. >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> cdi-dev mailing list >>>>>>>> cdi-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>> >>>>>>>> Note that for all code provided on this list, the provider licenses >>>>>>>> the code under the Apache License, Version 2 ( >>>>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>>>>>>> ideas provided on this list, the provider waives all patent and other >>>>>>>> intellectual property rights inherent in such information. >>>>>>>> >>>>>>> >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/dde61280/attachment-0001.html From rmannibucau at gmail.com Wed Mar 4 07:41:49 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 4 Mar 2015 13:41:49 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: References: Message-ID: try (CDIContainer container = CDIContainer.newCDIContainer()) { UnmanagedInstance main = new Unmanaged(MyMain.class) .create(); main.get().run(args); // we can even reuse main(String[]) args here main.destroy(); } Now let's call destroy close and we get: try (CDIContainer container = CDIContainer.newCDIContainer()) { try (UnmanagedInstance main = new Unmanaged(MyMain.class).create()) { main.get().run(args); } } Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-03-04 13:35 GMT+01:00 John D. Ament : > I don't understand the relationship to Java SE mode. > > On Wed, Mar 4, 2015 at 7:33 AM Romain Manni-Bucau > wrote: > >> instead of >> >> Unmanaged unmanagedFoo = new Unmanaged(Foo.class); >> UnmanagedInstance fooInstance = unmanagedFoo.newInstance(); >> Foo foo = fooInstance.produce().inject().postConstruct().get(); >> ... // Use the foo instance >> fooInstance.preDestroy().dispose(); >> >> >> just doing >> >> >> UnmanagedInstance fooInstance = new Unmanaged(Foo.class).create(); >> ... // Use the foo instance >> fooInstance.destroy(); >> >> >> Would make the main then quite trivial and more user friendly IMO >> >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> 2015-03-04 13:31 GMT+01:00 John D. Ament : >> >>> Get what enhancements? >>> >>> On Wed, Mar 4, 2015 at 7:28 AM Romain Manni-Bucau >>> wrote: >>> >>>> ok, initialize was returning a CDI instance then. >>>> >>>> If CDI instance is so present why bothering container api with it? Just >>>> looks like another Unmanaged. In this case I would enhance Unmanaged to >>>> have shortcut like create() (shortcut for >>>> produce()/inject()/postConstruct()) and destroy >>>> (preDestroy()/dispose()). Said otherwise: the need is already in the API so >>>> why not letting EE getting these enhancement as well? >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau | Blog >>>> | Github >>>> | LinkedIn >>>> | Tomitriber >>>> >>>> >>>> 2015-03-04 13:09 GMT+01:00 John D. Ament : >>>> >>>>> Same way as defined in the spec >>>>> >>>>> CDI.current().destroy(..) >>>>> >>>>> On Wed, Mar 4, 2015 at 6:44 AM Romain Manni-Bucau < >>>>> rmannibucau at gmail.com> wrote: >>>>> >>>>>> hmm, and if the bean is @Dependent? how do you release it? >>>>>> >>>>>> >>>>>> Romain Manni-Bucau >>>>>> @rmannibucau | Blog >>>>>> | Github >>>>>> | LinkedIn >>>>>> | Tomitriber >>>>>> >>>>>> >>>>>> 2015-03-04 12:37 GMT+01:00 John D. Ament : >>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Mar 4, 2015 at 6:35 AM Romain Manni-Bucau < >>>>>>> rmannibucau at gmail.com> wrote: >>>>>>> >>>>>>>> 2015-03-04 12:29 GMT+01:00 John D. Ament : >>>>>>>> >>>>>>>>> Hmm.. comments in line. >>>>>>>>> >>>>>>>>> On Wed, Mar 4, 2015 at 4:49 AM Antoine Sabot-Durand < >>>>>>>>> antoine at sabot-durand.net> wrote: >>>>>>>>> >>>>>>>>>> Hi John, >>>>>>>>>> >>>>>>>>>> I think it could be a good idea to write down all of these to >>>>>>>>>> have a more stable doc for discussion. You should update the google doc >>>>>>>>>> with the result of this discussion. >>>>>>>>>> >>>>>>>>>> I agree with the following points in this thread : >>>>>>>>>> >>>>>>>>>> - Minimize the number of new Class / Interface. CDI and >>>>>>>>>> CDIProvider usage is still not very clear for end user so we should add the >>>>>>>>>> strict minimum and try to enhance existing API / SPI when possible >>>>>>>>>> >>>>>>>>> >>>>>>>>> It seems odd to me that we're rehashing decisions made during the >>>>>>>>> EG meetings. Not putting it in CDI was discussed in several meetings at >>>>>>>>> the beginning of the year, and it seemed like the agreement was putting it >>>>>>>>> in CDI was a bad idea. >>>>>>>>> >>>>>>>>> >>>>>>>>>> - Be able to bootstrap CDI without returning BeanManager (env if >>>>>>>>>> the API give possibility to access it if needed). End user don?t need that >>>>>>>>>> : CDI app can start with an observer for instance >>>>>>>>>> >>>>>>>>> >>>>>>>>> Agreed, but I think we need to provide some entry point to allow >>>>>>>>> those who aren't comfortable with programming with events to leverage it. >>>>>>>>> Returning the CDI instance makes that easier to do than returning the >>>>>>>>> BeanManager. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Can you detail it please? CDI value is only its getBeanManager() >>>>>>>> method IMO so it sounds like it is 1-1 for me. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> Taken from the docs I"m working on: >>>>>>> >>>>>>> MyBean myBean = container.initialize().select(MyBean.class).get(); >>>>>>> myBean.doWork(); >>>>>>> >>>>>>> Vs the 3-4 lines it takes to get a reference using just BeanManager. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>> Something not dealt with but that we should keep in mind : >>>>>>>>>> - Providing a Java SE solution that could be easily used for a >>>>>>>>>> servlet bootstrap of CDI. I don?t know if we?ll standardize this but we >>>>>>>>>> definitely should keep this use case in mind >>>>>>>>>> >>>>>>>>>> and my bonus, it?s out of scope but I didn?t see anytime there >>>>>>>>>> that prevent this nice to have: >>>>>>>>>> - support the possibility to boot multiple BeanManager in Java SE. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> We talked about this one as well on the EG, either this year or >>>>>>>>> late last year. I thought the decision at that time was that we wouldn't >>>>>>>>> allow multiple containers at once in SE. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> wouldn't specify rather than wouldn't allow I think >>>>>>>> >>>>>>>> >>>>>>>>> Antoine >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Le 1 mars 2015 ? 15:13, John D. Ament a >>>>>>>>>> ?crit : >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> So, I think I've gathered enough feedback at this point, and seen >>>>>>>>>> some of the API changes. I'll hopefully be including some doc changes this >>>>>>>>>> week, but one question - do we want to start the SE specific stuff as its >>>>>>>>>> own asciidoc file? >>>>>>>>>> >>>>>>>>>> Changes made: >>>>>>>>>> >>>>>>>>>> - Changed return value to CDI to provide better >>>>>>>>>> capability out of the box. >>>>>>>>>> - Added AutoCloseable to CDIContainer, provided default >>>>>>>>>> implementation of calling shutdown. >>>>>>>>>> - Added synchronization support to the method body that retrieves >>>>>>>>>> the singleton instance (BTW, I'm not sure if this is even useful TBH as >>>>>>>>>> each impl, including the RI, needs to provide this class in its own format). >>>>>>>>>> - Made the params map typed to >>>>>>>>>> >>>>>>>>>> @Romain Your case isn't really supportable yet, until we have >>>>>>>>>> static injection support. You'd still have to have a managed version of >>>>>>>>>> Runner to work against. >>>>>>>>>> >>>>>>>>>> John >>>>>>>>>> >>>>>>>>>> On Sat, Feb 28, 2015 at 4:11 PM Romain Manni-Bucau < >>>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Yes but not the way to get an instance. Even Unmanaged does it. >>>>>>>>>>> >>>>>>>>>>> What can be awesome is to have static inject for it: >>>>>>>>>>> >>>>>>>>>>> public class Runner { >>>>>>>>>>> >>>>>>>>>>> @Inject >>>>>>>>>>> private static MyMain main; >>>>>>>>>>> >>>>>>>>>>> public static void main(String[] arg) { >>>>>>>>>>> try (CDIContainer c = CDIContainer.newContainer()) { >>>>>>>>>>> main.doWork(); >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> And not a single additional line :). >>>>>>>>>>> Le 28 f?vr. 2015 19:05, "John D. Ament" >>>>>>>>>>> a ?crit : >>>>>>>>>>> >>>>>>>>>>> Maybe I'm misreading, but I don't see us adding another API to >>>>>>>>>>>> do the same thing here - we're introducing new functionality. >>>>>>>>>>>> >>>>>>>>>>>> CDIContainer/Loader on startup/shutdown of the application >>>>>>>>>>>> >>>>>>>>>>>> CDI for runtime usage within the application to interact with >>>>>>>>>>>> the container. >>>>>>>>>>>> >>>>>>>>>>>> John >>>>>>>>>>>> >>>>>>>>>>>> On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau < >>>>>>>>>>>> rmannibucau at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> sure I fully agree excepted I think introducing yet another >>>>>>>>>>>>> API to do >>>>>>>>>>>>> the same thing is not good so super tempting to skip it and >>>>>>>>>>>>> wait for >>>>>>>>>>>>> feedbacks rather than introducing it eagerly. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>> @rmannibucau >>>>>>>>>>>>> http://www.tomitribe.com >>>>>>>>>>>>> http://rmannibucau.wordpress.com >>>>>>>>>>>>> https://github.com/rmannibucau >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2015-02-27 8:05 GMT+01:00 Jozef Hartinger >>>>>>>>>>>> >: >>>>>>>>>>>>> > My point is that from the application perspective, the user >>>>>>>>>>>>> obtains one >>>>>>>>>>>>> > container handle for eventual shutdown (CDIContainer) and >>>>>>>>>>>>> then looks up a >>>>>>>>>>>>> > different container handle (CDI) that they can use for real >>>>>>>>>>>>> work (lookup / >>>>>>>>>>>>> > event dispatch / etc.) It would be cleaner if the container >>>>>>>>>>>>> gave away a >>>>>>>>>>>>> > single handle that can do all of that. >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: >>>>>>>>>>>>> > >>>>>>>>>>>>> > Not sure I get how a CDI instance can help. >>>>>>>>>>>>> > >>>>>>>>>>>>> > But container.getBeanManager() sounds nice is not a shortcut >>>>>>>>>>>>> for >>>>>>>>>>>>> > CDI.current().getBm() otherwise it looks like duplication to >>>>>>>>>>>>> me. >>>>>>>>>>>>> > >>>>>>>>>>>>> > Can we make container not contextual - dont think so? If so >>>>>>>>>>>>> it makes sense >>>>>>>>>>>>> > otherwise I fear it doesnt add much. >>>>>>>>>>>>> > >>>>>>>>>>>>> > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" < >>>>>>>>>>>>> jharting at redhat.com> a ?crit : >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> I like the initialize + close() combination and the >>>>>>>>>>>>> try-with-resources >>>>>>>>>>>>> >> usage. >>>>>>>>>>>>> >> What looks weird to me is that at line one you obtain a >>>>>>>>>>>>> container handle: >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>>>>>>>>>>> >> CDI.current().getBeanManager() ... >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> and then at line two you call a static method to perform a >>>>>>>>>>>>> container >>>>>>>>>>>>> >> lookup :-/ >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> An API that allows you to use the container handle you >>>>>>>>>>>>> already got is way >>>>>>>>>>>>> >> better IMO, e.g.: >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>>>>>>>>>>> >> container.getBeanManager() >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> If CDIContainer.newCDIContainer() returns an CDI instance >>>>>>>>>>>>> or its subclass, >>>>>>>>>>>>> >> we get this easily. >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> Hi guys >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> why note keeping it simple? >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> try (CDIContainer container = >>>>>>>>>>>>> CDIContainer.newCDIContainer(/* optional >>>>>>>>>>>>> >>> map to configure vendor features */)) { >>>>>>>>>>>>> >>> CDI.current().getBeanManager().... >>>>>>>>>>>>> >>> } >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> Not sure the point having initialize() + having shutdown = >>>>>>>>>>>>> close >>>>>>>>>>>>> >>> really makes the API more fluent and modern IMO. >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> Also to be fully SE I guess provider() method would be >>>>>>>>>>>>> needed even if >>>>>>>>>>>>> >>> optional (SPI usage by default): >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> try (CDIContainer container = >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> CDIContainer.provider("org.jboss.weld. >>>>>>>>>>>>> WeldCdiContainerProvider").newCDIContainer()) >>>>>>>>>>>>> >>> { >>>>>>>>>>>>> >>> CDI.current().getBeanManager().... >>>>>>>>>>>>> >>> } >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> Finally I think having a kind of getInstance shortcut >>>>>>>>>>>>> could be a plus for >>>>>>>>>>>>> >>> SE: >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> try (CDIContainer container = >>>>>>>>>>>>> CDIContainer.newCDIContainer()) { >>>>>>>>>>>>> >>> container.newInstance(MyAppRunner.class /* optional >>>>>>>>>>>>> qualifiers */ >>>>>>>>>>>>> >>> ).run(args); >>>>>>>>>>>>> >>> } >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> Using container to get an instance would create the >>>>>>>>>>>>> instance and bind >>>>>>>>>>>>> >>> it to the container lifecycle (mainly for predestroy) >>>>>>>>>>>>> avoiding this >>>>>>>>>>>>> >>> boilerplate code in all main which will surely only be >>>>>>>>>>>>> used to launch >>>>>>>>>>>>> >>> a soft. >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> wdyt? >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> Romain Manni-Bucau >>>>>>>>>>>>> >>> @rmannibucau >>>>>>>>>>>>> >>> http://www.tomitribe.com >>>>>>>>>>>>> >>> http://rmannibucau.wordpress.com >>>>>>>>>>>>> >>> https://github.com/rmannibucau >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger < >>>>>>>>>>>>> jharting at redhat.com>: >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> Comments inline >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> Sorry Jozef, your email fell into the pits of google >>>>>>>>>>>>> inbox's "smart >>>>>>>>>>>>> >>>> sorting" >>>>>>>>>>>>> >>>> features. >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger < >>>>>>>>>>>>> jharting at redhat.com> >>>>>>>>>>>>> >>>> wrote: >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> Hi John, comments inline: >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> Jozef, >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> Most of what you see there is taken from the original >>>>>>>>>>>>> doc, since >>>>>>>>>>>>> >>>>> everyone >>>>>>>>>>>>> >>>>> seemed to be in agreement. I think the map is just a >>>>>>>>>>>>> safeguard in case >>>>>>>>>>>>> >>>>> of >>>>>>>>>>>>> >>>>> additional boot options available in some >>>>>>>>>>>>> implementations (e.g. I think >>>>>>>>>>>>> >>>>> OWB/OpenEJB have some options.. currently OpenEJB >>>>>>>>>>>>> supports an embedded >>>>>>>>>>>>> >>>>> CDI >>>>>>>>>>>>> >>>>> boot mode). >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> No, I am fine with the map. What I am questioning is the >>>>>>>>>>>>> type of the >>>>>>>>>>>>> >>>>> map. >>>>>>>>>>>>> >>>>> Usually, data structures with a similar purpose use >>>>>>>>>>>>> Strings as their >>>>>>>>>>>>> >>>>> keys. >>>>>>>>>>>>> >>>>> This applies to ServletContext attributes, >>>>>>>>>>>>> InvocationContext data, >>>>>>>>>>>>> >>>>> Servlet >>>>>>>>>>>>> >>>>> request/session attributes and others. I am therefore >>>>>>>>>>>>> wondering whether >>>>>>>>>>>>> >>>>> there is a usecase for the proposed unbound key >>>>>>>>>>>>> signature or not. >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> I think that's more of a placeholder, I was assuming it >>>>>>>>>>>>> would be >>>>>>>>>>>>> >>>> Map once we clarify everything. >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> We spoke a few times about BeanManager vs CDI. >>>>>>>>>>>>> BeanManager was >>>>>>>>>>>>> >>>>> preferable >>>>>>>>>>>>> >>>>> since there's no easy way to get the the instance, CDI >>>>>>>>>>>>> is easier to get >>>>>>>>>>>>> >>>>> and >>>>>>>>>>>>> >>>>> more aligned with how you would get it. Usually people >>>>>>>>>>>>> expect the >>>>>>>>>>>>> >>>>> BeanManager to be injected or available via JNDI, >>>>>>>>>>>>> neither would be the >>>>>>>>>>>>> >>>>> case >>>>>>>>>>>>> >>>>> here. >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> If CDI 2.0 targets Java SE then this container >>>>>>>>>>>>> initialization API will >>>>>>>>>>>>> >>>>> become something that ordinary application developers >>>>>>>>>>>>> use to start/stop >>>>>>>>>>>>> >>>>> CDI >>>>>>>>>>>>> >>>>> in their applications. It therefore cannot be considered >>>>>>>>>>>>> an SPI but >>>>>>>>>>>>> >>>>> instead >>>>>>>>>>>>> >>>>> should be something easy to use. On the other hand, >>>>>>>>>>>>> BeanManager is >>>>>>>>>>>>> >>>>> definitely an SPI. It is used in extension, frameworks >>>>>>>>>>>>> and generally >>>>>>>>>>>>> >>>>> for >>>>>>>>>>>>> >>>>> integration. Not much by applications directly. >>>>>>>>>>>>> Therefore, I don't see >>>>>>>>>>>>> >>>>> how >>>>>>>>>>>>> >>>>> the container bootstrap API and BeanManager fit >>>>>>>>>>>>> together. IMO the >>>>>>>>>>>>> >>>>> bootstrap >>>>>>>>>>>>> >>>>> API should expose something that makes common tasks >>>>>>>>>>>>> (obtaining a >>>>>>>>>>>>> >>>>> contextual >>>>>>>>>>>>> >>>>> reference and firing and event) easy, which the CDI >>>>>>>>>>>>> class does. >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> Plus do not forget that BeanManager can be obtained >>>>>>>>>>>>> easily using >>>>>>>>>>>>> >>>>> CDI.getBeanManager(). >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> I'm not disagreeing. There's a few things I'd consider: >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> - Is this mostly for new apps or existing? If existing, >>>>>>>>>>>>> it's probably >>>>>>>>>>>>> >>>> using >>>>>>>>>>>>> >>>> some internal API, if new it can use whatever API we give. >>>>>>>>>>>>> >>>> - I don't want to return void, we should give some kind >>>>>>>>>>>>> of reference >>>>>>>>>>>>> >>>> into >>>>>>>>>>>>> >>>> the container when we're done booting. >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> Agreed, we should not be returning void. >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> - CDI is a one step retrievable reference, where as >>>>>>>>>>>>> BeanManager is a two >>>>>>>>>>>>> >>>> step reference. With that said, BeanManager makes more >>>>>>>>>>>>> sense to return >>>>>>>>>>>>> >>>> here. Another thought could be we invent some new class >>>>>>>>>>>>> that has both, >>>>>>>>>>>>> >>>> but >>>>>>>>>>>>> >>>> that's really redundant. >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> Why do you think BeanManager makes more sense here? >>>>>>>>>>>>> Especially given the >>>>>>>>>>>>> >>>> assumption that application code is going to call this >>>>>>>>>>>>> init/shutdown >>>>>>>>>>>>> >>>> API, I >>>>>>>>>>>>> >>>> don't see BeanManager as making more sense. >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> Yes, this is the container start API. Sounds like you >>>>>>>>>>>>> have some good >>>>>>>>>>>>> >>>>> ideas for things like XML configuration or programmatic >>>>>>>>>>>>> configuration, >>>>>>>>>>>>> >>>>> both >>>>>>>>>>>>> >>>>> of which are being tracked under separate tickets. One >>>>>>>>>>>>> idea might be >>>>>>>>>>>>> >>>>> for an >>>>>>>>>>>>> >>>>> optional param in the map to control packages to >>>>>>>>>>>>> scan/ignore, in that >>>>>>>>>>>>> >>>>> map. >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> I am wondering whether this configuration should be >>>>>>>>>>>>> something optional >>>>>>>>>>>>> >>>>> built on top of the bootstrap API or whether we should >>>>>>>>>>>>> consider making >>>>>>>>>>>>> >>>>> it >>>>>>>>>>>>> >>>>> mandatory. Either way, we cannot add the bootstrap API >>>>>>>>>>>>> to the spec >>>>>>>>>>>>> >>>>> without >>>>>>>>>>>>> >>>>> explicitly defining how it behaves. My implicit >>>>>>>>>>>>> assumption of the >>>>>>>>>>>>> >>>>> proposal >>>>>>>>>>>>> >>>>> is that the container is supposed to scan the entire >>>>>>>>>>>>> classpath for >>>>>>>>>>>>> >>>>> explicit >>>>>>>>>>>>> >>>>> or implicit bean archives (including e.g. rt.jar), >>>>>>>>>>>>> discover beans, fire >>>>>>>>>>>>> >>>>> extensions, etc. This worries me as this default >>>>>>>>>>>>> behavior is far from >>>>>>>>>>>>> >>>>> being >>>>>>>>>>>>> >>>>> lightweight, which CDI for Java SE initially aimed to be. >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> Yes, the spec must be updated to reflect the behavior of >>>>>>>>>>>>> SE mode. I >>>>>>>>>>>>> >>>> plan to >>>>>>>>>>>>> >>>> get that completely into the google doc before opening >>>>>>>>>>>>> any spec changes >>>>>>>>>>>>> >>>> in a >>>>>>>>>>>>> >>>> PR. >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> We didn't want to over load the CDI interface. It >>>>>>>>>>>>> already does a lot. >>>>>>>>>>>>> >>>>> This is really SPI code, CDI even though it's in the spi >>>>>>>>>>>>> package is >>>>>>>>>>>>> >>>>> used in >>>>>>>>>>>>> >>>>> a lot of application code. >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> I would personally prefer to have it all in one place. >>>>>>>>>>>>> Having >>>>>>>>>>>>> >>>>> CDIContainer, CDIContainerLoader, CDI and CDIProvider >>>>>>>>>>>>> makes it more >>>>>>>>>>>>> >>>>> difficult to know when to use what. >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> The problem is that most CDI (the interface) operations >>>>>>>>>>>>> are against a >>>>>>>>>>>>> >>>> running container. I think we spoke about leveraging >>>>>>>>>>>>> CDIProvider at one >>>>>>>>>>>>> >>>> point (in fact, I mistakenly called CDIContainer >>>>>>>>>>>>> CDIProvider not even >>>>>>>>>>>>> >>>> realizing it was there). I doubt that most app >>>>>>>>>>>>> developers use it >>>>>>>>>>>>> >>>> currently, >>>>>>>>>>>>> >>>> there's not even a way to get a reference to it that I'm >>>>>>>>>>>>> aware of. It's >>>>>>>>>>>>> >>>> used by the implementor only. >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> I don't think there's a conflict. CDI class would still >>>>>>>>>>>>> only provide >>>>>>>>>>>>> >>>> methods >>>>>>>>>>>>> >>>> to be run against a running container. The difference is >>>>>>>>>>>>> that there >>>>>>>>>>>>> >>>> would be >>>>>>>>>>>>> >>>> additional static methods to get this running container >>>>>>>>>>>>> (CDI class) to >>>>>>>>>>>>> >>>> you >>>>>>>>>>>>> >>>> by starting the container. >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> Either way, I agree that reusing CDIProvider is a must. >>>>>>>>>>>>> There is no >>>>>>>>>>>>> >>>> reason >>>>>>>>>>>>> >>>> to define a new class for the same purpose. >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> I expect that my changes in the CDI spec around this will >>>>>>>>>>>>> state, along >>>>>>>>>>>>> >>>> the >>>>>>>>>>>>> >>>> lines of: >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> To retrieve a CDIContainer to launch, do this: >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> CDIContainer container = CDIContainerLocator.getCDICont >>>>>>>>>>>>> ainer(); >>>>>>>>>>>>> >>>> container.initialize(); >>>>>>>>>>>>> >>>> ... do work >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> Once you want to shutdown the container, do this: >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> container.shutdown(); >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> (we may want to consider implementing AutoCloseable, an >>>>>>>>>>>>> oversight on my >>>>>>>>>>>>> >>>> part) >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> and then later on >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> - What happens if I call CDIContainerLocator in an app >>>>>>>>>>>>> server >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> - It throws an IllegalStateException. >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> - The container provides no beans of type CDIContainer, >>>>>>>>>>>>> it is managed >>>>>>>>>>>>> >>>> outside of the CDI container. >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> John >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger < >>>>>>>>>>>>> jharting at redhat.com> >>>>>>>>>>>>> >>>>> wrote: >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> Hi John, some thoughts: >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> - instead of using BeanManager it makes more sense to >>>>>>>>>>>>> me to return a >>>>>>>>>>>>> >>>>>> CDI >>>>>>>>>>>>> >>>>>> instance, which is a more user-friendly API (and it >>>>>>>>>>>>> also exposes >>>>>>>>>>>>> >>>>>> access to >>>>>>>>>>>>> >>>>>> BeanManager) >>>>>>>>>>>>> >>>>>> - is there a usecase for arbitrary keys of the "params" >>>>>>>>>>>>> map or is >>>>>>>>>>>>> >>>>>> Map sufficient? >>>>>>>>>>>>> >>>>>> - if we could move the shutdown() method from >>>>>>>>>>>>> CDIContainer to the >>>>>>>>>>>>> >>>>>> actual >>>>>>>>>>>>> >>>>>> container handle that we obtain from initialize(), that >>>>>>>>>>>>> would look >>>>>>>>>>>>> >>>>>> more >>>>>>>>>>>>> >>>>>> object-oriented >>>>>>>>>>>>> >>>>>> - what exactly is initialize() supposed to do? Is it >>>>>>>>>>>>> supposed to start >>>>>>>>>>>>> >>>>>> scanning the entire classpath for CDI beans? That could >>>>>>>>>>>>> be a problem >>>>>>>>>>>>> >>>>>> especially with spring-boot-like fat jars. I think we >>>>>>>>>>>>> need an API to >>>>>>>>>>>>> >>>>>> tell >>>>>>>>>>>>> >>>>>> the container which classes / packages to consider. >>>>>>>>>>>>> Something like >>>>>>>>>>>>> >>>>>> Guice's >>>>>>>>>>>>> >>>>>> binding API perhaps? >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> - the proposal makes me wonder whether retrofitting >>>>>>>>>>>>> this functionality >>>>>>>>>>>>> >>>>>> to >>>>>>>>>>>>> >>>>>> the CDI class wouldn't be a better option. It could >>>>>>>>>>>>> look like: >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> CDI container = CDI.initialize(); >>>>>>>>>>>>> >>>>>> container.select(Foo.class).get(); >>>>>>>>>>>>> >>>>>> container.shutdown(); >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> compare it to: >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> CDIContainer container = CDIContainerLoader. >>>>>>>>>>>>> getCDIContainer(); >>>>>>>>>>>>> >>>>>> BeanManager manager = container.initialize(); >>>>>>>>>>>>> >>>>>> manager.getBeans(...); >>>>>>>>>>>>> >>>>>> container.shutdown(manager); >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> All, >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> I have the updated API here, and wanted to solicit any >>>>>>>>>>>>> final feedback >>>>>>>>>>>>> >>>>>> before updating the google doc and spec pages. >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> https://github.com/johnament/cdi/commit/ >>>>>>>>>>>>> 2c362161e18dd521f8e83c27151ddad467a1c01c >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> Let me know your thoughts. >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> Thanks, >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> John >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> _______________________________________________ >>>>>>>>>>>>> >>>>>> cdi-dev mailing list >>>>>>>>>>>>> >>>>>> cdi-dev at lists.jboss.org >>>>>>>>>>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> Note that for all code provided on this list, the >>>>>>>>>>>>> provider licenses >>>>>>>>>>>>> >>>>>> the >>>>>>>>>>>>> >>>>>> code under the Apache License, Version 2 >>>>>>>>>>>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For >>>>>>>>>>>>> all other ideas >>>>>>>>>>>>> >>>>>> provided on this list, the provider waives all patent >>>>>>>>>>>>> and other >>>>>>>>>>>>> >>>>>> intellectual >>>>>>>>>>>>> >>>>>> property rights inherent in such information. >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> _______________________________________________ >>>>>>>>>>>>> >>>> cdi-dev mailing list >>>>>>>>>>>>> >>>> cdi-dev at lists.jboss.org >>>>>>>>>>>>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> Note that for all code provided on this list, the >>>>>>>>>>>>> provider licenses the >>>>>>>>>>>>> >>>> code >>>>>>>>>>>>> >>>> under the Apache License, Version 2 >>>>>>>>>>>>> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For >>>>>>>>>>>>> all other ideas >>>>>>>>>>>>> >>>> provided on this list, the provider waives all patent and >>>>>>>>>>>>> other >>>>>>>>>>>>> >>>> intellectual >>>>>>>>>>>>> >>>> property rights inherent in such information. >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>> cdi-dev mailing list >>>>>>>>>> cdi-dev at lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>>>> >>>>>>>>>> Note that for all code provided on this list, the provider >>>>>>>>>> licenses the code under the Apache License, Version 2 ( >>>>>>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>>>>>>>>> ideas provided on this list, the provider waives all patent and other >>>>>>>>>> intellectual property rights inherent in such information. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> cdi-dev mailing list >>>>>>>>> cdi-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>>> >>>>>>>>> Note that for all code provided on this list, the provider >>>>>>>>> licenses the code under the Apache License, Version 2 ( >>>>>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>>>>>>>> ideas provided on this list, the provider waives all patent and other >>>>>>>>> intellectual property rights inherent in such information. >>>>>>>>> >>>>>>>> >>>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/6285effb/attachment-0001.html From jharting at redhat.com Wed Mar 4 07:43:30 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 04 Mar 2015 13:43:30 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: References: <54DB1F2B.1020609@redhat.com> <54DC61D9.701@redhat.com> <54EECC20.6040600@redhat.com> <54EF396E.20805@redhat.com> <54F01720.3080802@redhat.com> <54F6CACD.6080507@redhat.com> Message-ID: <54F6FDF2.3000808@redhat.com> The only argument I found supporting a strict separation of those two APIs is that it makes it easier to control when a user should or should not use boot (i.e. it should not be used in EE for example). That's a good argument. It's not however necessarily only achieved by two separate interfaces but can be as well be achieved with a subclass, e.g: - CDI for runtime operations only - StartedCDI extends CDI (or CDIContainer or whatever - the name does not matter at this point) for runtime operations + shutdown. Normally, CDI is available only. The boot API however would return StartedCDI thus allowing a user to shutdown what they started. On 03/04/2015 12:24 PM, John D. Ament wrote: > This is actually based on what we discussed in one of the EG meetings > > http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-01-14-17.04.log.html > > John > > On Wed, Mar 4, 2015 at 4:05 AM Jozef Hartinger > wrote: > > Well it's nowhere given that we must have two separate interfaces > for this. We can combine the start/stop API with the existing one > to provide an application with a single reference representing the > CDI container. > > > On 02/28/2015 07:05 PM, John D. Ament wrote: >> Maybe I'm misreading, but I don't see us adding another API to do >> the same thing here - we're introducing new functionality. >> >> CDIContainer/Loader on startup/shutdown of the application >> >> CDI for runtime usage within the application to interact with the >> container. >> >> John >> >> On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau >> > wrote: >> >> sure I fully agree excepted I think introducing yet another >> API to do >> the same thing is not good so super tempting to skip it and >> wait for >> feedbacks rather than introducing it eagerly. >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-02-27 8:05 GMT+01:00 Jozef Hartinger >> >: >> > My point is that from the application perspective, the user >> obtains one >> > container handle for eventual shutdown (CDIContainer) and >> then looks up a >> > different container handle (CDI) that they can use for real >> work (lookup / >> > event dispatch / etc.) It would be cleaner if the container >> gave away a >> > single handle that can do all of that. >> > >> > >> > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: >> > >> > Not sure I get how a CDI instance can help. >> > >> > But container.getBeanManager() sounds nice is not a >> shortcut for >> > CDI.current().getBm() otherwise it looks like duplication >> to me. >> > >> > Can we make container not contextual - dont think so? If so >> it makes sense >> > otherwise I fear it doesnt add much. >> > >> > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" >> > a ?crit : >> >> >> >> I like the initialize + close() combination and the >> try-with-resources >> >> usage. >> >> What looks weird to me is that at line one you obtain a >> container handle: >> >> >> >> try (CDIContainer container = CDIContainer.newCDIContai... >> >> CDI.current().getBeanManager() ... >> >> >> >> and then at line two you call a static method to perform a >> container >> >> lookup :-/ >> >> >> >> An API that allows you to use the container handle you >> already got is way >> >> better IMO, e.g.: >> >> >> >> try (CDIContainer container = CDIContainer.newCDIContai... >> >> container.getBeanManager() >> >> >> >> If CDIContainer.newCDIContainer() returns an CDI instance >> or its subclass, >> >> we get this easily. >> >> >> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: >> >>> >> >>> Hi guys >> >>> >> >>> why note keeping it simple? >> >>> >> >>> try (CDIContainer container = >> CDIContainer.newCDIContainer(/* optional >> >>> map to configure vendor features */)) { >> >>> CDI.current().getBeanManager().... >> >>> } >> >>> >> >>> Not sure the point having initialize() + having shutdown >> = close >> >>> really makes the API more fluent and modern IMO. >> >>> >> >>> Also to be fully SE I guess provider() method would be >> needed even if >> >>> optional (SPI usage by default): >> >>> >> >>> try (CDIContainer container = >> >>> >> >>> >> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider").newCDIContainer()) >> >>> { >> >>> CDI.current().getBeanManager().... >> >>> } >> >>> >> >>> Finally I think having a kind of getInstance shortcut >> could be a plus for >> >>> SE: >> >>> >> >>> try (CDIContainer container = >> CDIContainer.newCDIContainer()) { >> >>> container.newInstance(MyAppRunner.class /* optional >> qualifiers */ >> >>> ).run(args); >> >>> } >> >>> >> >>> Using container to get an instance would create the >> instance and bind >> >>> it to the container lifecycle (mainly for predestroy) >> avoiding this >> >>> boilerplate code in all main which will surely only be >> used to launch >> >>> a soft. >> >>> >> >>> wdyt? >> >>> >> >>> >> >>> >> >>> Romain Manni-Bucau >> >>> @rmannibucau >> >>> http://www.tomitribe.com >> >>> http://rmannibucau.wordpress.com >> >>> https://github.com/rmannibucau >> >>> >> >>> >> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger >> >: >> >>>> >> >>>> Comments inline >> >>>> >> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: >> >>>> >> >>>> Sorry Jozef, your email fell into the pits of google >> inbox's "smart >> >>>> sorting" >> >>>> features. >> >>>> >> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger >> > >> >>>> wrote: >> >>>>> >> >>>>> Hi John, comments inline: >> >>>>> >> >>>>> >> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >> >>>>> >> >>>>> Jozef, >> >>>>> >> >>>>> Most of what you see there is taken from the original >> doc, since >> >>>>> everyone >> >>>>> seemed to be in agreement. I think the map is just a >> safeguard in case >> >>>>> of >> >>>>> additional boot options available in some >> implementations (e.g. I think >> >>>>> OWB/OpenEJB have some options.. currently OpenEJB >> supports an embedded >> >>>>> CDI >> >>>>> boot mode). >> >>>>> >> >>>>> No, I am fine with the map. What I am questioning is >> the type of the >> >>>>> map. >> >>>>> Usually, data structures with a similar purpose use >> Strings as their >> >>>>> keys. >> >>>>> This applies to ServletContext attributes, >> InvocationContext data, >> >>>>> Servlet >> >>>>> request/session attributes and others. I am therefore >> wondering whether >> >>>>> there is a usecase for the proposed unbound key >> signature or not. >> >>>> >> >>>> >> >>>> I think that's more of a placeholder, I was assuming it >> would be >> >>>> Map once we clarify everything. >> >>>> >> >>>>> >> >>>>> >> >>>>> We spoke a few times about BeanManager vs CDI. >> BeanManager was >> >>>>> preferable >> >>>>> since there's no easy way to get the the instance, CDI >> is easier to get >> >>>>> and >> >>>>> more aligned with how you would get it. Usually people >> expect the >> >>>>> BeanManager to be injected or available via JNDI, >> neither would be the >> >>>>> case >> >>>>> here. >> >>>>> >> >>>>> If CDI 2.0 targets Java SE then this container >> initialization API will >> >>>>> become something that ordinary application developers >> use to start/stop >> >>>>> CDI >> >>>>> in their applications. It therefore cannot be >> considered an SPI but >> >>>>> instead >> >>>>> should be something easy to use. On the other hand, >> BeanManager is >> >>>>> definitely an SPI. It is used in extension, frameworks >> and generally >> >>>>> for >> >>>>> integration. Not much by applications directly. >> Therefore, I don't see >> >>>>> how >> >>>>> the container bootstrap API and BeanManager fit >> together. IMO the >> >>>>> bootstrap >> >>>>> API should expose something that makes common tasks >> (obtaining a >> >>>>> contextual >> >>>>> reference and firing and event) easy, which the CDI >> class does. >> >>>>> >> >>>>> Plus do not forget that BeanManager can be obtained >> easily using >> >>>>> CDI.getBeanManager(). >> >>>> >> >>>> >> >>>> I'm not disagreeing. There's a few things I'd consider: >> >>>> >> >>>> - Is this mostly for new apps or existing? If existing, >> it's probably >> >>>> using >> >>>> some internal API, if new it can use whatever API we give. >> >>>> - I don't want to return void, we should give some kind >> of reference >> >>>> into >> >>>> the container when we're done booting. >> >>>> >> >>>> Agreed, we should not be returning void. >> >>>> >> >>>> - CDI is a one step retrievable reference, where as >> BeanManager is a two >> >>>> step reference. With that said, BeanManager makes more >> sense to return >> >>>> here. Another thought could be we invent some new class >> that has both, >> >>>> but >> >>>> that's really redundant. >> >>>> >> >>>> Why do you think BeanManager makes more sense here? >> Especially given the >> >>>> assumption that application code is going to call this >> init/shutdown >> >>>> API, I >> >>>> don't see BeanManager as making more sense. >> >>>> >> >>>> >> >>>>> >> >>>>> >> >>>>> Yes, this is the container start API. Sounds like you >> have some good >> >>>>> ideas for things like XML configuration or programmatic >> configuration, >> >>>>> both >> >>>>> of which are being tracked under separate tickets. One >> idea might be >> >>>>> for an >> >>>>> optional param in the map to control packages to >> scan/ignore, in that >> >>>>> map. >> >>>>> >> >>>>> I am wondering whether this configuration should be >> something optional >> >>>>> built on top of the bootstrap API or whether we should >> consider making >> >>>>> it >> >>>>> mandatory. Either way, we cannot add the bootstrap API >> to the spec >> >>>>> without >> >>>>> explicitly defining how it behaves. My implicit >> assumption of the >> >>>>> proposal >> >>>>> is that the container is supposed to scan the entire >> classpath for >> >>>>> explicit >> >>>>> or implicit bean archives (including e.g. rt.jar), >> discover beans, fire >> >>>>> extensions, etc. This worries me as this default >> behavior is far from >> >>>>> being >> >>>>> lightweight, which CDI for Java SE initially aimed to be. >> >>>> >> >>>> >> >>>> Yes, the spec must be updated to reflect the behavior of >> SE mode. I >> >>>> plan to >> >>>> get that completely into the google doc before opening >> any spec changes >> >>>> in a >> >>>> PR. >> >>>> >> >>>>> >> >>>>> >> >>>>> We didn't want to over load the CDI interface. It >> already does a lot. >> >>>>> This is really SPI code, CDI even though it's in the >> spi package is >> >>>>> used in >> >>>>> a lot of application code. >> >>>>> >> >>>>> I would personally prefer to have it all in one place. >> Having >> >>>>> CDIContainer, CDIContainerLoader, CDI and CDIProvider >> makes it more >> >>>>> difficult to know when to use what. >> >>>> >> >>>> >> >>>> The problem is that most CDI (the interface) operations >> are against a >> >>>> running container. I think we spoke about leveraging >> CDIProvider at one >> >>>> point (in fact, I mistakenly called CDIContainer >> CDIProvider not even >> >>>> realizing it was there). I doubt that most app >> developers use it >> >>>> currently, >> >>>> there's not even a way to get a reference to it that I'm >> aware of. It's >> >>>> used by the implementor only. >> >>>> >> >>>> I don't think there's a conflict. CDI class would still >> only provide >> >>>> methods >> >>>> to be run against a running container. The difference is >> that there >> >>>> would be >> >>>> additional static methods to get this running container >> (CDI class) to >> >>>> you >> >>>> by starting the container. >> >>>> >> >>>> Either way, I agree that reusing CDIProvider is a must. >> There is no >> >>>> reason >> >>>> to define a new class for the same purpose. >> >>>> >> >>>> >> >>>> I expect that my changes in the CDI spec around this >> will state, along >> >>>> the >> >>>> lines of: >> >>>> >> >>>> To retrieve a CDIContainer to launch, do this: >> >>>> >> >>>> CDIContainer container = >> CDIContainerLocator.getCDIContainer(); >> >>>> container.initialize(); >> >>>> ... do work >> >>>> >> >>>> Once you want to shutdown the container, do this: >> >>>> >> >>>> container.shutdown(); >> >>>> >> >>>> (we may want to consider implementing AutoCloseable, an >> oversight on my >> >>>> part) >> >>>> >> >>>> and then later on >> >>>> >> >>>> - What happens if I call CDIContainerLocator in an app >> server >> >>>> >> >>>> - It throws an IllegalStateException. >> >>>> >> >>>> - The container provides no beans of type CDIContainer, >> it is managed >> >>>> outside of the CDI container. >> >>>> >> >>>> >> >>>>> >> >>>>> >> >>>>> John >> >>>>> >> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger >> > >> >>>>> wrote: >> >>>>>> >> >>>>>> Hi John, some thoughts: >> >>>>>> >> >>>>>> - instead of using BeanManager it makes more sense to >> me to return a >> >>>>>> CDI >> >>>>>> instance, which is a more user-friendly API (and it >> also exposes >> >>>>>> access to >> >>>>>> BeanManager) >> >>>>>> - is there a usecase for arbitrary keys of the >> "params" map or is >> >>>>>> Map sufficient? >> >>>>>> - if we could move the shutdown() method from >> CDIContainer to the >> >>>>>> actual >> >>>>>> container handle that we obtain from initialize(), >> that would look >> >>>>>> more >> >>>>>> object-oriented >> >>>>>> - what exactly is initialize() supposed to do? Is it >> supposed to start >> >>>>>> scanning the entire classpath for CDI beans? That >> could be a problem >> >>>>>> especially with spring-boot-like fat jars. I think we >> need an API to >> >>>>>> tell >> >>>>>> the container which classes / packages to consider. >> Something like >> >>>>>> Guice's >> >>>>>> binding API perhaps? >> >>>>>> >> >>>>>> - the proposal makes me wonder whether retrofitting >> this functionality >> >>>>>> to >> >>>>>> the CDI class wouldn't be a better option. It could >> look like: >> >>>>>> >> >>>>>> CDI container = CDI.initialize(); >> >>>>>> container.select(Foo.class).get(); >> >>>>>> container.shutdown(); >> >>>>>> >> >>>>>> compare it to: >> >>>>>> >> >>>>>> CDIContainer container = CDIContainerLoader. >> getCDIContainer(); >> >>>>>> BeanManager manager = container.initialize(); >> >>>>>> manager.getBeans(...); >> >>>>>> container.shutdown(manager); >> >>>>>> >> >>>>>> >> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >> >>>>>> >> >>>>>> All, >> >>>>>> >> >>>>>> I have the updated API here, and wanted to solicit any >> final feedback >> >>>>>> before updating the google doc and spec pages. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c >> >>>>>> >> >>>>>> Let me know your thoughts. >> >>>>>> >> >>>>>> Thanks, >> >>>>>> >> >>>>>> John >> >>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> cdi-dev mailing list >> >>>>>> cdi-dev at lists.jboss.org >> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >>>>>> >> >>>>>> Note that for all code provided on this list, the >> provider licenses >> >>>>>> the >> >>>>>> code under the Apache License, Version 2 >> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For >> all other ideas >> >>>>>> provided on this list, the provider waives all patent >> and other >> >>>>>> intellectual >> >>>>>> property rights inherent in such information. >> >>>>>> >> >>>>>> >> >>>> >> >>>> _______________________________________________ >> >>>> cdi-dev mailing list >> >>>> cdi-dev at lists.jboss.org >> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >>>> >> >>>> Note that for all code provided on this list, the >> provider licenses the >> >>>> code >> >>>> under the Apache License, Version 2 >> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For >> all other ideas >> >>>> provided on this list, the provider waives all patent >> and other >> >>>> intellectual >> >>>> property rights inherent in such information. >> >> >> >> >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/97afe5fb/attachment-0001.html From jharting at redhat.com Wed Mar 4 07:45:25 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 04 Mar 2015 13:45:25 +0100 Subject: [cdi-dev] Bean Discovery Mode in SE In-Reply-To: References: <54F6CD01.5080806@redhat.com> Message-ID: <54F6FE65.6020602@redhat.com> Weld SE only supports bean archives with beans.xml (all bean-discovery-modes are supported in such an archive). Therefore, it will only scan locations marked explicitly with beans.xml files, not the entire classpath. On 03/04/2015 12:42 PM, John D. Ament wrote: > Jozef, > > How does Weld SE deal with it right now? I run two components, one > using WildFly 8.2 and the other just SE mode w/ Weld SE. I don't > notice much of a difference in scanning, even though the SE one needs > to scan 50 mb of classpath. > > John > > On Wed, Mar 4, 2015 at 4:14 AM Jozef Hartinger > wrote: > > For EE assuming bean-discovery-mode="annotated" by default if no > beans.xml is found is OK as the scope of scanning is limited by > the deployment. In SE however this would require that we scan the > entire classpath for scope annotations, stereotypes, etc. I am > therefore concerned about the performance implications of this. > > > On 03/01/2015 04:18 PM, John D. Ament wrote: >> Yeah actually you're right. For some reason I had in my head >> that "all" was the default. It's very clearly not. Too early for >> some of this :-) >> >> So let me rephrase. "annotated" will be the default bean >> discovery mode if a classpath entry contains no >> META-INF/beans.xml, based on the exact same rules used in EE. >> >> Any concerns with that? >> >> John >> >> On Sun, Mar 1, 2015 at 10:10 AM Romain Manni-Bucau >> > wrote: >> >> For me it is 100% the same as ee where you have the same >> issues so keeping them aligned is better IMO. That said >> configuring globally the scanning would be nice. >> >> Le 1 mars 2015 15:54, "John D. Ament" > > a ?crit : >> >> All, >> >> I'd like to propose in my doc changes for CDI-26 that if >> a classpath entry does not contain a META-INF/beans.xml >> that it is treated as if it were >> bean-discovery-mode=none, e.g. no beans will be scanned >> in that entry. (BTW, I'm using classpath entry rather >> than archive in the document to account for cases where >> someone does -cp "./classes:./extra-classes:./lib/*" to >> define their classpath) >> >> It's a bit different than how EE works, but I could >> imagine it causing fewer headaches when running on SE >> classpaths. >> >> Any thoughts/comments? >> >> John >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the >> provider licenses the code under the Apache License, >> Version 2 >> (http://www.apache.org/licenses/LICENSE-2.0.html). For >> all other ideas provided on this list, the provider >> waives all patent and other intellectual property rights >> inherent in such information. >> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/b30226e4/attachment.html From rmannibucau at gmail.com Wed Mar 4 07:47:54 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 4 Mar 2015 13:47:54 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: <54F6FDF2.3000808@redhat.com> References: <54DB1F2B.1020609@redhat.com> <54DC61D9.701@redhat.com> <54EECC20.6040600@redhat.com> <54EF396E.20805@redhat.com> <54F01720.3080802@redhat.com> <54F6CACD.6080507@redhat.com> <54F6FDF2.3000808@redhat.com> Message-ID: Hmm I think one of the main point I try to push is we have a bunch of API to do it already, if we need yet another API to do the same we have several choices: - we love creating APIs - all previous APIs are failures and should be deprecated or fixed - there is a full mismatch with embedded and EE case (but we have existing proofs it is not the case) I think we should help user to not be lost between all APIs and I strongly believe we can't do anything on container to lookup beans (EJBContainer#getContext was a try which is close to it but it actually just limited user experience compared to existing solutions). What's the issue with UnmanagedInstance? Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-03-04 13:43 GMT+01:00 Jozef Hartinger : > The only argument I found supporting a strict separation of those two > APIs is that it makes it easier to control when a user should or should not > use boot (i.e. it should not be used in EE for example). > > That's a good argument. It's not however necessarily only achieved by two > separate interfaces but can be as well be achieved with a subclass, e.g: > - CDI for runtime operations only > - StartedCDI extends CDI (or CDIContainer or whatever - the name does not > matter at this point) for runtime operations + shutdown. > > Normally, CDI is available only. The boot API however would return > StartedCDI thus allowing a user to shutdown what they started. > > > > On 03/04/2015 12:24 PM, John D. Ament wrote: > > This is actually based on what we discussed in one of the EG meetings > > > http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-01-14-17.04.log.html > > John > > On Wed, Mar 4, 2015 at 4:05 AM Jozef Hartinger > wrote: > >> Well it's nowhere given that we must have two separate interfaces for >> this. We can combine the start/stop API with the existing one to provide an >> application with a single reference representing the CDI container. >> >> >> On 02/28/2015 07:05 PM, John D. Ament wrote: >> >> Maybe I'm misreading, but I don't see us adding another API to do the >> same thing here - we're introducing new functionality. >> >> CDIContainer/Loader on startup/shutdown of the application >> >> CDI for runtime usage within the application to interact with the >> container. >> >> John >> >> On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau >> wrote: >> >>> sure I fully agree excepted I think introducing yet another API to do >>> the same thing is not good so super tempting to skip it and wait for >>> feedbacks rather than introducing it eagerly. >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau >>> http://www.tomitribe.com >>> http://rmannibucau.wordpress.com >>> https://github.com/rmannibucau >>> >>> >>> 2015-02-27 8:05 GMT+01:00 Jozef Hartinger : >>> > My point is that from the application perspective, the user obtains one >>> > container handle for eventual shutdown (CDIContainer) and then looks >>> up a >>> > different container handle (CDI) that they can use for real work >>> (lookup / >>> > event dispatch / etc.) It would be cleaner if the container gave away a >>> > single handle that can do all of that. >>> > >>> > >>> > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: >>> > >>> > Not sure I get how a CDI instance can help. >>> > >>> > But container.getBeanManager() sounds nice is not a shortcut for >>> > CDI.current().getBm() otherwise it looks like duplication to me. >>> > >>> > Can we make container not contextual - dont think so? If so it makes >>> sense >>> > otherwise I fear it doesnt add much. >>> > >>> > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" a >>> ?crit : >>> >> >>> >> I like the initialize + close() combination and the try-with-resources >>> >> usage. >>> >> What looks weird to me is that at line one you obtain a container >>> handle: >>> >> >>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>> >> CDI.current().getBeanManager() ... >>> >> >>> >> and then at line two you call a static method to perform a container >>> >> lookup :-/ >>> >> >>> >> An API that allows you to use the container handle you already got is >>> way >>> >> better IMO, e.g.: >>> >> >>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>> >> container.getBeanManager() >>> >> >>> >> If CDIContainer.newCDIContainer() returns an CDI instance or its >>> subclass, >>> >> we get this easily. >>> >> >>> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: >>> >>> >>> >>> Hi guys >>> >>> >>> >>> why note keeping it simple? >>> >>> >>> >>> try (CDIContainer container = CDIContainer.newCDIContainer(/* >>> optional >>> >>> map to configure vendor features */)) { >>> >>> CDI.current().getBeanManager().... >>> >>> } >>> >>> >>> >>> Not sure the point having initialize() + having shutdown = close >>> >>> really makes the API more fluent and modern IMO. >>> >>> >>> >>> Also to be fully SE I guess provider() method would be needed even if >>> >>> optional (SPI usage by default): >>> >>> >>> >>> try (CDIContainer container = >>> >>> >>> >>> >>> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider").newCDIContainer()) >>> >>> { >>> >>> CDI.current().getBeanManager().... >>> >>> } >>> >>> >>> >>> Finally I think having a kind of getInstance shortcut could be a >>> plus for >>> >>> SE: >>> >>> >>> >>> try (CDIContainer container = CDIContainer.newCDIContainer()) { >>> >>> container.newInstance(MyAppRunner.class /* optional qualifiers >>> */ >>> >>> ).run(args); >>> >>> } >>> >>> >>> >>> Using container to get an instance would create the instance and bind >>> >>> it to the container lifecycle (mainly for predestroy) avoiding this >>> >>> boilerplate code in all main which will surely only be used to launch >>> >>> a soft. >>> >>> >>> >>> wdyt? >>> >>> >>> >>> >>> >>> >>> >>> Romain Manni-Bucau >>> >>> @rmannibucau >>> >>> http://www.tomitribe.com >>> >>> http://rmannibucau.wordpress.com >>> >>> https://github.com/rmannibucau >>> >>> >>> >>> >>> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger : >>> >>>> >>> >>>> Comments inline >>> >>>> >>> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: >>> >>>> >>> >>>> Sorry Jozef, your email fell into the pits of google inbox's "smart >>> >>>> sorting" >>> >>>> features. >>> >>>> >>> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger < >>> jharting at redhat.com> >>> >>>> wrote: >>> >>>>> >>> >>>>> Hi John, comments inline: >>> >>>>> >>> >>>>> >>> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >>> >>>>> >>> >>>>> Jozef, >>> >>>>> >>> >>>>> Most of what you see there is taken from the original doc, since >>> >>>>> everyone >>> >>>>> seemed to be in agreement. I think the map is just a safeguard in >>> case >>> >>>>> of >>> >>>>> additional boot options available in some implementations (e.g. I >>> think >>> >>>>> OWB/OpenEJB have some options.. currently OpenEJB supports an >>> embedded >>> >>>>> CDI >>> >>>>> boot mode). >>> >>>>> >>> >>>>> No, I am fine with the map. What I am questioning is the type of >>> the >>> >>>>> map. >>> >>>>> Usually, data structures with a similar purpose use Strings as >>> their >>> >>>>> keys. >>> >>>>> This applies to ServletContext attributes, InvocationContext data, >>> >>>>> Servlet >>> >>>>> request/session attributes and others. I am therefore wondering >>> whether >>> >>>>> there is a usecase for the proposed unbound key signature or not. >>> >>>> >>> >>>> >>> >>>> I think that's more of a placeholder, I was assuming it would be >>> >>>> Map once we clarify everything. >>> >>>> >>> >>>>> >>> >>>>> >>> >>>>> We spoke a few times about BeanManager vs CDI. BeanManager was >>> >>>>> preferable >>> >>>>> since there's no easy way to get the the instance, CDI is easier >>> to get >>> >>>>> and >>> >>>>> more aligned with how you would get it. Usually people expect the >>> >>>>> BeanManager to be injected or available via JNDI, neither would be >>> the >>> >>>>> case >>> >>>>> here. >>> >>>>> >>> >>>>> If CDI 2.0 targets Java SE then this container initialization API >>> will >>> >>>>> become something that ordinary application developers use to >>> start/stop >>> >>>>> CDI >>> >>>>> in their applications. It therefore cannot be considered an SPI but >>> >>>>> instead >>> >>>>> should be something easy to use. On the other hand, BeanManager is >>> >>>>> definitely an SPI. It is used in extension, frameworks and >>> generally >>> >>>>> for >>> >>>>> integration. Not much by applications directly. Therefore, I don't >>> see >>> >>>>> how >>> >>>>> the container bootstrap API and BeanManager fit together. IMO the >>> >>>>> bootstrap >>> >>>>> API should expose something that makes common tasks (obtaining a >>> >>>>> contextual >>> >>>>> reference and firing and event) easy, which the CDI class does. >>> >>>>> >>> >>>>> Plus do not forget that BeanManager can be obtained easily using >>> >>>>> CDI.getBeanManager(). >>> >>>> >>> >>>> >>> >>>> I'm not disagreeing. There's a few things I'd consider: >>> >>>> >>> >>>> - Is this mostly for new apps or existing? If existing, it's >>> probably >>> >>>> using >>> >>>> some internal API, if new it can use whatever API we give. >>> >>>> - I don't want to return void, we should give some kind of reference >>> >>>> into >>> >>>> the container when we're done booting. >>> >>>> >>> >>>> Agreed, we should not be returning void. >>> >>>> >>> >>>> - CDI is a one step retrievable reference, where as BeanManager is >>> a two >>> >>>> step reference. With that said, BeanManager makes more sense to >>> return >>> >>>> here. Another thought could be we invent some new class that has >>> both, >>> >>>> but >>> >>>> that's really redundant. >>> >>>> >>> >>>> Why do you think BeanManager makes more sense here? Especially >>> given the >>> >>>> assumption that application code is going to call this init/shutdown >>> >>>> API, I >>> >>>> don't see BeanManager as making more sense. >>> >>>> >>> >>>> >>> >>>>> >>> >>>>> >>> >>>>> Yes, this is the container start API. Sounds like you have some >>> good >>> >>>>> ideas for things like XML configuration or programmatic >>> configuration, >>> >>>>> both >>> >>>>> of which are being tracked under separate tickets. One idea might >>> be >>> >>>>> for an >>> >>>>> optional param in the map to control packages to scan/ignore, in >>> that >>> >>>>> map. >>> >>>>> >>> >>>>> I am wondering whether this configuration should be something >>> optional >>> >>>>> built on top of the bootstrap API or whether we should consider >>> making >>> >>>>> it >>> >>>>> mandatory. Either way, we cannot add the bootstrap API to the spec >>> >>>>> without >>> >>>>> explicitly defining how it behaves. My implicit assumption of the >>> >>>>> proposal >>> >>>>> is that the container is supposed to scan the entire classpath for >>> >>>>> explicit >>> >>>>> or implicit bean archives (including e.g. rt.jar), discover beans, >>> fire >>> >>>>> extensions, etc. This worries me as this default behavior is far >>> from >>> >>>>> being >>> >>>>> lightweight, which CDI for Java SE initially aimed to be. >>> >>>> >>> >>>> >>> >>>> Yes, the spec must be updated to reflect the behavior of SE mode. I >>> >>>> plan to >>> >>>> get that completely into the google doc before opening any spec >>> changes >>> >>>> in a >>> >>>> PR. >>> >>>> >>> >>>>> >>> >>>>> >>> >>>>> We didn't want to over load the CDI interface. It already does a >>> lot. >>> >>>>> This is really SPI code, CDI even though it's in the spi package is >>> >>>>> used in >>> >>>>> a lot of application code. >>> >>>>> >>> >>>>> I would personally prefer to have it all in one place. Having >>> >>>>> CDIContainer, CDIContainerLoader, CDI and CDIProvider makes it more >>> >>>>> difficult to know when to use what. >>> >>>> >>> >>>> >>> >>>> The problem is that most CDI (the interface) operations are against >>> a >>> >>>> running container. I think we spoke about leveraging CDIProvider >>> at one >>> >>>> point (in fact, I mistakenly called CDIContainer CDIProvider not >>> even >>> >>>> realizing it was there). I doubt that most app developers use it >>> >>>> currently, >>> >>>> there's not even a way to get a reference to it that I'm aware of. >>> It's >>> >>>> used by the implementor only. >>> >>>> >>> >>>> I don't think there's a conflict. CDI class would still only provide >>> >>>> methods >>> >>>> to be run against a running container. The difference is that there >>> >>>> would be >>> >>>> additional static methods to get this running container (CDI class) >>> to >>> >>>> you >>> >>>> by starting the container. >>> >>>> >>> >>>> Either way, I agree that reusing CDIProvider is a must. There is no >>> >>>> reason >>> >>>> to define a new class for the same purpose. >>> >>>> >>> >>>> >>> >>>> I expect that my changes in the CDI spec around this will state, >>> along >>> >>>> the >>> >>>> lines of: >>> >>>> >>> >>>> To retrieve a CDIContainer to launch, do this: >>> >>>> >>> >>>> CDIContainer container = CDIContainerLocator.getCDIContainer(); >>> >>>> container.initialize(); >>> >>>> ... do work >>> >>>> >>> >>>> Once you want to shutdown the container, do this: >>> >>>> >>> >>>> container.shutdown(); >>> >>>> >>> >>>> (we may want to consider implementing AutoCloseable, an oversight >>> on my >>> >>>> part) >>> >>>> >>> >>>> and then later on >>> >>>> >>> >>>> - What happens if I call CDIContainerLocator in an app server >>> >>>> >>> >>>> - It throws an IllegalStateException. >>> >>>> >>> >>>> - The container provides no beans of type CDIContainer, it is >>> managed >>> >>>> outside of the CDI container. >>> >>>> >>> >>>> >>> >>>>> >>> >>>>> >>> >>>>> John >>> >>>>> >>> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger < >>> jharting at redhat.com> >>> >>>>> wrote: >>> >>>>>> >>> >>>>>> Hi John, some thoughts: >>> >>>>>> >>> >>>>>> - instead of using BeanManager it makes more sense to me to >>> return a >>> >>>>>> CDI >>> >>>>>> instance, which is a more user-friendly API (and it also exposes >>> >>>>>> access to >>> >>>>>> BeanManager) >>> >>>>>> - is there a usecase for arbitrary keys of the "params" map or is >>> >>>>>> Map sufficient? >>> >>>>>> - if we could move the shutdown() method from CDIContainer to the >>> >>>>>> actual >>> >>>>>> container handle that we obtain from initialize(), that would look >>> >>>>>> more >>> >>>>>> object-oriented >>> >>>>>> - what exactly is initialize() supposed to do? Is it supposed to >>> start >>> >>>>>> scanning the entire classpath for CDI beans? That could be a >>> problem >>> >>>>>> especially with spring-boot-like fat jars. I think we need an API >>> to >>> >>>>>> tell >>> >>>>>> the container which classes / packages to consider. Something like >>> >>>>>> Guice's >>> >>>>>> binding API perhaps? >>> >>>>>> >>> >>>>>> - the proposal makes me wonder whether retrofitting this >>> functionality >>> >>>>>> to >>> >>>>>> the CDI class wouldn't be a better option. It could look like: >>> >>>>>> >>> >>>>>> CDI container = CDI.initialize(); >>> >>>>>> container.select(Foo.class).get(); >>> >>>>>> container.shutdown(); >>> >>>>>> >>> >>>>>> compare it to: >>> >>>>>> >>> >>>>>> CDIContainer container = CDIContainerLoader. getCDIContainer(); >>> >>>>>> BeanManager manager = container.initialize(); >>> >>>>>> manager.getBeans(...); >>> >>>>>> container.shutdown(manager); >>> >>>>>> >>> >>>>>> >>> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >>> >>>>>> >>> >>>>>> All, >>> >>>>>> >>> >>>>>> I have the updated API here, and wanted to solicit any final >>> feedback >>> >>>>>> before updating the google doc and spec pages. >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c >>> >>>>>> >>> >>>>>> Let me know your thoughts. >>> >>>>>> >>> >>>>>> Thanks, >>> >>>>>> >>> >>>>>> John >>> >>>>>> >>> >>>>>> >>> >>>>>> _______________________________________________ >>> >>>>>> cdi-dev mailing list >>> >>>>>> cdi-dev at lists.jboss.org >>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>>>>> >>> >>>>>> Note that for all code provided on this list, the provider >>> licenses >>> >>>>>> the >>> >>>>>> code under the Apache License, Version 2 >>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>> ideas >>> >>>>>> provided on this list, the provider waives all patent and other >>> >>>>>> intellectual >>> >>>>>> property rights inherent in such information. >>> >>>>>> >>> >>>>>> >>> >>>> >>> >>>> _______________________________________________ >>> >>>> cdi-dev mailing list >>> >>>> cdi-dev at lists.jboss.org >>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>>> >>> >>>> Note that for all code provided on this list, the provider licenses >>> the >>> >>>> code >>> >>>> under the Apache License, Version 2 >>> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>> ideas >>> >>>> provided on this list, the provider waives all patent and other >>> >>>> intellectual >>> >>>> property rights inherent in such information. >>> >> >>> >> >>> > >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/0c40b17c/attachment-0001.html From issues at jboss.org Wed Mar 4 07:52:49 2015 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Wed, 4 Mar 2015 07:52:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-514) FireEventTest#testDuplicateBindingsToFireEventFails() is wrong In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046171#comment-13046171 ] Jozef Hartinger commented on CDI-514: ------------------------------------- If an invariant of a method is well-defined then the method should validate it. As for why it is defined this way then I think it enforces consistency between what you can achieve using annotation on classes and what you can achieve programatically. Let's revisit this constraint for CDI 2.0 > FireEventTest#testDuplicateBindingsToFireEventFails() is wrong > -------------------------------------------------------------- > > Key: CDI-514 > URL: https://issues.jboss.org/browse/CDI-514 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Mark Struberg > > testDuplicateBindingsToFireEventFails() tests for 2 Lifted literals with different values. But this is perfectly fine as value is NOT annotated as @Nonbinding. Thus the 2 literals are NOT equals according to CDI rules. They are essentially 2 different annotations... > Plz remove this test. It also makes no sense to add all those very performance costly tests at runtime. The worst case which can happen is that the 2 annotations make no sense. But they don't break anything. Wheras checking all the nasty conditions each and every time is really mad from a performance aspect. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From jharting at redhat.com Wed Mar 4 07:59:39 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 04 Mar 2015 13:59:39 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: References: <54DB1F2B.1020609@redhat.com> <54DC61D9.701@redhat.com> <54EECC20.6040600@redhat.com> <54EF396E.20805@redhat.com> <54F01720.3080802@redhat.com> <54F6CACD.6080507@redhat.com> <54F6FDF2.3000808@redhat.com> Message-ID: <54F701BB.9050209@redhat.com> UnmanagedInstance is provided to make it easier for libraries to perform dependency injection on classes that are for some reason not CDI beans. It should not be a substitute for lookup of CDI beans. Therefore, I do not see UnmanagedInstance fitting here. On 03/04/2015 01:47 PM, Romain Manni-Bucau wrote: > Hmm > > I think one of the main point I try to push is we have a bunch of API > to do it already, if we need yet another API to do the same we have > several choices: > - we love creating APIs > - all previous APIs are failures and should be deprecated or fixed > - there is a full mismatch with embedded and EE case (but we have > existing proofs it is not the case) > > I think we should help user to not be lost between all APIs and I > strongly believe we can't do anything on container to lookup beans > (EJBContainer#getContext was a try which is close to it but it > actually just limited user experience compared to existing solutions). > > What's the issue with UnmanagedInstance? > > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2015-03-04 13:43 GMT+01:00 Jozef Hartinger >: > > The only argument I found supporting a strict separation of those > two APIs is that it makes it easier to control when a user should > or should not use boot (i.e. it should not be used in EE for example). > > That's a good argument. It's not however necessarily only achieved > by two separate interfaces but can be as well be achieved with a > subclass, e.g: > - CDI for runtime operations only > - StartedCDI extends CDI (or CDIContainer or whatever - the name > does not matter at this point) for runtime operations + shutdown. > > Normally, CDI is available only. The boot API however would return > StartedCDI thus allowing a user to shutdown what they started. > > > > On 03/04/2015 12:24 PM, John D. Ament wrote: >> This is actually based on what we discussed in one of the EG >> meetings >> >> http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-01-14-17.04.log.html >> >> John >> >> On Wed, Mar 4, 2015 at 4:05 AM Jozef Hartinger >> > wrote: >> >> Well it's nowhere given that we must have two separate >> interfaces for this. We can combine the start/stop API with >> the existing one to provide an application with a single >> reference representing the CDI container. >> >> >> On 02/28/2015 07:05 PM, John D. Ament wrote: >>> Maybe I'm misreading, but I don't see us adding another API >>> to do the same thing here - we're introducing new >>> functionality. >>> >>> CDIContainer/Loader on startup/shutdown of the application >>> >>> CDI for runtime usage within the application to interact >>> with the container. >>> >>> John >>> >>> On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau >>> > wrote: >>> >>> sure I fully agree excepted I think introducing yet >>> another API to do >>> the same thing is not good so super tempting to skip it >>> and wait for >>> feedbacks rather than introducing it eagerly. >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau >>> http://www.tomitribe.com >>> http://rmannibucau.wordpress.com >>> https://github.com/rmannibucau >>> >>> >>> 2015-02-27 8:05 GMT+01:00 Jozef Hartinger >>> >: >>> > My point is that from the application perspective, the >>> user obtains one >>> > container handle for eventual shutdown (CDIContainer) >>> and then looks up a >>> > different container handle (CDI) that they can use for >>> real work (lookup / >>> > event dispatch / etc.) It would be cleaner if the >>> container gave away a >>> > single handle that can do all of that. >>> > >>> > >>> > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: >>> > >>> > Not sure I get how a CDI instance can help. >>> > >>> > But container.getBeanManager() sounds nice is not a >>> shortcut for >>> > CDI.current().getBm() otherwise it looks like >>> duplication to me. >>> > >>> > Can we make container not contextual - dont think so? >>> If so it makes sense >>> > otherwise I fear it doesnt add much. >>> > >>> > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" >>> > a ?crit : >>> >> >>> >> I like the initialize + close() combination and the >>> try-with-resources >>> >> usage. >>> >> What looks weird to me is that at line one you obtain >>> a container handle: >>> >> >>> >> try (CDIContainer container = >>> CDIContainer.newCDIContai... >>> >> CDI.current().getBeanManager() ... >>> >> >>> >> and then at line two you call a static method to >>> perform a container >>> >> lookup :-/ >>> >> >>> >> An API that allows you to use the container handle >>> you already got is way >>> >> better IMO, e.g.: >>> >> >>> >> try (CDIContainer container = >>> CDIContainer.newCDIContai... >>> >> container.getBeanManager() >>> >> >>> >> If CDIContainer.newCDIContainer() returns an CDI >>> instance or its subclass, >>> >> we get this easily. >>> >> >>> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: >>> >>> >>> >>> Hi guys >>> >>> >>> >>> why note keeping it simple? >>> >>> >>> >>> try (CDIContainer container = >>> CDIContainer.newCDIContainer(/* optional >>> >>> map to configure vendor features */)) { >>> >>> CDI.current().getBeanManager().... >>> >>> } >>> >>> >>> >>> Not sure the point having initialize() + having >>> shutdown = close >>> >>> really makes the API more fluent and modern IMO. >>> >>> >>> >>> Also to be fully SE I guess provider() method would >>> be needed even if >>> >>> optional (SPI usage by default): >>> >>> >>> >>> try (CDIContainer container = >>> >>> >>> >>> >>> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider").newCDIContainer()) >>> >>> { >>> >>> CDI.current().getBeanManager().... >>> >>> } >>> >>> >>> >>> Finally I think having a kind of getInstance >>> shortcut could be a plus for >>> >>> SE: >>> >>> >>> >>> try (CDIContainer container = >>> CDIContainer.newCDIContainer()) { >>> >>> container.newInstance(MyAppRunner.class /* optional >>> qualifiers */ >>> >>> ).run(args); >>> >>> } >>> >>> >>> >>> Using container to get an instance would create the >>> instance and bind >>> >>> it to the container lifecycle (mainly for >>> predestroy) avoiding this >>> >>> boilerplate code in all main which will surely only >>> be used to launch >>> >>> a soft. >>> >>> >>> >>> wdyt? >>> >>> >>> >>> >>> >>> >>> >>> Romain Manni-Bucau >>> >>> @rmannibucau >>> >>> http://www.tomitribe.com >>> >>> http://rmannibucau.wordpress.com >>> >>> https://github.com/rmannibucau >>> >>> >>> >>> >>> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger >>> >: >>> >>>> >>> >>>> Comments inline >>> >>>> >>> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: >>> >>>> >>> >>>> Sorry Jozef, your email fell into the pits of >>> google inbox's "smart >>> >>>> sorting" >>> >>>> features. >>> >>>> >>> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger >>> > >>> >>>> wrote: >>> >>>>> >>> >>>>> Hi John, comments inline: >>> >>>>> >>> >>>>> >>> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >>> >>>>> >>> >>>>> Jozef, >>> >>>>> >>> >>>>> Most of what you see there is taken from the >>> original doc, since >>> >>>>> everyone >>> >>>>> seemed to be in agreement. I think the map is >>> just a safeguard in case >>> >>>>> of >>> >>>>> additional boot options available in some >>> implementations (e.g. I think >>> >>>>> OWB/OpenEJB have some options.. currently OpenEJB >>> supports an embedded >>> >>>>> CDI >>> >>>>> boot mode). >>> >>>>> >>> >>>>> No, I am fine with the map. What I am questioning >>> is the type of the >>> >>>>> map. >>> >>>>> Usually, data structures with a similar purpose >>> use Strings as their >>> >>>>> keys. >>> >>>>> This applies to ServletContext attributes, >>> InvocationContext data, >>> >>>>> Servlet >>> >>>>> request/session attributes and others. I am >>> therefore wondering whether >>> >>>>> there is a usecase for the proposed unbound key >>> signature or not. >>> >>>> >>> >>>> >>> >>>> I think that's more of a placeholder, I was >>> assuming it would be >>> >>>> Map once we clarify everything. >>> >>>> >>> >>>>> >>> >>>>> >>> >>>>> We spoke a few times about BeanManager vs CDI. >>> BeanManager was >>> >>>>> preferable >>> >>>>> since there's no easy way to get the the instance, >>> CDI is easier to get >>> >>>>> and >>> >>>>> more aligned with how you would get it. Usually >>> people expect the >>> >>>>> BeanManager to be injected or available via JNDI, >>> neither would be the >>> >>>>> case >>> >>>>> here. >>> >>>>> >>> >>>>> If CDI 2.0 targets Java SE then this container >>> initialization API will >>> >>>>> become something that ordinary application >>> developers use to start/stop >>> >>>>> CDI >>> >>>>> in their applications. It therefore cannot be >>> considered an SPI but >>> >>>>> instead >>> >>>>> should be something easy to use. On the other >>> hand, BeanManager is >>> >>>>> definitely an SPI. It is used in extension, >>> frameworks and generally >>> >>>>> for >>> >>>>> integration. Not much by applications directly. >>> Therefore, I don't see >>> >>>>> how >>> >>>>> the container bootstrap API and BeanManager fit >>> together. IMO the >>> >>>>> bootstrap >>> >>>>> API should expose something that makes common >>> tasks (obtaining a >>> >>>>> contextual >>> >>>>> reference and firing and event) easy, which the >>> CDI class does. >>> >>>>> >>> >>>>> Plus do not forget that BeanManager can be >>> obtained easily using >>> >>>>> CDI.getBeanManager(). >>> >>>> >>> >>>> >>> >>>> I'm not disagreeing. There's a few things I'd >>> consider: >>> >>>> >>> >>>> - Is this mostly for new apps or existing? If >>> existing, it's probably >>> >>>> using >>> >>>> some internal API, if new it can use whatever API >>> we give. >>> >>>> - I don't want to return void, we should give some >>> kind of reference >>> >>>> into >>> >>>> the container when we're done booting. >>> >>>> >>> >>>> Agreed, we should not be returning void. >>> >>>> >>> >>>> - CDI is a one step retrievable reference, where as >>> BeanManager is a two >>> >>>> step reference. With that said, BeanManager makes >>> more sense to return >>> >>>> here. Another thought could be we invent some new >>> class that has both, >>> >>>> but >>> >>>> that's really redundant. >>> >>>> >>> >>>> Why do you think BeanManager makes more sense here? >>> Especially given the >>> >>>> assumption that application code is going to call >>> this init/shutdown >>> >>>> API, I >>> >>>> don't see BeanManager as making more sense. >>> >>>> >>> >>>> >>> >>>>> >>> >>>>> >>> >>>>> Yes, this is the container start API. Sounds like >>> you have some good >>> >>>>> ideas for things like XML configuration or >>> programmatic configuration, >>> >>>>> both >>> >>>>> of which are being tracked under separate >>> tickets. One idea might be >>> >>>>> for an >>> >>>>> optional param in the map to control packages to >>> scan/ignore, in that >>> >>>>> map. >>> >>>>> >>> >>>>> I am wondering whether this configuration should >>> be something optional >>> >>>>> built on top of the bootstrap API or whether we >>> should consider making >>> >>>>> it >>> >>>>> mandatory. Either way, we cannot add the bootstrap >>> API to the spec >>> >>>>> without >>> >>>>> explicitly defining how it behaves. My implicit >>> assumption of the >>> >>>>> proposal >>> >>>>> is that the container is supposed to scan the >>> entire classpath for >>> >>>>> explicit >>> >>>>> or implicit bean archives (including e.g. rt.jar), >>> discover beans, fire >>> >>>>> extensions, etc. This worries me as this default >>> behavior is far from >>> >>>>> being >>> >>>>> lightweight, which CDI for Java SE initially aimed >>> to be. >>> >>>> >>> >>>> >>> >>>> Yes, the spec must be updated to reflect the >>> behavior of SE mode. I >>> >>>> plan to >>> >>>> get that completely into the google doc before >>> opening any spec changes >>> >>>> in a >>> >>>> PR. >>> >>>> >>> >>>>> >>> >>>>> >>> >>>>> We didn't want to over load the CDI interface. It >>> already does a lot. >>> >>>>> This is really SPI code, CDI even though it's in >>> the spi package is >>> >>>>> used in >>> >>>>> a lot of application code. >>> >>>>> >>> >>>>> I would personally prefer to have it all in one >>> place. Having >>> >>>>> CDIContainer, CDIContainerLoader, CDI and >>> CDIProvider makes it more >>> >>>>> difficult to know when to use what. >>> >>>> >>> >>>> >>> >>>> The problem is that most CDI (the interface) >>> operations are against a >>> >>>> running container. I think we spoke about >>> leveraging CDIProvider at one >>> >>>> point (in fact, I mistakenly called CDIContainer >>> CDIProvider not even >>> >>>> realizing it was there). I doubt that most app >>> developers use it >>> >>>> currently, >>> >>>> there's not even a way to get a reference to it >>> that I'm aware of. It's >>> >>>> used by the implementor only. >>> >>>> >>> >>>> I don't think there's a conflict. CDI class would >>> still only provide >>> >>>> methods >>> >>>> to be run against a running container. The >>> difference is that there >>> >>>> would be >>> >>>> additional static methods to get this running >>> container (CDI class) to >>> >>>> you >>> >>>> by starting the container. >>> >>>> >>> >>>> Either way, I agree that reusing CDIProvider is a >>> must. There is no >>> >>>> reason >>> >>>> to define a new class for the same purpose. >>> >>>> >>> >>>> >>> >>>> I expect that my changes in the CDI spec around >>> this will state, along >>> >>>> the >>> >>>> lines of: >>> >>>> >>> >>>> To retrieve a CDIContainer to launch, do this: >>> >>>> >>> >>>> CDIContainer container = >>> CDIContainerLocator.getCDIContainer(); >>> >>>> container.initialize(); >>> >>>> ... do work >>> >>>> >>> >>>> Once you want to shutdown the container, do this: >>> >>>> >>> >>>> container.shutdown(); >>> >>>> >>> >>>> (we may want to consider implementing >>> AutoCloseable, an oversight on my >>> >>>> part) >>> >>>> >>> >>>> and then later on >>> >>>> >>> >>>> - What happens if I call CDIContainerLocator in an >>> app server >>> >>>> >>> >>>> - It throws an IllegalStateException. >>> >>>> >>> >>>> - The container provides no beans of type >>> CDIContainer, it is managed >>> >>>> outside of the CDI container. >>> >>>> >>> >>>> >>> >>>>> >>> >>>>> >>> >>>>> John >>> >>>>> >>> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger >>> > >>> >>>>> wrote: >>> >>>>>> >>> >>>>>> Hi John, some thoughts: >>> >>>>>> >>> >>>>>> - instead of using BeanManager it makes more >>> sense to me to return a >>> >>>>>> CDI >>> >>>>>> instance, which is a more user-friendly API (and >>> it also exposes >>> >>>>>> access to >>> >>>>>> BeanManager) >>> >>>>>> - is there a usecase for arbitrary keys of the >>> "params" map or is >>> >>>>>> Map sufficient? >>> >>>>>> - if we could move the shutdown() method from >>> CDIContainer to the >>> >>>>>> actual >>> >>>>>> container handle that we obtain from >>> initialize(), that would look >>> >>>>>> more >>> >>>>>> object-oriented >>> >>>>>> - what exactly is initialize() supposed to do? Is >>> it supposed to start >>> >>>>>> scanning the entire classpath for CDI beans? That >>> could be a problem >>> >>>>>> especially with spring-boot-like fat jars. I >>> think we need an API to >>> >>>>>> tell >>> >>>>>> the container which classes / packages to >>> consider. Something like >>> >>>>>> Guice's >>> >>>>>> binding API perhaps? >>> >>>>>> >>> >>>>>> - the proposal makes me wonder whether >>> retrofitting this functionality >>> >>>>>> to >>> >>>>>> the CDI class wouldn't be a better option. It >>> could look like: >>> >>>>>> >>> >>>>>> CDI container = CDI.initialize(); >>> >>>>>> container.select(Foo.class).get(); >>> >>>>>> container.shutdown(); >>> >>>>>> >>> >>>>>> compare it to: >>> >>>>>> >>> >>>>>> CDIContainer container = CDIContainerLoader. >>> getCDIContainer(); >>> >>>>>> BeanManager manager = container.initialize(); >>> >>>>>> manager.getBeans(...); >>> >>>>>> container.shutdown(manager); >>> >>>>>> >>> >>>>>> >>> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >>> >>>>>> >>> >>>>>> All, >>> >>>>>> >>> >>>>>> I have the updated API here, and wanted to >>> solicit any final feedback >>> >>>>>> before updating the google doc and spec pages. >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c >>> >>>>>> >>> >>>>>> Let me know your thoughts. >>> >>>>>> >>> >>>>>> Thanks, >>> >>>>>> >>> >>>>>> John >>> >>>>>> >>> >>>>>> >>> >>>>>> _______________________________________________ >>> >>>>>> cdi-dev mailing list >>> >>>>>> cdi-dev at lists.jboss.org >>> >>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>>>>> >>> >>>>>> Note that for all code provided on this list, the >>> provider licenses >>> >>>>>> the >>> >>>>>> code under the Apache License, Version 2 >>> >>>>>> >>> (http://www.apache.org/licenses/LICENSE-2.0.html). For >>> all other ideas >>> >>>>>> provided on this list, the provider waives all >>> patent and other >>> >>>>>> intellectual >>> >>>>>> property rights inherent in such information. >>> >>>>>> >>> >>>>>> >>> >>>> >>> >>>> _______________________________________________ >>> >>>> cdi-dev mailing list >>> >>>> cdi-dev at lists.jboss.org >>> >>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>>> >>> >>>> Note that for all code provided on this list, the >>> provider licenses the >>> >>>> code >>> >>>> under the Apache License, Version 2 >>> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). >>> For all other ideas >>> >>>> provided on this list, the provider waives all >>> patent and other >>> >>>> intellectual >>> >>>> property rights inherent in such information. >>> >> >>> >> >>> > >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/b3f2a562/attachment-0001.html From rmannibucau at gmail.com Wed Mar 4 08:04:23 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 4 Mar 2015 14:04:23 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: <54F701BB.9050209@redhat.com> References: <54DB1F2B.1020609@redhat.com> <54DC61D9.701@redhat.com> <54EECC20.6040600@redhat.com> <54EF396E.20805@redhat.com> <54F01720.3080802@redhat.com> <54F6CACD.6080507@redhat.com> <54F6FDF2.3000808@redhat.com> <54F701BB.9050209@redhat.com> Message-ID: Your definition seems to fit the standalone need: libraries = not CDI based code (case of a standalone), the runner class (Mymain) doesnt have to be a CDI bean but has to get injections to launch the CDI code. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-03-04 13:59 GMT+01:00 Jozef Hartinger : > UnmanagedInstance is provided to make it easier for libraries to perform > dependency injection on classes that are for some reason not CDI beans. It > should not be a substitute for lookup of CDI beans. Therefore, I do not see > UnmanagedInstance fitting here. > > > On 03/04/2015 01:47 PM, Romain Manni-Bucau wrote: > > Hmm > > I think one of the main point I try to push is we have a bunch of API to > do it already, if we need yet another API to do the same we have several > choices: > - we love creating APIs > - all previous APIs are failures and should be deprecated or fixed > - there is a full mismatch with embedded and EE case (but we have existing > proofs it is not the case) > > I think we should help user to not be lost between all APIs and I > strongly believe we can't do anything on container to lookup beans > (EJBContainer#getContext was a try which is close to it but it actually > just limited user experience compared to existing solutions). > > What's the issue with UnmanagedInstance? > > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2015-03-04 13:43 GMT+01:00 Jozef Hartinger : > >> The only argument I found supporting a strict separation of those two >> APIs is that it makes it easier to control when a user should or should not >> use boot (i.e. it should not be used in EE for example). >> >> That's a good argument. It's not however necessarily only achieved by two >> separate interfaces but can be as well be achieved with a subclass, e.g: >> - CDI for runtime operations only >> - StartedCDI extends CDI (or CDIContainer or whatever - the name does not >> matter at this point) for runtime operations + shutdown. >> >> Normally, CDI is available only. The boot API however would return >> StartedCDI thus allowing a user to shutdown what they started. >> >> >> >> On 03/04/2015 12:24 PM, John D. Ament wrote: >> >> This is actually based on what we discussed in one of the EG meetings >> >> >> http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-01-14-17.04.log.html >> >> John >> >> On Wed, Mar 4, 2015 at 4:05 AM Jozef Hartinger >> wrote: >> >>> Well it's nowhere given that we must have two separate interfaces for >>> this. We can combine the start/stop API with the existing one to provide an >>> application with a single reference representing the CDI container. >>> >>> >>> On 02/28/2015 07:05 PM, John D. Ament wrote: >>> >>> Maybe I'm misreading, but I don't see us adding another API to do the >>> same thing here - we're introducing new functionality. >>> >>> CDIContainer/Loader on startup/shutdown of the application >>> >>> CDI for runtime usage within the application to interact with the >>> container. >>> >>> John >>> >>> On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau < >>> rmannibucau at gmail.com> wrote: >>> >>>> sure I fully agree excepted I think introducing yet another API to do >>>> the same thing is not good so super tempting to skip it and wait for >>>> feedbacks rather than introducing it eagerly. >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau >>>> http://www.tomitribe.com >>>> http://rmannibucau.wordpress.com >>>> https://github.com/rmannibucau >>>> >>>> >>>> 2015-02-27 8:05 GMT+01:00 Jozef Hartinger : >>>> > My point is that from the application perspective, the user obtains >>>> one >>>> > container handle for eventual shutdown (CDIContainer) and then looks >>>> up a >>>> > different container handle (CDI) that they can use for real work >>>> (lookup / >>>> > event dispatch / etc.) It would be cleaner if the container gave away >>>> a >>>> > single handle that can do all of that. >>>> > >>>> > >>>> > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: >>>> > >>>> > Not sure I get how a CDI instance can help. >>>> > >>>> > But container.getBeanManager() sounds nice is not a shortcut for >>>> > CDI.current().getBm() otherwise it looks like duplication to me. >>>> > >>>> > Can we make container not contextual - dont think so? If so it makes >>>> sense >>>> > otherwise I fear it doesnt add much. >>>> > >>>> > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" a >>>> ?crit : >>>> >> >>>> >> I like the initialize + close() combination and the >>>> try-with-resources >>>> >> usage. >>>> >> What looks weird to me is that at line one you obtain a container >>>> handle: >>>> >> >>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>> >> CDI.current().getBeanManager() ... >>>> >> >>>> >> and then at line two you call a static method to perform a container >>>> >> lookup :-/ >>>> >> >>>> >> An API that allows you to use the container handle you already got >>>> is way >>>> >> better IMO, e.g.: >>>> >> >>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>> >> container.getBeanManager() >>>> >> >>>> >> If CDIContainer.newCDIContainer() returns an CDI instance or its >>>> subclass, >>>> >> we get this easily. >>>> >> >>>> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: >>>> >>> >>>> >>> Hi guys >>>> >>> >>>> >>> why note keeping it simple? >>>> >>> >>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer(/* >>>> optional >>>> >>> map to configure vendor features */)) { >>>> >>> CDI.current().getBeanManager().... >>>> >>> } >>>> >>> >>>> >>> Not sure the point having initialize() + having shutdown = close >>>> >>> really makes the API more fluent and modern IMO. >>>> >>> >>>> >>> Also to be fully SE I guess provider() method would be needed even >>>> if >>>> >>> optional (SPI usage by default): >>>> >>> >>>> >>> try (CDIContainer container = >>>> >>> >>>> >>> >>>> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider").newCDIContainer()) >>>> >>> { >>>> >>> CDI.current().getBeanManager().... >>>> >>> } >>>> >>> >>>> >>> Finally I think having a kind of getInstance shortcut could be a >>>> plus for >>>> >>> SE: >>>> >>> >>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer()) { >>>> >>> container.newInstance(MyAppRunner.class /* optional >>>> qualifiers */ >>>> >>> ).run(args); >>>> >>> } >>>> >>> >>>> >>> Using container to get an instance would create the instance and >>>> bind >>>> >>> it to the container lifecycle (mainly for predestroy) avoiding this >>>> >>> boilerplate code in all main which will surely only be used to >>>> launch >>>> >>> a soft. >>>> >>> >>>> >>> wdyt? >>>> >>> >>>> >>> >>>> >>> >>>> >>> Romain Manni-Bucau >>>> >>> @rmannibucau >>>> >>> http://www.tomitribe.com >>>> >>> http://rmannibucau.wordpress.com >>>> >>> https://github.com/rmannibucau >>>> >>> >>>> >>> >>>> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger : >>>> >>>> >>>> >>>> Comments inline >>>> >>>> >>>> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: >>>> >>>> >>>> >>>> Sorry Jozef, your email fell into the pits of google inbox's "smart >>>> >>>> sorting" >>>> >>>> features. >>>> >>>> >>>> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger < >>>> jharting at redhat.com> >>>> >>>> wrote: >>>> >>>>> >>>> >>>>> Hi John, comments inline: >>>> >>>>> >>>> >>>>> >>>> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >>>> >>>>> >>>> >>>>> Jozef, >>>> >>>>> >>>> >>>>> Most of what you see there is taken from the original doc, since >>>> >>>>> everyone >>>> >>>>> seemed to be in agreement. I think the map is just a safeguard >>>> in case >>>> >>>>> of >>>> >>>>> additional boot options available in some implementations (e.g. I >>>> think >>>> >>>>> OWB/OpenEJB have some options.. currently OpenEJB supports an >>>> embedded >>>> >>>>> CDI >>>> >>>>> boot mode). >>>> >>>>> >>>> >>>>> No, I am fine with the map. What I am questioning is the type of >>>> the >>>> >>>>> map. >>>> >>>>> Usually, data structures with a similar purpose use Strings as >>>> their >>>> >>>>> keys. >>>> >>>>> This applies to ServletContext attributes, InvocationContext data, >>>> >>>>> Servlet >>>> >>>>> request/session attributes and others. I am therefore wondering >>>> whether >>>> >>>>> there is a usecase for the proposed unbound key signature or not. >>>> >>>> >>>> >>>> >>>> >>>> I think that's more of a placeholder, I was assuming it would be >>>> >>>> Map once we clarify everything. >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> We spoke a few times about BeanManager vs CDI. BeanManager was >>>> >>>>> preferable >>>> >>>>> since there's no easy way to get the the instance, CDI is easier >>>> to get >>>> >>>>> and >>>> >>>>> more aligned with how you would get it. Usually people expect the >>>> >>>>> BeanManager to be injected or available via JNDI, neither would >>>> be the >>>> >>>>> case >>>> >>>>> here. >>>> >>>>> >>>> >>>>> If CDI 2.0 targets Java SE then this container initialization API >>>> will >>>> >>>>> become something that ordinary application developers use to >>>> start/stop >>>> >>>>> CDI >>>> >>>>> in their applications. It therefore cannot be considered an SPI >>>> but >>>> >>>>> instead >>>> >>>>> should be something easy to use. On the other hand, BeanManager is >>>> >>>>> definitely an SPI. It is used in extension, frameworks and >>>> generally >>>> >>>>> for >>>> >>>>> integration. Not much by applications directly. Therefore, I >>>> don't see >>>> >>>>> how >>>> >>>>> the container bootstrap API and BeanManager fit together. IMO the >>>> >>>>> bootstrap >>>> >>>>> API should expose something that makes common tasks (obtaining a >>>> >>>>> contextual >>>> >>>>> reference and firing and event) easy, which the CDI class does. >>>> >>>>> >>>> >>>>> Plus do not forget that BeanManager can be obtained easily using >>>> >>>>> CDI.getBeanManager(). >>>> >>>> >>>> >>>> >>>> >>>> I'm not disagreeing. There's a few things I'd consider: >>>> >>>> >>>> >>>> - Is this mostly for new apps or existing? If existing, it's >>>> probably >>>> >>>> using >>>> >>>> some internal API, if new it can use whatever API we give. >>>> >>>> - I don't want to return void, we should give some kind of >>>> reference >>>> >>>> into >>>> >>>> the container when we're done booting. >>>> >>>> >>>> >>>> Agreed, we should not be returning void. >>>> >>>> >>>> >>>> - CDI is a one step retrievable reference, where as BeanManager is >>>> a two >>>> >>>> step reference. With that said, BeanManager makes more sense to >>>> return >>>> >>>> here. Another thought could be we invent some new class that has >>>> both, >>>> >>>> but >>>> >>>> that's really redundant. >>>> >>>> >>>> >>>> Why do you think BeanManager makes more sense here? Especially >>>> given the >>>> >>>> assumption that application code is going to call this >>>> init/shutdown >>>> >>>> API, I >>>> >>>> don't see BeanManager as making more sense. >>>> >>>> >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> Yes, this is the container start API. Sounds like you have some >>>> good >>>> >>>>> ideas for things like XML configuration or programmatic >>>> configuration, >>>> >>>>> both >>>> >>>>> of which are being tracked under separate tickets. One idea >>>> might be >>>> >>>>> for an >>>> >>>>> optional param in the map to control packages to scan/ignore, in >>>> that >>>> >>>>> map. >>>> >>>>> >>>> >>>>> I am wondering whether this configuration should be something >>>> optional >>>> >>>>> built on top of the bootstrap API or whether we should consider >>>> making >>>> >>>>> it >>>> >>>>> mandatory. Either way, we cannot add the bootstrap API to the spec >>>> >>>>> without >>>> >>>>> explicitly defining how it behaves. My implicit assumption of the >>>> >>>>> proposal >>>> >>>>> is that the container is supposed to scan the entire classpath for >>>> >>>>> explicit >>>> >>>>> or implicit bean archives (including e.g. rt.jar), discover >>>> beans, fire >>>> >>>>> extensions, etc. This worries me as this default behavior is far >>>> from >>>> >>>>> being >>>> >>>>> lightweight, which CDI for Java SE initially aimed to be. >>>> >>>> >>>> >>>> >>>> >>>> Yes, the spec must be updated to reflect the behavior of SE mode. >>>> I >>>> >>>> plan to >>>> >>>> get that completely into the google doc before opening any spec >>>> changes >>>> >>>> in a >>>> >>>> PR. >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> We didn't want to over load the CDI interface. It already does a >>>> lot. >>>> >>>>> This is really SPI code, CDI even though it's in the spi package >>>> is >>>> >>>>> used in >>>> >>>>> a lot of application code. >>>> >>>>> >>>> >>>>> I would personally prefer to have it all in one place. Having >>>> >>>>> CDIContainer, CDIContainerLoader, CDI and CDIProvider makes it >>>> more >>>> >>>>> difficult to know when to use what. >>>> >>>> >>>> >>>> >>>> >>>> The problem is that most CDI (the interface) operations are >>>> against a >>>> >>>> running container. I think we spoke about leveraging CDIProvider >>>> at one >>>> >>>> point (in fact, I mistakenly called CDIContainer CDIProvider not >>>> even >>>> >>>> realizing it was there). I doubt that most app developers use it >>>> >>>> currently, >>>> >>>> there's not even a way to get a reference to it that I'm aware >>>> of. It's >>>> >>>> used by the implementor only. >>>> >>>> >>>> >>>> I don't think there's a conflict. CDI class would still only >>>> provide >>>> >>>> methods >>>> >>>> to be run against a running container. The difference is that there >>>> >>>> would be >>>> >>>> additional static methods to get this running container (CDI >>>> class) to >>>> >>>> you >>>> >>>> by starting the container. >>>> >>>> >>>> >>>> Either way, I agree that reusing CDIProvider is a must. There is no >>>> >>>> reason >>>> >>>> to define a new class for the same purpose. >>>> >>>> >>>> >>>> >>>> >>>> I expect that my changes in the CDI spec around this will state, >>>> along >>>> >>>> the >>>> >>>> lines of: >>>> >>>> >>>> >>>> To retrieve a CDIContainer to launch, do this: >>>> >>>> >>>> >>>> CDIContainer container = CDIContainerLocator.getCDIContainer(); >>>> >>>> container.initialize(); >>>> >>>> ... do work >>>> >>>> >>>> >>>> Once you want to shutdown the container, do this: >>>> >>>> >>>> >>>> container.shutdown(); >>>> >>>> >>>> >>>> (we may want to consider implementing AutoCloseable, an oversight >>>> on my >>>> >>>> part) >>>> >>>> >>>> >>>> and then later on >>>> >>>> >>>> >>>> - What happens if I call CDIContainerLocator in an app server >>>> >>>> >>>> >>>> - It throws an IllegalStateException. >>>> >>>> >>>> >>>> - The container provides no beans of type CDIContainer, it is >>>> managed >>>> >>>> outside of the CDI container. >>>> >>>> >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> John >>>> >>>>> >>>> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger < >>>> jharting at redhat.com> >>>> >>>>> wrote: >>>> >>>>>> >>>> >>>>>> Hi John, some thoughts: >>>> >>>>>> >>>> >>>>>> - instead of using BeanManager it makes more sense to me to >>>> return a >>>> >>>>>> CDI >>>> >>>>>> instance, which is a more user-friendly API (and it also exposes >>>> >>>>>> access to >>>> >>>>>> BeanManager) >>>> >>>>>> - is there a usecase for arbitrary keys of the "params" map or is >>>> >>>>>> Map sufficient? >>>> >>>>>> - if we could move the shutdown() method from CDIContainer to the >>>> >>>>>> actual >>>> >>>>>> container handle that we obtain from initialize(), that would >>>> look >>>> >>>>>> more >>>> >>>>>> object-oriented >>>> >>>>>> - what exactly is initialize() supposed to do? Is it supposed to >>>> start >>>> >>>>>> scanning the entire classpath for CDI beans? That could be a >>>> problem >>>> >>>>>> especially with spring-boot-like fat jars. I think we need an >>>> API to >>>> >>>>>> tell >>>> >>>>>> the container which classes / packages to consider. Something >>>> like >>>> >>>>>> Guice's >>>> >>>>>> binding API perhaps? >>>> >>>>>> >>>> >>>>>> - the proposal makes me wonder whether retrofitting this >>>> functionality >>>> >>>>>> to >>>> >>>>>> the CDI class wouldn't be a better option. It could look like: >>>> >>>>>> >>>> >>>>>> CDI container = CDI.initialize(); >>>> >>>>>> container.select(Foo.class).get(); >>>> >>>>>> container.shutdown(); >>>> >>>>>> >>>> >>>>>> compare it to: >>>> >>>>>> >>>> >>>>>> CDIContainer container = CDIContainerLoader. getCDIContainer(); >>>> >>>>>> BeanManager manager = container.initialize(); >>>> >>>>>> manager.getBeans(...); >>>> >>>>>> container.shutdown(manager); >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >>>> >>>>>> >>>> >>>>>> All, >>>> >>>>>> >>>> >>>>>> I have the updated API here, and wanted to solicit any final >>>> feedback >>>> >>>>>> before updating the google doc and spec pages. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c >>>> >>>>>> >>>> >>>>>> Let me know your thoughts. >>>> >>>>>> >>>> >>>>>> Thanks, >>>> >>>>>> >>>> >>>>>> John >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> _______________________________________________ >>>> >>>>>> cdi-dev mailing list >>>> >>>>>> cdi-dev at lists.jboss.org >>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>>>> >>>> >>>>>> Note that for all code provided on this list, the provider >>>> licenses >>>> >>>>>> the >>>> >>>>>> code under the Apache License, Version 2 >>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all >>>> other ideas >>>> >>>>>> provided on this list, the provider waives all patent and other >>>> >>>>>> intellectual >>>> >>>>>> property rights inherent in such information. >>>> >>>>>> >>>> >>>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> cdi-dev mailing list >>>> >>>> cdi-dev at lists.jboss.org >>>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> >>>> >>>> Note that for all code provided on this list, the provider >>>> licenses the >>>> >>>> code >>>> >>>> under the Apache License, Version 2 >>>> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>>> ideas >>>> >>>> provided on this list, the provider waives all patent and other >>>> >>>> intellectual >>>> >>>> property rights inherent in such information. >>>> >> >>>> >> >>>> > >>>> >>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/cba35c37/attachment-0001.html From john.d.ament at gmail.com Wed Mar 4 08:05:48 2015 From: john.d.ament at gmail.com (John D. Ament) Date: Wed, 04 Mar 2015 13:05:48 +0000 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) References: <54DB1F2B.1020609@redhat.com> <54DC61D9.701@redhat.com> <54EECC20.6040600@redhat.com> <54EF396E.20805@redhat.com> <54F01720.3080802@redhat.com> <54F6CACD.6080507@redhat.com> <54F6FDF2.3000808@redhat.com> <54F701BB.9050209@redhat.com> Message-ID: Just to clarify a few more things. The use of CDIContainer container = CDIContainerLoader.getCDIContainer(); Was meant to emulate the boot process used in several other specs that have SE equivalents, e.g. JPA and Bean Validation, which use a locator type to give a factory, and that factory giving what you typically work with. John On Wed, Mar 4, 2015 at 7:59 AM Jozef Hartinger wrote: > UnmanagedInstance is provided to make it easier for libraries to perform > dependency injection on classes that are for some reason not CDI beans. It > should not be a substitute for lookup of CDI beans. Therefore, I do not see > UnmanagedInstance fitting here. > > > On 03/04/2015 01:47 PM, Romain Manni-Bucau wrote: > > Hmm > > I think one of the main point I try to push is we have a bunch of API to > do it already, if we need yet another API to do the same we have several > choices: > - we love creating APIs > - all previous APIs are failures and should be deprecated or fixed > - there is a full mismatch with embedded and EE case (but we have existing > proofs it is not the case) > > I think we should help user to not be lost between all APIs and I > strongly believe we can't do anything on container to lookup beans > (EJBContainer#getContext was a try which is close to it but it actually > just limited user experience compared to existing solutions). > > What's the issue with UnmanagedInstance? > > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2015-03-04 13:43 GMT+01:00 Jozef Hartinger : > >> The only argument I found supporting a strict separation of those two >> APIs is that it makes it easier to control when a user should or should not >> use boot (i.e. it should not be used in EE for example). >> >> That's a good argument. It's not however necessarily only achieved by two >> separate interfaces but can be as well be achieved with a subclass, e.g: >> - CDI for runtime operations only >> - StartedCDI extends CDI (or CDIContainer or whatever - the name does not >> matter at this point) for runtime operations + shutdown. >> >> Normally, CDI is available only. The boot API however would return >> StartedCDI thus allowing a user to shutdown what they started. >> >> >> >> On 03/04/2015 12:24 PM, John D. Ament wrote: >> >> This is actually based on what we discussed in one of the EG meetings >> >> >> http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-01-14-17.04.log.html >> >> John >> >> On Wed, Mar 4, 2015 at 4:05 AM Jozef Hartinger >> wrote: >> >>> Well it's nowhere given that we must have two separate interfaces for >>> this. We can combine the start/stop API with the existing one to provide an >>> application with a single reference representing the CDI container. >>> >>> >>> On 02/28/2015 07:05 PM, John D. Ament wrote: >>> >>> Maybe I'm misreading, but I don't see us adding another API to do the >>> same thing here - we're introducing new functionality. >>> >>> CDIContainer/Loader on startup/shutdown of the application >>> >>> CDI for runtime usage within the application to interact with the >>> container. >>> >>> John >>> >>> On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau < >>> rmannibucau at gmail.com> wrote: >>> >>>> sure I fully agree excepted I think introducing yet another API to do >>>> the same thing is not good so super tempting to skip it and wait for >>>> feedbacks rather than introducing it eagerly. >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau >>>> http://www.tomitribe.com >>>> http://rmannibucau.wordpress.com >>>> https://github.com/rmannibucau >>>> >>>> >>>> 2015-02-27 8:05 GMT+01:00 Jozef Hartinger : >>>> > My point is that from the application perspective, the user obtains >>>> one >>>> > container handle for eventual shutdown (CDIContainer) and then looks >>>> up a >>>> > different container handle (CDI) that they can use for real work >>>> (lookup / >>>> > event dispatch / etc.) It would be cleaner if the container gave away >>>> a >>>> > single handle that can do all of that. >>>> > >>>> > >>>> > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: >>>> > >>>> > Not sure I get how a CDI instance can help. >>>> > >>>> > But container.getBeanManager() sounds nice is not a shortcut for >>>> > CDI.current().getBm() otherwise it looks like duplication to me. >>>> > >>>> > Can we make container not contextual - dont think so? If so it makes >>>> sense >>>> > otherwise I fear it doesnt add much. >>>> > >>>> > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" a >>>> ?crit : >>>> >> >>>> >> I like the initialize + close() combination and the >>>> try-with-resources >>>> >> usage. >>>> >> What looks weird to me is that at line one you obtain a container >>>> handle: >>>> >> >>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>> >> CDI.current().getBeanManager() ... >>>> >> >>>> >> and then at line two you call a static method to perform a container >>>> >> lookup :-/ >>>> >> >>>> >> An API that allows you to use the container handle you already got >>>> is way >>>> >> better IMO, e.g.: >>>> >> >>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>> >> container.getBeanManager() >>>> >> >>>> >> If CDIContainer.newCDIContainer() returns an CDI instance or its >>>> subclass, >>>> >> we get this easily. >>>> >> >>>> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: >>>> >>> >>>> >>> Hi guys >>>> >>> >>>> >>> why note keeping it simple? >>>> >>> >>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer(/* >>>> optional >>>> >>> map to configure vendor features */)) { >>>> >>> CDI.current().getBeanManager().... >>>> >>> } >>>> >>> >>>> >>> Not sure the point having initialize() + having shutdown = close >>>> >>> really makes the API more fluent and modern IMO. >>>> >>> >>>> >>> Also to be fully SE I guess provider() method would be needed even >>>> if >>>> >>> optional (SPI usage by default): >>>> >>> >>>> >>> try (CDIContainer container = >>>> >>> >>>> >>> >>>> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider").newCDIContainer()) >>>> >>> { >>>> >>> CDI.current().getBeanManager().... >>>> >>> } >>>> >>> >>>> >>> Finally I think having a kind of getInstance shortcut could be a >>>> plus for >>>> >>> SE: >>>> >>> >>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer()) { >>>> >>> container.newInstance(MyAppRunner.class /* optional >>>> qualifiers */ >>>> >>> ).run(args); >>>> >>> } >>>> >>> >>>> >>> Using container to get an instance would create the instance and >>>> bind >>>> >>> it to the container lifecycle (mainly for predestroy) avoiding this >>>> >>> boilerplate code in all main which will surely only be used to >>>> launch >>>> >>> a soft. >>>> >>> >>>> >>> wdyt? >>>> >>> >>>> >>> >>>> >>> >>>> >>> Romain Manni-Bucau >>>> >>> @rmannibucau >>>> >>> http://www.tomitribe.com >>>> >>> http://rmannibucau.wordpress.com >>>> >>> https://github.com/rmannibucau >>>> >>> >>>> >>> >>>> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger : >>>> >>>> >>>> >>>> Comments inline >>>> >>>> >>>> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: >>>> >>>> >>>> >>>> Sorry Jozef, your email fell into the pits of google inbox's "smart >>>> >>>> sorting" >>>> >>>> features. >>>> >>>> >>>> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger < >>>> jharting at redhat.com> >>>> >>>> wrote: >>>> >>>>> >>>> >>>>> Hi John, comments inline: >>>> >>>>> >>>> >>>>> >>>> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >>>> >>>>> >>>> >>>>> Jozef, >>>> >>>>> >>>> >>>>> Most of what you see there is taken from the original doc, since >>>> >>>>> everyone >>>> >>>>> seemed to be in agreement. I think the map is just a safeguard >>>> in case >>>> >>>>> of >>>> >>>>> additional boot options available in some implementations (e.g. I >>>> think >>>> >>>>> OWB/OpenEJB have some options.. currently OpenEJB supports an >>>> embedded >>>> >>>>> CDI >>>> >>>>> boot mode). >>>> >>>>> >>>> >>>>> No, I am fine with the map. What I am questioning is the type of >>>> the >>>> >>>>> map. >>>> >>>>> Usually, data structures with a similar purpose use Strings as >>>> their >>>> >>>>> keys. >>>> >>>>> This applies to ServletContext attributes, InvocationContext data, >>>> >>>>> Servlet >>>> >>>>> request/session attributes and others. I am therefore wondering >>>> whether >>>> >>>>> there is a usecase for the proposed unbound key signature or not. >>>> >>>> >>>> >>>> >>>> >>>> I think that's more of a placeholder, I was assuming it would be >>>> >>>> Map once we clarify everything. >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> We spoke a few times about BeanManager vs CDI. BeanManager was >>>> >>>>> preferable >>>> >>>>> since there's no easy way to get the the instance, CDI is easier >>>> to get >>>> >>>>> and >>>> >>>>> more aligned with how you would get it. Usually people expect the >>>> >>>>> BeanManager to be injected or available via JNDI, neither would >>>> be the >>>> >>>>> case >>>> >>>>> here. >>>> >>>>> >>>> >>>>> If CDI 2.0 targets Java SE then this container initialization API >>>> will >>>> >>>>> become something that ordinary application developers use to >>>> start/stop >>>> >>>>> CDI >>>> >>>>> in their applications. It therefore cannot be considered an SPI >>>> but >>>> >>>>> instead >>>> >>>>> should be something easy to use. On the other hand, BeanManager is >>>> >>>>> definitely an SPI. It is used in extension, frameworks and >>>> generally >>>> >>>>> for >>>> >>>>> integration. Not much by applications directly. Therefore, I >>>> don't see >>>> >>>>> how >>>> >>>>> the container bootstrap API and BeanManager fit together. IMO the >>>> >>>>> bootstrap >>>> >>>>> API should expose something that makes common tasks (obtaining a >>>> >>>>> contextual >>>> >>>>> reference and firing and event) easy, which the CDI class does. >>>> >>>>> >>>> >>>>> Plus do not forget that BeanManager can be obtained easily using >>>> >>>>> CDI.getBeanManager(). >>>> >>>> >>>> >>>> >>>> >>>> I'm not disagreeing. There's a few things I'd consider: >>>> >>>> >>>> >>>> - Is this mostly for new apps or existing? If existing, it's >>>> probably >>>> >>>> using >>>> >>>> some internal API, if new it can use whatever API we give. >>>> >>>> - I don't want to return void, we should give some kind of >>>> reference >>>> >>>> into >>>> >>>> the container when we're done booting. >>>> >>>> >>>> >>>> Agreed, we should not be returning void. >>>> >>>> >>>> >>>> - CDI is a one step retrievable reference, where as BeanManager is >>>> a two >>>> >>>> step reference. With that said, BeanManager makes more sense to >>>> return >>>> >>>> here. Another thought could be we invent some new class that has >>>> both, >>>> >>>> but >>>> >>>> that's really redundant. >>>> >>>> >>>> >>>> Why do you think BeanManager makes more sense here? Especially >>>> given the >>>> >>>> assumption that application code is going to call this >>>> init/shutdown >>>> >>>> API, I >>>> >>>> don't see BeanManager as making more sense. >>>> >>>> >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> Yes, this is the container start API. Sounds like you have some >>>> good >>>> >>>>> ideas for things like XML configuration or programmatic >>>> configuration, >>>> >>>>> both >>>> >>>>> of which are being tracked under separate tickets. One idea >>>> might be >>>> >>>>> for an >>>> >>>>> optional param in the map to control packages to scan/ignore, in >>>> that >>>> >>>>> map. >>>> >>>>> >>>> >>>>> I am wondering whether this configuration should be something >>>> optional >>>> >>>>> built on top of the bootstrap API or whether we should consider >>>> making >>>> >>>>> it >>>> >>>>> mandatory. Either way, we cannot add the bootstrap API to the spec >>>> >>>>> without >>>> >>>>> explicitly defining how it behaves. My implicit assumption of the >>>> >>>>> proposal >>>> >>>>> is that the container is supposed to scan the entire classpath for >>>> >>>>> explicit >>>> >>>>> or implicit bean archives (including e.g. rt.jar), discover >>>> beans, fire >>>> >>>>> extensions, etc. This worries me as this default behavior is far >>>> from >>>> >>>>> being >>>> >>>>> lightweight, which CDI for Java SE initially aimed to be. >>>> >>>> >>>> >>>> >>>> >>>> Yes, the spec must be updated to reflect the behavior of SE mode. >>>> I >>>> >>>> plan to >>>> >>>> get that completely into the google doc before opening any spec >>>> changes >>>> >>>> in a >>>> >>>> PR. >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> We didn't want to over load the CDI interface. It already does a >>>> lot. >>>> >>>>> This is really SPI code, CDI even though it's in the spi package >>>> is >>>> >>>>> used in >>>> >>>>> a lot of application code. >>>> >>>>> >>>> >>>>> I would personally prefer to have it all in one place. Having >>>> >>>>> CDIContainer, CDIContainerLoader, CDI and CDIProvider makes it >>>> more >>>> >>>>> difficult to know when to use what. >>>> >>>> >>>> >>>> >>>> >>>> The problem is that most CDI (the interface) operations are >>>> against a >>>> >>>> running container. I think we spoke about leveraging CDIProvider >>>> at one >>>> >>>> point (in fact, I mistakenly called CDIContainer CDIProvider not >>>> even >>>> >>>> realizing it was there). I doubt that most app developers use it >>>> >>>> currently, >>>> >>>> there's not even a way to get a reference to it that I'm aware >>>> of. It's >>>> >>>> used by the implementor only. >>>> >>>> >>>> >>>> I don't think there's a conflict. CDI class would still only >>>> provide >>>> >>>> methods >>>> >>>> to be run against a running container. The difference is that there >>>> >>>> would be >>>> >>>> additional static methods to get this running container (CDI >>>> class) to >>>> >>>> you >>>> >>>> by starting the container. >>>> >>>> >>>> >>>> Either way, I agree that reusing CDIProvider is a must. There is no >>>> >>>> reason >>>> >>>> to define a new class for the same purpose. >>>> >>>> >>>> >>>> >>>> >>>> I expect that my changes in the CDI spec around this will state, >>>> along >>>> >>>> the >>>> >>>> lines of: >>>> >>>> >>>> >>>> To retrieve a CDIContainer to launch, do this: >>>> >>>> >>>> >>>> CDIContainer container = CDIContainerLocator.getCDIContainer(); >>>> >>>> container.initialize(); >>>> >>>> ... do work >>>> >>>> >>>> >>>> Once you want to shutdown the container, do this: >>>> >>>> >>>> >>>> container.shutdown(); >>>> >>>> >>>> >>>> (we may want to consider implementing AutoCloseable, an oversight >>>> on my >>>> >>>> part) >>>> >>>> >>>> >>>> and then later on >>>> >>>> >>>> >>>> - What happens if I call CDIContainerLocator in an app server >>>> >>>> >>>> >>>> - It throws an IllegalStateException. >>>> >>>> >>>> >>>> - The container provides no beans of type CDIContainer, it is >>>> managed >>>> >>>> outside of the CDI container. >>>> >>>> >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> John >>>> >>>>> >>>> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger < >>>> jharting at redhat.com> >>>> >>>>> wrote: >>>> >>>>>> >>>> >>>>>> Hi John, some thoughts: >>>> >>>>>> >>>> >>>>>> - instead of using BeanManager it makes more sense to me to >>>> return a >>>> >>>>>> CDI >>>> >>>>>> instance, which is a more user-friendly API (and it also exposes >>>> >>>>>> access to >>>> >>>>>> BeanManager) >>>> >>>>>> - is there a usecase for arbitrary keys of the "params" map or is >>>> >>>>>> Map sufficient? >>>> >>>>>> - if we could move the shutdown() method from CDIContainer to the >>>> >>>>>> actual >>>> >>>>>> container handle that we obtain from initialize(), that would >>>> look >>>> >>>>>> more >>>> >>>>>> object-oriented >>>> >>>>>> - what exactly is initialize() supposed to do? Is it supposed to >>>> start >>>> >>>>>> scanning the entire classpath for CDI beans? That could be a >>>> problem >>>> >>>>>> especially with spring-boot-like fat jars. I think we need an >>>> API to >>>> >>>>>> tell >>>> >>>>>> the container which classes / packages to consider. Something >>>> like >>>> >>>>>> Guice's >>>> >>>>>> binding API perhaps? >>>> >>>>>> >>>> >>>>>> - the proposal makes me wonder whether retrofitting this >>>> functionality >>>> >>>>>> to >>>> >>>>>> the CDI class wouldn't be a better option. It could look like: >>>> >>>>>> >>>> >>>>>> CDI container = CDI.initialize(); >>>> >>>>>> container.select(Foo.class).get(); >>>> >>>>>> container.shutdown(); >>>> >>>>>> >>>> >>>>>> compare it to: >>>> >>>>>> >>>> >>>>>> CDIContainer container = CDIContainerLoader. getCDIContainer(); >>>> >>>>>> BeanManager manager = container.initialize(); >>>> >>>>>> manager.getBeans(...); >>>> >>>>>> container.shutdown(manager); >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >>>> >>>>>> >>>> >>>>>> All, >>>> >>>>>> >>>> >>>>>> I have the updated API here, and wanted to solicit any final >>>> feedback >>>> >>>>>> before updating the google doc and spec pages. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c >>>> >>>>>> >>>> >>>>>> Let me know your thoughts. >>>> >>>>>> >>>> >>>>>> Thanks, >>>> >>>>>> >>>> >>>>>> John >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> _______________________________________________ >>>> >>>>>> cdi-dev mailing list >>>> >>>>>> cdi-dev at lists.jboss.org >>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>>>> >>>> >>>>>> Note that for all code provided on this list, the provider >>>> licenses >>>> >>>>>> the >>>> >>>>>> code under the Apache License, Version 2 >>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all >>>> other ideas >>>> >>>>>> provided on this list, the provider waives all patent and other >>>> >>>>>> intellectual >>>> >>>>>> property rights inherent in such information. >>>> >>>>>> >>>> >>>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> cdi-dev mailing list >>>> >>>> cdi-dev at lists.jboss.org >>>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> >>>> >>>> Note that for all code provided on this list, the provider >>>> licenses the >>>> >>>> code >>>> >>>> under the Apache License, Version 2 >>>> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>>> ideas >>>> >>>> provided on this list, the provider waives all patent and other >>>> >>>> intellectual >>>> >>>> property rights inherent in such information. >>>> >> >>>> >> >>>> > >>>> >>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/2c4aa205/attachment-0001.html From rmannibucau at gmail.com Wed Mar 4 08:10:28 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 4 Mar 2015 14:10:28 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: References: <54DB1F2B.1020609@redhat.com> <54DC61D9.701@redhat.com> <54EECC20.6040600@redhat.com> <54EF396E.20805@redhat.com> <54F01720.3080802@redhat.com> <54F6CACD.6080507@redhat.com> <54F6FDF2.3000808@redhat.com> <54F701BB.9050209@redhat.com> Message-ID: Was due to the fact you can't have a static method in an interface, now you can so it can be hidden Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-03-04 14:05 GMT+01:00 John D. Ament : > Just to clarify a few more things. > > The use of > > CDIContainer container = CDIContainerLoader.getCDIContainer(); > > Was meant to emulate the boot process used in several other specs that > have SE equivalents, e.g. JPA and Bean Validation, which use a locator type > to give a factory, and that factory giving what you typically work with. > > John > > > On Wed, Mar 4, 2015 at 7:59 AM Jozef Hartinger > wrote: > >> UnmanagedInstance is provided to make it easier for libraries to perform >> dependency injection on classes that are for some reason not CDI beans. It >> should not be a substitute for lookup of CDI beans. Therefore, I do not see >> UnmanagedInstance fitting here. >> >> >> On 03/04/2015 01:47 PM, Romain Manni-Bucau wrote: >> >> Hmm >> >> I think one of the main point I try to push is we have a bunch of API >> to do it already, if we need yet another API to do the same we have several >> choices: >> - we love creating APIs >> - all previous APIs are failures and should be deprecated or fixed >> - there is a full mismatch with embedded and EE case (but we have >> existing proofs it is not the case) >> >> I think we should help user to not be lost between all APIs and I >> strongly believe we can't do anything on container to lookup beans >> (EJBContainer#getContext was a try which is close to it but it actually >> just limited user experience compared to existing solutions). >> >> What's the issue with UnmanagedInstance? >> >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> 2015-03-04 13:43 GMT+01:00 Jozef Hartinger : >> >>> The only argument I found supporting a strict separation of those two >>> APIs is that it makes it easier to control when a user should or should not >>> use boot (i.e. it should not be used in EE for example). >>> >>> That's a good argument. It's not however necessarily only achieved by >>> two separate interfaces but can be as well be achieved with a subclass, e.g: >>> - CDI for runtime operations only >>> - StartedCDI extends CDI (or CDIContainer or whatever - the name does >>> not matter at this point) for runtime operations + shutdown. >>> >>> Normally, CDI is available only. The boot API however would return >>> StartedCDI thus allowing a user to shutdown what they started. >>> >>> >>> >>> On 03/04/2015 12:24 PM, John D. Ament wrote: >>> >>> This is actually based on what we discussed in one of the EG meetings >>> >>> >>> http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-01-14-17.04.log.html >>> >>> John >>> >>> On Wed, Mar 4, 2015 at 4:05 AM Jozef Hartinger >>> wrote: >>> >>>> Well it's nowhere given that we must have two separate interfaces for >>>> this. We can combine the start/stop API with the existing one to provide an >>>> application with a single reference representing the CDI container. >>>> >>>> >>>> On 02/28/2015 07:05 PM, John D. Ament wrote: >>>> >>>> Maybe I'm misreading, but I don't see us adding another API to do the >>>> same thing here - we're introducing new functionality. >>>> >>>> CDIContainer/Loader on startup/shutdown of the application >>>> >>>> CDI for runtime usage within the application to interact with the >>>> container. >>>> >>>> John >>>> >>>> On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau < >>>> rmannibucau at gmail.com> wrote: >>>> >>>>> sure I fully agree excepted I think introducing yet another API to do >>>>> the same thing is not good so super tempting to skip it and wait for >>>>> feedbacks rather than introducing it eagerly. >>>>> >>>>> >>>>> Romain Manni-Bucau >>>>> @rmannibucau >>>>> http://www.tomitribe.com >>>>> http://rmannibucau.wordpress.com >>>>> https://github.com/rmannibucau >>>>> >>>>> >>>>> 2015-02-27 8:05 GMT+01:00 Jozef Hartinger : >>>>> > My point is that from the application perspective, the user obtains >>>>> one >>>>> > container handle for eventual shutdown (CDIContainer) and then looks >>>>> up a >>>>> > different container handle (CDI) that they can use for real work >>>>> (lookup / >>>>> > event dispatch / etc.) It would be cleaner if the container gave >>>>> away a >>>>> > single handle that can do all of that. >>>>> > >>>>> > >>>>> > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: >>>>> > >>>>> > Not sure I get how a CDI instance can help. >>>>> > >>>>> > But container.getBeanManager() sounds nice is not a shortcut for >>>>> > CDI.current().getBm() otherwise it looks like duplication to me. >>>>> > >>>>> > Can we make container not contextual - dont think so? If so it makes >>>>> sense >>>>> > otherwise I fear it doesnt add much. >>>>> > >>>>> > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" a >>>>> ?crit : >>>>> >> >>>>> >> I like the initialize + close() combination and the >>>>> try-with-resources >>>>> >> usage. >>>>> >> What looks weird to me is that at line one you obtain a container >>>>> handle: >>>>> >> >>>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>>> >> CDI.current().getBeanManager() ... >>>>> >> >>>>> >> and then at line two you call a static method to perform a container >>>>> >> lookup :-/ >>>>> >> >>>>> >> An API that allows you to use the container handle you already got >>>>> is way >>>>> >> better IMO, e.g.: >>>>> >> >>>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>>> >> container.getBeanManager() >>>>> >> >>>>> >> If CDIContainer.newCDIContainer() returns an CDI instance or its >>>>> subclass, >>>>> >> we get this easily. >>>>> >> >>>>> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: >>>>> >>> >>>>> >>> Hi guys >>>>> >>> >>>>> >>> why note keeping it simple? >>>>> >>> >>>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer(/* >>>>> optional >>>>> >>> map to configure vendor features */)) { >>>>> >>> CDI.current().getBeanManager().... >>>>> >>> } >>>>> >>> >>>>> >>> Not sure the point having initialize() + having shutdown = close >>>>> >>> really makes the API more fluent and modern IMO. >>>>> >>> >>>>> >>> Also to be fully SE I guess provider() method would be needed even >>>>> if >>>>> >>> optional (SPI usage by default): >>>>> >>> >>>>> >>> try (CDIContainer container = >>>>> >>> >>>>> >>> >>>>> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider").newCDIContainer()) >>>>> >>> { >>>>> >>> CDI.current().getBeanManager().... >>>>> >>> } >>>>> >>> >>>>> >>> Finally I think having a kind of getInstance shortcut could be a >>>>> plus for >>>>> >>> SE: >>>>> >>> >>>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer()) { >>>>> >>> container.newInstance(MyAppRunner.class /* optional >>>>> qualifiers */ >>>>> >>> ).run(args); >>>>> >>> } >>>>> >>> >>>>> >>> Using container to get an instance would create the instance and >>>>> bind >>>>> >>> it to the container lifecycle (mainly for predestroy) avoiding this >>>>> >>> boilerplate code in all main which will surely only be used to >>>>> launch >>>>> >>> a soft. >>>>> >>> >>>>> >>> wdyt? >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> Romain Manni-Bucau >>>>> >>> @rmannibucau >>>>> >>> http://www.tomitribe.com >>>>> >>> http://rmannibucau.wordpress.com >>>>> >>> https://github.com/rmannibucau >>>>> >>> >>>>> >>> >>>>> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger : >>>>> >>>> >>>>> >>>> Comments inline >>>>> >>>> >>>>> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: >>>>> >>>> >>>>> >>>> Sorry Jozef, your email fell into the pits of google inbox's >>>>> "smart >>>>> >>>> sorting" >>>>> >>>> features. >>>>> >>>> >>>>> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger < >>>>> jharting at redhat.com> >>>>> >>>> wrote: >>>>> >>>>> >>>>> >>>>> Hi John, comments inline: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >>>>> >>>>> >>>>> >>>>> Jozef, >>>>> >>>>> >>>>> >>>>> Most of what you see there is taken from the original doc, since >>>>> >>>>> everyone >>>>> >>>>> seemed to be in agreement. I think the map is just a safeguard >>>>> in case >>>>> >>>>> of >>>>> >>>>> additional boot options available in some implementations (e.g. >>>>> I think >>>>> >>>>> OWB/OpenEJB have some options.. currently OpenEJB supports an >>>>> embedded >>>>> >>>>> CDI >>>>> >>>>> boot mode). >>>>> >>>>> >>>>> >>>>> No, I am fine with the map. What I am questioning is the type of >>>>> the >>>>> >>>>> map. >>>>> >>>>> Usually, data structures with a similar purpose use Strings as >>>>> their >>>>> >>>>> keys. >>>>> >>>>> This applies to ServletContext attributes, InvocationContext >>>>> data, >>>>> >>>>> Servlet >>>>> >>>>> request/session attributes and others. I am therefore wondering >>>>> whether >>>>> >>>>> there is a usecase for the proposed unbound key signature or not. >>>>> >>>> >>>>> >>>> >>>>> >>>> I think that's more of a placeholder, I was assuming it would be >>>>> >>>> Map once we clarify everything. >>>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> We spoke a few times about BeanManager vs CDI. BeanManager was >>>>> >>>>> preferable >>>>> >>>>> since there's no easy way to get the the instance, CDI is easier >>>>> to get >>>>> >>>>> and >>>>> >>>>> more aligned with how you would get it. Usually people expect >>>>> the >>>>> >>>>> BeanManager to be injected or available via JNDI, neither would >>>>> be the >>>>> >>>>> case >>>>> >>>>> here. >>>>> >>>>> >>>>> >>>>> If CDI 2.0 targets Java SE then this container initialization >>>>> API will >>>>> >>>>> become something that ordinary application developers use to >>>>> start/stop >>>>> >>>>> CDI >>>>> >>>>> in their applications. It therefore cannot be considered an SPI >>>>> but >>>>> >>>>> instead >>>>> >>>>> should be something easy to use. On the other hand, BeanManager >>>>> is >>>>> >>>>> definitely an SPI. It is used in extension, frameworks and >>>>> generally >>>>> >>>>> for >>>>> >>>>> integration. Not much by applications directly. Therefore, I >>>>> don't see >>>>> >>>>> how >>>>> >>>>> the container bootstrap API and BeanManager fit together. IMO the >>>>> >>>>> bootstrap >>>>> >>>>> API should expose something that makes common tasks (obtaining a >>>>> >>>>> contextual >>>>> >>>>> reference and firing and event) easy, which the CDI class does. >>>>> >>>>> >>>>> >>>>> Plus do not forget that BeanManager can be obtained easily using >>>>> >>>>> CDI.getBeanManager(). >>>>> >>>> >>>>> >>>> >>>>> >>>> I'm not disagreeing. There's a few things I'd consider: >>>>> >>>> >>>>> >>>> - Is this mostly for new apps or existing? If existing, it's >>>>> probably >>>>> >>>> using >>>>> >>>> some internal API, if new it can use whatever API we give. >>>>> >>>> - I don't want to return void, we should give some kind of >>>>> reference >>>>> >>>> into >>>>> >>>> the container when we're done booting. >>>>> >>>> >>>>> >>>> Agreed, we should not be returning void. >>>>> >>>> >>>>> >>>> - CDI is a one step retrievable reference, where as BeanManager >>>>> is a two >>>>> >>>> step reference. With that said, BeanManager makes more sense to >>>>> return >>>>> >>>> here. Another thought could be we invent some new class that has >>>>> both, >>>>> >>>> but >>>>> >>>> that's really redundant. >>>>> >>>> >>>>> >>>> Why do you think BeanManager makes more sense here? Especially >>>>> given the >>>>> >>>> assumption that application code is going to call this >>>>> init/shutdown >>>>> >>>> API, I >>>>> >>>> don't see BeanManager as making more sense. >>>>> >>>> >>>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Yes, this is the container start API. Sounds like you have some >>>>> good >>>>> >>>>> ideas for things like XML configuration or programmatic >>>>> configuration, >>>>> >>>>> both >>>>> >>>>> of which are being tracked under separate tickets. One idea >>>>> might be >>>>> >>>>> for an >>>>> >>>>> optional param in the map to control packages to scan/ignore, in >>>>> that >>>>> >>>>> map. >>>>> >>>>> >>>>> >>>>> I am wondering whether this configuration should be something >>>>> optional >>>>> >>>>> built on top of the bootstrap API or whether we should consider >>>>> making >>>>> >>>>> it >>>>> >>>>> mandatory. Either way, we cannot add the bootstrap API to the >>>>> spec >>>>> >>>>> without >>>>> >>>>> explicitly defining how it behaves. My implicit assumption of the >>>>> >>>>> proposal >>>>> >>>>> is that the container is supposed to scan the entire classpath >>>>> for >>>>> >>>>> explicit >>>>> >>>>> or implicit bean archives (including e.g. rt.jar), discover >>>>> beans, fire >>>>> >>>>> extensions, etc. This worries me as this default behavior is far >>>>> from >>>>> >>>>> being >>>>> >>>>> lightweight, which CDI for Java SE initially aimed to be. >>>>> >>>> >>>>> >>>> >>>>> >>>> Yes, the spec must be updated to reflect the behavior of SE >>>>> mode. I >>>>> >>>> plan to >>>>> >>>> get that completely into the google doc before opening any spec >>>>> changes >>>>> >>>> in a >>>>> >>>> PR. >>>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> We didn't want to over load the CDI interface. It already does >>>>> a lot. >>>>> >>>>> This is really SPI code, CDI even though it's in the spi package >>>>> is >>>>> >>>>> used in >>>>> >>>>> a lot of application code. >>>>> >>>>> >>>>> >>>>> I would personally prefer to have it all in one place. Having >>>>> >>>>> CDIContainer, CDIContainerLoader, CDI and CDIProvider makes it >>>>> more >>>>> >>>>> difficult to know when to use what. >>>>> >>>> >>>>> >>>> >>>>> >>>> The problem is that most CDI (the interface) operations are >>>>> against a >>>>> >>>> running container. I think we spoke about leveraging CDIProvider >>>>> at one >>>>> >>>> point (in fact, I mistakenly called CDIContainer CDIProvider not >>>>> even >>>>> >>>> realizing it was there). I doubt that most app developers use it >>>>> >>>> currently, >>>>> >>>> there's not even a way to get a reference to it that I'm aware >>>>> of. It's >>>>> >>>> used by the implementor only. >>>>> >>>> >>>>> >>>> I don't think there's a conflict. CDI class would still only >>>>> provide >>>>> >>>> methods >>>>> >>>> to be run against a running container. The difference is that >>>>> there >>>>> >>>> would be >>>>> >>>> additional static methods to get this running container (CDI >>>>> class) to >>>>> >>>> you >>>>> >>>> by starting the container. >>>>> >>>> >>>>> >>>> Either way, I agree that reusing CDIProvider is a must. There is >>>>> no >>>>> >>>> reason >>>>> >>>> to define a new class for the same purpose. >>>>> >>>> >>>>> >>>> >>>>> >>>> I expect that my changes in the CDI spec around this will state, >>>>> along >>>>> >>>> the >>>>> >>>> lines of: >>>>> >>>> >>>>> >>>> To retrieve a CDIContainer to launch, do this: >>>>> >>>> >>>>> >>>> CDIContainer container = CDIContainerLocator.getCDIContainer(); >>>>> >>>> container.initialize(); >>>>> >>>> ... do work >>>>> >>>> >>>>> >>>> Once you want to shutdown the container, do this: >>>>> >>>> >>>>> >>>> container.shutdown(); >>>>> >>>> >>>>> >>>> (we may want to consider implementing AutoCloseable, an oversight >>>>> on my >>>>> >>>> part) >>>>> >>>> >>>>> >>>> and then later on >>>>> >>>> >>>>> >>>> - What happens if I call CDIContainerLocator in an app server >>>>> >>>> >>>>> >>>> - It throws an IllegalStateException. >>>>> >>>> >>>>> >>>> - The container provides no beans of type CDIContainer, it is >>>>> managed >>>>> >>>> outside of the CDI container. >>>>> >>>> >>>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> John >>>>> >>>>> >>>>> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger < >>>>> jharting at redhat.com> >>>>> >>>>> wrote: >>>>> >>>>>> >>>>> >>>>>> Hi John, some thoughts: >>>>> >>>>>> >>>>> >>>>>> - instead of using BeanManager it makes more sense to me to >>>>> return a >>>>> >>>>>> CDI >>>>> >>>>>> instance, which is a more user-friendly API (and it also exposes >>>>> >>>>>> access to >>>>> >>>>>> BeanManager) >>>>> >>>>>> - is there a usecase for arbitrary keys of the "params" map or >>>>> is >>>>> >>>>>> Map sufficient? >>>>> >>>>>> - if we could move the shutdown() method from CDIContainer to >>>>> the >>>>> >>>>>> actual >>>>> >>>>>> container handle that we obtain from initialize(), that would >>>>> look >>>>> >>>>>> more >>>>> >>>>>> object-oriented >>>>> >>>>>> - what exactly is initialize() supposed to do? Is it supposed >>>>> to start >>>>> >>>>>> scanning the entire classpath for CDI beans? That could be a >>>>> problem >>>>> >>>>>> especially with spring-boot-like fat jars. I think we need an >>>>> API to >>>>> >>>>>> tell >>>>> >>>>>> the container which classes / packages to consider. Something >>>>> like >>>>> >>>>>> Guice's >>>>> >>>>>> binding API perhaps? >>>>> >>>>>> >>>>> >>>>>> - the proposal makes me wonder whether retrofitting this >>>>> functionality >>>>> >>>>>> to >>>>> >>>>>> the CDI class wouldn't be a better option. It could look like: >>>>> >>>>>> >>>>> >>>>>> CDI container = CDI.initialize(); >>>>> >>>>>> container.select(Foo.class).get(); >>>>> >>>>>> container.shutdown(); >>>>> >>>>>> >>>>> >>>>>> compare it to: >>>>> >>>>>> >>>>> >>>>>> CDIContainer container = CDIContainerLoader. getCDIContainer(); >>>>> >>>>>> BeanManager manager = container.initialize(); >>>>> >>>>>> manager.getBeans(...); >>>>> >>>>>> container.shutdown(manager); >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >>>>> >>>>>> >>>>> >>>>>> All, >>>>> >>>>>> >>>>> >>>>>> I have the updated API here, and wanted to solicit any final >>>>> feedback >>>>> >>>>>> before updating the google doc and spec pages. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c >>>>> >>>>>> >>>>> >>>>>> Let me know your thoughts. >>>>> >>>>>> >>>>> >>>>>> Thanks, >>>>> >>>>>> >>>>> >>>>>> John >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> _______________________________________________ >>>>> >>>>>> cdi-dev mailing list >>>>> >>>>>> cdi-dev at lists.jboss.org >>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>>> >>>>> >>>>>> Note that for all code provided on this list, the provider >>>>> licenses >>>>> >>>>>> the >>>>> >>>>>> code under the Apache License, Version 2 >>>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all >>>>> other ideas >>>>> >>>>>> provided on this list, the provider waives all patent and other >>>>> >>>>>> intellectual >>>>> >>>>>> property rights inherent in such information. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>> >>>>> >>>> _______________________________________________ >>>>> >>>> cdi-dev mailing list >>>>> >>>> cdi-dev at lists.jboss.org >>>>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>> >>>>> >>>> Note that for all code provided on this list, the provider >>>>> licenses the >>>>> >>>> code >>>>> >>>> under the Apache License, Version 2 >>>>> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>>>> ideas >>>>> >>>> provided on this list, the provider waives all patent and other >>>>> >>>> intellectual >>>>> >>>> property rights inherent in such information. >>>>> >> >>>>> >> >>>>> > >>>>> >>>> >>>> >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/4597c6a8/attachment-0001.html From jharting at redhat.com Wed Mar 4 09:46:47 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 04 Mar 2015 15:46:47 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: References: <54DB1F2B.1020609@redhat.com> <54DC61D9.701@redhat.com> <54EECC20.6040600@redhat.com> <54EF396E.20805@redhat.com> <54F01720.3080802@redhat.com> <54F6CACD.6080507@redhat.com> <54F6FDF2.3000808@redhat.com> <54F701BB.9050209@redhat.com> Message-ID: <54F71AD7.7080003@redhat.com> Sure, I am not saying Unmanaged should not be used at all. Under given circumstances it makes sense to use Unmanaged. I however don't think it fits as the general recommended way of using CDI in SE because if a given class is a bean already, the managed instance should be obtained instead of creating an unmanaged instance. On 03/04/2015 02:04 PM, Romain Manni-Bucau wrote: > Your definition seems to fit the standalone need: libraries = not CDI > based code (case of a standalone), the runner class (Mymain) doesnt > have to be a CDI bean but has to get injections to launch the CDI code. > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2015-03-04 13:59 GMT+01:00 Jozef Hartinger >: > > UnmanagedInstance is provided to make it easier for libraries to > perform dependency injection on classes that are for some reason > not CDI beans. It should not be a substitute for lookup of CDI > beans. Therefore, I do not see UnmanagedInstance fitting here. > > > On 03/04/2015 01:47 PM, Romain Manni-Bucau wrote: >> Hmm >> >> I think one of the main point I try to push is we have a bunch of >> API to do it already, if we need yet another API to do the same >> we have several choices: >> - we love creating APIs >> - all previous APIs are failures and should be deprecated or fixed >> - there is a full mismatch with embedded and EE case (but we have >> existing proofs it is not the case) >> >> I think we should help user to not be lost between all APIs and I >> strongly believe we can't do anything on container to lookup >> beans (EJBContainer#getContext was a try which is close to it but >> it actually just limited user experience compared to existing >> solutions). >> >> What's the issue with UnmanagedInstance? >> >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> 2015-03-04 13:43 GMT+01:00 Jozef Hartinger > >: >> >> The only argument I found supporting a strict separation of >> those two APIs is that it makes it easier to control when a >> user should or should not use boot (i.e. it should not be >> used in EE for example). >> >> That's a good argument. It's not however necessarily only >> achieved by two separate interfaces but can be as well be >> achieved with a subclass, e.g: >> - CDI for runtime operations only >> - StartedCDI extends CDI (or CDIContainer or whatever - the >> name does not matter at this point) for runtime operations + >> shutdown. >> >> Normally, CDI is available only. The boot API however would >> return StartedCDI thus allowing a user to shutdown what they >> started. >> >> >> >> On 03/04/2015 12:24 PM, John D. Ament wrote: >>> This is actually based on what we discussed in one of the EG >>> meetings >>> >>> http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-01-14-17.04.log.html >>> >>> John >>> >>> On Wed, Mar 4, 2015 at 4:05 AM Jozef Hartinger >>> > wrote: >>> >>> Well it's nowhere given that we must have two separate >>> interfaces for this. We can combine the start/stop API >>> with the existing one to provide an application with a >>> single reference representing the CDI container. >>> >>> >>> On 02/28/2015 07:05 PM, John D. Ament wrote: >>>> Maybe I'm misreading, but I don't see us adding another >>>> API to do the same thing here - we're introducing new >>>> functionality. >>>> >>>> CDIContainer/Loader on startup/shutdown of the application >>>> >>>> CDI for runtime usage within the application to >>>> interact with the container. >>>> >>>> John >>>> >>>> On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau >>>> > >>>> wrote: >>>> >>>> sure I fully agree excepted I think introducing yet >>>> another API to do >>>> the same thing is not good so super tempting to >>>> skip it and wait for >>>> feedbacks rather than introducing it eagerly. >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau >>>> http://www.tomitribe.com >>>> http://rmannibucau.wordpress.com >>>> https://github.com/rmannibucau >>>> >>>> >>>> 2015-02-27 8:05 GMT+01:00 Jozef Hartinger >>>> >: >>>> > My point is that from the application >>>> perspective, the user obtains one >>>> > container handle for eventual shutdown >>>> (CDIContainer) and then looks up a >>>> > different container handle (CDI) that they can >>>> use for real work (lookup / >>>> > event dispatch / etc.) It would be cleaner if the >>>> container gave away a >>>> > single handle that can do all of that. >>>> > >>>> > >>>> > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: >>>> > >>>> > Not sure I get how a CDI instance can help. >>>> > >>>> > But container.getBeanManager() sounds nice is not >>>> a shortcut for >>>> > CDI.current().getBm() otherwise it looks like >>>> duplication to me. >>>> > >>>> > Can we make container not contextual - dont think >>>> so? If so it makes sense >>>> > otherwise I fear it doesnt add much. >>>> > >>>> > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" >>>> > >>>> a ?crit : >>>> >> >>>> >> I like the initialize + close() combination and >>>> the try-with-resources >>>> >> usage. >>>> >> What looks weird to me is that at line one you >>>> obtain a container handle: >>>> >> >>>> >> try (CDIContainer container = >>>> CDIContainer.newCDIContai... >>>> >> CDI.current().getBeanManager() ... >>>> >> >>>> >> and then at line two you call a static method to >>>> perform a container >>>> >> lookup :-/ >>>> >> >>>> >> An API that allows you to use the container >>>> handle you already got is way >>>> >> better IMO, e.g.: >>>> >> >>>> >> try (CDIContainer container = >>>> CDIContainer.newCDIContai... >>>> >> container.getBeanManager() >>>> >> >>>> >> If CDIContainer.newCDIContainer() returns an CDI >>>> instance or its subclass, >>>> >> we get this easily. >>>> >> >>>> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: >>>> >>> >>>> >>> Hi guys >>>> >>> >>>> >>> why note keeping it simple? >>>> >>> >>>> >>> try (CDIContainer container = >>>> CDIContainer.newCDIContainer(/* optional >>>> >>> map to configure vendor features */)) { >>>> >>> CDI.current().getBeanManager().... >>>> >>> } >>>> >>> >>>> >>> Not sure the point having initialize() + having >>>> shutdown = close >>>> >>> really makes the API more fluent and modern IMO. >>>> >>> >>>> >>> Also to be fully SE I guess provider() method >>>> would be needed even if >>>> >>> optional (SPI usage by default): >>>> >>> >>>> >>> try (CDIContainer container = >>>> >>> >>>> >>> >>>> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider").newCDIContainer()) >>>> >>> { >>>> >>> CDI.current().getBeanManager().... >>>> >>> } >>>> >>> >>>> >>> Finally I think having a kind of getInstance >>>> shortcut could be a plus for >>>> >>> SE: >>>> >>> >>>> >>> try (CDIContainer container = >>>> CDIContainer.newCDIContainer()) { >>>> >>> container.newInstance(MyAppRunner.class /* >>>> optional qualifiers */ >>>> >>> ).run(args); >>>> >>> } >>>> >>> >>>> >>> Using container to get an instance would create >>>> the instance and bind >>>> >>> it to the container lifecycle (mainly for >>>> predestroy) avoiding this >>>> >>> boilerplate code in all main which will surely >>>> only be used to launch >>>> >>> a soft. >>>> >>> >>>> >>> wdyt? >>>> >>> >>>> >>> >>>> >>> >>>> >>> Romain Manni-Bucau >>>> >>> @rmannibucau >>>> >>> http://www.tomitribe.com >>>> >>> http://rmannibucau.wordpress.com >>>> >>> https://github.com/rmannibucau >>>> >>> >>>> >>> >>>> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger >>>> >: >>>> >>>> >>>> >>>> Comments inline >>>> >>>> >>>> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: >>>> >>>> >>>> >>>> Sorry Jozef, your email fell into the pits of >>>> google inbox's "smart >>>> >>>> sorting" >>>> >>>> features. >>>> >>>> >>>> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef >>>> Hartinger >>> > >>>> >>>> wrote: >>>> >>>>> >>>> >>>>> Hi John, comments inline: >>>> >>>>> >>>> >>>>> >>>> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >>>> >>>>> >>>> >>>>> Jozef, >>>> >>>>> >>>> >>>>> Most of what you see there is taken from the >>>> original doc, since >>>> >>>>> everyone >>>> >>>>> seemed to be in agreement. I think the map >>>> is just a safeguard in case >>>> >>>>> of >>>> >>>>> additional boot options available in some >>>> implementations (e.g. I think >>>> >>>>> OWB/OpenEJB have some options.. currently >>>> OpenEJB supports an embedded >>>> >>>>> CDI >>>> >>>>> boot mode). >>>> >>>>> >>>> >>>>> No, I am fine with the map. What I am >>>> questioning is the type of the >>>> >>>>> map. >>>> >>>>> Usually, data structures with a similar >>>> purpose use Strings as their >>>> >>>>> keys. >>>> >>>>> This applies to ServletContext attributes, >>>> InvocationContext data, >>>> >>>>> Servlet >>>> >>>>> request/session attributes and others. I am >>>> therefore wondering whether >>>> >>>>> there is a usecase for the proposed unbound >>>> key signature or not. >>>> >>>> >>>> >>>> >>>> >>>> I think that's more of a placeholder, I was >>>> assuming it would be >>>> >>>> Map once we clarify everything. >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> We spoke a few times about BeanManager vs >>>> CDI. BeanManager was >>>> >>>>> preferable >>>> >>>>> since there's no easy way to get the the >>>> instance, CDI is easier to get >>>> >>>>> and >>>> >>>>> more aligned with how you would get it. >>>> Usually people expect the >>>> >>>>> BeanManager to be injected or available via >>>> JNDI, neither would be the >>>> >>>>> case >>>> >>>>> here. >>>> >>>>> >>>> >>>>> If CDI 2.0 targets Java SE then this >>>> container initialization API will >>>> >>>>> become something that ordinary application >>>> developers use to start/stop >>>> >>>>> CDI >>>> >>>>> in their applications. It therefore cannot be >>>> considered an SPI but >>>> >>>>> instead >>>> >>>>> should be something easy to use. On the other >>>> hand, BeanManager is >>>> >>>>> definitely an SPI. It is used in extension, >>>> frameworks and generally >>>> >>>>> for >>>> >>>>> integration. Not much by applications >>>> directly. Therefore, I don't see >>>> >>>>> how >>>> >>>>> the container bootstrap API and BeanManager >>>> fit together. IMO the >>>> >>>>> bootstrap >>>> >>>>> API should expose something that makes common >>>> tasks (obtaining a >>>> >>>>> contextual >>>> >>>>> reference and firing and event) easy, which >>>> the CDI class does. >>>> >>>>> >>>> >>>>> Plus do not forget that BeanManager can be >>>> obtained easily using >>>> >>>>> CDI.getBeanManager(). >>>> >>>> >>>> >>>> >>>> >>>> I'm not disagreeing. There's a few things I'd >>>> consider: >>>> >>>> >>>> >>>> - Is this mostly for new apps or existing? If >>>> existing, it's probably >>>> >>>> using >>>> >>>> some internal API, if new it can use whatever >>>> API we give. >>>> >>>> - I don't want to return void, we should give >>>> some kind of reference >>>> >>>> into >>>> >>>> the container when we're done booting. >>>> >>>> >>>> >>>> Agreed, we should not be returning void. >>>> >>>> >>>> >>>> - CDI is a one step retrievable reference, >>>> where as BeanManager is a two >>>> >>>> step reference. With that said, BeanManager >>>> makes more sense to return >>>> >>>> here. Another thought could be we invent some >>>> new class that has both, >>>> >>>> but >>>> >>>> that's really redundant. >>>> >>>> >>>> >>>> Why do you think BeanManager makes more sense >>>> here? Especially given the >>>> >>>> assumption that application code is going to >>>> call this init/shutdown >>>> >>>> API, I >>>> >>>> don't see BeanManager as making more sense. >>>> >>>> >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> Yes, this is the container start API. Sounds >>>> like you have some good >>>> >>>>> ideas for things like XML configuration or >>>> programmatic configuration, >>>> >>>>> both >>>> >>>>> of which are being tracked under separate >>>> tickets. One idea might be >>>> >>>>> for an >>>> >>>>> optional param in the map to control packages >>>> to scan/ignore, in that >>>> >>>>> map. >>>> >>>>> >>>> >>>>> I am wondering whether this configuration >>>> should be something optional >>>> >>>>> built on top of the bootstrap API or whether >>>> we should consider making >>>> >>>>> it >>>> >>>>> mandatory. Either way, we cannot add the >>>> bootstrap API to the spec >>>> >>>>> without >>>> >>>>> explicitly defining how it behaves. My >>>> implicit assumption of the >>>> >>>>> proposal >>>> >>>>> is that the container is supposed to scan the >>>> entire classpath for >>>> >>>>> explicit >>>> >>>>> or implicit bean archives (including e.g. >>>> rt.jar), discover beans, fire >>>> >>>>> extensions, etc. This worries me as this >>>> default behavior is far from >>>> >>>>> being >>>> >>>>> lightweight, which CDI for Java SE initially >>>> aimed to be. >>>> >>>> >>>> >>>> >>>> >>>> Yes, the spec must be updated to reflect the >>>> behavior of SE mode. I >>>> >>>> plan to >>>> >>>> get that completely into the google doc before >>>> opening any spec changes >>>> >>>> in a >>>> >>>> PR. >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> We didn't want to over load the CDI >>>> interface. It already does a lot. >>>> >>>>> This is really SPI code, CDI even though it's >>>> in the spi package is >>>> >>>>> used in >>>> >>>>> a lot of application code. >>>> >>>>> >>>> >>>>> I would personally prefer to have it all in >>>> one place. Having >>>> >>>>> CDIContainer, CDIContainerLoader, CDI and >>>> CDIProvider makes it more >>>> >>>>> difficult to know when to use what. >>>> >>>> >>>> >>>> >>>> >>>> The problem is that most CDI (the interface) >>>> operations are against a >>>> >>>> running container. I think we spoke about >>>> leveraging CDIProvider at one >>>> >>>> point (in fact, I mistakenly called >>>> CDIContainer CDIProvider not even >>>> >>>> realizing it was there). I doubt that most >>>> app developers use it >>>> >>>> currently, >>>> >>>> there's not even a way to get a reference to >>>> it that I'm aware of. It's >>>> >>>> used by the implementor only. >>>> >>>> >>>> >>>> I don't think there's a conflict. CDI class >>>> would still only provide >>>> >>>> methods >>>> >>>> to be run against a running container. The >>>> difference is that there >>>> >>>> would be >>>> >>>> additional static methods to get this running >>>> container (CDI class) to >>>> >>>> you >>>> >>>> by starting the container. >>>> >>>> >>>> >>>> Either way, I agree that reusing CDIProvider >>>> is a must. There is no >>>> >>>> reason >>>> >>>> to define a new class for the same purpose. >>>> >>>> >>>> >>>> >>>> >>>> I expect that my changes in the CDI spec >>>> around this will state, along >>>> >>>> the >>>> >>>> lines of: >>>> >>>> >>>> >>>> To retrieve a CDIContainer to launch, do this: >>>> >>>> >>>> >>>> CDIContainer container = >>>> CDIContainerLocator.getCDIContainer(); >>>> >>>> container.initialize(); >>>> >>>> ... do work >>>> >>>> >>>> >>>> Once you want to shutdown the container, do this: >>>> >>>> >>>> >>>> container.shutdown(); >>>> >>>> >>>> >>>> (we may want to consider implementing >>>> AutoCloseable, an oversight on my >>>> >>>> part) >>>> >>>> >>>> >>>> and then later on >>>> >>>> >>>> >>>> - What happens if I call CDIContainerLocator >>>> in an app server >>>> >>>> >>>> >>>> - It throws an IllegalStateException. >>>> >>>> >>>> >>>> - The container provides no beans of type >>>> CDIContainer, it is managed >>>> >>>> outside of the CDI container. >>>> >>>> >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> John >>>> >>>>> >>>> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef >>>> Hartinger >>> > >>>> >>>>> wrote: >>>> >>>>>> >>>> >>>>>> Hi John, some thoughts: >>>> >>>>>> >>>> >>>>>> - instead of using BeanManager it makes more >>>> sense to me to return a >>>> >>>>>> CDI >>>> >>>>>> instance, which is a more user-friendly API >>>> (and it also exposes >>>> >>>>>> access to >>>> >>>>>> BeanManager) >>>> >>>>>> - is there a usecase for arbitrary keys of >>>> the "params" map or is >>>> >>>>>> Map sufficient? >>>> >>>>>> - if we could move the shutdown() method >>>> from CDIContainer to the >>>> >>>>>> actual >>>> >>>>>> container handle that we obtain from >>>> initialize(), that would look >>>> >>>>>> more >>>> >>>>>> object-oriented >>>> >>>>>> - what exactly is initialize() supposed to >>>> do? Is it supposed to start >>>> >>>>>> scanning the entire classpath for CDI beans? >>>> That could be a problem >>>> >>>>>> especially with spring-boot-like fat jars. I >>>> think we need an API to >>>> >>>>>> tell >>>> >>>>>> the container which classes / packages to >>>> consider. Something like >>>> >>>>>> Guice's >>>> >>>>>> binding API perhaps? >>>> >>>>>> >>>> >>>>>> - the proposal makes me wonder whether >>>> retrofitting this functionality >>>> >>>>>> to >>>> >>>>>> the CDI class wouldn't be a better option. >>>> It could look like: >>>> >>>>>> >>>> >>>>>> CDI container = CDI.initialize(); >>>> >>>>>> container.select(Foo.class).get(); >>>> >>>>>> container.shutdown(); >>>> >>>>>> >>>> >>>>>> compare it to: >>>> >>>>>> >>>> >>>>>> CDIContainer container = CDIContainerLoader. >>>> getCDIContainer(); >>>> >>>>>> BeanManager manager = container.initialize(); >>>> >>>>>> manager.getBeans(...); >>>> >>>>>> container.shutdown(manager); >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >>>> >>>>>> >>>> >>>>>> All, >>>> >>>>>> >>>> >>>>>> I have the updated API here, and wanted to >>>> solicit any final feedback >>>> >>>>>> before updating the google doc and spec pages. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c >>>> >>>>>> >>>> >>>>>> Let me know your thoughts. >>>> >>>>>> >>>> >>>>>> Thanks, >>>> >>>>>> >>>> >>>>>> John >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> _______________________________________________ >>>> >>>>>> cdi-dev mailing list >>>> >>>>>> cdi-dev at lists.jboss.org >>>> >>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>>>> >>>> >>>>>> Note that for all code provided on this >>>> list, the provider licenses >>>> >>>>>> the >>>> >>>>>> code under the Apache License, Version 2 >>>> >>>>>> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). >>>> For all other ideas >>>> >>>>>> provided on this list, the provider waives >>>> all patent and other >>>> >>>>>> intellectual >>>> >>>>>> property rights inherent in such information. >>>> >>>>>> >>>> >>>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> cdi-dev mailing list >>>> >>>> cdi-dev at lists.jboss.org >>>> >>>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> >>>> >>>> Note that for all code provided on this list, >>>> the provider licenses the >>>> >>>> code >>>> >>>> under the Apache License, Version 2 >>>> >>>> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). >>>> For all other ideas >>>> >>>> provided on this list, the provider waives all >>>> patent and other >>>> >>>> intellectual >>>> >>>> property rights inherent in such information. >>>> >> >>>> >> >>>> > >>>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/afbcaec4/attachment-0001.html From rmannibucau at gmail.com Wed Mar 4 09:48:31 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 4 Mar 2015 15:48:31 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: <54F71AD7.7080003@redhat.com> References: <54DB1F2B.1020609@redhat.com> <54DC61D9.701@redhat.com> <54EECC20.6040600@redhat.com> <54EF396E.20805@redhat.com> <54F01720.3080802@redhat.com> <54F6CACD.6080507@redhat.com> <54F6FDF2.3000808@redhat.com> <54F701BB.9050209@redhat.com> <54F71AD7.7080003@redhat.com> Message-ID: Sure but since the path from main(String[]) to CDI is actually this one it can be the solution. This is not the general way to use CDI but the way to enter CDI for me, then you simply use @Inject. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-03-04 15:46 GMT+01:00 Jozef Hartinger : > Sure, I am not saying Unmanaged should not be used at all. Under given > circumstances it makes sense to use Unmanaged. I however don't think it > fits as the general recommended way of using CDI in SE because if a given > class is a bean already, the managed instance should be obtained instead of > creating an unmanaged instance. > > > On 03/04/2015 02:04 PM, Romain Manni-Bucau wrote: > > Your definition seems to fit the standalone need: libraries = not CDI > based code (case of a standalone), the runner class (Mymain) doesnt have to > be a CDI bean but has to get injections to launch the CDI code. > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2015-03-04 13:59 GMT+01:00 Jozef Hartinger : > >> UnmanagedInstance is provided to make it easier for libraries to perform >> dependency injection on classes that are for some reason not CDI beans. It >> should not be a substitute for lookup of CDI beans. Therefore, I do not see >> UnmanagedInstance fitting here. >> >> >> On 03/04/2015 01:47 PM, Romain Manni-Bucau wrote: >> >> Hmm >> >> I think one of the main point I try to push is we have a bunch of API >> to do it already, if we need yet another API to do the same we have several >> choices: >> - we love creating APIs >> - all previous APIs are failures and should be deprecated or fixed >> - there is a full mismatch with embedded and EE case (but we have >> existing proofs it is not the case) >> >> I think we should help user to not be lost between all APIs and I >> strongly believe we can't do anything on container to lookup beans >> (EJBContainer#getContext was a try which is close to it but it actually >> just limited user experience compared to existing solutions). >> >> What's the issue with UnmanagedInstance? >> >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> 2015-03-04 13:43 GMT+01:00 Jozef Hartinger : >> >>> The only argument I found supporting a strict separation of those two >>> APIs is that it makes it easier to control when a user should or should not >>> use boot (i.e. it should not be used in EE for example). >>> >>> That's a good argument. It's not however necessarily only achieved by >>> two separate interfaces but can be as well be achieved with a subclass, e.g: >>> - CDI for runtime operations only >>> - StartedCDI extends CDI (or CDIContainer or whatever - the name does >>> not matter at this point) for runtime operations + shutdown. >>> >>> Normally, CDI is available only. The boot API however would return >>> StartedCDI thus allowing a user to shutdown what they started. >>> >>> >>> >>> On 03/04/2015 12:24 PM, John D. Ament wrote: >>> >>> This is actually based on what we discussed in one of the EG meetings >>> >>> >>> http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-01-14-17.04.log.html >>> >>> John >>> >>> On Wed, Mar 4, 2015 at 4:05 AM Jozef Hartinger >>> wrote: >>> >>>> Well it's nowhere given that we must have two separate interfaces for >>>> this. We can combine the start/stop API with the existing one to provide an >>>> application with a single reference representing the CDI container. >>>> >>>> >>>> On 02/28/2015 07:05 PM, John D. Ament wrote: >>>> >>>> Maybe I'm misreading, but I don't see us adding another API to do the >>>> same thing here - we're introducing new functionality. >>>> >>>> CDIContainer/Loader on startup/shutdown of the application >>>> >>>> CDI for runtime usage within the application to interact with the >>>> container. >>>> >>>> John >>>> >>>> On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau < >>>> rmannibucau at gmail.com> wrote: >>>> >>>>> sure I fully agree excepted I think introducing yet another API to do >>>>> the same thing is not good so super tempting to skip it and wait for >>>>> feedbacks rather than introducing it eagerly. >>>>> >>>>> >>>>> Romain Manni-Bucau >>>>> @rmannibucau >>>>> http://www.tomitribe.com >>>>> http://rmannibucau.wordpress.com >>>>> https://github.com/rmannibucau >>>>> >>>>> >>>>> 2015-02-27 8:05 GMT+01:00 Jozef Hartinger : >>>>> > My point is that from the application perspective, the user obtains >>>>> one >>>>> > container handle for eventual shutdown (CDIContainer) and then looks >>>>> up a >>>>> > different container handle (CDI) that they can use for real work >>>>> (lookup / >>>>> > event dispatch / etc.) It would be cleaner if the container gave >>>>> away a >>>>> > single handle that can do all of that. >>>>> > >>>>> > >>>>> > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: >>>>> > >>>>> > Not sure I get how a CDI instance can help. >>>>> > >>>>> > But container.getBeanManager() sounds nice is not a shortcut for >>>>> > CDI.current().getBm() otherwise it looks like duplication to me. >>>>> > >>>>> > Can we make container not contextual - dont think so? If so it makes >>>>> sense >>>>> > otherwise I fear it doesnt add much. >>>>> > >>>>> > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" a >>>>> ?crit : >>>>> >> >>>>> >> I like the initialize + close() combination and the >>>>> try-with-resources >>>>> >> usage. >>>>> >> What looks weird to me is that at line one you obtain a container >>>>> handle: >>>>> >> >>>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>>> >> CDI.current().getBeanManager() ... >>>>> >> >>>>> >> and then at line two you call a static method to perform a container >>>>> >> lookup :-/ >>>>> >> >>>>> >> An API that allows you to use the container handle you already got >>>>> is way >>>>> >> better IMO, e.g.: >>>>> >> >>>>> >> try (CDIContainer container = CDIContainer.newCDIContai... >>>>> >> container.getBeanManager() >>>>> >> >>>>> >> If CDIContainer.newCDIContainer() returns an CDI instance or its >>>>> subclass, >>>>> >> we get this easily. >>>>> >> >>>>> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: >>>>> >>> >>>>> >>> Hi guys >>>>> >>> >>>>> >>> why note keeping it simple? >>>>> >>> >>>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer(/* >>>>> optional >>>>> >>> map to configure vendor features */)) { >>>>> >>> CDI.current().getBeanManager().... >>>>> >>> } >>>>> >>> >>>>> >>> Not sure the point having initialize() + having shutdown = close >>>>> >>> really makes the API more fluent and modern IMO. >>>>> >>> >>>>> >>> Also to be fully SE I guess provider() method would be needed even >>>>> if >>>>> >>> optional (SPI usage by default): >>>>> >>> >>>>> >>> try (CDIContainer container = >>>>> >>> >>>>> >>> >>>>> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider").newCDIContainer()) >>>>> >>> { >>>>> >>> CDI.current().getBeanManager().... >>>>> >>> } >>>>> >>> >>>>> >>> Finally I think having a kind of getInstance shortcut could be a >>>>> plus for >>>>> >>> SE: >>>>> >>> >>>>> >>> try (CDIContainer container = CDIContainer.newCDIContainer()) { >>>>> >>> container.newInstance(MyAppRunner.class /* optional >>>>> qualifiers */ >>>>> >>> ).run(args); >>>>> >>> } >>>>> >>> >>>>> >>> Using container to get an instance would create the instance and >>>>> bind >>>>> >>> it to the container lifecycle (mainly for predestroy) avoiding this >>>>> >>> boilerplate code in all main which will surely only be used to >>>>> launch >>>>> >>> a soft. >>>>> >>> >>>>> >>> wdyt? >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> Romain Manni-Bucau >>>>> >>> @rmannibucau >>>>> >>> http://www.tomitribe.com >>>>> >>> http://rmannibucau.wordpress.com >>>>> >>> https://github.com/rmannibucau >>>>> >>> >>>>> >>> >>>>> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger : >>>>> >>>> >>>>> >>>> Comments inline >>>>> >>>> >>>>> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: >>>>> >>>> >>>>> >>>> Sorry Jozef, your email fell into the pits of google inbox's >>>>> "smart >>>>> >>>> sorting" >>>>> >>>> features. >>>>> >>>> >>>>> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger < >>>>> jharting at redhat.com> >>>>> >>>> wrote: >>>>> >>>>> >>>>> >>>>> Hi John, comments inline: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >>>>> >>>>> >>>>> >>>>> Jozef, >>>>> >>>>> >>>>> >>>>> Most of what you see there is taken from the original doc, since >>>>> >>>>> everyone >>>>> >>>>> seemed to be in agreement. I think the map is just a safeguard >>>>> in case >>>>> >>>>> of >>>>> >>>>> additional boot options available in some implementations (e.g. >>>>> I think >>>>> >>>>> OWB/OpenEJB have some options.. currently OpenEJB supports an >>>>> embedded >>>>> >>>>> CDI >>>>> >>>>> boot mode). >>>>> >>>>> >>>>> >>>>> No, I am fine with the map. What I am questioning is the type of >>>>> the >>>>> >>>>> map. >>>>> >>>>> Usually, data structures with a similar purpose use Strings as >>>>> their >>>>> >>>>> keys. >>>>> >>>>> This applies to ServletContext attributes, InvocationContext >>>>> data, >>>>> >>>>> Servlet >>>>> >>>>> request/session attributes and others. I am therefore wondering >>>>> whether >>>>> >>>>> there is a usecase for the proposed unbound key signature or not. >>>>> >>>> >>>>> >>>> >>>>> >>>> I think that's more of a placeholder, I was assuming it would be >>>>> >>>> Map once we clarify everything. >>>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> We spoke a few times about BeanManager vs CDI. BeanManager was >>>>> >>>>> preferable >>>>> >>>>> since there's no easy way to get the the instance, CDI is easier >>>>> to get >>>>> >>>>> and >>>>> >>>>> more aligned with how you would get it. Usually people expect >>>>> the >>>>> >>>>> BeanManager to be injected or available via JNDI, neither would >>>>> be the >>>>> >>>>> case >>>>> >>>>> here. >>>>> >>>>> >>>>> >>>>> If CDI 2.0 targets Java SE then this container initialization >>>>> API will >>>>> >>>>> become something that ordinary application developers use to >>>>> start/stop >>>>> >>>>> CDI >>>>> >>>>> in their applications. It therefore cannot be considered an SPI >>>>> but >>>>> >>>>> instead >>>>> >>>>> should be something easy to use. On the other hand, BeanManager >>>>> is >>>>> >>>>> definitely an SPI. It is used in extension, frameworks and >>>>> generally >>>>> >>>>> for >>>>> >>>>> integration. Not much by applications directly. Therefore, I >>>>> don't see >>>>> >>>>> how >>>>> >>>>> the container bootstrap API and BeanManager fit together. IMO the >>>>> >>>>> bootstrap >>>>> >>>>> API should expose something that makes common tasks (obtaining a >>>>> >>>>> contextual >>>>> >>>>> reference and firing and event) easy, which the CDI class does. >>>>> >>>>> >>>>> >>>>> Plus do not forget that BeanManager can be obtained easily using >>>>> >>>>> CDI.getBeanManager(). >>>>> >>>> >>>>> >>>> >>>>> >>>> I'm not disagreeing. There's a few things I'd consider: >>>>> >>>> >>>>> >>>> - Is this mostly for new apps or existing? If existing, it's >>>>> probably >>>>> >>>> using >>>>> >>>> some internal API, if new it can use whatever API we give. >>>>> >>>> - I don't want to return void, we should give some kind of >>>>> reference >>>>> >>>> into >>>>> >>>> the container when we're done booting. >>>>> >>>> >>>>> >>>> Agreed, we should not be returning void. >>>>> >>>> >>>>> >>>> - CDI is a one step retrievable reference, where as BeanManager >>>>> is a two >>>>> >>>> step reference. With that said, BeanManager makes more sense to >>>>> return >>>>> >>>> here. Another thought could be we invent some new class that has >>>>> both, >>>>> >>>> but >>>>> >>>> that's really redundant. >>>>> >>>> >>>>> >>>> Why do you think BeanManager makes more sense here? Especially >>>>> given the >>>>> >>>> assumption that application code is going to call this >>>>> init/shutdown >>>>> >>>> API, I >>>>> >>>> don't see BeanManager as making more sense. >>>>> >>>> >>>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Yes, this is the container start API. Sounds like you have some >>>>> good >>>>> >>>>> ideas for things like XML configuration or programmatic >>>>> configuration, >>>>> >>>>> both >>>>> >>>>> of which are being tracked under separate tickets. One idea >>>>> might be >>>>> >>>>> for an >>>>> >>>>> optional param in the map to control packages to scan/ignore, in >>>>> that >>>>> >>>>> map. >>>>> >>>>> >>>>> >>>>> I am wondering whether this configuration should be something >>>>> optional >>>>> >>>>> built on top of the bootstrap API or whether we should consider >>>>> making >>>>> >>>>> it >>>>> >>>>> mandatory. Either way, we cannot add the bootstrap API to the >>>>> spec >>>>> >>>>> without >>>>> >>>>> explicitly defining how it behaves. My implicit assumption of the >>>>> >>>>> proposal >>>>> >>>>> is that the container is supposed to scan the entire classpath >>>>> for >>>>> >>>>> explicit >>>>> >>>>> or implicit bean archives (including e.g. rt.jar), discover >>>>> beans, fire >>>>> >>>>> extensions, etc. This worries me as this default behavior is far >>>>> from >>>>> >>>>> being >>>>> >>>>> lightweight, which CDI for Java SE initially aimed to be. >>>>> >>>> >>>>> >>>> >>>>> >>>> Yes, the spec must be updated to reflect the behavior of SE >>>>> mode. I >>>>> >>>> plan to >>>>> >>>> get that completely into the google doc before opening any spec >>>>> changes >>>>> >>>> in a >>>>> >>>> PR. >>>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> We didn't want to over load the CDI interface. It already does >>>>> a lot. >>>>> >>>>> This is really SPI code, CDI even though it's in the spi package >>>>> is >>>>> >>>>> used in >>>>> >>>>> a lot of application code. >>>>> >>>>> >>>>> >>>>> I would personally prefer to have it all in one place. Having >>>>> >>>>> CDIContainer, CDIContainerLoader, CDI and CDIProvider makes it >>>>> more >>>>> >>>>> difficult to know when to use what. >>>>> >>>> >>>>> >>>> >>>>> >>>> The problem is that most CDI (the interface) operations are >>>>> against a >>>>> >>>> running container. I think we spoke about leveraging CDIProvider >>>>> at one >>>>> >>>> point (in fact, I mistakenly called CDIContainer CDIProvider not >>>>> even >>>>> >>>> realizing it was there). I doubt that most app developers use it >>>>> >>>> currently, >>>>> >>>> there's not even a way to get a reference to it that I'm aware >>>>> of. It's >>>>> >>>> used by the implementor only. >>>>> >>>> >>>>> >>>> I don't think there's a conflict. CDI class would still only >>>>> provide >>>>> >>>> methods >>>>> >>>> to be run against a running container. The difference is that >>>>> there >>>>> >>>> would be >>>>> >>>> additional static methods to get this running container (CDI >>>>> class) to >>>>> >>>> you >>>>> >>>> by starting the container. >>>>> >>>> >>>>> >>>> Either way, I agree that reusing CDIProvider is a must. There is >>>>> no >>>>> >>>> reason >>>>> >>>> to define a new class for the same purpose. >>>>> >>>> >>>>> >>>> >>>>> >>>> I expect that my changes in the CDI spec around this will state, >>>>> along >>>>> >>>> the >>>>> >>>> lines of: >>>>> >>>> >>>>> >>>> To retrieve a CDIContainer to launch, do this: >>>>> >>>> >>>>> >>>> CDIContainer container = CDIContainerLocator.getCDIContainer(); >>>>> >>>> container.initialize(); >>>>> >>>> ... do work >>>>> >>>> >>>>> >>>> Once you want to shutdown the container, do this: >>>>> >>>> >>>>> >>>> container.shutdown(); >>>>> >>>> >>>>> >>>> (we may want to consider implementing AutoCloseable, an oversight >>>>> on my >>>>> >>>> part) >>>>> >>>> >>>>> >>>> and then later on >>>>> >>>> >>>>> >>>> - What happens if I call CDIContainerLocator in an app server >>>>> >>>> >>>>> >>>> - It throws an IllegalStateException. >>>>> >>>> >>>>> >>>> - The container provides no beans of type CDIContainer, it is >>>>> managed >>>>> >>>> outside of the CDI container. >>>>> >>>> >>>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> John >>>>> >>>>> >>>>> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger < >>>>> jharting at redhat.com> >>>>> >>>>> wrote: >>>>> >>>>>> >>>>> >>>>>> Hi John, some thoughts: >>>>> >>>>>> >>>>> >>>>>> - instead of using BeanManager it makes more sense to me to >>>>> return a >>>>> >>>>>> CDI >>>>> >>>>>> instance, which is a more user-friendly API (and it also exposes >>>>> >>>>>> access to >>>>> >>>>>> BeanManager) >>>>> >>>>>> - is there a usecase for arbitrary keys of the "params" map or >>>>> is >>>>> >>>>>> Map sufficient? >>>>> >>>>>> - if we could move the shutdown() method from CDIContainer to >>>>> the >>>>> >>>>>> actual >>>>> >>>>>> container handle that we obtain from initialize(), that would >>>>> look >>>>> >>>>>> more >>>>> >>>>>> object-oriented >>>>> >>>>>> - what exactly is initialize() supposed to do? Is it supposed >>>>> to start >>>>> >>>>>> scanning the entire classpath for CDI beans? That could be a >>>>> problem >>>>> >>>>>> especially with spring-boot-like fat jars. I think we need an >>>>> API to >>>>> >>>>>> tell >>>>> >>>>>> the container which classes / packages to consider. Something >>>>> like >>>>> >>>>>> Guice's >>>>> >>>>>> binding API perhaps? >>>>> >>>>>> >>>>> >>>>>> - the proposal makes me wonder whether retrofitting this >>>>> functionality >>>>> >>>>>> to >>>>> >>>>>> the CDI class wouldn't be a better option. It could look like: >>>>> >>>>>> >>>>> >>>>>> CDI container = CDI.initialize(); >>>>> >>>>>> container.select(Foo.class).get(); >>>>> >>>>>> container.shutdown(); >>>>> >>>>>> >>>>> >>>>>> compare it to: >>>>> >>>>>> >>>>> >>>>>> CDIContainer container = CDIContainerLoader. getCDIContainer(); >>>>> >>>>>> BeanManager manager = container.initialize(); >>>>> >>>>>> manager.getBeans(...); >>>>> >>>>>> container.shutdown(manager); >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >>>>> >>>>>> >>>>> >>>>>> All, >>>>> >>>>>> >>>>> >>>>>> I have the updated API here, and wanted to solicit any final >>>>> feedback >>>>> >>>>>> before updating the google doc and spec pages. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c >>>>> >>>>>> >>>>> >>>>>> Let me know your thoughts. >>>>> >>>>>> >>>>> >>>>>> Thanks, >>>>> >>>>>> >>>>> >>>>>> John >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> _______________________________________________ >>>>> >>>>>> cdi-dev mailing list >>>>> >>>>>> cdi-dev at lists.jboss.org >>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>>> >>>>> >>>>>> Note that for all code provided on this list, the provider >>>>> licenses >>>>> >>>>>> the >>>>> >>>>>> code under the Apache License, Version 2 >>>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all >>>>> other ideas >>>>> >>>>>> provided on this list, the provider waives all patent and other >>>>> >>>>>> intellectual >>>>> >>>>>> property rights inherent in such information. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>> >>>>> >>>> _______________________________________________ >>>>> >>>> cdi-dev mailing list >>>>> >>>> cdi-dev at lists.jboss.org >>>>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>> >>>>> >>>> Note that for all code provided on this list, the provider >>>>> licenses the >>>>> >>>> code >>>>> >>>> under the Apache License, Version 2 >>>>> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>>>> ideas >>>>> >>>> provided on this list, the provider waives all patent and other >>>>> >>>> intellectual >>>>> >>>> property rights inherent in such information. >>>>> >> >>>>> >> >>>>> > >>>>> >>>> >>>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/f3fd5ef7/attachment-0001.html From antoine at sabot-durand.net Wed Mar 4 11:53:30 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 4 Mar 2015 17:53:30 +0100 Subject: [cdi-dev] Feedback - CDI bootstrap API (CDI-26) In-Reply-To: References: Message-ID: > Le 4 mars 2015 ? 12:29, John D. Ament a ?crit : > > Hmm.. comments in line. > > On Wed, Mar 4, 2015 at 4:49 AM Antoine Sabot-Durand > wrote: > Hi John, > > I think it could be a good idea to write down all of these to have a more stable doc for discussion. You should update the google doc with the result of this discussion. > > I agree with the following points in this thread : > > - Minimize the number of new Class / Interface. CDI and CDIProvider usage is still not very clear for end user so we should add the strict minimum and try to enhance existing API / SPI when possible > > It seems odd to me that we're rehashing decisions made during the EG meetings. Not putting it in CDI was discussed in several meetings at the beginning of the year, and it seemed like the agreement was putting it in CDI was a bad idea. You misread me : I didn?t write that we should use CDI, I wrote that we should add as few new classes / interfaces as possible. Jozef proposed some idea with CDIProvider. > > - Be able to bootstrap CDI without returning BeanManager (env if the API give possibility to access it if needed). End user don?t need that : CDI app can start with an observer for instance > > Agreed, but I think we need to provide some entry point to allow those who aren't comfortable with programming with events to leverage it. Returning the CDI instance makes that easier to do than returning the BeanManager. Yes that?s why I wrote ?even if the API give possibility to access it?. CDI is a good choice as a return type IMO. > > > Something not dealt with but that we should keep in mind : > - Providing a Java SE solution that could be easily used for a servlet bootstrap of CDI. I don?t know if we?ll standardize this but we definitely should keep this use case in mind > > and my bonus, it?s out of scope but I didn?t see anytime there that prevent this nice to have: > - support the possibility to boot multiple BeanManager in Java SE. > > > We talked about this one as well on the EG, either this year or late last year. I thought the decision at that time was that we wouldn't allow multiple containers at once in SE. We talked about it but I don?t remember a strong decision. > > Antoine > > >> Le 1 mars 2015 ? 15:13, John D. Ament > a ?crit : > >> >> So, I think I've gathered enough feedback at this point, and seen some of the API changes. I'll hopefully be including some doc changes this week, but one question - do we want to start the SE specific stuff as its own asciidoc file? >> >> Changes made: >> >> - Changed return value to CDI to provide better capability out of the box. >> - Added AutoCloseable to CDIContainer, provided default implementation of calling shutdown. >> - Added synchronization support to the method body that retrieves the singleton instance (BTW, I'm not sure if this is even useful TBH as each impl, including the RI, needs to provide this class in its own format). >> - Made the params map typed to >> >> @Romain Your case isn't really supportable yet, until we have static injection support. You'd still have to have a managed version of Runner to work against. >> >> John >> >> On Sat, Feb 28, 2015 at 4:11 PM Romain Manni-Bucau > wrote: >> Yes but not the way to get an instance. Even Unmanaged does it. >> >> What can be awesome is to have static inject for it: >> >> public class Runner { >> >> @Inject >> private static MyMain main; >> >> public static void main(String[] arg) { >> try (CDIContainer c = CDIContainer.newContainer()) { >> main.doWork(); >> } >> } >> >> } >> >> And not a single additional line :). >> >> Le 28 f?vr. 2015 19:05, "John D. Ament" > a ?crit : >> >> Maybe I'm misreading, but I don't see us adding another API to do the same thing here - we're introducing new functionality. >> >> CDIContainer/Loader on startup/shutdown of the application >> >> CDI for runtime usage within the application to interact with the container. >> >> John >> >> On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau > wrote: >> sure I fully agree excepted I think introducing yet another API to do >> the same thing is not good so super tempting to skip it and wait for >> feedbacks rather than introducing it eagerly. >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-02-27 8:05 GMT+01:00 Jozef Hartinger >: >> > My point is that from the application perspective, the user obtains one >> > container handle for eventual shutdown (CDIContainer) and then looks up a >> > different container handle (CDI) that they can use for real work (lookup / >> > event dispatch / etc.) It would be cleaner if the container gave away a >> > single handle that can do all of that. >> > >> > >> > On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote: >> > >> > Not sure I get how a CDI instance can help. >> > >> > But container.getBeanManager() sounds nice is not a shortcut for >> > CDI.current().getBm() otherwise it looks like duplication to me. >> > >> > Can we make container not contextual - dont think so? If so it makes sense >> > otherwise I fear it doesnt add much. >> > >> > Le 26 f?vr. 2015 16:19, "Jozef Hartinger" > a ?crit : >> >> >> >> I like the initialize + close() combination and the try-with-resources >> >> usage. >> >> What looks weird to me is that at line one you obtain a container handle: >> >> >> >> try (CDIContainer container = CDIContainer.newCDIContai... >> >> CDI.current().getBeanManager() ... >> >> >> >> and then at line two you call a static method to perform a container >> >> lookup :-/ >> >> >> >> An API that allows you to use the container handle you already got is way >> >> better IMO, e.g.: >> >> >> >> try (CDIContainer container = CDIContainer.newCDIContai... >> >> container.getBeanManager() >> >> >> >> If CDIContainer.newCDIContainer() returns an CDI instance or its subclass, >> >> we get this easily. >> >> >> >> On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote: >> >>> >> >>> Hi guys >> >>> >> >>> why note keeping it simple? >> >>> >> >>> try (CDIContainer container = CDIContainer.newCDIContainer(/* optional >> >>> map to configure vendor features */)) { >> >>> CDI.current().getBeanManager().... >> >>> } >> >>> >> >>> Not sure the point having initialize() + having shutdown = close >> >>> really makes the API more fluent and modern IMO. >> >>> >> >>> Also to be fully SE I guess provider() method would be needed even if >> >>> optional (SPI usage by default): >> >>> >> >>> try (CDIContainer container = >> >>> >> >>> CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider").newCDIContainer()) >> >>> { >> >>> CDI.current().getBeanManager().... >> >>> } >> >>> >> >>> Finally I think having a kind of getInstance shortcut could be a plus for >> >>> SE: >> >>> >> >>> try (CDIContainer container = CDIContainer.newCDIContainer()) { >> >>> container.newInstance(MyAppRunner.class /* optional qualifiers */ >> >>> ).run(args); >> >>> } >> >>> >> >>> Using container to get an instance would create the instance and bind >> >>> it to the container lifecycle (mainly for predestroy) avoiding this >> >>> boilerplate code in all main which will surely only be used to launch >> >>> a soft. >> >>> >> >>> wdyt? >> >>> >> >>> >> >>> >> >>> Romain Manni-Bucau >> >>> @rmannibucau >> >>> http://www.tomitribe.com >> >>> http://rmannibucau.wordpress.com >> >>> https://github.com/rmannibucau >> >>> >> >>> >> >>> 2015-02-26 8:32 GMT+01:00 Jozef Hartinger >: >> >>>> >> >>>> Comments inline >> >>>> >> >>>> On 02/25/2015 05:53 PM, John D. Ament wrote: >> >>>> >> >>>> Sorry Jozef, your email fell into the pits of google inbox's "smart >> >>>> sorting" >> >>>> features. >> >>>> >> >>>> On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger > >> >>>> wrote: >> >>>>> >> >>>>> Hi John, comments inline: >> >>>>> >> >>>>> >> >>>>> On 02/11/2015 06:02 PM, John D. Ament wrote: >> >>>>> >> >>>>> Jozef, >> >>>>> >> >>>>> Most of what you see there is taken from the original doc, since >> >>>>> everyone >> >>>>> seemed to be in agreement. I think the map is just a safeguard in case >> >>>>> of >> >>>>> additional boot options available in some implementations (e.g. I think >> >>>>> OWB/OpenEJB have some options.. currently OpenEJB supports an embedded >> >>>>> CDI >> >>>>> boot mode). >> >>>>> >> >>>>> No, I am fine with the map. What I am questioning is the type of the >> >>>>> map. >> >>>>> Usually, data structures with a similar purpose use Strings as their >> >>>>> keys. >> >>>>> This applies to ServletContext attributes, InvocationContext data, >> >>>>> Servlet >> >>>>> request/session attributes and others. I am therefore wondering whether >> >>>>> there is a usecase for the proposed unbound key signature or not. >> >>>> >> >>>> >> >>>> I think that's more of a placeholder, I was assuming it would be >> >>>> Map once we clarify everything. >> >>>> >> >>>>> >> >>>>> >> >>>>> We spoke a few times about BeanManager vs CDI. BeanManager was >> >>>>> preferable >> >>>>> since there's no easy way to get the the instance, CDI is easier to get >> >>>>> and >> >>>>> more aligned with how you would get it. Usually people expect the >> >>>>> BeanManager to be injected or available via JNDI, neither would be the >> >>>>> case >> >>>>> here. >> >>>>> >> >>>>> If CDI 2.0 targets Java SE then this container initialization API will >> >>>>> become something that ordinary application developers use to start/stop >> >>>>> CDI >> >>>>> in their applications. It therefore cannot be considered an SPI but >> >>>>> instead >> >>>>> should be something easy to use. On the other hand, BeanManager is >> >>>>> definitely an SPI. It is used in extension, frameworks and generally >> >>>>> for >> >>>>> integration. Not much by applications directly. Therefore, I don't see >> >>>>> how >> >>>>> the container bootstrap API and BeanManager fit together. IMO the >> >>>>> bootstrap >> >>>>> API should expose something that makes common tasks (obtaining a >> >>>>> contextual >> >>>>> reference and firing and event) easy, which the CDI class does. >> >>>>> >> >>>>> Plus do not forget that BeanManager can be obtained easily using >> >>>>> CDI.getBeanManager(). >> >>>> >> >>>> >> >>>> I'm not disagreeing. There's a few things I'd consider: >> >>>> >> >>>> - Is this mostly for new apps or existing? If existing, it's probably >> >>>> using >> >>>> some internal API, if new it can use whatever API we give. >> >>>> - I don't want to return void, we should give some kind of reference >> >>>> into >> >>>> the container when we're done booting. >> >>>> >> >>>> Agreed, we should not be returning void. >> >>>> >> >>>> - CDI is a one step retrievable reference, where as BeanManager is a two >> >>>> step reference. With that said, BeanManager makes more sense to return >> >>>> here. Another thought could be we invent some new class that has both, >> >>>> but >> >>>> that's really redundant. >> >>>> >> >>>> Why do you think BeanManager makes more sense here? Especially given the >> >>>> assumption that application code is going to call this init/shutdown >> >>>> API, I >> >>>> don't see BeanManager as making more sense. >> >>>> >> >>>> >> >>>>> >> >>>>> >> >>>>> Yes, this is the container start API. Sounds like you have some good >> >>>>> ideas for things like XML configuration or programmatic configuration, >> >>>>> both >> >>>>> of which are being tracked under separate tickets. One idea might be >> >>>>> for an >> >>>>> optional param in the map to control packages to scan/ignore, in that >> >>>>> map. >> >>>>> >> >>>>> I am wondering whether this configuration should be something optional >> >>>>> built on top of the bootstrap API or whether we should consider making >> >>>>> it >> >>>>> mandatory. Either way, we cannot add the bootstrap API to the spec >> >>>>> without >> >>>>> explicitly defining how it behaves. My implicit assumption of the >> >>>>> proposal >> >>>>> is that the container is supposed to scan the entire classpath for >> >>>>> explicit >> >>>>> or implicit bean archives (including e.g. rt.jar), discover beans, fire >> >>>>> extensions, etc. This worries me as this default behavior is far from >> >>>>> being >> >>>>> lightweight, which CDI for Java SE initially aimed to be. >> >>>> >> >>>> >> >>>> Yes, the spec must be updated to reflect the behavior of SE mode. I >> >>>> plan to >> >>>> get that completely into the google doc before opening any spec changes >> >>>> in a >> >>>> PR. >> >>>> >> >>>>> >> >>>>> >> >>>>> We didn't want to over load the CDI interface. It already does a lot. >> >>>>> This is really SPI code, CDI even though it's in the spi package is >> >>>>> used in >> >>>>> a lot of application code. >> >>>>> >> >>>>> I would personally prefer to have it all in one place. Having >> >>>>> CDIContainer, CDIContainerLoader, CDI and CDIProvider makes it more >> >>>>> difficult to know when to use what. >> >>>> >> >>>> >> >>>> The problem is that most CDI (the interface) operations are against a >> >>>> running container. I think we spoke about leveraging CDIProvider at one >> >>>> point (in fact, I mistakenly called CDIContainer CDIProvider not even >> >>>> realizing it was there). I doubt that most app developers use it >> >>>> currently, >> >>>> there's not even a way to get a reference to it that I'm aware of. It's >> >>>> used by the implementor only. >> >>>> >> >>>> I don't think there's a conflict. CDI class would still only provide >> >>>> methods >> >>>> to be run against a running container. The difference is that there >> >>>> would be >> >>>> additional static methods to get this running container (CDI class) to >> >>>> you >> >>>> by starting the container. >> >>>> >> >>>> Either way, I agree that reusing CDIProvider is a must. There is no >> >>>> reason >> >>>> to define a new class for the same purpose. >> >>>> >> >>>> >> >>>> I expect that my changes in the CDI spec around this will state, along >> >>>> the >> >>>> lines of: >> >>>> >> >>>> To retrieve a CDIContainer to launch, do this: >> >>>> >> >>>> CDIContainer container = CDIContainerLocator.getCDIContainer(); >> >>>> container.initialize(); >> >>>> ... do work >> >>>> >> >>>> Once you want to shutdown the container, do this: >> >>>> >> >>>> container.shutdown(); >> >>>> >> >>>> (we may want to consider implementing AutoCloseable, an oversight on my >> >>>> part) >> >>>> >> >>>> and then later on >> >>>> >> >>>> - What happens if I call CDIContainerLocator in an app server >> >>>> >> >>>> - It throws an IllegalStateException. >> >>>> >> >>>> - The container provides no beans of type CDIContainer, it is managed >> >>>> outside of the CDI container. >> >>>> >> >>>> >> >>>>> >> >>>>> >> >>>>> John >> >>>>> >> >>>>> On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger > >> >>>>> wrote: >> >>>>>> >> >>>>>> Hi John, some thoughts: >> >>>>>> >> >>>>>> - instead of using BeanManager it makes more sense to me to return a >> >>>>>> CDI >> >>>>>> instance, which is a more user-friendly API (and it also exposes >> >>>>>> access to >> >>>>>> BeanManager) >> >>>>>> - is there a usecase for arbitrary keys of the "params" map or is >> >>>>>> Map sufficient? >> >>>>>> - if we could move the shutdown() method from CDIContainer to the >> >>>>>> actual >> >>>>>> container handle that we obtain from initialize(), that would look >> >>>>>> more >> >>>>>> object-oriented >> >>>>>> - what exactly is initialize() supposed to do? Is it supposed to start >> >>>>>> scanning the entire classpath for CDI beans? That could be a problem >> >>>>>> especially with spring-boot-like fat jars. I think we need an API to >> >>>>>> tell >> >>>>>> the container which classes / packages to consider. Something like >> >>>>>> Guice's >> >>>>>> binding API perhaps? >> >>>>>> >> >>>>>> - the proposal makes me wonder whether retrofitting this functionality >> >>>>>> to >> >>>>>> the CDI class wouldn't be a better option. It could look like: >> >>>>>> >> >>>>>> CDI container = CDI.initialize(); >> >>>>>> container.select(Foo.class).get(); >> >>>>>> container.shutdown(); >> >>>>>> >> >>>>>> compare it to: >> >>>>>> >> >>>>>> CDIContainer container = CDIContainerLoader. getCDIContainer(); >> >>>>>> BeanManager manager = container.initialize(); >> >>>>>> manager.getBeans(...); >> >>>>>> container.shutdown(manager); >> >>>>>> >> >>>>>> >> >>>>>> On 02/10/2015 06:58 PM, John D. Ament wrote: >> >>>>>> >> >>>>>> All, >> >>>>>> >> >>>>>> I have the updated API here, and wanted to solicit any final feedback >> >>>>>> before updating the google doc and spec pages. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c >> >>>>>> >> >>>>>> Let me know your thoughts. >> >>>>>> >> >>>>>> Thanks, >> >>>>>> >> >>>>>> John >> >>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> cdi-dev mailing list >> >>>>>> cdi-dev at lists.jboss.org >> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >>>>>> >> >>>>>> Note that for all code provided on this list, the provider licenses >> >>>>>> the >> >>>>>> code under the Apache License, Version 2 >> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas >> >>>>>> provided on this list, the provider waives all patent and other >> >>>>>> intellectual >> >>>>>> property rights inherent in such information. >> >>>>>> >> >>>>>> >> >>>> >> >>>> _______________________________________________ >> >>>> cdi-dev mailing list >> >>>> cdi-dev at lists.jboss.org >> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >>>> >> >>>> Note that for all code provided on this list, the provider licenses the >> >>>> code >> >>>> under the Apache License, Version 2 >> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas >> >>>> provided on this list, the provider waives all patent and other >> >>>> intellectual >> >>>> property rights inherent in such information. >> >> >> >> >> > >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150304/18313d73/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/20150304/18313d73/attachment-0001.bin From struberg at yahoo.de Wed Mar 4 14:25:44 2015 From: struberg at yahoo.de (Mark Struberg) Date: Wed, 4 Mar 2015 20:25:44 +0100 Subject: [cdi-dev] explicit bean archives discovery-mode 'annotated' Message-ID: <64A8559B-65B5-457B-B5AB-0DF0EAE76A0D@yahoo.de> Hi! I think I?ve implemented the behavour the spec defines - but it does not make much sense. First let?s look at the spec: 11.5.6. ProcessAnnotatedType event The container must fire an event, before it processes a type, for every Java class, interface (excluding the special kind of interface declaration annotation type) or enum DISCOVERED as defined in Section 12.4.1, ?Type discovery? 12.4.1 defines? First the container must discover types. The container discovers: ? each Java class with a bean defining annotation in an implicit bean archive. And in 2.5 we can read "f the bean discovery mode is annotated then: ? bean classes that don?t have bean defining annotation (as defined in Section 2.5.1, ?Bean defining annotations?) and are not bean classes of sessions beans, are NOT DISCOVERED? Which to me means that for a BDA with discovery-mode = ?annotated? we ONLY must fire ProcessAnnotatedType for classes with bean defining annotations, and NOT for interfaces or enums. If this is true, then it is a huge mess for lots of CDI Extensions. It basically renders the ?annotated? mode pretty much useless. What we really need instead is a mode which will not automatically make a @Dependent bean out of every class later. But I really would ?discover? all classes in a BDA and pass them to ProcessAnnotatedType. Some way to fix this or do we have to wait for CDI-2.0 to repair CDI-1.1? LieGrue, strub From mkouba at redhat.com Thu Mar 5 02:54:57 2015 From: mkouba at redhat.com (Martin Kouba) Date: Thu, 05 Mar 2015 08:54:57 +0100 Subject: [cdi-dev] explicit bean archives discovery-mode 'annotated' In-Reply-To: <64A8559B-65B5-457B-B5AB-0DF0EAE76A0D@yahoo.de> References: <64A8559B-65B5-457B-B5AB-0DF0EAE76A0D@yahoo.de> Message-ID: <54F80BD1.8080603@redhat.com> Hi Mark, First of all you're talking about _implicit_ bean archives - explict bean archive contains a beans.xml with bean-discovery-mode of all, with no version number or an empty file. With regard to usability (from the extension developer point of view) - could you give some practical examples? AFAIK it's really useful from the app developer point of view. Dne 4.3.2015 v 20:25 Mark Struberg napsal(a): > Hi! > > I think I?ve implemented the behavour the spec defines - but it does not make much sense. > > First let?s look at the spec: > > 11.5.6. ProcessAnnotatedType event > The container must fire an event, before it processes a type, for every Java class, interface > (excluding the special kind of interface declaration annotation type) or enum DISCOVERED > as defined in Section 12.4.1, ?Type discovery? > > 12.4.1 defines? > First the container must discover types. The container discovers: > ? each Java class with a bean defining annotation in an implicit bean archive. > > > And in 2.5 we can read > "f the bean discovery mode is annotated then: > ? bean classes that don?t have bean defining annotation (as defined in Section 2.5.1, ?Bean defining annotations?) and are not bean classes of sessions beans, are NOT DISCOVERED? > > > > Which to me means that for a BDA with discovery-mode = ?annotated? we ONLY must fire ProcessAnnotatedType for classes with bean defining annotations, and NOT for interfaces or enums. > If this is true, then it is a huge mess for lots of CDI Extensions. It basically renders the ?annotated? mode pretty much useless. > > > What we really need instead is a mode which will not automatically make a @Dependent bean out of every class later. But I really would ?discover? all classes in a BDA and pass them to ProcessAnnotatedType. > Some way to fix this or do we have to wait for CDI-2.0 to repair CDI-1.1? > > LieGrue, > strub > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > -- Martin Kouba Software Engineer Red Hat, Czech Republic From struberg at yahoo.de Thu Mar 5 03:28:17 2015 From: struberg at yahoo.de (Mark Struberg) Date: Thu, 5 Mar 2015 09:28:17 +0100 Subject: [cdi-dev] explicit bean archives discovery-mode 'annotated' In-Reply-To: <54F80BD1.8080603@redhat.com> References: <64A8559B-65B5-457B-B5AB-0DF0EAE76A0D@yahoo.de> <54F80BD1.8080603@redhat.com> Message-ID: <689DA50D-EF53-4520-B2B7-265290DBD999@yahoo.de> Well, the terms ?explicit? and ?implicit? BDA are blurry as well. I _explicitly_ add a beans.xml with version=1.1 and bean-discovery-mode=?annotated? and still it is an ?implicit? BDA according to those definitions. Not very self-explaining but anyway. Has not much to do with the current topic as well, so not sure why you mentioned it? An example of usability would e.g. be the DeltaSpike @MessageBundle feature. Seam3 has had something similar afair. For those who don?t know it see [1]. You basically have an interface and DeltaSpike automatically picks those up and provides implementations for them which are registered as Beans. But in the ?annotated? mode we wont get any PAT for those interfaces anymore. The same mechanism is used tor JPA archives, PropertyFileConfig, etc? Just grep DeltaSpike and check where PAT gets used. It?s all over the place? LieGrue, strub [1] http://deltaspike.apache.org/documentation/core.html#_messages_and_i18n > Am 05.03.2015 um 08:54 schrieb Martin Kouba : > > Hi Mark, > > First of all you're talking about _implicit_ bean archives - explict bean archive contains a beans.xml with bean-discovery-mode of all, with no version number or an empty file. > > With regard to usability (from the extension developer point of view) - could you give some practical examples? AFAIK it's really useful from the app developer point of view. > > Dne 4.3.2015 v 20:25 Mark Struberg napsal(a): >> Hi! >> >> I think I?ve implemented the behavour the spec defines - but it does not make much sense. >> >> First let?s look at the spec: >> >> 11.5.6. ProcessAnnotatedType event >> The container must fire an event, before it processes a type, for every Java class, interface >> (excluding the special kind of interface declaration annotation type) or enum DISCOVERED >> as defined in Section 12.4.1, ?Type discovery? >> >> 12.4.1 defines? >> First the container must discover types. The container discovers: >> ? each Java class with a bean defining annotation in an implicit bean archive. >> >> >> And in 2.5 we can read >> "f the bean discovery mode is annotated then: >> ? bean classes that don?t have bean defining annotation (as defined in Section 2.5.1, ?Bean defining annotations?) and are not bean classes of sessions beans, are NOT DISCOVERED? >> >> >> >> Which to me means that for a BDA with discovery-mode = ?annotated? we ONLY must fire ProcessAnnotatedType for classes with bean defining annotations, and NOT for interfaces or enums. >> If this is true, then it is a huge mess for lots of CDI Extensions. It basically renders the ?annotated? mode pretty much useless. >> >> >> What we really need instead is a mode which will not automatically make a @Dependent bean out of every class later. But I really would ?discover? all classes in a BDA and pass them to ProcessAnnotatedType. >> Some way to fix this or do we have to wait for CDI-2.0 to repair CDI-1.1? >> >> LieGrue, >> strub >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic From struberg at yahoo.de Thu Mar 5 04:09:17 2015 From: struberg at yahoo.de (Mark Struberg) Date: Thu, 5 Mar 2015 10:09:17 +0100 Subject: [cdi-dev] explicit bean archives discovery-mode 'annotated' In-Reply-To: <689DA50D-EF53-4520-B2B7-265290DBD999@yahoo.de> References: <64A8559B-65B5-457B-B5AB-0DF0EAE76A0D@yahoo.de> <54F80BD1.8080603@redhat.com> <689DA50D-EF53-4520-B2B7-265290DBD999@yahoo.de> Message-ID: Just figured that I already reported this a year ago: https://issues.jboss.org/browse/CDI-420 > Am 05.03.2015 um 09:28 schrieb Mark Struberg : > > Well, the terms ?explicit? and ?implicit? BDA are blurry as well. I _explicitly_ add a beans.xml with version=1.1 and bean-discovery-mode=?annotated? and still it is an ?implicit? BDA according to those definitions. Not very self-explaining but anyway. Has not much to do with the current topic as well, so not sure why you mentioned it? > > An example of usability would e.g. be the DeltaSpike @MessageBundle feature. Seam3 has had something similar afair. > For those who don?t know it see [1]. You basically have an interface and DeltaSpike automatically picks those up and provides implementations for them which are registered as Beans. > > But in the ?annotated? mode we wont get any PAT for those interfaces anymore. The same mechanism is used tor JPA archives, PropertyFileConfig, etc? > Just grep DeltaSpike and check where PAT gets used. It?s all over the place? > > LieGrue, > strub > > > > [1] http://deltaspike.apache.org/documentation/core.html#_messages_and_i18n > > >> Am 05.03.2015 um 08:54 schrieb Martin Kouba : >> >> Hi Mark, >> >> First of all you're talking about _implicit_ bean archives - explict bean archive contains a beans.xml with bean-discovery-mode of all, with no version number or an empty file. >> >> With regard to usability (from the extension developer point of view) - could you give some practical examples? AFAIK it's really useful from the app developer point of view. >> >> Dne 4.3.2015 v 20:25 Mark Struberg napsal(a): >>> Hi! >>> >>> I think I?ve implemented the behavour the spec defines - but it does not make much sense. >>> >>> First let?s look at the spec: >>> >>> 11.5.6. ProcessAnnotatedType event >>> The container must fire an event, before it processes a type, for every Java class, interface >>> (excluding the special kind of interface declaration annotation type) or enum DISCOVERED >>> as defined in Section 12.4.1, ?Type discovery? >>> >>> 12.4.1 defines? >>> First the container must discover types. The container discovers: >>> ? each Java class with a bean defining annotation in an implicit bean archive. >>> >>> >>> And in 2.5 we can read >>> "f the bean discovery mode is annotated then: >>> ? bean classes that don?t have bean defining annotation (as defined in Section 2.5.1, ?Bean defining annotations?) and are not bean classes of sessions beans, are NOT DISCOVERED? >>> >>> >>> >>> Which to me means that for a BDA with discovery-mode = ?annotated? we ONLY must fire ProcessAnnotatedType for classes with bean defining annotations, and NOT for interfaces or enums. >>> If this is true, then it is a huge mess for lots of CDI Extensions. It basically renders the ?annotated? mode pretty much useless. >>> >>> >>> What we really need instead is a mode which will not automatically make a @Dependent bean out of every class later. But I really would ?discover? all classes in a BDA and pass them to ProcessAnnotatedType. >>> Some way to fix this or do we have to wait for CDI-2.0 to repair CDI-1.1? >>> >>> LieGrue, >>> strub >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>> >> >> -- >> Martin Kouba >> Software Engineer >> Red Hat, Czech Republic > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From antoine at sabot-durand.net Thu Mar 5 08:14:00 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 5 Mar 2015 14:14:00 +0100 Subject: [cdi-dev] explicit bean archives discovery-mode 'annotated' In-Reply-To: <689DA50D-EF53-4520-B2B7-265290DBD999@yahoo.de> References: <64A8559B-65B5-457B-B5AB-0DF0EAE76A0D@yahoo.de> <54F80BD1.8080603@redhat.com> <689DA50D-EF53-4520-B2B7-265290DBD999@yahoo.de> Message-ID: <972A938F-B013-4ECB-A8B9-FA0328187C30@sabot-durand.net> > Le 5 mars 2015 ? 09:28, Mark Struberg a ?crit : > > Well, the terms ?explicit? and ?implicit? BDA are blurry as well. I _explicitly_ add a beans.xml with version=1.1 and bean-discovery-mode=?annotated? and still it is an ?implicit? BDA according to those definitions. Not very self-explaining but anyway. Has not much to do with the current topic as well, so not sure why you mentioned it? > It?s the other way around. Implicit bean archive behave as if they have a beans.xml with version 1.1 and ?annotated? bean-discovery mode. > An example of usability would e.g. be the DeltaSpike @MessageBundle feature. Seam3 has had something similar afair. > For those who don?t know it see [1]. You basically have an interface and DeltaSpike automatically picks those up and provides implementations for them which are registered as Beans. > > But in the ?annotated? mode we wont get any PAT for those interfaces anymore. The same mechanism is used tor JPA archives, PropertyFileConfig, etc? > Just grep DeltaSpike and check where PAT gets used. It?s all over the place? Yes, that?s why you shouldn?t use annotated discovery mode if you want to do serious stuff in CDI. Having a mode where PAT are fired but AnnotatedType without Bean Defining annotation wouldn?t become bean might bring more confusion : what happen if I replace the AnnotatedType with one bearing a Bean Defining annotation or if I register a new AnnotatedType without bean defining annotation in BeforeBenDiscovery? We have to leave with this Annotated mode which already brought it?s issues (https://issues.jboss.org/browse/CDI-377) and recommend users that want do real stuff with CDI to use All discovery mode. > > LieGrue, > strub > > > > [1] http://deltaspike.apache.org/documentation/core.html#_messages_and_i18n > > >> Am 05.03.2015 um 08:54 schrieb Martin Kouba : >> >> Hi Mark, >> >> First of all you're talking about _implicit_ bean archives - explict bean archive contains a beans.xml with bean-discovery-mode of all, with no version number or an empty file. >> >> With regard to usability (from the extension developer point of view) - could you give some practical examples? AFAIK it's really useful from the app developer point of view. >> >> Dne 4.3.2015 v 20:25 Mark Struberg napsal(a): >>> Hi! >>> >>> I think I?ve implemented the behavour the spec defines - but it does not make much sense. >>> >>> First let?s look at the spec: >>> >>> 11.5.6. ProcessAnnotatedType event >>> The container must fire an event, before it processes a type, for every Java class, interface >>> (excluding the special kind of interface declaration annotation type) or enum DISCOVERED >>> as defined in Section 12.4.1, ?Type discovery? >>> >>> 12.4.1 defines? >>> First the container must discover types. The container discovers: >>> ? each Java class with a bean defining annotation in an implicit bean archive. >>> >>> >>> And in 2.5 we can read >>> "f the bean discovery mode is annotated then: >>> ? bean classes that don?t have bean defining annotation (as defined in Section 2.5.1, ?Bean defining annotations?) and are not bean classes of sessions beans, are NOT DISCOVERED? >>> >>> >>> >>> Which to me means that for a BDA with discovery-mode = ?annotated? we ONLY must fire ProcessAnnotatedType for classes with bean defining annotations, and NOT for interfaces or enums. >>> If this is true, then it is a huge mess for lots of CDI Extensions. It basically renders the ?annotated? mode pretty much useless. >>> >>> >>> What we really need instead is a mode which will not automatically make a @Dependent bean out of every class later. But I really would ?discover? all classes in a BDA and pass them to ProcessAnnotatedType. >>> Some way to fix this or do we have to wait for CDI-2.0 to repair CDI-1.1? >>> >>> LieGrue, >>> strub >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>> >> >> -- >> Martin Kouba >> Software Engineer >> Red Hat, Czech Republic > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- 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/20150305/3a370c1e/attachment-0001.bin From struberg at yahoo.de Thu Mar 5 09:20:18 2015 From: struberg at yahoo.de (Mark Struberg) Date: Thu, 5 Mar 2015 15:20:18 +0100 Subject: [cdi-dev] explicit bean archives discovery-mode 'annotated' In-Reply-To: <972A938F-B013-4ECB-A8B9-FA0328187C30@sabot-durand.net> References: <64A8559B-65B5-457B-B5AB-0DF0EAE76A0D@yahoo.de> <54F80BD1.8080603@redhat.com> <689DA50D-EF53-4520-B2B7-265290DBD999@yahoo.de> <972A938F-B013-4ECB-A8B9-FA0328187C30@sabot-durand.net> Message-ID: <9C11E215-7D80-495F-A177-E802AA0EBEE6@yahoo.de> > Am 05.03.2015 um 14:14 schrieb Antoine Sabot-Durand : > >> Le 5 mars 2015 ? 09:28, Mark Struberg a ?crit : >> >> Well, the terms ?explicit? and ?implicit? BDA are blurry as well. I _explicitly_ add a beans.xml with version=1.1 and bean-discovery-mode=?annotated? and still it is an ?implicit? BDA according to those definitions. Not very self-explaining but anyway. Has not much to do with the current topic as well, so not sure why you mentioned it? >> > > It?s the other way around. Implicit bean archive behave as if they have a beans.xml with version 1.1 and ?annotated? bean-discovery mode. Sorry Antoine, what I wrote is imo correct according to the correct spec wording. Please read 12.1: "An explicit bean archive is an archive which contains a beans.xml file: ? with a version number of 1.1 (or later), with the bean-discovery-mode of all, or, ? with no version number, or, ? that is an empty file.? The important part is ?with the bean-discovery-mode of ALL?. So if it does have a different bean-discovery-mode (here: annotated) then it is NOT an explicit bean archive and is falls under the subsumption of the follow up paragraph: "An implicit bean archive is any other archive which contains one or more bean classes " So according to the current wording (has been there that way since CDI-1.1) a jar with a beans.xml with bean-discovery-mode=?annotated? is an ?implicit bean archive?. Maybe ?annotated? is just missing in the first sentence? > Yes, that?s why you shouldn?t use annotated discovery mode if you want to do serious stuff in CDI. Well that?s the same like saying ?sorry folks, we fucked it up. Use something different.? :) The main reason for all this is to reduce the amount of beans by not picking up every damn class on the classpath as @Dependent scoped bean. LieGrue, strub From antoine at sabot-durand.net Thu Mar 5 10:06:01 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 5 Mar 2015 16:06:01 +0100 Subject: [cdi-dev] explicit bean archives discovery-mode 'annotated' In-Reply-To: <9C11E215-7D80-495F-A177-E802AA0EBEE6@yahoo.de> References: <64A8559B-65B5-457B-B5AB-0DF0EAE76A0D@yahoo.de> <54F80BD1.8080603@redhat.com> <689DA50D-EF53-4520-B2B7-265290DBD999@yahoo.de> <972A938F-B013-4ECB-A8B9-FA0328187C30@sabot-durand.net> <9C11E215-7D80-495F-A177-E802AA0EBEE6@yahoo.de> Message-ID: <1F5D9B6F-DB90-4494-B196-AC253B67043E@sabot-durand.net> > Le 5 mars 2015 ? 15:20, Mark Struberg a ?crit : > > >> Am 05.03.2015 um 14:14 schrieb Antoine Sabot-Durand : >> >>> Le 5 mars 2015 ? 09:28, Mark Struberg a ?crit : >>> >>> Well, the terms ?explicit? and ?implicit? BDA are blurry as well. I _explicitly_ add a beans.xml with version=1.1 and bean-discovery-mode=?annotated? and still it is an ?implicit? BDA according to those definitions. Not very self-explaining but anyway. Has not much to do with the current topic as well, so not sure why you mentioned it? >>> >> >> It?s the other way around. Implicit bean archive behave as if they have a beans.xml with version 1.1 and ?annotated? bean-discovery mode. > > > Sorry Antoine, what I wrote is imo correct according to the correct spec wording. > > Please read 12.1: > > "An explicit bean archive is an archive which contains a beans.xml file: > ? with a version number of 1.1 (or later), with the bean-discovery-mode of all, or, > ? with no version number, or, > ? that is an empty file.? > > The important part is ?with the bean-discovery-mode of ALL?. So if it does have a different bean-discovery-mode (here: annotated) then it is NOT an explicit bean archive and is falls under the subsumption of the follow up paragraph: > "An implicit bean archive is any other archive which contains one or more bean classes " > > > > So according to the current wording (has been there that way since CDI-1.1) a jar with a beans.xml with bean-discovery-mode=?annotated? is an ?implicit bean archive?. Maybe ?annotated? is just missing in the first sentence? > We are saying the same. what?s your point here ? > >> Yes, that?s why you shouldn?t use annotated discovery mode if you want to do serious stuff in CDI. > > Well that?s the same like saying ?sorry folks, we fucked it up. Use something different.? :) Yes, but if you re-read CDI-377 you?ll notice that the problematic linked annotated has already consumed a lot of precious time to a lot of people. > The main reason for all this is to reduce the amount of beans by not picking up every damn class on the classpath as @Dependent scoped bean. No, the main reason for annotated mode is to activate CDI automatically in Java EE 7 without messing with class not thought for CDI. > > LieGrue, > strub > -------------- 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/20150305/758c73ae/attachment.bin From struberg at yahoo.de Thu Mar 5 10:27:11 2015 From: struberg at yahoo.de (Mark Struberg) Date: Thu, 5 Mar 2015 16:27:11 +0100 Subject: [cdi-dev] explicit bean archives discovery-mode 'annotated' In-Reply-To: <1F5D9B6F-DB90-4494-B196-AC253B67043E@sabot-durand.net> References: <64A8559B-65B5-457B-B5AB-0DF0EAE76A0D@yahoo.de> <54F80BD1.8080603@redhat.com> <689DA50D-EF53-4520-B2B7-265290DBD999@yahoo.de> <972A938F-B013-4ECB-A8B9-FA0328187C30@sabot-durand.net> <9C11E215-7D80-495F-A177-E802AA0EBEE6@yahoo.de> <1F5D9B6F-DB90-4494-B196-AC253B67043E@sabot-durand.net> Message-ID: > Am 05.03.2015 um 16:06 schrieb Antoine Sabot-Durand : > > > It?s the other way around. Implicit bean archive behave as if they have a beans.xml with version 1.1 and ?annotated? bean-discovery mode. > We are saying the same. what?s your point here ? Oh now I get your original sentence. Sorry was an ebkac [1] on my side. LieGrue, strub [1] error between keyboard and chair From jharting at redhat.com Fri Mar 6 02:00:03 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Fri, 06 Mar 2015 08:00:03 +0100 Subject: [cdi-dev] explicit bean archives discovery-mode 'annotated' In-Reply-To: <972A938F-B013-4ECB-A8B9-FA0328187C30@sabot-durand.net> References: <64A8559B-65B5-457B-B5AB-0DF0EAE76A0D@yahoo.de> <54F80BD1.8080603@redhat.com> <689DA50D-EF53-4520-B2B7-265290DBD999@yahoo.de> <972A938F-B013-4ECB-A8B9-FA0328187C30@sabot-durand.net> Message-ID: <54F95073.9050508@redhat.com> Are you really telling people to use beans.xml with bdm="all" again? Is that based on this particular issue or did you reach the conclusion before based on some other issues? On 03/05/2015 02:14 PM, Antoine Sabot-Durand wrote: > Yes, that?s why you shouldn?t use annotated discovery mode if you want to do serious stuff in CDI. From jharting at redhat.com Fri Mar 6 02:11:42 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Fri, 06 Mar 2015 08:11:42 +0100 Subject: [cdi-dev] explicit bean archives discovery-mode 'annotated' In-Reply-To: <689DA50D-EF53-4520-B2B7-265290DBD999@yahoo.de> References: <64A8559B-65B5-457B-B5AB-0DF0EAE76A0D@yahoo.de> <54F80BD1.8080603@redhat.com> <689DA50D-EF53-4520-B2B7-265290DBD999@yahoo.de> Message-ID: <54F9532E.7080003@redhat.com> This interface/enum discovery use-case very often uses a marker annotation (e.g. @MessageBundle). Such extension can work around this limitation by making the marker annotation a @Stereotype. Can you see any other scenarios where implicit bean archives are a problem? On 03/05/2015 09:28 AM, Mark Struberg wrote: > Well, the terms ?explicit? and ?implicit? BDA are blurry as well. I_explicitly_ add a beans.xml with version=1.1 and bean-discovery-mode=?annotated? and still it is an ?implicit? BDA according to those definitions. Not very self-explaining but anyway. Has not much to do with the current topic as well, so not sure why you mentioned it? > > An example of usability would e.g. be the DeltaSpike @MessageBundle feature. Seam3 has had something similar afair. > For those who don?t know it see [1]. You basically have an interface and DeltaSpike automatically picks those up and provides implementations for them which are registered as Beans. > > But in the ?annotated? mode we wont get any PAT for those interfaces anymore. The same mechanism is used tor JPA archives, PropertyFileConfig, etc? > Just grep DeltaSpike and check where PAT gets used. It?s all over the place? > > LieGrue, > strub From issues at jboss.org Fri Mar 6 02:12:49 2015 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Fri, 6 Mar 2015 02:12:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'detected' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046872#comment-13046872 ] Jozef Hartinger commented on CDI-420: ------------------------------------- This interface/enum discovery use-case very often uses a marker annotation (e.g. @MessageBundle). Such extension can work around this limitation by making the marker annotation a @Stereotype. > add a bean-discovery-mode 'detected' > ------------------------------------ > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: TBD > Reporter: Mark Struberg > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > ? each Java class, interface or enum deployed in an explicit bean archive, and > ? each Java class with a bean defining annotation in an implicit bean archive. > ? each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message was sent by Atlassian JIRA (v6.3.11#6341) From rmannibucau at gmail.com Fri Mar 6 03:03:27 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Fri, 6 Mar 2015 09:03:27 +0100 Subject: [cdi-dev] explicit bean archives discovery-mode 'annotated' In-Reply-To: <54F9532E.7080003@redhat.com> References: <64A8559B-65B5-457B-B5AB-0DF0EAE76A0D@yahoo.de> <54F80BD1.8080603@redhat.com> <689DA50D-EF53-4520-B2B7-265290DBD999@yahoo.de> <54F9532E.7080003@redhat.com> Message-ID: Hi Well you cant ask libs to change their programming model for it IMO. It is clearly a regression. Another broken case is if any other IoC uses some of these annotations but doesnt rely on scanning. Now you scan the jar and can get surprises and even an Error. Le 6 mars 2015 08:12, "Jozef Hartinger" a ?crit : > This interface/enum discovery use-case very often uses a marker > annotation (e.g. @MessageBundle). Such extension can work around this > limitation by making the marker annotation a @Stereotype. Can you see > any other scenarios where implicit bean archives are a problem? > > On 03/05/2015 09:28 AM, Mark Struberg wrote: > > Well, the terms ?explicit? and ?implicit? BDA are blurry as well. > I_explicitly_ add a beans.xml with version=1.1 and > bean-discovery-mode=?annotated? and still it is an ?implicit? BDA according > to those definitions. Not very self-explaining but anyway. Has not much to > do with the current topic as well, so not sure why you mentioned it? > > > > An example of usability would e.g. be the DeltaSpike @MessageBundle > feature. Seam3 has had something similar afair. > > For those who don?t know it see [1]. You basically have an interface and > DeltaSpike automatically picks those up and provides implementations for > them which are registered as Beans. > > > > But in the ?annotated? mode we wont get any PAT for those interfaces > anymore. The same mechanism is used tor JPA archives, PropertyFileConfig, > etc? > > Just grep DeltaSpike and check where PAT gets used. It?s all over the > place? > > > > LieGrue, > > strub > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150306/fb295495/attachment-0001.html From jharting at redhat.com Fri Mar 6 03:15:14 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Fri, 06 Mar 2015 09:15:14 +0100 Subject: [cdi-dev] explicit bean archives discovery-mode 'annotated' In-Reply-To: References: <64A8559B-65B5-457B-B5AB-0DF0EAE76A0D@yahoo.de> <54F80BD1.8080603@redhat.com> <689DA50D-EF53-4520-B2B7-265290DBD999@yahoo.de> <54F9532E.7080003@redhat.com> Message-ID: <54F96212.80200@redhat.com> On 03/06/2015 09:03 AM, Romain Manni-Bucau wrote: > > Hi > > Well you cant ask libs to change their programming model for it IMO. > It is clearly a regression. > Why not? Existing applications (empty beans.xml) will still work as before so there is no regression. If a lib wants to support bean-discovery-mode="annotated" then it has to adapt. It would be better if they did not have to but it's too late at this point. > > Another broken case is if any other IoC uses some of these annotations > but doesnt rely on scanning. Now you scan the jar and can get > surprises and even an Error. > Yes, this was a risk when implicit bean archives were introduced. This was in the end mitigated by only making CDI annotations as bean defining (most likely other IoC won't use CDI annotations) plus introducing bdm="none" mode. > > Le 6 mars 2015 08:12, "Jozef Hartinger" > a ?crit : > > This interface/enum discovery use-case very often uses a marker > annotation (e.g. @MessageBundle). Such extension can work around this > limitation by making the marker annotation a @Stereotype. Can you see > any other scenarios where implicit bean archives are a problem? > > On 03/05/2015 09:28 AM, Mark Struberg wrote: > > Well, the terms ?explicit? and ?implicit? BDA are blurry as > well. I_explicitly_ add a beans.xml with version=1.1 and > bean-discovery-mode=?annotated? and still it is an ?implicit? BDA > according to those definitions. Not very self-explaining but > anyway. Has not much to do with the current topic as well, so not > sure why you mentioned it? > > > > An example of usability would e.g. be the DeltaSpike > @MessageBundle feature. Seam3 has had something similar afair. > > For those who don?t know it see [1]. You basically have an > interface and DeltaSpike automatically picks those up and provides > implementations for them which are registered as Beans. > > > > But in the ?annotated? mode we wont get any PAT for those > interfaces anymore. The same mechanism is used tor JPA archives, > PropertyFileConfig, etc? > > Just grep DeltaSpike and check where PAT gets used. It?s all > over the place? > > > > LieGrue, > > strub > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider > licenses the code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > ideas provided on this list, the provider waives all patent and > other intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150306/ca55e216/attachment.html From rmannibucau at gmail.com Fri Mar 6 03:22:10 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Fri, 6 Mar 2015 09:22:10 +0100 Subject: [cdi-dev] explicit bean archives discovery-mode 'annotated' In-Reply-To: <54F96212.80200@redhat.com> References: <64A8559B-65B5-457B-B5AB-0DF0EAE76A0D@yahoo.de> <54F80BD1.8080603@redhat.com> <689DA50D-EF53-4520-B2B7-265290DBD999@yahoo.de> <54F9532E.7080003@redhat.com> <54F96212.80200@redhat.com> Message-ID: Well @Interceptor is widely used elsewhere - that's the main one I can think about. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-03-06 9:15 GMT+01:00 Jozef Hartinger : > > On 03/06/2015 09:03 AM, Romain Manni-Bucau wrote: > > Hi > > Well you cant ask libs to change their programming model for it IMO. It is > clearly a regression. > > Why not? Existing applications (empty beans.xml) will still work as before > so there is no regression. If a lib wants to support > bean-discovery-mode="annotated" then it has to adapt. It would be better if > they did not have to but it's too late at this point. > > Another broken case is if any other IoC uses some of these annotations but > doesnt rely on scanning. Now you scan the jar and can get surprises and > even an Error. > > Yes, this was a risk when implicit bean archives were introduced. This was > in the end mitigated by only making CDI annotations as bean defining (most > likely other IoC won't use CDI annotations) plus introducing bdm="none" > mode. > > Le 6 mars 2015 08:12, "Jozef Hartinger" a ?crit : > >> This interface/enum discovery use-case very often uses a marker >> annotation (e.g. @MessageBundle). Such extension can work around this >> limitation by making the marker annotation a @Stereotype. Can you see >> any other scenarios where implicit bean archives are a problem? >> >> On 03/05/2015 09:28 AM, Mark Struberg wrote: >> > Well, the terms ?explicit? and ?implicit? BDA are blurry as well. >> I_explicitly_ add a beans.xml with version=1.1 and >> bean-discovery-mode=?annotated? and still it is an ?implicit? BDA according >> to those definitions. Not very self-explaining but anyway. Has not much to >> do with the current topic as well, so not sure why you mentioned it? >> > >> > An example of usability would e.g. be the DeltaSpike @MessageBundle >> feature. Seam3 has had something similar afair. >> > For those who don?t know it see [1]. You basically have an interface >> and DeltaSpike automatically picks those up and provides implementations >> for them which are registered as Beans. >> > >> > But in the ?annotated? mode we wont get any PAT for those interfaces >> anymore. The same mechanism is used tor JPA archives, PropertyFileConfig, >> etc? >> > Just grep DeltaSpike and check where PAT gets used. It?s all over the >> place? >> > >> > LieGrue, >> > strub >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150306/34aa4a21/attachment.html From struberg at yahoo.de Fri Mar 6 03:44:00 2015 From: struberg at yahoo.de (Mark Struberg) Date: Fri, 6 Mar 2015 09:44:00 +0100 Subject: [cdi-dev] explicit bean archives discovery-mode 'annotated' In-Reply-To: <54F96212.80200@redhat.com> References: <64A8559B-65B5-457B-B5AB-0DF0EAE76A0D@yahoo.de> <54F80BD1.8080603@redhat.com> <689DA50D-EF53-4520-B2B7-265290DBD999@yahoo.de> <54F9532E.7080003@redhat.com> <54F96212.80200@redhat.com> Message-ID: <06C2CDE6-D404-48D7-B744-578A5A47452B@yahoo.de> While we are at it: the ?none? mode is broken as well ;) Imagine you have a jar in say DeltaSpike with a bean-discovery-mode=?none?. Now let?s run this in CDI-1.1++ containers: all fine jar gets ignored But in CDI-1.0 containers: whoops, due to having a beans.xml at all (marker interface) the container must scan this jar. There is simply no backward compatible way to tell the container that it should ignore a jar. LieGure, strub > Am 06.03.2015 um 09:15 schrieb Jozef Hartinger : > > > On 03/06/2015 09:03 AM, Romain Manni-Bucau wrote: >> Hi >> >> Well you cant ask libs to change their programming model for it IMO. It is clearly a regression. >> > Why not? Existing applications (empty beans.xml) will still work as before so there is no regression. If a lib wants to support bean-discovery-mode="annotated" then it has to adapt. It would be better if they did not have to but it's too late at this point. >> Another broken case is if any other IoC uses some of these annotations but doesnt rely on scanning. Now you scan the jar and can get surprises and even an Error. > Yes, this was a risk when implicit bean archives were introduced. This was in the end mitigated by only making CDI annotations as bean defining (most likely other IoC won't use CDI annotations) plus introducing bdm="none" mode. From rmannibucau at gmail.com Fri Mar 6 03:48:01 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Fri, 6 Mar 2015 09:48:01 +0100 Subject: [cdi-dev] explicit bean archives discovery-mode 'annotated' In-Reply-To: <06C2CDE6-D404-48D7-B744-578A5A47452B@yahoo.de> References: <64A8559B-65B5-457B-B5AB-0DF0EAE76A0D@yahoo.de> <54F80BD1.8080603@redhat.com> <689DA50D-EF53-4520-B2B7-265290DBD999@yahoo.de> <54F9532E.7080003@redhat.com> <54F96212.80200@redhat.com> <06C2CDE6-D404-48D7-B744-578A5A47452B@yahoo.de> Message-ID: that's not the issue of none. None was mainly designed for not cdi libs I think...which will never get modified for cdi *by design*. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-03-06 9:44 GMT+01:00 Mark Struberg : > While we are at it: the ?none? mode is broken as well ;) > > Imagine you have a jar in say DeltaSpike with a > bean-discovery-mode=?none?. > > Now let?s run this in CDI-1.1++ containers: all fine jar gets ignored > But in CDI-1.0 containers: whoops, due to having a beans.xml at all > (marker interface) the container must scan this jar. > > > There is simply no backward compatible way to tell the container that it > should ignore a jar. > > LieGure, > strub > > > > > Am 06.03.2015 um 09:15 schrieb Jozef Hartinger : > > > > > > On 03/06/2015 09:03 AM, Romain Manni-Bucau wrote: > >> Hi > >> > >> Well you cant ask libs to change their programming model for it IMO. It > is clearly a regression. > >> > > Why not? Existing applications (empty beans.xml) will still work as > before so there is no regression. If a lib wants to support > bean-discovery-mode="annotated" then it has to adapt. It would be better if > they did not have to but it's too late at this point. > >> Another broken case is if any other IoC uses some of these annotations > but doesnt rely on scanning. Now you scan the jar and can get surprises and > even an Error. > > Yes, this was a risk when implicit bean archives were introduced. This > was in the end mitigated by only making CDI annotations as bean defining > (most likely other IoC won't use CDI annotations) plus introducing > bdm="none" mode. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150306/a3ca6b07/attachment-0001.html From struberg at yahoo.de Fri Mar 6 03:54:43 2015 From: struberg at yahoo.de (Mark Struberg) Date: Fri, 6 Mar 2015 09:54:43 +0100 Subject: [cdi-dev] explicit bean archives discovery-mode 'annotated' In-Reply-To: References: <64A8559B-65B5-457B-B5AB-0DF0EAE76A0D@yahoo.de> <54F80BD1.8080603@redhat.com> <689DA50D-EF53-4520-B2B7-265290DBD999@yahoo.de> <54F9532E.7080003@redhat.com> <54F96212.80200@redhat.com> <06C2CDE6-D404-48D7-B744-578A5A47452B@yahoo.de> Message-ID: yes, but the pure fact that there is a beans.xml in the jar actually MAKE them a CDI lib for EE6 and CDI-1.0 containers? LieGrue, strub > Am 06.03.2015 um 09:48 schrieb Romain Manni-Bucau : > > that's not the issue of none. None was mainly designed for not cdi libs I think...which will never get modified for cdi *by design*. > > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > 2015-03-06 9:44 GMT+01:00 Mark Struberg : > While we are at it: the ?none? mode is broken as well ;) > > Imagine you have a jar in say DeltaSpike with a bean-discovery-mode=?none?. > > Now let?s run this in CDI-1.1++ containers: all fine jar gets ignored > But in CDI-1.0 containers: whoops, due to having a beans.xml at all (marker interface) the container must scan this jar. > > > There is simply no backward compatible way to tell the container that it should ignore a jar. > > LieGure, > strub > > From antoine at sabot-durand.net Fri Mar 6 04:50:08 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 6 Mar 2015 10:50:08 +0100 Subject: [cdi-dev] explicit bean archives discovery-mode 'annotated' In-Reply-To: <54F95073.9050508@redhat.com> References: <64A8559B-65B5-457B-B5AB-0DF0EAE76A0D@yahoo.de> <54F80BD1.8080603@redhat.com> <689DA50D-EF53-4520-B2B7-265290DBD999@yahoo.de> <972A938F-B013-4ECB-A8B9-FA0328187C30@sabot-durand.net> <54F95073.9050508@redhat.com> Message-ID: I often give this solution to people having issue with unsatisfied injection point issue. Of course I could also tell them to check every bean and see if there is a bean defining annotation on all of them but it could be far more fastidious. Perhaps the solution could be to add a neutral annotation (empty stereotypes) that explicitly declares a bean. The oxymora with ?annotated" discovery mode is that it was designed to ease life of user (and beginners) but that it requires to understand what is a bean defining annotation and put one on the bean... > Le 6 mars 2015 ? 08:00, Jozef Hartinger a ?crit : > > Are you really telling people to use beans.xml with bdm="all" again? Is that based on this particular issue or did you reach the conclusion before based on some other issues? > > On 03/05/2015 02:14 PM, Antoine Sabot-Durand wrote: >> Yes, that?s why you shouldn?t use annotated discovery mode if you want to do serious stuff in CDI. > -------------- 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/20150306/f6089d14/attachment.bin From antoine at sabot-durand.net Fri Mar 6 04:55:09 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 6 Mar 2015 10:55:09 +0100 Subject: [cdi-dev] explicit bean archives discovery-mode 'annotated' In-Reply-To: References: <64A8559B-65B5-457B-B5AB-0DF0EAE76A0D@yahoo.de> <54F80BD1.8080603@redhat.com> <689DA50D-EF53-4520-B2B7-265290DBD999@yahoo.de> <54F9532E.7080003@redhat.com> Message-ID: <41AC0547-BC54-48C9-82F6-95515AE48DCB@sabot-durand.net> > Le 6 mars 2015 ? 09:03, Romain Manni-Bucau a ?crit : > > Hi > > Well you cant ask libs to change their programming model for it IMO. It is clearly a regression. > Far easier than informing all lib users to change or create bean discovery mode. > Another broken case is if any other IoC uses some of these annotations but doesnt rely on scanning. Now you scan the jar and can get surprises and even an Error. > Not true anymore. all bean defining annotation are only CDI annotation now : http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bean_defining_annotations . That was one of the fix in CDI 1.2 MR. > Le 6 mars 2015 08:12, "Jozef Hartinger" > a ?crit : > This interface/enum discovery use-case very often uses a marker > annotation (e.g. @MessageBundle). Such extension can work around this > limitation by making the marker annotation a @Stereotype. Can you see > any other scenarios where implicit bean archives are a problem? > > On 03/05/2015 09:28 AM, Mark Struberg wrote: > > Well, the terms ?explicit? and ?implicit? BDA are blurry as well. I_explicitly_ add a beans.xml with version=1.1 and bean-discovery-mode=?annotated? and still it is an ?implicit? BDA according to those definitions. Not very self-explaining but anyway. Has not much to do with the current topic as well, so not sure why you mentioned it? > > > > An example of usability would e.g. be the DeltaSpike @MessageBundle feature. Seam3 has had something similar afair. > > For those who don?t know it see [1]. You basically have an interface and DeltaSpike automatically picks those up and provides implementations for them which are registered as Beans. > > > > But in the ?annotated? mode we wont get any PAT for those interfaces anymore. The same mechanism is used tor JPA archives, PropertyFileConfig, etc? > > Just grep DeltaSpike and check where PAT gets used. It?s all over the place? > > > > LieGrue, > > strub > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150306/1d86b18c/attachment.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/20150306/1d86b18c/attachment.bin From antoine at sabot-durand.net Fri Mar 6 05:01:11 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 6 Mar 2015 11:01:11 +0100 Subject: [cdi-dev] explicit bean archives discovery-mode 'annotated' In-Reply-To: References: <64A8559B-65B5-457B-B5AB-0DF0EAE76A0D@yahoo.de> <54F80BD1.8080603@redhat.com> <689DA50D-EF53-4520-B2B7-265290DBD999@yahoo.de> <54F9532E.7080003@redhat.com> <54F96212.80200@redhat.com> Message-ID: <2F7838CF-094B-4B36-BFF8-4BB9337A026E@sabot-durand.net> I checked that no other IoC framework was using @Interceptor before proposing the fix in CDI-377 > Le 6 mars 2015 ? 09:22, Romain Manni-Bucau a ?crit : > > Well @Interceptor is widely used elsewhere - that's the main one I can think about. > > > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > 2015-03-06 9:15 GMT+01:00 Jozef Hartinger >: > > On 03/06/2015 09:03 AM, Romain Manni-Bucau wrote: >> Hi >> >> Well you cant ask libs to change their programming model for it IMO. It is clearly a regression. >> > Why not? Existing applications (empty beans.xml) will still work as before so there is no regression. If a lib wants to support bean-discovery-mode="annotated" then it has to adapt. It would be better if they did not have to but it's too late at this point. >> Another broken case is if any other IoC uses some of these annotations but doesnt rely on scanning. Now you scan the jar and can get surprises and even an Error. > Yes, this was a risk when implicit bean archives were introduced. This was in the end mitigated by only making CDI annotations as bean defining (most likely other IoC won't use CDI annotations) plus introducing bdm="none" mode. >> >> Le 6 mars 2015 08:12, "Jozef Hartinger" > a ?crit : >> This interface/enum discovery use-case very often uses a marker >> annotation (e.g. @MessageBundle). Such extension can work around this >> limitation by making the marker annotation a @Stereotype. Can you see >> any other scenarios where implicit bean archives are a problem? >> >> On 03/05/2015 09:28 AM, Mark Struberg wrote: >> > Well, the terms ?explicit? and ?implicit? BDA are blurry as well. I_explicitly_ add a beans.xml with version=1.1 and bean-discovery-mode=?annotated? and still it is an ?implicit? BDA according to those definitions. Not very self-explaining but anyway. Has not much to do with the current topic as well, so not sure why you mentioned it? >> > >> > An example of usability would e.g. be the DeltaSpike @MessageBundle feature. Seam3 has had something similar afair. >> > For those who don?t know it see [1]. You basically have an interface and DeltaSpike automatically picks those up and provides implementations for them which are registered as Beans. >> > >> > But in the ?annotated? mode we wont get any PAT for those interfaces anymore. The same mechanism is used tor JPA archives, PropertyFileConfig, etc? >> > Just grep DeltaSpike and check where PAT gets used. It?s all over the place? >> > >> > LieGrue, >> > strub >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150306/1d4a0f9e/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/20150306/1d4a0f9e/attachment-0001.bin From rmannibucau at gmail.com Fri Mar 6 05:06:00 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Fri, 6 Mar 2015 11:06:00 +0100 Subject: [cdi-dev] explicit bean archives discovery-mode 'annotated' In-Reply-To: <2F7838CF-094B-4B36-BFF8-4BB9337A026E@sabot-durand.net> References: <64A8559B-65B5-457B-B5AB-0DF0EAE76A0D@yahoo.de> <54F80BD1.8080603@redhat.com> <689DA50D-EF53-4520-B2B7-265290DBD999@yahoo.de> <54F9532E.7080003@redhat.com> <54F96212.80200@redhat.com> <2F7838CF-094B-4B36-BFF8-4BB9337A026E@sabot-durand.net> Message-ID: that's not fully true Antoine, EJB does at least - but some guice extensions as well. If you have a EE 5/6/7 ejb lib then you can now break where you were not before. On CDI alone side it is fine but not for EE globally. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-03-06 11:01 GMT+01:00 Antoine Sabot-Durand : > I checked that no other IoC framework was using @Interceptor before > proposing the fix in CDI-377 > > > Le 6 mars 2015 ? 09:22, Romain Manni-Bucau a > ?crit : > > Well @Interceptor is widely used elsewhere - that's the main one I can > think about. > > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2015-03-06 9:15 GMT+01:00 Jozef Hartinger : > >> >> On 03/06/2015 09:03 AM, Romain Manni-Bucau wrote: >> >> Hi >> >> Well you cant ask libs to change their programming model for it IMO. It >> is clearly a regression. >> >> Why not? Existing applications (empty beans.xml) will still work as >> before so there is no regression. If a lib wants to support >> bean-discovery-mode="annotated" then it has to adapt. It would be better if >> they did not have to but it's too late at this point. >> >> Another broken case is if any other IoC uses some of these annotations >> but doesnt rely on scanning. Now you scan the jar and can get surprises and >> even an Error. >> >> Yes, this was a risk when implicit bean archives were introduced. This >> was in the end mitigated by only making CDI annotations as bean defining >> (most likely other IoC won't use CDI annotations) plus introducing >> bdm="none" mode. >> >> >> Le 6 mars 2015 08:12, "Jozef Hartinger" a ?crit : >> >>> This interface/enum discovery use-case very often uses a marker >>> annotation (e.g. @MessageBundle). Such extension can work around this >>> limitation by making the marker annotation a @Stereotype. Can you see >>> any other scenarios where implicit bean archives are a problem? >>> >>> On 03/05/2015 09:28 AM, Mark Struberg wrote: >>> > Well, the terms ?explicit? and ?implicit? BDA are blurry as well. >>> I_explicitly_ add a beans.xml with version=1.1 and >>> bean-discovery-mode=?annotated? and still it is an ?implicit? BDA according >>> to those definitions. Not very self-explaining but anyway. Has not much to >>> do with the current topic as well, so not sure why you mentioned it? >>> > >>> > An example of usability would e.g. be the DeltaSpike @MessageBundle >>> feature. Seam3 has had something similar afair. >>> > For those who don?t know it see [1]. You basically have an interface >>> and DeltaSpike automatically picks those up and provides implementations >>> for them which are registered as Beans. >>> > >>> > But in the ?annotated? mode we wont get any PAT for those interfaces >>> anymore. The same mechanism is used tor JPA archives, PropertyFileConfig, >>> etc? >>> > Just grep DeltaSpike and check where PAT gets used. It?s all over the >>> place? >>> > >>> > LieGrue, >>> > strub >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>> provided on this list, the provider waives all patent and other >>> intellectual property rights inherent in such information. >> >> >> > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150306/d69b05a3/attachment.html From antoine at sabot-durand.net Fri Mar 6 05:16:30 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 6 Mar 2015 11:16:30 +0100 Subject: [cdi-dev] explicit bean archives discovery-mode 'annotated' In-Reply-To: References: <64A8559B-65B5-457B-B5AB-0DF0EAE76A0D@yahoo.de> <54F80BD1.8080603@redhat.com> <689DA50D-EF53-4520-B2B7-265290DBD999@yahoo.de> <54F9532E.7080003@redhat.com> <54F96212.80200@redhat.com> <2F7838CF-094B-4B36-BFF8-4BB9337A026E@sabot-durand.net> Message-ID: <5467131C-D10F-4622-8099-5A637FA70C51@sabot-durand.net> > Le 6 mars 2015 ? 11:06, Romain Manni-Bucau a ?crit : > > that's not fully true Antoine, EJB does at least - but some guice extensions as well. If you have a EE 5/6/7 ejb lib then you can now break where you were not before. On CDI alone side it is fine but not for EE globally. Nice feedback if we were march 6th 2014 before end of CDI 1.2 work. CDI-377 and CDI-404 were debated by a lot of people... > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > 2015-03-06 11:01 GMT+01:00 Antoine Sabot-Durand >: > I checked that no other IoC framework was using @Interceptor before proposing the fix in CDI-377 > > >> Le 6 mars 2015 ? 09:22, Romain Manni-Bucau > a ?crit : >> >> Well @Interceptor is widely used elsewhere - that's the main one I can think about. >> >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >> 2015-03-06 9:15 GMT+01:00 Jozef Hartinger >: >> >> On 03/06/2015 09:03 AM, Romain Manni-Bucau wrote: >>> Hi >>> >>> Well you cant ask libs to change their programming model for it IMO. It is clearly a regression. >>> >> Why not? Existing applications (empty beans.xml) will still work as before so there is no regression. If a lib wants to support bean-discovery-mode="annotated" then it has to adapt. It would be better if they did not have to but it's too late at this point. >>> Another broken case is if any other IoC uses some of these annotations but doesnt rely on scanning. Now you scan the jar and can get surprises and even an Error. >> Yes, this was a risk when implicit bean archives were introduced. This was in the end mitigated by only making CDI annotations as bean defining (most likely other IoC won't use CDI annotations) plus introducing bdm="none" mode. >>> >>> Le 6 mars 2015 08:12, "Jozef Hartinger" > a ?crit : >>> This interface/enum discovery use-case very often uses a marker >>> annotation (e.g. @MessageBundle). Such extension can work around this >>> limitation by making the marker annotation a @Stereotype. Can you see >>> any other scenarios where implicit bean archives are a problem? >>> >>> On 03/05/2015 09:28 AM, Mark Struberg wrote: >>> > Well, the terms ?explicit? and ?implicit? BDA are blurry as well. I_explicitly_ add a beans.xml with version=1.1 and bean-discovery-mode=?annotated? and still it is an ?implicit? BDA according to those definitions. Not very self-explaining but anyway. Has not much to do with the current topic as well, so not sure why you mentioned it? >>> > >>> > An example of usability would e.g. be the DeltaSpike @MessageBundle feature. Seam3 has had something similar afair. >>> > For those who don?t know it see [1]. You basically have an interface and DeltaSpike automatically picks those up and provides implementations for them which are registered as Beans. >>> > >>> > But in the ?annotated? mode we wont get any PAT for those interfaces anymore. The same mechanism is used tor JPA archives, PropertyFileConfig, etc? >>> > Just grep DeltaSpike and check where PAT gets used. It?s all over the place? >>> > >>> > LieGrue, >>> > strub >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150306/9213ed30/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/20150306/9213ed30/attachment-0001.bin From issues at jboss.org Sun Mar 8 13:41:18 2015 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Sun, 8 Mar 2015 13:41:18 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-516) Firing events with dynamic parameterized types In-Reply-To: References: Message-ID: Antonin Stefanutti created CDI-516: -------------------------------------- Summary: Firing events with dynamic parameterized types Key: CDI-516 URL: https://issues.jboss.org/browse/CDI-516 Project: CDI Specification Issues Issue Type: Feature Request Components: Events Reporter: Antonin Stefanutti For the time being, either by using {{Event.select(...)}}, respectively {{BeanManager.fireEvent(...)}}, it is not possible to fire an event whose runtime type is a dynamic parameterized type, as specified in [The {{Event}} interface|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#event]: {quote} If the container is unable to resolve the parameterized type of the event object, it uses the specified type to infer the parameterized type of the event types. If the runtime type of the event object contains an unresolvable type variable, an {{IllegalArgumentException}} is thrown. {quote} Respectively in [Firing an event|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bm_fire_event]: {quote} If the runtime type of the event object contains a type variable, an {{IllegalArgumentException}} is thrown. {quote} While, it is possible to pass a {{TypeLiteral}} to the {{Event.select(...)}} method, e.g.: {code} @Inject Event event; event.select(new TypeLiteral() {}); {code} It is not possible to pass a type variable known at runtime as the {{TypeLiteral}} class relies on the declared type variable and does not permit to override that behavior as the {{TypeLiteral.getType()}} method is declared {{final}}. Yet, there are use cases where that need is valid, for example: {code} CdiEventEndpoint cdiEventEndpoint(InjectionPoint ip, CamelContext context, @Any Event event) throws Exception { // Represents the runtime type for T Type type = ((ParameterizedType) ip.getType()).getActualTypeArguments()[0]; String uri = endpointUri(type, ip.getQualifiers()); if (context.hasEndpoint(uri) == null) { // Work around to pass the dynamic type TypeLiteral literal = new TypeLiteral() {}; for (Field field : TypeLiteral.class.getDeclaredFields()) { if (field.getType().equals(Type.class)) { field.setAccessible(true); field.set(literal, type); break; } } // Here we used the dynamic type Event typedEvent = event.select(literal, ip.getQualifiers().toArray(new Annotation[ip.getQualifiers().size()])); context.addEndpoint(uri, new CdiEventEndpoint<>(typedEvent, uri, context)); } return CamelContextHelper.getMandatoryEndpoint(context, uri, CdiEventEndpoint.class); } {code} In the example above, the {{TypeLiteral}} class could have a constructor taking the dynamic type as argument. Another alternative would be to enrich the {{BeanManager}} SPI with the following method: {code} public void fireEvent(Object event, Type type, Annotation... qualifiers); {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Mar 8 13:49:18 2015 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Sun, 8 Mar 2015 13:49:18 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-516) Firing events with dynamic parameterized types In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonin Stefanutti updated CDI-516: ----------------------------------- Description: For the time being, either by using {{Event.select(...)}}, respectively {{BeanManager.fireEvent(...)}}, it is not possible to fire an event whose runtime type is a dynamic parameterized type, as specified in [The {{Event}} interface|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#event]: {quote} If the container is unable to resolve the parameterized type of the event object, it uses the specified type to infer the parameterized type of the event types. If the runtime type of the event object contains an unresolvable type variable, an {{IllegalArgumentException}} is thrown. {quote} Respectively in [Firing an event|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bm_fire_event]: {quote} If the runtime type of the event object contains a type variable, an {{IllegalArgumentException}} is thrown. {quote} While, it is possible to pass a {{TypeLiteral}} to the {{Event.select(...)}} method, e.g.: {code} @Inject Event event; event.select(new TypeLiteral() {}); {code} It is not possible to pass a type variable known at runtime as the {{TypeLiteral}} class relies on the declared type variable and does not permit to override that behavior as the {{TypeLiteral.getType()}} method is declared {{final}}. Yet, there are use cases where that need is valid, for example: {code} CdiEventEndpoint cdiEventEndpoint(InjectionPoint ip, CamelContext context, @Any Event event) throws Exception { // Represents the runtime type for T Type type = ((ParameterizedType) ip.getType()).getActualTypeArguments()[0]; String uri = endpointUri(type, ip.getQualifiers()); if (context.hasEndpoint(uri) == null) { // Work around to pass the dynamic type TypeLiteral literal = new TypeLiteral() {}; for (Field field : TypeLiteral.class.getDeclaredFields()) { if (field.getType().equals(Type.class)) { field.setAccessible(true); field.set(literal, type); break; } } // Here we used the dynamic type Event typedEvent = event.select(literal, ip.getQualifiers().toArray(new Annotation[ip.getQualifiers().size()])); context.addEndpoint(uri, new CdiEventEndpoint<>(typedEvent, uri, context)); } return CamelContextHelper.getMandatoryEndpoint(context, uri, CdiEventEndpoint.class); } {code} In the example above, the {{TypeLiteral}} class could have a constructor taking the dynamic type as argument. Another alternative would be to enrich the {{BeanManager}} SPI with the following method: {code} public void fireEvent(Object event, Type type, Annotation... qualifiers); {code} That use case is taken from the [CDI event Camel endpoint|https://github.com/astefanutti/camel-cdi/blob/84426570bcd7815eb98f87b07739aa9ddfc44191/impl/src/main/java/org/apache/camel/cdi/CdiCamelFactory.java#L91] in the [Camel CDI extension|https://github.com/astefanutti/camel-cdi]. was: For the time being, either by using {{Event.select(...)}}, respectively {{BeanManager.fireEvent(...)}}, it is not possible to fire an event whose runtime type is a dynamic parameterized type, as specified in [The {{Event}} interface|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#event]: {quote} If the container is unable to resolve the parameterized type of the event object, it uses the specified type to infer the parameterized type of the event types. If the runtime type of the event object contains an unresolvable type variable, an {{IllegalArgumentException}} is thrown. {quote} Respectively in [Firing an event|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bm_fire_event]: {quote} If the runtime type of the event object contains a type variable, an {{IllegalArgumentException}} is thrown. {quote} While, it is possible to pass a {{TypeLiteral}} to the {{Event.select(...)}} method, e.g.: {code} @Inject Event event; event.select(new TypeLiteral() {}); {code} It is not possible to pass a type variable known at runtime as the {{TypeLiteral}} class relies on the declared type variable and does not permit to override that behavior as the {{TypeLiteral.getType()}} method is declared {{final}}. Yet, there are use cases where that need is valid, for example: {code} CdiEventEndpoint cdiEventEndpoint(InjectionPoint ip, CamelContext context, @Any Event event) throws Exception { // Represents the runtime type for T Type type = ((ParameterizedType) ip.getType()).getActualTypeArguments()[0]; String uri = endpointUri(type, ip.getQualifiers()); if (context.hasEndpoint(uri) == null) { // Work around to pass the dynamic type TypeLiteral literal = new TypeLiteral() {}; for (Field field : TypeLiteral.class.getDeclaredFields()) { if (field.getType().equals(Type.class)) { field.setAccessible(true); field.set(literal, type); break; } } // Here we used the dynamic type Event typedEvent = event.select(literal, ip.getQualifiers().toArray(new Annotation[ip.getQualifiers().size()])); context.addEndpoint(uri, new CdiEventEndpoint<>(typedEvent, uri, context)); } return CamelContextHelper.getMandatoryEndpoint(context, uri, CdiEventEndpoint.class); } {code} In the example above, the {{TypeLiteral}} class could have a constructor taking the dynamic type as argument. Another alternative would be to enrich the {{BeanManager}} SPI with the following method: {code} public void fireEvent(Object event, Type type, Annotation... qualifiers); {code} > Firing events with dynamic parameterized types > ---------------------------------------------- > > Key: CDI-516 > URL: https://issues.jboss.org/browse/CDI-516 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Reporter: Antonin Stefanutti > > For the time being, either by using {{Event.select(...)}}, respectively {{BeanManager.fireEvent(...)}}, it is not possible to fire an event whose runtime type is a dynamic parameterized type, as specified in [The {{Event}} interface|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#event]: > {quote} > If the container is unable to resolve the parameterized type of the event object, it uses the specified type to infer the parameterized type of the event types. > If the runtime type of the event object contains an unresolvable type variable, an {{IllegalArgumentException}} is thrown. > {quote} > Respectively in [Firing an event|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bm_fire_event]: > {quote} > If the runtime type of the event object contains a type variable, an {{IllegalArgumentException}} is thrown. > {quote} > While, it is possible to pass a {{TypeLiteral}} to the {{Event.select(...)}} method, e.g.: > {code} > @Inject > Event event; > event.select(new TypeLiteral() {}); > {code} > It is not possible to pass a type variable known at runtime as the {{TypeLiteral}} class relies on the declared type variable and does not permit to override that behavior as the {{TypeLiteral.getType()}} method is declared {{final}}. > Yet, there are use cases where that need is valid, for example: > {code} > CdiEventEndpoint cdiEventEndpoint(InjectionPoint ip, CamelContext context, @Any Event event) throws Exception { > // Represents the runtime type for T > Type type = ((ParameterizedType) ip.getType()).getActualTypeArguments()[0]; > String uri = endpointUri(type, ip.getQualifiers()); > if (context.hasEndpoint(uri) == null) { > // Work around to pass the dynamic type > TypeLiteral literal = new TypeLiteral() {}; > for (Field field : TypeLiteral.class.getDeclaredFields()) { > if (field.getType().equals(Type.class)) { > field.setAccessible(true); > field.set(literal, type); > break; > } > } > // Here we used the dynamic type > Event typedEvent = event.select(literal, ip.getQualifiers().toArray(new Annotation[ip.getQualifiers().size()])); > context.addEndpoint(uri, new CdiEventEndpoint<>(typedEvent, uri, context)); > } > return CamelContextHelper.getMandatoryEndpoint(context, uri, CdiEventEndpoint.class); > } > {code} > In the example above, the {{TypeLiteral}} class could have a constructor taking the dynamic type as argument. > Another alternative would be to enrich the {{BeanManager}} SPI with the following method: > {code} > public void fireEvent(Object event, Type type, Annotation... qualifiers); > {code} > That use case is taken from the [CDI event Camel endpoint|https://github.com/astefanutti/camel-cdi/blob/84426570bcd7815eb98f87b07739aa9ddfc44191/impl/src/main/java/org/apache/camel/cdi/CdiCamelFactory.java#L91] in the [Camel CDI extension|https://github.com/astefanutti/camel-cdi]. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Mar 8 16:21:18 2015 From: issues at jboss.org (Sven Linstaedt (JIRA)) Date: Sun, 8 Mar 2015 16:21:18 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-516) Firing events with dynamic parameterized types In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13047216#comment-13047216 ] Sven Linstaedt commented on CDI-516: ------------------------------------ Opting for the second solution, as application code should not have to deal with java.lang.reflect.* and framework code (that needs to handle generic types) should not have to mess around with convenience oriented Instance- or Event-related code. > Firing events with dynamic parameterized types > ---------------------------------------------- > > Key: CDI-516 > URL: https://issues.jboss.org/browse/CDI-516 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Reporter: Antonin Stefanutti > > For the time being, either by using {{Event.select(...)}}, respectively {{BeanManager.fireEvent(...)}}, it is not possible to fire an event whose runtime type is a dynamic parameterized type, as specified in [The {{Event}} interface|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#event]: > {quote} > If the container is unable to resolve the parameterized type of the event object, it uses the specified type to infer the parameterized type of the event types. > If the runtime type of the event object contains an unresolvable type variable, an {{IllegalArgumentException}} is thrown. > {quote} > Respectively in [Firing an event|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bm_fire_event]: > {quote} > If the runtime type of the event object contains a type variable, an {{IllegalArgumentException}} is thrown. > {quote} > While, it is possible to pass a {{TypeLiteral}} to the {{Event.select(...)}} method, e.g.: > {code} > @Inject > Event event; > event.select(new TypeLiteral() {}); > {code} > It is not possible to pass a type variable known at runtime as the {{TypeLiteral}} class relies on the declared type variable and does not permit to override that behavior as the {{TypeLiteral.getType()}} method is declared {{final}}. > Yet, there are use cases where that need is valid, for example: > {code} > CdiEventEndpoint cdiEventEndpoint(InjectionPoint ip, CamelContext context, @Any Event event) throws Exception { > // Represents the runtime type for T > Type type = ((ParameterizedType) ip.getType()).getActualTypeArguments()[0]; > String uri = endpointUri(type, ip.getQualifiers()); > if (context.hasEndpoint(uri) == null) { > // Work around to pass the dynamic type > TypeLiteral literal = new TypeLiteral() {}; > for (Field field : TypeLiteral.class.getDeclaredFields()) { > if (field.getType().equals(Type.class)) { > field.setAccessible(true); > field.set(literal, type); > break; > } > } > // Here we used the dynamic type > Event typedEvent = event.select(literal, ip.getQualifiers().toArray(new Annotation[ip.getQualifiers().size()])); > context.addEndpoint(uri, new CdiEventEndpoint<>(typedEvent, uri, context)); > } > return CamelContextHelper.getMandatoryEndpoint(context, uri, CdiEventEndpoint.class); > } > {code} > In the example above, the {{TypeLiteral}} class could have a constructor taking the dynamic type as argument. > Another alternative would be to enrich the {{BeanManager}} SPI with the following method: > {code} > public void fireEvent(Object event, Type type, Annotation... qualifiers); > {code} > That use case is taken from the [CDI event Camel endpoint|https://github.com/astefanutti/camel-cdi/blob/84426570bcd7815eb98f87b07739aa9ddfc44191/impl/src/main/java/org/apache/camel/cdi/CdiCamelFactory.java#L91] in the [Camel CDI extension|https://github.com/astefanutti/camel-cdi]. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From struberg at yahoo.de Mon Mar 9 04:52:32 2015 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 9 Mar 2015 09:52:32 +0100 Subject: [cdi-dev] [weld-dev] How to skip CDI injection if a property is not configured in batch application? In-Reply-To: <54FD3CE0.1070706@redhat.com> References: <54FB2D34.5090005@redhat.com> <54FD3CE0.1070706@redhat.com> Message-ID: <105DD0AB-949B-42D0-AD7C-9A71DB832432@yahoo.de> There is an easy trick though which we do at BatchEE: The producer is @Dependent. So you can simply inject the InjectionPoint and inspect the current value in case it is not yet set. LieGrue, strub > Am 09.03.2015 um 07:25 schrieb Jozef Hartinger : > > Adding weld-dev. > > Hi Cheng, > > by defining a producer method you are basically saying "I am able to supply an object for this given type/qualifier combination". There is not way to opt out of it at runtime. Are you concerned about the JVM default values or the default values a user has provided? > > Jozef > > On 03/07/2015 05:54 PM, Cheng Fang wrote: >> Hi Jozef, >> >> I'm having a question in using CDI injection in project JBeret (batch impl project), and would appreciate any help from you. >> >> A batch application (in Java SE or EE) can inject configured batch properties into batch artifact classes: >> >> @Inject >> @javax.batch.api.BatchProperty(name = "batchPropName") >> String batchPropName = "default name"; >> >> The property value comes from job.xml, which is the batch job definition descriptor file: >> >> >> >> >> >> ... >> >> When "batchPropName" property is not configured in job.xml, the injection should not happen, and whatever java default field value should be preserved for batchPropName field. >> >> With our current batch CDI extension [1] and producer bean [2], it injects a null value into this field, overwriting the java default value, when the target batch property is not present. >> >> How to signal to Weld to skip performing the injection for those injection targets? Ideally, I hope it can be done from within producer methods, which is the place we retrieve batch properties and know whether they exist or not. >> >> I think this is also how Java EE field injection works. How do we handle it in EE, and is it something I can mirror? >> >> Thanks, >> Cheng >> >> [1] https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/creation/BatchCDIExtension.java >> >> [2] https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/creation/BatchBeanProducer.java >> >> > > _______________________________________________ > weld-dev mailing list > weld-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev From struberg at yahoo.de Mon Mar 9 04:53:50 2015 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 9 Mar 2015 09:53:50 +0100 Subject: [cdi-dev] [weld-dev] How to skip CDI injection if a property is not configured in batch application? In-Reply-To: <54FD4033.2030706@redhat.com> References: <54FB2D34.5090005@redhat.com> <54FD3CE0.1070706@redhat.com> <54FD4033.2030706@redhat.com> Message-ID: Not possible. The jobs can also only get added at runtime. So you don not have this information during bootstrap. LieGrue, strub > Am 09.03.2015 um 07:39 schrieb Jozef Hartinger : > > You can actually work around by listening to ProcessAnnotatedType and removing the @Inject annotation from injection points for which there is no value to inject. Is the set of defined key-value pairs known at the time when the CDI extension is called? > > Jozef > > On 03/09/2015 07:25 AM, Jozef Hartinger wrote: >> Adding weld-dev. >> >> Hi Cheng, >> >> by defining a producer method you are basically saying "I am able to supply an object for this given type/qualifier combination". There is not way to opt out of it at runtime. Are you concerned about the JVM default values or the default values a user has provided? >> >> Jozef >> >> On 03/07/2015 05:54 PM, Cheng Fang wrote: >>> Hi Jozef, >>> >>> I'm having a question in using CDI injection in project JBeret (batch impl project), and would appreciate any help from you. >>> >>> A batch application (in Java SE or EE) can inject configured batch properties into batch artifact classes: >>> >>> @Inject >>> @javax.batch.api.BatchProperty(name = "batchPropName") >>> String batchPropName = "default name"; >>> >>> The property value comes from job.xml, which is the batch job definition descriptor file: >>> >>> >>> >>> >>> >>> ... >>> >>> When "batchPropName" property is not configured in job.xml, the injection should not happen, and whatever java default field value should be preserved for batchPropName field. >>> >>> With our current batch CDI extension [1] and producer bean [2], it injects a null value into this field, overwriting the java default value, when the target batch property is not present. >>> >>> How to signal to Weld to skip performing the injection for those injection targets? Ideally, I hope it can be done from within producer methods, which is the place we retrieve batch properties and know whether they exist or not. >>> >>> I think this is also how Java EE field injection works. How do we handle it in EE, and is it something I can mirror? >>> >>> Thanks, >>> Cheng >>> >>> [1] https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/creation/BatchCDIExtension.java >>> >>> [2] https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/creation/BatchBeanProducer.java >>> >>> >> >> >> >> _______________________________________________ >> weld-dev mailing list >> >> weld-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/weld-dev > > _______________________________________________ > weld-dev mailing list > weld-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev From jharting at redhat.com Mon Mar 9 05:32:48 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Mon, 09 Mar 2015 10:32:48 +0100 Subject: [cdi-dev] [weld-dev] How to skip CDI injection if a property is not configured in batch application? In-Reply-To: <105DD0AB-949B-42D0-AD7C-9A71DB832432@yahoo.de> References: <54FB2D34.5090005@redhat.com> <54FD3CE0.1070706@redhat.com> <105DD0AB-949B-42D0-AD7C-9A71DB832432@yahoo.de> Message-ID: <54FD68C0.5060003@redhat.com> How do you obtain the current value of a field from an InjectionPoint? Do you use proprietary APIs for that? Jozef On 03/09/2015 09:52 AM, Mark Struberg wrote: > There is an easy trick though which we do at BatchEE: > The producer is @Dependent. So you can simply inject the InjectionPoint and inspect the current value in case it is not yet set. > > LieGrue, > strub > > >> Am 09.03.2015 um 07:25 schrieb Jozef Hartinger : >> >> Adding weld-dev. >> >> Hi Cheng, >> >> by defining a producer method you are basically saying "I am able to supply an object for this given type/qualifier combination". There is not way to opt out of it at runtime. Are you concerned about the JVM default values or the default values a user has provided? >> >> Jozef >> >> On 03/07/2015 05:54 PM, Cheng Fang wrote: >>> Hi Jozef, >>> >>> I'm having a question in using CDI injection in project JBeret (batch impl project), and would appreciate any help from you. >>> >>> A batch application (in Java SE or EE) can inject configured batch properties into batch artifact classes: >>> >>> @Inject >>> @javax.batch.api.BatchProperty(name = "batchPropName") >>> String batchPropName = "default name"; >>> >>> The property value comes from job.xml, which is the batch job definition descriptor file: >>> >>> >>> >>> >>> >>> ... >>> >>> When "batchPropName" property is not configured in job.xml, the injection should not happen, and whatever java default field value should be preserved for batchPropName field. >>> >>> With our current batch CDI extension [1] and producer bean [2], it injects a null value into this field, overwriting the java default value, when the target batch property is not present. >>> >>> How to signal to Weld to skip performing the injection for those injection targets? Ideally, I hope it can be done from within producer methods, which is the place we retrieve batch properties and know whether they exist or not. >>> >>> I think this is also how Java EE field injection works. How do we handle it in EE, and is it something I can mirror? >>> >>> Thanks, >>> Cheng >>> >>> [1] https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/creation/BatchCDIExtension.java >>> >>> [2] https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/creation/BatchBeanProducer.java >>> >>> >> _______________________________________________ >> weld-dev mailing list >> weld-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/weld-dev > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From jharting at redhat.com Mon Mar 9 05:48:39 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Mon, 09 Mar 2015 10:48:39 +0100 Subject: [cdi-dev] [weld-dev] How to skip CDI injection if a property is not configured in batch application? In-Reply-To: <54FD68C0.5060003@redhat.com> References: <54FB2D34.5090005@redhat.com> <54FD3CE0.1070706@redhat.com> <105DD0AB-949B-42D0-AD7C-9A71DB832432@yahoo.de> <54FD68C0.5060003@redhat.com> Message-ID: <54FD6C77.7080705@redhat.com> Moving the thread back to weld-dev On 03/09/2015 10:32 AM, Jozef Hartinger wrote: > How do you obtain the current value of a field from an InjectionPoint? > Do you use proprietary APIs for that? > > Jozef > > On 03/09/2015 09:52 AM, Mark Struberg wrote: >> There is an easy trick though which we do at BatchEE: >> The producer is @Dependent. So you can simply inject the InjectionPoint and inspect the current value in case it is not yet set. >> >> LieGrue, >> strub >> >> >>> Am 09.03.2015 um 07:25 schrieb Jozef Hartinger : >>> >>> Adding weld-dev. >>> >>> Hi Cheng, >>> >>> by defining a producer method you are basically saying "I am able to supply an object for this given type/qualifier combination". There is not way to opt out of it at runtime. Are you concerned about the JVM default values or the default values a user has provided? >>> >>> Jozef >>> >>> On 03/07/2015 05:54 PM, Cheng Fang wrote: >>>> Hi Jozef, >>>> >>>> I'm having a question in using CDI injection in project JBeret (batch impl project), and would appreciate any help from you. >>>> >>>> A batch application (in Java SE or EE) can inject configured batch properties into batch artifact classes: >>>> >>>> @Inject >>>> @javax.batch.api.BatchProperty(name = "batchPropName") >>>> String batchPropName = "default name"; >>>> >>>> The property value comes from job.xml, which is the batch job definition descriptor file: >>>> >>>> >>>> >>>> >>>> >>>> ... >>>> >>>> When "batchPropName" property is not configured in job.xml, the injection should not happen, and whatever java default field value should be preserved for batchPropName field. >>>> >>>> With our current batch CDI extension [1] and producer bean [2], it injects a null value into this field, overwriting the java default value, when the target batch property is not present. >>>> >>>> How to signal to Weld to skip performing the injection for those injection targets? Ideally, I hope it can be done from within producer methods, which is the place we retrieve batch properties and know whether they exist or not. >>>> >>>> I think this is also how Java EE field injection works. How do we handle it in EE, and is it something I can mirror? >>>> >>>> Thanks, >>>> Cheng >>>> >>>> [1] https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/creation/BatchCDIExtension.java >>>> >>>> [2] https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/creation/BatchBeanProducer.java >>>> >>>> >>> _______________________________________________ >>> weld-dev mailing list >>> weld-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/weld-dev >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From antoine at sabot-durand.net Mon Mar 9 06:40:27 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 9 Mar 2015 11:40:27 +0100 Subject: [cdi-dev] Changing our meeting time slot? Message-ID: Hi all, Following last week discussion, you?ll find a Doodle link below to choose your the best time slot for our meeting. I propose time slot on several days for 6-7pm CET or 8-9pm CET (I?m usually not available between 7-8pm). I took into consideration USA and Europe (majority of us) TZ. Please fill the doodle so we could change our meeting slot and have more people able to join. http://doodle.com/izh845adznk37vww thanks Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150309/90a37dbe/attachment.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/20150309/90a37dbe/attachment.bin From issues at jboss.org Mon Mar 9 18:02:18 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Mon, 9 Mar 2015 18:02:18 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-517) assignability to parameterized required type In-Reply-To: References: Message-ID: Mark Struberg created CDI-517: --------------------------------- Summary: assignability to parameterized required type Key: CDI-517 URL: https://issues.jboss.org/browse/CDI-517 Project: CDI Specification Issues Issue Type: Bug Components: Resolution Affects Versions: 1.2.Final, 1.1.PFD Reporter: Mark Struberg 2 days before the CDI-1.1 spec went PDF the following backward-incomatible change was made: {quote} -A raw bean type is considered assignable to a parameterized required type if the raw types are identical. + A raw bean type is considered assignable to a parameterized required type if the raw types are identical and all type parameters of the bean type are either unbounded type variables or java.lang.Object. {quote} This breaks a lot of projects and also is also not compatible with the JavaEE6 RI and the CDI-1.0 RI where this was explicitly allowed. This is a follow up to CDI-304. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Mar 9 18:20:18 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Mon, 9 Mar 2015 18:20:18 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-517) assignability to parameterized required type In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048390#comment-13048390 ] Mark Struberg commented on CDI-517: ----------------------------------- wrote a small sample app to demonstrate the difference in behaviour with old and new containers. https://github.com/struberg/cdispec-517 > assignability to parameterized required type > -------------------------------------------- > > Key: CDI-517 > URL: https://issues.jboss.org/browse/CDI-517 > Project: CDI Specification Issues > Issue Type: Bug > Components: Resolution > Affects Versions: 1.1.PFD, 1.2.Final > Reporter: Mark Struberg > > 2 days before the CDI-1.1 spec went PDF the following backward-incomatible change was made: > {quote} > -A raw bean type is considered assignable to a parameterized required type if the raw types are identical. > + A raw bean type is considered assignable to a parameterized required type if the raw types are identical and all type parameters of the bean type are either unbounded type variables or java.lang.Object. > {quote} > This breaks a lot of projects and also is also not compatible with the JavaEE6 RI and the CDI-1.0 RI where this was explicitly allowed. > This is a follow up to CDI-304. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Mar 10 03:40:18 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 10 Mar 2015 03:40:18 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-517) assignability to parameterized required type In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048442#comment-13048442 ] Martin Kouba commented on CDI-517: ---------------------------------- Well, it was added in this commit [42f5f8ec974e24dfdca5c34eadd3f85785077ca5|https://github.com/cdi-spec/cdi/commit/42f5f8ec974e24dfdca5c34eadd3f85785077ca5] (authored on 25 Feb 2013), the Proposed Final Draft was published on *06 Mar, 2013*, and the Final Release was on *24 May, 2013*. That's enough time for revision. It was also discussed in [DELTASPIKE-295|https://issues.apache.org/jira/browse/DELTASPIKE-295]. So I don't understand your "2 days" sentence. In any case, it is incompatible in the sense that it *was not defined in CDI 1.0*. And in my opinion it was a mistake. Also note that it's very easy to fix (and follow the rules explicitly defined in the CDI spec): http://grepcode.com/file/repo1.maven.org/maven2/org.apache.deltaspike.modules/deltaspike-jsf-module-impl/1.2.1/org/apache/deltaspike/jsf/impl/message/JsfMessageProducer.java#40 Honestly Mark, do you think it's correct to allow something like this? {code:java} class Foo { private T ref; public Foo(T ref) { this.ref = ref; } } @Produces Foo createFoo() { Foo foo = new Foo(10); return foo; } // The producer would be assignable... @Inject Foo stringFoo; {code} > assignability to parameterized required type > -------------------------------------------- > > Key: CDI-517 > URL: https://issues.jboss.org/browse/CDI-517 > Project: CDI Specification Issues > Issue Type: Bug > Components: Resolution > Affects Versions: 1.1.PFD, 1.2.Final > Reporter: Mark Struberg > > 2 days before the CDI-1.1 spec went PDF the following backward-incomatible change was made: > {quote} > -A raw bean type is considered assignable to a parameterized required type if the raw types are identical. > + A raw bean type is considered assignable to a parameterized required type if the raw types are identical and all type parameters of the bean type are either unbounded type variables or java.lang.Object. > {quote} > This breaks a lot of projects and also is also not compatible with the JavaEE6 RI and the CDI-1.0 RI where this was explicitly allowed. > This is a follow up to CDI-304. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Mar 10 04:48:18 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Tue, 10 Mar 2015 04:48:18 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-517) assignability to parameterized required type In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048460#comment-13048460 ] Mark Struberg commented on CDI-517: ----------------------------------- It's at least fine from a pure Java aspect. See the discussion over at DeltaSpike LONG before this change got made to the spec. The problem is that there are many libraries and customer projects out there which behave that way (returning a raw type in the producer) and I gave all the arguments already in CID-304. Also note that returning a ParameterizedType does NOT work in the EE6 RI, nor in WebSphere and also not in older JBossAS versions. Been there, done that... > assignability to parameterized required type > -------------------------------------------- > > Key: CDI-517 > URL: https://issues.jboss.org/browse/CDI-517 > Project: CDI Specification Issues > Issue Type: Bug > Components: Resolution > Affects Versions: 1.1.PFD, 1.2.Final > Reporter: Mark Struberg > > 2 days before the CDI-1.1 spec went PDF the following backward-incomatible change was made: > {quote} > -A raw bean type is considered assignable to a parameterized required type if the raw types are identical. > + A raw bean type is considered assignable to a parameterized required type if the raw types are identical and all type parameters of the bean type are either unbounded type variables or java.lang.Object. > {quote} > This breaks a lot of projects and also is also not compatible with the JavaEE6 RI and the CDI-1.0 RI where this was explicitly allowed. > This is a follow up to CDI-304. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Mar 10 04:49:18 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Tue, 10 Mar 2015 04:49:18 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-517) assignability to parameterized required type In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048460#comment-13048460 ] Mark Struberg edited comment on CDI-517 at 3/10/15 4:48 AM: ------------------------------------------------------------ It's at least fine from a pure Java aspect. See the discussion over at DeltaSpike LONG before this change got made to the spec. The problem is that there are many libraries and customer projects out there which behave that way (returning a raw type in the producer) and I gave all the arguments already in CDI-304. Also note that returning a ParameterizedType does NOT work in the EE6 RI, nor in WebSphere and also not in older JBossAS versions. Been there, done that... was (Author: struberg): It's at least fine from a pure Java aspect. See the discussion over at DeltaSpike LONG before this change got made to the spec. The problem is that there are many libraries and customer projects out there which behave that way (returning a raw type in the producer) and I gave all the arguments already in CID-304. Also note that returning a ParameterizedType does NOT work in the EE6 RI, nor in WebSphere and also not in older JBossAS versions. Been there, done that... > assignability to parameterized required type > -------------------------------------------- > > Key: CDI-517 > URL: https://issues.jboss.org/browse/CDI-517 > Project: CDI Specification Issues > Issue Type: Bug > Components: Resolution > Affects Versions: 1.1.PFD, 1.2.Final > Reporter: Mark Struberg > > 2 days before the CDI-1.1 spec went PDF the following backward-incomatible change was made: > {quote} > -A raw bean type is considered assignable to a parameterized required type if the raw types are identical. > + A raw bean type is considered assignable to a parameterized required type if the raw types are identical and all type parameters of the bean type are either unbounded type variables or java.lang.Object. > {quote} > This breaks a lot of projects and also is also not compatible with the JavaEE6 RI and the CDI-1.0 RI where this was explicitly allowed. > This is a follow up to CDI-304. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Mar 10 05:09:18 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 10 Mar 2015 05:09:18 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-517) assignability to parameterized required type In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048471#comment-13048471 ] Martin Kouba commented on CDI-517: ---------------------------------- bq. It's at least fine from a pure Java aspect Works but it's not recommended and you get a compiler warning. bq. Also note that returning a ParameterizedType does NOT work in the EE6 RI, nor in WebSphere and also not in older JBossAS versions. I don't understand. There is a TCK test (since 1.0.x) for a producer method which returns a parameterized type: [ProducerMethodDefinitionTest#testParameterizedReturnType()|https://github.com/cdi-spec/cdi-tck/blob/1.0/impl/src/main/java/org/jboss/jsr299/tck/tests/implementation/producer/method/definition/ProducerMethodDefinitionTest.java#L84]. > assignability to parameterized required type > -------------------------------------------- > > Key: CDI-517 > URL: https://issues.jboss.org/browse/CDI-517 > Project: CDI Specification Issues > Issue Type: Bug > Components: Resolution > Affects Versions: 1.1.PFD, 1.2.Final > Reporter: Mark Struberg > > 2 days before the CDI-1.1 spec went PDF the following backward-incomatible change was made: > {quote} > -A raw bean type is considered assignable to a parameterized required type if the raw types are identical. > + A raw bean type is considered assignable to a parameterized required type if the raw types are identical and all type parameters of the bean type are either unbounded type variables or java.lang.Object. > {quote} > This breaks a lot of projects and also is also not compatible with the JavaEE6 RI and the CDI-1.0 RI where this was explicitly allowed. > This is a follow up to CDI-304. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From werner.keil at gmail.com Tue Mar 10 05:10:08 2015 From: werner.keil at gmail.com (Werner Keil) Date: Tue, 10 Mar 2015 10:10:08 +0100 Subject: [cdi-dev] Changing our meeting time slot? Message-ID: Hi, Just filled out my preferences. Note, the strong occurrence of 2-3 calls (EC/JSR 364 and 362) makes Tue hard for me, especially the 6pm slot. As of now the client's site and firewall blocks everything including the web IRC clients. Which is why 8pm is the safer option (I am home practically every day before 8) for the next few months. Werner On Tue, Mar 10, 2015 at 9:48 AM, wrote: > Send cdi-dev mailing list submissions to > cdi-dev at lists.jboss.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.jboss.org/mailman/listinfo/cdi-dev > or, via email, send a message with subject or body 'help' to > cdi-dev-request at lists.jboss.org > > You can reach the person managing the list at > cdi-dev-owner at lists.jboss.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of cdi-dev digest..." > > > Today's Topics: > > 1. Re: [weld-dev] How to skip CDI injection if a property is not > configured in batch application? (Jozef Hartinger) > 2. Re: [weld-dev] How to skip CDI injection if a property is not > configured in batch application? (Jozef Hartinger) > 3. Changing our meeting time slot? (Antoine Sabot-Durand) > 4. [JBoss JIRA] (CDI-517) assignability to parameterized > required type (Mark Struberg (JIRA)) > 5. [JBoss JIRA] (CDI-517) assignability to parameterized > required type (Mark Struberg (JIRA)) > 6. [JBoss JIRA] (CDI-517) assignability to parameterized > required type (Martin Kouba (JIRA)) > 7. [JBoss JIRA] (CDI-517) assignability to parameterized > required type (Mark Struberg (JIRA)) > > > ---------------------------------------------------------------------- > > > Message: 3 > Date: Mon, 9 Mar 2015 11:40:27 +0100 > From: Antoine Sabot-Durand > Subject: [cdi-dev] Changing our meeting time slot? > To: cdi-dev > Message-ID: > Content-Type: text/plain; charset="utf-8" > > Hi all, > > Following last week discussion, you?ll find a Doodle link below to choose > your the best time slot for our meeting. I propose time slot on several > days for 6-7pm CET or 8-9pm CET (I?m usually not available between 7-8pm). > I took into consideration USA and Europe (majority of us) TZ. > Please fill the doodle so we could change our meeting slot and have more > people able to join. > > http://doodle.com/izh845adznk37vww > > thanks > > Antoine > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20150309/90a37dbe/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/20150309/90a37dbe/attachment-0001.bin > > ------------------------------ > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > End of cdi-dev Digest, Vol 52, Issue 45 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150310/c22a144f/attachment.html From issues at jboss.org Tue Mar 10 06:04:18 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Tue, 10 Mar 2015 06:04:18 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-517) assignability to parameterized required type In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048489#comment-13048489 ] Mark Struberg commented on CDI-517: ----------------------------------- This is close to impossible. Check out my sample app. It runs fine on Weld-1.1.23.Final but is broken in Weld-2. If there would be a working CDI-1.0 TCK test this would mean that Weld-1 does not pass the TCK. That's highly unlikely... > assignability to parameterized required type > -------------------------------------------- > > Key: CDI-517 > URL: https://issues.jboss.org/browse/CDI-517 > Project: CDI Specification Issues > Issue Type: Bug > Components: Resolution > Affects Versions: 1.1.PFD, 1.2.Final > Reporter: Mark Struberg > > 2 days before the CDI-1.1 spec went PDF the following backward-incomatible change was made: > {quote} > -A raw bean type is considered assignable to a parameterized required type if the raw types are identical. > + A raw bean type is considered assignable to a parameterized required type if the raw types are identical and all type parameters of the bean type are either unbounded type variables or java.lang.Object. > {quote} > This breaks a lot of projects and also is also not compatible with the JavaEE6 RI and the CDI-1.0 RI where this was explicitly allowed. > This is a follow up to CDI-304. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Mar 10 07:29:18 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 10 Mar 2015 07:29:18 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-517) assignability to parameterized required type In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048526#comment-13048526 ] Martin Kouba commented on CDI-517: ---------------------------------- bq. Check out my sample app. It runs fine on Weld-1.1.23.Final but is broken in Weld-2. This is expected. bq. If there would be a working CDI-1.0 TCK test this would mean that Weld-1 does not pass the TCK. Could you be more specific? What does it mean _"returning a ParameterizedType does NOT work in the EE6 RI"_? There is no test for assignability of a raw return type to a parameterized required type. But there's a test for assignability of a parameterized return type to a parameterized required type. > assignability to parameterized required type > -------------------------------------------- > > Key: CDI-517 > URL: https://issues.jboss.org/browse/CDI-517 > Project: CDI Specification Issues > Issue Type: Bug > Components: Resolution > Affects Versions: 1.1.PFD, 1.2.Final > Reporter: Mark Struberg > > 2 days before the CDI-1.1 spec went PDF the following backward-incomatible change was made: > {quote} > -A raw bean type is considered assignable to a parameterized required type if the raw types are identical. > + A raw bean type is considered assignable to a parameterized required type if the raw types are identical and all type parameters of the bean type are either unbounded type variables or java.lang.Object. > {quote} > This breaks a lot of projects and also is also not compatible with the JavaEE6 RI and the CDI-1.0 RI where this was explicitly allowed. > This is a follow up to CDI-304. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From antoine at sabot-durand.net Wed Mar 11 08:59:09 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 11 Mar 2015 13:59:09 +0100 Subject: [cdi-dev] Next CDI meeting tuesday 17th Message-ID: <6D577617-5AC3-43AC-A999-90408E657691@sabot-durand.net> Hi All, So we decided to move our weekly meeting on Tuesday at the same time (6:00pm CET). So Let?s meet next Tuesday with following point and action : - Deciding last points for Java SE boot. John Ament is on the topic. If you need help or reviewer John let us know. - Closing the Async Event chapter. I?m completing my Yet Another Doc On Async Event to put all the point we agreed on and will launch the final discussion points in the coming days - Date for releasing the Early Draft 1 of CDI 2.0. The initial idea was to publish it during march, but I think it?s more realistic to aim mid-april. Let?s discuss the content and release fate of it. 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/20150311/6e8fac27/attachment-0001.bin From antoine at sabot-durand.net Thu Mar 12 08:56:16 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 12 Mar 2015 13:56:16 +0100 Subject: [cdi-dev] Update on Async event doc Message-ID: Hi all, I compiled all the feedback and decision we took regarding async events and updated the Google Doc : https://docs.google.com/document/d/1Tm_fZWS6569YqCH9lGxuqBGzS9gfupic-vv1dyKCUxk/edit?usp=sharing The following point stays open. I?d like to close them (if possible) during the next meeting on Tuesday 1) Async delivery mechanism (comment by Jozef) Should we write in the spec about how threads for events delivery should be used? Personally I?d rather not: I think this should be let to implementation, the specification should only describe the expected behavior (concurrency or not). now I may have missed something. 2) Exception Handling (comment by Jozef) I didn?t write anything about exception and we should decide what happens if an exception occurs in an observer during async event dispatch. I think that it shouldn?t impact other observers and that we should stick to the way CompletionStage API works today. 3) Async event activation on both ends We all agree that we need to explicitly fire event asynchronously on the producer side (fireAsync()). The discussion in 8.1 is about adding a way to accept async call on the consumer (observer) side. a) As events are often triggered in other parts of the application than the parts that consume them (most CDI framework lib fire events foe end user code) preventing user to decide if an observer can be called asynchronously could lead to issues and will prevent library developper to use fireAsync() (in a defensive coding approach). b) On the other hand, when placed in the same application, it?ll be very confusing for user to have to fireAsync() and enable async observer to activate this new feature. I propose an opt-out approach. We add ?asyncSupported' member to ?@Observes' annotation with ?true? as default value. So in case of b) the end user won?t have to explicitly activate async on observer and i case of a) user detecting issue coming from async treatment of an event can explicitly declares one or more observer not compatible with async resolution with @Observes(asyncSupported=False) 4) Support observer ordering with async events I think we should keep event ordering for synchronous event and ignore this feature in async event. I don?t see obvious use case to be async and ordered. 5) Context propagation I understand that propagating contexts in async event would impact easily context API. My only concern here is to be define async event to keep this feature possible. If I forgot points please comment this mail and the doc so we can take final decision during next meeting. Thank you Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150312/e43a43e7/attachment.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/20150312/e43a43e7/attachment.bin From martin at fryc.eu Sun Mar 15 06:21:52 2015 From: martin at fryc.eu (=?UTF-8?B?TWFydGluIEZyecSN?=) Date: Sun, 15 Mar 2015 11:21:52 +0100 Subject: [cdi-dev] API for dispatching of async events Message-ID: Hi all, Is it possible to have some API for applications to provide policy which will decide which thread pool will be used for which type of events? If all events share only one thread pool dedicated to processing of all async event, usage of this type of events is very limited. For example: ValidateTransactionDataEvent observed by more that one "application module" LimitVerification module AccessVerification module ... LogTransactionEvent observed by some other modules TechnicalLog module (could be blocked in IO) If async events will be processed in similar way as async EJB methods - usually implemented in app servers as one shared thread pool with limited application control (discard policy, ...), both of these events will share one thread pool and some type of events could fully blocked it and "stop" application. If threre will be some policy API like: java.util.concurrent.ExecutorService dispatch(T event, Annotation... qualifiers) it will allow application to decide which thread pool should be used for which type of event. In EE environment, it must be ManagedExecutorService looked it up from JNDI, in SE environment it could be ExecutorService created for applications needs. Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150315/9108df94/attachment.html From john.d.ament at gmail.com Sun Mar 15 12:03:38 2015 From: john.d.ament at gmail.com (John D. Ament) Date: Sun, 15 Mar 2015 16:03:38 +0000 Subject: [cdi-dev] CDI SE Google Doc Updated Message-ID: HI all, Apologies for being a week late on getting this doc together. I had some personal issues pop up after my leg came out of its cast that consumed most of my week last week. Anywho, I've updated the doc with a summary of what was discussed with CDI SE bootstrap support. You can find that here: https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing There are two minor changes that I made from where we last discussed, as when I was putting together code I found some gaps and figured it best to fix them here than later. 1. CDIProvider does not implement AutoCloseable. Since CDI class maintains a reference to the provider, implementing AutoCloseable was not adding anything. 2. I added a method boolean isInitialized() so that the caller can know if they need to start the container (or if it's already running). Locally, I've also modified the CDI.current() method to use getCDIProvider() instead of internally finding the provider since we now have a getter. One thing I'd like to get feedback on is if calling initialize/shutdown in a container should throw IllegalStateException, or probably better to throw UnsupportedOperationException when called in EE containers. Let me know your thoughts. John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150315/4298a246/attachment.html From arjan.tijms at gmail.com Sun Mar 15 13:46:37 2015 From: arjan.tijms at gmail.com (arjan tijms) Date: Sun, 15 Mar 2015 18:46:37 +0100 Subject: [cdi-dev] API for dispatching of async events In-Reply-To: References: Message-ID: Hi, On Sun, Mar 15, 2015 at 11:21 AM, Martin Fry? wrote: > If async events will be processed in similar way as async EJB methods - > usually implemented in app servers as one shared thread pool with limited > application control (discard policy, ...), both of these events will share > one thread pool and some type of events could fully blocked it and "stop" > application. > Indeed, especially if it will be possible to wait for all async events to have completed, the risk for deadlock is very real. This was explained in some more detail here: https://java.net/jira/browse/EJB_SPEC-9?focusedCommentId=345825&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-345825 Kind regards, Arjan Tijms > > If threre will be some policy API like: > > java.util.concurrent.ExecutorService dispatch(T event, Annotation... > qualifiers) > > it will allow application to decide which thread pool should be used for > which type of event. > In EE environment, it must be ManagedExecutorService looked it up from > JNDI, in SE environment it could be ExecutorService created for > applications needs. > > Martin > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150315/b2c1d0ae/attachment.html From jharting at redhat.com Mon Mar 16 05:33:56 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Mon, 16 Mar 2015 10:33:56 +0100 Subject: [cdi-dev] Update on Async event doc In-Reply-To: References: Message-ID: <5506A384.9080902@redhat.com> On 03/12/2015 01:56 PM, Antoine Sabot-Durand wrote: > Hi all, > > I compiled all the feedback and decision we took regarding async > events and updated the Google Doc : > https://docs.google.com/document/d/1Tm_fZWS6569YqCH9lGxuqBGzS9gfupic-vv1dyKCUxk/edit?usp=sharing > > The following point stays open. I?d like to close them (if possible) > during the next meeting on Tuesday > > 1) Async delivery mechanism (comment by Jozef) > Should we write in the spec about how threads for events delivery > should be used? Personally I?d rather not: I think this should be let > to implementation, the specification should only describe the expected > behavior (concurrency or not). now I may have missed something. We should not specify technical details assuming we clearly define what guarantees are/are not available regarding ordering, visibility, concurrency, effects of exceptions, CDI/security/transactional context propagation and perhaps others I missed. > > 2) Exception Handling (comment by Jozef) > I didn?t write anything about exception and we should decide what > happens if an exception occurs in an observer during async event > dispatch. I think that it shouldn?t impact other observers and that we > should stick to the way CompletionStage API works today. What does it mean? CompletionStage API allows you to handle (a single) Exception. Would those exceptions be swallowed or provided to the caller somehow? > > 3) Async event activation on both ends > We all agree that we need to explicitly fire event asynchronously on > the producer side (fireAsync()). The discussion in 8.1 is about adding > a way to accept async call on the consumer (observer) side. > a) As events are often triggered in other parts of the application > than the parts that consume them (most CDI framework lib fire events > foe end user code) preventing user to decide if an observer can be > called asynchronously could lead to issues and will prevent library > developper to use fireAsync() (in a defensive coding approach). > b) On the other hand, when placed in the same application, it?ll be > very confusing for user to have to fireAsync() and enable async > observer to activate this new feature. > > I propose an opt-out approach. We add ?asyncSupported' member to > ?@Observes' annotation with ?true? as default value. So in case of b) > the end user won?t have to explicitly activate async on observer and i > case of a) user detecting issue coming from async treatment of an > event can explicitly declares one or more observer not compatible with > async resolution with @Observes(asyncSupported=False) > > 4) Support observer ordering with async events > I think we should keep event ordering for synchronous event and ignore > this feature in async event. I don?t see obvious use case to be async > and ordered. if an observer O1 defines priority P1 and a different observer O2 defines P2 where P2 > P1 then it probably does that for a reason. Most likely because O2 depends on the state changes possibly performed by O1. I think this holds true no matter if the event is fired synchronously or asynchronously. Therefore, I think we should respect priority in both cases. In addition, the observer ordering concept will be simpler if we treat observers the same way in both sync and async. > > 5) Context propagation > I understand that propagating contexts in async event would impact > easily context API. My only concern here is to be define async event > to keep this feature possible. > > If I forgot points please comment this mail and the doc so we can take > final decision during next meeting. > > Thank you > > > Antoine > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150316/8649906c/attachment-0001.html From jharting at redhat.com Mon Mar 16 05:45:11 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Mon, 16 Mar 2015 10:45:11 +0100 Subject: [cdi-dev] CDI SE Google Doc Updated In-Reply-To: References: Message-ID: <5506A627.4050205@redhat.com> The CDIProvider serves as a kind of SPI for CDI's static methods to be able to call into the implementation. I don't think reusing it also as a user-facing code is a good idea. What people suggesting to reuse CDIProvider had in mind, I think, was to reuse it as the SPI for talking to the CDI implementation instead. That way, the initialize() static method of CDIContainer/StartedCDI/whatever we call it can use CDIProvider internally to actually start the container. In addition, the current proposal does not make it possible to implement parallel container instances. Jozef On 03/15/2015 05:03 PM, John D. Ament wrote: > HI all, > > Apologies for being a week late on getting this doc together. I had > some personal issues pop up after my leg came out of its cast that > consumed most of my week last week. > > Anywho, I've updated the doc with a summary of what was discussed with > CDI SE bootstrap support. You can find that here: > https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing > > There are two minor changes that I made from where we last discussed, > as when I was putting together code I found some gaps and figured it > best to fix them here than later. > > 1. CDIProvider does not implement AutoCloseable. Since CDI class > maintains a reference to the provider, implementing AutoCloseable was > not adding anything. > > 2. I added a method boolean isInitialized() so that the caller can > know if they need to start the container (or if it's already running). > > Locally, I've also modified the CDI.current() method to use > getCDIProvider() instead of internally finding the provider since we > now have a getter. > > One thing I'd like to get feedback on is if calling > initialize/shutdown in a container should throw IllegalStateException, > or probably better to throw UnsupportedOperationException when called > in EE containers. > > Let me know your thoughts. > > John > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150316/a2a985e0/attachment.html From jharting at redhat.com Mon Mar 16 06:02:09 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Mon, 16 Mar 2015 11:02:09 +0100 Subject: [cdi-dev] CDI SE Google Doc Updated In-Reply-To: <5506A627.4050205@redhat.com> References: <5506A627.4050205@redhat.com> Message-ID: <5506AA21.7000606@redhat.com> Btw was there any further discussion about the bean discovery mode in SE? On 03/16/2015 10:45 AM, Jozef Hartinger wrote: > The CDIProvider serves as a kind of SPI for CDI's static methods to be > able to call into the implementation. I don't think reusing it also as > a user-facing code is a good idea. What people suggesting to reuse > CDIProvider had in mind, I think, was to reuse it as the SPI for > talking to the CDI implementation instead. That way, the initialize() > static method of CDIContainer/StartedCDI/whatever we call it can use > CDIProvider internally to actually start the container. > > In addition, the current proposal does not make it possible to > implement parallel container instances. > > Jozef > > On 03/15/2015 05:03 PM, John D. Ament wrote: >> HI all, >> >> Apologies for being a week late on getting this doc together. I had >> some personal issues pop up after my leg came out of its cast that >> consumed most of my week last week. >> >> Anywho, I've updated the doc with a summary of what was discussed >> with CDI SE bootstrap support. You can find that here: >> https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing >> >> There are two minor changes that I made from where we last discussed, >> as when I was putting together code I found some gaps and figured it >> best to fix them here than later. >> >> 1. CDIProvider does not implement AutoCloseable. Since CDI class >> maintains a reference to the provider, implementing AutoCloseable was >> not adding anything. >> >> 2. I added a method boolean isInitialized() so that the caller can >> know if they need to start the container (or if it's already running). >> >> Locally, I've also modified the CDI.current() method to use >> getCDIProvider() instead of internally finding the provider since we >> now have a getter. >> >> One thing I'd like to get feedback on is if calling >> initialize/shutdown in a container should throw >> IllegalStateException, or probably better to throw >> UnsupportedOperationException when called in EE containers. >> >> Let me know your thoughts. >> >> John >> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150316/43772766/attachment.html From issues at jboss.org Mon Mar 16 06:14:19 2015 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Mon, 16 Mar 2015 06:14:19 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-517) assignability to parameterized required type In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13050357#comment-13050357 ] Jozef Hartinger commented on CDI-517: ------------------------------------- {quote}2 days before the CDI-1.1 spec went PDF{quote} False. See Martin's comment for details. {quote}backward-incomatible change was made{quote} False. CDI 1.0 did not allow this. Therefore, specifying this in CDI 1.1 is backward compatible from the spec point of view. {quote}not compatible with the JavaEE6 RI and the CDI-1.0 RI where this was explicitly allowed.{quote} False. It was never *explicitly allowed*. It was *implicity* allowed by a bug in CDI RI. Now to get to your point the usage of "raw references to generic types" (called simply raw types hereafter) is discouraged by the JLS, supported only to provide compatibility with legacy pre Java 1.5 code and generates a compiler warning. Therefore, people should not be using it in the first place. You're right that fixing the Weld bug caused a few problems here and there where people were still using raw types. This is unfortunate but hardly anything can be done about it at this point especially given that this was already dealt with in CDI-304. > assignability to parameterized required type > -------------------------------------------- > > Key: CDI-517 > URL: https://issues.jboss.org/browse/CDI-517 > Project: CDI Specification Issues > Issue Type: Bug > Components: Resolution > Affects Versions: 1.1.PFD, 1.2.Final > Reporter: Mark Struberg > > 2 days before the CDI-1.1 spec went PDF the following backward-incomatible change was made: > {quote} > -A raw bean type is considered assignable to a parameterized required type if the raw types are identical. > + A raw bean type is considered assignable to a parameterized required type if the raw types are identical and all type parameters of the bean type are either unbounded type variables or java.lang.Object. > {quote} > This breaks a lot of projects and also is also not compatible with the JavaEE6 RI and the CDI-1.0 RI where this was explicitly allowed. > This is a follow up to CDI-304. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From antoine at sabot-durand.net Mon Mar 16 12:19:27 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 16 Mar 2015 17:19:27 +0100 Subject: [cdi-dev] Update on Async event doc In-Reply-To: <5506A384.9080902@redhat.com> References: <5506A384.9080902@redhat.com> Message-ID: <37A9AF8E-D899-451A-B495-3B9A9A36B561@sabot-durand.net> > Le 16 mars 2015 ? 10:33, Jozef Hartinger a ?crit : > > > On 03/12/2015 01:56 PM, Antoine Sabot-Durand wrote: >> Hi all, >> >> I compiled all the feedback and decision we took regarding async events and updated the Google Doc : https://docs.google.com/document/d/1Tm_fZWS6569YqCH9lGxuqBGzS9gfupic-vv1dyKCUxk/edit?usp=sharing >> >> The following point stays open. I?d like to close them (if possible) during the next meeting on Tuesday >> >> 1) Async delivery mechanism (comment by Jozef) >> Should we write in the spec about how threads for events delivery should be used? Personally I?d rather not: I think this should be let to implementation, the specification should only describe the expected behavior (concurrency or not). now I may have missed something. > We should not specify technical details assuming we clearly define what guarantees are/are not available regarding ordering, visibility, concurrency, effects of exceptions, CDI/security/transactional context propagation and perhaps others I missed. We?re saying the same : these will come from the specified behavior ;) >> >> 2) Exception Handling (comment by Jozef) >> I didn?t write anything about exception and we should decide what happens if an exception occurs in an observer during async event dispatch. I think that it shouldn?t impact other observers and that we should stick to the way CompletionStage API works today. > > What does it mean? CompletionStage API allows you to handle (a single) Exception. Would those exceptions be swallowed or provided to the caller somehow? suggestion are welcome. How could we handle multiple exception at the caller level ? >> >> 3) Async event activation on both ends >> We all agree that we need to explicitly fire event asynchronously on the producer side (fireAsync()). The discussion in 8.1 is about adding a way to accept async call on the consumer (observer) side. >> a) As events are often triggered in other parts of the application than the parts that consume them (most CDI framework lib fire events foe end user code) preventing user to decide if an observer can be called asynchronously could lead to issues and will prevent library developper to use fireAsync() (in a defensive coding approach). >> b) On the other hand, when placed in the same application, it?ll be very confusing for user to have to fireAsync() and enable async observer to activate this new feature. >> >> I propose an opt-out approach. We add ?asyncSupported' member to ?@Observes' annotation with ?true? as default value. So in case of b) the end user won?t have to explicitly activate async on observer and i case of a) user detecting issue coming from async treatment of an event can explicitly declares one or more observer not compatible with async resolution with @Observes(asyncSupported=False) >> >> 4) Support observer ordering with async events >> I think we should keep event ordering for synchronous event and ignore this feature in async event. I don?t see obvious use case to be async and ordered. > if an observer O1 defines priority P1 and a different observer O2 defines P2 where P2 > P1 then it probably does that for a reason. Most likely because O2 depends on the state changes possibly performed by O1. I think this holds true no matter if the event is fired synchronously or asynchronously. Therefore, I think we should respect priority in both cases. > > In addition, the observer ordering concept will be simpler if we treat observers the same way in both sync and async. That?s why your input is precious, previous discussion brought us with the opposite pov. Personally the simpler to implement is the right choice... >> >> 5) Context propagation >> I understand that propagating contexts in async event would impact easily context API. My only concern here is to be define async event to keep this feature possible. >> >> If I forgot points please comment this mail and the doc so we can take final decision during next meeting. >> >> Thank you >> >> >> Antoine >> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150316/54b95247/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/20150316/54b95247/attachment-0001.bin From antoine at sabot-durand.net Mon Mar 16 12:42:31 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 16 Mar 2015 17:42:31 +0100 Subject: [cdi-dev] CDI SE Google Doc Updated In-Reply-To: <5506A627.4050205@redhat.com> References: <5506A627.4050205@redhat.com> Message-ID: > The CDIProvider serves as a kind of SPI for CDI's static methods to be able to call into the implementation. I don't think reusing it also as a user-facing code is a good idea. What people suggesting to reuse CDIProvider had in mind, I think, was to reuse it as the SPI for talking to the CDI implementation instead. That way, the initialize() static method of CDIContainer/StartedCDI/whatever we call it can use CDIProvider internally to actually start the container. > > In addition, the current proposal does not make it possible to implement parallel container instances. We?ll re-discuss that tomorrow at the meeting. If you'd bring an alternative proposal that would be great > > Jozef > > On 03/15/2015 05:03 PM, John D. Ament wrote: >> HI all, >> >> Apologies for being a week late on getting this doc together. I had some personal issues pop up after my leg came out of its cast that consumed most of my week last week. >> >> Anywho, I've updated the doc with a summary of what was discussed with CDI SE bootstrap support. You can find that here: https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing >> >> There are two minor changes that I made from where we last discussed, as when I was putting together code I found some gaps and figured it best to fix them here than later. >> >> 1. CDIProvider does not implement AutoCloseable. Since CDI class maintains a reference to the provider, implementing AutoCloseable was not adding anything. >> >> 2. I added a method boolean isInitialized() so that the caller can know if they need to start the container (or if it's already running). >> >> Locally, I've also modified the CDI.current() method to use getCDIProvider() instead of internally finding the provider since we now have a getter. >> >> One thing I'd like to get feedback on is if calling initialize/shutdown in a container should throw IllegalStateException, or probably better to throw UnsupportedOperationException when called in EE containers. >> >> Let me know your thoughts. >> >> John >> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150316/99faab43/attachment.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/20150316/99faab43/attachment.bin From antoine at sabot-durand.net Mon Mar 16 12:45:37 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 16 Mar 2015 17:45:37 +0100 Subject: [cdi-dev] CDI SE Google Doc Updated In-Reply-To: <5506AA21.7000606@redhat.com> References: <5506A627.4050205@redhat.com> <5506AA21.7000606@redhat.com> Message-ID: <902F25F0-60F1-4F1D-9D24-F62767FE5767@sabot-durand.net> > Le 16 mars 2015 ? 11:02, Jozef Hartinger a ?crit : > > Btw was there any further discussion about the bean discovery mode in SE? > For the time being we decided to have the same discovery mode in SE (default to Annotated). If someone has a good reason to change the default mode in SE and/or add a new discovery mode, I?d be glad to hear about it. > On 03/16/2015 10:45 AM, Jozef Hartinger wrote: >> The CDIProvider serves as a kind of SPI for CDI's static methods to be able to call into the implementation. I don't think reusing it also as a user-facing code is a good idea. What people suggesting to reuse CDIProvider had in mind, I think, was to reuse it as the SPI for talking to the CDI implementation instead. That way, the initialize() static method of CDIContainer/StartedCDI/whatever we call it can use CDIProvider internally to actually start the container. >> >> In addition, the current proposal does not make it possible to implement parallel container instances. >> >> Jozef >> >> On 03/15/2015 05:03 PM, John D. Ament wrote: >>> HI all, >>> >>> Apologies for being a week late on getting this doc together. I had some personal issues pop up after my leg came out of its cast that consumed most of my week last week. >>> >>> Anywho, I've updated the doc with a summary of what was discussed with CDI SE bootstrap support. You can find that here: https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing >>> >>> There are two minor changes that I made from where we last discussed, as when I was putting together code I found some gaps and figured it best to fix them here than later. >>> >>> 1. CDIProvider does not implement AutoCloseable. Since CDI class maintains a reference to the provider, implementing AutoCloseable was not adding anything. >>> >>> 2. I added a method boolean isInitialized() so that the caller can know if they need to start the container (or if it's already running). >>> >>> Locally, I've also modified the CDI.current() method to use getCDIProvider() instead of internally finding the provider since we now have a getter. >>> >>> One thing I'd like to get feedback on is if calling initialize/shutdown in a container should throw IllegalStateException, or probably better to throw UnsupportedOperationException when called in EE containers. >>> >>> Let me know your thoughts. >>> >>> John >>> >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150316/a43046d4/attachment.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/20150316/a43046d4/attachment.bin From john.d.ament at gmail.com Mon Mar 16 13:06:07 2015 From: john.d.ament at gmail.com (John D. Ament) Date: Mon, 16 Mar 2015 17:06:07 +0000 Subject: [cdi-dev] CDI SE Google Doc Updated In-Reply-To: References: <5506A627.4050205@redhat.com> Message-ID: On Mon, Mar 16, 2015 at 12:42 PM Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > > The CDIProvider serves as a kind of SPI for CDI's static methods to be > able to call into the implementation. I don't think reusing it also as a > user-facing code is a good idea. What people suggesting to reuse > CDIProvider had in mind, I think, was to reuse it as the SPI for talking to > the CDI implementation instead. That way, the initialize() static method of > CDIContainer/StartedCDI/whatever we call it can use CDIProvider internally > to actually start the container. > > > In addition, the current proposal does not make it possible to implement > parallel container instances. > > > > We?ll re-discuss that tomorrow at the meeting. If you'd bring an > alternative proposal that would be great > There's a chance I won't be at tomorrow's meeting but I'll follow up either way. > > > Jozef > > On 03/15/2015 05:03 PM, John D. Ament wrote: > > HI all, > > Apologies for being a week late on getting this doc together. I had > some personal issues pop up after my leg came out of its cast that consumed > most of my week last week. > > Anywho, I've updated the doc with a summary of what was discussed with > CDI SE bootstrap support. You can find that here: > https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing > > There are two minor changes that I made from where we last discussed, as > when I was putting together code I found some gaps and figured it best to > fix them here than later. > > 1. CDIProvider does not implement AutoCloseable. Since CDI class > maintains a reference to the provider, implementing AutoCloseable was not > adding anything. > > 2. I added a method boolean isInitialized() so that the caller can know > if they need to start the container (or if it's already running). > > Locally, I've also modified the CDI.current() method to use > getCDIProvider() instead of internally finding the provider since we now > have a getter. > > One thing I'd like to get feedback on is if calling initialize/shutdown > in a container should throw IllegalStateException, or probably better to > throw UnsupportedOperationException when called in EE containers. > > Let me know your thoughts. > > John > > > > _______________________________________________ > cdi-dev mailing listcdi-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150316/85805c37/attachment-0001.html From martin at fryc.eu Mon Mar 16 14:17:28 2015 From: martin at fryc.eu (=?UTF-8?B?TWFydGluIEZyecSN?=) Date: Mon, 16 Mar 2015 19:17:28 +0100 Subject: [cdi-dev] API for dispatching of async events In-Reply-To: References: Message-ID: Hi, more than deadlock I meant that quickly processed events (calculations, verifications, ...) will be mixed in queue with slowly processed events (writing to FS, WS call, ...) and application could be interested only in result of "quick" events and doesn't care, when slow one will be finished (eg. logging, ...). It will cause to take unnecessary time for request processing. If application will be able to tell to async event "dispatcher", process this type of events on this executor, another type by this one and rest by this one, they won't be mixed in queue of one executor. Application will be then able to dedicate executor for processing of events needed for finishing of request processing and another for events which could be done even after request processing will be finished. King regards, Martin Fry? On Sun, Mar 15, 2015 at 6:46 PM, arjan tijms wrote: > Hi, > > On Sun, Mar 15, 2015 at 11:21 AM, Martin Fry? wrote: > >> If async events will be processed in similar way as async EJB methods - >> usually implemented in app servers as one shared thread pool with limited >> application control (discard policy, ...), both of these events will share >> one thread pool and some type of events could fully blocked it and "stop" >> application. >> > > Indeed, especially if it will be possible to wait for all async events to > have completed, the risk for deadlock is very real. > > This was explained in some more detail here: > https://java.net/jira/browse/EJB_SPEC-9?focusedCommentId=345825&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-345825 > > Kind regards, > Arjan Tijms > > > >> >> If threre will be some policy API like: >> >> java.util.concurrent.ExecutorService dispatch(T event, Annotation... >> qualifiers) >> >> it will allow application to decide which thread pool should be used for >> which type of event. >> In EE environment, it must be ManagedExecutorService looked it up from >> JNDI, in SE environment it could be ExecutorService created for >> applications needs. >> >> Martin >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150316/bfe0e4ae/attachment.html From arjan.tijms at gmail.com Mon Mar 16 14:26:59 2015 From: arjan.tijms at gmail.com (arjan tijms) Date: Mon, 16 Mar 2015 19:26:59 +0100 Subject: [cdi-dev] API for dispatching of async events In-Reply-To: References: Message-ID: Hi, On Monday, March 16, 2015, Martin Fry? > wrote: > Hi, > more than deadlock I meant that quickly processed events (calculations, > verifications, ...) will be mixed in a queue with slowly processed events > (writing to FS, WS call, ...) and the application could be interested only > in the result of "quick" events > Sure, you are right. There are many use cases for seperate thread pools. The one you described above is essentially a QoS one. The bottom line is that APIs should as much as possible allow the user to define multiple pools and to associate a pool with a specific parallel/async operation. Kind regards, Arjan Tijms > and doesn't care, when slow one will be finished (eg. logging, ...). It > will cause to take unnecessary time for request processing. > > If application will be able to tell to async event "dispatcher", process > this type of events on this executor, another type by this one and rest by > this one, they won't be mixed in queue of one executor. Application will be > then able to dedicate executor for processing of events needed for > finishing of request processing and another for events which could be done > even after request processing will be finished. > > King regards, > Martin Fry? > > On Sun, Mar 15, 2015 at 6:46 PM, arjan tijms > wrote: > >> Hi, >> >> On Sun, Mar 15, 2015 at 11:21 AM, Martin Fry? wrote: >> >>> If async events will be processed in similar way as async EJB methods - >>> usually implemented in app servers as one shared thread pool with limited >>> application control (discard policy, ...), both of these events will share >>> one thread pool and some type of events could fully blocked it and "stop" >>> application. >>> >> >> Indeed, especially if it will be possible to wait for all async events to >> have completed, the risk for deadlock is very real. >> >> This was explained in some more detail here: >> https://java.net/jira/browse/EJB_SPEC-9?focusedCommentId=345825&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-345825 >> >> Kind regards, >> Arjan Tijms >> >> >> >>> >>> If threre will be some policy API like: >>> >>> java.util.concurrent.ExecutorService dispatch(T event, Annotation... >>> qualifiers) >>> >>> it will allow application to decide which thread pool should be used for >>> which type of event. >>> In EE environment, it must be ManagedExecutorService looked it up from >>> JNDI, in SE environment it could be ExecutorService created for >>> applications needs. >>> >>> Martin >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>> provided on this list, the provider waives all patent and other >>> intellectual property rights inherent in such information. >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150316/cc8ad0f8/attachment.html From jharting at redhat.com Tue Mar 17 02:22:48 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Tue, 17 Mar 2015 07:22:48 +0100 Subject: [cdi-dev] CDI SE Google Doc Updated In-Reply-To: <902F25F0-60F1-4F1D-9D24-F62767FE5767@sabot-durand.net> References: <5506A627.4050205@redhat.com> <5506AA21.7000606@redhat.com> <902F25F0-60F1-4F1D-9D24-F62767FE5767@sabot-durand.net> Message-ID: <5507C838.9020209@redhat.com> On 03/16/2015 05:45 PM, Antoine Sabot-Durand wrote: > >> Le 16 mars 2015 ? 11:02, Jozef Hartinger > > a ?crit : >> >> Btw was there any further discussion about the bean discovery mode in SE? >> > > For the time being we decided to have the same discovery mode in SE > (default to Annotated). If someone has a good reason to change the > default mode in SE and/or add a new discovery mode, I?d be glad to > hear about it. http://lists.jboss.org/pipermail/cdi-dev/2015-March/006334.html > > >> On 03/16/2015 10:45 AM, Jozef Hartinger wrote: >>> The CDIProvider serves as a kind of SPI for CDI's static methods to >>> be able to call into the implementation. I don't think reusing it >>> also as a user-facing code is a good idea. What people suggesting to >>> reuse CDIProvider had in mind, I think, was to reuse it as the SPI >>> for talking to the CDI implementation instead. That way, the >>> initialize() static method of CDIContainer/StartedCDI/whatever we >>> call it can use CDIProvider internally to actually start the container. >>> >>> In addition, the current proposal does not make it possible to >>> implement parallel container instances. >>> >>> Jozef >>> >>> On 03/15/2015 05:03 PM, John D. Ament wrote: >>>> HI all, >>>> >>>> Apologies for being a week late on getting this doc together. I >>>> had some personal issues pop up after my leg came out of its cast >>>> that consumed most of my week last week. >>>> >>>> Anywho, I've updated the doc with a summary of what was discussed >>>> with CDI SE bootstrap support. You can find that here: >>>> https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing >>>> >>>> There are two minor changes that I made from where we last >>>> discussed, as when I was putting together code I found some gaps >>>> and figured it best to fix them here than later. >>>> >>>> 1. CDIProvider does not implement AutoCloseable. Since CDI class >>>> maintains a reference to the provider, implementing AutoCloseable >>>> was not adding anything. >>>> >>>> 2. I added a method boolean isInitialized() so that the caller can >>>> know if they need to start the container (or if it's already running). >>>> >>>> Locally, I've also modified the CDI.current() method to use >>>> getCDIProvider() instead of internally finding the provider since >>>> we now have a getter. >>>> >>>> One thing I'd like to get feedback on is if calling >>>> initialize/shutdown in a container should throw >>>> IllegalStateException, or probably better to throw >>>> UnsupportedOperationException when called in EE containers. >>>> >>>> Let me know your thoughts. >>>> >>>> John >>>> >>>> >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>> >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses >> the code under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >> ideas provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150317/3d656024/attachment-0001.html From jharting at redhat.com Tue Mar 17 02:27:33 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Tue, 17 Mar 2015 07:27:33 +0100 Subject: [cdi-dev] Update on Async event doc In-Reply-To: <37A9AF8E-D899-451A-B495-3B9A9A36B561@sabot-durand.net> References: <5506A384.9080902@redhat.com> <37A9AF8E-D899-451A-B495-3B9A9A36B561@sabot-durand.net> Message-ID: <5507C955.7080808@redhat.com> On 03/16/2015 05:19 PM, Antoine Sabot-Durand wrote: > >> Le 16 mars 2015 ? 10:33, Jozef Hartinger > > a ?crit : >> >> >> On 03/12/2015 01:56 PM, Antoine Sabot-Durand wrote: >>> Hi all, >>> >>> I compiled all the feedback and decision we took regarding async >>> events and updated the Google Doc : >>> https://docs.google.com/document/d/1Tm_fZWS6569YqCH9lGxuqBGzS9gfupic-vv1dyKCUxk/edit?usp=sharing >>> >>> The following point stays open. I?d like to close them (if possible) >>> during the next meeting on Tuesday >>> >>> 1) Async delivery mechanism (comment by Jozef) >>> Should we write in the spec about how threads for events delivery >>> should be used? Personally I?d rather not: I think this should be >>> let to implementation, the specification should only describe the >>> expected behavior (concurrency or not). now I may have missed something. >> We should not specify technical details assuming we clearly define >> what guarantees are/are not available regarding ordering, visibility, >> concurrency, effects of exceptions, CDI/security/transactional >> context propagation and perhaps others I missed. > > We?re saying the same : these will come from the specified behavior ;) > >>> >>> 2) Exception Handling (comment by Jozef) >>> I didn?t write anything about exception and we should decide what >>> happens if an exception occurs in an observer during async event >>> dispatch. I think that it shouldn?t impact other observers and that >>> we should stick to the way CompletionStage API works today. >> >> What does it mean? CompletionStage API allows you to handle (a >> single) Exception. Would those exceptions be swallowed or provided to >> the caller somehow? > > suggestion are welcome. How could we handle multiple exception at the > caller level ? I don't know. How did you plan to handle those in your proposal? > >>> >>> 3) Async event activation on both ends >>> We all agree that we need to explicitly fire event asynchronously on >>> the producer side (fireAsync()). The discussion in 8.1 is about >>> adding a way to accept async call on the consumer (observer) side. >>> a) As events are often triggered in other parts of the application >>> than the parts that consume them (most CDI framework lib fire events >>> foe end user code) preventing user to decide if an observer can be >>> called asynchronously could lead to issues and will prevent library >>> developper to use fireAsync() (in a defensive coding approach). >>> b) On the other hand, when placed in the same application, it?ll be >>> very confusing for user to have to fireAsync() and enable async >>> observer to activate this new feature. >>> >>> I propose an opt-out approach. We add ?asyncSupported' member to >>> ?@Observes' annotation with ?true? as default value. So in case of >>> b) the end user won?t have to explicitly activate async on observer >>> and i case of a) user detecting issue coming from async treatment of >>> an event can explicitly declares one or more observer not compatible >>> with async resolution with @Observes(asyncSupported=False) >>> >>> 4) Support observer ordering with async events >>> I think we should keep event ordering for synchronous event and >>> ignore this feature in async event. I don?t see obvious use case to >>> be async and ordered. >> if an observer O1 defines priority P1 and a different observer O2 >> defines P2 where P2 > P1 then it probably does that for a reason. >> Most likely because O2 depends on the state changes possibly >> performed by O1. I think this holds true no matter if the event is >> fired synchronously or asynchronously. Therefore, I think we should >> respect priority in both cases. >> >> In addition, the observer ordering concept will be simpler if we >> treat observers the same way in both sync and async. > > That?s why your input is precious, previous discussion brought us with > the opposite pov. Personally the simpler to implement is the right > choice... No, I mean simpler to explain and for users to take in. Implementation complexity is way less important. > >>> >>> 5) Context propagation >>> I understand that propagating contexts in async event would impact >>> easily context API. My only concern here is to be define async event >>> to keep this feature possible. >>> >>> If I forgot points please comment this mail and the doc so we can >>> take final decision during next meeting. >>> >>> Thank you >>> >>> >>> Antoine >>> >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150317/8cbf2627/attachment.html From mkouba at redhat.com Tue Mar 17 04:50:12 2015 From: mkouba at redhat.com (Martin Kouba) Date: Tue, 17 Mar 2015 09:50:12 +0100 Subject: [cdi-dev] CDI SE Google Doc Updated In-Reply-To: <5507C838.9020209@redhat.com> References: <5506A627.4050205@redhat.com> <5506AA21.7000606@redhat.com> <902F25F0-60F1-4F1D-9D24-F62767FE5767@sabot-durand.net> <5507C838.9020209@redhat.com> Message-ID: <5507EAC4.1080306@redhat.com> It's ok to have the same default bean discovery mode in Java SE. However, I think there is no easy way to scan the classpath and "detect" bean archives without beans.xml, i.e. implicit bean archives without the descriptor. That's the reason why bean archives without beans.xml are not supported in Weld SE. If anyone knows how to implement this properly, speak out. Martin Dne 17.3.2015 v 07:22 Jozef Hartinger napsal(a): > > On 03/16/2015 05:45 PM, Antoine Sabot-Durand wrote: >> >>> Le 16 mars 2015 ? 11:02, Jozef Hartinger >> > a ?crit : >>> >>> Btw was there any further discussion about the bean discovery mode in SE >>> >> >> For the time being we decided to have the same discovery mode in SE >> (default to Annotated). If someone has a good reason to change the >> default mode in SE and/or add a new discovery mode, I?d be glad to >> hear about it. > http://lists.jboss.org/pipermail/cdi-dev/2015-March/006334.html >> >> >>> On 03/16/2015 10:45 AM, Jozef Hartinger wrote: >>>> The CDIProvider serves as a kind of SPI for CDI's static methods to >>>> be able to call into the implementation. I don't think reusing it >>>> also as a user-facing code is a good idea. What people suggesting to >>>> reuse CDIProvider had in mind, I think, was to reuse it as the SPI >>>> for talking to the CDI implementation instead. That way, the >>>> initialize() static method of CDIContainer/StartedCDI/whatever we >>>> call it can use CDIProvider internally to actually start the container. >>>> >>>> In addition, the current proposal does not make it possible to >>>> implement parallel container instances. >>>> >>>> Jozef >>>> >>>> On 03/15/2015 05:03 PM, John D. Ament wrote: >>>>> HI all, >>>>> >>>>> Apologies for being a week late on getting this doc together. I >>>>> had some personal issues pop up after my leg came out of its cast >>>>> that consumed most of my week last week. >>>>> >>>>> Anywho, I've updated the doc with a summary of what was discussed >>>>> with CDI SE bootstrap support. You can find that here: >>>>> https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing >>>>> >>>>> There are two minor changes that I made from where we last >>>>> discussed, as when I was putting together code I found some gaps >>>>> and figured it best to fix them here than later. >>>>> >>>>> 1. CDIProvider does not implement AutoCloseable. Since CDI class >>>>> maintains a reference to the provider, implementing AutoCloseable >>>>> was not adding anything. >>>>> >>>>> 2. I added a method boolean isInitialized() so that the caller can >>>>> know if they need to start the container (or if it's already running). >>>>> >>>>> Locally, I've also modified the CDI.current() method to use >>>>> getCDIProvider() instead of internally finding the provider since >>>>> we now have a getter. >>>>> >>>>> One thing I'd like to get feedback on is if calling >>>>> initialize/shutdown in a container should throw >>>>> IllegalStateException, or probably better to throw >>>>> UnsupportedOperationException when called in EE containers. >>>>> >>>>> Let me know your thoughts. >>>>> >>>>> John >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>>> >>>> >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses >>> the code under the Apache License, Version 2 >>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>> ideas provided on this list, the provider waives all patent and other >>> intellectual property rights inherent in such information. >> > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > From antoine at sabot-durand.net Tue Mar 17 05:39:18 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 17 Mar 2015 10:39:18 +0100 Subject: [cdi-dev] CDI SE Google Doc Updated In-Reply-To: <5507EAC4.1080306@redhat.com> References: <5506A627.4050205@redhat.com> <5506AA21.7000606@redhat.com> <902F25F0-60F1-4F1D-9D24-F62767FE5767@sabot-durand.net> <5507C838.9020209@redhat.com> <5507EAC4.1080306@redhat.com> Message-ID: <7C891419-F1E0-4D4A-9FC3-9CC4A82FCDB4@sabot-durand.net> So perhaps the solution would be to require beans.xml in SE or a specific parameter in command line. Antoine Sabot-Durand > Le 17 mars 2015 ? 09:50, Martin Kouba a ?crit : > > It's ok to have the same default bean discovery mode in Java SE. However, I think there is no easy way to scan the classpath and "detect" bean archives without beans.xml, i.e. implicit bean archives without the descriptor. > > That's the reason why bean archives without beans.xml are not supported in Weld SE. > > If anyone knows how to implement this properly, speak out. > > Martin > > Dne 17.3.2015 v 07:22 Jozef Hartinger napsal(a): >> >>> On 03/16/2015 05:45 PM, Antoine Sabot-Durand wrote: >>> >>>> Le 16 mars 2015 ? 11:02, Jozef Hartinger >>> > a ?crit : >>>> >>>> Btw was there any further discussion about the bean discovery mode in SE >>> >>> For the time being we decided to have the same discovery mode in SE >>> (default to Annotated). If someone has a good reason to change the >>> default mode in SE and/or add a new discovery mode, I?d be glad to >>> hear about it. >> http://lists.jboss.org/pipermail/cdi-dev/2015-March/006334.html >>> >>> >>>>> On 03/16/2015 10:45 AM, Jozef Hartinger wrote: >>>>> The CDIProvider serves as a kind of SPI for CDI's static methods to >>>>> be able to call into the implementation. I don't think reusing it >>>>> also as a user-facing code is a good idea. What people suggesting to >>>>> reuse CDIProvider had in mind, I think, was to reuse it as the SPI >>>>> for talking to the CDI implementation instead. That way, the >>>>> initialize() static method of CDIContainer/StartedCDI/whatever we >>>>> call it can use CDIProvider internally to actually start the container. >>>>> >>>>> In addition, the current proposal does not make it possible to >>>>> implement parallel container instances. >>>>> >>>>> Jozef >>>>> >>>>>> On 03/15/2015 05:03 PM, John D. Ament wrote: >>>>>> HI all, >>>>>> >>>>>> Apologies for being a week late on getting this doc together. I >>>>>> had some personal issues pop up after my leg came out of its cast >>>>>> that consumed most of my week last week. >>>>>> >>>>>> Anywho, I've updated the doc with a summary of what was discussed >>>>>> with CDI SE bootstrap support. You can find that here: >>>>>> https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing >>>>>> >>>>>> There are two minor changes that I made from where we last >>>>>> discussed, as when I was putting together code I found some gaps >>>>>> and figured it best to fix them here than later. >>>>>> >>>>>> 1. CDIProvider does not implement AutoCloseable. Since CDI class >>>>>> maintains a reference to the provider, implementing AutoCloseable >>>>>> was not adding anything. >>>>>> >>>>>> 2. I added a method boolean isInitialized() so that the caller can >>>>>> know if they need to start the container (or if it's already running). >>>>>> >>>>>> Locally, I've also modified the CDI.current() method to use >>>>>> getCDIProvider() instead of internally finding the provider since >>>>>> we now have a getter. >>>>>> >>>>>> One thing I'd like to get feedback on is if calling >>>>>> initialize/shutdown in a container should throw >>>>>> IllegalStateException, or probably better to throw >>>>>> UnsupportedOperationException when called in EE containers. >>>>>> >>>>>> Let me know your thoughts. >>>>>> >>>>>> John >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> cdi-dev mailing list >>>>>> cdi-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>> >>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider licenses >>>> the code under the Apache License, Version 2 >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>>> ideas provided on this list, the provider waives all patent and other >>>> intellectual property rights inherent in such information. >> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> From john.d.ament at gmail.com Tue Mar 17 05:49:53 2015 From: john.d.ament at gmail.com (John D. Ament) Date: Tue, 17 Mar 2015 09:49:53 +0000 Subject: [cdi-dev] CDI SE Google Doc Updated In-Reply-To: <5507EAC4.1080306@redhat.com> References: <5506A627.4050205@redhat.com> <5506AA21.7000606@redhat.com> <902F25F0-60F1-4F1D-9D24-F62767FE5767@sabot-durand.net> <5507C838.9020209@redhat.com> <5507EAC4.1080306@redhat.com> Message-ID: On Tue, Mar 17, 2015 at 4:50 AM Martin Kouba wrote: > It's ok to have the same default bean discovery mode in Java SE. > However, I think there is no easy way to scan the classpath and "detect" > bean archives without beans.xml, i.e. implicit bean archives without the > descriptor. > You should be able to read java.class.path to determine the possible archives. Then use the URL of the class itself to find which JAR it came from. > > That's the reason why bean archives without beans.xml are not supported > in Weld SE. > > If anyone knows how to implement this properly, speak out. > > Martin > > Dne 17.3.2015 v 07:22 Jozef Hartinger napsal(a): > > > > On 03/16/2015 05:45 PM, Antoine Sabot-Durand wrote: > >> > >>> Le 16 mars 2015 ? 11:02, Jozef Hartinger >>> > a ?crit : > >>> > >>> Btw was there any further discussion about the bean discovery mode in > SE > >>> > >> > >> For the time being we decided to have the same discovery mode in SE > >> (default to Annotated). If someone has a good reason to change the > >> default mode in SE and/or add a new discovery mode, I?d be glad to > >> hear about it. > > http://lists.jboss.org/pipermail/cdi-dev/2015-March/006334.html > >> > >> > >>> On 03/16/2015 10:45 AM, Jozef Hartinger wrote: > >>>> The CDIProvider serves as a kind of SPI for CDI's static methods to > >>>> be able to call into the implementation. I don't think reusing it > >>>> also as a user-facing code is a good idea. What people suggesting to > >>>> reuse CDIProvider had in mind, I think, was to reuse it as the SPI > >>>> for talking to the CDI implementation instead. That way, the > >>>> initialize() static method of CDIContainer/StartedCDI/whatever we > >>>> call it can use CDIProvider internally to actually start the > container. > >>>> > >>>> In addition, the current proposal does not make it possible to > >>>> implement parallel container instances. > >>>> > >>>> Jozef > >>>> > >>>> On 03/15/2015 05:03 PM, John D. Ament wrote: > >>>>> HI all, > >>>>> > >>>>> Apologies for being a week late on getting this doc together. I > >>>>> had some personal issues pop up after my leg came out of its cast > >>>>> that consumed most of my week last week. > >>>>> > >>>>> Anywho, I've updated the doc with a summary of what was discussed > >>>>> with CDI SE bootstrap support. You can find that here: > >>>>> https://docs.google.com/document/d/1LgsGT- > AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing > >>>>> > >>>>> There are two minor changes that I made from where we last > >>>>> discussed, as when I was putting together code I found some gaps > >>>>> and figured it best to fix them here than later. > >>>>> > >>>>> 1. CDIProvider does not implement AutoCloseable. Since CDI class > >>>>> maintains a reference to the provider, implementing AutoCloseable > >>>>> was not adding anything. > >>>>> > >>>>> 2. I added a method boolean isInitialized() so that the caller can > >>>>> know if they need to start the container (or if it's already > running). > >>>>> > >>>>> Locally, I've also modified the CDI.current() method to use > >>>>> getCDIProvider() instead of internally finding the provider since > >>>>> we now have a getter. > >>>>> > >>>>> One thing I'd like to get feedback on is if calling > >>>>> initialize/shutdown in a container should throw > >>>>> IllegalStateException, or probably better to throw > >>>>> UnsupportedOperationException when called in EE containers. > >>>>> > >>>>> Let me know your thoughts. > >>>>> > >>>>> John > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> cdi-dev mailing list > >>>>> cdi-dev at lists.jboss.org > >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>>> > >>>>> Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 (http://www.apache.org/ > licenses/LICENSE-2.0.html). For all other ideas provided on this list, > the provider waives all patent and other intellectual property rights > inherent in such information. > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> cdi-dev mailing list > >>>> cdi-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>> > >>>> Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 (http://www.apache.org/ > licenses/LICENSE-2.0.html). For all other ideas provided on this list, > the provider waives all patent and other intellectual property rights > inherent in such information. > >>> > >>> _______________________________________________ > >>> cdi-dev mailing list > >>> cdi-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>> > >>> Note that for all code provided on this list, the provider licenses > >>> the code under the Apache License, Version 2 > >>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > >>> ideas provided on this list, the provider waives all patent and other > >>> intellectual property rights inherent in such information. > >> > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 (http://www.apache.org/ > licenses/LICENSE-2.0.html). For all other ideas provided on this list, > the provider waives all patent and other intellectual property rights > inherent in such information. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 (http://www.apache.org/ > licenses/LICENSE-2.0.html). For all other ideas provided on this list, > the provider waives all patent and other intellectual property rights > inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150317/eea065e2/attachment.html From issues at jboss.org Tue Mar 17 05:56:22 2015 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Tue, 17 Mar 2015 05:56:22 -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:comment-tabpanel&focusedCommentId=13050840#comment-13050840 ] Jozef Hartinger commented on CDI-26: ------------------------------------ An alternative proposal that does not prevent parallel container instances: {code:java} public abstract class ControlledCDI extends CDI implements AutoCloseable { public static ControlledCDI initialize() { // TODO: Use CDIProvider internally to talk to the impl } public static ControlledCDI initialize(Map properties) { // TODO: Use CDIProvider internally to talk to the impl } public abstract void close(); } {code} Usage: {code:java} try (ControlledCDI cdi = ControlledCDI.initialize()) { Foo foo = cdi.select(Foo.class).get(); System.out.println(foo.computeResult()); } {code} Note that this is a preliminary proposal. The class name is subject to change plus we'll most likely need a builder API instead of the static methods in the end. > 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, 1.1.PFD, 1.2.Final > 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.3.11#6341) From mkouba at redhat.com Tue Mar 17 08:05:40 2015 From: mkouba at redhat.com (Martin Kouba) Date: Tue, 17 Mar 2015 13:05:40 +0100 Subject: [cdi-dev] CDI SE Google Doc Updated In-Reply-To: References: <5506A627.4050205@redhat.com> <5506AA21.7000606@redhat.com> <902F25F0-60F1-4F1D-9D24-F62767FE5767@sabot-durand.net> <5507C838.9020209@redhat.com> <5507EAC4.1080306@redhat.com> Message-ID: <55081894.8050104@redhat.com> Dne 17.3.2015 v 10:49 John D. Ament napsal(a): > > > On Tue, Mar 17, 2015 at 4:50 AM Martin Kouba > wrote: > > It's ok to have the same default bean discovery mode in Java SE. > However, I think there is no easy way to scan the classpath and "detect" > bean archives without beans.xml, i.e. implicit bean archives without the > descriptor. > > > You should be able to read java.class.path to determine the possible > archives. Then use the URL of the class itself to find which JAR it > came from. I'm not sure this will cover all use-cases (Web Start, extension classes, ...). Moreover, elements of the class are platform-specific. So it wouldn't be trivial to parse it. > > > That's the reason why bean archives without beans.xml are not supported > in Weld SE. > > If anyone knows how to implement this properly, speak out. > > Martin > > Dne 17.3.2015 v 07:22 Jozef Hartinger napsal(a): > > > > On 03/16/2015 05:45 PM, Antoine Sabot-Durand wrote: > >> > >>> Le 16 mars 2015 ? 11:02, Jozef Hartinger > >>> >> a > ?crit : > >>> > >>> Btw was there any further discussion about the bean discovery > mode in SE > >>> > >> > >> For the time being we decided to have the same discovery mode in SE > >> (default to Annotated). If someone has a good reason to change the > >> default mode in SE and/or add a new discovery mode, I?d be glad to > >> hear about it. > > > http://lists.jboss.org/__pipermail/cdi-dev/2015-March/__006334.html > > >> > >> > >>> On 03/16/2015 10:45 AM, Jozef Hartinger wrote: > >>>> The CDIProvider serves as a kind of SPI for CDI's static > methods to > >>>> be able to call into the implementation. I don't think reusing it > >>>> also as a user-facing code is a good idea. What people > suggesting to > >>>> reuse CDIProvider had in mind, I think, was to reuse it as the SPI > >>>> for talking to the CDI implementation instead. That way, the > >>>> initialize() static method of > CDIContainer/StartedCDI/__whatever we > >>>> call it can use CDIProvider internally to actually start the > container. > >>>> > >>>> In addition, the current proposal does not make it possible to > >>>> implement parallel container instances. > >>>> > >>>> Jozef > >>>> > >>>> On 03/15/2015 05:03 PM, John D. Ament wrote: > >>>>> HI all, > >>>>> > >>>>> Apologies for being a week late on getting this doc together. I > >>>>> had some personal issues pop up after my leg came out of its cast > >>>>> that consumed most of my week last week. > >>>>> > >>>>> Anywho, I've updated the doc with a summary of what was discussed > >>>>> with CDI SE bootstrap support. You can find that here: > >>>>> > https://docs.google.com/__document/d/1LgsGT-__AAlrF72Z5pW4xNQiVjUHGUME46ZmB-__wwF35Yw/edit?usp=sharing > > >>>>> > >>>>> There are two minor changes that I made from where we last > >>>>> discussed, as when I was putting together code I found some gaps > >>>>> and figured it best to fix them here than later. > >>>>> > >>>>> 1. CDIProvider does not implement AutoCloseable. Since CDI class > >>>>> maintains a reference to the provider, implementing AutoCloseable > >>>>> was not adding anything. > >>>>> > >>>>> 2. I added a method boolean isInitialized() so that the > caller can > >>>>> know if they need to start the container (or if it's already > running). > >>>>> > >>>>> Locally, I've also modified the CDI.current() method to use > >>>>> getCDIProvider() instead of internally finding the provider since > >>>>> we now have a getter. > >>>>> > >>>>> One thing I'd like to get feedback on is if calling > >>>>> initialize/shutdown in a container should throw > >>>>> IllegalStateException, or probably better to throw > >>>>> UnsupportedOperationException when called in EE containers. > >>>>> > >>>>> Let me know your thoughts. > >>>>> > >>>>> John > >>>>> > >>>>> > >>>>> > >>>>> _________________________________________________ > >>>>> cdi-dev mailing list > >>>>> cdi-dev at lists.jboss.org > >>>>> https://lists.jboss.org/__mailman/listinfo/cdi-dev > > >>>>> > >>>>> Note that for all code provided on this list, the provider > licenses the code under the Apache License, Version 2 > (http://www.apache.org/__licenses/LICENSE-2.0.html > ). For all other > ideas provided on this list, the provider waives all patent and > other intellectual property rights inherent in such information. > >>>> > >>>> > >>>> > >>>> _________________________________________________ > >>>> cdi-dev mailing list > >>>> cdi-dev at lists.jboss.org > >>>> https://lists.jboss.org/__mailman/listinfo/cdi-dev > > >>>> > >>>> Note that for all code provided on this list, the provider > licenses the code under the Apache License, Version 2 > (http://www.apache.org/__licenses/LICENSE-2.0.html > ). For all other > ideas provided on this list, the provider waives all patent and > other intellectual property rights inherent in such information. > >>> > >>> _________________________________________________ > >>> cdi-dev mailing list > >>> cdi-dev at lists.jboss.org > > > >>> https://lists.jboss.org/__mailman/listinfo/cdi-dev > > >>> > >>> Note that for all code provided on this list, the provider licenses > >>> the code under the Apache License, Version 2 > >>> (http://www.apache.org/__licenses/LICENSE-2.0.html > ). For all other > >>> ideas provided on this list, the provider waives all patent and > other > >>> intellectual property rights inherent in such information. > >> > > > > > > > > _________________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/__mailman/listinfo/cdi-dev > > > > > Note that for all code provided on this list, the provider > licenses the code under the Apache License, Version 2 > (http://www.apache.org/__licenses/LICENSE-2.0.html > ). For all other > ideas provided on this list, the provider waives all patent and > other intellectual property rights inherent in such information. > > > _________________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/__mailman/listinfo/cdi-dev > > > Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 > (http://www.apache.org/__licenses/LICENSE-2.0.html > ). For all other > ideas provided on this list, the provider waives all patent and > other intellectual property rights inherent in such information. > From antoine at sabot-durand.net Tue Mar 17 11:06:12 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 17 Mar 2015 15:06:12 +0000 Subject: [cdi-dev] Invitation: CDI weekly meeting - Toutes les semaines entre 18:00 et 19:00 le Mercredi (ASD Perso) Message-ID: <001a11c3ca14af712a05117d4e78@google.com> Vous avez ?t? invit? ? l'?v?nement suivant. Titre : CDI weekly meeting View your event at https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3Btc292ZnRvMWpkcWsgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZGU3ZDQwYmRmMTA4MDY2YzgyOTQ0ZGIwMzIyMjM4NzM3MGE3ZGU1OQ&ctz=Europe/Paris&hl=en_GB. View your event at https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3Btc292ZnRvMWpkcWsgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZGU3ZDQwYmRmMTA4MDY2YzgyOTQ0ZGIwMzIyMjM4NzM3MGE3ZGU1OQ&ctz=Europe/Paris&hl=en_GB. View your event at https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3Btc292ZnRvMWpkcWsgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZGU3ZDQwYmRmMTA4MDY2YzgyOTQ0ZGIwMzIyMjM4NzM3MGE3ZGU1OQ&ctz=Europe/Paris&hl=en_GB. Date?: Toutes les semaines entre 18:00 et 19:00 le Mercredi Paris Lieu : IRC #cdi-dev channel on freenode Appel vid?o: https://plus.google.com/hangouts/_/sabot-durand.net/antoine-cdi Agenda?: ASD Perso Participants?: * Antoine Sabot-Durand- organisateur * cdi-dev D?tails de l'?v?nement : https://www.google.com/calendar/event?action=VIEW&eid=XzcxMGpnZ3BrNjEwamliOXA2OHNrNGI5azY0cjM0YmExOGNzajBiOW02MTIzYWgxZzcwb2phZ2hsNm8gY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0Y2Q1YmEzMjU2NzNhZjM4MTFkMDQ5MWU4MjhiYzg2NWUyYjU4YWJhYg&ctz=Europe/Paris&hl=fr Invitation de Google?Agenda?: https://www.google.com/calendar/ Vous recevez ce message ? l'adresse cdi-dev at lists.jboss.org, car vous participez ? cet ?v?nement. Pour ne plus recevoir de notifications pour cet ?v?nement ? l'avenir, refusez cet ?v?nement. Vous avez ?galement la possibilit? de cr?er un compte Google sur la page https://www.google.com/calendar/ et de d?finir vous-m?me les param?tres de notification pour l'int?gralit? de votre agenda. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150317/9b6900bb/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 2356 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150317/9b6900bb/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 2413 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150317/9b6900bb/attachment-0003.bin From werner.keil at gmail.com Tue Mar 17 11:20:22 2015 From: werner.keil at gmail.com (Werner Keil) Date: Tue, 17 Mar 2015 16:20:22 +0100 Subject: [cdi-dev] Invitation: CDI weekly meeting - Toutes les semaines entre Message-ID: It's all French, but I suppose the meeting is today not tomorrow? As mentioned, I can't use IRC in the office, and there's an overlap with JSR 364 (phone call works as long as it's not an international line) so I won't be able to join this week I'm afraid. If Europe also gets to Daylight Saving, the other call may be later, then I could probably attend both (from home;-) Werner On Tue, Mar 17, 2015 at 4:06 PM, wrote: > Send cdi-dev mailing list submissions to > cdi-dev at lists.jboss.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.jboss.org/mailman/listinfo/cdi-dev > or, via email, send a message with subject or body 'help' to > cdi-dev-request at lists.jboss.org > > You can reach the person managing the list at > cdi-dev-owner at lists.jboss.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of cdi-dev digest..." > > > Today's Topics: > > 1. Re: CDI SE Google Doc Updated (Martin Kouba) > 2. Invitation: CDI weekly meeting - Toutes les semaines entre > 18:00 et 19:00 le Mercredi (ASD Perso) (Antoine Sabot-Durand) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 17 Mar 2015 13:05:40 +0100 > From: Martin Kouba > Subject: Re: [cdi-dev] CDI SE Google Doc Updated > To: "John D. Ament" , Jozef Hartinger > , Antoine Sabot-Durand < > antoine at sabot-durand.net> > Cc: "cdi-dev at lists.jboss.org" > Message-ID: <55081894.8050104 at redhat.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > Dne 17.3.2015 v 10:49 John D. Ament napsal(a): > > > > > > On Tue, Mar 17, 2015 at 4:50 AM Martin Kouba > > wrote: > > > > It's ok to have the same default bean discovery mode in Java SE. > > However, I think there is no easy way to scan the classpath and > "detect" > > bean archives without beans.xml, i.e. implicit bean archives without > the > > descriptor. > > > > > > You should be able to read java.class.path to determine the possible > > archives. Then use the URL of the class itself to find which JAR it > > came from. > > I'm not sure this will cover all use-cases (Web Start, extension > classes, ...). Moreover, elements of the class are platform-specific. So > it wouldn't be trivial to parse it. > > > > > > > That's the reason why bean archives without beans.xml are not > supported > > in Weld SE. > > > > If anyone knows how to implement this properly, speak out. > > > > Martin > > > > Dne 17.3.2015 v 07:22 Jozef Hartinger napsal(a): > > > > > > On 03/16/2015 05:45 PM, Antoine Sabot-Durand wrote: > > >> > > >>> Le 16 mars 2015 ? 11:02, Jozef Hartinger > > > >>> >> a > > ?crit : > > >>> > > >>> Btw was there any further discussion about the bean discovery > > mode in SE > > >>> > > >> > > >> For the time being we decided to have the same discovery mode in > SE > > >> (default to Annotated). If someone has a good reason to change > the > > >> default mode in SE and/or add a new discovery mode, I?d be glad > to > > >> hear about it. > > > > > http://lists.jboss.org/__pipermail/cdi-dev/2015-March/__006334.html > > > > >> > > >> > > >>> On 03/16/2015 10:45 AM, Jozef Hartinger wrote: > > >>>> The CDIProvider serves as a kind of SPI for CDI's static > > methods to > > >>>> be able to call into the implementation. I don't think reusing > it > > >>>> also as a user-facing code is a good idea. What people > > suggesting to > > >>>> reuse CDIProvider had in mind, I think, was to reuse it as the > SPI > > >>>> for talking to the CDI implementation instead. That way, the > > >>>> initialize() static method of > > CDIContainer/StartedCDI/__whatever we > > >>>> call it can use CDIProvider internally to actually start the > > container. > > >>>> > > >>>> In addition, the current proposal does not make it possible to > > >>>> implement parallel container instances. > > >>>> > > >>>> Jozef > > >>>> > > >>>> On 03/15/2015 05:03 PM, John D. Ament wrote: > > >>>>> HI all, > > >>>>> > > >>>>> Apologies for being a week late on getting this doc > together. I > > >>>>> had some personal issues pop up after my leg came out of its > cast > > >>>>> that consumed most of my week last week. > > >>>>> > > >>>>> Anywho, I've updated the doc with a summary of what was > discussed > > >>>>> with CDI SE bootstrap support. You can find that here: > > >>>>> > > > https://docs.google.com/__document/d/1LgsGT-__AAlrF72Z5pW4xNQiVjUHGUME46ZmB-__wwF35Yw/edit?usp=sharing > > < > https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing > > > > >>>>> > > >>>>> There are two minor changes that I made from where we last > > >>>>> discussed, as when I was putting together code I found some > gaps > > >>>>> and figured it best to fix them here than later. > > >>>>> > > >>>>> 1. CDIProvider does not implement AutoCloseable. Since CDI > class > > >>>>> maintains a reference to the provider, implementing > AutoCloseable > > >>>>> was not adding anything. > > >>>>> > > >>>>> 2. I added a method boolean isInitialized() so that the > > caller can > > >>>>> know if they need to start the container (or if it's already > > running). > > >>>>> > > >>>>> Locally, I've also modified the CDI.current() method to use > > >>>>> getCDIProvider() instead of internally finding the provider > since > > >>>>> we now have a getter. > > >>>>> > > >>>>> One thing I'd like to get feedback on is if calling > > >>>>> initialize/shutdown in a container should throw > > >>>>> IllegalStateException, or probably better to throw > > >>>>> UnsupportedOperationException when called in EE containers. > > >>>>> > > >>>>> Let me know your thoughts. > > >>>>> > > >>>>> John > > >>>>> > > >>>>> > > >>>>> > > >>>>> _________________________________________________ > > >>>>> cdi-dev mailing list > > >>>>> cdi-dev at lists.jboss.org > > >>>>> https://lists.jboss.org/__mailman/listinfo/cdi-dev > > > > >>>>> > > >>>>> Note that for all code provided on this list, the provider > > licenses the code under the Apache License, Version 2 > > (http://www.apache.org/__licenses/LICENSE-2.0.html > > ). For all other > > ideas provided on this list, the provider waives all patent and > > other intellectual property rights inherent in such information. > > >>>> > > >>>> > > >>>> > > >>>> _________________________________________________ > > >>>> cdi-dev mailing list > > >>>> cdi-dev at lists.jboss.org > > >>>> https://lists.jboss.org/__mailman/listinfo/cdi-dev > > > > >>>> > > >>>> Note that for all code provided on this list, the provider > > licenses the code under the Apache License, Version 2 > > (http://www.apache.org/__licenses/LICENSE-2.0.html > > ). For all other > > ideas provided on this list, the provider waives all patent and > > other intellectual property rights inherent in such information. > > >>> > > >>> _________________________________________________ > > >>> cdi-dev mailing list > > >>> cdi-dev at lists.jboss.org > > > > > >>> https://lists.jboss.org/__mailman/listinfo/cdi-dev > > > > >>> > > >>> Note that for all code provided on this list, the provider > licenses > > >>> the code under the Apache License, Version 2 > > >>> (http://www.apache.org/__licenses/LICENSE-2.0.html > > ). For all other > > >>> ideas provided on this list, the provider waives all patent and > > other > > >>> intellectual property rights inherent in such information. > > >> > > > > > > > > > > > > _________________________________________________ > > > cdi-dev mailing list > > > cdi-dev at lists.jboss.org > > > https://lists.jboss.org/__mailman/listinfo/cdi-dev > > > > > > > > Note that for all code provided on this list, the provider > > licenses the code under the Apache License, Version 2 > > (http://www.apache.org/__licenses/LICENSE-2.0.html > > ). For all other > > ideas provided on this list, the provider waives all patent and > > other intellectual property rights inherent in such information. > > > > > _________________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/__mailman/listinfo/cdi-dev > > > > > > Note that for all code provided on this list, the provider licenses > > the code under the Apache License, Version 2 > > (http://www.apache.org/__licenses/LICENSE-2.0.html > > ). For all other > > ideas provided on this list, the provider waives all patent and > > other intellectual property rights inherent in such information. > > > > > > ------------------------------ > > Message: 2 > Date: Tue, 17 Mar 2015 15:06:12 +0000 > From: Antoine Sabot-Durand > Subject: [cdi-dev] Invitation: CDI weekly meeting - Toutes les > semaines entre 18:00 et 19:00 le Mercredi (ASD Perso) > To: cdi-dev > Message-ID: <001a11c3ca14af712a05117d4e78 at google.com> > Content-Type: text/plain; charset="iso-8859-1" > > Vous avez ?t? invit? ? l'?v?nement suivant. > > Titre : CDI weekly meeting > View your event at > > https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3Btc292ZnRvMWpkcWsgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZGU3ZDQwYmRmMTA4MDY2YzgyOTQ0ZGIwMzIyMjM4NzM3MGE3ZGU1OQ&ctz=Europe/Paris&hl=en_GB > . > View your event at > > https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3Btc292ZnRvMWpkcWsgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZGU3ZDQwYmRmMTA4MDY2YzgyOTQ0ZGIwMzIyMjM4NzM3MGE3ZGU1OQ&ctz=Europe/Paris&hl=en_GB > . > View your event at > > https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3Btc292ZnRvMWpkcWsgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZGU3ZDQwYmRmMTA4MDY2YzgyOTQ0ZGIwMzIyMjM4NzM3MGE3ZGU1OQ&ctz=Europe/Paris&hl=en_GB. > Date?: Toutes les semaines entre 18:00 et 19:00 le Mercredi Paris > Lieu : IRC #cdi-dev channel on freenode > Appel vid?o: > https://plus.google.com/hangouts/_/sabot-durand.net/antoine-cdi > < > https://plus.google.com/hangouts/_/sabot-durand.net/antoine-cdi?hceid=YW50b2luZUBzYWJvdC1kdXJhbmQubmV0._710jggpk610jib9p68sk4b9k64r34ba18csj0b9m6123ah1g70ojaghl6o > > > Agenda?: ASD Perso > Participants?: > * Antoine Sabot-Durand- organisateur > * cdi-dev > > D?tails de l'?v?nement : > > https://www.google.com/calendar/event?action=VIEW&eid=XzcxMGpnZ3BrNjEwamliOXA2OHNrNGI5azY0cjM0YmExOGNzajBiOW02MTIzYWgxZzcwb2phZ2hsNm8gY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0Y2Q1YmEzMjU2NzNhZjM4MTFkMDQ5MWU4MjhiYzg2NWUyYjU4YWJhYg&ctz=Europe/Paris&hl=fr > > Invitation de Google?Agenda?: https://www.google.com/calendar/ > > Vous recevez ce message ? l'adresse cdi-dev at lists.jboss.org, car vous > participez ? cet ?v?nement. > > Pour ne plus recevoir de notifications pour cet ?v?nement ? l'avenir, > refusez cet ?v?nement. Vous avez ?galement la possibilit? de cr?er un > compte Google sur la page https://www.google.com/calendar/ et de d?finir > vous-m?me les param?tres de notification pour l'int?gralit? de votre > agenda. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20150317/9b6900bb/attachment.html > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: text/calendar > Size: 2356 bytes > Desc: not available > Url : > http://lists.jboss.org/pipermail/cdi-dev/attachments/20150317/9b6900bb/attachment.bin > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: invite.ics > Type: application/ics > Size: 2413 bytes > Desc: not available > Url : > http://lists.jboss.org/pipermail/cdi-dev/attachments/20150317/9b6900bb/attachment-0001.bin > > ------------------------------ > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > End of cdi-dev Digest, Vol 52, Issue 53 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150317/7a15193d/attachment-0001.html From antoine at sabot-durand.net Tue Mar 17 11:36:50 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 17 Mar 2015 16:36:50 +0100 Subject: [cdi-dev] Choosing a date for next CDI Face to Face meeting Message-ID: <5BF5FCD9-FBF2-4A46-AB8F-0335C2618BB8@sabot-durand.net> Hi Guys, We?re planning to organize a new face to face meeting for CDI EG and community. The place will be in Brno (at Red Hat HQ in Czech Republic) and we?re planning to set it up on a Saturday to avoid loosing more than a day of work for you all. As we plan to have this meeting for a whole day long you?ll probably have to arrive on Friday evening and leave on Saturday morning. Please fill the following Doodle to help use choose the best date for this meeting: http://doodle.com/ecvpshxceup8b278 Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150317/aeba404d/attachment.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/20150317/aeba404d/attachment.bin From antoine at sabot-durand.net Tue Mar 17 13:14:44 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 17 Mar 2015 18:14:44 +0100 Subject: [cdi-dev] Wrong google invitation. Message-ID: <51423341-BF0C-4B3A-9663-CB2E24485B9B@sabot-durand.net> Hi all, I send by mistake a false invitation for our meeting. It?s not on Wednesday but on Tuesday. Sorry for that 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/20150317/b0d65819/attachment.bin From john.d.ament at gmail.com Tue Mar 17 13:30:58 2015 From: john.d.ament at gmail.com (John D. Ament) Date: Tue, 17 Mar 2015 17:30:58 +0000 Subject: [cdi-dev] Wrong google invitation. In-Reply-To: <51423341-BF0C-4B3A-9663-CB2E24485B9B@sabot-durand.net> References: <51423341-BF0C-4B3A-9663-CB2E24485B9B@sabot-durand.net> Message-ID: I've never actually received a google invite. On Tue, Mar 17, 2015 at 1:14 PM Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi all, > > I send by mistake a false invitation for our meeting. It?s not on > Wednesday but on Tuesday. > > Sorry for that > > Antoine > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 (http://www.apache.org/ > licenses/LICENSE-2.0.html). For all other ideas provided on this list, > the provider waives all patent and other intellectual property rights > inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150317/cf249687/attachment.html From antoine at sabot-durand.net Tue Mar 17 13:59:48 2015 From: antoine at sabot-durand.net (antoine at sabot-durand.net) Date: Tue, 17 Mar 2015 17:59:48 +0000 Subject: [cdi-dev] =?iso-8859-1?q?Invitation_mise_=E0_jour=3A_CDI_weekly_m?= =?iso-8859-1?q?eeting_-_Toutes_les_semaines_entre_18=3A00_et_19=3A?= =?iso-8859-1?q?00_le_Mardi_=28ASD_Perso=29?= Message-ID: <089e013d202483d7eb05117fbb93@google.com> Cet ?v?nement a ?t? modifi?. Titre : CDI weekly meeting View your event at https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3Btc292ZnRvMWpkcWsgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZGU3ZDQwYmRmMTA4MDY2YzgyOTQ0ZGIwMzIyMjM4NzM3MGE3ZGU1OQ&ctz=Europe/Paris&hl=en_GB. View your event at https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3Btc292ZnRvMWpkcWsgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZGU3ZDQwYmRmMTA4MDY2YzgyOTQ0ZGIwMzIyMjM4NzM3MGE3ZGU1OQ&ctz=Europe/Paris&hl=en_GB. View your event at https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3Btc292ZnRvMWpkcWsgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZGU3ZDQwYmRmMTA4MDY2YzgyOTQ0ZGIwMzIyMjM4NzM3MGE3ZGU1OQ&ctz=Europe/Paris&hl=en_GB. Date?: Toutes les semaines entre 18:00 et 19:00 le Mardi Paris (modifi?) Lieu : IRC #cdi-dev channel on freenode Appel vid?o: https://plus.google.com/hangouts/_/sabot-durand.net/antoine-cdi Agenda?: ASD Perso Participants?: * Antoine Sabot-Durand- organisateur * cdi-dev D?tails de l'?v?nement : https://www.google.com/calendar/event?action=VIEW&eid=XzcxMGpnZ3BrNjEwamliOXA2OHNrNGI5azY0cjM0YmExOGNzajBiOW02MTIzYWgxZzcwb2phZ2hsNm8gY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0Y2Q1YmEzMjU2NzNhZjM4MTFkMDQ5MWU4MjhiYzg2NWUyYjU4YWJhYg&ctz=Europe/Paris&hl=fr Invitation de Google?Agenda?: https://www.google.com/calendar/ Vous recevez ce message ? l'adresse cdi-dev at lists.jboss.org, car vous participez ? cet ?v?nement. Pour ne plus recevoir de notifications pour cet ?v?nement ? l'avenir, refusez cet ?v?nement. Vous avez ?galement la possibilit? de cr?er un compte Google sur la page https://www.google.com/calendar/ et de d?finir vous-m?me les param?tres de notification pour l'int?gralit? de votre agenda. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150317/2fbb5ad2/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 2347 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150317/2fbb5ad2/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 2404 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150317/2fbb5ad2/attachment-0003.bin From antoine at sabot-durand.net Wed Mar 18 03:48:49 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 18 Mar 2015 08:48:49 +0100 Subject: [cdi-dev] On @Observes for async events Message-ID: Hi all, Yesterday we had another meeting to try to find a better solution than explicitly activating async event on observer, without no success. I understand that we should go on on this feature so what I suggest is to have a meeting (an hangout) with people that want to try to find a better solution. If we find something we?ll do a last proposal, and in all case we?ll adopt the woking solution next week for this point. People interested with this please manifest yourself. If we have to go with opt-in (have to explicitly declare an observer supporting async event) we also have to validate the decision to use a member in @Observes (as it was decided before) or go back on that as mMark keep asking by introducing a new annotation to add on the observer (@Async or something similar). As I said when we discussed this point, I prefer the member in @Observes but we may have overlooked issues linked to backward compatibility. A third solution might be to introduce an @ObserveAsync to declare an asynchronous capable observer? I?m waiting for active feedback from you to find the best solution taking ALL aspects (not only the technicals one) into account. Thanks, 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/20150318/f1dc125f/attachment.bin From arne.limburg at openknowledge.de Wed Mar 18 04:05:30 2015 From: arne.limburg at openknowledge.de (Arne Limburg) Date: Wed, 18 Mar 2015 08:05:30 +0000 Subject: [cdi-dev] On @Observes for async events In-Reply-To: Message-ID: Hi to all, I think the biggest issue with backward compatibility is, that the current @Observes annotation by default has TransactionPhase.IN_PROGRESS. I think we can?t deal with this, if the default for observers would be async. So I think there is no way to specify async as default without loosing backward compatibility. Any other thoughts? Cheers, Arne Am 18.03.15 08:48 schrieb "Antoine Sabot-Durand" unter : >Hi all, > >Yesterday we had another meeting to try to find a better solution than >explicitly activating async event on observer, without no success. I >understand that we should go on on this feature so what I suggest is to >have a meeting (an hangout) with people that want to try to find a better >solution. If we find something we?ll do a last proposal, and in all case >we?ll adopt the woking solution next week for this point. People >interested with this please manifest yourself. > >If we have to go with opt-in (have to explicitly declare an observer >supporting async event) we also have to validate the decision to use a >member in @Observes (as it was decided before) or go back on that as >mMark keep asking by introducing a new annotation to add on the observer >(@Async or something similar). As I said when we discussed this point, I >prefer the member in @Observes but we may have overlooked issues linked >to backward compatibility. >A third solution might be to introduce an @ObserveAsync to declare an >asynchronous capable observer? > >I?m waiting for active feedback from you to find the best solution taking >ALL aspects (not only the technicals one) into account. > >Thanks, > >Antoine From antoine at sabot-durand.net Wed Mar 18 04:21:59 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 18 Mar 2015 09:21:59 +0100 Subject: [cdi-dev] On @Observes for async events In-Reply-To: References: Message-ID: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> Hi Arne, Sorry can you explain why? This value allows observer to be called inside or outside a transaction. What will be the compatibility issue? Antoine > Le 18 mars 2015 ? 09:05, Arne Limburg a ?crit : > > Hi to all, > > I think the biggest issue with backward compatibility is, that the current > @Observes annotation by default has TransactionPhase.IN_PROGRESS. > I think we can?t deal with this, if the default for observers would be > async. So I think there is no way to specify async as default without > loosing backward compatibility. > Any other thoughts? > > Cheers, > Arne > > > Am 18.03.15 08:48 schrieb "Antoine Sabot-Durand" unter > : > >> Hi all, >> >> Yesterday we had another meeting to try to find a better solution than >> explicitly activating async event on observer, without no success. I >> understand that we should go on on this feature so what I suggest is to >> have a meeting (an hangout) with people that want to try to find a better >> solution. If we find something we?ll do a last proposal, and in all case >> we?ll adopt the woking solution next week for this point. People >> interested with this please manifest yourself. >> >> If we have to go with opt-in (have to explicitly declare an observer >> supporting async event) we also have to validate the decision to use a >> member in @Observes (as it was decided before) or go back on that as >> mMark keep asking by introducing a new annotation to add on the observer >> (@Async or something similar). As I said when we discussed this point, I >> prefer the member in @Observes but we may have overlooked issues linked >> to backward compatibility. >> A third solution might be to introduce an @ObserveAsync to declare an >> asynchronous capable observer? >> >> I?m waiting for active feedback from you to find the best solution taking >> ALL aspects (not only the technicals one) into account. >> >> Thanks, >> >> 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/20150318/45576dc7/attachment.bin From arne.limburg at openknowledge.de Wed Mar 18 04:30:35 2015 From: arne.limburg at openknowledge.de (Arne Limburg) Date: Wed, 18 Mar 2015 08:30:35 +0000 Subject: [cdi-dev] On @Observes for async events In-Reply-To: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> Message-ID: Hi Antoine, The third bullet point in 10.5.1 of the CDI 1.1 spec states that the observer method must be called in the same transaction context as the event.fire(...) if it is no transactional observer (that is TransactionPhase.IN_PROGRESS). If the default behavior would be async, we would have to move the transaction context to another thread. To my best knowledge this would be the only situation in EE where this is the case. Cheers, Arne Am 18.03.15 09:21 schrieb "Antoine Sabot-Durand" unter : >Hi Arne, > >Sorry can you explain why? This value allows observer to be called inside >or outside a transaction. What will be the compatibility issue? > >Antoine > > >> Le 18 mars 2015 ? 09:05, Arne Limburg a >>?crit : >> >> Hi to all, >> >> I think the biggest issue with backward compatibility is, that the >>current >> @Observes annotation by default has TransactionPhase.IN_PROGRESS. >> I think we can?t deal with this, if the default for observers would be >> async. So I think there is no way to specify async as default without >> loosing backward compatibility. >> Any other thoughts? >> >> Cheers, >> Arne >> >> >> Am 18.03.15 08:48 schrieb "Antoine Sabot-Durand" unter >> : >> >>> Hi all, >>> >>> Yesterday we had another meeting to try to find a better solution than >>> explicitly activating async event on observer, without no success. I >>> understand that we should go on on this feature so what I suggest is to >>> have a meeting (an hangout) with people that want to try to find a >>>better >>> solution. If we find something we?ll do a last proposal, and in all >>>case >>> we?ll adopt the woking solution next week for this point. People >>> interested with this please manifest yourself. >>> >>> If we have to go with opt-in (have to explicitly declare an observer >>> supporting async event) we also have to validate the decision to use a >>> member in @Observes (as it was decided before) or go back on that as >>> mMark keep asking by introducing a new annotation to add on the >>>observer >>> (@Async or something similar). As I said when we discussed this point, >>>I >>> prefer the member in @Observes but we may have overlooked issues linked >>> to backward compatibility. >>> A third solution might be to introduce an @ObserveAsync to declare an >>> asynchronous capable observer? >>> >>> I?m waiting for active feedback from you to find the best solution >>>taking >>> ALL aspects (not only the technicals one) into account. >>> >>> Thanks, >>> >>> Antoine >> > From rmannibucau at gmail.com Wed Mar 18 04:42:48 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 18 Mar 2015 09:42:48 +0100 Subject: [cdi-dev] On @Observes for async events In-Reply-To: References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> Message-ID: Hi guys, think Mark is right and a new API (as fireAsync) would be better for users for: - understanding - compatibility (think to custom extensions using this flag) that said if we have @Async methods I think async observers are really useless, isn't it? Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-03-18 9:30 GMT+01:00 Arne Limburg : > Hi Antoine, > > The third bullet point in 10.5.1 of the CDI 1.1 spec states that the > observer method must be called in the same transaction context as the > event.fire(...) if it is no transactional observer (that is > TransactionPhase.IN_PROGRESS). > If the default behavior would be async, we would have to move the > transaction context to another thread. To my best knowledge this would be > the only situation in EE where this is the case. > > Cheers, > Arne > > Am 18.03.15 09:21 schrieb "Antoine Sabot-Durand" unter > : > > >Hi Arne, > > > >Sorry can you explain why? This value allows observer to be called inside > >or outside a transaction. What will be the compatibility issue? > > > >Antoine > > > > > >> Le 18 mars 2015 ? 09:05, Arne Limburg a > >>?crit : > >> > >> Hi to all, > >> > >> I think the biggest issue with backward compatibility is, that the > >>current > >> @Observes annotation by default has TransactionPhase.IN_PROGRESS. > >> I think we can?t deal with this, if the default for observers would be > >> async. So I think there is no way to specify async as default without > >> loosing backward compatibility. > >> Any other thoughts? > >> > >> Cheers, > >> Arne > >> > >> > >> Am 18.03.15 08:48 schrieb "Antoine Sabot-Durand" unter > >> : > >> > >>> Hi all, > >>> > >>> Yesterday we had another meeting to try to find a better solution than > >>> explicitly activating async event on observer, without no success. I > >>> understand that we should go on on this feature so what I suggest is to > >>> have a meeting (an hangout) with people that want to try to find a > >>>better > >>> solution. If we find something we?ll do a last proposal, and in all > >>>case > >>> we?ll adopt the woking solution next week for this point. People > >>> interested with this please manifest yourself. > >>> > >>> If we have to go with opt-in (have to explicitly declare an observer > >>> supporting async event) we also have to validate the decision to use a > >>> member in @Observes (as it was decided before) or go back on that as > >>> mMark keep asking by introducing a new annotation to add on the > >>>observer > >>> (@Async or something similar). As I said when we discussed this point, > >>>I > >>> prefer the member in @Observes but we may have overlooked issues linked > >>> to backward compatibility. > >>> A third solution might be to introduce an @ObserveAsync to declare an > >>> asynchronous capable observer? > >>> > >>> I?m waiting for active feedback from you to find the best solution > >>>taking > >>> ALL aspects (not only the technicals one) into account. > >>> > >>> Thanks, > >>> > >>> Antoine > >> > > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/a0d7bb55/attachment-0001.html From antoine at sabot-durand.net Wed Mar 18 04:55:13 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 18 Mar 2015 09:55:13 +0100 Subject: [cdi-dev] On @Observes for async events In-Reply-To: References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> Message-ID: <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> > > Le 18 mars 2015 ? 09:42, Romain Manni-Bucau a ?crit : > > Hi guys, > > think Mark is right and a new API (as fireAsync) would be better for users for: > - understanding > - compatibility (think to custom extensions using this flag) My point here is to avoid making CDI the EJB next by introducing @Async or @Asynchronous annotation in the spec. This kind of annotation should be shared by other specs and would have a better fit in concurrency utilities or commons annotations spec. > that said if we have @Async methods I think async observers are really useless, isn't it? @Async is rather useless IMO when you see how easy it is do async operation with Java 8. On the other hand Async observers are a at a higher level since they are called thru the Container and that the fire point must know what?s going on at the other side. > > > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > 2015-03-18 9:30 GMT+01:00 Arne Limburg >: > Hi Antoine, > > The third bullet point in 10.5.1 of the CDI 1.1 spec states that the > observer method must be called in the same transaction context as the > event.fire(...) if it is no transactional observer (that is > TransactionPhase.IN_PROGRESS). > If the default behavior would be async, we would have to move the > transaction context to another thread. To my best knowledge this would be > the only situation in EE where this is the case. > > Cheers, > Arne > > Am 18.03.15 09:21 schrieb "Antoine Sabot-Durand" unter > >: > > >Hi Arne, > > > >Sorry can you explain why? This value allows observer to be called inside > >or outside a transaction. What will be the compatibility issue? > > > >Antoine > > > > > >> Le 18 mars 2015 ? 09:05, Arne Limburg > a > >>?crit : > >> > >> Hi to all, > >> > >> I think the biggest issue with backward compatibility is, that the > >>current > >> @Observes annotation by default has TransactionPhase.IN_PROGRESS. > >> I think we can?t deal with this, if the default for observers would be > >> async. So I think there is no way to specify async as default without > >> loosing backward compatibility. > >> Any other thoughts? > >> > >> Cheers, > >> Arne > >> > >> > >> Am 18.03.15 08:48 schrieb "Antoine Sabot-Durand" unter > >> >: > >> > >>> Hi all, > >>> > >>> Yesterday we had another meeting to try to find a better solution than > >>> explicitly activating async event on observer, without no success. I > >>> understand that we should go on on this feature so what I suggest is to > >>> have a meeting (an hangout) with people that want to try to find a > >>>better > >>> solution. If we find something we?ll do a last proposal, and in all > >>>case > >>> we?ll adopt the woking solution next week for this point. People > >>> interested with this please manifest yourself. > >>> > >>> If we have to go with opt-in (have to explicitly declare an observer > >>> supporting async event) we also have to validate the decision to use a > >>> member in @Observes (as it was decided before) or go back on that as > >>> mMark keep asking by introducing a new annotation to add on the > >>>observer > >>> (@Async or something similar). As I said when we discussed this point, > >>>I > >>> prefer the member in @Observes but we may have overlooked issues linked > >>> to backward compatibility. > >>> A third solution might be to introduce an @ObserveAsync to declare an > >>> asynchronous capable observer? > >>> > >>> I?m waiting for active feedback from you to find the best solution > >>>taking > >>> ALL aspects (not only the technicals one) into account. > >>> > >>> Thanks, > >>> > >>> Antoine > >> > > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/3822ae8d/attachment.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/20150318/3822ae8d/attachment.bin From rmannibucau at gmail.com Wed Mar 18 04:58:04 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 18 Mar 2015 09:58:04 +0100 Subject: [cdi-dev] On @Observes for async events In-Reply-To: <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> Message-ID: 2015-03-18 9:55 GMT+01:00 Antoine Sabot-Durand : > > Le 18 mars 2015 ? 09:42, Romain Manni-Bucau a > ?crit : > > Hi guys, > > think Mark is right and a new API (as fireAsync) would be better for users > for: > - understanding > - compatibility (think to custom extensions using this flag) > > > My point here is to avoid making CDI the EJB next by introducing @Async or > @Asynchronous annotation in the spec. This kind of annotation should be > shared by other specs and would have a better fit in concurrency utilities > or commons annotations spec. > > +1 > that said if we have @Async methods I think async observers are really > useless, isn't it? > > > @Async is rather useless IMO when you see how easy it is do async > operation with Java 8. On the other hand Async observers are a at a higher > level since they are called thru the Container and that the fire point must > know what?s going on at the other side. > > don't get it, observer can use j8 then to do its stuff asynchronously so maybe the feature if finally useless assuming you run on j8. That said saying a method is async is still more elegant than firing it in a pool you don't control. > > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2015-03-18 9:30 GMT+01:00 Arne Limburg : > >> Hi Antoine, >> >> The third bullet point in 10.5.1 of the CDI 1.1 spec states that the >> observer method must be called in the same transaction context as the >> event.fire(...) if it is no transactional observer (that is >> TransactionPhase.IN_PROGRESS). >> If the default behavior would be async, we would have to move the >> transaction context to another thread. To my best knowledge this would be >> the only situation in EE where this is the case. >> >> Cheers, >> Arne >> >> Am 18.03.15 09:21 schrieb "Antoine Sabot-Durand" unter >> : >> >> >Hi Arne, >> > >> >Sorry can you explain why? This value allows observer to be called inside >> >or outside a transaction. What will be the compatibility issue? >> > >> >Antoine >> > >> > >> >> Le 18 mars 2015 ? 09:05, Arne Limburg >> a >> >>?crit : >> >> >> >> Hi to all, >> >> >> >> I think the biggest issue with backward compatibility is, that the >> >>current >> >> @Observes annotation by default has TransactionPhase.IN_PROGRESS. >> >> I think we can?t deal with this, if the default for observers would be >> >> async. So I think there is no way to specify async as default without >> >> loosing backward compatibility. >> >> Any other thoughts? >> >> >> >> Cheers, >> >> Arne >> >> >> >> >> >> Am 18.03.15 08:48 schrieb "Antoine Sabot-Durand" unter >> >> : >> >> >> >>> Hi all, >> >>> >> >>> Yesterday we had another meeting to try to find a better solution than >> >>> explicitly activating async event on observer, without no success. I >> >>> understand that we should go on on this feature so what I suggest is >> to >> >>> have a meeting (an hangout) with people that want to try to find a >> >>>better >> >>> solution. If we find something we?ll do a last proposal, and in all >> >>>case >> >>> we?ll adopt the woking solution next week for this point. People >> >>> interested with this please manifest yourself. >> >>> >> >>> If we have to go with opt-in (have to explicitly declare an observer >> >>> supporting async event) we also have to validate the decision to use a >> >>> member in @Observes (as it was decided before) or go back on that as >> >>> mMark keep asking by introducing a new annotation to add on the >> >>>observer >> >>> (@Async or something similar). As I said when we discussed this point, >> >>>I >> >>> prefer the member in @Observes but we may have overlooked issues >> linked >> >>> to backward compatibility. >> >>> A third solution might be to introduce an @ObserveAsync to declare an >> >>> asynchronous capable observer? >> >>> >> >>> I?m waiting for active feedback from you to find the best solution >> >>>taking >> >>> ALL aspects (not only the technicals one) into account. >> >>> >> >>> Thanks, >> >>> >> >>> Antoine >> >> >> > >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/f3813ab8/attachment-0001.html From antoine at sabot-durand.net Wed Mar 18 05:33:13 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 18 Mar 2015 10:33:13 +0100 Subject: [cdi-dev] On @Observes for async events In-Reply-To: References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> Message-ID: <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> > Le 18 mars 2015 ? 09:58, Romain Manni-Bucau a ?crit : > > > 2015-03-18 9:55 GMT+01:00 Antoine Sabot-Durand >: >> >> Le 18 mars 2015 ? 09:42, Romain Manni-Bucau > a ?crit : >> >> Hi guys, >> >> think Mark is right and a new API (as fireAsync) would be better for users for: >> - understanding >> - compatibility (think to custom extensions using this flag) > > My point here is to avoid making CDI the EJB next by introducing @Async or @Asynchronous annotation in the spec. This kind of annotation should be shared by other specs and would have a better fit in concurrency utilities or commons annotations spec. > > > +1 > >> that said if we have @Async methods I think async observers are really useless, isn't it? > > @Async is rather useless IMO when you see how easy it is do async operation with Java 8. On the other hand Async observers are a at a higher level since they are called thru the Container and that the fire point must know what?s going on at the other side. > > > don't get it, observer can use j8 then to do its stuff asynchronously so maybe the feature if finally useless assuming you run on j8. And how do you make your fire point know that one of its observer will be asynchronous ? How do you manage event ordering (as we plan to support it for async event as well). I think we shouldn?t see the event bus as a standard method call but something more featured (think about parameter injection in observer methods or transactional behavior) > > That said saying a method is async is still more elegant than firing it in a pool you don't control. fireAsync will have a signature allowing you to pass your own Executor to give you better control on thread pool > >> >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >> 2015-03-18 9:30 GMT+01:00 Arne Limburg >: >> Hi Antoine, >> >> The third bullet point in 10.5.1 of the CDI 1.1 spec states that the >> observer method must be called in the same transaction context as the >> event.fire(...) if it is no transactional observer (that is >> TransactionPhase.IN_PROGRESS). >> If the default behavior would be async, we would have to move the >> transaction context to another thread. To my best knowledge this would be >> the only situation in EE where this is the case. >> >> Cheers, >> Arne >> >> Am 18.03.15 09:21 schrieb "Antoine Sabot-Durand" unter >> >: >> >> >Hi Arne, >> > >> >Sorry can you explain why? This value allows observer to be called inside >> >or outside a transaction. What will be the compatibility issue? >> > >> >Antoine >> > >> > >> >> Le 18 mars 2015 ? 09:05, Arne Limburg > a >> >>?crit : >> >> >> >> Hi to all, >> >> >> >> I think the biggest issue with backward compatibility is, that the >> >>current >> >> @Observes annotation by default has TransactionPhase.IN_PROGRESS. >> >> I think we can?t deal with this, if the default for observers would be >> >> async. So I think there is no way to specify async as default without >> >> loosing backward compatibility. >> >> Any other thoughts? >> >> >> >> Cheers, >> >> Arne >> >> >> >> >> >> Am 18.03.15 08:48 schrieb "Antoine Sabot-Durand" unter >> >> >: >> >> >> >>> Hi all, >> >>> >> >>> Yesterday we had another meeting to try to find a better solution than >> >>> explicitly activating async event on observer, without no success. I >> >>> understand that we should go on on this feature so what I suggest is to >> >>> have a meeting (an hangout) with people that want to try to find a >> >>>better >> >>> solution. If we find something we?ll do a last proposal, and in all >> >>>case >> >>> we?ll adopt the woking solution next week for this point. People >> >>> interested with this please manifest yourself. >> >>> >> >>> If we have to go with opt-in (have to explicitly declare an observer >> >>> supporting async event) we also have to validate the decision to use a >> >>> member in @Observes (as it was decided before) or go back on that as >> >>> mMark keep asking by introducing a new annotation to add on the >> >>>observer >> >>> (@Async or something similar). As I said when we discussed this point, >> >>>I >> >>> prefer the member in @Observes but we may have overlooked issues linked >> >>> to backward compatibility. >> >>> A third solution might be to introduce an @ObserveAsync to declare an >> >>> asynchronous capable observer? >> >>> >> >>> I?m waiting for active feedback from you to find the best solution >> >>>taking >> >>> ALL aspects (not only the technicals one) into account. >> >>> >> >>> Thanks, >> >>> >> >>> Antoine >> >> >> > >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/a1043f4b/attachment.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/20150318/a1043f4b/attachment.bin From rmannibucau at gmail.com Wed Mar 18 05:53:20 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 18 Mar 2015 10:53:20 +0100 Subject: [cdi-dev] On @Observes for async events In-Reply-To: <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> Message-ID: 2015-03-18 10:33 GMT+01:00 Antoine Sabot-Durand : > > Le 18 mars 2015 ? 09:58, Romain Manni-Bucau a > ?crit : > > > 2015-03-18 9:55 GMT+01:00 Antoine Sabot-Durand : > >> >> Le 18 mars 2015 ? 09:42, Romain Manni-Bucau a >> ?crit : >> >> Hi guys, >> >> think Mark is right and a new API (as fireAsync) would be better for >> users for: >> - understanding >> - compatibility (think to custom extensions using this flag) >> >> >> My point here is to avoid making CDI the EJB next by introducing @Async >> or @Asynchronous annotation in the spec. This kind of annotation should be >> shared by other specs and would have a better fit in concurrency utilities >> or commons annotations spec. >> >> > +1 > > >> that said if we have @Async methods I think async observers are really >> useless, isn't it? >> >> >> @Async is rather useless IMO when you see how easy it is do async >> operation with Java 8. On the other hand Async observers are a at a higher >> level since they are called thru the Container and that the fire point must >> know what?s going on at the other side. >> >> > don't get it, observer can use j8 then to do its stuff asynchronously so > maybe the feature if finally useless assuming you run on j8. > > > And how do you make your fire point know that one of its observer will be > asynchronous ? How do you manage event ordering (as we plan to support it > for async event as well). I think we shouldn?t see the event bus as a > standard method call but something more featured (think about parameter > injection in observer methods or transactional behavior) > > then this is not asynchronism and just an observer queue which is something different IMO > > That said saying a method is async is still more elegant than firing it in > a pool you don't control. > > > fireAsync will have a signature allowing you to pass your own Executor to > give you better control on thread pool > > a default one should be bound to the bm - main case IMO. having an app executor is not a very nice solution in term of API. > > >> >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> 2015-03-18 9:30 GMT+01:00 Arne Limburg : >> >>> Hi Antoine, >>> >>> The third bullet point in 10.5.1 of the CDI 1.1 spec states that the >>> observer method must be called in the same transaction context as the >>> event.fire(...) if it is no transactional observer (that is >>> TransactionPhase.IN_PROGRESS). >>> If the default behavior would be async, we would have to move the >>> transaction context to another thread. To my best knowledge this would be >>> the only situation in EE where this is the case. >>> >>> Cheers, >>> Arne >>> >>> Am 18.03.15 09:21 schrieb "Antoine Sabot-Durand" unter >>> : >>> >>> >Hi Arne, >>> > >>> >Sorry can you explain why? This value allows observer to be called >>> inside >>> >or outside a transaction. What will be the compatibility issue? >>> > >>> >Antoine >>> > >>> > >>> >> Le 18 mars 2015 ? 09:05, Arne Limburg >>> a >>> >>?crit : >>> >> >>> >> Hi to all, >>> >> >>> >> I think the biggest issue with backward compatibility is, that the >>> >>current >>> >> @Observes annotation by default has TransactionPhase.IN_PROGRESS. >>> >> I think we can?t deal with this, if the default for observers would be >>> >> async. So I think there is no way to specify async as default without >>> >> loosing backward compatibility. >>> >> Any other thoughts? >>> >> >>> >> Cheers, >>> >> Arne >>> >> >>> >> >>> >> Am 18.03.15 08:48 schrieb "Antoine Sabot-Durand" unter >>> >> : >>> >> >>> >>> Hi all, >>> >>> >>> >>> Yesterday we had another meeting to try to find a better solution >>> than >>> >>> explicitly activating async event on observer, without no success. I >>> >>> understand that we should go on on this feature so what I suggest is >>> to >>> >>> have a meeting (an hangout) with people that want to try to find a >>> >>>better >>> >>> solution. If we find something we?ll do a last proposal, and in all >>> >>>case >>> >>> we?ll adopt the woking solution next week for this point. People >>> >>> interested with this please manifest yourself. >>> >>> >>> >>> If we have to go with opt-in (have to explicitly declare an observer >>> >>> supporting async event) we also have to validate the decision to use >>> a >>> >>> member in @Observes (as it was decided before) or go back on that as >>> >>> mMark keep asking by introducing a new annotation to add on the >>> >>>observer >>> >>> (@Async or something similar). As I said when we discussed this >>> point, >>> >>>I >>> >>> prefer the member in @Observes but we may have overlooked issues >>> linked >>> >>> to backward compatibility. >>> >>> A third solution might be to introduce an @ObserveAsync to declare an >>> >>> asynchronous capable observer? >>> >>> >>> >>> I?m waiting for active feedback from you to find the best solution >>> >>>taking >>> >>> ALL aspects (not only the technicals one) into account. >>> >>> >>> >>> Thanks, >>> >>> >>> >>> Antoine >>> >> >>> > >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>> provided on this list, the provider waives all patent and other >>> intellectual property rights inherent in such information. >>> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/4c7348a4/attachment-0001.html From antoine at sabot-durand.net Wed Mar 18 06:03:05 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 18 Mar 2015 11:03:05 +0100 Subject: [cdi-dev] On @Observes for async events In-Reply-To: References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> Message-ID: <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> > Le 18 mars 2015 ? 10:53, Romain Manni-Bucau a ?crit : > > > 2015-03-18 10:33 GMT+01:00 Antoine Sabot-Durand >: > >> Le 18 mars 2015 ? 09:58, Romain Manni-Bucau > a ?crit : >> >> >> 2015-03-18 9:55 GMT+01:00 Antoine Sabot-Durand >: >>> >>> Le 18 mars 2015 ? 09:42, Romain Manni-Bucau > a ?crit : >>> >>> Hi guys, >>> >>> think Mark is right and a new API (as fireAsync) would be better for users for: >>> - understanding >>> - compatibility (think to custom extensions using this flag) >> >> My point here is to avoid making CDI the EJB next by introducing @Async or @Asynchronous annotation in the spec. This kind of annotation should be shared by other specs and would have a better fit in concurrency utilities or commons annotations spec. >> >> >> +1 >> >>> that said if we have @Async methods I think async observers are really useless, isn't it? >> >> @Async is rather useless IMO when you see how easy it is do async operation with Java 8. On the other hand Async observers are a at a higher level since they are called thru the Container and that the fire point must know what?s going on at the other side. >> >> >> don't get it, observer can use j8 then to do its stuff asynchronously so maybe the feature if finally useless assuming you run on j8. > > And how do you make your fire point know that one of its observer will be asynchronous ? How do you manage event ordering (as we plan to support it for async event as well). I think we shouldn?t see the event bus as a standard method call but something more featured (think about parameter injection in observer methods or transactional behavior) > > > then this is not asynchronism and just an observer queue which is something different IMO. From user pov it?s async : "I fire an event and get the control back right away". The impl will make an observer queue in an other thread, but the user exp is totally different than classic fire(). > >> >> That said saying a method is async is still more elegant than firing it in a pool you don't control. > > fireAsync will have a signature allowing you to pass your own Executor to give you better control on thread pool > > > a default one should be bound to the bm - main case IMO. having an app executor is not a very nice solution in term of API. Yes it was already discussed, there will be 2 signatures for fireAsync(). >> >>> >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>> 2015-03-18 9:30 GMT+01:00 Arne Limburg >: >>> Hi Antoine, >>> >>> The third bullet point in 10.5.1 of the CDI 1.1 spec states that the >>> observer method must be called in the same transaction context as the >>> event.fire(...) if it is no transactional observer (that is >>> TransactionPhase.IN_PROGRESS). >>> If the default behavior would be async, we would have to move the >>> transaction context to another thread. To my best knowledge this would be >>> the only situation in EE where this is the case. >>> >>> Cheers, >>> Arne >>> >>> Am 18.03.15 09:21 schrieb "Antoine Sabot-Durand" unter >>> >: >>> >>> >Hi Arne, >>> > >>> >Sorry can you explain why? This value allows observer to be called inside >>> >or outside a transaction. What will be the compatibility issue? >>> > >>> >Antoine >>> > >>> > >>> >> Le 18 mars 2015 ? 09:05, Arne Limburg > a >>> >>?crit : >>> >> >>> >> Hi to all, >>> >> >>> >> I think the biggest issue with backward compatibility is, that the >>> >>current >>> >> @Observes annotation by default has TransactionPhase.IN_PROGRESS. >>> >> I think we can?t deal with this, if the default for observers would be >>> >> async. So I think there is no way to specify async as default without >>> >> loosing backward compatibility. >>> >> Any other thoughts? >>> >> >>> >> Cheers, >>> >> Arne >>> >> >>> >> >>> >> Am 18.03.15 08:48 schrieb "Antoine Sabot-Durand" unter >>> >> >: >>> >> >>> >>> Hi all, >>> >>> >>> >>> Yesterday we had another meeting to try to find a better solution than >>> >>> explicitly activating async event on observer, without no success. I >>> >>> understand that we should go on on this feature so what I suggest is to >>> >>> have a meeting (an hangout) with people that want to try to find a >>> >>>better >>> >>> solution. If we find something we?ll do a last proposal, and in all >>> >>>case >>> >>> we?ll adopt the woking solution next week for this point. People >>> >>> interested with this please manifest yourself. >>> >>> >>> >>> If we have to go with opt-in (have to explicitly declare an observer >>> >>> supporting async event) we also have to validate the decision to use a >>> >>> member in @Observes (as it was decided before) or go back on that as >>> >>> mMark keep asking by introducing a new annotation to add on the >>> >>>observer >>> >>> (@Async or something similar). As I said when we discussed this point, >>> >>>I >>> >>> prefer the member in @Observes but we may have overlooked issues linked >>> >>> to backward compatibility. >>> >>> A third solution might be to introduce an @ObserveAsync to declare an >>> >>> asynchronous capable observer? >>> >>> >>> >>> I?m waiting for active feedback from you to find the best solution >>> >>>taking >>> >>> ALL aspects (not only the technicals one) into account. >>> >>> >>> >>> Thanks, >>> >>> >>> >>> Antoine >>> >> >>> > >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/b923208f/attachment.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/20150318/b923208f/attachment.bin From rmannibucau at gmail.com Wed Mar 18 06:05:01 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 18 Mar 2015 11:05:01 +0100 Subject: [cdi-dev] On @Observes for async events In-Reply-To: <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> Message-ID: 2015-03-18 11:03 GMT+01:00 Antoine Sabot-Durand : > > Le 18 mars 2015 ? 10:53, Romain Manni-Bucau a > ?crit : > > > 2015-03-18 10:33 GMT+01:00 Antoine Sabot-Durand > : > >> >> Le 18 mars 2015 ? 09:58, Romain Manni-Bucau a >> ?crit : >> >> >> 2015-03-18 9:55 GMT+01:00 Antoine Sabot-Durand >> : >> >>> >>> Le 18 mars 2015 ? 09:42, Romain Manni-Bucau a >>> ?crit : >>> >>> Hi guys, >>> >>> think Mark is right and a new API (as fireAsync) would be better for >>> users for: >>> - understanding >>> - compatibility (think to custom extensions using this flag) >>> >>> >>> My point here is to avoid making CDI the EJB next by introducing @Async >>> or @Asynchronous annotation in the spec. This kind of annotation should be >>> shared by other specs and would have a better fit in concurrency utilities >>> or commons annotations spec. >>> >>> >> +1 >> >> >>> that said if we have @Async methods I think async observers are really >>> useless, isn't it? >>> >>> >>> @Async is rather useless IMO when you see how easy it is do async >>> operation with Java 8. On the other hand Async observers are a at a higher >>> level since they are called thru the Container and that the fire point must >>> know what?s going on at the other side. >>> >>> >> don't get it, observer can use j8 then to do its stuff asynchronously so >> maybe the feature if finally useless assuming you run on j8. >> >> >> And how do you make your fire point know that one of its observer will be >> asynchronous ? How do you manage event ordering (as we plan to support it >> for async event as well). I think we shouldn?t see the event bus as a >> standard method call but something more featured (think about parameter >> injection in observer methods or transactional behavior) >> >> > then this is not asynchronism and just an observer queue which is > something different IMO. > > > From user pov it?s async : "I fire an event and get the control back right > away". The impl will make an observer queue in an other thread, but the > user exp is totally different than classic fire(). > > this is discussable since it is not for 2 observers. If you use async it can be - often - cause of a long processing, if you have 2 long computing methods then you sequentiallize it which breaks the reason why you wanted async, no? > > >> >> That said saying a method is async is still more elegant than firing it >> in a pool you don't control. >> >> >> fireAsync will have a signature allowing you to pass your own Executor to >> give you better control on thread pool >> >> > a default one should be bound to the bm - main case IMO. having an app > executor is not a very nice solution in term of API. > > > Yes it was already discussed, there will be 2 signatures for fireAsync(). > > > > >> >>> >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog >>> | Github >>> | LinkedIn >>> | Tomitriber >>> >>> >>> 2015-03-18 9:30 GMT+01:00 Arne Limburg : >>> >>>> Hi Antoine, >>>> >>>> The third bullet point in 10.5.1 of the CDI 1.1 spec states that the >>>> observer method must be called in the same transaction context as the >>>> event.fire(...) if it is no transactional observer (that is >>>> TransactionPhase.IN_PROGRESS). >>>> If the default behavior would be async, we would have to move the >>>> transaction context to another thread. To my best knowledge this would >>>> be >>>> the only situation in EE where this is the case. >>>> >>>> Cheers, >>>> Arne >>>> >>>> Am 18.03.15 09:21 schrieb "Antoine Sabot-Durand" unter >>>> : >>>> >>>> >Hi Arne, >>>> > >>>> >Sorry can you explain why? This value allows observer to be called >>>> inside >>>> >or outside a transaction. What will be the compatibility issue? >>>> > >>>> >Antoine >>>> > >>>> > >>>> >> Le 18 mars 2015 ? 09:05, Arne Limburg >>>> a >>>> >>?crit : >>>> >> >>>> >> Hi to all, >>>> >> >>>> >> I think the biggest issue with backward compatibility is, that the >>>> >>current >>>> >> @Observes annotation by default has TransactionPhase.IN_PROGRESS. >>>> >> I think we can?t deal with this, if the default for observers would >>>> be >>>> >> async. So I think there is no way to specify async as default without >>>> >> loosing backward compatibility. >>>> >> Any other thoughts? >>>> >> >>>> >> Cheers, >>>> >> Arne >>>> >> >>>> >> >>>> >> Am 18.03.15 08:48 schrieb "Antoine Sabot-Durand" unter >>>> >> : >>>> >> >>>> >>> Hi all, >>>> >>> >>>> >>> Yesterday we had another meeting to try to find a better solution >>>> than >>>> >>> explicitly activating async event on observer, without no success. I >>>> >>> understand that we should go on on this feature so what I suggest >>>> is to >>>> >>> have a meeting (an hangout) with people that want to try to find a >>>> >>>better >>>> >>> solution. If we find something we?ll do a last proposal, and in all >>>> >>>case >>>> >>> we?ll adopt the woking solution next week for this point. People >>>> >>> interested with this please manifest yourself. >>>> >>> >>>> >>> If we have to go with opt-in (have to explicitly declare an observer >>>> >>> supporting async event) we also have to validate the decision to >>>> use a >>>> >>> member in @Observes (as it was decided before) or go back on that as >>>> >>> mMark keep asking by introducing a new annotation to add on the >>>> >>>observer >>>> >>> (@Async or something similar). As I said when we discussed this >>>> point, >>>> >>>I >>>> >>> prefer the member in @Observes but we may have overlooked issues >>>> linked >>>> >>> to backward compatibility. >>>> >>> A third solution might be to introduce an @ObserveAsync to declare >>>> an >>>> >>> asynchronous capable observer? >>>> >>> >>>> >>> I?m waiting for active feedback from you to find the best solution >>>> >>>taking >>>> >>> ALL aspects (not only the technicals one) into account. >>>> >>> >>>> >>> Thanks, >>>> >>> >>>> >>> Antoine >>>> >> >>>> > >>>> >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider licenses the >>>> code under the Apache License, Version 2 ( >>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>>> provided on this list, the provider waives all patent and other >>>> intellectual property rights inherent in such information. >>>> >>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/1ea907cf/attachment-0001.html From antoine at sabot-durand.net Wed Mar 18 06:06:00 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 18 Mar 2015 11:06:00 +0100 Subject: [cdi-dev] Async event material Message-ID: <2B342334-6413-4217-87B5-9B5E81B40583@sabot-durand.net> Hi all, For the info there are 2 docs (https://docs.google.com/document/d/1wJFvThqS8SrmKiuWsWgWH252k58PHGvM_iKePje4sxQ/edit?usp=sharing and https://docs.google.com/document/d/1Tm_fZWS6569YqCH9lGxuqBGzS9gfupic-vv1dyKCUxk/edit?usp=sharing ) and a lot meeting transcript on the subject (http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/index.html ). I know it?s not fun to read all these (some info is outdated) but it?s a nice way to understand all the point we already discussed and avoid going back on them without a good reason. Yes, we spent a looooot of time on this async stuff but remember it?s the number 1 requested feature by our end user so we should really avoid f***ing it up. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/282204d8/attachment.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/20150318/282204d8/attachment.bin From antoine at sabot-durand.net Wed Mar 18 06:11:30 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 18 Mar 2015 11:11:30 +0100 Subject: [cdi-dev] On @Observes for async events In-Reply-To: References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> Message-ID: <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> Support of ordering in async event was last discussed yesterday in this thread (http://cdi-development-mailing-list.1064426.n5.nabble.com/Update-on-Async-event-doc-td5711176.html ) I tend to agree with Jozef. It?s more consistent for user to allow ordering in async event as in sync. Antoine > Le 18 mars 2015 ? 11:05, Romain Manni-Bucau a ?crit : > > > 2015-03-18 11:03 GMT+01:00 Antoine Sabot-Durand >: > >> Le 18 mars 2015 ? 10:53, Romain Manni-Bucau > a ?crit : >> >> >> 2015-03-18 10:33 GMT+01:00 Antoine Sabot-Durand >: >> >>> Le 18 mars 2015 ? 09:58, Romain Manni-Bucau > a ?crit : >>> >>> >>> 2015-03-18 9:55 GMT+01:00 Antoine Sabot-Durand >: >>>> >>>> Le 18 mars 2015 ? 09:42, Romain Manni-Bucau > a ?crit : >>>> >>>> Hi guys, >>>> >>>> think Mark is right and a new API (as fireAsync) would be better for users for: >>>> - understanding >>>> - compatibility (think to custom extensions using this flag) >>> >>> My point here is to avoid making CDI the EJB next by introducing @Async or @Asynchronous annotation in the spec. This kind of annotation should be shared by other specs and would have a better fit in concurrency utilities or commons annotations spec. >>> >>> >>> +1 >>> >>>> that said if we have @Async methods I think async observers are really useless, isn't it? >>> >>> @Async is rather useless IMO when you see how easy it is do async operation with Java 8. On the other hand Async observers are a at a higher level since they are called thru the Container and that the fire point must know what?s going on at the other side. >>> >>> >>> don't get it, observer can use j8 then to do its stuff asynchronously so maybe the feature if finally useless assuming you run on j8. >> >> And how do you make your fire point know that one of its observer will be asynchronous ? How do you manage event ordering (as we plan to support it for async event as well). I think we shouldn?t see the event bus as a standard method call but something more featured (think about parameter injection in observer methods or transactional behavior) >> >> >> then this is not asynchronism and just an observer queue which is something different IMO. > > From user pov it?s async : "I fire an event and get the control back right away". The impl will make an observer queue in an other thread, but the user exp is totally different than classic fire(). > > > this is discussable since it is not for 2 observers. If you use async it can be - often - cause of a long processing, if you have 2 long computing methods then you sequentiallize it which breaks the reason why you wanted async, no? >> >>> >>> That said saying a method is async is still more elegant than firing it in a pool you don't control. >> >> fireAsync will have a signature allowing you to pass your own Executor to give you better control on thread pool >> >> >> a default one should be bound to the bm - main case IMO. having an app executor is not a very nice solution in term of API. > > Yes it was already discussed, there will be 2 signatures for fireAsync(). > > > >>> >>>> >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>> 2015-03-18 9:30 GMT+01:00 Arne Limburg >: >>>> Hi Antoine, >>>> >>>> The third bullet point in 10.5.1 of the CDI 1.1 spec states that the >>>> observer method must be called in the same transaction context as the >>>> event.fire(...) if it is no transactional observer (that is >>>> TransactionPhase.IN_PROGRESS). >>>> If the default behavior would be async, we would have to move the >>>> transaction context to another thread. To my best knowledge this would be >>>> the only situation in EE where this is the case. >>>> >>>> Cheers, >>>> Arne >>>> >>>> Am 18.03.15 09:21 schrieb "Antoine Sabot-Durand" unter >>>> >: >>>> >>>> >Hi Arne, >>>> > >>>> >Sorry can you explain why? This value allows observer to be called inside >>>> >or outside a transaction. What will be the compatibility issue? >>>> > >>>> >Antoine >>>> > >>>> > >>>> >> Le 18 mars 2015 ? 09:05, Arne Limburg > a >>>> >>?crit : >>>> >> >>>> >> Hi to all, >>>> >> >>>> >> I think the biggest issue with backward compatibility is, that the >>>> >>current >>>> >> @Observes annotation by default has TransactionPhase.IN_PROGRESS. >>>> >> I think we can?t deal with this, if the default for observers would be >>>> >> async. So I think there is no way to specify async as default without >>>> >> loosing backward compatibility. >>>> >> Any other thoughts? >>>> >> >>>> >> Cheers, >>>> >> Arne >>>> >> >>>> >> >>>> >> Am 18.03.15 08:48 schrieb "Antoine Sabot-Durand" unter >>>> >> >: >>>> >> >>>> >>> Hi all, >>>> >>> >>>> >>> Yesterday we had another meeting to try to find a better solution than >>>> >>> explicitly activating async event on observer, without no success. I >>>> >>> understand that we should go on on this feature so what I suggest is to >>>> >>> have a meeting (an hangout) with people that want to try to find a >>>> >>>better >>>> >>> solution. If we find something we?ll do a last proposal, and in all >>>> >>>case >>>> >>> we?ll adopt the woking solution next week for this point. People >>>> >>> interested with this please manifest yourself. >>>> >>> >>>> >>> If we have to go with opt-in (have to explicitly declare an observer >>>> >>> supporting async event) we also have to validate the decision to use a >>>> >>> member in @Observes (as it was decided before) or go back on that as >>>> >>> mMark keep asking by introducing a new annotation to add on the >>>> >>>observer >>>> >>> (@Async or something similar). As I said when we discussed this point, >>>> >>>I >>>> >>> prefer the member in @Observes but we may have overlooked issues linked >>>> >>> to backward compatibility. >>>> >>> A third solution might be to introduce an @ObserveAsync to declare an >>>> >>> asynchronous capable observer? >>>> >>> >>>> >>> I?m waiting for active feedback from you to find the best solution >>>> >>>taking >>>> >>> ALL aspects (not only the technicals one) into account. >>>> >>> >>>> >>> Thanks, >>>> >>> >>>> >>> Antoine >>>> >> >>>> > >>>> >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/2a2189be/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/20150318/2a2189be/attachment-0001.bin From rmannibucau at gmail.com Wed Mar 18 06:16:33 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 18 Mar 2015 11:16:33 +0100 Subject: [cdi-dev] On @Observes for async events In-Reply-To: <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> Message-ID: Think it is highly wrong, if you need priorities between tasks in async world you use completion hooks, sequentializing them arbitrarily just makes it not async anymore (+ think to the case you dont really have priorities you are just breaking the whole concept). So a deifnitionexception is the thing to throw when you have @Async+ at Priority IMO. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-03-18 11:11 GMT+01:00 Antoine Sabot-Durand : > Support of ordering in async event was last discussed yesterday in this > thread ( > http://cdi-development-mailing-list.1064426.n5.nabble.com/Update-on-Async-event-doc-td5711176.html > ) > I tend to agree with Jozef. It?s more consistent for user to allow > ordering in async event as in sync. > > Antoine > > > Le 18 mars 2015 ? 11:05, Romain Manni-Bucau a > ?crit : > > > 2015-03-18 11:03 GMT+01:00 Antoine Sabot-Durand > : > >> >> Le 18 mars 2015 ? 10:53, Romain Manni-Bucau a >> ?crit : >> >> >> 2015-03-18 10:33 GMT+01:00 Antoine Sabot-Durand > >: >> >>> >>> Le 18 mars 2015 ? 09:58, Romain Manni-Bucau a >>> ?crit : >>> >>> >>> 2015-03-18 9:55 GMT+01:00 Antoine Sabot-Durand >> >: >>> >>>> >>>> Le 18 mars 2015 ? 09:42, Romain Manni-Bucau a >>>> ?crit : >>>> >>>> Hi guys, >>>> >>>> think Mark is right and a new API (as fireAsync) would be better for >>>> users for: >>>> - understanding >>>> - compatibility (think to custom extensions using this flag) >>>> >>>> >>>> My point here is to avoid making CDI the EJB next by introducing @Async >>>> or @Asynchronous annotation in the spec. This kind of annotation should be >>>> shared by other specs and would have a better fit in concurrency utilities >>>> or commons annotations spec. >>>> >>>> >>> +1 >>> >>> >>>> that said if we have @Async methods I think async observers are really >>>> useless, isn't it? >>>> >>>> >>>> @Async is rather useless IMO when you see how easy it is do async >>>> operation with Java 8. On the other hand Async observers are a at a higher >>>> level since they are called thru the Container and that the fire point must >>>> know what?s going on at the other side. >>>> >>>> >>> don't get it, observer can use j8 then to do its stuff asynchronously so >>> maybe the feature if finally useless assuming you run on j8. >>> >>> >>> And how do you make your fire point know that one of its observer will >>> be asynchronous ? How do you manage event ordering (as we plan to support >>> it for async event as well). I think we shouldn?t see the event bus as a >>> standard method call but something more featured (think about parameter >>> injection in observer methods or transactional behavior) >>> >>> >> then this is not asynchronism and just an observer queue which is >> something different IMO. >> >> >> From user pov it?s async : "I fire an event and get the control back >> right away". The impl will make an observer queue in an other thread, but >> the user exp is totally different than classic fire(). >> >> > this is discussable since it is not for 2 observers. If you use async it > can be - often - cause of a long processing, if you have 2 long computing > methods then you sequentiallize it which breaks the reason why you wanted > async, no? > >> >> >>> >>> That said saying a method is async is still more elegant than firing it >>> in a pool you don't control. >>> >>> >>> fireAsync will have a signature allowing you to pass your own Executor >>> to give you better control on thread pool >>> >>> >> a default one should be bound to the bm - main case IMO. having an app >> executor is not a very nice solution in term of API. >> >> >> Yes it was already discussed, there will be 2 signatures for fireAsync(). >> >> >> >> >>> >>>> >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau | Blog >>>> | Github >>>> | LinkedIn >>>> | Tomitriber >>>> >>>> >>>> 2015-03-18 9:30 GMT+01:00 Arne Limburg : >>>> >>>>> Hi Antoine, >>>>> >>>>> The third bullet point in 10.5.1 of the CDI 1.1 spec states that the >>>>> observer method must be called in the same transaction context as the >>>>> event.fire(...) if it is no transactional observer (that is >>>>> TransactionPhase.IN_PROGRESS). >>>>> If the default behavior would be async, we would have to move the >>>>> transaction context to another thread. To my best knowledge this would >>>>> be >>>>> the only situation in EE where this is the case. >>>>> >>>>> Cheers, >>>>> Arne >>>>> >>>>> Am 18.03.15 09:21 schrieb "Antoine Sabot-Durand" unter >>>>> : >>>>> >>>>> >Hi Arne, >>>>> > >>>>> >Sorry can you explain why? This value allows observer to be called >>>>> inside >>>>> >or outside a transaction. What will be the compatibility issue? >>>>> > >>>>> >Antoine >>>>> > >>>>> > >>>>> >> Le 18 mars 2015 ? 09:05, Arne Limburg < >>>>> arne.limburg at openknowledge.de> a >>>>> >>?crit : >>>>> >> >>>>> >> Hi to all, >>>>> >> >>>>> >> I think the biggest issue with backward compatibility is, that the >>>>> >>current >>>>> >> @Observes annotation by default has TransactionPhase.IN_PROGRESS. >>>>> >> I think we can?t deal with this, if the default for observers would >>>>> be >>>>> >> async. So I think there is no way to specify async as default >>>>> without >>>>> >> loosing backward compatibility. >>>>> >> Any other thoughts? >>>>> >> >>>>> >> Cheers, >>>>> >> Arne >>>>> >> >>>>> >> >>>>> >> Am 18.03.15 08:48 schrieb "Antoine Sabot-Durand" unter >>>>> >> : >>>>> >> >>>>> >>> Hi all, >>>>> >>> >>>>> >>> Yesterday we had another meeting to try to find a better solution >>>>> than >>>>> >>> explicitly activating async event on observer, without no success. >>>>> I >>>>> >>> understand that we should go on on this feature so what I suggest >>>>> is to >>>>> >>> have a meeting (an hangout) with people that want to try to find a >>>>> >>>better >>>>> >>> solution. If we find something we?ll do a last proposal, and in all >>>>> >>>case >>>>> >>> we?ll adopt the woking solution next week for this point. People >>>>> >>> interested with this please manifest yourself. >>>>> >>> >>>>> >>> If we have to go with opt-in (have to explicitly declare an >>>>> observer >>>>> >>> supporting async event) we also have to validate the decision to >>>>> use a >>>>> >>> member in @Observes (as it was decided before) or go back on that >>>>> as >>>>> >>> mMark keep asking by introducing a new annotation to add on the >>>>> >>>observer >>>>> >>> (@Async or something similar). As I said when we discussed this >>>>> point, >>>>> >>>I >>>>> >>> prefer the member in @Observes but we may have overlooked issues >>>>> linked >>>>> >>> to backward compatibility. >>>>> >>> A third solution might be to introduce an @ObserveAsync to declare >>>>> an >>>>> >>> asynchronous capable observer? >>>>> >>> >>>>> >>> I?m waiting for active feedback from you to find the best solution >>>>> >>>taking >>>>> >>> ALL aspects (not only the technicals one) into account. >>>>> >>> >>>>> >>> Thanks, >>>>> >>> >>>>> >>> Antoine >>>>> >> >>>>> > >>>>> >>>>> >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>> Note that for all code provided on this list, the provider licenses >>>>> the code under the Apache License, Version 2 ( >>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>>>> provided on this list, the provider waives all patent and other >>>>> intellectual property rights inherent in such information. >>>>> >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/78a96a22/attachment.html From jharting at redhat.com Wed Mar 18 08:15:39 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 18 Mar 2015 13:15:39 +0100 Subject: [cdi-dev] On @Observes for async events In-Reply-To: References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> Message-ID: <55096C6B.9080700@redhat.com> On 03/18/2015 11:16 AM, Romain Manni-Bucau wrote: > sequentializing them arbitrarily just makes it not async anymore the event firing thread won't wait for event delivery so it is still async > (+ think to the case you dont really have priorities you are just > breaking the whole concept). If you do not have priorities (or they are the same) then it is most likely fine to notify the observers in parallel. If you however do have priorities then it makes sense IMO to take them into account. Doing otherwise just complicates the entire concept by adding an artificial constraint. From rmannibucau at gmail.com Wed Mar 18 08:28:44 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 18 Mar 2015 13:28:44 +0100 Subject: [cdi-dev] On @Observes for async events In-Reply-To: <55096C6B.9080700@redhat.com> References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> <55096C6B.9080700@redhat.com> Message-ID: 2015-03-18 13:15 GMT+01:00 Jozef Hartinger : > > On 03/18/2015 11:16 AM, Romain Manni-Bucau wrote: > >> sequentializing them arbitrarily just makes it not async anymore >> > the event firing thread won't wait for event delivery so it is still async well doesn't change the fact you break original async need/wish doing it. > > (+ think to the case you dont really have priorities you are just >> breaking the whole concept). >> > If you do not have priorities (or they are the same) then it is most > likely fine to notify the observers in parallel. If you however do have > priorities then it makes sense IMO to take them into account. Doing > otherwise just complicates the entire concept by adding an artificial > constraint. > point is you are introducing a model concept which is not aligned on the common model + doesn't even match correctly the async needs (what about onFailure() and onTimeout() which are mandatory when doing async) I tend to join Mark saying we should just do the minimum instead of wanting to do to much and providing something highly broken we'll need to fix in next version with more broken patterns. What's the need is the real question, not what would be cool to implement. Don't forget an async spec smells more and more strong with real async semantic and solutions so I guess the less we put in CDI now better it is. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/71cf4fa3/attachment.html From jharting at redhat.com Wed Mar 18 08:35:29 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 18 Mar 2015 13:35:29 +0100 Subject: [cdi-dev] On @Observes for async events In-Reply-To: References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> <55096C6B.9080700@redhat.com> Message-ID: <55097111.1090402@redhat.com> On 03/18/2015 01:28 PM, Romain Manni-Bucau wrote: > > > 2015-03-18 13:15 GMT+01:00 Jozef Hartinger >: > > > On 03/18/2015 11:16 AM, Romain Manni-Bucau wrote: > > sequentializing them arbitrarily just makes it not async anymore > > the event firing thread won't wait for event delivery so it is > still async > > > well doesn't change the fact you break original async need/wish doing it. break what? > > > (+ think to the case you dont really have priorities you are > just breaking the whole concept). > > If you do not have priorities (or they are the same) then it is > most likely fine to notify the observers in parallel. If you > however do have priorities then it makes sense IMO to take them > into account. Doing otherwise just complicates the entire concept > by adding an artificial constraint. > > > > point is you are introducing a model concept which is not aligned on > the common model + doesn't even match correctly the async needs (what > about onFailure() and onTimeout() which are mandatory when doing async) what common model? > > I tend to join Mark saying we should just do the minimum instead of > wanting to do to much and providing something highly broken we'll need > to fix in next version with more broken patterns. What's the need is > the real question, not what would be cool to implement. > > Don't forget an async spec smells more and more strong with real async > semantic and solutions so I guess the less we put in CDI now better it is. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/577cea24/attachment.html From rmannibucau at gmail.com Wed Mar 18 08:46:55 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 18 Mar 2015 13:46:55 +0100 Subject: [cdi-dev] On @Observes for async events In-Reply-To: <55097111.1090402@redhat.com> References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> <55096C6B.9080700@redhat.com> <55097111.1090402@redhat.com> Message-ID: 2015-03-18 13:35 GMT+01:00 Jozef Hartinger : > > On 03/18/2015 01:28 PM, Romain Manni-Bucau wrote: > > > > 2015-03-18 13:15 GMT+01:00 Jozef Hartinger : > >> >> On 03/18/2015 11:16 AM, Romain Manni-Bucau wrote: >> >>> sequentializing them arbitrarily just makes it not async anymore >>> >> the event firing thread won't wait for event delivery so it is still >> async > > > well doesn't change the fact you break original async need/wish doing it. > > break what? > > don't wait behavior, own thread model by call which is what async means most of the time > > >> >> (+ think to the case you dont really have priorities you are just >>> breaking the whole concept). >>> >> If you do not have priorities (or they are the same) then it is most >> likely fine to notify the observers in parallel. If you however do have >> priorities then it makes sense IMO to take them into account. Doing >> otherwise just complicates the entire concept by adding an artificial >> constraint. >> > > > point is you are introducing a model concept which is not aligned on the > common model + doesn't even match correctly the async needs (what about > onFailure() and onTimeout() which are mandatory when doing async) > > what common model? > > > callbacks one which is the only one making async usable and prod compatible > I tend to join Mark saying we should just do the minimum instead of > wanting to do to much and providing something highly broken we'll need to > fix in next version with more broken patterns. What's the need is the real > question, not what would be cool to implement. > > Don't forget an async spec smells more and more strong with real async > semantic and solutions so I guess the less we put in CDI now better it is. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/11a02ce1/attachment.html From jharting at redhat.com Wed Mar 18 08:55:59 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 18 Mar 2015 13:55:59 +0100 Subject: [cdi-dev] On @Observes for async events In-Reply-To: References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> <55096C6B.9080700@redhat.com> <55097111.1090402@redhat.com> Message-ID: <550975DF.2080505@redhat.com> On 03/18/2015 01:46 PM, Romain Manni-Bucau wrote: > > 2015-03-18 13:35 GMT+01:00 Jozef Hartinger >: > > > On 03/18/2015 01:28 PM, Romain Manni-Bucau wrote: >> >> >> 2015-03-18 13:15 GMT+01:00 Jozef Hartinger > >: >> >> >> On 03/18/2015 11:16 AM, Romain Manni-Bucau wrote: >> >> sequentializing them arbitrarily just makes it not async >> anymore >> >> the event firing thread won't wait for event delivery so it >> is still async >> >> >> well doesn't change the fact you break original async need/wish >> doing it. > break what? > > don't wait behavior, own thread model by call which is what async > means most of the time Well, the thread firing an event won't wait for the observers to complete so I cannot see how it breaks your "original async need/wish". Or do you associate "async" with splitting the work into as many parallel threads as possible? If so then we have a mismatch in terminology. > >> >> (+ think to the case you dont really have priorities you >> are just breaking the whole concept). >> >> If you do not have priorities (or they are the same) then it >> is most likely fine to notify the observers in parallel. If >> you however do have priorities then it makes sense IMO to >> take them into account. Doing otherwise just complicates the >> entire concept by adding an artificial constraint. >> >> >> >> point is you are introducing a model concept which is not aligned >> on the common model + doesn't even match correctly the async >> needs (what about onFailure() and onTimeout() which are mandatory >> when doing async) > what common model? >> > callbacks one which is the only one making async usable and prod > compatible Which part is not aligned? In the current proposal you get a callback when all observers complete or an exception occurs. In what order the observers are called does not change anything about that. > >> I tend to join Mark saying we should just do the minimum instead >> of wanting to do to much and providing something highly broken >> we'll need to fix in next version with more broken patterns. >> What's the need is the real question, not what would be cool to >> implement. >> >> Don't forget an async spec smells more and more strong with real >> async semantic and solutions so I guess the less we put in CDI >> now better it is. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/5cb28c06/attachment-0001.html From rmannibucau at gmail.com Wed Mar 18 09:04:32 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 18 Mar 2015 14:04:32 +0100 Subject: [cdi-dev] On @Observes for async events In-Reply-To: <550975DF.2080505@redhat.com> References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> <55096C6B.9080700@redhat.com> <55097111.1090402@redhat.com> <550975DF.2080505@redhat.com> Message-ID: 2015-03-18 13:55 GMT+01:00 Jozef Hartinger : > > On 03/18/2015 01:46 PM, Romain Manni-Bucau wrote: > > > 2015-03-18 13:35 GMT+01:00 Jozef Hartinger : > >> >> On 03/18/2015 01:28 PM, Romain Manni-Bucau wrote: >> >> >> >> 2015-03-18 13:15 GMT+01:00 Jozef Hartinger : >> >>> >>> On 03/18/2015 11:16 AM, Romain Manni-Bucau wrote: >>> >>>> sequentializing them arbitrarily just makes it not async anymore >>>> >>> the event firing thread won't wait for event delivery so it is still >>> async >> >> >> well doesn't change the fact you break original async need/wish doing >> it. >> >> break what? >> >> don't wait behavior, own thread model by call which is what async > means most of the time > > Well, the thread firing an event won't wait for the observers to complete > so I cannot see how it breaks your "original async need/wish". Or do you > associate "async" with splitting the work into as many parallel threads as > possible? If so then we have a mismatch in terminology. > > well about terminology maybe but I more think about expected behavior as a user. Think we now both get what we each of us put behind async and question is what's the most common case. Depending where you put async (fireAsync vs @Async/@ObserveAsync) it is not the same thing at all. > > >> >> >>> >>> (+ think to the case you dont really have priorities you are just >>>> breaking the whole concept). >>>> >>> If you do not have priorities (or they are the same) then it is most >>> likely fine to notify the observers in parallel. If you however do have >>> priorities then it makes sense IMO to take them into account. Doing >>> otherwise just complicates the entire concept by adding an artificial >>> constraint. >>> >> >> >> point is you are introducing a model concept which is not aligned on >> the common model + doesn't even match correctly the async needs (what about >> onFailure() and onTimeout() which are mandatory when doing async) >> >> what common model? >> >> >> callbacks one which is the only one making async usable and prod > compatible > > Which part is not aligned? In the current proposal you get a callback when > all observers complete or an exception occurs. In what order the observers > are called does not change anything about that. > you don't control the timeout and exception from the callback. I mean in the observer chain which is what is needed most of the time (it helps me to think to it with a javascript example but maybe my personal feeling). > > I tend to join Mark saying we should just do the minimum instead of >> wanting to do to much and providing something highly broken we'll need to >> fix in next version with more broken patterns. What's the need is the real >> question, not what would be cool to implement. >> >> Don't forget an async spec smells more and more strong with real async >> semantic and solutions so I guess the less we put in CDI now better it is. >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/feda5cbb/attachment.html From pmuir at redhat.com Wed Mar 18 11:14:53 2015 From: pmuir at redhat.com (Pete Muir) Date: Wed, 18 Mar 2015 15:14:53 +0000 Subject: [cdi-dev] On @Observes for async events In-Reply-To: <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> Message-ID: I think I have misunderstood the async model that is being proposed. We are proposing that all the observers of an event fired asynchronously are all run on a single thread? (Not the thread that fires the event, another thread, but the same thread for each observer). This would be a somewhat odd limitation in my mind. It?s certainly *not* something that is semantically intuitive if you have something like @Observes @Asynchronously on event observers, which definitely implies the event observation is asynchronous, not the event firing. I would definitely prefer an asynchronous observation model, which I can?t see as being remotely compatible with observer ordering. The classic approach of using callbacks to identify when a method is done is inherently more powerful, and better understood. Perhaps I?ve missed this, but what are the use cases for wanting to specify that the observation is done async on the observer? And how does this relate to the event firing methods ability to get a callback? I suspect you would need to retrofit the entire firing system to always return a callback if you wanted to allow the observer to control whether it was async or not. > On 18 Mar 2015, at 10:11, Antoine Sabot-Durand wrote: > > Support of ordering in async event was last discussed yesterday in this thread (http://cdi-development-mailing-list.1064426.n5.nabble.com/Update-on-Async-event-doc-td5711176.html ) > I tend to agree with Jozef. It?s more consistent for user to allow ordering in async event as in sync. > > Antoine > > >> Le 18 mars 2015 ? 11:05, Romain Manni-Bucau > a ?crit : >> >> >> 2015-03-18 11:03 GMT+01:00 Antoine Sabot-Durand >: >> >>> Le 18 mars 2015 ? 10:53, Romain Manni-Bucau > a ?crit : >>> >>> >>> 2015-03-18 10:33 GMT+01:00 Antoine Sabot-Durand >: >>> >>>> Le 18 mars 2015 ? 09:58, Romain Manni-Bucau > a ?crit : >>>> >>>> >>>> 2015-03-18 9:55 GMT+01:00 Antoine Sabot-Durand >: >>>>> >>>>> Le 18 mars 2015 ? 09:42, Romain Manni-Bucau > a ?crit : >>>>> >>>>> Hi guys, >>>>> >>>>> think Mark is right and a new API (as fireAsync) would be better for users for: >>>>> - understanding >>>>> - compatibility (think to custom extensions using this flag) >>>> >>>> My point here is to avoid making CDI the EJB next by introducing @Async or @Asynchronous annotation in the spec. This kind of annotation should be shared by other specs and would have a better fit in concurrency utilities or commons annotations spec. >>>> >>>> >>>> +1 >>>> >>>>> that said if we have @Async methods I think async observers are really useless, isn't it? >>>> >>>> @Async is rather useless IMO when you see how easy it is do async operation with Java 8. On the other hand Async observers are a at a higher level since they are called thru the Container and that the fire point must know what?s going on at the other side. >>>> >>>> >>>> don't get it, observer can use j8 then to do its stuff asynchronously so maybe the feature if finally useless assuming you run on j8. >>> >>> And how do you make your fire point know that one of its observer will be asynchronous ? How do you manage event ordering (as we plan to support it for async event as well). I think we shouldn?t see the event bus as a standard method call but something more featured (think about parameter injection in observer methods or transactional behavior) >>> >>> >>> then this is not asynchronism and just an observer queue which is something different IMO. >> >> From user pov it?s async : "I fire an event and get the control back right away". The impl will make an observer queue in an other thread, but the user exp is totally different than classic fire(). >> >> >> this is discussable since it is not for 2 observers. If you use async it can be - often - cause of a long processing, if you have 2 long computing methods then you sequentiallize it which breaks the reason why you wanted async, no? >>> >>>> >>>> That said saying a method is async is still more elegant than firing it in a pool you don't control. >>> >>> fireAsync will have a signature allowing you to pass your own Executor to give you better control on thread pool >>> >>> >>> a default one should be bound to the bm - main case IMO. having an app executor is not a very nice solution in term of API. >> >> Yes it was already discussed, there will be 2 signatures for fireAsync(). >> >> >> >>>> >>>>> >>>>> >>>>> >>>>> Romain Manni-Bucau >>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>> 2015-03-18 9:30 GMT+01:00 Arne Limburg >: >>>>> Hi Antoine, >>>>> >>>>> The third bullet point in 10.5.1 of the CDI 1.1 spec states that the >>>>> observer method must be called in the same transaction context as the >>>>> event.fire(...) if it is no transactional observer (that is >>>>> TransactionPhase.IN_PROGRESS). >>>>> If the default behavior would be async, we would have to move the >>>>> transaction context to another thread. To my best knowledge this would be >>>>> the only situation in EE where this is the case. >>>>> >>>>> Cheers, >>>>> Arne >>>>> >>>>> Am 18.03.15 09:21 schrieb "Antoine Sabot-Durand" unter >>>>> >: >>>>> >>>>> >Hi Arne, >>>>> > >>>>> >Sorry can you explain why? This value allows observer to be called inside >>>>> >or outside a transaction. What will be the compatibility issue? >>>>> > >>>>> >Antoine >>>>> > >>>>> > >>>>> >> Le 18 mars 2015 ? 09:05, Arne Limburg > a >>>>> >>?crit : >>>>> >> >>>>> >> Hi to all, >>>>> >> >>>>> >> I think the biggest issue with backward compatibility is, that the >>>>> >>current >>>>> >> @Observes annotation by default has TransactionPhase.IN_PROGRESS. >>>>> >> I think we can?t deal with this, if the default for observers would be >>>>> >> async. So I think there is no way to specify async as default without >>>>> >> loosing backward compatibility. >>>>> >> Any other thoughts? >>>>> >> >>>>> >> Cheers, >>>>> >> Arne >>>>> >> >>>>> >> >>>>> >> Am 18.03.15 08:48 schrieb "Antoine Sabot-Durand" unter >>>>> >> >: >>>>> >> >>>>> >>> Hi all, >>>>> >>> >>>>> >>> Yesterday we had another meeting to try to find a better solution than >>>>> >>> explicitly activating async event on observer, without no success. I >>>>> >>> understand that we should go on on this feature so what I suggest is to >>>>> >>> have a meeting (an hangout) with people that want to try to find a >>>>> >>>better >>>>> >>> solution. If we find something we?ll do a last proposal, and in all >>>>> >>>case >>>>> >>> we?ll adopt the woking solution next week for this point. People >>>>> >>> interested with this please manifest yourself. >>>>> >>> >>>>> >>> If we have to go with opt-in (have to explicitly declare an observer >>>>> >>> supporting async event) we also have to validate the decision to use a >>>>> >>> member in @Observes (as it was decided before) or go back on that as >>>>> >>> mMark keep asking by introducing a new annotation to add on the >>>>> >>>observer >>>>> >>> (@Async or something similar). As I said when we discussed this point, >>>>> >>>I >>>>> >>> prefer the member in @Observes but we may have overlooked issues linked >>>>> >>> to backward compatibility. >>>>> >>> A third solution might be to introduce an @ObserveAsync to declare an >>>>> >>> asynchronous capable observer? >>>>> >>> >>>>> >>> I?m waiting for active feedback from you to find the best solution >>>>> >>>taking >>>>> >>> ALL aspects (not only the technicals one) into account. >>>>> >>> >>>>> >>> Thanks, >>>>> >>> >>>>> >>> Antoine >>>>> >> >>>>> > >>>>> >>>>> >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/778a69a5/attachment-0001.html From pmuir at redhat.com Wed Mar 18 11:17:24 2015 From: pmuir at redhat.com (Pete Muir) Date: Wed, 18 Mar 2015 15:17:24 +0000 Subject: [cdi-dev] On @Observes for async events In-Reply-To: References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> <55096C6B.9080700@redhat.com> <55097111.1090402@redhat.com> <550975DF.2080505@redhat.com> Message-ID: <79830A70-82D8-4148-A0C6-5F99698FDF23@redhat.com> > On 18 Mar 2015, at 13:04, Romain Manni-Bucau wrote: > > > 2015-03-18 13:55 GMT+01:00 Jozef Hartinger >: > > On 03/18/2015 01:46 PM, Romain Manni-Bucau wrote: >> >> 2015-03-18 13:35 GMT+01:00 Jozef Hartinger >: >> >> On 03/18/2015 01:28 PM, Romain Manni-Bucau wrote: >>> >>> >>> 2015-03-18 13:15 GMT+01:00 Jozef Hartinger >: >>> >>> On 03/18/2015 11:16 AM, Romain Manni-Bucau wrote: >>> sequentializing them arbitrarily just makes it not async anymore >>> the event firing thread won't wait for event delivery so it is still async >>> >>> well doesn't change the fact you break original async need/wish doing it. >> break what? >> >> don't wait behavior, own thread model by call which is what async means most of the time > Well, the thread firing an event won't wait for the observers to complete so I cannot see how it breaks your "original async need/wish". Or do you associate "async" with splitting the work into as many parallel threads as possible? If so then we have a mismatch in terminology. FWIW this is what I would interpret an async observer model to be, yes. An async fire, perhaps not. However I think it?s unnecessarily limiting to design the ability to do this out of the spec, especially for an edge case such as asynchronous ordered observers. If you are writing an async observer, you clearly need to make it?s functionality idempotent, or expect things to go weird. Ordered observers are something I?m still not overly happy about ;-) > > > well about terminology maybe but I more think about expected behavior as a user. Think we now both get what we each of us put behind async and question is what's the most common case. Depending where you put async (fireAsync vs @Async/@ObserveAsync) it is not the same thing at all. >> >>> >>> >>> (+ think to the case you dont really have priorities you are just breaking the whole concept). >>> If you do not have priorities (or they are the same) then it is most likely fine to notify the observers in parallel. If you however do have priorities then it makes sense IMO to take them into account. Doing otherwise just complicates the entire concept by adding an artificial constraint. >>> >>> >>> point is you are introducing a model concept which is not aligned on the common model + doesn't even match correctly the async needs (what about onFailure() and onTimeout() which are mandatory when doing async) >> what common model? >>> >> >> callbacks one which is the only one making async usable and prod compatible > Which part is not aligned? In the current proposal you get a callback when all observers complete or an exception occurs. In what order the observers are called does not change anything about that. > > you don't control the timeout and exception from the callback. I mean in the observer chain which is what is needed most of the time (it helps me to think to it with a javascript example but maybe my personal feeling). > > >>> I tend to join Mark saying we should just do the minimum instead of wanting to do to much and providing something highly broken we'll need to fix in next version with more broken patterns. What's the need is the real question, not what would be cool to implement. >>> >>> Don't forget an async spec smells more and more strong with real async semantic and solutions so I guess the less we put in CDI now better it is. >> >> > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/4eee0ff4/attachment.html From pmuir at redhat.com Wed Mar 18 11:19:17 2015 From: pmuir at redhat.com (Pete Muir) Date: Wed, 18 Mar 2015 15:19:17 +0000 Subject: [cdi-dev] Update on Async event doc In-Reply-To: References: Message-ID: <35DAD12B-F0D9-478D-95E1-5F5DB1C2DBD1@redhat.com> > On 12 Mar 2015, at 12:56, Antoine Sabot-Durand wrote: > > Hi all, > > I compiled all the feedback and decision we took regarding async events and updated the Google Doc : https://docs.google.com/document/d/1Tm_fZWS6569YqCH9lGxuqBGzS9gfupic-vv1dyKCUxk/edit?usp=sharing > > The following point stays open. I?d like to close them (if possible) during the next meeting on Tuesday > > 1) Async delivery mechanism (comment by Jozef) > Should we write in the spec about how threads for events delivery should be used? Personally I?d rather not: I think this should be let to implementation, the specification should only describe the expected behavior (concurrency or not). now I may have missed something. > > 2) Exception Handling (comment by Jozef) > I didn?t write anything about exception and we should decide what happens if an exception occurs in an observer during async event dispatch. I think that it shouldn?t impact other observers and that we should stick to the way CompletionStage API works today. > > 3) Async event activation on both ends > We all agree that we need to explicitly fire event asynchronously on the producer side (fireAsync()). The discussion in 8.1 is about adding a way to accept async call on the consumer (observer) side. > a) As events are often triggered in other parts of the application than the parts that consume them (most CDI framework lib fire events foe end user code) preventing user to decide if an observer can be called asynchronously could lead to issues and will prevent library developper to use fireAsync() (in a defensive coding approach). Why? > b) On the other hand, when placed in the same application, it?ll be very confusing for user to have to fireAsync() and enable async observer to activate this new feature. > > I propose an opt-out approach. We add ?asyncSupported' member to ?@Observes' annotation with ?true? as default value. So in case of b) the end user won?t have to explicitly activate async on observer and i case of a) user detecting issue coming from async treatment of an event can explicitly declares one or more observer not compatible with async resolution with @Observes(asyncSupported=False) That?s really messy. > > 4) Support observer ordering with async events > I think we should keep event ordering for synchronous event and ignore this feature in async event. I don?t see obvious use case to be async and ordered. > > 5) Context propagation > I understand that propagating contexts in async event would impact easily context API. My only concern here is to be define async event to keep this feature possible. > > If I forgot points please comment this mail and the doc so we can take final decision during next meeting. > > Thank you > > > Antoine > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/d48fd62d/attachment-0001.html From antoine at sabot-durand.net Wed Mar 18 11:36:45 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 18 Mar 2015 16:36:45 +0100 Subject: [cdi-dev] On @Observes for async events In-Reply-To: <79830A70-82D8-4148-A0C6-5F99698FDF23@redhat.com> References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> <55096C6B.9080700@redhat.com> <55097111.1090402@redhat.com> <550975DF.2080505@redhat.com> <79830A70-82D8-4148-A0C6-5F99698FDF23@redhat.com> Message-ID: <551F540F-DD19-4AAF-A96C-64A5F54DEC96@sabot-durand.net> Ok guys, Again, ordering here is optional. My first thought was to not support it with async events, Jozef relaunch the subject. The heart of the discussion here is ?can we find a way to avoid activating async event at both ends and keep backward compatibility?. Have to use fireAsync() on one side and @Async @Observes or @Observes(asyncSupported=true) at the other side seems to me very unfriendly for users, but when I see mot people focus on other secondary points I think I?m the only one to find this crappy ;). > Le 18 mars 2015 ? 16:17, Pete Muir a ?crit : > > >> On 18 Mar 2015, at 13:04, Romain Manni-Bucau > wrote: >> >> >> 2015-03-18 13:55 GMT+01:00 Jozef Hartinger >: >> >> On 03/18/2015 01:46 PM, Romain Manni-Bucau wrote: >>> >>> 2015-03-18 13:35 GMT+01:00 Jozef Hartinger >: >>> >>> On 03/18/2015 01:28 PM, Romain Manni-Bucau wrote: >>>> >>>> >>>> 2015-03-18 13:15 GMT+01:00 Jozef Hartinger >: >>>> >>>> On 03/18/2015 11:16 AM, Romain Manni-Bucau wrote: >>>> sequentializing them arbitrarily just makes it not async anymore >>>> the event firing thread won't wait for event delivery so it is still async >>>> >>>> well doesn't change the fact you break original async need/wish doing it. >>> break what? >>> >>> don't wait behavior, own thread model by call which is what async means most of the time >> Well, the thread firing an event won't wait for the observers to complete so I cannot see how it breaks your "original async need/wish". Or do you associate "async" with splitting the work into as many parallel threads as possible? If so then we have a mismatch in terminology. > > FWIW this is what I would interpret an async observer model to be, yes. An async fire, perhaps not. However I think it?s unnecessarily limiting to design the ability to do this out of the spec, especially for an edge case such as asynchronous ordered observers. > > If you are writing an async observer, you clearly need to make it?s functionality idempotent, or expect things to go weird. > > Ordered observers are something I?m still not overly happy about ;-) > >> >> >> well about terminology maybe but I more think about expected behavior as a user. Think we now both get what we each of us put behind async and question is what's the most common case. Depending where you put async (fireAsync vs @Async/@ObserveAsync) it is not the same thing at all. >>> >>> >>> >>> (+ think to the case you dont really have priorities you are just breaking the whole concept). >>> If you do not have priorities (or they are the same) then it is most likely fine to notify the observers in parallel. If you however do have priorities then it makes sense IMO to take them into account. Doing otherwise just complicates the entire concept by adding an artificial constraint. >>> >>> >>> point is you are introducing a model concept which is not aligned on the common model + doesn't even match correctly the async needs (what about onFailure() and onTimeout() which are mandatory when doing async) >>> what common model? >>>> >>> >>> callbacks one which is the only one making async usable and prod compatible >> Which part is not aligned? In the current proposal you get a callback when all observers complete or an exception occurs. In what order the observers are called does not change anything about that. >> >> you don't control the timeout and exception from the callback. I mean in the observer chain which is what is needed most of the time (it helps me to think to it with a javascript example but maybe my personal feeling). >> >> >>>> I tend to join Mark saying we should just do the minimum instead of wanting to do to much and providing something highly broken we'll need to fix in next version with more broken patterns. What's the need is the real question, not what would be cool to implement. >>>> >>>> Don't forget an async spec smells more and more strong with real async semantic and solutions so I guess the less we put in CDI now better it is. >>> >>> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/76be5fde/attachment.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/20150318/76be5fde/attachment.bin From antoine at sabot-durand.net Wed Mar 18 11:44:33 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 18 Mar 2015 16:44:33 +0100 Subject: [cdi-dev] Update on Async event doc In-Reply-To: <35DAD12B-F0D9-478D-95E1-5F5DB1C2DBD1@redhat.com> References: <35DAD12B-F0D9-478D-95E1-5F5DB1C2DBD1@redhat.com> Message-ID: <6F63C532-6829-471B-BC68-C743ABDBB180@sabot-durand.net> > Le 18 mars 2015 ? 16:19, Pete Muir a ?crit : > >> >> On 12 Mar 2015, at 12:56, Antoine Sabot-Durand > wrote: >> >> Hi all, >> >> I compiled all the feedback and decision we took regarding async events and updated the Google Doc : https://docs.google.com/document/d/1Tm_fZWS6569YqCH9lGxuqBGzS9gfupic-vv1dyKCUxk/edit?usp=sharing >> >> The following point stays open. I?d like to close them (if possible) during the next meeting on Tuesday >> >> 1) Async delivery mechanism (comment by Jozef) >> Should we write in the spec about how threads for events delivery should be used? Personally I?d rather not: I think this should be let to implementation, the specification should only describe the expected behavior (concurrency or not). now I may have missed something. >> >> 2) Exception Handling (comment by Jozef) >> I didn?t write anything about exception and we should decide what happens if an exception occurs in an observer during async event dispatch. I think that it shouldn?t impact other observers and that we should stick to the way CompletionStage API works today. >> >> 3) Async event activation on both ends >> We all agree that we need to explicitly fire event asynchronously on the producer side (fireAsync()). The discussion in 8.1 is about adding a way to accept async call on the consumer (observer) side. >> a) As events are often triggered in other parts of the application than the parts that consume them (most CDI framework lib fire events foe end user code) preventing user to decide if an observer can be called asynchronously could lead to issues and will prevent library developper to use fireAsync() (in a defensive coding approach). > > Why? read the doc section 8.1 containing objection brought by Mark (https://docs.google.com/document/d/1Tm_fZWS6569YqCH9lGxuqBGzS9gfupic-vv1dyKCUxk/edit?usp=sharing ). I asked people if they could find way to refute objection nearly one month ago. If you can do it, I?ll be glad... > >> b) On the other hand, when placed in the same application, it?ll be very confusing for user to have to fireAsync() and enable async observer to activate this new feature. >> >> I propose an opt-out approach. We add ?asyncSupported' member to ?@Observes' annotation with ?true? as default value. So in case of b) the end user won?t have to explicitly activate async on observer and i case of a) user detecting issue coming from async treatment of an event can explicitly declares one or more observer not compatible with async resolution with @Observes(asyncSupported=False) > > That?s really messy. No compare to the opt-in approach : @Observes(asyncSupported=true) or @Async void myObserver(@Observes payload) in addition to fireAsync(). > >> >> 4) Support observer ordering with async events >> I think we should keep event ordering for synchronous event and ignore this feature in async event. I don?t see obvious use case to be async and ordered. >> >> 5) Context propagation >> I understand that propagating contexts in async event would impact easily context API. My only concern here is to be define async event to keep this feature possible. >> >> If I forgot points please comment this mail and the doc so we can take final decision during next meeting. >> >> Thank you >> >> >> Antoine >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/da55a2b5/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/20150318/da55a2b5/attachment-0001.bin From issues at jboss.org Wed Mar 18 12:07:19 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 18 Mar 2015 12:07:19 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-452) Specify that web scoped (request, session, application) beans are injectable in async servlets In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-452: ------------------------------------- Fix Version/s: 2.0 (discussion) > Specify that web scoped (request, session, application) beans are injectable in async servlets > ---------------------------------------------------------------------------------------------- > > Key: CDI-452 > URL: https://issues.jboss.org/browse/CDI-452 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Affects Versions: 1.0 > Reporter: Ed Burns > Priority: Trivial > Fix For: 2.0 (discussion) > > > Consider this code based on this blog post: < https://weblogs.java.net/blog/swchan2/archive/2013/06/06/asynchronous-servlet-and-java-ee-concurrency-utilities >. > {code} > @WebServlet(urlPatterns="/test2", asyncSupported=true) > public class TestAsyncMESServlet extends HttpServlet { > @Resource > private ManagedExecutorService managedExecutorService; > @Inject > MyRunnableImpl myRunnableImpl; > @Override > protected void doGet(HttpServletRequest req, HttpServletResponse res) > throws ServletException, IOException { > final AsyncContext asyncContext = req.startAsync(); > final PrintWriter writer = res.getWriter(); > managedExecutorService.submit(myRunnableImpl); > } > public static class MyRunnableImpl implements Runnable { > @Inject > Bean bean; // Bean is @RequestScoped > @Override > public void run() { > writer.println("Done"); > asyncContext.complete(); > } > } > } > {code} > According to Jozef Hartzinger, this currently does not work, because only @Dependent and @ApplicationScoped beans are propagated to the new thread. To keep CDI relevant in light of the reactive programming movement and the popularity of node.js, we need to make this work. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Mar 18 12:09:19 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 18 Mar 2015 12:09:19 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-452) Specify that web scoped (request, session, application) beans are injectable in async servlets In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051463#comment-13051463 ] Antoine Sabot-Durand commented on CDI-452: ------------------------------------------ I agree [~edburns], we really should revisit contexts to see how we could change API to be able to propagate them in asynchronous operation. > Specify that web scoped (request, session, application) beans are injectable in async servlets > ---------------------------------------------------------------------------------------------- > > Key: CDI-452 > URL: https://issues.jboss.org/browse/CDI-452 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Affects Versions: 1.0 > Reporter: Ed Burns > Priority: Trivial > Fix For: 2.0 (discussion) > > > Consider this code based on this blog post: < https://weblogs.java.net/blog/swchan2/archive/2013/06/06/asynchronous-servlet-and-java-ee-concurrency-utilities >. > {code} > @WebServlet(urlPatterns="/test2", asyncSupported=true) > public class TestAsyncMESServlet extends HttpServlet { > @Resource > private ManagedExecutorService managedExecutorService; > @Inject > MyRunnableImpl myRunnableImpl; > @Override > protected void doGet(HttpServletRequest req, HttpServletResponse res) > throws ServletException, IOException { > final AsyncContext asyncContext = req.startAsync(); > final PrintWriter writer = res.getWriter(); > managedExecutorService.submit(myRunnableImpl); > } > public static class MyRunnableImpl implements Runnable { > @Inject > Bean bean; // Bean is @RequestScoped > @Override > public void run() { > writer.println("Done"); > asyncContext.complete(); > } > } > } > {code} > According to Jozef Hartzinger, this currently does not work, because only @Dependent and @ApplicationScoped beans are propagated to the new thread. To keep CDI relevant in light of the reactive programming movement and the popularity of node.js, we need to make this work. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From pmuir at redhat.com Wed Mar 18 12:31:39 2015 From: pmuir at redhat.com (Pete Muir) Date: Wed, 18 Mar 2015 16:31:39 +0000 Subject: [cdi-dev] On @Observes for async events In-Reply-To: <551F540F-DD19-4AAF-A96C-64A5F54DEC96@sabot-durand.net> References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> <55096C6B.9080700@redhat.com> <55097111.1090402@redhat.com> <550975DF.2080505@redhat.com> <79830A7! 0-82D8-4148-A0C6-5F99698FDF23@redhat.com> <551F540F-DD19-4AAF-A96C-64A5F54DEC96@sabot-durand.net> Message-ID: <06185990-67E5-4177-810B-A7C3BD1ABF7B@redhat.com> Agreed, that is a mess. Why do we need to enable on both sides? > On 18 Mar 2015, at 15:36, Antoine Sabot-Durand wrote: > > Ok guys, > > Again, ordering here is optional. My first thought was to not support it with async events, Jozef relaunch the subject. The heart of the discussion here is ?can we find a way to avoid activating async event at both ends and keep backward compatibility?. Have to use fireAsync() on one side and @Async @Observes or @Observes(asyncSupported=true) at the other side seems to me very unfriendly for users, but when I see mot people focus on other secondary points I think I?m the only one to find this crappy ;). > > >> Le 18 mars 2015 ? 16:17, Pete Muir > a ?crit : >> >> >>> On 18 Mar 2015, at 13:04, Romain Manni-Bucau > wrote: >>> >>> >>> 2015-03-18 13:55 GMT+01:00 Jozef Hartinger >: >>> >>> On 03/18/2015 01:46 PM, Romain Manni-Bucau wrote: >>>> >>>> 2015-03-18 13:35 GMT+01:00 Jozef Hartinger >: >>>> >>>> On 03/18/2015 01:28 PM, Romain Manni-Bucau wrote: >>>>> >>>>> >>>>> 2015-03-18 13:15 GMT+01:00 Jozef Hartinger >: >>>>> >>>>> On 03/18/2015 11:16 AM, Romain Manni-Bucau wrote: >>>>> sequentializing them arbitrarily just makes it not async anymore >>>>> the event firing thread won't wait for event delivery so it is still async >>>>> >>>>> well doesn't change the fact you break original async need/wish doing it. >>>> break what? >>>> >>>> don't wait behavior, own thread model by call which is what async means most of the time >>> Well, the thread firing an event won't wait for the observers to complete so I cannot see how it breaks your "original async need/wish". Or do you associate "async" with splitting the work into as many parallel threads as possible? If so then we have a mismatch in terminology. >> >> FWIW this is what I would interpret an async observer model to be, yes. An async fire, perhaps not. However I think it?s unnecessarily limiting to design the ability to do this out of the spec, especially for an edge case such as asynchronous ordered observers. >> >> If you are writing an async observer, you clearly need to make it?s functionality idempotent, or expect things to go weird. >> >> Ordered observers are something I?m still not overly happy about ;-) >> >>> >>> >>> well about terminology maybe but I more think about expected behavior as a user. Think we now both get what we each of us put behind async and question is what's the most common case. Depending where you put async (fireAsync vs @Async/@ObserveAsync) it is not the same thing at all. >>> >>> >>> >>> (+ think to the case you dont really have priorities you are just breaking the whole concept). >>> If you do not have priorities (or they are the same) then it is most likely fine to notify the observers in parallel. If you however do have priorities then it makes sense IMO to take them into account. Doing otherwise just complicates the entire concept by adding an artificial constraint. >>> >>> >>> point is you are introducing a model concept which is not aligned on the common model + doesn't even match correctly the async needs (what about onFailure() and onTimeout() which are mandatory when doing async) >>> what common model? >>>> >>> callbacks one which is the only one making async usable and prod compatible >>> Which part is not aligned? In the current proposal you get a callback when all observers complete or an exception occurs. In what order the observers are called does not change anything about that. >>> >>> you don't control the timeout and exception from the callback. I mean in the observer chain which is what is needed most of the time (it helps me to think to it with a javascript example but maybe my personal feeling). >>> >>> >>>>> I tend to join Mark saying we should just do the minimum instead of wanting to do to much and providing something highly broken we'll need to fix in next version with more broken patterns. What's the need is the real question, not what would be cool to implement. >>>>> >>>>> Don't forget an async spec smells more and more strong with real async semantic and solutions so I guess the less we put in CDI now better it is. >>>> >>>> >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/f83f5c4c/attachment-0001.html From antoine at sabot-durand.net Wed Mar 18 12:46:33 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 18 Mar 2015 17:46:33 +0100 Subject: [cdi-dev] On @Observes for async events In-Reply-To: <06185990-67E5-4177-810B-A7C3BD1ABF7B@redhat.com> References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> <55096C6B.9080700@redhat.com> <55097111.1090402@redhat.com> <550975DF.2080505@redhat.com> <79830A7! 0-82D8-4148-A0C6-5F99698FDF23@redhat.com> <551F540F-DD19-4AAF-A96C-64A5F54DEC96@sabot-durand.net> <06185990-67E5-4177-810B-A7C3BD1ABF7B@redhat.com> Message-ID: <68C0CE58-9042-4242-A6F1-00826F6B12C5@sabot-durand.net> > Le 18 mars 2015 ? 17:31, Pete Muir a ?crit : > > Agreed, that is a mess. Why do we need to enable on both sides? Glad to share this pic with you. Mark raised the problem of backward compatibility. If a 3rd party lib use fireAsync(), user have no choice to deactivate async operation on his @Observes. Imagine this observer is linked to a transaction phase, it won?t work as expected. So if we don?t give a mean to opt-in or opt-out async on observer code may break and thus 3rd party lib will never switch to fireAsync(). We also have the problem of bean injection or bean request in the observer, as we are not sure to adopt context propagation in async operation as I?d like to, it could also break code to fore observer in async mode from outside. > >> On 18 Mar 2015, at 15:36, Antoine Sabot-Durand > wrote: >> >> Ok guys, >> >> Again, ordering here is optional. My first thought was to not support it with async events, Jozef relaunch the subject. The heart of the discussion here is ?can we find a way to avoid activating async event at both ends and keep backward compatibility?. Have to use fireAsync() on one side and @Async @Observes or @Observes(asyncSupported=true) at the other side seems to me very unfriendly for users, but when I see mot people focus on other secondary points I think I?m the only one to find this crappy ;). >> >> >>> Le 18 mars 2015 ? 16:17, Pete Muir > a ?crit : >>> >>> >>>> On 18 Mar 2015, at 13:04, Romain Manni-Bucau > wrote: >>>> >>>> >>>> 2015-03-18 13:55 GMT+01:00 Jozef Hartinger >: >>>> >>>> On 03/18/2015 01:46 PM, Romain Manni-Bucau wrote: >>>>> >>>>> 2015-03-18 13:35 GMT+01:00 Jozef Hartinger >: >>>>> >>>>> On 03/18/2015 01:28 PM, Romain Manni-Bucau wrote: >>>>>> >>>>>> >>>>>> 2015-03-18 13:15 GMT+01:00 Jozef Hartinger >: >>>>>> >>>>>> On 03/18/2015 11:16 AM, Romain Manni-Bucau wrote: >>>>>> sequentializing them arbitrarily just makes it not async anymore >>>>>> the event firing thread won't wait for event delivery so it is still async >>>>>> >>>>>> well doesn't change the fact you break original async need/wish doing it. >>>>> break what? >>>>> >>>>> don't wait behavior, own thread model by call which is what async means most of the time >>>> Well, the thread firing an event won't wait for the observers to complete so I cannot see how it breaks your "original async need/wish". Or do you associate "async" with splitting the work into as many parallel threads as possible? If so then we have a mismatch in terminology. >>> >>> FWIW this is what I would interpret an async observer model to be, yes. An async fire, perhaps not. However I think it?s unnecessarily limiting to design the ability to do this out of the spec, especially for an edge case such as asynchronous ordered observers. >>> >>> If you are writing an async observer, you clearly need to make it?s functionality idempotent, or expect things to go weird. >>> >>> Ordered observers are something I?m still not overly happy about ;-) >>> >>>> >>>> >>>> well about terminology maybe but I more think about expected behavior as a user. Think we now both get what we each of us put behind async and question is what's the most common case. Depending where you put async (fireAsync vs @Async/@ObserveAsync) it is not the same thing at all. >>>> >>>> >>>> >>>> (+ think to the case you dont really have priorities you are just breaking the whole concept). >>>> If you do not have priorities (or they are the same) then it is most likely fine to notify the observers in parallel. If you however do have priorities then it makes sense IMO to take them into account. Doing otherwise just complicates the entire concept by adding an artificial constraint. >>>> >>>> >>>> point is you are introducing a model concept which is not aligned on the common model + doesn't even match correctly the async needs (what about onFailure() and onTimeout() which are mandatory when doing async) >>>> what common model? >>>>> >>>> callbacks one which is the only one making async usable and prod compatible >>>> Which part is not aligned? In the current proposal you get a callback when all observers complete or an exception occurs. In what order the observers are called does not change anything about that. >>>> >>>> you don't control the timeout and exception from the callback. I mean in the observer chain which is what is needed most of the time (it helps me to think to it with a javascript example but maybe my personal feeling). >>>> >>>> >>>>>> I tend to join Mark saying we should just do the minimum instead of wanting to do to much and providing something highly broken we'll need to fix in next version with more broken patterns. What's the need is the real question, not what would be cool to implement. >>>>>> >>>>>> Don't forget an async spec smells more and more strong with real async semantic and solutions so I guess the less we put in CDI now better it is. >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/631ec131/attachment.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/20150318/631ec131/attachment.bin From pmuir at redhat.com Wed Mar 18 12:57:02 2015 From: pmuir at redhat.com (Pete Muir) Date: Wed, 18 Mar 2015 16:57:02 +0000 Subject: [cdi-dev] On @Observes for async events In-Reply-To: <68C0CE58-9042-4242-A6F1-00826F6B12C5@sabot-durand.net> References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> <55096C6B.9080700@redhat.com> <55097111.1090402@redhat.com> <550975DF.2080505@redhat.com> <79830A7! ! 0-82D8-4148-A0C6-5F99698FDF23@redhat.com> <551F540F-DD19-4AAF-A96C-64A5F54DEC96@sabot-durand.net> <06185990-67E5-4177-810B-A7C3BD1ABF7B@redhat.com> <68C0CE58-9042-4242-A6F1-00826F6B12C5@sabot-durand.net> Message-ID: <9C3547B9-2C7A-44EB-9C24-119C430CA3A1@redhat.com> > On 18 Mar 2015, at 16:46, Antoine Sabot-Durand wrote: > > >> Le 18 mars 2015 ? 17:31, Pete Muir > a ?crit : >> >> Agreed, that is a mess. Why do we need to enable on both sides? > > Glad to share this pic with you. Mark raised the problem of backward compatibility. If a 3rd party lib use fireAsync(), user have no choice to deactivate async operation on his @Observes. Imagine this observer is linked to a transaction phase, it won?t work as expected. So if we don?t give a mean to opt-in or opt-out async on observer code may break and thus 3rd party lib will never switch to fireAsync(). Ok, I?m missing a subtle point I guess. If a transaction is running, then the observer method is invoked async anyway (during the correct phase). If a transaction is not running, then it can fire async as per non transactional observers. > We also have the problem of bean injection or bean request in the observer, as we are not sure to adopt context propagation in async operation as I?d like to, it could also break code to fore observer in async mode from outside. I would assume that context propagation is a must. However I can see that if we can?t support this, then there is a problem. > > >> >>> On 18 Mar 2015, at 15:36, Antoine Sabot-Durand > wrote: >>> >>> Ok guys, >>> >>> Again, ordering here is optional. My first thought was to not support it with async events, Jozef relaunch the subject. The heart of the discussion here is ?can we find a way to avoid activating async event at both ends and keep backward compatibility?. Have to use fireAsync() on one side and @Async @Observes or @Observes(asyncSupported=true) at the other side seems to me very unfriendly for users, but when I see mot people focus on other secondary points I think I?m the only one to find this crappy ;). >>> >>> >>>> Le 18 mars 2015 ? 16:17, Pete Muir > a ?crit : >>>> >>>> >>>>> On 18 Mar 2015, at 13:04, Romain Manni-Bucau > wrote: >>>>> >>>>> >>>>> 2015-03-18 13:55 GMT+01:00 Jozef Hartinger >: >>>>> >>>>> On 03/18/2015 01:46 PM, Romain Manni-Bucau wrote: >>>>>> >>>>>> 2015-03-18 13:35 GMT+01:00 Jozef Hartinger >: >>>>>> >>>>>> On 03/18/2015 01:28 PM, Romain Manni-Bucau wrote: >>>>>>> >>>>>>> >>>>>>> 2015-03-18 13:15 GMT+01:00 Jozef Hartinger >: >>>>>>> >>>>>>> On 03/18/2015 11:16 AM, Romain Manni-Bucau wrote: >>>>>>> sequentializing them arbitrarily just makes it not async anymore >>>>>>> the event firing thread won't wait for event delivery so it is still async >>>>>>> >>>>>>> well doesn't change the fact you break original async need/wish doing it. >>>>>> break what? >>>>>> >>>>>> don't wait behavior, own thread model by call which is what async means most of the time >>>>> Well, the thread firing an event won't wait for the observers to complete so I cannot see how it breaks your "original async need/wish". Or do you associate "async" with splitting the work into as many parallel threads as possible? If so then we have a mismatch in terminology. >>>> >>>> FWIW this is what I would interpret an async observer model to be, yes. An async fire, perhaps not. However I think it?s unnecessarily limiting to design the ability to do this out of the spec, especially for an edge case such as asynchronous ordered observers. >>>> >>>> If you are writing an async observer, you clearly need to make it?s functionality idempotent, or expect things to go weird. >>>> >>>> Ordered observers are something I?m still not overly happy about ;-) >>>> >>>>> >>>>> >>>>> well about terminology maybe but I more think about expected behavior as a user. Think we now both get what we each of us put behind async and question is what's the most common case. Depending where you put async (fireAsync vs @Async/@ObserveAsync) it is not the same thing at all. >>>>> >>>>> >>>>> >>>>> (+ think to the case you dont really have priorities you are just breaking the whole concept). >>>>> If you do not have priorities (or they are the same) then it is most likely fine to notify the observers in parallel. If you however do have priorities then it makes sense IMO to take them into account. Doing otherwise just complicates the entire concept by adding an artificial constraint. >>>>> >>>>> >>>>> point is you are introducing a model concept which is not aligned on the common model + doesn't even match correctly the async needs (what about onFailure() and onTimeout() which are mandatory when doing async) >>>>> what common model? >>>>>> >>>>> callbacks one which is the only one making async usable and prod compatible >>>>> Which part is not aligned? In the current proposal you get a callback when all observers complete or an exception occurs. In what order the observers are called does not change anything about that. >>>>> >>>>> you don't control the timeout and exception from the callback. I mean in the observer chain which is what is needed most of the time (it helps me to think to it with a javascript example but maybe my personal feeling). >>>>> >>>>> >>>>>>> I tend to join Mark saying we should just do the minimum instead of wanting to do to much and providing something highly broken we'll need to fix in next version with more broken patterns. What's the need is the real question, not what would be cool to implement. >>>>>>> >>>>>>> Don't forget an async spec smells more and more strong with real async semantic and solutions so I guess the less we put in CDI now better it is. >>>>>> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/370d4301/attachment-0001.html From rmannibucau at gmail.com Wed Mar 18 13:26:04 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 18 Mar 2015 18:26:04 +0100 Subject: [cdi-dev] On @Observes for async events In-Reply-To: <9C3547B9-2C7A-44EB-9C24-119C430CA3A1@redhat.com> References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> <55096C6B.9080700@redhat.com> <55097111.1090402@redhat.com> <550975DF.2080505@redhat.com> <551F540F-DD19-4AAF-A96C-64A5F54DEC96@sabot-durand.net> <06185990-67E5-4177-810B-A7C3BD1ABF7B@redhat.com> <68C0CE58-9042-4242-A6F1-00826F6B12C5@sabot-durand.net> <9C3547B9-2C7A-44EB-9C24-119C430CA3A1@redhat.com> Message-ID: 2015-03-18 17:57 GMT+01:00 Pete Muir : > > On 18 Mar 2015, at 16:46, Antoine Sabot-Durand > wrote: > > > Le 18 mars 2015 ? 17:31, Pete Muir a ?crit : > > Agreed, that is a mess. Why do we need to enable on both sides? > > > Glad to share this pic with you. Mark raised the problem of backward > compatibility. If a 3rd party lib use fireAsync(), user have no choice to > deactivate async operation on his @Observes. Imagine this observer is > linked to a transaction phase, it won?t work as expected. So if we don?t > give a mean to opt-in or opt-out async on observer code may break and thus > 3rd party lib will never switch to fireAsync(). > > > Ok, I?m missing a subtle point I guess. If a transaction is running, then > the observer method is invoked async anyway (during the correct phase). If > a transaction is not running, then it can fire async as per non > transactional observers. > > We also have the problem of bean injection or bean request in the > observer, as we are not sure to adopt context propagation in async > operation as I?d like to, it could also break code to fore observer in > async mode from outside. > > > I would assume that context propagation is a must. > > but opposed to ee concurrency utilities and other EE parts? sounds weird even if tempting, maybe need a sync with other specs > However I can see that if we can?t support this, then there is a problem. > > > > > On 18 Mar 2015, at 15:36, Antoine Sabot-Durand > wrote: > > Ok guys, > > Again, ordering here is optional. My first thought was to not support it > with async events, Jozef relaunch the subject. The heart of the discussion > here is ?can we find a way to avoid activating async event at both ends and > keep backward compatibility?. Have to use fireAsync() on one side and > @Async @Observes or @Observes(asyncSupported=true) at the other side seems > to me very unfriendly for users, but when I see mot people focus on other > secondary points I think I?m the only one to find this crappy ;). > > > Le 18 mars 2015 ? 16:17, Pete Muir a ?crit : > > > On 18 Mar 2015, at 13:04, Romain Manni-Bucau > wrote: > > > 2015-03-18 13:55 GMT+01:00 Jozef Hartinger : > >> >> On 03/18/2015 01:46 PM, Romain Manni-Bucau wrote: >> >> >> 2015-03-18 13:35 GMT+01:00 Jozef Hartinger : >> >>> >>> On 03/18/2015 01:28 PM, Romain Manni-Bucau wrote: >>> >>> >>> >>> 2015-03-18 13:15 GMT+01:00 Jozef Hartinger : >>> >>>> >>>> On 03/18/2015 11:16 AM, Romain Manni-Bucau wrote: >>>> >>>>> sequentializing them arbitrarily just makes it not async anymore >>>>> >>>> the event firing thread won't wait for event delivery so it is still >>>> async >>> >>> >>> well doesn't change the fact you break original async need/wish doing it. >>> >>> break what? >>> >>> don't wait behavior, own thread model by call which is what async means >> most of the time >> >> Well, the thread firing an event won't wait for the observers to complete >> so I cannot see how it breaks your "original async need/wish". Or do you >> associate "async" with splitting the work into as many parallel threads as >> possible? If so then we have a mismatch in terminology. >> > > FWIW this is what I would interpret an async observer model to be, yes. An > async fire, perhaps not. However I think it?s unnecessarily limiting to > design the ability to do this out of the spec, especially for an edge case > such as asynchronous ordered observers. > > If you are writing an async observer, you clearly need to make it?s > functionality idempotent, or expect things to go weird. > > Ordered observers are something I?m still not overly happy about ;-) > > > well about terminology maybe but I more think about expected behavior as a > user. Think we now both get what we each of us put behind async and > question is what's the most common case. Depending where you put async > (fireAsync vs @Async/@ObserveAsync) it is not the same thing at all. > >> >> >> >> (+ think to the case you dont really have priorities you are just >>> breaking the whole concept). >>> >> If you do not have priorities (or they are the same) then it is most >> likely fine to notify the observers in parallel. If you however do have >> priorities then it makes sense IMO to take them into account. Doing >> otherwise just complicates the entire concept by adding an artificial >> constraint. >> >> >> point is you are introducing a model concept which is not aligned on the >> common model + doesn't even match correctly the async needs (what about >> onFailure() and onTimeout() which are mandatory when doing async) >> what common model? >> >> >> callbacks one which is the only one making async usable and prod >> compatible >> Which part is not aligned? In the current proposal you get a callback >> when all observers complete or an exception occurs. In what order the >> observers are called does not change anything about that. >> > > you don't control the timeout and exception from the callback. I mean in > the observer chain which is what is needed most of the time (it helps me to > think to it with a javascript example but maybe my personal feeling). > > >> >> I tend to join Mark saying we should just do the minimum instead of >>> wanting to do to much and providing something highly broken we'll need to >>> fix in next version with more broken patterns. What's the need is the real >>> question, not what would be cool to implement. >>> >>> Don't forget an async spec smells more and more strong with real async >>> semantic and solutions so I guess the less we put in CDI now better it is. >>> >>> >>> >> >> > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/4ac7d885/attachment.html From pmuir at redhat.com Wed Mar 18 13:30:54 2015 From: pmuir at redhat.com (Pete Muir) Date: Wed, 18 Mar 2015 17:30:54 +0000 Subject: [cdi-dev] On @Observes for async events In-Reply-To: References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> <55096C6B.9080700@redhat.com> <55097111.1090402@redhat.com> <550975DF.2080505@redhat.com> <551F540! F-DD19-4AAF-A96C-64A5F54DEC96@sabot-durand.net> <06185990-67E5-4177-810B-A7C3BD1ABF7B@redhat.com> <68C0CE58-9042-4242-A6F1-00826F6B12C5@sabot-durand.net> <9C3547B9-2C7A-44EB-9C24-119C430CA3A1@redhat.com> Message-ID: > On 18 Mar 2015, at 17:26, Romain Manni-Bucau wrote: > > > > 2015-03-18 17:57 GMT+01:00 Pete Muir >: > >> On 18 Mar 2015, at 16:46, Antoine Sabot-Durand > wrote: >> >> >>> Le 18 mars 2015 ? 17:31, Pete Muir > a ?crit : >>> >>> Agreed, that is a mess. Why do we need to enable on both sides? >> >> Glad to share this pic with you. Mark raised the problem of backward compatibility. If a 3rd party lib use fireAsync(), user have no choice to deactivate async operation on his @Observes. Imagine this observer is linked to a transaction phase, it won?t work as expected. So if we don?t give a mean to opt-in or opt-out async on observer code may break and thus 3rd party lib will never switch to fireAsync(). > > Ok, I?m missing a subtle point I guess. If a transaction is running, then the observer method is invoked async anyway (during the correct phase). If a transaction is not running, then it can fire async as per non transactional observers. > >> We also have the problem of bean injection or bean request in the observer, as we are not sure to adopt context propagation in async operation as I?d like to, it could also break code to fore observer in async mode from outside. > > I would assume that context propagation is a must. > > > but opposed to ee concurrency utilities I thought this was by mistake rather than design? > and other EE parts? Again, AIUI by mistake, not design. > sounds weird even if tempting, maybe need a sync with other specs > > However I can see that if we can?t support this, then there is a problem. > >> >> >>> >>>> On 18 Mar 2015, at 15:36, Antoine Sabot-Durand > wrote: >>>> >>>> Ok guys, >>>> >>>> Again, ordering here is optional. My first thought was to not support it with async events, Jozef relaunch the subject. The heart of the discussion here is ?can we find a way to avoid activating async event at both ends and keep backward compatibility?. Have to use fireAsync() on one side and @Async @Observes or @Observes(asyncSupported=true) at the other side seems to me very unfriendly for users, but when I see mot people focus on other secondary points I think I?m the only one to find this crappy ;). >>>> >>>> >>>>> Le 18 mars 2015 ? 16:17, Pete Muir > a ?crit : >>>>> >>>>> >>>>>> On 18 Mar 2015, at 13:04, Romain Manni-Bucau > wrote: >>>>>> >>>>>> >>>>>> 2015-03-18 13:55 GMT+01:00 Jozef Hartinger >: >>>>>> >>>>>> On 03/18/2015 01:46 PM, Romain Manni-Bucau wrote: >>>>>>> >>>>>>> 2015-03-18 13:35 GMT+01:00 Jozef Hartinger >: >>>>>>> >>>>>>> On 03/18/2015 01:28 PM, Romain Manni-Bucau wrote: >>>>>>>> >>>>>>>> >>>>>>>> 2015-03-18 13:15 GMT+01:00 Jozef Hartinger >: >>>>>>>> >>>>>>>> On 03/18/2015 11:16 AM, Romain Manni-Bucau wrote: >>>>>>>> sequentializing them arbitrarily just makes it not async anymore >>>>>>>> the event firing thread won't wait for event delivery so it is still async >>>>>>>> >>>>>>>> well doesn't change the fact you break original async need/wish doing it. >>>>>>> break what? >>>>>>> >>>>>>> don't wait behavior, own thread model by call which is what async means most of the time >>>>>> Well, the thread firing an event won't wait for the observers to complete so I cannot see how it breaks your "original async need/wish". Or do you associate "async" with splitting the work into as many parallel threads as possible? If so then we have a mismatch in terminology. >>>>> >>>>> FWIW this is what I would interpret an async observer model to be, yes. An async fire, perhaps not. However I think it?s unnecessarily limiting to design the ability to do this out of the spec, especially for an edge case such as asynchronous ordered observers. >>>>> >>>>> If you are writing an async observer, you clearly need to make it?s functionality idempotent, or expect things to go weird. >>>>> >>>>> Ordered observers are something I?m still not overly happy about ;-) >>>>> >>>>>> >>>>>> >>>>>> well about terminology maybe but I more think about expected behavior as a user. Think we now both get what we each of us put behind async and question is what's the most common case. Depending where you put async (fireAsync vs @Async/@ObserveAsync) it is not the same thing at all. >>>>>> >>>>>> >>>>>> >>>>>> (+ think to the case you dont really have priorities you are just breaking the whole concept). >>>>>> If you do not have priorities (or they are the same) then it is most likely fine to notify the observers in parallel. If you however do have priorities then it makes sense IMO to take them into account. Doing otherwise just complicates the entire concept by adding an artificial constraint. >>>>>> >>>>>> >>>>>> point is you are introducing a model concept which is not aligned on the common model + doesn't even match correctly the async needs (what about onFailure() and onTimeout() which are mandatory when doing async) >>>>>> what common model? >>>>>>> >>>>>> callbacks one which is the only one making async usable and prod compatible >>>>>> Which part is not aligned? In the current proposal you get a callback when all observers complete or an exception occurs. In what order the observers are called does not change anything about that. >>>>>> >>>>>> you don't control the timeout and exception from the callback. I mean in the observer chain which is what is needed most of the time (it helps me to think to it with a javascript example but maybe my personal feeling). >>>>>> >>>>>> >>>>>>>> I tend to join Mark saying we should just do the minimum instead of wanting to do to much and providing something highly broken we'll need to fix in next version with more broken patterns. What's the need is the real question, not what would be cool to implement. >>>>>>>> >>>>>>>> Don't forget an async spec smells more and more strong with real async semantic and solutions so I guess the less we put in CDI now better it is. >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> cdi-dev mailing list >>>>>> cdi-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>> >>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>>>> >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/f6cabd66/attachment-0001.html From rmannibucau at gmail.com Wed Mar 18 13:40:16 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 18 Mar 2015 18:40:16 +0100 Subject: [cdi-dev] On @Observes for async events In-Reply-To: References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> <55096C6B.9080700@redhat.com> <55097111.1090402@redhat.com> <550975DF.2080505@redhat.com> <06185990-67E5-4177-810B-A7C3BD1ABF7B@redhat.com> <68C0CE58-9042-4242-A6F1-00826F6B12C5@sabot-durand.net> <9C3547B9-2C7A-44EB-9C24-119C430CA3A1@redhat.com> Message-ID: 2015-03-18 18:30 GMT+01:00 Pete Muir : > > On 18 Mar 2015, at 17:26, Romain Manni-Bucau > wrote: > > > > 2015-03-18 17:57 GMT+01:00 Pete Muir : > >> >> On 18 Mar 2015, at 16:46, Antoine Sabot-Durand >> wrote: >> >> >> Le 18 mars 2015 ? 17:31, Pete Muir a ?crit : >> >> Agreed, that is a mess. Why do we need to enable on both sides? >> >> >> Glad to share this pic with you. Mark raised the problem of backward >> compatibility. If a 3rd party lib use fireAsync(), user have no choice to >> deactivate async operation on his @Observes. Imagine this observer is >> linked to a transaction phase, it won?t work as expected. So if we don?t >> give a mean to opt-in or opt-out async on observer code may break and thus >> 3rd party lib will never switch to fireAsync(). >> >> >> Ok, I?m missing a subtle point I guess. If a transaction is running, then >> the observer method is invoked async anyway (during the correct phase). If >> a transaction is not running, then it can fire async as per non >> transactional observers. >> >> We also have the problem of bean injection or bean request in the >> observer, as we are not sure to adopt context propagation in async >> operation as I?d like to, it could also break code to fore observer in >> async mode from outside. >> >> >> I would assume that context propagation is a must. >> >> > but opposed to ee concurrency utilities > > > I thought this was by mistake rather than design? > > and other EE parts? > > > Again, AIUI by mistake, not design. > > yes and no, propagating request scope can break the whole app > sounds weird even if tempting, maybe need a sync with other specs > > >> However I can see that if we can?t support this, then there is a problem. >> >> >> >> >> On 18 Mar 2015, at 15:36, Antoine Sabot-Durand >> wrote: >> >> Ok guys, >> >> Again, ordering here is optional. My first thought was to not support it >> with async events, Jozef relaunch the subject. The heart of the discussion >> here is ?can we find a way to avoid activating async event at both ends and >> keep backward compatibility?. Have to use fireAsync() on one side and >> @Async @Observes or @Observes(asyncSupported=true) at the other side seems >> to me very unfriendly for users, but when I see mot people focus on other >> secondary points I think I?m the only one to find this crappy ;). >> >> >> Le 18 mars 2015 ? 16:17, Pete Muir a ?crit : >> >> >> On 18 Mar 2015, at 13:04, Romain Manni-Bucau >> wrote: >> >> >> 2015-03-18 13:55 GMT+01:00 Jozef Hartinger : >> >>> >>> On 03/18/2015 01:46 PM, Romain Manni-Bucau wrote: >>> >>> >>> 2015-03-18 13:35 GMT+01:00 Jozef Hartinger : >>> >>>> >>>> On 03/18/2015 01:28 PM, Romain Manni-Bucau wrote: >>>> >>>> >>>> >>>> 2015-03-18 13:15 GMT+01:00 Jozef Hartinger : >>>> >>>>> >>>>> On 03/18/2015 11:16 AM, Romain Manni-Bucau wrote: >>>>> >>>>>> sequentializing them arbitrarily just makes it not async anymore >>>>>> >>>>> the event firing thread won't wait for event delivery so it is still >>>>> async >>>> >>>> >>>> well doesn't change the fact you break original async need/wish doing >>>> it. >>>> >>>> break what? >>>> >>>> don't wait behavior, own thread model by call which is what async means >>> most of the time >>> >>> Well, the thread firing an event won't wait for the observers to >>> complete so I cannot see how it breaks your "original async need/wish". Or >>> do you associate "async" with splitting the work into as many parallel >>> threads as possible? If so then we have a mismatch in terminology. >>> >> >> FWIW this is what I would interpret an async observer model to be, yes. >> An async fire, perhaps not. However I think it?s unnecessarily limiting to >> design the ability to do this out of the spec, especially for an edge case >> such as asynchronous ordered observers. >> >> If you are writing an async observer, you clearly need to make it?s >> functionality idempotent, or expect things to go weird. >> >> Ordered observers are something I?m still not overly happy about ;-) >> >> >> well about terminology maybe but I more think about expected behavior as >> a user. Think we now both get what we each of us put behind async and >> question is what's the most common case. Depending where you put async >> (fireAsync vs @Async/@ObserveAsync) it is not the same thing at all. >> >>> >>> >>> >>> (+ think to the case you dont really have priorities you are just >>>> breaking the whole concept). >>>> >>> If you do not have priorities (or they are the same) then it is most >>> likely fine to notify the observers in parallel. If you however do have >>> priorities then it makes sense IMO to take them into account. Doing >>> otherwise just complicates the entire concept by adding an artificial >>> constraint. >>> >>> >>> point is you are introducing a model concept which is not aligned on the >>> common model + doesn't even match correctly the async needs (what about >>> onFailure() and onTimeout() which are mandatory when doing async) >>> what common model? >>> >>> >>> callbacks one which is the only one making async usable and prod >>> compatible >>> Which part is not aligned? In the current proposal you get a callback >>> when all observers complete or an exception occurs. In what order the >>> observers are called does not change anything about that. >>> >> >> you don't control the timeout and exception from the callback. I mean in >> the observer chain which is what is needed most of the time (it helps me to >> think to it with a javascript example but maybe my personal feeling). >> >> >>> >>> I tend to join Mark saying we should just do the minimum instead of >>>> wanting to do to much and providing something highly broken we'll need to >>>> fix in next version with more broken patterns. What's the need is the real >>>> question, not what would be cool to implement. >>>> >>>> Don't forget an async spec smells more and more strong with real async >>>> semantic and solutions so I guess the less we put in CDI now better it is. >>>> >>>> >>>> >>> >>> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/88615195/attachment.html From pmuir at redhat.com Wed Mar 18 13:42:47 2015 From: pmuir at redhat.com (Pete Muir) Date: Wed, 18 Mar 2015 17:42:47 +0000 Subject: [cdi-dev] On @Observes for async events In-Reply-To: References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> <55096C6B.9080700@redhat.com> <55097111.1090402@redhat.com> <550975DF.2080505@redhat.com> <0618599! 0-67E5-4177-810B-A7C3BD1ABF7B@redhat.com> <68C0CE58-9042-4242-A6F1-00826F6B12C5@sabot-durand.net> <9C3547B9-2C7A-44EB-9C24-119C430CA3A1@redhat.com> Message-ID: Care to be a little less vague? ;-) > On 18 Mar 2015, at 17:40, Romain Manni-Bucau wrote: > > > 2015-03-18 18:30 GMT+01:00 Pete Muir >: > >> On 18 Mar 2015, at 17:26, Romain Manni-Bucau > wrote: >> >> >> >> 2015-03-18 17:57 GMT+01:00 Pete Muir >: >> >>> On 18 Mar 2015, at 16:46, Antoine Sabot-Durand > wrote: >>> >>> >>>> Le 18 mars 2015 ? 17:31, Pete Muir > a ?crit : >>>> >>>> Agreed, that is a mess. Why do we need to enable on both sides? >>> >>> Glad to share this pic with you. Mark raised the problem of backward compatibility. If a 3rd party lib use fireAsync(), user have no choice to deactivate async operation on his @Observes. Imagine this observer is linked to a transaction phase, it won?t work as expected. So if we don?t give a mean to opt-in or opt-out async on observer code may break and thus 3rd party lib will never switch to fireAsync(). >> >> Ok, I?m missing a subtle point I guess. If a transaction is running, then the observer method is invoked async anyway (during the correct phase). If a transaction is not running, then it can fire async as per non transactional observers. >> >>> We also have the problem of bean injection or bean request in the observer, as we are not sure to adopt context propagation in async operation as I?d like to, it could also break code to fore observer in async mode from outside. >> >> I would assume that context propagation is a must. >> >> >> but opposed to ee concurrency utilities > > I thought this was by mistake rather than design? > >> and other EE parts? > > Again, AIUI by mistake, not design. > > > yes and no, propagating request scope can break the whole app > >> sounds weird even if tempting, maybe need a sync with other specs >> >> However I can see that if we can?t support this, then there is a problem. >> >>> >>> >>>> >>>>> On 18 Mar 2015, at 15:36, Antoine Sabot-Durand > wrote: >>>>> >>>>> Ok guys, >>>>> >>>>> Again, ordering here is optional. My first thought was to not support it with async events, Jozef relaunch the subject. The heart of the discussion here is ?can we find a way to avoid activating async event at both ends and keep backward compatibility?. Have to use fireAsync() on one side and @Async @Observes or @Observes(asyncSupported=true) at the other side seems to me very unfriendly for users, but when I see mot people focus on other secondary points I think I?m the only one to find this crappy ;). >>>>> >>>>> >>>>>> Le 18 mars 2015 ? 16:17, Pete Muir > a ?crit : >>>>>> >>>>>> >>>>>>> On 18 Mar 2015, at 13:04, Romain Manni-Bucau > wrote: >>>>>>> >>>>>>> >>>>>>> 2015-03-18 13:55 GMT+01:00 Jozef Hartinger >: >>>>>>> >>>>>>> On 03/18/2015 01:46 PM, Romain Manni-Bucau wrote: >>>>>>>> >>>>>>>> 2015-03-18 13:35 GMT+01:00 Jozef Hartinger >: >>>>>>>> >>>>>>>> On 03/18/2015 01:28 PM, Romain Manni-Bucau wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> 2015-03-18 13:15 GMT+01:00 Jozef Hartinger >: >>>>>>>>> >>>>>>>>> On 03/18/2015 11:16 AM, Romain Manni-Bucau wrote: >>>>>>>>> sequentializing them arbitrarily just makes it not async anymore >>>>>>>>> the event firing thread won't wait for event delivery so it is still async >>>>>>>>> >>>>>>>>> well doesn't change the fact you break original async need/wish doing it. >>>>>>>> break what? >>>>>>>> >>>>>>>> don't wait behavior, own thread model by call which is what async means most of the time >>>>>>> Well, the thread firing an event won't wait for the observers to complete so I cannot see how it breaks your "original async need/wish". Or do you associate "async" with splitting the work into as many parallel threads as possible? If so then we have a mismatch in terminology. >>>>>> >>>>>> FWIW this is what I would interpret an async observer model to be, yes. An async fire, perhaps not. However I think it?s unnecessarily limiting to design the ability to do this out of the spec, especially for an edge case such as asynchronous ordered observers. >>>>>> >>>>>> If you are writing an async observer, you clearly need to make it?s functionality idempotent, or expect things to go weird. >>>>>> >>>>>> Ordered observers are something I?m still not overly happy about ;-) >>>>>> >>>>>>> >>>>>>> >>>>>>> well about terminology maybe but I more think about expected behavior as a user. Think we now both get what we each of us put behind async and question is what's the most common case. Depending where you put async (fireAsync vs @Async/@ObserveAsync) it is not the same thing at all. >>>>>>> >>>>>>> >>>>>>> >>>>>>> (+ think to the case you dont really have priorities you are just breaking the whole concept). >>>>>>> If you do not have priorities (or they are the same) then it is most likely fine to notify the observers in parallel. If you however do have priorities then it makes sense IMO to take them into account. Doing otherwise just complicates the entire concept by adding an artificial constraint. >>>>>>> >>>>>>> >>>>>>> point is you are introducing a model concept which is not aligned on the common model + doesn't even match correctly the async needs (what about onFailure() and onTimeout() which are mandatory when doing async) >>>>>>> what common model? >>>>>>>> >>>>>>> callbacks one which is the only one making async usable and prod compatible >>>>>>> Which part is not aligned? In the current proposal you get a callback when all observers complete or an exception occurs. In what order the observers are called does not change anything about that. >>>>>>> >>>>>>> you don't control the timeout and exception from the callback. I mean in the observer chain which is what is needed most of the time (it helps me to think to it with a javascript example but maybe my personal feeling). >>>>>>> >>>>>>> >>>>>>>>> I tend to join Mark saying we should just do the minimum instead of wanting to do to much and providing something highly broken we'll need to fix in next version with more broken patterns. What's the need is the real question, not what would be cool to implement. >>>>>>>>> >>>>>>>>> Don't forget an async spec smells more and more strong with real async semantic and solutions so I guess the less we put in CDI now better it is. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> cdi-dev mailing list >>>>>>> cdi-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>> >>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>>>>> >>>>>> _______________________________________________ >>>>>> cdi-dev mailing list >>>>>> cdi-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>> >>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/a748015f/attachment-0001.html From rmannibucau at gmail.com Wed Mar 18 13:56:29 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 18 Mar 2015 18:56:29 +0100 Subject: [cdi-dev] On @Observes for async events In-Reply-To: References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> <55096C6B.9080700@redhat.com> <55097111.1090402@redhat.com> <550975DF.2080505@redhat.com> <68C0CE58-9042-4242-A6F1-00826F6B12C5@sabot-durand.net> <9C3547B9-2C7A-44EB-9C24-119C430CA3A1@redhat.com> Message-ID: request scope in CDI means thread scope = thread safe. If you assume it and propagate it in another threa (async) then you can be no more thread safe. if observers rely on request beans (logged user?) then app is broken Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-03-18 18:42 GMT+01:00 Pete Muir : > Care to be a little less vague? ;-) > > On 18 Mar 2015, at 17:40, Romain Manni-Bucau > wrote: > > > 2015-03-18 18:30 GMT+01:00 Pete Muir : > >> >> On 18 Mar 2015, at 17:26, Romain Manni-Bucau >> wrote: >> >> >> >> 2015-03-18 17:57 GMT+01:00 Pete Muir : >> >>> >>> On 18 Mar 2015, at 16:46, Antoine Sabot-Durand >>> wrote: >>> >>> >>> Le 18 mars 2015 ? 17:31, Pete Muir a ?crit : >>> >>> Agreed, that is a mess. Why do we need to enable on both sides? >>> >>> >>> Glad to share this pic with you. Mark raised the problem of backward >>> compatibility. If a 3rd party lib use fireAsync(), user have no choice to >>> deactivate async operation on his @Observes. Imagine this observer is >>> linked to a transaction phase, it won?t work as expected. So if we don?t >>> give a mean to opt-in or opt-out async on observer code may break and thus >>> 3rd party lib will never switch to fireAsync(). >>> >>> >>> Ok, I?m missing a subtle point I guess. If a transaction is running, >>> then the observer method is invoked async anyway (during the correct >>> phase). If a transaction is not running, then it can fire async as per non >>> transactional observers. >>> >>> We also have the problem of bean injection or bean request in the >>> observer, as we are not sure to adopt context propagation in async >>> operation as I?d like to, it could also break code to fore observer in >>> async mode from outside. >>> >>> >>> I would assume that context propagation is a must. >>> >>> >> but opposed to ee concurrency utilities >> >> >> I thought this was by mistake rather than design? >> >> and other EE parts? >> >> >> Again, AIUI by mistake, not design. >> >> > yes and no, propagating request scope can break the whole app > > >> sounds weird even if tempting, maybe need a sync with other specs >> >> >>> However I can see that if we can?t support this, then there is a problem. >>> >>> >>> >>> >>> On 18 Mar 2015, at 15:36, Antoine Sabot-Durand >>> wrote: >>> >>> Ok guys, >>> >>> Again, ordering here is optional. My first thought was to not support it >>> with async events, Jozef relaunch the subject. The heart of the discussion >>> here is ?can we find a way to avoid activating async event at both ends and >>> keep backward compatibility?. Have to use fireAsync() on one side and >>> @Async @Observes or @Observes(asyncSupported=true) at the other side seems >>> to me very unfriendly for users, but when I see mot people focus on other >>> secondary points I think I?m the only one to find this crappy ;). >>> >>> >>> Le 18 mars 2015 ? 16:17, Pete Muir a ?crit : >>> >>> >>> On 18 Mar 2015, at 13:04, Romain Manni-Bucau >>> wrote: >>> >>> >>> 2015-03-18 13:55 GMT+01:00 Jozef Hartinger : >>> >>>> >>>> On 03/18/2015 01:46 PM, Romain Manni-Bucau wrote: >>>> >>>> >>>> 2015-03-18 13:35 GMT+01:00 Jozef Hartinger : >>>> >>>>> >>>>> On 03/18/2015 01:28 PM, Romain Manni-Bucau wrote: >>>>> >>>>> >>>>> >>>>> 2015-03-18 13:15 GMT+01:00 Jozef Hartinger : >>>>> >>>>>> >>>>>> On 03/18/2015 11:16 AM, Romain Manni-Bucau wrote: >>>>>> >>>>>>> sequentializing them arbitrarily just makes it not async anymore >>>>>>> >>>>>> the event firing thread won't wait for event delivery so it is still >>>>>> async >>>>> >>>>> >>>>> well doesn't change the fact you break original async need/wish doing >>>>> it. >>>>> >>>>> break what? >>>>> >>>>> don't wait behavior, own thread model by call which is what async >>>> means most of the time >>>> >>>> Well, the thread firing an event won't wait for the observers to >>>> complete so I cannot see how it breaks your "original async need/wish". Or >>>> do you associate "async" with splitting the work into as many parallel >>>> threads as possible? If so then we have a mismatch in terminology. >>>> >>> >>> FWIW this is what I would interpret an async observer model to be, yes. >>> An async fire, perhaps not. However I think it?s unnecessarily limiting to >>> design the ability to do this out of the spec, especially for an edge case >>> such as asynchronous ordered observers. >>> >>> If you are writing an async observer, you clearly need to make it?s >>> functionality idempotent, or expect things to go weird. >>> >>> Ordered observers are something I?m still not overly happy about ;-) >>> >>> >>> well about terminology maybe but I more think about expected behavior as >>> a user. Think we now both get what we each of us put behind async and >>> question is what's the most common case. Depending where you put async >>> (fireAsync vs @Async/@ObserveAsync) it is not the same thing at all. >>> >>>> >>>> >>>> >>>> (+ think to the case you dont really have priorities you are just >>>>> breaking the whole concept). >>>>> >>>> If you do not have priorities (or they are the same) then it is most >>>> likely fine to notify the observers in parallel. If you however do have >>>> priorities then it makes sense IMO to take them into account. Doing >>>> otherwise just complicates the entire concept by adding an artificial >>>> constraint. >>>> >>>> >>>> point is you are introducing a model concept which is not aligned on >>>> the common model + doesn't even match correctly the async needs (what about >>>> onFailure() and onTimeout() which are mandatory when doing async) >>>> what common model? >>>> >>>> >>>> callbacks one which is the only one making async usable and prod >>>> compatible >>>> Which part is not aligned? In the current proposal you get a callback >>>> when all observers complete or an exception occurs. In what order the >>>> observers are called does not change anything about that. >>>> >>> >>> you don't control the timeout and exception from the callback. I mean in >>> the observer chain which is what is needed most of the time (it helps me to >>> think to it with a javascript example but maybe my personal feeling). >>> >>> >>>> >>>> I tend to join Mark saying we should just do the minimum instead of >>>>> wanting to do to much and providing something highly broken we'll need to >>>>> fix in next version with more broken patterns. What's the need is the real >>>>> question, not what would be cool to implement. >>>>> >>>>> Don't forget an async spec smells more and more strong with real async >>>>> semantic and solutions so I guess the less we put in CDI now better it is. >>>>> >>>>> >>>>> >>>> >>>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>> provided on this list, the provider waives all patent and other >>> intellectual property rights inherent in such information. >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>> provided on this list, the provider waives all patent and other >>> intellectual property rights inherent in such information. >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/dec31203/attachment-0001.html From struberg at yahoo.de Thu Mar 19 02:14:34 2015 From: struberg at yahoo.de (Mark Struberg) Date: Thu, 19 Mar 2015 07:14:34 +0100 Subject: [cdi-dev] On @Observes for async events In-Reply-To: <9C3547B9-2C7A-44EB-9C24-119C430CA3A1@redhat.com> References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> <55096C6B.9080700@redhat.com> <55097111.1090402@redhat.com> <550975DF.2080505@redhat.com> <79830A7! ! 0-82D8-4148-A0C6-5F99698FDF23@redhat.com> <551F540F-DD19-4AAF-A96C-64A5F54DEC96@sabot-durand.net> <06185990-67E5-4177-810B-A7C3BD1ABF7B@redhat.com> <68C0CE58-9042-4242-A6F1-00826F6B12C5@sabot-durand.net> <9C3547B9-2C7A-44EB-9C24-119C430CA3A1@redhat.com> Message-ID: <29B1DD84-0552-43F5-8C77-CB743D34AAE9@yahoo.de> Hi Pete! > Ok, I?m missing a subtle point I guess. If a transaction is running, then the observer method is invoked async anyway (during the correct phase). Imo there are 2 different notion of ?async?. 1.) means at some ?random' other point in time 2.) means at some different thread. The BEFORE_SUCCESS (and maybe a few others) usually are category 1.). Means they fire at some other point in time (before the transaction gets finally committed), BUT they fire on the same Thread (because they need all the TX stuff set up). > I would assume that context propagation is a must. This is hard, but probably doable for our own scopes. @RequestScoped could probably work. @SessionScoped is _much_ harder! And for custom Scopes ALL bets are off anyway? So I?d rather not force this on customers. Especially not if we need some high degree of backward compatibility. LieGrue, strub > Am 18.03.2015 um 17:57 schrieb Pete Muir : > > >> On 18 Mar 2015, at 16:46, Antoine Sabot-Durand wrote: >> >> >>> Le 18 mars 2015 ? 17:31, Pete Muir a ?crit : >>> >>> Agreed, that is a mess. Why do we need to enable on both sides? >> >> Glad to share this pic with you. Mark raised the problem of backward compatibility. If a 3rd party lib use fireAsync(), user have no choice to deactivate async operation on his @Observes. Imagine this observer is linked to a transaction phase, it won?t work as expected. So if we don?t give a mean to opt-in or opt-out async on observer code may break and thus 3rd party lib will never switch to fireAsync(). > > Ok, I?m missing a subtle point I guess. If a transaction is running, then the observer method is invoked async anyway (during the correct phase). If a transaction is not running, then it can fire async as per non transactional observers. > >> We also have the problem of bean injection or bean request in the observer, as we are not sure to adopt context propagation in async operation as I?d like to, it could also break code to fore observer in async mode from outside. > > I would assume that context propagation is a must. > > However I can see that if we can?t support this, then there is a problem. > >> >> >>> >>>> On 18 Mar 2015, at 15:36, Antoine Sabot-Durand wrote: >>>> >>>> Ok guys, >>>> >>>> Again, ordering here is optional. My first thought was to not support it with async events, Jozef relaunch the subject. The heart of the discussion here is ?can we find a way to avoid activating async event at both ends and keep backward compatibility?. Have to use fireAsync() on one side and @Async @Observes or @Observes(asyncSupported=true) at the other side seems to me very unfriendly for users, but when I see mot people focus on other secondary points I think I?m the only one to find this crappy ;). >>>> >>>> >>>>> Le 18 mars 2015 ? 16:17, Pete Muir a ?crit : >>>>> >>>>> >>>>>> On 18 Mar 2015, at 13:04, Romain Manni-Bucau wrote: >>>>>> >>>>>> >>>>>> 2015-03-18 13:55 GMT+01:00 Jozef Hartinger : >>>>>> >>>>>> On 03/18/2015 01:46 PM, Romain Manni-Bucau wrote: >>>>>>> >>>>>>> 2015-03-18 13:35 GMT+01:00 Jozef Hartinger : >>>>>>> >>>>>>> On 03/18/2015 01:28 PM, Romain Manni-Bucau wrote: >>>>>>>> >>>>>>>> >>>>>>>> 2015-03-18 13:15 GMT+01:00 Jozef Hartinger : >>>>>>>> >>>>>>>> On 03/18/2015 11:16 AM, Romain Manni-Bucau wrote: >>>>>>>> sequentializing them arbitrarily just makes it not async anymore >>>>>>>> the event firing thread won't wait for event delivery so it is still async >>>>>>>> >>>>>>>> well doesn't change the fact you break original async need/wish doing it. >>>>>>> break what? >>>>>>> don't wait behavior, own thread model by call which is what async means most of the time >>>>>> Well, the thread firing an event won't wait for the observers to complete so I cannot see how it breaks your "original async need/wish". Or do you associate "async" with splitting the work into as many parallel threads as possible? If so then we have a mismatch in terminology. >>>>> >>>>> FWIW this is what I would interpret an async observer model to be, yes. An async fire, perhaps not. However I think it?s unnecessarily limiting to design the ability to do this out of the spec, especially for an edge case such as asynchronous ordered observers. >>>>> >>>>> If you are writing an async observer, you clearly need to make it?s functionality idempotent, or expect things to go weird. >>>>> >>>>> Ordered observers are something I?m still not overly happy about ;-) >>>>> >>>>>> >>>>>> well about terminology maybe but I more think about expected behavior as a user. Think we now both get what we each of us put behind async and question is what's the most common case. Depending where you put async (fireAsync vs @Async/@ObserveAsync) it is not the same thing at all. >>>>>> >>>>>> >>>>>> >>>>>> (+ think to the case you dont really have priorities you are just breaking the whole concept). >>>>>> If you do not have priorities (or they are the same) then it is most likely fine to notify the observers in parallel. If you however do have priorities then it makes sense IMO to take them into account. Doing otherwise just complicates the entire concept by adding an artificial constraint. >>>>>> >>>>>> >>>>>> point is you are introducing a model concept which is not aligned on the common model + doesn't even match correctly the async needs (what about onFailure() and onTimeout() which are mandatory when doing async) >>>>>> what common model? >>>>>>> >>>>>> callbacks one which is the only one making async usable and prod compatible >>>>>> Which part is not aligned? In the current proposal you get a callback when all observers complete or an exception occurs. In what order the observers are called does not change anything about that. >>>>>> >>>>>> you don't control the timeout and exception from the callback. I mean in the observer chain which is what is needed most of the time (it helps me to think to it with a javascript example but maybe my personal feeling). >>>>>> >>>>>> >>>>>>>> I tend to join Mark saying we should just do the minimum instead of wanting to do to much and providing something highly broken we'll need to fix in next version with more broken patterns. What's the need is the real question, not what would be cool to implement. >>>>>>>> >>>>>>>> Don't forget an async spec smells more and more strong with real async semantic and solutions so I guess the less we put in CDI now better it is. >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> cdi-dev mailing list >>>>>> cdi-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>> >>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>>>> >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>>> >>> >> > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From struberg at yahoo.de Thu Mar 19 02:25:42 2015 From: struberg at yahoo.de (Mark Struberg) Date: Thu, 19 Mar 2015 07:25:42 +0100 Subject: [cdi-dev] On @Observes for async events In-Reply-To: References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> <55096C6B.9080700@redhat.com> <55097111.1090402@redhat.com> <550975DF.2080505@redhat.com> <551F540! F-DD19-4AAF-A96C-64A5F54DEC96@sabot-durand.net> <06185990-67E5-4177-810B-A7C3BD1ABF7B@redhat.com> <68C0CE58-9042-4242-A6F1-00826F6B12C5@sabot-durand.net> <9C3547B9-2C7A-44EB-9C24-119C430CA3A1@redhat.com> Message-ID: <33DA3D25-45A9-42CD-A74C-F311995D3AFF@yahoo.de> >> but opposed to ee concurrency utilities > > I thought this was by mistake rather than design? As far as I remember there was a long discussion on the EJB EG and it was intentionally that @Asynchronous does NOT propagate any information about the session, security, and don?t even share the same pool instance from @Stateless (pool ~what we have as @RequestScoped). The reason is that EJB is all about removing concurrency complexity from the user as good as possible. The other problem is that you don?t have it under control how long the new thread will run. And the Session might be looong time dead already. Another issue is with TX handling. The JPA spec and also JTA spec (TransactionSynchronizationRegistry) defines that a transaction must not be used ?concurrently?. Means they only must be assigned to a very single Thread. Even with servlet 3.0 async requests you have a ServletRequest only attached to a very single thread AT EACH TIME (means the thread might switch, but it?s max 1 at a time). LieGrue, strub From pmuir at redhat.com Thu Mar 19 07:07:55 2015 From: pmuir at redhat.com (Pete Muir) Date: Thu, 19 Mar 2015 11:07:55 +0000 Subject: [cdi-dev] On @Observes for async events In-Reply-To: References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> <55096C6B.9080700@redhat.com> <55097111.1090402@redhat.com> <550975DF.2080505@redhat.com> <68C0CE5! 8-9042-4242-A6F1-00826F6B12C5@sabot-durand.net> <9C3547B9-2C7A-44EB-9C24-119C430CA3A1@redhat.com> Message-ID: <9F24F1B7-EF58-4875-B9B9-650AE351A35B@redhat.com> Yeah, good point, thanks :-) > On 18 Mar 2015, at 17:56, Romain Manni-Bucau wrote: > > request scope in CDI means thread scope = thread safe. If you assume it and propagate it in another threa (async) then you can be no more thread safe. if observers rely on request beans (logged user?) then app is broken > > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > 2015-03-18 18:42 GMT+01:00 Pete Muir >: > Care to be a little less vague? ;-) > >> On 18 Mar 2015, at 17:40, Romain Manni-Bucau > wrote: >> >> >> 2015-03-18 18:30 GMT+01:00 Pete Muir >: >> >>> On 18 Mar 2015, at 17:26, Romain Manni-Bucau > wrote: >>> >>> >>> >>> 2015-03-18 17:57 GMT+01:00 Pete Muir >: >>> >>>> On 18 Mar 2015, at 16:46, Antoine Sabot-Durand > wrote: >>>> >>>> >>>>> Le 18 mars 2015 ? 17:31, Pete Muir > a ?crit : >>>>> >>>>> Agreed, that is a mess. Why do we need to enable on both sides? >>>> >>>> Glad to share this pic with you. Mark raised the problem of backward compatibility. If a 3rd party lib use fireAsync(), user have no choice to deactivate async operation on his @Observes. Imagine this observer is linked to a transaction phase, it won?t work as expected. So if we don?t give a mean to opt-in or opt-out async on observer code may break and thus 3rd party lib will never switch to fireAsync(). >>> >>> Ok, I?m missing a subtle point I guess. If a transaction is running, then the observer method is invoked async anyway (during the correct phase). If a transaction is not running, then it can fire async as per non transactional observers. >>> >>>> We also have the problem of bean injection or bean request in the observer, as we are not sure to adopt context propagation in async operation as I?d like to, it could also break code to fore observer in async mode from outside. >>> >>> I would assume that context propagation is a must. >>> >>> >>> but opposed to ee concurrency utilities >> >> I thought this was by mistake rather than design? >> >>> and other EE parts? >> >> Again, AIUI by mistake, not design. >> >> >> yes and no, propagating request scope can break the whole app >> >>> sounds weird even if tempting, maybe need a sync with other specs >>> >>> However I can see that if we can?t support this, then there is a problem. >>> >>>> >>>> >>>>> >>>>>> On 18 Mar 2015, at 15:36, Antoine Sabot-Durand > wrote: >>>>>> >>>>>> Ok guys, >>>>>> >>>>>> Again, ordering here is optional. My first thought was to not support it with async events, Jozef relaunch the subject. The heart of the discussion here is ?can we find a way to avoid activating async event at both ends and keep backward compatibility?. Have to use fireAsync() on one side and @Async @Observes or @Observes(asyncSupported=true) at the other side seems to me very unfriendly for users, but when I see mot people focus on other secondary points I think I?m the only one to find this crappy ;). >>>>>> >>>>>> >>>>>>> Le 18 mars 2015 ? 16:17, Pete Muir > a ?crit : >>>>>>> >>>>>>> >>>>>>>> On 18 Mar 2015, at 13:04, Romain Manni-Bucau > wrote: >>>>>>>> >>>>>>>> >>>>>>>> 2015-03-18 13:55 GMT+01:00 Jozef Hartinger >: >>>>>>>> >>>>>>>> On 03/18/2015 01:46 PM, Romain Manni-Bucau wrote: >>>>>>>>> >>>>>>>>> 2015-03-18 13:35 GMT+01:00 Jozef Hartinger >: >>>>>>>>> >>>>>>>>> On 03/18/2015 01:28 PM, Romain Manni-Bucau wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2015-03-18 13:15 GMT+01:00 Jozef Hartinger >: >>>>>>>>>> >>>>>>>>>> On 03/18/2015 11:16 AM, Romain Manni-Bucau wrote: >>>>>>>>>> sequentializing them arbitrarily just makes it not async anymore >>>>>>>>>> the event firing thread won't wait for event delivery so it is still async >>>>>>>>>> >>>>>>>>>> well doesn't change the fact you break original async need/wish doing it. >>>>>>>>> break what? >>>>>>>>> >>>>>>>>> don't wait behavior, own thread model by call which is what async means most of the time >>>>>>>> Well, the thread firing an event won't wait for the observers to complete so I cannot see how it breaks your "original async need/wish". Or do you associate "async" with splitting the work into as many parallel threads as possible? If so then we have a mismatch in terminology. >>>>>>> >>>>>>> FWIW this is what I would interpret an async observer model to be, yes. An async fire, perhaps not. However I think it?s unnecessarily limiting to design the ability to do this out of the spec, especially for an edge case such as asynchronous ordered observers. >>>>>>> >>>>>>> If you are writing an async observer, you clearly need to make it?s functionality idempotent, or expect things to go weird. >>>>>>> >>>>>>> Ordered observers are something I?m still not overly happy about ;-) >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> well about terminology maybe but I more think about expected behavior as a user. Think we now both get what we each of us put behind async and question is what's the most common case. Depending where you put async (fireAsync vs @Async/@ObserveAsync) it is not the same thing at all. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> (+ think to the case you dont really have priorities you are just breaking the whole concept). >>>>>>>> If you do not have priorities (or they are the same) then it is most likely fine to notify the observers in parallel. If you however do have priorities then it makes sense IMO to take them into account. Doing otherwise just complicates the entire concept by adding an artificial constraint. >>>>>>>> >>>>>>>> >>>>>>>> point is you are introducing a model concept which is not aligned on the common model + doesn't even match correctly the async needs (what about onFailure() and onTimeout() which are mandatory when doing async) >>>>>>>> what common model? >>>>>>>>> >>>>>>>> callbacks one which is the only one making async usable and prod compatible >>>>>>>> Which part is not aligned? In the current proposal you get a callback when all observers complete or an exception occurs. In what order the observers are called does not change anything about that. >>>>>>>> >>>>>>>> you don't control the timeout and exception from the callback. I mean in the observer chain which is what is needed most of the time (it helps me to think to it with a javascript example but maybe my personal feeling). >>>>>>>> >>>>>>>> >>>>>>>>>> I tend to join Mark saying we should just do the minimum instead of wanting to do to much and providing something highly broken we'll need to fix in next version with more broken patterns. What's the need is the real question, not what would be cool to implement. >>>>>>>>>> >>>>>>>>>> Don't forget an async spec smells more and more strong with real async semantic and solutions so I guess the less we put in CDI now better it is. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> cdi-dev mailing list >>>>>>>> cdi-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>> >>>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> cdi-dev mailing list >>>>>>> cdi-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>> >>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150319/f2b95bde/attachment-0001.html From pmuir at redhat.com Thu Mar 19 07:08:40 2015 From: pmuir at redhat.com (Pete Muir) Date: Thu, 19 Mar 2015 11:08:40 +0000 Subject: [cdi-dev] On @Observes for async events In-Reply-To: <33DA3D25-45A9-42CD-A74C-F311995D3AFF@yahoo.de> References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> <55096C6B.9080700@redhat.com> <55097111.1090402@redhat.com> <550975DF.2080505@redhat.com> <551F540! ! ! F-DD19-4AAF-A96C-64A5F54DEC96@sabot-durand.net> <06185990-67E5-4177-810B-A7C3BD1ABF7B@redhat.com> <68C0CE58-9042-4242-A6F1-00826F6B12C5@sabot-durand.net> <9C3547B9-2C7A-44EB-9C24-119C430CA3A1@redhat.com> <33DA3D25-45A9-42CD-A74C-F311995D3AFF@yahoo.de> Message-ID: <41A4AD62-F292-4EA0-96CB-966D97572A77@redhat.com> Good points, I will mull on it :-) > On 19 Mar 2015, at 06:25, Mark Struberg wrote: > >>> but opposed to ee concurrency utilities >> >> I thought this was by mistake rather than design? > > > > As far as I remember there was a long discussion on the EJB EG and it was intentionally that @Asynchronous does NOT propagate any information about the session, security, and don?t even share the same pool instance from @Stateless (pool ~what we have as @RequestScoped). > > The reason is that EJB is all about removing concurrency complexity from the user as good as possible. The other problem is that you don?t have it under control how long the new thread will run. And the Session might be looong time dead already. Another issue is with TX handling. The JPA spec and also JTA spec (TransactionSynchronizationRegistry) defines that a transaction must not be used ?concurrently?. Means they only must be assigned to a very single Thread. > > Even with servlet 3.0 async requests you have a ServletRequest only attached to a very single thread AT EACH TIME (means the thread might switch, but it?s max 1 at a time). > > > > LieGrue, > strub From jharting at redhat.com Thu Mar 19 08:09:34 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Thu, 19 Mar 2015 13:09:34 +0100 Subject: [cdi-dev] On @Observes for async events In-Reply-To: References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> Message-ID: <550ABC7E.6070601@redhat.com> On 03/18/2015 04:14 PM, Pete Muir wrote: > I think I have misunderstood the async model that is being proposed. > We are proposing that all the observers of an event fired > asynchronously are all run on a single thread? (Not the thread that > fires the event, another thread, but the same thread for each observer). No, the current proposal is not that specific at this point do define a particular architecture. The one you mentioned is one of the possible options. It has certain advantages: - the caller of fireAsync() does not wait for observers to complete so it is async for the caller - observer notification works the same as way as we know today except that in a different thread - the common pattern of using mutable event payload on which observers contribute would work fine - the payload does not need to be thread-safe - it would be safely published to the notification thread by the CDI implementation and there are no races between observers - ordering (if needed) fits well Disadvantages - it does not eliminate the backward-compatibility problem completely (different thread means different transaction context, CDI contexts and thread locals) - observers are not called in parallel Another option would be to call the observers in parallel Advantages: - the caller of fireAsync() does not wait for observers to complete so it is async for the caller - observers are independent of each other Disadvantages: - it does not eliminate the backward-compatibility problem completely (different thread means different transaction context, CDI contexts and thread locals) - the payload needs to be thread-safe - ordering would not work here - single event firing possibly results in multiple exceptions (tricky for the caller to handle with CompletionStage API) Another option is to combine those two and by default call the observers in parallel. If for some reason an observer depends on a different observer (by means of priorities) then the container guarantees that the partial ordering of observer notification is met. Advantages: - the caller of fireAsync() does not wait for observers to complete so it is async for the caller - observers are independent of each other - priority works the same in sync and async Disadvantages: - it does not eliminate the backward-compatibility problem completely (different thread means different transaction context, CDI contexts and thread locals) - the payload needs to be thread-safe - single event firing possibly results in multiple exceptions (tricky for the caller to handle with CompletionStage API) > > This would be a somewhat odd limitation in my mind. It?s certainly > *not* something that is semantically intuitive if you have something > like @Observes @Asynchronously on event observers, which definitely > implies the event observation is asynchronous, not the event firing. In the current proposal, @Observes @Asynchronously is just an enabler (for backward compatibility) of async event firing. It alone does not mean anything. > > I would definitely prefer an asynchronous observation model, which I > can?t see as being remotely compatible with observer ordering. The > classic approach of using callbacks to identify when a method is done > is inherently more powerful, and better understood. So basically kind of EJB's @Asynchronous methods applied to observers + a callback on event.fire()? The downside I can see here is that the event.fire() caller never knows whether the call will block or not whereas with event.fireAsync() it would be guaranteed not to block. > > Perhaps I?ve missed this, but what are the use cases for wanting to > specify that the observation is done async on the observer? And how > does this relate to the event firing methods ability to get a > callback? I suspect you would need to retrofit the entire firing > system to always return a callback if you wanted to allow the observer > to control whether it was async or not. > >> On 18 Mar 2015, at 10:11, Antoine Sabot-Durand >> > wrote: >> >> Support of ordering in async event was last discussed yesterday in >> this thread >> (http://cdi-development-mailing-list.1064426.n5.nabble.com/Update-on-Async-event-doc-td5711176.html) >> I tend to agree with Jozef. It?s more consistent for user to allow >> ordering in async event as in sync. >> >> Antoine >> >> >>> Le 18 mars 2015 ? 11:05, Romain Manni-Bucau >> > a ?crit : >>> >>> >>> 2015-03-18 11:03 GMT+01:00 Antoine >>> Sabot-Durand>> >: >>> >>> >>>> Le 18 mars 2015 ? 10:53, Romain Manni-Bucau >>>> > a ?crit : >>>> >>>> >>>> 2015-03-18 10:33 GMT+01:00 Antoine >>>> Sabot-Durand>>> >: >>>> >>>> >>>>> Le 18 mars 2015 ? 09:58, Romain Manni-Bucau >>>>> > a >>>>> ?crit : >>>>> >>>>> >>>>> 2015-03-18 9:55 GMT+01:00 Antoine >>>>> Sabot-Durand>>>> >: >>>>> >>>>>> >>>>>> Le 18 mars 2015 ? 09:42, Romain Manni-Bucau >>>>>> >>>>> > a ?crit : >>>>>> >>>>>> Hi guys, >>>>>> >>>>>> think Mark is right and a new API (as fireAsync) >>>>>> would be better for users for: >>>>>> - understanding >>>>>> - compatibility (think to custom extensions using >>>>>> this flag) >>>>> >>>>> My point here is to avoid making CDI the EJB next by >>>>> introducing @Async or @Asynchronous annotation in the >>>>> spec. This kind of annotation should be shared by >>>>> other specs and would have a better fit in concurrency >>>>> utilities or commons annotations spec. >>>>> >>>>> >>>>> +1 >>>>> >>>>>> that said if we have @Async methods I think async >>>>>> observers are really useless, isn't it? >>>>> >>>>> @Async is rather useless IMO when you see how easy it >>>>> is do async operation with Java 8. On the other hand >>>>> Async observers are a at a higher level since they are >>>>> called thru the Container and that the fire point must >>>>> know what?s going on at the other side. >>>>> >>>>> >>>>> don't get it, observer can use j8 then to do its stuff >>>>> asynchronously so maybe the feature if finally useless >>>>> assuming you run on j8. >>>> >>>> And how do you make your fire point know that one of its >>>> observer will be asynchronous ? How do you manage event >>>> ordering (as we plan to support it for async event as >>>> well). I think we shouldn?t see the event bus as a standard >>>> method call but something more featured (think about >>>> parameter injection in observer methods or transactional >>>> behavior) >>>> >>>> >>>> then this is not asynchronism and just an observer queue which >>>> is something different IMO. >>> >>> From user pov it?s async : "I fire an event and get the control >>> back right away". The impl will make an observer queue in an >>> other thread, but the user exp is totally different than classic >>> fire(). >>> >>> >>> this is discussable since it is not for 2 observers. If you use >>> async it can be - often - cause of a long processing, if you have 2 >>> long computing methods then you sequentiallize it which breaks the >>> reason why you wanted async, no? >>> >>>>> >>>>> That said saying a method is async is still more elegant >>>>> than firing it in a pool you don't control. >>>> >>>> fireAsync will have a signature allowing you to pass your >>>> own Executor to give you better control on thread pool >>>> >>>> >>>> a default one should be bound to the bm - main case IMO. having >>>> an app executor is not a very nice solution in term of API. >>> >>> Yes it was already discussed, there will be 2 signatures for >>> fireAsync(). >>> >>> >>> >>>>>> >>>>>> >>>>>> >>>>>> Romain Manni-Bucau >>>>>> @rmannibucau | Blog >>>>>> |Github >>>>>> |LinkedIn >>>>>> |Tomitriber >>>>>> >>>>>> >>>>>> 2015-03-18 9:30 GMT+01:00 Arne >>>>>> Limburg>>>>> >: >>>>>> >>>>>> Hi Antoine, >>>>>> >>>>>> The third bullet point in 10.5.1 of the CDI 1.1 >>>>>> spec states that the >>>>>> observer method must be called in the same >>>>>> transaction context as the >>>>>> event.fire(...) if it is no transactional >>>>>> observer (that is >>>>>> TransactionPhase.IN_PROGRESS). >>>>>> If the default behavior would be async, we would >>>>>> have to move the >>>>>> transaction context to another thread. To my best >>>>>> knowledge this would be >>>>>> the only situation in EE where this is the case. >>>>>> >>>>>> Cheers, >>>>>> Arne >>>>>> >>>>>> Am 18.03.15 09:21 schrieb "Antoine Sabot-Durand" >>>>>> unter >>>>>> >>>>> >: >>>>>> >>>>>> >Hi Arne, >>>>>> > >>>>>> >Sorry can you explain why? This value allows >>>>>> observer to be called inside >>>>>> >or outside a transaction. What will be the >>>>>> compatibility issue? >>>>>> > >>>>>> >Antoine >>>>>> > >>>>>> > >>>>>> >> Le 18 mars 2015 ? 09:05, Arne Limburg >>>>>> >>>>> > a >>>>>> >>?crit : >>>>>> >> >>>>>> >> Hi to all, >>>>>> >> >>>>>> >> I think the biggest issue with backward >>>>>> compatibility is, that the >>>>>> >>current >>>>>> >> @Observes annotation by default has >>>>>> TransactionPhase.IN_PROGRESS. >>>>>> >> I think we can?t deal with this, if the >>>>>> default for observers would be >>>>>> >> async. So I think there is no way to specify >>>>>> async as default without >>>>>> >> loosing backward compatibility. >>>>>> >> Any other thoughts? >>>>>> >> >>>>>> >> Cheers, >>>>>> >> Arne >>>>>> >> >>>>>> >> >>>>>> >> Am 18.03.15 08:48 schrieb "Antoine >>>>>> Sabot-Durand" unter >>>>>> >> >>>>> >: >>>>>> >> >>>>>> >>> Hi all, >>>>>> >>> >>>>>> >>> Yesterday we had another meeting to try to >>>>>> find a better solution than >>>>>> >>> explicitly activating async event on >>>>>> observer, without no success. I >>>>>> >>> understand that we should go on on this >>>>>> feature so what I suggest is to >>>>>> >>> have a meeting (an hangout) with people that >>>>>> want to try to find a >>>>>> >>>better >>>>>> >>> solution. If we find something we?ll do a >>>>>> last proposal, and in all >>>>>> >>>case >>>>>> >>> we?ll adopt the woking solution next week for >>>>>> this point. People >>>>>> >>> interested with this please manifest yourself. >>>>>> >>> >>>>>> >>> If we have to go with opt-in (have to >>>>>> explicitly declare an observer >>>>>> >>> supporting async event) we also have to >>>>>> validate the decision to use a >>>>>> >>> member in @Observes (as it was decided >>>>>> before) or go back on that as >>>>>> >>> mMark keep asking by introducing a new >>>>>> annotation to add on the >>>>>> >>>observer >>>>>> >>> (@Async or something similar). As I said when >>>>>> we discussed this point, >>>>>> >>>I >>>>>> >>> prefer the member in @Observes but we may >>>>>> have overlooked issues linked >>>>>> >>> to backward compatibility. >>>>>> >>> A third solution might be to introduce an >>>>>> @ObserveAsync to declare an >>>>>> >>> asynchronous capable observer? >>>>>> >>> >>>>>> >>> I?m waiting for active feedback from you to >>>>>> find the best solution >>>>>> >>>taking >>>>>> >>> ALL aspects (not only the technicals one) >>>>>> into account. >>>>>> >>> >>>>>> >>> Thanks, >>>>>> >>> >>>>>> >>> Antoine >>>>>> >> >>>>>> > >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> cdi-dev mailing list >>>>>> cdi-dev at lists.jboss.org >>>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>> >>>>>> Note that for all code provided on this list, the >>>>>> provider licenses the code under the Apache >>>>>> License, Version 2 >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For >>>>>> all other ideas provided on this list, the >>>>>> provider waives all patent and other intellectual >>>>>> property rights inherent in such information. >>>>>> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses >> the code under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >> ideas provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150319/fdcc7c9c/attachment-0001.html From jose.paumard at gmail.com Thu Mar 19 09:26:56 2015 From: jose.paumard at gmail.com (=?UTF-8?Q?Jos=C3=A9_Paumard?=) Date: Thu, 19 Mar 2015 14:26:56 +0100 Subject: [cdi-dev] On @Observes for async events In-Reply-To: <550ABC7E.6070601@redhat.com> References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> <550ABC7E.6070601@redhat.com> Message-ID: A few points : The current fireAsync() method that has been voted for allows all this : - calling of the observers in one different thread : just call fireAsycn(payload, singleThreadExecutorService) and you're done - calling of the observers "in parallel" (I dont like this way of saying it, since it leads to confusion) is also possible by not passing any ES, or a more than one threaded ES In both cases you can order events in a strict (call the events of priority N, wait for them to return, then call the next priotiry) or relax mode (call the events of priority N, then call the events of next priority without waiting for them to return). There are two kinds of problems that need to be dealt with : - fixing the 1.2 specification that does not say anything about thread / event firing / observation (there's a JIRA for that) - state that you need to guarantee non-race conditions on mutable event payload in the case of concurrent observers, the easiest way (of course not the only one) being : provide immutable payload - context propagation through threads : we really need to work on this point and find a clean way to do this, at least for non TX contexts (since TX cant be accessed concurrently for other reasons). Jos? 2015-03-19 13:09 GMT+01:00 Jozef Hartinger : > > On 03/18/2015 04:14 PM, Pete Muir wrote: > > I think I have misunderstood the async model that is being proposed. We > are proposing that all the observers of an event fired asynchronously are > all run on a single thread? (Not the thread that fires the event, another > thread, but the same thread for each observer). > > No, the current proposal is not that specific at this point do define a > particular architecture. The one you mentioned is one of the possible > options. > > It has certain advantages: > - the caller of fireAsync() does not wait for observers to complete so it > is async for the caller > - observer notification works the same as way as we know today except that > in a different thread > - the common pattern of using mutable event payload on which observers > contribute would work fine - the payload does not need to be thread-safe - > it would be safely published to the notification thread by the CDI > implementation and there are no races between observers > - ordering (if needed) fits well > > Disadvantages > - it does not eliminate the backward-compatibility problem completely > (different thread means different transaction context, CDI contexts and > thread locals) > - observers are not called in parallel > > Another option would be to call the observers in parallel > Advantages: > - the caller of fireAsync() does not wait for observers to complete so it > is async for the caller > - observers are independent of each other > Disadvantages: > - it does not eliminate the backward-compatibility problem completely > (different thread means different transaction context, CDI contexts and > thread locals) > - the payload needs to be thread-safe > - ordering would not work here > - single event firing possibly results in multiple exceptions (tricky for > the caller to handle with CompletionStage API) > > Another option is to combine those two and by default call the observers > in parallel. If for some reason an observer depends on a different observer > (by means of priorities) then the container guarantees that the partial > ordering of observer notification is met. > > Advantages: > - the caller of fireAsync() does not wait for observers to complete so it > is async for the caller > - observers are independent of each other > - priority works the same in sync and async > Disadvantages: > - it does not eliminate the backward-compatibility problem completely > (different thread means different transaction context, CDI contexts and > thread locals) > - the payload needs to be thread-safe > - single event firing possibly results in multiple exceptions (tricky for > the caller to handle with CompletionStage API) > > > > This would be a somewhat odd limitation in my mind. It?s certainly *not* > something that is semantically intuitive if you have something like > @Observes @Asynchronously on event observers, which definitely implies the > event observation is asynchronous, not the event firing. > > In the current proposal, @Observes @Asynchronously is just an enabler (for > backward compatibility) of async event firing. It alone does not mean > anything. > > > I would definitely prefer an asynchronous observation model, which I > can?t see as being remotely compatible with observer ordering. The classic > approach of using callbacks to identify when a method is done is inherently > more powerful, and better understood. > > So basically kind of EJB's @Asynchronous methods applied to observers + a > callback on event.fire()? The downside I can see here is that the > event.fire() caller never knows whether the call will block or not whereas > with event.fireAsync() it would be guaranteed not to block. > > > Perhaps I?ve missed this, but what are the use cases for wanting to > specify that the observation is done async on the observer? And how does > this relate to the event firing methods ability to get a callback? I > suspect you would need to retrofit the entire firing system to always > return a callback if you wanted to allow the observer to control whether it > was async or not. > > On 18 Mar 2015, at 10:11, Antoine Sabot-Durand > wrote: > > Support of ordering in async event was last discussed yesterday in this > thread ( > http://cdi-development-mailing-list.1064426.n5.nabble.com/Update-on-Async-event-doc-td5711176.html > ) > I tend to agree with Jozef. It?s more consistent for user to allow > ordering in async event as in sync. > > Antoine > > > Le 18 mars 2015 ? 11:05, Romain Manni-Bucau a > ?crit : > > > 2015-03-18 11:03 GMT+01:00 Antoine Sabot-Durand > : > >> >> Le 18 mars 2015 ? 10:53, Romain Manni-Bucau a >> ?crit : >> >> >> 2015-03-18 10:33 GMT+01:00 Antoine Sabot-Durand < >> antoine at sabot-durand.net>: >> >>> >>> Le 18 mars 2015 ? 09:58, Romain Manni-Bucau a >>> ?crit : >>> >>> >>> 2015-03-18 9:55 GMT+01:00 Antoine Sabot-Durand < >>> antoine at sabot-durand.net>: >>> >>>> >>>> Le 18 mars 2015 ? 09:42, Romain Manni-Bucau a >>>> ?crit : >>>> >>>> Hi guys, >>>> >>>> think Mark is right and a new API (as fireAsync) would be better for >>>> users for: >>>> - understanding >>>> - compatibility (think to custom extensions using this flag) >>>> >>>> >>>> My point here is to avoid making CDI the EJB next by introducing >>>> @Async or @Asynchronous annotation in the spec. This kind of annotation >>>> should be shared by other specs and would have a better fit in concurrency >>>> utilities or commons annotations spec. >>>> >>>> >>> +1 >>> >>> >>>> that said if we have @Async methods I think async observers are >>>> really useless, isn't it? >>>> >>>> >>>> @Async is rather useless IMO when you see how easy it is do async >>>> operation with Java 8. On the other hand Async observers are a at a higher >>>> level since they are called thru the Container and that the fire point must >>>> know what?s going on at the other side. >>>> >>>> >>> don't get it, observer can use j8 then to do its stuff asynchronously >>> so maybe the feature if finally useless assuming you run on j8. >>> >>> >>> And how do you make your fire point know that one of its observer will >>> be asynchronous ? How do you manage event ordering (as we plan to support >>> it for async event as well). I think we shouldn?t see the event bus as a >>> standard method call but something more featured (think about parameter >>> injection in observer methods or transactional behavior) >>> >>> >> then this is not asynchronism and just an observer queue which is >> something different IMO. >> >> >> From user pov it?s async : "I fire an event and get the control back >> right away". The impl will make an observer queue in an other thread, but >> the user exp is totally different than classic fire(). >> >> > this is discussable since it is not for 2 observers. If you use async it > can be - often - cause of a long processing, if you have 2 long computing > methods then you sequentiallize it which breaks the reason why you wanted > async, no? > >> >> >>> >>> That said saying a method is async is still more elegant than firing >>> it in a pool you don't control. >>> >>> >>> fireAsync will have a signature allowing you to pass your own Executor >>> to give you better control on thread pool >>> >>> >> a default one should be bound to the bm - main case IMO. having an app >> executor is not a very nice solution in term of API. >> >> >> Yes it was already discussed, there will be 2 signatures for >> fireAsync(). >> >> >> >> >>> >>>> >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau | Blog >>>> | Github >>>> | LinkedIn >>>> | Tomitriber >>>> >>>> >>>> 2015-03-18 9:30 GMT+01:00 Arne Limburg : >>>> >>>>> Hi Antoine, >>>>> >>>>> The third bullet point in 10.5.1 of the CDI 1.1 spec states that the >>>>> observer method must be called in the same transaction context as the >>>>> event.fire(...) if it is no transactional observer (that is >>>>> TransactionPhase.IN_PROGRESS). >>>>> If the default behavior would be async, we would have to move the >>>>> transaction context to another thread. To my best knowledge this would >>>>> be >>>>> the only situation in EE where this is the case. >>>>> >>>>> Cheers, >>>>> Arne >>>>> >>>>> Am 18.03.15 09:21 schrieb "Antoine Sabot-Durand" unter >>>>> : >>>>> >>>>> >Hi Arne, >>>>> > >>>>> >Sorry can you explain why? This value allows observer to be called >>>>> inside >>>>> >or outside a transaction. What will be the compatibility issue? >>>>> > >>>>> >Antoine >>>>> > >>>>> > >>>>> >> Le 18 mars 2015 ? 09:05, Arne Limburg < >>>>> arne.limburg at openknowledge.de> a >>>>> >>?crit : >>>>> >> >>>>> >> Hi to all, >>>>> >> >>>>> >> I think the biggest issue with backward compatibility is, that the >>>>> >>current >>>>> >> @Observes annotation by default has TransactionPhase.IN_PROGRESS. >>>>> >> I think we can?t deal with this, if the default for observers would >>>>> be >>>>> >> async. So I think there is no way to specify async as default >>>>> without >>>>> >> loosing backward compatibility. >>>>> >> Any other thoughts? >>>>> >> >>>>> >> Cheers, >>>>> >> Arne >>>>> >> >>>>> >> >>>>> >> Am 18.03.15 08:48 schrieb "Antoine Sabot-Durand" unter >>>>> >> : >>>>> >> >>>>> >>> Hi all, >>>>> >>> >>>>> >>> Yesterday we had another meeting to try to find a better solution >>>>> than >>>>> >>> explicitly activating async event on observer, without no success. >>>>> I >>>>> >>> understand that we should go on on this feature so what I suggest >>>>> is to >>>>> >>> have a meeting (an hangout) with people that want to try to find a >>>>> >>>better >>>>> >>> solution. If we find something we?ll do a last proposal, and in all >>>>> >>>case >>>>> >>> we?ll adopt the woking solution next week for this point. People >>>>> >>> interested with this please manifest yourself. >>>>> >>> >>>>> >>> If we have to go with opt-in (have to explicitly declare an >>>>> observer >>>>> >>> supporting async event) we also have to validate the decision to >>>>> use a >>>>> >>> member in @Observes (as it was decided before) or go back on that >>>>> as >>>>> >>> mMark keep asking by introducing a new annotation to add on the >>>>> >>>observer >>>>> >>> (@Async or something similar). As I said when we discussed this >>>>> point, >>>>> >>>I >>>>> >>> prefer the member in @Observes but we may have overlooked issues >>>>> linked >>>>> >>> to backward compatibility. >>>>> >>> A third solution might be to introduce an @ObserveAsync to declare >>>>> an >>>>> >>> asynchronous capable observer? >>>>> >>> >>>>> >>> I?m waiting for active feedback from you to find the best solution >>>>> >>>taking >>>>> >>> ALL aspects (not only the technicals one) into account. >>>>> >>> >>>>> >>> Thanks, >>>>> >>> >>>>> >>> Antoine >>>>> >> >>>>> > >>>>> >>>>> >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>> Note that for all code provided on this list, the provider licenses >>>>> the code under the Apache License, Version 2 ( >>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>>>> provided on this list, the provider waives all patent and other >>>>> intellectual property rights inherent in such information. >>>>> >>>> > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > > > _______________________________________________ > cdi-dev mailing listcdi-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -- Java le soir Cours Java en ligne Twitter Paris JUG Devoxx France M : +33 6 76 82 91 47 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150319/fb292aa1/attachment-0001.html From antoine at sabot-durand.net Thu Mar 19 10:36:50 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 19 Mar 2015 15:36:50 +0100 Subject: [cdi-dev] What about @AsyncObserves ? Message-ID: <8633DCCC-4951-4D0A-BB5B-0E900633EE9B@sabot-durand.net> Hi guys, So it seems impossible to avoid opt-in on the observer side for the sake of awkward compatibility. Adding a member to @Observes could also be a source of issues when old CDI lib will be used with CDI 2.0 runtime. Some of us (including me) don?t want to add an @Async annotation to CDI spec, so perhaps we should add an async alternative to @Observes with an @AsyncObserves or @ObservesAsync ? So it would be public void myObserver(@AsyncObserves payload) {} instead of @Async public void myObserver(@Observes payload) {} Pros : - it?s a cleaner way to manage the opt-in than to put 2 annotations or add a member to an existing one - it could have new members related to async behavior (context propagation, concurrent scenario, etc?) - As it won?t be in legacy code no risk to see old observers called asynchronously Cons : - Still not clear for users when fire() is called to see @AsyncObserves launched synchronously - Yet another annotation added wdyt ? Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150319/b8761614/attachment.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/20150319/b8761614/attachment.bin From antoine at sabot-durand.net Thu Mar 19 10:38:24 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 19 Mar 2015 07:38:24 -0700 (MST) Subject: [cdi-dev] Choosing a date for next CDI Face to Face meeting In-Reply-To: <5BF5FCD9-FBF2-4A46-AB8F-0335C2618BB8@sabot-durand.net> References: <5BF5FCD9-FBF2-4A46-AB8F-0335C2618BB8@sabot-durand.net> Message-ID: <1426775904740-5711245.post@n5.nabble.com> Don't be shy. If you have concern with the date or other point let me know. -- View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/Choosing-a-date-for-next-CDI-Face-to-Face-meeting-tp5711199p5711245.html Sent from the CDI Development mailing list mailing list archive at Nabble.com. From antoine at sabot-durand.net Thu Mar 19 10:50:15 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 19 Mar 2015 15:50:15 +0100 Subject: [cdi-dev] Early Draft 1 Message-ID: <763D1F6F-17A3-467F-8BB5-70FF2EB22941@sabot-durand.net> Hi All, I talked about it if before but we should really start preparing our Early Draft. I?d like to release it for second half of April and put the big stuff we are working on right now: - Java SE / EE split - Async Events - Java SE support An early draft is not a finished document, new features we?ll add there could be changed later or totally disappear if we?re not happy with it. It?s a great way to show our work to the greater community and have feedback. Certainly a way to get a higher point of view on our recent discussions ;). We?ll take a moment during our next meeting to deal with that coming release. 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/20150319/c3f59040/attachment.bin From rmannibucau at gmail.com Thu Mar 19 10:51:03 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Thu, 19 Mar 2015 15:51:03 +0100 Subject: [cdi-dev] What about @AsyncObserves ? In-Reply-To: <8633DCCC-4951-4D0A-BB5B-0E900633EE9B@sabot-durand.net> References: <8633DCCC-4951-4D0A-BB5B-0E900633EE9B@sabot-durand.net> Message-ID: sounds like a quick and dirty solution to me. @Async will arrive - maybe too early today - but adding @ObservesAsync just cause we dont have yet @Async will make this API obselete pretty quickly isn't it (already cause of EJB actually). Do we really want this feature at this price? If yes *AsyncObserves *sounds an acceptable compromise but still will mess up the API IMO. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-03-19 15:36 GMT+01:00 Antoine Sabot-Durand : > Hi guys, > > > So it seems impossible to avoid opt-in on the observer side for the sake > of awkward compatibility. > Adding a member to @Observes could also be a source of issues when old CDI > lib will be used with CDI 2.0 runtime. Some of us (including me) don?t want > to add an @Async annotation to CDI spec, so perhaps we should add an async > alternative to @Observes with an @AsyncObserves or @ObservesAsync ? > > So it would be > > public void myObserver(*@AsyncObserves* payload) {} > > instead of > > *@Async* > public void myObserver(@Observes payload) {} > > > Pros : > - it?s a cleaner way to manage the opt-in than to put 2 annotations or add > a member to an existing one > - it could have new members related to async behavior (context > propagation, concurrent scenario, etc?) > - As it won?t be in legacy code no risk to see old observers called > asynchronously > > Cons : > - Still not clear for users when fire() is called to see @AsyncObserves > launched synchronously > - Yet another annotation added > > wdyt ? > > Antoine > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150319/2d7fde48/attachment.html From antoine at sabot-durand.net Thu Mar 19 11:44:40 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 19 Mar 2015 16:44:40 +0100 Subject: [cdi-dev] What about @AsyncObserves ? In-Reply-To: References: <8633DCCC-4951-4D0A-BB5B-0E900633EE9B@sabot-durand.net> Message-ID: <473540E5-F3A4-49C1-B85E-D76976502573@sabot-durand.net> > Le 19 mars 2015 ? 15:51, Romain Manni-Bucau a ?crit : > > sounds like a quick and dirty solution to me. @Async will arrive Yes like in ?Async is coming? ;) > - maybe too early today - but adding @ObservesAsync just cause we dont have yet @Async will make this API obselete pretty quickly isn't it (already cause of EJB actually). and if we add an @Async in our spec you think it?s better ? > > Do we really want this feature at this price? #1 requested feature by users. > If yes AsyncObserves sounds an acceptable compromise but still will mess up the API IMO. The question is ?Is it more or less messy than @Async @Observes?" I don?t know? It has pros and cons as I listed... > > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > 2015-03-19 15:36 GMT+01:00 Antoine Sabot-Durand >: > Hi guys, > > > So it seems impossible to avoid opt-in on the observer side for the sake of awkward compatibility. > Adding a member to @Observes could also be a source of issues when old CDI lib will be used with CDI 2.0 runtime. Some of us (including me) don?t want to add an @Async annotation to CDI spec, so perhaps we should add an async alternative to @Observes with an @AsyncObserves or @ObservesAsync ? > > So it would be > > public void myObserver(@AsyncObserves payload) {} > > instead of > > @Async > public void myObserver(@Observes payload) {} > > > Pros : > - it?s a cleaner way to manage the opt-in than to put 2 annotations or add a member to an existing one > - it could have new members related to async behavior (context propagation, concurrent scenario, etc?) > - As it won?t be in legacy code no risk to see old observers called asynchronously > > Cons : > - Still not clear for users when fire() is called to see @AsyncObserves launched synchronously > - Yet another annotation added > > wdyt ? > > Antoine > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150319/cb1b3430/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/20150319/cb1b3430/attachment-0001.bin From jose.paumard at gmail.com Thu Mar 19 11:52:21 2015 From: jose.paumard at gmail.com (=?UTF-8?Q?Jos=C3=A9_Paumard?=) Date: Thu, 19 Mar 2015 16:52:21 +0100 Subject: [cdi-dev] What about @AsyncObserves ? In-Reply-To: <473540E5-F3A4-49C1-B85E-D76976502573@sabot-durand.net> References: <8633DCCC-4951-4D0A-BB5B-0E900633EE9B@sabot-durand.net> <473540E5-F3A4-49C1-B85E-D76976502573@sabot-durand.net> Message-ID: > So it seems impossible to avoid opt-in on the observer side What is the "killer" argument for that ? Jos? 2015-03-19 16:44 GMT+01:00 Antoine Sabot-Durand : > > Le 19 mars 2015 ? 15:51, Romain Manni-Bucau a > ?crit : > > sounds like a quick and dirty solution to me. @Async will arrive > > > Yes like in ?Async is coming? ;) > > - maybe too early today - but adding @ObservesAsync just cause we dont > have yet @Async will make this API obselete pretty quickly isn't it > (already cause of EJB actually). > > > and if we add an @Async in our spec you think it?s better ? > > > Do we really want this feature at this price? > > > #1 requested feature by users. > > If yes *AsyncObserves *sounds an acceptable compromise but still will > mess up the API IMO. > > > The question is ?Is it more or less messy than @Async @Observes?" I don?t > know? It has pros and cons as I listed... > > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2015-03-19 15:36 GMT+01:00 Antoine Sabot-Durand > : > >> Hi guys, >> >> >> So it seems impossible to avoid opt-in on the observer side for the sake >> of awkward compatibility. >> Adding a member to @Observes could also be a source of issues when old >> CDI lib will be used with CDI 2.0 runtime. Some of us (including me) don?t >> want to add an @Async annotation to CDI spec, so perhaps we should add an >> async alternative to @Observes with an @AsyncObserves or @ObservesAsync ? >> >> So it would be >> >> public void myObserver(*@AsyncObserves* payload) {} >> >> instead of >> >> *@Async* >> public void myObserver(@Observes payload) {} >> >> >> Pros : >> - it?s a cleaner way to manage the opt-in than to put 2 annotations or >> add a member to an existing one >> - it could have new members related to async behavior (context >> propagation, concurrent scenario, etc?) >> - As it won?t be in legacy code no risk to see old observers called >> asynchronously >> >> Cons : >> - Still not clear for users when fire() is called to see @AsyncObserves >> launched synchronously >> - Yet another annotation added >> >> wdyt ? >> >> Antoine >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -- Java le soir Cours Java en ligne Twitter Paris JUG Devoxx France M : +33 6 76 82 91 47 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150319/db4f05c6/attachment.html From rmannibucau at gmail.com Thu Mar 19 11:54:38 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Thu, 19 Mar 2015 16:54:38 +0100 Subject: [cdi-dev] What about @AsyncObserves ? In-Reply-To: <473540E5-F3A4-49C1-B85E-D76976502573@sabot-durand.net> References: <8633DCCC-4951-4D0A-BB5B-0E900633EE9B@sabot-durand.net> <473540E5-F3A4-49C1-B85E-D76976502573@sabot-durand.net> Message-ID: 2015-03-19 16:44 GMT+01:00 Antoine Sabot-Durand : > > Le 19 mars 2015 ? 15:51, Romain Manni-Bucau a > ?crit : > > sounds like a quick and dirty solution to me. @Async will arrive > > > Yes like in ?Async is coming? ;) > > - maybe too early today - but adding @ObservesAsync just cause we dont > have yet @Async will make this API obselete pretty quickly isn't it > (already cause of EJB actually). > > > and if we add an @Async in our spec you think it?s better ? > > no we agree > > Do we really want this feature at this price? > > > #1 requested feature by users. > > not a reason to mess up the spec IMO. One of the best feature of EE is its stability, here I think we break this basic rule knowing it which doesn't sound professional from my window. This feature is important but already doable today - I guess all vendors provide a solution so business wise you are not blocked and you can even stay portable with very few code (even no code in EE). Other point is defining a more appropriated API is surely needed interacting with the @async/threading spec. EE concurrency spec has something which could help in context propagation if spec is updated: http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html can be a way to get context propagation but manually this way it is a "use it at your own risk" solution which is the best can do. > If yes *AsyncObserves *sounds an acceptable compromise but still will > mess up the API IMO. > > > The question is ?Is it more or less messy than @Async @Observes?" I don?t > know? It has pros and cons as I listed... > > agree, both are intermediary states probably which is not satisfying. > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2015-03-19 15:36 GMT+01:00 Antoine Sabot-Durand > : > >> Hi guys, >> >> >> So it seems impossible to avoid opt-in on the observer side for the sake >> of awkward compatibility. >> Adding a member to @Observes could also be a source of issues when old >> CDI lib will be used with CDI 2.0 runtime. Some of us (including me) don?t >> want to add an @Async annotation to CDI spec, so perhaps we should add an >> async alternative to @Observes with an @AsyncObserves or @ObservesAsync ? >> >> So it would be >> >> public void myObserver(*@AsyncObserves* payload) {} >> >> instead of >> >> *@Async* >> public void myObserver(@Observes payload) {} >> >> >> Pros : >> - it?s a cleaner way to manage the opt-in than to put 2 annotations or >> add a member to an existing one >> - it could have new members related to async behavior (context >> propagation, concurrent scenario, etc?) >> - As it won?t be in legacy code no risk to see old observers called >> asynchronously >> >> Cons : >> - Still not clear for users when fire() is called to see @AsyncObserves >> launched synchronously >> - Yet another annotation added >> >> wdyt ? >> >> Antoine >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150319/814a7e9a/attachment.html From antoine at sabot-durand.net Thu Mar 19 12:19:49 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 19 Mar 2015 17:19:49 +0100 Subject: [cdi-dev] What about @AsyncObserves ? In-Reply-To: References: <8633DCCC-4951-4D0A-BB5B-0E900633EE9B@sabot-durand.net> <473540E5-F3A4-49C1-B85E-D76976502573@sabot-durand.net> Message-ID: <85C50A1B-9920-42D8-868A-BFBABBC283BC@sabot-durand.net> The killer argument is that nobody succeed to provide a way to prevent opt-in and keep backward compaibility. The problem comes from the fact that producer and consumer can be in different jar compiled with different version of CDI and running on CDI 2.0 preventing using opt-out. If you have the solution without opt-in I?m all ears. > Le 19 mars 2015 ? 16:52, Jos? Paumard a ?crit : > > > So it seems impossible to avoid opt-in on the observer side > What is the "killer" argument for that ? > > Jos? > > 2015-03-19 16:44 GMT+01:00 Antoine Sabot-Durand >: > >> Le 19 mars 2015 ? 15:51, Romain Manni-Bucau > a ?crit : >> >> sounds like a quick and dirty solution to me. @Async will arrive > > Yes like in ?Async is coming? ;) > >> - maybe too early today - but adding @ObservesAsync just cause we dont have yet @Async will make this API obselete pretty quickly isn't it (already cause of EJB actually). > > and if we add an @Async in our spec you think it?s better ? > >> >> Do we really want this feature at this price? > > #1 requested feature by users. > >> If yes AsyncObserves sounds an acceptable compromise but still will mess up the API IMO. > > The question is ?Is it more or less messy than @Async @Observes?" I don?t know? It has pros and cons as I listed... > >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >> 2015-03-19 15:36 GMT+01:00 Antoine Sabot-Durand >: >> Hi guys, >> >> >> So it seems impossible to avoid opt-in on the observer side for the sake of awkward compatibility. >> Adding a member to @Observes could also be a source of issues when old CDI lib will be used with CDI 2.0 runtime. Some of us (including me) don?t want to add an @Async annotation to CDI spec, so perhaps we should add an async alternative to @Observes with an @AsyncObserves or @ObservesAsync ? >> >> So it would be >> >> public void myObserver(@AsyncObserves payload) {} >> >> instead of >> >> @Async >> public void myObserver(@Observes payload) {} >> >> >> Pros : >> - it?s a cleaner way to manage the opt-in than to put 2 annotations or add a member to an existing one >> - it could have new members related to async behavior (context propagation, concurrent scenario, etc?) >> - As it won?t be in legacy code no risk to see old observers called asynchronously >> >> Cons : >> - Still not clear for users when fire() is called to see @AsyncObserves launched synchronously >> - Yet another annotation added >> >> wdyt ? >> >> Antoine >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > > > -- > Java le soir Cours Java en ligne > Twitter Paris JUG Devoxx France > M : +33 6 76 82 91 47 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150319/c26345e5/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/20150319/c26345e5/attachment-0001.bin From jose.paumard at gmail.com Thu Mar 19 13:17:50 2015 From: jose.paumard at gmail.com (=?UTF-8?Q?Jos=C3=A9_Paumard?=) Date: Thu, 19 Mar 2015 18:17:50 +0100 Subject: [cdi-dev] What about @AsyncObserves ? In-Reply-To: <85C50A1B-9920-42D8-868A-BFBABBC283BC@sabot-durand.net> References: <8633DCCC-4951-4D0A-BB5B-0E900633EE9B@sabot-durand.net> <473540E5-F3A4-49C1-B85E-D76976502573@sabot-durand.net> <85C50A1B-9920-42D8-868A-BFBABBC283BC@sabot-durand.net> Message-ID: I see the situation as being : - CDI 1.x : I call event.fireEvent(...), there is an observer that is called. Currently it is called in the same thread. - CDI 2.0 : I call event.fireEvent(...), there is an observer that is called. It will be called in the same thread. So what is the backward compatibility issue here ? From what I understand it just works the same. Jos? 2015-03-19 17:19 GMT+01:00 Antoine Sabot-Durand : > The killer argument is that nobody succeed to provide a way to prevent > opt-in and keep backward compaibility. The problem comes from the fact that > producer and consumer can be in different jar compiled with different > version of CDI and running on CDI 2.0 preventing using opt-out. > If you have the solution without opt-in I?m all ears. > > > Le 19 mars 2015 ? 16:52, Jos? Paumard a ?crit : > > > So it seems impossible to avoid opt-in on the observer side > What is the "killer" argument for that ? > > Jos? > > 2015-03-19 16:44 GMT+01:00 Antoine Sabot-Durand > : > >> >> Le 19 mars 2015 ? 15:51, Romain Manni-Bucau a >> ?crit : >> >> sounds like a quick and dirty solution to me. @Async will arrive >> >> >> Yes like in ?Async is coming? ;) >> >> - maybe too early today - but adding @ObservesAsync just cause we dont >> have yet @Async will make this API obselete pretty quickly isn't it >> (already cause of EJB actually). >> >> >> and if we add an @Async in our spec you think it?s better ? >> >> >> Do we really want this feature at this price? >> >> >> #1 requested feature by users. >> >> If yes *AsyncObserves *sounds an acceptable compromise but still will >> mess up the API IMO. >> >> >> The question is ?Is it more or less messy than @Async @Observes?" I >> don?t know? It has pros and cons as I listed... >> >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> 2015-03-19 15:36 GMT+01:00 Antoine Sabot-Durand > >: >> >>> Hi guys, >>> >>> >>> So it seems impossible to avoid opt-in on the observer side for the sake >>> of awkward compatibility. >>> Adding a member to @Observes could also be a source of issues when old >>> CDI lib will be used with CDI 2.0 runtime. Some of us (including me) don?t >>> want to add an @Async annotation to CDI spec, so perhaps we should add an >>> async alternative to @Observes with an @AsyncObserves or @ObservesAsync ? >>> >>> So it would be >>> >>> public void myObserver(*@AsyncObserves* payload) {} >>> >>> instead of >>> >>> *@Async* >>> public void myObserver(@Observes payload) {} >>> >>> >>> Pros : >>> - it?s a cleaner way to manage the opt-in than to put 2 annotations or >>> add a member to an existing one >>> - it could have new members related to async behavior (context >>> propagation, concurrent scenario, etc?) >>> - As it won?t be in legacy code no risk to see old observers called >>> asynchronously >>> >>> Cons : >>> - Still not clear for users when fire() is called to see @AsyncObserves >>> launched synchronously >>> - Yet another annotation added >>> >>> wdyt ? >>> >>> Antoine >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>> provided on this list, the provider waives all patent and other >>> intellectual property rights inherent in such information. >>> >> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> > > > > -- > Java le soir Cours Java en ligne > > Twitter Paris JUG > Devoxx France > M : +33 6 76 82 91 47 > > > -- Java le soir Cours Java en ligne Twitter Paris JUG Devoxx France M : +33 6 76 82 91 47 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150319/3e53d27e/attachment.html From arjan.tijms at gmail.com Thu Mar 19 14:14:27 2015 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 19 Mar 2015 19:14:27 +0100 Subject: [cdi-dev] On @Observes for async events In-Reply-To: <33DA3D25-45A9-42CD-A74C-F311995D3AFF@yahoo.de> References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> <55096C6B.9080700@redhat.com> <55097111.1090402@redhat.com> <550975DF.2080505@redhat.com> <06185990-67E5-4177-810B-A7C3BD1ABF7B@redhat.com> <68C0CE58-9042-4242-A6F1-00826F6B12C5@sabot-durand.net> <9C3547B9-2C7A-44EB-9C24-119C430CA3A1@redhat.com> <33DA3D25-45A9-42CD-A74C-F311995D3AFF@yahoo.de> Message-ID: Hi On Thursday, March 19, 2015, Mark Struberg wrote: > >> but opposed to ee concurrency utilities > > > > I thought this was by mistake rather than design? > > > > As far as I remember there was a long discussion on the EJB EG and it was > intentionally that @Asynchronous does NOT propagate any information about > the session, security, and don?t even share the same pool instance from > @Stateless (pool ~what we have as @RequestScoped). Slightly off topic perhaps, but @Stateless is difficult to map to a (CDI) scope. Everytime a method is called on a proxy, a different actual bean instance can be used (but it can also be the same bean instance as used for the previous call from the same thread) The concept is actually not that far removed from a message passing paradigm, but using synchronous communication and a typed target. Kind regards, Arjan Tijms > > The reason is that EJB is all about removing concurrency complexity from > the user as good as possible. The other problem is that you don?t have it > under control how long the new thread will run. And the Session might be > looong time dead already. Another issue is with TX handling. The JPA spec > and also JTA spec (TransactionSynchronizationRegistry) defines that a > transaction must not be used ?concurrently?. Means they only must be > assigned to a very single Thread. > > Even with servlet 3.0 async requests you have a ServletRequest only > attached to a very single thread AT EACH TIME (means the thread might > switch, but it?s max 1 at a time). > > > > LieGrue, > strub > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150319/eb53594c/attachment.html From struberg at yahoo.de Thu Mar 19 15:34:40 2015 From: struberg at yahoo.de (Mark Struberg) Date: Thu, 19 Mar 2015 20:34:40 +0100 Subject: [cdi-dev] On @Observes for async events In-Reply-To: References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> <55096C6B.9080700@redhat.com> <55097111.1090402@redhat.com> <550975DF.2080505@redhat.com> <06185990-67E5-4177-810B-A7C3BD1ABF7B@redhat.com> <68C0CE58-9042-4242-A6F1-00826F6B12C5@sabot-durand.net> <9C3547B9-2C7A-44EB-9C24-119C430CA3A1@redhat.com> <33DA3D25-45A9-42CD-A74C-F311995D3AFF@yahoo.de> Message-ID: > Slightly off topic perhaps, but @Stateless is difficult to map to a (CDI) scope. Everytime a method is called on a proxy, a different actual bean instance can be used That is EXACTLY as NormalScoped beans are handled. Just think of @Stateless as a @PoolScoped CDI bean. And then you are almost there? It?s basically @RequestScoped with re-using instances by putting them back into a poll cache (like we had it with JSP tags in the old days). And of course with a few default Interceptors. But that?s really it. LieGrue, strub > Am 19.03.2015 um 19:14 schrieb arjan tijms : > > Hi > > On Thursday, March 19, 2015, Mark Struberg wrote: > >> but opposed to ee concurrency utilities > > > > I thought this was by mistake rather than design? > > > > As far as I remember there was a long discussion on the EJB EG and it was intentionally that @Asynchronous does NOT propagate any information about the session, security, and don?t even share the same pool instance from @Stateless (pool ~what we have as @RequestScoped). > > Slightly off topic perhaps, but @Stateless is difficult to map to a (CDI) scope. Everytime a method is called on a proxy, a different actual bean instance can be used (but it can also be the same bean instance as used for the previous call from the same thread) > > The concept is actually not that far removed from a message passing paradigm, but using synchronous communication and a typed target. > > Kind regards, > Arjan Tijms > > > > The reason is that EJB is all about removing concurrency complexity from the user as good as possible. The other problem is that you don?t have it under control how long the new thread will run. And the Session might be looong time dead already. Another issue is with TX handling. The JPA spec and also JTA spec (TransactionSynchronizationRegistry) defines that a transaction must not be used ?concurrently?. Means they only must be assigned to a very single Thread. > > Even with servlet 3.0 async requests you have a ServletRequest only attached to a very single thread AT EACH TIME (means the thread might switch, but it?s max 1 at a time). > > > > LieGrue, > strub > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From struberg at yahoo.de Thu Mar 19 15:40:20 2015 From: struberg at yahoo.de (Mark Struberg) Date: Thu, 19 Mar 2015 20:40:20 +0100 Subject: [cdi-dev] What about @AsyncObserves ? In-Reply-To: <85C50A1B-9920-42D8-868A-BFBABBC283BC@sabot-durand.net> References: <8633DCCC-4951-4D0A-BB5B-0E900633EE9B@sabot-durand.net> <473540E5-F3A4-49C1-B85E-D76976502573@sabot-durand.net> <85C50A1B-9920-42D8-868A-BFBABBC283BC@sabot-durand.net> Message-ID: +1 to what Antoine said. Would also love a different way but found no better solution so far - and I thought about it for weeks already :( LieGrue, strub > Am 19.03.2015 um 17:19 schrieb Antoine Sabot-Durand : > > The killer argument is that nobody succeed to provide a way to prevent opt-in and keep backward compaibility. The problem comes from the fact that producer and consumer can be in different jar compiled with different version of CDI and running on CDI 2.0 preventing using opt-out. > If you have the solution without opt-in I?m all ears. > > >> Le 19 mars 2015 ? 16:52, Jos? Paumard a ?crit : >> >> > So it seems impossible to avoid opt-in on the observer side >> What is the "killer" argument for that ? >> >> Jos? >> >> 2015-03-19 16:44 GMT+01:00 Antoine Sabot-Durand : >> >>> Le 19 mars 2015 ? 15:51, Romain Manni-Bucau a ?crit : >>> >>> sounds like a quick and dirty solution to me. @Async will arrive >> >> Yes like in ?Async is coming? ;) >> >>> - maybe too early today - but adding @ObservesAsync just cause we dont have yet @Async will make this API obselete pretty quickly isn't it (already cause of EJB actually). >> >> and if we add an @Async in our spec you think it?s better ? >> >>> >>> Do we really want this feature at this price? >> >> #1 requested feature by users. >> >>> If yes AsyncObserves sounds an acceptable compromise but still will mess up the API IMO. >> >> The question is ?Is it more or less messy than @Async @Observes?" I don?t know? It has pros and cons as I listed... >> >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>> >>> 2015-03-19 15:36 GMT+01:00 Antoine Sabot-Durand : >>> Hi guys, >>> >>> >>> So it seems impossible to avoid opt-in on the observer side for the sake of awkward compatibility. >>> Adding a member to @Observes could also be a source of issues when old CDI lib will be used with CDI 2.0 runtime. Some of us (including me) don?t want to add an @Async annotation to CDI spec, so perhaps we should add an async alternative to @Observes with an @AsyncObserves or @ObservesAsync ? >>> >>> So it would be >>> >>> public void myObserver(@AsyncObserves payload) {} >>> >>> instead of >>> >>> @Async >>> public void myObserver(@Observes payload) {} >>> >>> >>> Pros : >>> - it?s a cleaner way to manage the opt-in than to put 2 annotations or add a member to an existing one >>> - it could have new members related to async behavior (context propagation, concurrent scenario, etc?) >>> - As it won?t be in legacy code no risk to see old observers called asynchronously >>> >>> Cons : >>> - Still not clear for users when fire() is called to see @AsyncObserves launched synchronously >>> - Yet another annotation added >>> >>> wdyt ? >>> >>> Antoine >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> >> >> >> -- >> Java le soir Cours Java en ligne >> Twitter Paris JUG Devoxx France >> M : +33 6 76 82 91 47 > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From struberg at yahoo.de Thu Mar 19 15:43:18 2015 From: struberg at yahoo.de (Mark Struberg) Date: Thu, 19 Mar 2015 20:43:18 +0100 Subject: [cdi-dev] What about @AsyncObserves ? In-Reply-To: References: <8633DCCC-4951-4D0A-BB5B-0E900633EE9B@sabot-durand.net> <473540E5-F3A4-49C1-B85E-D76976502573@sabot-durand.net> <85C50A1B-9920-42D8-868A-BFBABBC283BC@sabot-durand.net> Message-ID: <2434F2F5-2903-4339-98A2-14E0C497B512@yahoo.de> Imagine you write some business code and your Observer needs a @RequestScoped LoggedInUser. The event gets fired by some cool library you use. Now this cool library updates to CDI-2.0 and uses fireAsync from now on. But your code still needs the @RequestScoped LoggedInUser on the same thread -> booooom. LieGrue, strub > Am 19.03.2015 um 18:17 schrieb Jos? Paumard : > > I see the situation as being : > - CDI 1.x : I call event.fireEvent(...), there is an observer that is called. Currently it is called in the same thread. > - CDI 2.0 : I call event.fireEvent(...), there is an observer that is called. It will be called in the same thread. > > So what is the backward compatibility issue here ? From what I understand it just works the same. > > Jos? > > > 2015-03-19 17:19 GMT+01:00 Antoine Sabot-Durand : > The killer argument is that nobody succeed to provide a way to prevent opt-in and keep backward compaibility. The problem comes from the fact that producer and consumer can be in different jar compiled with different version of CDI and running on CDI 2.0 preventing using opt-out. > If you have the solution without opt-in I?m all ears. > > >> Le 19 mars 2015 ? 16:52, Jos? Paumard a ?crit : >> >> > So it seems impossible to avoid opt-in on the observer side >> What is the "killer" argument for that ? >> >> Jos? >> >> 2015-03-19 16:44 GMT+01:00 Antoine Sabot-Durand : >> >>> Le 19 mars 2015 ? 15:51, Romain Manni-Bucau a ?crit : >>> >>> sounds like a quick and dirty solution to me. @Async will arrive >> >> Yes like in ?Async is coming? ;) >> >>> - maybe too early today - but adding @ObservesAsync just cause we dont have yet @Async will make this API obselete pretty quickly isn't it (already cause of EJB actually). >> >> and if we add an @Async in our spec you think it?s better ? >> >>> >>> Do we really want this feature at this price? >> >> #1 requested feature by users. >> >>> If yes AsyncObserves sounds an acceptable compromise but still will mess up the API IMO. >> >> The question is ?Is it more or less messy than @Async @Observes?" I don?t know? It has pros and cons as I listed... >> >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>> >>> 2015-03-19 15:36 GMT+01:00 Antoine Sabot-Durand : >>> Hi guys, >>> >>> >>> So it seems impossible to avoid opt-in on the observer side for the sake of awkward compatibility. >>> Adding a member to @Observes could also be a source of issues when old CDI lib will be used with CDI 2.0 runtime. Some of us (including me) don?t want to add an @Async annotation to CDI spec, so perhaps we should add an async alternative to @Observes with an @AsyncObserves or @ObservesAsync ? >>> >>> So it would be >>> >>> public void myObserver(@AsyncObserves payload) {} >>> >>> instead of >>> >>> @Async >>> public void myObserver(@Observes payload) {} >>> >>> >>> Pros : >>> - it?s a cleaner way to manage the opt-in than to put 2 annotations or add a member to an existing one >>> - it could have new members related to async behavior (context propagation, concurrent scenario, etc?) >>> - As it won?t be in legacy code no risk to see old observers called asynchronously >>> >>> Cons : >>> - Still not clear for users when fire() is called to see @AsyncObserves launched synchronously >>> - Yet another annotation added >>> >>> wdyt ? >>> >>> Antoine >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> >> >> >> -- >> Java le soir Cours Java en ligne >> Twitter Paris JUG Devoxx France >> M : +33 6 76 82 91 47 > > > > > -- > Java le soir Cours Java en ligne > Twitter Paris JUG Devoxx France > M : +33 6 76 82 91 47 > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From jens.schumann at openknowledge.de Thu Mar 19 15:52:43 2015 From: jens.schumann at openknowledge.de (Jens Schumann) Date: Thu, 19 Mar 2015 19:52:43 +0000 Subject: [cdi-dev] On @Observes for async events In-Reply-To: References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> <55096C6B.9080700@redhat.com> <55097111.1090402@redhat.com> <550975DF.2080505@redhat.com> <06185990-67E5-4177-810B-A7C3BD1ABF7B@redhat.com> <68C0CE58-9042-4242-A6F1-00826F6B12C5@sabot-durand.net> <9C3547B9-2C7A-44EB-9C24-119C430CA3A1@redhat.com> <33DA3D25-45A9-42CD-A74C-F311995D3AFF@yahoo.de> Message-ID: Mark, Are you sure with that? I agree with you if you look from a implementation point of view. However I believe that most @Stateless EJBs can easily be migrated to @ApplicationScoped. (At least this is what we have been doing in our migration projects until now). Most @Stateless EJBs are implemented thread-safe unless someone violated the Stateless EJB contract;). Jens Am 19/03/15 20:34 schrieb "Mark Struberg" unter : >> Slightly off topic perhaps, but @Stateless is difficult to map to a >>(CDI) scope. Everytime a method is called on a proxy, a different actual >>bean instance can be used > >That is EXACTLY as NormalScoped beans are handled. Just think of >@Stateless as a @PoolScoped CDI bean. And then you are almost there? > >It?s basically @RequestScoped with re-using instances by putting them >back into a poll cache (like we had it with JSP tags in the old days). >And of course with a few default Interceptors. But that?s really it. > >LieGrue, >strub > > >> Am 19.03.2015 um 19:14 schrieb arjan tijms : >> >> Hi >> >> On Thursday, March 19, 2015, Mark Struberg wrote: >> >> but opposed to ee concurrency utilities >> > >> > I thought this was by mistake rather than design? >> >> >> >> As far as I remember there was a long discussion on the EJB EG and it >>was intentionally that @Asynchronous does NOT propagate any information >>about the session, security, and don?t even share the same pool instance >>from @Stateless (pool ~what we have as @RequestScoped). >> >> Slightly off topic perhaps, but @Stateless is difficult to map to a >>(CDI) scope. Everytime a method is called on a proxy, a different actual >>bean instance can be used (but it can also be the same bean instance as >>used for the previous call from the same thread) >> >> The concept is actually not that far removed from a message passing >>paradigm, but using synchronous communication and a typed target. >> >> Kind regards, >> Arjan Tijms >> >> >> >> The reason is that EJB is all about removing concurrency complexity >>from the user as good as possible. The other problem is that you don?t >>have it under control how long the new thread will run. And the Session >>might be looong time dead already. Another issue is with TX handling. >>The JPA spec and also JTA spec (TransactionSynchronizationRegistry) >>defines that a transaction must not be used ?concurrently?. Means they >>only must be assigned to a very single Thread. >> >> Even with servlet 3.0 async requests you have a ServletRequest only >>attached to a very single thread AT EACH TIME (means the thread might >>switch, but it?s max 1 at a time). >> >> >> >> LieGrue, >> strub >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >>code under the Apache License, Version 2 >>(http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>provided on this list, the provider waives all patent and other >>intellectual property rights inherent in such information. > > >_______________________________________________ >cdi-dev mailing list >cdi-dev at lists.jboss.org >https://lists.jboss.org/mailman/listinfo/cdi-dev > >Note that for all code provided on this list, the provider licenses the >code under the Apache License, Version 2 >(http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >provided on this list, the provider waives all patent and other >intellectual property rights inherent in such information. From jens.schumann at openknowledge.de Thu Mar 19 16:04:08 2015 From: jens.schumann at openknowledge.de (Jens Schumann) Date: Thu, 19 Mar 2015 20:04:08 +0000 Subject: [cdi-dev] What about @AsyncObserves ? In-Reply-To: <2434F2F5-2903-4339-98A2-14E0C497B512@yahoo.de> References: <8633DCCC-4951-4D0A-BB5B-0E900633EE9B@sabot-durand.net> <473540E5-F3A4-49C1-B85E-D76976502573@sabot-durand.net> <85C50A1B-9920-42D8-868A-BFBABBC283BC@sabot-durand.net> <2434F2F5-2903-4339-98A2-14E0C497B512@yahoo.de> Message-ID: Is this a spec related backward compatibility issue at all? Sounds like a major contract break on application level. Nothing we (CDI) can do here. Jens Am 19/03/15 20:43 schrieb "Mark Struberg" unter : >Imagine you write some business code and your Observer needs a >@RequestScoped LoggedInUser. >The event gets fired by some cool library you use. > >Now this cool library updates to CDI-2.0 and uses fireAsync from now on. >But your code still needs the @RequestScoped LoggedInUser on the same >thread -> booooom. > >LieGrue, >strub > >> Am 19.03.2015 um 18:17 schrieb Jos? Paumard : >> >> I see the situation as being : >> - CDI 1.x : I call event.fireEvent(...), there is an observer that is >>called. Currently it is called in the same thread. >> - CDI 2.0 : I call event.fireEvent(...), there is an observer that is >>called. It will be called in the same thread. >> >> So what is the backward compatibility issue here ? From what I >>understand it just works the same. >> >> Jos? >> >> >> 2015-03-19 17:19 GMT+01:00 Antoine Sabot-Durand >>: >> The killer argument is that nobody succeed to provide a way to prevent >>opt-in and keep backward compaibility. The problem comes from the fact >>that producer and consumer can be in different jar compiled with >>different version of CDI and running on CDI 2.0 preventing using >>opt-out. >> If you have the solution without opt-in I?m all ears. >> >> >>> Le 19 mars 2015 ? 16:52, Jos? Paumard a ?crit >>>: >>> >>> > So it seems impossible to avoid opt-in on the observer side >>> What is the "killer" argument for that ? >>> >>> Jos? >>> >>> 2015-03-19 16:44 GMT+01:00 Antoine Sabot-Durand >>>: >>> >>>> Le 19 mars 2015 ? 15:51, Romain Manni-Bucau a >>>>?crit : >>>> >>>> sounds like a quick and dirty solution to me. @Async will arrive >>> >>> Yes like in ?Async is coming? ;) >>> >>>> - maybe too early today - but adding @ObservesAsync just cause we >>>>dont have yet @Async will make this API obselete pretty quickly isn't >>>>it (already cause of EJB actually). >>> >>> and if we add an @Async in our spec you think it?s better ? >>> >>>> >>>> Do we really want this feature at this price? >>> >>> #1 requested feature by users. >>> >>>> If yes AsyncObserves sounds an acceptable compromise but still will >>>>mess up the API IMO. >>> >>> The question is ?Is it more or less messy than @Async @Observes?" I >>>don?t know? It has pros and cons as I listed... >>> >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>> >>>> 2015-03-19 15:36 GMT+01:00 Antoine Sabot-Durand >>>>: >>>> Hi guys, >>>> >>>> >>>> So it seems impossible to avoid opt-in on the observer side for the >>>>sake of awkward compatibility. >>>> Adding a member to @Observes could also be a source of issues when >>>>old CDI lib will be used with CDI 2.0 runtime. Some of us (including >>>>me) don?t want to add an @Async annotation to CDI spec, so perhaps we >>>>should add an async alternative to @Observes with an @AsyncObserves or >>>>@ObservesAsync ? >>>> >>>> So it would be >>>> >>>> public void myObserver(@AsyncObserves payload) {} >>>> >>>> instead of >>>> >>>> @Async >>>> public void myObserver(@Observes payload) {} >>>> >>>> >>>> Pros : >>>> - it?s a cleaner way to manage the opt-in than to put 2 annotations >>>>or add a member to an existing one >>>> - it could have new members related to async behavior (context >>>>propagation, concurrent scenario, etc?) >>>> - As it won?t be in legacy code no risk to see old observers called >>>>asynchronously >>>> >>>> Cons : >>>> - Still not clear for users when fire() is called to see >>>>@AsyncObserves launched synchronously >>>> - Yet another annotation added >>>> >>>> wdyt ? >>>> >>>> Antoine >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider licenses >>>>the code under the Apache License, Version 2 >>>>(http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>>>provided on this list, the provider waives all patent and other >>>>intellectual property rights inherent in such information. >>>> >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses >>>the code under the Apache License, Version 2 >>>(http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>>provided on this list, the provider waives all patent and other >>>intellectual property rights inherent in such information. >>> >>> >>> >>> -- >>> Java le soir Cours Java en ligne >>> Twitter Paris JUG Devoxx France >>> M : +33 6 76 82 91 47 >> >> >> >> >> -- >> Java le soir Cours Java en ligne >> Twitter Paris JUG Devoxx France >> M : +33 6 76 82 91 47 >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >>code under the Apache License, Version 2 >>(http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>provided on this list, the provider waives all patent and other >>intellectual property rights inherent in such information. > > >_______________________________________________ >cdi-dev mailing list >cdi-dev at lists.jboss.org >https://lists.jboss.org/mailman/listinfo/cdi-dev > >Note that for all code provided on this list, the provider licenses the >code under the Apache License, Version 2 >(http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >provided on this list, the provider waives all patent and other >intellectual property rights inherent in such information. From arjan.tijms at gmail.com Thu Mar 19 16:39:02 2015 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 19 Mar 2015 21:39:02 +0100 Subject: [cdi-dev] On @Observes for async events In-Reply-To: References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> <55096C6B.9080700@redhat.com> <55097111.1090402@redhat.com> <550975DF.2080505@redhat.com> <06185990-67E5-4177-810B-A7C3BD1ABF7B@redhat.com> <68C0CE58-9042-4242-A6F1-00826F6B12C5@sabot-durand.net> <9C3547B9-2C7A-44EB-9C24-119C430CA3A1@redhat.com> <33DA3D25-45A9-42CD-A74C-F311995D3AFF@yahoo.de> Message-ID: Hi, On Thu, Mar 19, 2015 at 8:34 PM, Mark Struberg wrote: > > Slightly off topic perhaps, but @Stateless is difficult to map to a > (CDI) scope. Everytime a method is called on a proxy, a different actual > bean instance can be used > > That is EXACTLY as NormalScoped beans are handled. With the small complication that @Stateless beans are considered @Dependent in CDI (see https://issues.jboss.org/browse/CDI-414 for a consequence this has). > Just think of @Stateless as a @PoolScoped CDI bean. And then you are > almost there? > It?s basically @RequestScoped with re-using instances by putting them back > into a poll cache (like we had it with JSP tags in the old days). And of > course with a few default Interceptors. But that?s really it. > I don't really agree. @RequestScoped will give you the same bean as long as the same request scope is active for the caller. Every call is guaranteed to go to the same bean. For @Stateless the situation is actually reversed. There is no scope that the caller is in. Every call the caller makes on a bean may go to a difference instance. Conceptually it's like a method call results in a package containing the call details being put on a queue, then a *random* bean is chosen from a pool or created on the spot to process that package. Then when it finishes processing the result is returned to the caller and that random bean is put back into the pool or is immediately destroyed. That's IMHO really nothing like @RequestScoped. With a bit of imagination you could possibly say it's @MethodScoped. This scope is independent of any context of the caller, and it starts as soon as the call is made and it ends when the call exits. Within the context of this single method call the bean instance is guaranteed to be active. @PoolScoped is tempting, but not possible the way the EJB spec is defined now. The reason is simply that there's nothing in the spec that mandates stateless beans to be pooled. EJB Entity Beans if I'm not mistaken had a pooling requirement, but for stateless beans the spec merely hints that those beans *might* be pooled. At any length, @PoolScoped would define the life-time of a bean (when it's constructed and when it's destroyed) indeed, but it would mean nothing for the caller. A caller can't ever be in the scope of the imaginary pool scope for a particular bean. Kind regards, Arjan Tijms > > LieGrue, > strub > > > > Am 19.03.2015 um 19:14 schrieb arjan tijms : > > > > Hi > > > > On Thursday, March 19, 2015, Mark Struberg wrote: > > >> but opposed to ee concurrency utilities > > > > > > I thought this was by mistake rather than design? > > > > > > > > As far as I remember there was a long discussion on the EJB EG and it > was intentionally that @Asynchronous does NOT propagate any information > about the session, security, and don?t even share the same pool instance > from @Stateless (pool ~what we have as @RequestScoped). > > > > Slightly off topic perhaps, but @Stateless is difficult to map to a > (CDI) scope. Everytime a method is called on a proxy, a different actual > bean instance can be used (but it can also be the same bean instance as > used for the previous call from the same thread) > > > > The concept is actually not that far removed from a message passing > paradigm, but using synchronous communication and a typed target. > > > > Kind regards, > > Arjan Tijms > > > > > > > > The reason is that EJB is all about removing concurrency complexity from > the user as good as possible. The other problem is that you don?t have it > under control how long the new thread will run. And the Session might be > looong time dead already. Another issue is with TX handling. The JPA spec > and also JTA spec (TransactionSynchronizationRegistry) defines that a > transaction must not be used ?concurrently?. Means they only must be > assigned to a very single Thread. > > > > Even with servlet 3.0 async requests you have a ServletRequest only > attached to a very single thread AT EACH TIME (means the thread might > switch, but it?s max 1 at a time). > > > > > > > > LieGrue, > > strub > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150319/960b6c48/attachment.html From arjan.tijms at gmail.com Thu Mar 19 16:48:22 2015 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 19 Mar 2015 21:48:22 +0100 Subject: [cdi-dev] On @Observes for async events In-Reply-To: References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> <55096C6B.9080700@redhat.com> <55097111.1090402@redhat.com> <550975DF.2080505@redhat.com> <06185990-67E5-4177-810B-A7C3BD1ABF7B@redhat.com> <68C0CE58-9042-4242-A6F1-00826F6B12C5@sabot-durand.net> <9C3547B9-2C7A-44EB-9C24-119C430CA3A1@redhat.com> <33DA3D25-45A9-42CD-A74C-F311995D3AFF@yahoo.de> Message-ID: Hi, On Thu, Mar 19, 2015 at 8:52 PM, Jens Schumann < jens.schumann at openknowledge.de> wrote: > I agree with you if you look from a implementation point of view. However > I believe that most @Stateless EJBs can easily be migrated to > @ApplicationScoped. (At least this is what we have been doing in our > migration projects until now). > Practically, maybe... it depends. @ApplicationScoped is a different thing too. Everything it contains is shared with all callers, while for @Stateless beans every caller gets its own instance. > Most @Stateless EJBs are implemented thread-safe unless someone violated > the Stateless EJB contract;). > An @Stateless bean does not have to be thread-safe, since the stateless contract guarantees only one thread is ever active in a bean. I explained this into some more detail here: http://en.wikipedia.org/wiki/Enterprise_JavaBeans#Stateless_Session_Beans One pattern of using stateless beans is to inject or instantiate a non-thread safe resource in the @PostConstruct method, and then be assured that only 1 thread ever accesses that resource at the same time without paying for any locking overhead (such as in @Singleton beans). If the resource is heavyweight to create, you would usually depend on stateless beans being pooled, but unfortunately this is a container specific feature. Kind regards, Arjan Tijms > > Jens > > Am 19/03/15 20:34 schrieb "Mark Struberg" unter : > > >> Slightly off topic perhaps, but @Stateless is difficult to map to a > >>(CDI) scope. Everytime a method is called on a proxy, a different actual > >>bean instance can be used > > > >That is EXACTLY as NormalScoped beans are handled. Just think of > >@Stateless as a @PoolScoped CDI bean. And then you are almost there? > > > >It?s basically @RequestScoped with re-using instances by putting them > >back into a poll cache (like we had it with JSP tags in the old days). > >And of course with a few default Interceptors. But that?s really it. > > > >LieGrue, > >strub > > > > > >> Am 19.03.2015 um 19:14 schrieb arjan tijms : > >> > >> Hi > >> > >> On Thursday, March 19, 2015, Mark Struberg wrote: > >> >> but opposed to ee concurrency utilities > >> > > >> > I thought this was by mistake rather than design? > >> > >> > >> > >> As far as I remember there was a long discussion on the EJB EG and it > >>was intentionally that @Asynchronous does NOT propagate any information > >>about the session, security, and don?t even share the same pool instance > >>from @Stateless (pool ~what we have as @RequestScoped). > >> > >> Slightly off topic perhaps, but @Stateless is difficult to map to a > >>(CDI) scope. Everytime a method is called on a proxy, a different actual > >>bean instance can be used (but it can also be the same bean instance as > >>used for the previous call from the same thread) > >> > >> The concept is actually not that far removed from a message passing > >>paradigm, but using synchronous communication and a typed target. > >> > >> Kind regards, > >> Arjan Tijms > >> > >> > >> > >> The reason is that EJB is all about removing concurrency complexity > >>from the user as good as possible. The other problem is that you don?t > >>have it under control how long the new thread will run. And the Session > >>might be looong time dead already. Another issue is with TX handling. > >>The JPA spec and also JTA spec (TransactionSynchronizationRegistry) > >>defines that a transaction must not be used ?concurrently?. Means they > >>only must be assigned to a very single Thread. > >> > >> Even with servlet 3.0 async requests you have a ServletRequest only > >>attached to a very single thread AT EACH TIME (means the thread might > >>switch, but it?s max 1 at a time). > >> > >> > >> > >> LieGrue, > >> strub > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> Note that for all code provided on this list, the provider licenses the > >>code under the Apache License, Version 2 > >>(http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > >>provided on this list, the provider waives all patent and other > >>intellectual property rights inherent in such information. > > > > > >_______________________________________________ > >cdi-dev mailing list > >cdi-dev at lists.jboss.org > >https://lists.jboss.org/mailman/listinfo/cdi-dev > > > >Note that for all code provided on this list, the provider licenses the > >code under the Apache License, Version 2 > >(http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > >provided on this list, the provider waives all patent and other > >intellectual property rights inherent in such information. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150319/75550057/attachment.html From sven.linstaedt at gmail.com Thu Mar 19 17:37:04 2015 From: sven.linstaedt at gmail.com (Sven Linstaedt) Date: Thu, 19 Mar 2015 22:37:04 +0100 Subject: [cdi-dev] What about @AsyncObserves ? In-Reply-To: <85C50A1B-9920-42D8-868A-BFBABBC283BC@sabot-durand.net> References: <8633DCCC-4951-4D0A-BB5B-0E900633EE9B@sabot-durand.net> <473540E5-F3A4-49C1-B85E-D76976502573@sabot-durand.net> <85C50A1B-9920-42D8-868A-BFBABBC283BC@sabot-durand.net> Message-ID: <9E45BC1D-05AD-4F59-8D38-C9BEDFE193D8@gmail.com> Could this opt-in/opt-out problem be defaulted with a new beans.xml version? So older bean archive's observers will be handled synchronously even when the event is triggered asynchronously and the "newer" bean archive's observer will be triggered async, if the caller fired the event async? BR, Sven -- sent by phone > Am 19.03.2015 um 17:19 schrieb Antoine Sabot-Durand : > > The killer argument is that nobody succeed to provide a way to prevent opt-in and keep backward compaibility. The problem comes from the fact that producer and consumer can be in different jar compiled with different version of CDI and running on CDI 2.0 preventing using opt-out. > If you have the solution without opt-in I?m all ears. > > >> Le 19 mars 2015 ? 16:52, Jos? Paumard a ?crit : >> >> > So it seems impossible to avoid opt-in on the observer side >> What is the "killer" argument for that ? >> >> Jos? >> >> 2015-03-19 16:44 GMT+01:00 Antoine Sabot-Durand : >>> >>>> Le 19 mars 2015 ? 15:51, Romain Manni-Bucau a ?crit : >>>> >>>> sounds like a quick and dirty solution to me. @Async will arrive >>> >>> Yes like in ?Async is coming? ;) >>> >>>> - maybe too early today - but adding @ObservesAsync just cause we dont have yet @Async will make this API obselete pretty quickly isn't it (already cause of EJB actually). >>> >>> and if we add an @Async in our spec you think it?s better ? >>> >>>> >>>> Do we really want this feature at this price? >>> >>> #1 requested feature by users. >>> >>>> If yes AsyncObserves sounds an acceptable compromise but still will mess up the API IMO. >>> >>> The question is ?Is it more or less messy than @Async @Observes?" I don?t know? It has pros and cons as I listed... >>> >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>> >>>> 2015-03-19 15:36 GMT+01:00 Antoine Sabot-Durand : >>>>> Hi guys, >>>>> >>>>> >>>>> So it seems impossible to avoid opt-in on the observer side for the sake of awkward compatibility. >>>>> Adding a member to @Observes could also be a source of issues when old CDI lib will be used with CDI 2.0 runtime. Some of us (including me) don?t want to add an @Async annotation to CDI spec, so perhaps we should add an async alternative to @Observes with an @AsyncObserves or @ObservesAsync ? >>>>> >>>>> So it would be >>>>> >>>>> public void myObserver(@AsyncObserves payload) {} >>>>> >>>>> instead of >>>>> >>>>> @Async >>>>> public void myObserver(@Observes payload) {} >>>>> >>>>> >>>>> Pros : >>>>> - it?s a cleaner way to manage the opt-in than to put 2 annotations or add a member to an existing one >>>>> - it could have new members related to async behavior (context propagation, concurrent scenario, etc?) >>>>> - As it won?t be in legacy code no risk to see old observers called asynchronously >>>>> >>>>> Cons : >>>>> - Still not clear for users when fire() is called to see @AsyncObserves launched synchronously >>>>> - Yet another annotation added >>>>> >>>>> wdyt ? >>>>> >>>>> Antoine >>>>> >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> >> >> >> -- >> Java le soir Cours Java en ligne >> Twitter Paris JUG Devoxx France >> M : +33 6 76 82 91 47 > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150319/e200a607/attachment-0001.html From arjan.tijms at gmail.com Thu Mar 19 18:32:19 2015 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 19 Mar 2015 23:32:19 +0100 Subject: [cdi-dev] What about @AsyncObserves ? In-Reply-To: <2434F2F5-2903-4339-98A2-14E0C497B512@yahoo.de> References: <8633DCCC-4951-4D0A-BB5B-0E900633EE9B@sabot-durand.net> <473540E5-F3A4-49C1-B85E-D76976502573@sabot-durand.net> <85C50A1B-9920-42D8-868A-BFBABBC283BC@sabot-durand.net> <2434F2F5-2903-4339-98A2-14E0C497B512@yahoo.de> Message-ID: Hi, On Thu, Mar 19, 2015 at 8:43 PM, Mark Struberg wrote: > Imagine you write some business code and your Observer needs a > @RequestScoped LoggedInUser. > The event gets fired by some cool library you use. > > Now this cool library updates to CDI-2.0 and uses fireAsync from now on. > But your code still needs the @RequestScoped LoggedInUser on the same > thread -> booooom. > You are right that this would indeed break, and that's of course bad. This particular situation might be prevented though by having an @RequestScoped producer for LoggedInUser, that fetches the application specific representation of the user based on the user/caller principal. If the request scope is not propagated to async observers, but the security context is, then the code would keep working and only behind the scenes will cause the producer method to be called again. But that's just for this particular situation. Any dependency on other kinds of request scoped beans would still fail of course. Kind regards, Arjan Tijms > > LieGrue, > strub > > > Am 19.03.2015 um 18:17 schrieb Jos? Paumard : > > > > I see the situation as being : > > - CDI 1.x : I call event.fireEvent(...), there is an observer that is > called. Currently it is called in the same thread. > > - CDI 2.0 : I call event.fireEvent(...), there is an observer that is > called. It will be called in the same thread. > > > > So what is the backward compatibility issue here ? From what I > understand it just works the same. > > > > Jos? > > > > > > 2015-03-19 17:19 GMT+01:00 Antoine Sabot-Durand < > antoine at sabot-durand.net>: > > The killer argument is that nobody succeed to provide a way to prevent > opt-in and keep backward compaibility. The problem comes from the fact that > producer and consumer can be in different jar compiled with different > version of CDI and running on CDI 2.0 preventing using opt-out. > > If you have the solution without opt-in I?m all ears. > > > > > >> Le 19 mars 2015 ? 16:52, Jos? Paumard a ?crit > : > >> > >> > So it seems impossible to avoid opt-in on the observer side > >> What is the "killer" argument for that ? > >> > >> Jos? > >> > >> 2015-03-19 16:44 GMT+01:00 Antoine Sabot-Durand < > antoine at sabot-durand.net>: > >> > >>> Le 19 mars 2015 ? 15:51, Romain Manni-Bucau a > ?crit : > >>> > >>> sounds like a quick and dirty solution to me. @Async will arrive > >> > >> Yes like in ?Async is coming? ;) > >> > >>> - maybe too early today - but adding @ObservesAsync just cause we dont > have yet @Async will make this API obselete pretty quickly isn't it > (already cause of EJB actually). > >> > >> and if we add an @Async in our spec you think it?s better ? > >> > >>> > >>> Do we really want this feature at this price? > >> > >> #1 requested feature by users. > >> > >>> If yes AsyncObserves sounds an acceptable compromise but still will > mess up the API IMO. > >> > >> The question is ?Is it more or less messy than @Async @Observes?" I > don?t know? It has pros and cons as I listed... > >> > >>> > >>> > >>> Romain Manni-Bucau > >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber > >>> > >>> 2015-03-19 15:36 GMT+01:00 Antoine Sabot-Durand < > antoine at sabot-durand.net>: > >>> Hi guys, > >>> > >>> > >>> So it seems impossible to avoid opt-in on the observer side for the > sake of awkward compatibility. > >>> Adding a member to @Observes could also be a source of issues when old > CDI lib will be used with CDI 2.0 runtime. Some of us (including me) don?t > want to add an @Async annotation to CDI spec, so perhaps we should add an > async alternative to @Observes with an @AsyncObserves or @ObservesAsync ? > >>> > >>> So it would be > >>> > >>> public void myObserver(@AsyncObserves payload) {} > >>> > >>> instead of > >>> > >>> @Async > >>> public void myObserver(@Observes payload) {} > >>> > >>> > >>> Pros : > >>> - it?s a cleaner way to manage the opt-in than to put 2 annotations or > add a member to an existing one > >>> - it could have new members related to async behavior (context > propagation, concurrent scenario, etc?) > >>> - As it won?t be in legacy code no risk to see old observers called > asynchronously > >>> > >>> Cons : > >>> - Still not clear for users when fire() is called to see > @AsyncObserves launched synchronously > >>> - Yet another annotation added > >>> > >>> wdyt ? > >>> > >>> Antoine > >>> > >>> _______________________________________________ > >>> cdi-dev mailing list > >>> cdi-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>> > >>> Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > >>> > >> > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > >> > >> > >> > >> -- > >> Java le soir Cours Java en ligne > >> Twitter Paris JUG Devoxx France > >> M : +33 6 76 82 91 47 > > > > > > > > > > -- > > Java le soir Cours Java en ligne > > Twitter Paris JUG Devoxx France > > M : +33 6 76 82 91 47 > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150319/fa89ec2d/attachment.html From struberg at yahoo.de Fri Mar 20 02:55:56 2015 From: struberg at yahoo.de (Mark Struberg) Date: Fri, 20 Mar 2015 07:55:56 +0100 Subject: [cdi-dev] What about @AsyncObserves ? In-Reply-To: References: <8633DCCC-4951-4D0A-BB5B-0E900633EE9B@sabot-durand.net> <473540E5-F3A4-49C1-B85E-D76976502573@sabot-durand.net> <85C50A1B-9920-42D8-868A-BFBABBC283BC@sabot-durand.net> <2434F2F5-2903-4339-98A2-14E0C497B512@yahoo.de> Message-ID: Depends on what we like to achieve with this feature. Imo it?s simple as that: there are cases where the observer MUST get executed on the same thread. There might be @RequestScoped beans, TX and even native ThreadLocals involved. And the sender doesn?t always know. In practice this would mean that you can only use fireAsync if you know ALL your observers. But this totally defeats most of the benefits of an eventing pattern. So people will simply not use fireAsync most of the time (as defensive approach). LieGrue, strub > Am 19.03.2015 um 21:04 schrieb Jens Schumann : > > Is this a spec related backward compatibility issue at all? Sounds like a > major contract break on application level. Nothing we (CDI) can do here. > > Jens > > Am 19/03/15 20:43 schrieb "Mark Struberg" unter : > >> Imagine you write some business code and your Observer needs a >> @RequestScoped LoggedInUser. >> The event gets fired by some cool library you use. >> >> Now this cool library updates to CDI-2.0 and uses fireAsync from now on. >> But your code still needs the @RequestScoped LoggedInUser on the same >> thread -> booooom. >> >> LieGrue, >> strub >> >>> Am 19.03.2015 um 18:17 schrieb Jos? Paumard : >>> >>> I see the situation as being : >>> - CDI 1.x : I call event.fireEvent(...), there is an observer that is >>> called. Currently it is called in the same thread. >>> - CDI 2.0 : I call event.fireEvent(...), there is an observer that is >>> called. It will be called in the same thread. >>> >>> So what is the backward compatibility issue here ? From what I >>> understand it just works the same. >>> >>> Jos? >>> >>> >>> 2015-03-19 17:19 GMT+01:00 Antoine Sabot-Durand >>> : >>> The killer argument is that nobody succeed to provide a way to prevent >>> opt-in and keep backward compaibility. The problem comes from the fact >>> that producer and consumer can be in different jar compiled with >>> different version of CDI and running on CDI 2.0 preventing using >>> opt-out. >>> If you have the solution without opt-in I?m all ears. >>> >>> >>>> Le 19 mars 2015 ? 16:52, Jos? Paumard a ?crit >>>> : >>>> >>>>> So it seems impossible to avoid opt-in on the observer side >>>> What is the "killer" argument for that ? >>>> >>>> Jos? >>>> >>>> 2015-03-19 16:44 GMT+01:00 Antoine Sabot-Durand >>>> : >>>> >>>>> Le 19 mars 2015 ? 15:51, Romain Manni-Bucau a >>>>> ?crit : >>>>> >>>>> sounds like a quick and dirty solution to me. @Async will arrive >>>> >>>> Yes like in ?Async is coming? ;) >>>> >>>>> - maybe too early today - but adding @ObservesAsync just cause we >>>>> dont have yet @Async will make this API obselete pretty quickly isn't >>>>> it (already cause of EJB actually). >>>> >>>> and if we add an @Async in our spec you think it?s better ? >>>> >>>>> >>>>> Do we really want this feature at this price? >>>> >>>> #1 requested feature by users. >>>> >>>>> If yes AsyncObserves sounds an acceptable compromise but still will >>>>> mess up the API IMO. >>>> >>>> The question is ?Is it more or less messy than @Async @Observes?" I >>>> don?t know? It has pros and cons as I listed... >>>> >>>>> >>>>> >>>>> Romain Manni-Bucau >>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>> >>>>> 2015-03-19 15:36 GMT+01:00 Antoine Sabot-Durand >>>>> : >>>>> Hi guys, >>>>> >>>>> >>>>> So it seems impossible to avoid opt-in on the observer side for the >>>>> sake of awkward compatibility. >>>>> Adding a member to @Observes could also be a source of issues when >>>>> old CDI lib will be used with CDI 2.0 runtime. Some of us (including >>>>> me) don?t want to add an @Async annotation to CDI spec, so perhaps we >>>>> should add an async alternative to @Observes with an @AsyncObserves or >>>>> @ObservesAsync ? >>>>> >>>>> So it would be >>>>> >>>>> public void myObserver(@AsyncObserves payload) {} >>>>> >>>>> instead of >>>>> >>>>> @Async >>>>> public void myObserver(@Observes payload) {} >>>>> >>>>> >>>>> Pros : >>>>> - it?s a cleaner way to manage the opt-in than to put 2 annotations >>>>> or add a member to an existing one >>>>> - it could have new members related to async behavior (context >>>>> propagation, concurrent scenario, etc?) >>>>> - As it won?t be in legacy code no risk to see old observers called >>>>> asynchronously >>>>> >>>>> Cons : >>>>> - Still not clear for users when fire() is called to see >>>>> @AsyncObserves launched synchronously >>>>> - Yet another annotation added >>>>> >>>>> wdyt ? >>>>> >>>>> Antoine >>>>> >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>> Note that for all code provided on this list, the provider licenses >>>>> the code under the Apache License, Version 2 >>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>>>> provided on this list, the provider waives all patent and other >>>>> intellectual property rights inherent in such information. >>>>> >>>> >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider licenses >>>> the code under the Apache License, Version 2 >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>>> provided on this list, the provider waives all patent and other >>>> intellectual property rights inherent in such information. >>>> >>>> >>>> >>>> -- >>>> Java le soir Cours Java en ligne >>>> Twitter Paris JUG Devoxx France >>>> M : +33 6 76 82 91 47 >>> >>> >>> >>> >>> -- >>> Java le soir Cours Java en ligne >>> Twitter Paris JUG Devoxx France >>> M : +33 6 76 82 91 47 >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 >>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>> provided on this list, the provider waives all patent and other >>> intellectual property rights inherent in such information. >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. > From struberg at yahoo.de Fri Mar 20 03:31:42 2015 From: struberg at yahoo.de (Mark Struberg) Date: Fri, 20 Mar 2015 08:31:42 +0100 Subject: [cdi-dev] On @Observes for async events In-Reply-To: References: <09C973EA-C150-4B0A-982D-252A7168D4D9@sabot-durand.net> <8B9722C8-2E5F-4295-B335-5BC9BA3EC1F4@sabot-durand.net> <3A171575-6B94-4032-AA9D-3BFD565D33FA@sabot-durand.net> <22F28786-2B38-4068-9860-0E150DBAED25@sabot-durand.net> <823354AD-D32E-465E-8A31-0C0681E3D743@sabot-durand.net> <55096C6B.9080700@redhat.com> <55097111.1090402@redhat.com> <550975DF.2080505@redhat.com> <06185990-67E5-4177-810B-A7C3BD1ABF7B@redhat.com> <68C0CE58-9042-4242-A6F1-00826F6B12C5@sabot-durand.net> <9C3547B9-2C7A-44EB-9C24-119C430CA3A1@redhat.com> <33DA3D25-45A9-42CD-A74C-F311995D3AFF@yahoo.de> Message-ID: <3D221C32-DC3D-4280-8B97-A5E630621F64@yahoo.de> Arjan, answers inside. > I don't really agree. > > @RequestScoped will give you the same bean as long as the same request scope is active for the caller. Every call is guaranteed to go to the same bean. That?s why I wrote ~ (means ?roughly equals?). What I meant by that is that @RequestScoped also gives you the same guarantees regarding concurrency like @Stateless. Means you can be sure that you only get accessed from max 1 Thread at the same time. > For @Stateless the situation is actually reversed. There is no scope that the caller is in. Every call the caller makes on a bean may go to a difference instance. Conceptually it's like a method call results in a package containing the call details being put on a queue, then a *random* bean is chosen from a pool or created on the spot to process that package. Then when it finishes processing the result is returned to the caller and that random bean is put back into the pool or is immediately destroyed. That?s IMHO really nothing like @RequestScoped. > @PoolScoped is tempting, but not possible the way the EJB spec is defined now. The reason is simply that there?s nothing in the spec that mandates stateless beans to be pooled. No, the guarantees are at least like RequestScoped in regards of concurrency. Sometimes even less. Trust me, I know a bit about this as I?ve implemented such containers ;) You are right that it is not mandated by the spec and each EJB container is perfectly free to destroy a @Stateless bean whenever he likes (except in the middle of a method call on it, but not even that is specified). But in practice all EJB containers I do know only destroy them at the end of a request IF they don?t put them back to the pool. The usual lifespan for a @Stateless bean is from 30 mins to 12h (depending on a container and your configuration). Some do not destroy them at all. After a request they just put the instance back to the pool cache. You can easily check this yourself by logging out some info in @PostConstruct and let the app (EAR, WAR) run on various containers. Anyway. The real point is that the NormalScoped CDI proxies DO call Context#get(Bean) for EACH AND EVERY method invocation. So however you like your @Stateless beans to behave we could do it! The real blocker is somewhere totally different. E.g. CDI does not allow final non-private/non-static methods. Nor do we allow public fields. In those cases we say the bean is ?unproxyable?. See CDI spec 3.15. EJB NIV does allow this - or better: it does not explicitly disallow it. With the effect that those method will get called on the proxy instance (which is usually created with sun.misc.Unsafe#allocateInstance and thus have no called nor any field initialized) and NOT on your contextual instance. > At any length, @PoolScoped would define the life-time of a bean (when it?s constructed and when it's destroyed) indeed, but it would mean nothing for the caller. No, the Context implementation of any scope can freely decide IF and WHEN he likes to destroy it?s contextual instances? LieGrue, strub From issues at jboss.org Fri Mar 20 06:15:21 2015 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Fri, 20 Mar 2015 06:15:21 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-518) Clarify boundaries of the ServletContext event In-Reply-To: References: Message-ID: Jozef Hartinger created CDI-518: ----------------------------------- Summary: Clarify boundaries of the ServletContext event Key: CDI-518 URL: https://issues.jboss.org/browse/CDI-518 Project: CDI Specification Issues Issue Type: Clarification Components: Events Reporter: Jozef Hartinger {quote} An event with qualifier @Initialized(ApplicationScoped.class) is fired when the application context is initialized and an event with qualifier @Destroyed(ApplicationScoped.class) is fired when the application is destroyed. The event payload is: ? the ServletContext if the application is a web application deployed to a Servlet container, or Conversation context lifecycle ? any java.lang.Object for other types of application. {quote} Unlike dependency injection, the spec does not define any visibility boundaries for events. It could therefore be implied that in an EAR a web application could observe the ServletContext event for a different web application. This obviously does not seem right and the spec should explicitly define the expected behavior. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Mar 20 06:34:18 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Fri, 20 Mar 2015 06:34:18 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-518) Clarify boundaries of the ServletContext event In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13052104#comment-13052104 ] Mark Struberg commented on CDI-518: ----------------------------------- I don't think we need to change anything. Section "10.3 Observer resolution" defines {quote} An event is delivered to an observer method if: ? The observer method belongs to an enabled bean. {quote} In fact if WAR1 calls BeanManager#resolveObserverMethods then the ObserverMethods from WAR2 must not even get returned. Also see 10.5 "Observer notification" {quote} ? If there is no context active for the scope to which the bean declaring the observer method belongs, then the observer method should not be called. {quote} We can assume that the 'ApplicationContext' of beans from the other webapp (e.g. WAR2) is not active during a request to WAR1. This might be a bit too implicit, but there are already multiple other reasons why observers from WAR2 should not get this event from WAR1. > Clarify boundaries of the ServletContext event > ---------------------------------------------- > > Key: CDI-518 > URL: https://issues.jboss.org/browse/CDI-518 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Jozef Hartinger > > {quote} > An event with qualifier @Initialized(ApplicationScoped.class) is fired when the application > context is initialized and an event with qualifier @Destroyed(ApplicationScoped.class) is fired > when the application is destroyed. The event payload is: > ? the ServletContext if the application is a web application deployed to a Servlet container, or Conversation context lifecycle > ? any java.lang.Object for other types of application. > {quote} > Unlike dependency injection, the spec does not define any visibility boundaries for events. It could therefore be implied that in an EAR a web application could observe the ServletContext event for a different web application. This obviously does not seem right and the spec should explicitly define the expected behavior. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From pmuir at redhat.com Fri Mar 20 06:36:13 2015 From: pmuir at redhat.com (Pete Muir) Date: Fri, 20 Mar 2015 10:36:13 +0000 Subject: [cdi-dev] What about @AsyncObserves ? In-Reply-To: References: <8633DCCC-4951-4D0A-BB5B-0E900633EE9B@sabot-durand.net> <473540E5-F3A4-49C1-B85E-D76976502573@sabot-durand.net> Message-ID: <289CC3BE-08D8-442D-976B-BD05C4E5CAD4@redhat.com> > On 19 Mar 2015, at 15:54, Romain Manni-Bucau wrote: > > > 2015-03-19 16:44 GMT+01:00 Antoine Sabot-Durand >: > >> Le 19 mars 2015 ? 15:51, Romain Manni-Bucau > a ?crit : >> >> sounds like a quick and dirty solution to me. @Async will arrive > > Yes like in ?Async is coming? ;) > >> - maybe too early today - but adding @ObservesAsync just cause we dont have yet @Async will make this API obselete pretty quickly isn't it (already cause of EJB actually). > > and if we add an @Async in our spec you think it?s better ? > > > no we agree >> >> Do we really want this feature at this price? > > #1 requested feature by users. > > > not a reason to mess up the spec IMO. One of the best feature of EE is its stability, here I think we break this basic rule knowing it which doesn't sound professional from my window. > > This feature is important but already doable today - I guess all vendors provide a solution so business wise you are not blocked and you can even stay portable with very few code (even no code in EE). > > Other point is defining a more appropriated API is surely needed interacting with the @async/threading spec. EE concurrency spec has something which could help in context propagation if spec is updated: http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextService.html > > can be a way to get context propagation but manually this way it is a "use it at your own risk" solution which is the best can do. I agree, we shouldn?t deliver this as currently proposed. What about adding SPI hooks to the core, so that e.g. DeltaSpike could implement something over the top that allows the nice programming model. We can then adopt in to the spec in 2.1? > >> If yes AsyncObserves sounds an acceptable compromise but still will mess up the API IMO. > > The question is ?Is it more or less messy than @Async @Observes?" I don?t know? It has pros and cons as I listed... > > > agree, both are intermediary states probably which is not satisfying. >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >> 2015-03-19 15:36 GMT+01:00 Antoine Sabot-Durand >: >> Hi guys, >> >> >> So it seems impossible to avoid opt-in on the observer side for the sake of awkward compatibility. >> Adding a member to @Observes could also be a source of issues when old CDI lib will be used with CDI 2.0 runtime. Some of us (including me) don?t want to add an @Async annotation to CDI spec, so perhaps we should add an async alternative to @Observes with an @AsyncObserves or @ObservesAsync ? >> >> So it would be >> >> public void myObserver(@AsyncObserves payload) {} >> >> instead of >> >> @Async >> public void myObserver(@Observes payload) {} >> >> >> Pros : >> - it?s a cleaner way to manage the opt-in than to put 2 annotations or add a member to an existing one >> - it could have new members related to async behavior (context propagation, concurrent scenario, etc?) >> - As it won?t be in legacy code no risk to see old observers called asynchronously >> >> Cons : >> - Still not clear for users when fire() is called to see @AsyncObserves launched synchronously >> - Yet another annotation added >> >> wdyt ? >> >> Antoine >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150320/426061e8/attachment.html From issues at jboss.org Fri Mar 20 06:43:18 2015 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Fri, 20 Mar 2015 06:43:18 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-518) Clarify boundaries of the ServletContext event In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13052108#comment-13052108 ] Jozef Hartinger commented on CDI-518: ------------------------------------- {quote}In fact if WAR1 calls BeanManager#resolveObserverMethods then the ObserverMethods from WAR2 must not even get returned.{quote} Based on what? Your conclusion is reasonable but the spec does not say so. Therefore, I raised this clarification issue. > Clarify boundaries of the ServletContext event > ---------------------------------------------- > > Key: CDI-518 > URL: https://issues.jboss.org/browse/CDI-518 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Jozef Hartinger > > {quote} > An event with qualifier @Initialized(ApplicationScoped.class) is fired when the application > context is initialized and an event with qualifier @Destroyed(ApplicationScoped.class) is fired > when the application is destroyed. The event payload is: > ? the ServletContext if the application is a web application deployed to a Servlet container, or Conversation context lifecycle > ? any java.lang.Object for other types of application. > {quote} > Unlike dependency injection, the spec does not define any visibility boundaries for events. It could therefore be implied that in an EAR a web application could observe the ServletContext event for a different web application. This obviously does not seem right and the spec should explicitly define the expected behavior. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Mar 20 08:21:18 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Fri, 20 Mar 2015 08:21:18 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-518) Clarify boundaries of the ServletContext event In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13052147#comment-13052147 ] Mark Struberg commented on CDI-518: ----------------------------------- The JavaEE umbrella spec says so in the isolation chapter. They are not referring to Bean of course, but class visibility. But it essentially boils down to the same. > Clarify boundaries of the ServletContext event > ---------------------------------------------- > > Key: CDI-518 > URL: https://issues.jboss.org/browse/CDI-518 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Jozef Hartinger > > {quote} > An event with qualifier @Initialized(ApplicationScoped.class) is fired when the application > context is initialized and an event with qualifier @Destroyed(ApplicationScoped.class) is fired > when the application is destroyed. The event payload is: > ? the ServletContext if the application is a web application deployed to a Servlet container, or Conversation context lifecycle > ? any java.lang.Object for other types of application. > {quote} > Unlike dependency injection, the spec does not define any visibility boundaries for events. It could therefore be implied that in an EAR a web application could observe the ServletContext event for a different web application. This obviously does not seem right and the spec should explicitly define the expected behavior. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Mar 20 08:34:18 2015 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Fri, 20 Mar 2015 08:34:18 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-518) Clarify boundaries of the ServletContext event In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13052155#comment-13052155 ] Jozef Hartinger commented on CDI-518: ------------------------------------- Do you mean "8.3 Class Loading Requirements"? If so then don't forget that ServletContext is not an application class. Therefore, this needs to be defined explicitly. > Clarify boundaries of the ServletContext event > ---------------------------------------------- > > Key: CDI-518 > URL: https://issues.jboss.org/browse/CDI-518 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Jozef Hartinger > > {quote} > An event with qualifier @Initialized(ApplicationScoped.class) is fired when the application > context is initialized and an event with qualifier @Destroyed(ApplicationScoped.class) is fired > when the application is destroyed. The event payload is: > ? the ServletContext if the application is a web application deployed to a Servlet container, or Conversation context lifecycle > ? any java.lang.Object for other types of application. > {quote} > Unlike dependency injection, the spec does not define any visibility boundaries for events. It could therefore be implied that in an EAR a web application could observe the ServletContext event for a different web application. This obviously does not seem right and the spec should explicitly define the expected behavior. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Mar 20 08:39:18 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Fri, 20 Mar 2015 08:39:18 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-518) Clarify boundaries of the ServletContext event In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13052157#comment-13052157 ] Mark Struberg commented on CDI-518: ----------------------------------- Oki, getting tricky now. I think we should take a step back and finally do our homework regarding EAR handling. * What classes are seen where. * How do we handle/deal with isolation and visibility constraints of CDI running in EARs. * How does Extension visibility look like * Which classes should get delivered to which Extension * getBeans in EARs * @Named in EARs (thats a TOTAL mess right now) * getInterceptors, decorators etc in EARs ... After that the observer resolution will solve itself pretty quickly. > Clarify boundaries of the ServletContext event > ---------------------------------------------- > > Key: CDI-518 > URL: https://issues.jboss.org/browse/CDI-518 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Jozef Hartinger > > {quote} > An event with qualifier @Initialized(ApplicationScoped.class) is fired when the application > context is initialized and an event with qualifier @Destroyed(ApplicationScoped.class) is fired > when the application is destroyed. The event payload is: > ? the ServletContext if the application is a web application deployed to a Servlet container, or Conversation context lifecycle > ? any java.lang.Object for other types of application. > {quote} > Unlike dependency injection, the spec does not define any visibility boundaries for events. It could therefore be implied that in an EAR a web application could observe the ServletContext event for a different web application. This obviously does not seem right and the spec should explicitly define the expected behavior. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From antoine at sabot-durand.net Fri Mar 20 10:59:22 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 20 Mar 2015 15:59:22 +0100 Subject: [cdi-dev] What about @AsyncObserves ? In-Reply-To: <9E45BC1D-05AD-4F59-8D38-C9BEDFE193D8@gmail.com> References: <8633DCCC-4951-4D0A-BB5B-0E900633EE9B@sabot-durand.net> <473540E5-F3A4-49C1-B85E-D76976502573@sabot-durand.net> <85C50A1B-9920-42D8-868A-BFBABBC283BC@sabot-durand.net> <9E45BC1D-05AD-4F59-8D38-C9BEDFE193D8@gmail.com> Message-ID: <62D98F58-4F4D-4662-83FC-E44B991C79E9@sabot-durand.net> Hi Sven, We could figure something like that. During last meeting I proposed this (extracted from the log) 17:42:51 could we imagine something based on bean archive version <>17:43:27 the question of the contexts should be treated separately imho <>17:44:15 having async behavior as I proposed only if bean archive are explicitly stated at version 2.x ? <>17:44:33 that would eliminate implicit bean archives <>17:44:52 yes I know jharting <>17:44:57 :-( <>17:45:53 imagine you have this AsyncSupported member <>17:45:58 with an enum value <>17:46:15 auto,true,false <>17:46:23 default value is at auto <>17:46:47 if you explictly says that your BA is version 2.0 <>17:46:49 auto is like true <>17:46:57 if not it's like false <>17:47:04 and you'll have to opt-in <>17:48:00 I see you frowning accros the connection jharting ;) <>17:48:51 so for implicit BA you'll have to opt-in <>17:49:48 for explicit BA with version 2.0 you'll have nothing to do to have async (you can still opt-in) <>17:50:02 and can opt-out for a given observer <>17:50:32 I'm not sure about the user friendness of this solution ;) <>17:51:07 it's pretty complicated <>17:51:15 I was just wondering how to explain the different behaviour based on some version number :D <>17:51:35 I agree On the paper that could be a good solution, but implicit bean archive add too much complexity here. The only solution would have an easy way to know if a bean archive was compiled with CDI 2.0 API? Having a specific annotation for Async Observer is probably a more standard solution... > Le 19 mars 2015 ? 22:37, Sven Linstaedt a ?crit : > > Could this opt-in/opt-out problem be defaulted with a new beans.xml version? So older bean archive's observers will be handled synchronously even when the event is triggered asynchronously and the "newer" bean archive's observer will be triggered async, if the caller fired the event async? > > BR, Sven > > -- sent by phone > > Am 19.03.2015 um 17:19 schrieb Antoine Sabot-Durand >: > >> The killer argument is that nobody succeed to provide a way to prevent opt-in and keep backward compaibility. The problem comes from the fact that producer and consumer can be in different jar compiled with different version of CDI and running on CDI 2.0 preventing using opt-out. >> If you have the solution without opt-in I?m all ears. >> >> >>> Le 19 mars 2015 ? 16:52, Jos? Paumard > a ?crit : >>> >>> > So it seems impossible to avoid opt-in on the observer side >>> What is the "killer" argument for that ? >>> >>> Jos? >>> >>> 2015-03-19 16:44 GMT+01:00 Antoine Sabot-Durand >: >>> >>>> Le 19 mars 2015 ? 15:51, Romain Manni-Bucau > a ?crit : >>>> >>>> sounds like a quick and dirty solution to me. @Async will arrive >>> >>> Yes like in ?Async is coming? ;) >>> >>>> - maybe too early today - but adding @ObservesAsync just cause we dont have yet @Async will make this API obselete pretty quickly isn't it (already cause of EJB actually). >>> >>> and if we add an @Async in our spec you think it?s better ? >>> >>>> >>>> Do we really want this feature at this price? >>> >>> #1 requested feature by users. >>> >>>> If yes AsyncObserves sounds an acceptable compromise but still will mess up the API IMO. >>> >>> The question is ?Is it more or less messy than @Async @Observes?" I don?t know? It has pros and cons as I listed... >>> >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>> 2015-03-19 15:36 GMT+01:00 Antoine Sabot-Durand >: >>>> Hi guys, >>>> >>>> >>>> So it seems impossible to avoid opt-in on the observer side for the sake of awkward compatibility. >>>> Adding a member to @Observes could also be a source of issues when old CDI lib will be used with CDI 2.0 runtime. Some of us (including me) don?t want to add an @Async annotation to CDI spec, so perhaps we should add an async alternative to @Observes with an @AsyncObserves or @ObservesAsync ? >>>> >>>> So it would be >>>> >>>> public void myObserver(@AsyncObserves payload) {} >>>> >>>> instead of >>>> >>>> @Async >>>> public void myObserver(@Observes payload) {} >>>> >>>> >>>> Pros : >>>> - it?s a cleaner way to manage the opt-in than to put 2 annotations or add a member to an existing one >>>> - it could have new members related to async behavior (context propagation, concurrent scenario, etc?) >>>> - As it won?t be in legacy code no risk to see old observers called asynchronously >>>> >>>> Cons : >>>> - Still not clear for users when fire() is called to see @AsyncObserves launched synchronously >>>> - Yet another annotation added >>>> >>>> wdyt ? >>>> >>>> Antoine >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>>> >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>> >>> >>> >>> -- >>> Java le soir Cours Java en ligne >>> Twitter Paris JUG Devoxx France >>> M : +33 6 76 82 91 47 >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150320/d2c75dc7/attachment-0001.html From thjanssen123 at gmail.com Mon Mar 23 10:29:34 2015 From: thjanssen123 at gmail.com (Thorben Janssen) Date: Mon, 23 Mar 2015 15:29:34 +0100 Subject: [cdi-dev] JavaLand Message-ID: <55102405.6357b40a.691a.6738@mx.google.com> Hi, I know I'm asking a little bit late, but is anyone else attending the JavaLand conference this week? Would be nice to meet some of you in person. You can find me at the J-Pardy quiz tomorrow evening or send me a message to arrange a meeting. Regards, Thorben PS: I will miss the weekly meeting tomorrow :( -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150323/c3447b58/attachment.html From struberg at yahoo.de Mon Mar 23 13:12:17 2015 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 23 Mar 2015 18:12:17 +0100 Subject: [cdi-dev] JavaLand In-Reply-To: <55102405.6357b40a.691a.6738@mx.google.com> References: <55102405.6357b40a.691a.6738@mx.google.com> Message-ID: just arrived. :) LieGrue, strub > Am 23.03.2015 um 15:29 schrieb Thorben Janssen : > > Hi, > > I know I'm asking a little bit late, but is anyone else attending the JavaLand conference this week? > Would be nice to meet some of you in person. You can find me at the J-Pardy quiz tomorrow evening or send me a message to arrange a meeting. > > Regards, > Thorben > > PS: I will miss the weekly meeting tomorrow :( > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From antoine at sabot-durand.net Tue Mar 24 05:20:02 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 24 Mar 2015 10:20:02 +0100 Subject: [cdi-dev] Today's meeting --> Focus on Java SE Message-ID: <420E8FF1-1AD3-4A91-96CC-D68DE7F04708@sabot-durand.net> Hi all, We have John and Jozef proposal to discuss in https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing and https://issues.jboss.org/browse/CDI-26 The main questions are : - Do we eventually introduce new API as Jozef proposed ? - Is parallel container instances a nice to have feature ? - Are we sure we don?t expose hook for service (like JTA) to standardize integration of these ? - Do we want to propose Servlet integration as well in the spec ? - Are this choice not preventing a future context control API ? That?s the points I?d like to deal with. If you have others, please let me know. If we have spare time we?ll deal with Early Draft release and Async Events. Regards, Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150324/625045fd/attachment.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/20150324/625045fd/attachment.bin From john.d.ament at gmail.com Tue Mar 24 14:00:00 2015 From: john.d.ament at gmail.com (John D. Ament) Date: Tue, 24 Mar 2015 18:00:00 +0000 Subject: [cdi-dev] Shutting down CDI Instances Message-ID: All, In discussion today w/ Jozef, we found that the way of shutting down a container in the proposed SE API precluded the notion that multiple containers could be running. While we're not necessarily going to handle multiple containers right now, we don't want to preclude the idea either. With that said, there were three different approaches though up to handle how to shutdown a launched container. it obivously would only work with an SE booted container, but part of this does give a pointer in how we may implement initialize. Option 1 - Subclass CDI. The returned CDI instance when bootstrapped would return this subclass of CDI that has shutdown capability. Option 2 - Add method to CDI. Add the shutdown method to CDI directly, and throw an exception if called in an EE environment. Option 3 - Return a different object all together when initializing. Return something else from initialize, e.g. CDIContext, which has a shutdown method when you initialize. That class would also have a getter for the CDI instance backing it. Let us know your thoughts. Thanks, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150324/096f96d5/attachment.html From jose.paumard at gmail.com Tue Mar 24 15:59:10 2015 From: jose.paumard at gmail.com (=?UTF-8?Q?Jos=C3=A9_Paumard?=) Date: Tue, 24 Mar 2015 20:59:10 +0100 Subject: [cdi-dev] Some more thoughts on async events Message-ID: Hi all, We had many discussions on this very hot topic. We really need to come with a good pattern, since a lot of people are expecting async features in CDI 2.0. So far, we have a fireAsync(...) on the firing side and an opt-in element on the observer side, to prevent accidental async call of an observer that needs to be called in the context of a transaction (for instance). Having to add this opt-in element on all our legacy observers will be very tedious, so we need to come with a better pattern here. We could add some information in the beans.xml, that would affect all the observers of the bean archive. Something that would tell "this bean archive globally supports asynchronous calls", that would act as a global opt-in. Then we also need a mean to opt-out observers one by one, because we'll have to deal with exceptions to this global rule. Of course it could be done in the other way round: a global opt-out (bean archive-wise) and individual opt-ins. If there is no beans.xml, or a beans.xml without this information, the default behavior would be "asynch is not supported" for backward compatibility reasons. This individual opt-in / opt-out then becomes an override to a global rule set in the beans.xml, or defaulted to "async not supported". It can be expressed in the beans.xml itself, or with annotations on the observers. To deal with the potential incompatibility of adding an attribute to the existing @Observes annotation, we could propose a new annotation, something like @AsyncSupported(true) for instance. Jos? -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150324/a1cc90c8/attachment.html From struberg at yahoo.de Tue Mar 24 18:16:47 2015 From: struberg at yahoo.de (Mark Struberg) Date: Tue, 24 Mar 2015 23:16:47 +0100 Subject: [cdi-dev] Some more thoughts on async events In-Reply-To: References: Message-ID: <3DE9AAD8-DBD1-4492-BD7F-696FC8FFDA49@yahoo.de> > Am 24.03.2015 um 20:59 schrieb Jos? Paumard : > > Having to add this opt-in element on all our legacy observers will be very tedious, so we need to come with a better pattern here. I don?t get you. The opt-in is EXACTLY what is needed for legacy observers. Or do you like to change the behaviour of all the 10000 observers out there in HUGE projects? This is way too critical to change it implicitly. I sadly still have seen way too much projects with barely a test coverage. And those projects will likely blow up if we switch all Observers to async by default? Also note that often you cannot even re-compile libs which use observers. So you just cannot just add anything. > We could add some information in the beans.xml, that would affect all the observers of the bean archive. NO WAY! This BDA stuff is already considered a.) legacy and there was a good reason why @Priority for Alternatives, Interceptors and Decorators got introduced to get rid of it - and b.) badly specced (section 5 and 12 have a different definition of BDA). What we really need btw need some new method on the ProcessObserverMethod to switch async on/off. LieGrue, strub From antoine at sabot-durand.net Wed Mar 25 02:13:53 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 25 Mar 2015 07:13:53 +0100 Subject: [cdi-dev] Some more thoughts on async events In-Reply-To: <3DE9AAD8-DBD1-4492-BD7F-696FC8FFDA49@yahoo.de> References: <3DE9AAD8-DBD1-4492-BD7F-696FC8FFDA49@yahoo.de> Message-ID: <27C28D2F-66EB-41BB-8CCF-43905ECEA85B@sabot-durand.net> > Le 24 mars 2015 ? 23:16, Mark Struberg a ?crit : > > > >> Am 24.03.2015 um 20:59 schrieb Jos? Paumard : >> >> Having to add this opt-in element on all our legacy observers will be very tedious, so we need to come with a better pattern here. > > > I don?t get you. The opt-in is EXACTLY what is needed for legacy observers. Or do you like to change the behaviour of all the 10000 observers out there in HUGE projects? This is way too critical to change it implicitly. > I sadly still have seen way too much projects with barely a test coverage. And those projects will likely blow up if we switch all Observers to async by default? > > Also note that often you cannot even re-compile libs which use observers. So you just cannot just add anything. > I think we can think about a way to ease the life of the 90 % user that will want to use async event in their project and will find quite boring to activate it at both ends. We could figure something that add to the proposed feature not, a new feature. If a user know that the majority of observers in his project support async, wouldn?t it be nice to have a way to tell it once and deactivate the few that don?t support it ? That?s what I understand from Jos? proposal. To make short : have async deactivated by default and having two way to activate it : on each observer or once in the current archive. And when it?s activate for all observer in the archive give a way to deactivate it on observer basis. > >> We could add some information in the beans.xml, that would affect all the observers of the bean archive. > > NO WAY! Mark, we are on a community ML. People are here to make proposal and brainstorm ideas. So please let people express their ideas and give YOUR disagreement in a polite and non-agressive way. Your objection content will probably be more read. > This BDA stuff is already considered a.) legacy Says who? Where it?s written in the spec that BDA are legacy? All the bean discovery mechanism is based on BDA. The notion won?t go anywhere soon. It should be better defined in the spec since it?s part of basic mechanism. What about alternatives activation by config (no recompilation) and class filtering for bean discovery? Legacy as well? You cannot explain that observers cannot be async by default with the good example of an application having jar (BDA) compiled with different CDI version and when someone start thinking about a solution based on configuration in BDA explain him that it?s legacy. > and there was a good reason why @Priority for Alternatives, Interceptors and Decorators got introduced to get rid of it Yes because it was limitative to have them activated for only one BDA and don?t have a way to activate them for the whole application. > - and b.) badly specced (section 5 and 12 have a different definition of BDA). Yes, but since when a concept needing clarification has to be declared legacy? > > What we really need btw need some new method on the ProcessObserverMethod to switch async on/off. And how will you know that your observer is not part of a BDA compiled in CDI 1.x? The question is: will it be useful to allow user to activate by configuration (beans.xml or config annotation / class) asyncSupported by default for all their observer they design in their CDI 2.0 application? Anybody having the end user interest in mind will try to examine this question and only answer ?no? if it brings more complexity for end user. Because we?re not writing this spec for us but for end users. 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/20150325/93d5946d/attachment-0001.bin From rmannibucau at gmail.com Wed Mar 25 03:55:48 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 25 Mar 2015 08:55:48 +0100 Subject: [cdi-dev] Some more thoughts on async events In-Reply-To: <27C28D2F-66EB-41BB-8CCF-43905ECEA85B@sabot-durand.net> References: <3DE9AAD8-DBD1-4492-BD7F-696FC8FFDA49@yahoo.de> <27C28D2F-66EB-41BB-8CCF-43905ECEA85B@sabot-durand.net> Message-ID: Hi guys, thinking to it I think double activation whatever it is would be a failure. As you said Antoine keep the user eyes. Do you want to activate it twice? I udnerstand the concern but really think - whatever technical reason behind - that as a user this is an API failure. However I wonder if we just didn't overlooked the issue and can't just say that async is not yet used so we can consider fired payloads will be different (let say to be immutable for instance) so there is surely no conflict in most cases (ie observers can be supposed supporting it in all cases). If not we can detect it and fail. Most of the time observer chain was compared to filter chain but actually filter chain is closer to interceptor chain but not observer one. In other words if we want to do something - hopefully we'll not since it would break most of usages IMO - we should validate all interceptors of all observers. Why is it different. Cause interceptors are synchonous wrapping inheriting from a context when observers are by design "unknown" from the sender getting their data from a message. The fact the sender doesn't care about observers (but just their effects on its enclosing method - execution duration) makes this double activation a pain whereever it is. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-03-25 7:13 GMT+01:00 Antoine Sabot-Durand : > > > Le 24 mars 2015 ? 23:16, Mark Struberg a ?crit : > > > > > > > >> Am 24.03.2015 um 20:59 schrieb Jos? Paumard : > >> > >> Having to add this opt-in element on all our legacy observers will be > very tedious, so we need to come with a better pattern here. > > > > > > I don?t get you. The opt-in is EXACTLY what is needed for legacy > observers. Or do you like to change the behaviour of all the 10000 > observers out there in HUGE projects? This is way too critical to change it > implicitly. > > I sadly still have seen way too much projects with barely a test > coverage. And those projects will likely blow up if we switch all Observers > to async by default? > > > > Also note that often you cannot even re-compile libs which use > observers. So you just cannot just add anything. > > > > I think we can think about a way to ease the life of the 90 % user that > will want to use async event in their project and will find quite boring to > activate it at both ends. We could figure something that add to the > proposed feature not, a new feature. If a user know that the majority of > observers in his project support async, wouldn?t it be nice to have a way > to tell it once and deactivate the few that don?t support it ? That?s what > I understand from Jos? proposal. > > To make short : have async deactivated by default and having two way to > activate it : on each observer or once in the current archive. And when > it?s activate for all observer in the archive give a way to deactivate it > on observer basis. > > > > > >> We could add some information in the beans.xml, that would affect all > the observers of the bean archive. > > > > NO WAY! > > Mark, we are on a community ML. People are here to make proposal and > brainstorm ideas. So please let people express their ideas and give YOUR > disagreement in a polite and non-agressive way. Your objection content will > probably be more read. > > > This BDA stuff is already considered a.) legacy > > Says who? Where it?s written in the spec that BDA are legacy? All the bean > discovery mechanism is based on BDA. The notion won?t go anywhere soon. It > should be better defined in the spec since it?s part of basic mechanism. > What about alternatives activation by config (no recompilation) and class > filtering for bean discovery? Legacy as well? > You cannot explain that observers cannot be async by default with the good > example of an application having jar (BDA) compiled with different CDI > version and when someone start thinking about a solution based on > configuration in BDA explain him that it?s legacy. > > > and there was a good reason why @Priority for Alternatives, Interceptors > and Decorators got introduced to get rid of it > > Yes because it was limitative to have them activated for only one BDA and > don?t have a way to activate them for the whole application. > > > > - and b.) badly specced (section 5 and 12 have a different definition of > BDA). > > Yes, but since when a concept needing clarification has to be declared > legacy? > > > > > What we really need btw need some new method on the > ProcessObserverMethod to switch async on/off. > > And how will you know that your observer is not part of a BDA compiled in > CDI 1.x? > > > The question is: will it be useful to allow user to activate by > configuration (beans.xml or config annotation / class) asyncSupported by > default for all their observer they design in their CDI 2.0 application? > Anybody having the end user interest in mind will try to examine this > question and only answer ?no? if it brings more complexity for end user. > > Because we?re not writing this spec for us but for end users. > > > Antoine > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150325/95800ec3/attachment.html From werner.keil at gmail.com Wed Mar 25 05:04:21 2015 From: werner.keil at gmail.com (Werner Keil) Date: Wed, 25 Mar 2015 10:04:21 +0100 Subject: [cdi-dev] Shutting down CDI Instances (John D. Ament) Message-ID: All, Especially if it was only relevant to some "profile" of CDI or environment like SE, I'd say +1 for Option 1. It sounds more modular to me, e.g. this sub-class may only appear in a certain module of CDI 2 and above (even more vital when you think SE 9+ and Jigsaw;-) Cheers, Werner On Wed, Mar 25, 2015 at 7:14 AM, wrote: > Send cdi-dev mailing list submissions to > cdi-dev at lists.jboss.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.jboss.org/mailman/listinfo/cdi-dev > or, via email, send a message with subject or body 'help' to > cdi-dev-request at lists.jboss.org > > You can reach the person managing the list at > cdi-dev-owner at lists.jboss.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of cdi-dev digest..." > > > Today's Topics: > > 1. JavaLand (Thorben Janssen) > 2. Re: JavaLand (Mark Struberg) > 3. Today's meeting --> Focus on Java SE (Antoine Sabot-Durand) > 4. Shutting down CDI Instances (John D. Ament) > 5. Some more thoughts on async events (Jos? Paumard) > 6. Re: Some more thoughts on async events (Mark Struberg) > 7. Re: Some more thoughts on async events (Antoine Sabot-Durand) > > > ---------------------------------------------------------------------- > > Message: 4 > Date: Tue, 24 Mar 2015 18:00:00 +0000 > From: "John D. Ament" > Subject: [cdi-dev] Shutting down CDI Instances > To: "cdi-dev at lists.jboss.org" > Message-ID: > < > CAOqetn_wThUpYSb_2D+VTBaq3MAd4MVn6FqX9aHa444XkvM9Yg at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > All, > > In discussion today w/ Jozef, we found that the way of shutting down a > container in the proposed SE API precluded the notion that multiple > containers could be running. While we're not necessarily going to handle > multiple containers right now, we don't want to preclude the idea either. > With that said, there were three different approaches though up to handle > how to shutdown a launched container. it obivously would only work with an > SE booted container, but part of this does give a pointer in how we may > implement initialize. > > Option 1 - Subclass CDI. The returned CDI instance when bootstrapped would > return this subclass of CDI that has shutdown capability. > > Option 2 - Add method to CDI. Add the shutdown method to CDI directly, and > throw an exception if called in an EE environment. > > Option 3 - Return a different object all together when initializing. > Return something else from initialize, e.g. CDIContext, which has a > shutdown method when you initialize. That class would also have a getter > for the CDI instance backing it. > > Let us know your thoughts. > > Thanks, > > John > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20150324/096f96d5/attachment-0001.html > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > End of cdi-dev Digest, Vol 52, Issue 82 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150325/8c2e5e08/attachment.html From jharting at redhat.com Wed Mar 25 05:55:25 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 25 Mar 2015 10:55:25 +0100 Subject: [cdi-dev] Some more thoughts on async events In-Reply-To: References: <3DE9AAD8-DBD1-4492-BD7F-696FC8FFDA49@yahoo.de> <27C28D2F-66EB-41BB-8CCF-43905ECEA85B@sabot-durand.net> Message-ID: <5512860D.6010102@redhat.com> On 03/25/2015 08:55 AM, Romain Manni-Bucau wrote: > Hi guys, > > thinking to it I think double activation whatever it is would be a > failure. As you said Antoine keep the user eyes. Do you want to > activate it twice? I udnerstand the concern but really think - > whatever technical reason behind - that as a user this is an API failure. > Agreed. > However I wonder if we just didn't overlooked the issue and can't just > say that async is not yet used so we can consider fired payloads will > be different (let say to be immutable for instance) so there is surely > no conflict in most cases (ie observers can be supposed supporting it > in all cases). If not we can detect it and fail. We cannot really detect upfront if a legacy observer is going to fail when executed in a thread other than the event-sending one. Mark gave examples of the scenarios we cannot detect, e.g: - legacy observer depends on a state of a CDI context that is not propagated to the thread that executes the observer - legacy observer depends on transactional state - legacy observer uses a ThreadLocal > > Most of the time observer chain was compared to filter chain but > actually filter chain is closer to interceptor chain but not observer > one. In other words if we want to do something - hopefully we'll not > since it would break most of usages IMO - we should validate all > interceptors of all observers. Why is it different. Cause interceptors > are synchonous wrapping inheriting from a context when observers are > by design "unknown" from the sender getting their data from a message. > The fact the sender doesn't care about observers (but just their > effects on its enclosing method - execution duration) makes this > double activation a pain whereever it is. > > > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2015-03-25 7:13 GMT+01:00 Antoine Sabot-Durand > >: > > > > Le 24 mars 2015 ? 23:16, Mark Struberg > a ?crit : > > > > > > > >> Am 24.03.2015 um 20:59 schrieb Jos? Paumard > >: > >> > >> Having to add this opt-in element on all our legacy observers > will be very tedious, so we need to come with a better pattern here. > > > > > > I don?t get you. The opt-in is EXACTLY what is needed for legacy > observers. Or do you like to change the behaviour of all the 10000 > observers out there in HUGE projects? This is way too critical to > change it implicitly. > > I sadly still have seen way too much projects with barely a test > coverage. And those projects will likely blow up if we switch all > Observers to async by default? > > > > Also note that often you cannot even re-compile libs which use > observers. So you just cannot just add anything. > > > > I think we can think about a way to ease the life of the 90 % user > that will want to use async event in their project and will find > quite boring to activate it at both ends. We could figure > something that add to the proposed feature not, a new feature. If > a user know that the majority of observers in his project support > async, wouldn?t it be nice to have a way to tell it once and > deactivate the few that don?t support it ? That?s what I > understand from Jos? proposal. > > To make short : have async deactivated by default and having two > way to activate it : on each observer or once in the current > archive. And when it?s activate for all observer in the archive > give a way to deactivate it on observer basis. > > > > > >> We could add some information in the beans.xml, that would > affect all the observers of the bean archive. > > > > NO WAY! > > Mark, we are on a community ML. People are here to make proposal > and brainstorm ideas. So please let people express their ideas and > give YOUR disagreement in a polite and non-agressive way. Your > objection content will probably be more read. > > > This BDA stuff is already considered a.) legacy > > Says who? Where it?s written in the spec that BDA are legacy? All > the bean discovery mechanism is based on BDA. The notion won?t go > anywhere soon. It should be better defined in the spec since it?s > part of basic mechanism. What about alternatives activation by > config (no recompilation) and class filtering for bean discovery? > Legacy as well? > You cannot explain that observers cannot be async by default with > the good example of an application having jar (BDA) compiled with > different CDI version and when someone start thinking about a > solution based on configuration in BDA explain him that it?s legacy. > > > and there was a good reason why @Priority for Alternatives, > Interceptors and Decorators got introduced to get rid of it > > Yes because it was limitative to have them activated for only one > BDA and don?t have a way to activate them for the whole application. > > > > - and b.) badly specced (section 5 and 12 have a different > definition of BDA). > > Yes, but since when a concept needing clarification has to be > declared legacy? > > > > > What we really need btw need some new method on the > ProcessObserverMethod to switch async on/off. > > And how will you know that your observer is not part of a BDA > compiled in CDI 1.x? > > > The question is: will it be useful to allow user to activate by > configuration (beans.xml or config annotation / class) > asyncSupported by default for all their observer they design in > their CDI 2.0 application? Anybody having the end user interest in > mind will try to examine this question and only answer ?no? if it > brings more complexity for end user. > > Because we?re not writing this spec for us but for end users. > > > Antoine > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider > licenses the code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > ideas provided on this list, the provider waives all patent and > other intellectual property rights inherent in such information. > > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150325/bc9380b8/attachment-0001.html From rmannibucau at gmail.com Wed Mar 25 06:01:36 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 25 Mar 2015 11:01:36 +0100 Subject: [cdi-dev] Some more thoughts on async events In-Reply-To: <5512860D.6010102@redhat.com> References: <3DE9AAD8-DBD1-4492-BD7F-696FC8FFDA49@yahoo.de> <27C28D2F-66EB-41BB-8CCF-43905ECEA85B@sabot-durand.net> <5512860D.6010102@redhat.com> Message-ID: sure we can't detect it but since that's new events that's also new observers (no CDi 1.x uses async observers). If an app reuse the same payload it will fail but I don't think we should care about this case. Would significally simplify the life of users + we can't validate it anyway, even with observers activating the feature. Said otherwise how do you ensure today a session scope bean relying on a thread local will work during session invalidation? you don't and nobody complained. Think we shouldn't make it more complex than it is. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-03-25 10:55 GMT+01:00 Jozef Hartinger : > > On 03/25/2015 08:55 AM, Romain Manni-Bucau wrote: > > Hi guys, > > thinking to it I think double activation whatever it is would be a > failure. As you said Antoine keep the user eyes. Do you want to activate it > twice? I udnerstand the concern but really think - whatever technical > reason behind - that as a user this is an API failure. > > Agreed. > > However I wonder if we just didn't overlooked the issue and can't just > say that async is not yet used so we can consider fired payloads will be > different (let say to be immutable for instance) so there is surely no > conflict in most cases (ie observers can be supposed supporting it in all > cases). If not we can detect it and fail. > > We cannot really detect upfront if a legacy observer is going to fail when > executed in a thread other than the event-sending one. Mark gave examples > of the scenarios we cannot detect, e.g: > - legacy observer depends on a state of a CDI context that is not > propagated to the thread that executes the observer > - legacy observer depends on transactional state > - legacy observer uses a ThreadLocal > > > Most of the time observer chain was compared to filter chain but > actually filter chain is closer to interceptor chain but not observer one. > In other words if we want to do something - hopefully we'll not since it > would break most of usages IMO - we should validate all interceptors of all > observers. Why is it different. Cause interceptors are synchonous wrapping > inheriting from a context when observers are by design "unknown" from the > sender getting their data from a message. The fact the sender doesn't care > about observers (but just their effects on its enclosing method - execution > duration) makes this double activation a pain whereever it is. > > > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2015-03-25 7:13 GMT+01:00 Antoine Sabot-Durand : > >> >> > Le 24 mars 2015 ? 23:16, Mark Struberg a ?crit : >> > >> > >> > >> >> Am 24.03.2015 um 20:59 schrieb Jos? Paumard : >> >> >> >> Having to add this opt-in element on all our legacy observers will be >> very tedious, so we need to come with a better pattern here. >> > >> > >> > I don?t get you. The opt-in is EXACTLY what is needed for legacy >> observers. Or do you like to change the behaviour of all the 10000 >> observers out there in HUGE projects? This is way too critical to change it >> implicitly. >> > I sadly still have seen way too much projects with barely a test >> coverage. And those projects will likely blow up if we switch all Observers >> to async by default? >> > >> > Also note that often you cannot even re-compile libs which use >> observers. So you just cannot just add anything. >> > >> >> I think we can think about a way to ease the life of the 90 % user that >> will want to use async event in their project and will find quite boring to >> activate it at both ends. We could figure something that add to the >> proposed feature not, a new feature. If a user know that the majority of >> observers in his project support async, wouldn?t it be nice to have a way >> to tell it once and deactivate the few that don?t support it ? That?s what >> I understand from Jos? proposal. >> >> To make short : have async deactivated by default and having two way to >> activate it : on each observer or once in the current archive. And when >> it?s activate for all observer in the archive give a way to deactivate it >> on observer basis. >> >> >> > >> >> We could add some information in the beans.xml, that would affect all >> the observers of the bean archive. >> > >> > NO WAY! >> >> Mark, we are on a community ML. People are here to make proposal and >> brainstorm ideas. So please let people express their ideas and give YOUR >> disagreement in a polite and non-agressive way. Your objection content will >> probably be more read. >> >> > This BDA stuff is already considered a.) legacy >> >> Says who? Where it?s written in the spec that BDA are legacy? All the >> bean discovery mechanism is based on BDA. The notion won?t go anywhere >> soon. It should be better defined in the spec since it?s part of basic >> mechanism. What about alternatives activation by config (no recompilation) >> and class filtering for bean discovery? Legacy as well? >> You cannot explain that observers cannot be async by default with the >> good example of an application having jar (BDA) compiled with different CDI >> version and when someone start thinking about a solution based on >> configuration in BDA explain him that it?s legacy. >> >> > and there was a good reason why @Priority for Alternatives, >> Interceptors and Decorators got introduced to get rid of it >> >> Yes because it was limitative to have them activated for only one BDA and >> don?t have a way to activate them for the whole application. >> >> >> > - and b.) badly specced (section 5 and 12 have a different definition >> of BDA). >> >> Yes, but since when a concept needing clarification has to be declared >> legacy? >> >> > >> > What we really need btw need some new method on the >> ProcessObserverMethod to switch async on/off. >> >> And how will you know that your observer is not part of a BDA compiled in >> CDI 1.x? >> >> >> The question is: will it be useful to allow user to activate by >> configuration (beans.xml or config annotation / class) asyncSupported by >> default for all their observer they design in their CDI 2.0 application? >> Anybody having the end user interest in mind will try to examine this >> question and only answer ?no? if it brings more complexity for end user. >> >> Because we?re not writing this spec for us but for end users. >> >> >> Antoine >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> > > > > _______________________________________________ > cdi-dev mailing listcdi-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150325/51785ae7/attachment.html From antoine at sabot-durand.net Wed Mar 25 09:45:59 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 25 Mar 2015 14:45:59 +0100 Subject: [cdi-dev] Previously on "Double end async events activation" Message-ID: <8C6A9139-6FF9-4A0B-B89B-AEAD06A7EB78@sabot-durand.net> Hi all, This mail is quite long, but if you want to catch up on this double end activation for async event and bring your help on this point, you should take the 10 mn to read it and make your feedback. We?ve been talking of this for more thant on month now, so it?s normal that reflection and proposition take a few lines to synthesize Discussion is going back to solution avoiding this double activation stuff for async event. To avoid explaining again why we should care and the solution we already explore here is a small wrap up of previous episodes : 1) Why is it important to take time on this? Some of you may find we already spend too many time on this question, but remember. Async events are the 1st requested stuff from the community. It has been asked for a long time (Jira ticket is CDI-4). We didn?t provided a solution for CDI 1.1 so now people are waiting this feature and they probably hope it?ll be nicely designed. To make short : if we don?t deliver users will be very disappointed, if we propose a lousy solution people will be very critic. I know that it?s better to not deliver than delivering something we are not happy with, but we really should be careful here 2) Why this double activation is needed? For the producer (fire()) side it?s rather obvious : we cannot magically change all synchronous event call to async. We need an handle on the work in progress (so a new method signature with CompletionStage), the payload mutation mechanism would break as all transactional events. So there?s no debate on fireAsync() On the Observer side, the reason is for backward compatibility. CDI events are a great way to cross boundary of our own code and activate unknown code at runtime in another piece of the app (another jar) that we don?t own. This other code can be a framework, a code developed by an other team in a big project or a legacy jar that we don?t want to touch. Imagine the following use cases (all code running on CDI 2) a) I?m compiling in CDI 1.x and one of the Jar (framework for instance) already migrated to CDI 2.0 firing async event where it use to fire sync events. Without activation on the observer side, I have all the chance to see my observer break. And if I decide to upgrade to CDI 2.0 I must have a way to activate / deactivate async call on given observers b) I?m compiling in CDI 2.0 but use jar1 in CDI 1.0 and jar2 in CDI 2.0 coming from other teams. jar2 and jar1 are old related piece of code communicating the event. The guys in jar2 had time to migrate to CDI 2.0 and switch most fire() to fireAsync(). Observer in jar1 will be called asynchronously if the default is to have async activated for all observer. I agree that these example looks like corner case but the side effect will be that no framework developper will switch to fireAsync() to prevent these issues and we?ll have an adoption problem. More than that as we are designing a Java EE specification we are committed to backward compatibility and cannot change behavior of old code, like it would do 3) Implementing this observer activation I?m listing here all the solution to deal with this requirement. For some of them I?ll add the reason we won?t adopt it or my feeling about it a) Adding or using an @Async annotation : @Async public void myObserver(@Observes Object payload) {} Personally I don?t want to add @Async to or @Asynchronous to CDI, it feels too much like an EJB-ification of the spec. If we go that way we should work to add this to Commons Annotation (simpler for CDI SE) or concurrent utilities (more consistent but not CDI SE friendly since we?ll have to get this dependency in SE). As we?ll already have to wrk on Commons Annotation for @Priority (allowing it on parameter for event ordering), it could make sens to focus our effort here. This @Async annotation could be used for async operation if we decide to add this support to CDI. The downside of this annotation is the confusion it can bring to people thinking that it will be sufficient to have an Async observer. The second objection is the confusion if we decide to not add async support operation in CDI (since it?s nearly out of the bow in Java 8). Some people won?t understand why @Async is used only on event b) Having an @AsyncSupported annotation @AsyncSupported(true) public void myObserver(@Observes Object payload) {} An observer without this annotation will be considered having @AsyncSupported(false) by default Very similar to previous solution but rather different semantically. It doesn?t give the impression that it?s activating async behavior but it allows it. The boolean value (true by default) could be a solution if we find a nice way to activate async observer by default for our jars (code we own) and provide an opt out solution for the few observer that wouldn?t support it. Personally I don?t have issue to add this annotation to CDI since it?s more configuration than activation c) Adding a member to @Observes public void myObserver(@Observes(asyncSupported=true) Object payload) The good part of it is that it prevent us to add a new annotation. The major drawback is linking issue with oCDI 1.x code (with old @Observes) running on CDI 2.0. to my knowledge, nobody tested that so far but anyway it?s a risk. d) Add an @ObserveAsync annotation public void myObserver(@ObserveAsync Object payload) {} As we have backward compatibility issue, introducing a brand new type of observer instead of adding annotation on observer or modifying existing @Observes annotation, could be an idea. We could imagine having specific async config in this annotation (scope to propagate if we decide to support this feature). The main downside of this is the introduction of another annotation to observe event and the confusion for user when using fire() and waiting @ObserveAsync event launch asynchronously 4) What about changing default behavior for the local jar? Idea launched by some of us. We could extend the chosen scenario by activating AsyncSupport by default on all observer on the current jar (BDA). Since the main backward compatibility issue is linked to have different CDI jar from different owners and version we could give local control to the user for his own code and jars. That could be done in beans.xml like we did for bean-discovery with an async-event attributes for instance or in code by a config annotation or event in extension (but we probably should expose the BDA concept in SPI if we go that way?) 5)Conclusion: Now you have the whole picture. If I missed things, tell me. If you like an idea please tell it, if you have a new idea or a different POV, feel free to speak. Thanks for reading. 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/20150325/b2694582/attachment-0001.bin From rmannibucau at gmail.com Wed Mar 25 10:00:45 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 25 Mar 2015 15:00:45 +0100 Subject: [cdi-dev] Previously on "Double end async events activation" In-Reply-To: <8C6A9139-6FF9-4A0B-B89B-AEAD06A7EB78@sabot-durand.net> References: <8C6A9139-6FF9-4A0B-B89B-AEAD06A7EB78@sabot-durand.net> Message-ID: few comments inline Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-03-25 14:45 GMT+01:00 Antoine Sabot-Durand : > Hi all, > > > This mail is quite long, but if you want to catch up on this double end > activation for async event and bring your help on this point, you should > take the 10 mn to read it and make your feedback. We?ve been talking of > this for more thant on month now, so it?s normal that reflection and > proposition take a few lines to synthesize > Discussion is going back to solution avoiding this double activation stuff > for async event. To avoid explaining again why we should care and the > solution we already explore here is a small wrap up of previous episodes : > > 1) Why is it important to take time on this? > Some of you may find we already spend too many time on this question, but > remember. Async events are the 1st requested stuff from the community. It > has been asked for a long time (Jira ticket is CDI-4). We didn?t provided a > solution for CDI 1.1 so now people are waiting this feature and they > probably hope it?ll be nicely designed. > To make short : if we don?t deliver users will be very disappointed, if we > propose a lousy solution people will be very critic. I know that it?s > better to not deliver than delivering something we are not happy with, but > we really should be careful here > > > 2) Why this double activation is needed? > For the producer (fire()) side it?s rather obvious : we cannot magically > change all synchronous event call to async. We need an handle on the work > in progress (so a new method signature with CompletionStage), the payload > mutation mechanism would break as all transactional events. So there?s no > debate on fireAsync() > > On the Observer side, the reason is for backward compatibility. CDI events > are a great way to cross boundary of our own code and activate unknown code > at runtime in another piece of the app (another jar) that we don?t own. > This other code can be a framework, a code developed by an other team in a > big project or a legacy jar that we don?t want to touch. > > Imagine the following use cases (all code running on CDI 2) > > a) I?m compiling in CDI 1.x and one of the Jar (framework for instance) > already migrated to CDI 2.0 firing async event where it use to fire sync > events. Without activation on the observer side, I have all the chance to > see my observer break. And if I decide to upgrade to CDI 2.0 I must have a > way to activate / deactivate async call on given observers > > b) I?m compiling in CDI 2.0 but use jar1 in CDI 1.0 and jar2 in CDI 2.0 > coming from other teams. jar2 and jar1 are old related piece of code > communicating the event. The guys in jar2 had time to migrate to CDI 2.0 > and switch most fire() to fireAsync(). Observer in jar1 will be called > asynchronously if the default is to have async activated for all observer. > > I agree that these example looks like corner case but the side effect will > be that no framework developper will switch to fireAsync() to prevent these > issues and we?ll have an adoption problem. > More than that as we are designing a Java EE specification we are > committed to backward compatibility and cannot change behavior of old code, > like it would do > > I'm not sure. A framework will not use fireAsync() for its existing base (CDI 1.x) but for new usages I think it will if relevant cause there is yet no observer out there. > 3) Implementing this observer activation > > I?m listing here all the solution to deal with this requirement. For some > of them I?ll add the reason we won?t adopt it or my feeling about it > > > a) Adding or using an @Async annotation : > > @Async > public void myObserver(@Observes Object payload) {} > > Personally I don?t want to add @Async to or @Asynchronous to CDI, it feels > too much like an EJB-ification of the spec. If we go that way we should > work to add this to Commons Annotation (simpler for CDI SE) or concurrent > utilities (more consistent but not CDI SE friendly since we?ll have to get > this dependency in SE). As we?ll already have to wrk on Commons Annotation > for @Priority (allowing it on parameter for event ordering), it could make > sens to focus our effort here. > This @Async annotation could be used for async operation if we decide to > add this support to CDI. > > The downside of this annotation is the confusion it can bring to people > thinking that it will be sufficient to have an Async observer. The second > objection is the confusion if we decide to not add async support operation > in CDI (since it?s nearly out of the bow in Java 8). Some people won?t > understand why @Async is used only on event > > +1, also means async observers are useless with java 8 isn't it? > b) Having an @AsyncSupported annotation > > @AsyncSupported(true) > public void myObserver(@Observes Object payload) {} > > An observer without this annotation will be considered having > @AsyncSupported(false) by default > > Very similar to previous solution but rather different semantically. It > doesn?t give the impression that it?s activating async behavior but it > allows it. The boolean value (true by default) could be a solution if we > find a nice way to activate async observer by default for our jars (code we > own) and provide an opt out solution for the few observer that wouldn?t > support it. > Personally I don?t have issue to add this annotation to CDI since it?s > more configuration than activation > > c) Adding a member to @Observes > > public void myObserver(@Observes(asyncSupported=true) Object payload) > > The good part of it is that it prevent us to add a new annotation. The > major drawback is linking issue with oCDI 1.x code (with old @Observes) > running on CDI 2.0. to my knowledge, nobody tested that so far but anyway > it?s a risk. > > should work (like @Resource for JavaEE 6 I think which was missing lookup()) but still need double activation which looks to me like EJB 2 :s > d) Add an @ObserveAsync annotation > > public void myObserver(@ObserveAsync Object payload) {} > > As we have backward compatibility issue, introducing a brand new type of > observer instead of adding annotation on observer or modifying existing > @Observes annotation, could be an idea. We could imagine having specific > async config in this annotation (scope to propagate if we decide to support > this feature). > The main downside of this is the introduction of another annotation to > observe event and the confusion for user when using fire() and waiting > @ObserveAsync event launch asynchronously > > -1, you orignial statement is support of async and not async observation, seems it breaks this to me. > 4) What about changing default behavior for the local jar? > > Idea launched by some of us. We could extend the chosen scenario by > activating AsyncSupport by default on all observer on the current jar > (BDA). Since the main backward compatibility issue is linked to have > different CDI jar from different owners and version we could give local > control to the user for his own code and jars. > That could be done in beans.xml like we did for bean-discovery with an > async-event attributes for instance or in code by a config annotation or > event in extension (but we probably should expose the BDA concept in SPI if > we go that way?) > > 5)Conclusion: > Now you have the whole picture. If I missed things, tell me. If you like > an idea please tell it, if you have a new idea or a different POV, feel > free to speak. > > Any test using j8 to get async features without anything in CDI framework have been done? Think it is smooth enough finally and avoid to mess up CDI, allows to wait for a real async solution if needed at spec level (concurreny utilities maybe) and doesn't prevent users to use asynchronism in a proper way (compared to what we can do at framework level, ie have composition for instance). > Thanks for reading. > > Antoine > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150325/1eb2440d/attachment.html From arjan.tijms at gmail.com Wed Mar 25 10:54:57 2015 From: arjan.tijms at gmail.com (arjan tijms) Date: Wed, 25 Mar 2015 15:54:57 +0100 Subject: [cdi-dev] Best way to specify for spec that CDI contexts should be available? Message-ID: Hi, In the Security EG many proposals that are currently being discussed depend on CDI being available in authentication modules. Low level authentication modules do not necessarily have to be beans themselves, but they have to be able to programmatically pull beans from the bean manager, in order to be able to delegate certain authentication decisions to those. Now if I'm not mistaken, CDI is most often initialized per request via a ServletRequestListener (in a vendor specific way), so those obviously have to be invoked before an authentication module is invoked (which is a Servlet concern). On the other hand, the CDI spec defines when the request scope, session scope and application scope should be active, referencing other spec artifacts there. Furthermore, it seems the CDI 2.0 spec is also working on providing APIs for initializing CDI, but does that also take into account the per request initialization that CDI implementations currently do? Would this be powerful enough for code in an authentication module to initialize CDI itself, such that request- session- and application scoped beans can be pulled from the bean manager? And if the above would be possible, what would happen if an authentication module initialized the per request bits of CDI, and then afterwards (within the same request) the container would attempt to initialize CDI as it would normally do for usage in Servlets and Filters? So, what would be spec-wise and practically speaking the best way to specify that CDI should be available in authentication modules? Kind regards, Arjan Tijms -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150325/c70f14eb/attachment.html From mpaluch at paluch.biz Wed Mar 25 15:28:46 2015 From: mpaluch at paluch.biz (Mark Paluch) Date: Wed, 25 Mar 2015 20:28:46 +0100 Subject: [cdi-dev] Previously on "Double end async events activation" In-Reply-To: <8C6A9139-6FF9-4A0B-B89B-AEAD06A7EB78@sabot-durand.net> References: <8C6A9139-6FF9-4A0B-B89B-AEAD06A7EB78@sabot-durand.net> Message-ID: Hi Antoine, thanks for your input and this summary. I placed my comments inline. Best regards, Mark > Am 25.03.2015 um 14:45 schrieb Antoine Sabot-Durand : > > Hi all, > > > This mail is quite long, but if you want to catch up on this double end activation for async event and bring your help on this point, you should take the 10 mn to read it and make your feedback. We?ve been talking of this for more thant on month now, so it?s normal that reflection and proposition take a few lines to synthesize > Discussion is going back to solution avoiding this double activation stuff for async event. To avoid explaining again why we should care and the solution we already explore here is a small wrap up of previous episodes : > > 1) Why is it important to take time on this? > Some of you may find we already spend too many time on this question, but remember. Async events are the 1st requested stuff from the community. It has been asked for a long time (Jira ticket is CDI-4). We didn?t provided a solution for CDI 1.1 so now people are waiting this feature and they probably hope it?ll be nicely designed. > To make short : if we don?t deliver users will be very disappointed, if we propose a lousy solution people will be very critic. I know that it?s better to not deliver than delivering something we are not happy with, but we really should be careful here +1 CDI 2.0 without async events seems a no-go > > > 2) Why this double activation is needed? > For the producer (fire()) side it?s rather obvious : we cannot magically change all synchronous event call to async. We need an handle on the work in progress (so a new method signature with CompletionStage), the payload mutation mechanism would break as all transactional events. So there?s no debate on fireAsync() +1 on fireAsync fireAsync triggers always asynchronous event processing. Currently we?re talking about interference between observers, but there are lots of other ways to do nasty things (e.g. modifying the payload from the firing thread). Any caller expects a method returning CompletionStage returning instantly, before any work is done. This leads to the point that disabling async on legacy observers would lead that fireAsync would return after those legacy observers are processed. > > > 3) Implementing this observer activation > > I?m listing here all the solution to deal with this requirement. For some of them I?ll add the reason we won?t adopt it or my feeling about it > I would add another case which might help to clarify @Priority as well: 1. fire with @Observers: same behavior as CDI 1.x 2. fireAsync with @Observes: observers are processed in any order in sequence but in a different thread - nothing new until now - 3. fireAsync with @Observers and @Concurrent (obviously not async to prevent confusion): Observers carrying @Concurrent are running concurrently to each other (that?s the double-opt in case). Observers not having @Concurrent are handled like point 2. observer methods are not allowed to to have both, @Priority and @Concurrent 4. fire with @Observes and @Concurrent: Ability to use fire with some level of async. The behavior on the caller side does not change, fire waits until all observer method invocations are finished We should think also about ProcessObserverMethod. That?s the place where you can override any priority/(async|concurrent) settings and perhaps even the asyncSupported flag. This sort of opt-out is maybe sufficient. Now what happens, if asyncSupported=false and fireAsync? How about just skipping the observer? > > > > 4) What about changing default behavior for the local jar? > > Idea launched by some of us. We could extend the chosen scenario by activating AsyncSupport by default on all observer on the current jar (BDA). Since the main backward compatibility issue is linked to have different CDI jar from different owners and version we could give local control to the user for his own code and jars. > That could be done in beans.xml like we did for bean-discovery with an async-event attributes for instance or in code by a config annotation or event in extension (but we probably should expose the BDA concept in SPI if we go that way?) This feels like a dirty hack and in the end you can?t tell how your application will behave. > > 5)Conclusion: > Now you have the whole picture. If I missed things, tell me. If you like an idea please tell it, if you have a new idea or a different POV, feel free to speak. > > Thanks for reading. > > Antoine > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From antoine at sabot-durand.net Thu Mar 26 05:17:24 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 26 Mar 2015 10:17:24 +0100 Subject: [cdi-dev] Previously on "Double end async events activation" In-Reply-To: References: <8C6A9139-6FF9-4A0B-B89B-AEAD06A7EB78@sabot-durand.net> Message-ID: <3891A573-F8EA-4CDF-95AA-014E5307A023@sabot-durand.net> Hi Romain, Thanks for your feedback > Le 25 mars 2015 ? 15:00, Romain Manni-Bucau a ?crit : > > few comments inline > > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > 2015-03-25 14:45 GMT+01:00 Antoine Sabot-Durand >: > Hi all, > > > This mail is quite long, but if you want to catch up on this double end activation for async event and bring your help on this point, you should take the 10 mn to read it and make your feedback. We?ve been talking of this for more thant on month now, so it?s normal that reflection and proposition take a few lines to synthesize > Discussion is going back to solution avoiding this double activation stuff for async event. To avoid explaining again why we should care and the solution we already explore here is a small wrap up of previous episodes : > > 1) Why is it important to take time on this? > Some of you may find we already spend too many time on this question, but remember. Async events are the 1st requested stuff from the community. It has been asked for a long time (Jira ticket is CDI-4). We didn?t provided a solution for CDI 1.1 so now people are waiting this feature and they probably hope it?ll be nicely designed. > To make short : if we don?t deliver users will be very disappointed, if we propose a lousy solution people will be very critic. I know that it?s better to not deliver than delivering something we are not happy with, but we really should be careful here > > > 2) Why this double activation is needed? > For the producer (fire()) side it?s rather obvious : we cannot magically change all synchronous event call to async. We need an handle on the work in progress (so a new method signature with CompletionStage), the payload mutation mechanism would break as all transactional events. So there?s no debate on fireAsync() > > On the Observer side, the reason is for backward compatibility. CDI events are a great way to cross boundary of our own code and activate unknown code at runtime in another piece of the app (another jar) that we don?t own. This other code can be a framework, a code developed by an other team in a big project or a legacy jar that we don?t want to touch. > > Imagine the following use cases (all code running on CDI 2) > > a) I?m compiling in CDI 1.x and one of the Jar (framework for instance) already migrated to CDI 2.0 firing async event where it use to fire sync events. Without activation on the observer side, I have all the chance to see my observer break. And if I decide to upgrade to CDI 2.0 I must have a way to activate / deactivate async call on given observers > > b) I?m compiling in CDI 2.0 but use jar1 in CDI 1.0 and jar2 in CDI 2.0 coming from other teams. jar2 and jar1 are old related piece of code communicating the event. The guys in jar2 had time to migrate to CDI 2.0 and switch most fire() to fireAsync(). Observer in jar1 will be called asynchronously if the default is to have async activated for all observer. > > I agree that these example looks like corner case but the side effect will be that no framework developper will switch to fireAsync() to prevent these issues and we?ll have an adoption problem. > More than that as we are designing a Java EE specification we are committed to backward compatibility and cannot change behavior of old code, like it would do > > > I'm not sure. A framework will not use fireAsync() for its existing base (CDI 1.x) but for new usages I think it will if relevant cause there is yet no observer out there. Perhaps but we cannot speculate on that. Given the very open observer resolution rules we have (an observer on Object with default qualifier will be called for all events), user can break things without knowing it > > 3) Implementing this observer activation > > I?m listing here all the solution to deal with this requirement. For some of them I?ll add the reason we won?t adopt it or my feeling about it > > > a) Adding or using an @Async annotation : > > @Async > public void myObserver(@Observes Object payload) {} > > Personally I don?t want to add @Async to or @Asynchronous to CDI, it feels too much like an EJB-ification of the spec. If we go that way we should work to add this to Commons Annotation (simpler for CDI SE) or concurrent utilities (more consistent but not CDI SE friendly since we?ll have to get this dependency in SE). As we?ll already have to wrk on Commons Annotation for @Priority (allowing it on parameter for event ordering), it could make sens to focus our effort here. > This @Async annotation could be used for async operation if we decide to add this support to CDI. > > The downside of this annotation is the confusion it can bring to people thinking that it will be sufficient to have an Async observer. The second objection is the confusion if we decide to not add async support operation in CDI (since it?s nearly out of the bow in Java 8). Some people won?t understand why @Async is used only on event > > > +1, also means async observers are useless with java 8 isn't it? Nope. Observer are not standard java invocation: you call one fire() and will trigger an unknown number of observer. If you want to have feedback on async observer (are they all complete) you need to add these async mechanism in the event bus. Having a bunch of standard observe launching async operation thru CompletableFuture API without any mean of sending feedback will be a total mess IMO. > > b) Having an @AsyncSupported annotation > > @AsyncSupported(true) > public void myObserver(@Observes Object payload) {} > > An observer without this annotation will be considered having @AsyncSupported(false) by default > > Very similar to previous solution but rather different semantically. It doesn?t give the impression that it?s activating async behavior but it allows it. The boolean value (true by default) could be a solution if we find a nice way to activate async observer by default for our jars (code we own) and provide an opt out solution for the few observer that wouldn?t support it. > Personally I don?t have issue to add this annotation to CDI since it?s more configuration than activation > > c) Adding a member to @Observes > > public void myObserver(@Observes(asyncSupported=true) Object payload) > > The good part of it is that it prevent us to add a new annotation. The major drawback is linking issue with oCDI 1.x code (with old @Observes) running on CDI 2.0. to my knowledge, nobody tested that so far but anyway it?s a risk. > > > should work (like @Resource for JavaEE 6 I think which was missing lookup()) but still need double activation which looks to me like EJB 2 :s Yes, I add the same example in mind, but I never experimented old EE 6 code running on EE 7 with @Resource usage. I?m going to do some test to know if this option is realistic. > > d) Add an @ObserveAsync annotation > > public void myObserver(@ObserveAsync Object payload) {} > > As we have backward compatibility issue, introducing a brand new type of observer instead of adding annotation on observer or modifying existing @Observes annotation, could be an idea. We could imagine having specific async config in this annotation (scope to propagate if we decide to support this feature). > The main downside of this is the introduction of another annotation to observe event and the confusion for user when using fire() and waiting @ObserveAsync event launch asynchronously > > > -1, you orignial statement is support of async and not async observation, seems it breaks this to me. I agree, could be more confusing than good. For me it?s like a). having @Async on a method (or here @ObserveAsync in an observer) let user think that it will async without anything else needed. > > 4) What about changing default behavior for the local jar? > > Idea launched by some of us. We could extend the chosen scenario by activating AsyncSupport by default on all observer on the current jar (BDA). Since the main backward compatibility issue is linked to have different CDI jar from different owners and version we could give local control to the user for his own code and jars. > That could be done in beans.xml like we did for bean-discovery with an async-event attributes for instance or in code by a config annotation or event in extension (but we probably should expose the BDA concept in SPI if we go that way?) > > 5)Conclusion: > Now you have the whole picture. If I missed things, tell me. If you like an idea please tell it, if you have a new idea or a different POV, feel free to speak. > > > > Any test using j8 to get async features without anything in CDI framework have been done? Think it is smooth enough finally and avoid to mess up CDI, allows to wait for a real async solution if needed at spec level (concurreny utilities maybe) and doesn't prevent users to use asynchronism in a proper way (compared to what we can do at framework level, ie have composition for instance). No need for test for standard async operation, it will work on SE and in EE we?ll just have to use concurrency utilities to get a managed executor. Regarding these operation the question will be do we introduce syntaxic sugar to add support in CDI (an annotation to replace 2 or 3 lines of code), right now I?d be tempted to answer ?no? but I may missed specific use case like async interceptors. Again, the question here is for Async in event: as we don?t have hand on observers invocation we have to enhance the event engine to support this async behavior in order to get feedback of these async operations. > > > Thanks for reading. > > Antoine > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150326/376a3846/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/20150326/376a3846/attachment-0001.bin From rmannibucau at gmail.com Thu Mar 26 05:33:26 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Thu, 26 Mar 2015 10:33:26 +0100 Subject: [cdi-dev] Previously on "Double end async events activation" In-Reply-To: <3891A573-F8EA-4CDF-95AA-014E5307A023@sabot-durand.net> References: <8C6A9139-6FF9-4A0B-B89B-AEAD06A7EB78@sabot-durand.net> <3891A573-F8EA-4CDF-95AA-014E5307A023@sabot-durand.net> Message-ID: true, missed the feedback part but then async cdi bus sounds like a really weak "async" bus - ie with no async operations. I dont recall but in the original polling you did was async vote commented? Ie do we know if users just want fire and forget or do they want real async API where it would mean having composition for instance. Being said async code is often associated to fire and forget, feedback is an option IMO but I can be wrong here. If not it means fireAsync would simply return void like fire/fireEvent. Side note: if you observe "Object" you already don't care about the context since you can be called from threads without any active context so not something to care about IMO. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-03-26 10:17 GMT+01:00 Antoine Sabot-Durand : > Hi Romain, > > Thanks for your feedback > > Le 25 mars 2015 ? 15:00, Romain Manni-Bucau a > ?crit : > > few comments inline > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2015-03-25 14:45 GMT+01:00 Antoine Sabot-Durand > : > >> Hi all, >> >> >> This mail is quite long, but if you want to catch up on this double end >> activation for async event and bring your help on this point, you should >> take the 10 mn to read it and make your feedback. We?ve been talking of >> this for more thant on month now, so it?s normal that reflection and >> proposition take a few lines to synthesize >> Discussion is going back to solution avoiding this double activation >> stuff for async event. To avoid explaining again why we should care and the >> solution we already explore here is a small wrap up of previous episodes : >> >> 1) Why is it important to take time on this? >> Some of you may find we already spend too many time on this question, but >> remember. Async events are the 1st requested stuff from the community. It >> has been asked for a long time (Jira ticket is CDI-4). We didn?t provided a >> solution for CDI 1.1 so now people are waiting this feature and they >> probably hope it?ll be nicely designed. >> To make short : if we don?t deliver users will be very disappointed, if >> we propose a lousy solution people will be very critic. I know that it?s >> better to not deliver than delivering something we are not happy with, but >> we really should be careful here >> >> >> 2) Why this double activation is needed? >> For the producer (fire()) side it?s rather obvious : we cannot magically >> change all synchronous event call to async. We need an handle on the work >> in progress (so a new method signature with CompletionStage), the payload >> mutation mechanism would break as all transactional events. So there?s no >> debate on fireAsync() >> >> On the Observer side, the reason is for backward compatibility. CDI >> events are a great way to cross boundary of our own code and activate >> unknown code at runtime in another piece of the app (another jar) that we >> don?t own. This other code can be a framework, a code developed by an other >> team in a big project or a legacy jar that we don?t want to touch. >> >> Imagine the following use cases (all code running on CDI 2) >> >> a) I?m compiling in CDI 1.x and one of the Jar (framework for instance) >> already migrated to CDI 2.0 firing async event where it use to fire sync >> events. Without activation on the observer side, I have all the chance to >> see my observer break. And if I decide to upgrade to CDI 2.0 I must have a >> way to activate / deactivate async call on given observers >> >> b) I?m compiling in CDI 2.0 but use jar1 in CDI 1.0 and jar2 in CDI 2.0 >> coming from other teams. jar2 and jar1 are old related piece of code >> communicating the event. The guys in jar2 had time to migrate to CDI 2.0 >> and switch most fire() to fireAsync(). Observer in jar1 will be called >> asynchronously if the default is to have async activated for all observer. >> >> I agree that these example looks like corner case but the side effect >> will be that no framework developper will switch to fireAsync() to prevent >> these issues and we?ll have an adoption problem. >> More than that as we are designing a Java EE specification we are >> committed to backward compatibility and cannot change behavior of old code, >> like it would do >> >> > I'm not sure. A framework will not use fireAsync() for its existing base > (CDI 1.x) but for new usages I think it will if relevant cause there is yet > no observer out there. > > > > Perhaps but we cannot speculate on that. Given the very open observer > resolution rules we have (an observer on Object with default qualifier will > be called for all events), user can break things without knowing it > > > >> 3) Implementing this observer activation >> >> I?m listing here all the solution to deal with this requirement. For some >> of them I?ll add the reason we won?t adopt it or my feeling about it >> >> >> a) Adding or using an @Async annotation : >> >> @Async >> public void myObserver(@Observes Object payload) {} >> >> Personally I don?t want to add @Async to or @Asynchronous to CDI, it >> feels too much like an EJB-ification of the spec. If we go that way we >> should work to add this to Commons Annotation (simpler for CDI SE) or >> concurrent utilities (more consistent but not CDI SE friendly since we?ll >> have to get this dependency in SE). As we?ll already have to wrk on Commons >> Annotation for @Priority (allowing it on parameter for event ordering), it >> could make sens to focus our effort here. >> This @Async annotation could be used for async operation if we decide to >> add this support to CDI. >> >> The downside of this annotation is the confusion it can bring to people >> thinking that it will be sufficient to have an Async observer. The second >> objection is the confusion if we decide to not add async support operation >> in CDI (since it?s nearly out of the bow in Java 8). Some people won?t >> understand why @Async is used only on event >> >> > +1, also means async observers are useless with java 8 isn't it? > > > Nope. Observer are not standard java invocation: you call one fire() and > will trigger an unknown number of observer. If you want to have feedback on > async observer (are they all complete) you need to add these async > mechanism in the event bus. Having a bunch of standard observe launching > async operation thru CompletableFuture API without any mean of sending > feedback will be a total mess IMO. > > > > >> b) Having an @AsyncSupported annotation >> >> @AsyncSupported(true) >> public void myObserver(@Observes Object payload) {} >> >> An observer without this annotation will be considered having >> @AsyncSupported(false) by default >> >> Very similar to previous solution but rather different semantically. It >> doesn?t give the impression that it?s activating async behavior but it >> allows it. The boolean value (true by default) could be a solution if we >> find a nice way to activate async observer by default for our jars (code we >> own) and provide an opt out solution for the few observer that wouldn?t >> support it. >> Personally I don?t have issue to add this annotation to CDI since it?s >> more configuration than activation >> >> c) Adding a member to @Observes >> >> public void myObserver(@Observes(asyncSupported=true) Object payload) >> >> The good part of it is that it prevent us to add a new annotation. The >> major drawback is linking issue with oCDI 1.x code (with old @Observes) >> running on CDI 2.0. to my knowledge, nobody tested that so far but anyway >> it?s a risk. >> >> > should work (like @Resource for JavaEE 6 I think which was missing > lookup()) but still need double activation which looks to me like EJB 2 :s > > > Yes, I add the same example in mind, but I never experimented old EE 6 > code running on EE 7 with @Resource usage. I?m going to do some test to > know if this option is realistic. > > > >> d) Add an @ObserveAsync annotation >> >> public void myObserver(@ObserveAsync Object payload) {} >> >> As we have backward compatibility issue, introducing a brand new type of >> observer instead of adding annotation on observer or modifying existing >> @Observes annotation, could be an idea. We could imagine having specific >> async config in this annotation (scope to propagate if we decide to support >> this feature). >> The main downside of this is the introduction of another annotation to >> observe event and the confusion for user when using fire() and waiting >> @ObserveAsync event launch asynchronously >> >> > -1, you orignial statement is support of async and not async observation, > seems it breaks this to me. > > > I agree, could be more confusing than good. For me it?s like a). having > @Async on a method (or here @ObserveAsync in an observer) let user think > that it will async without anything else needed. > > > >> 4) What about changing default behavior for the local jar? >> >> Idea launched by some of us. We could extend the chosen scenario by >> activating AsyncSupport by default on all observer on the current jar >> (BDA). Since the main backward compatibility issue is linked to have >> different CDI jar from different owners and version we could give local >> control to the user for his own code and jars. >> That could be done in beans.xml like we did for bean-discovery with an >> async-event attributes for instance or in code by a config annotation or >> event in extension (but we probably should expose the BDA concept in SPI if >> we go that way?) >> >> 5)Conclusion: >> Now you have the whole picture. If I missed things, tell me. If you like >> an idea please tell it, if you have a new idea or a different POV, feel >> free to speak. >> >> > > Any test using j8 to get async features without anything in CDI framework > have been done? Think it is smooth enough finally and avoid to mess up CDI, > allows to wait for a real async solution if needed at spec level > (concurreny utilities maybe) and doesn't prevent users to use asynchronism > in a proper way (compared to what we can do at framework level, ie have > composition for instance). > > > No need for test for standard async operation, it will work on SE and in > EE we?ll just have to use concurrency utilities to get a managed executor. > Regarding these operation the question will be do we introduce syntaxic > sugar to add support in CDI (an annotation to replace 2 or 3 lines of > code), right now I?d be tempted to answer ?no? but I may missed specific > use case like async interceptors. > > Again, the question here is for Async in event: as we don?t have hand on > observers invocation we have to enhance the event engine to support this > async behavior in order to get feedback of these async operations. > > > > >> Thanks for reading. >> >> Antoine >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150326/2de1fb8c/attachment.html From antoine at sabot-durand.net Thu Mar 26 05:59:27 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 26 Mar 2015 10:59:27 +0100 Subject: [cdi-dev] Previously on "Double end async events activation" In-Reply-To: References: <8C6A9139-6FF9-4A0B-B89B-AEAD06A7EB78@sabot-durand.net> Message-ID: <5A3152B6-3AC0-4B9E-9183-C540972339A7@sabot-durand.net> > Le 25 mars 2015 ? 20:28, Mark Paluch a ?crit : > > Hi Antoine, > > thanks for your input and this summary. > I placed my comments inline. > > Best regards, Mark > > >> Am 25.03.2015 um 14:45 schrieb Antoine Sabot-Durand : >> >> Hi all, >> >> >> This mail is quite long, but if you want to catch up on this double end activation for async event and bring your help on this point, you should take the 10 mn to read it and make your feedback. We?ve been talking of this for more thant on month now, so it?s normal that reflection and proposition take a few lines to synthesize >> Discussion is going back to solution avoiding this double activation stuff for async event. To avoid explaining again why we should care and the solution we already explore here is a small wrap up of previous episodes : >> >> 1) Why is it important to take time on this? >> Some of you may find we already spend too many time on this question, but remember. Async events are the 1st requested stuff from the community. It has been asked for a long time (Jira ticket is CDI-4). We didn?t provided a solution for CDI 1.1 so now people are waiting this feature and they probably hope it?ll be nicely designed. >> To make short : if we don?t deliver users will be very disappointed, if we propose a lousy solution people will be very critic. I know that it?s better to not deliver than delivering something we are not happy with, but we really should be careful here > > +1 CDI 2.0 without async events seems a no-go > >> >> >> 2) Why this double activation is needed? >> For the producer (fire()) side it?s rather obvious : we cannot magically change all synchronous event call to async. We need an handle on the work in progress (so a new method signature with CompletionStage), the payload mutation mechanism would break as all transactional events. So there?s no debate on fireAsync() > > +1 on fireAsync > > fireAsync triggers always asynchronous event processing. Currently we?re talking about interference between observers, but there are lots of other ways to do nasty things (e.g. modifying the payload from the firing thread). Any caller expects a method returning CompletionStage returning instantly, before any work is done. This leads to the point that disabling async on legacy observers would lead that fireAsync would return after those legacy observers are processed. yes, it will behave like a standard fire(). BTW the interesting part of my paragraph is "why it is needed on observer". As you seem to exclude that constraint in your following proposal, I?d like to read why you think so > >> >> >> 3) Implementing this observer activation >> >> I?m listing here all the solution to deal with this requirement. For some of them I?ll add the reason we won?t adopt it or my feeling about it >> > > I would add another case which might help to clarify @Priority as well: > > 1. fire with @Observers: same behavior as CDI 1.x > 2. fireAsync with @Observes: observers are processed in any order in sequence but in a different thread How do you deal with transactional observer or observer injecting contextual beans? > - nothing new until now - > 3. fireAsync with @Observers and @Concurrent (obviously not async to prevent confusion): Observers carrying @Concurrent are running concurrently to each other (that?s the double-opt in case). Observers not having @Concurrent are handled like point 2. observer methods are not allowed to to have both, @Priority and @Concurrent > 4. fire with @Observes and @Concurrent: Ability to use fire with some level of async. The behavior on the caller side does not change, fire waits until all observer method invocations are finished > > We should think also about ProcessObserverMethod. That?s the place where you can override any priority/(async|concurrent) settings and perhaps even the asyncSupported flag. This sort of opt-out is maybe sufficient. Now what happens, if asyncSupported=false and fireAsync? How about just skipping the observer? How can you choose observer to opt out? Do you suggest a case by case approach? Won?t it be a bit complicated for standard end user to add an extension for that. Mark, you?re describing additional interesting features for async event, but don?t react on the necessity of async support flag on observer and what would be your favorite choice. >> >> 4) What about changing default behavior for the local jar? >> >> Idea launched by some of us. We could extend the chosen scenario by activating AsyncSupport by default on all observer on the current jar (BDA). Since the main backward compatibility issue is linked to have different CDI jar from different owners and version we could give local control to the user for his own code and jars. >> That could be done in beans.xml like we did for bean-discovery with an async-event attributes for instance or in code by a config annotation or event in extension (but we probably should expose the BDA concept in SPI if we go that way?) > > This feels like a dirty hack and in the end you can?t tell how your application will behave. It?s like your ProcessObserverMethod solution but limited to one Bean Archive that user controls. It?s only a convenient way to replace async opt-in addition on 99 observer by one opt-out on 1 observer? > >> >> 5)Conclusion: >> Now you have the whole picture. If I missed things, tell me. If you like an idea please tell it, if you have a new idea or a different POV, feel free to speak. >> >> Thanks for reading. >> >> Antoine >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- 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/20150326/aaca47d7/attachment-0001.bin From antoine at sabot-durand.net Thu Mar 26 06:56:18 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 26 Mar 2015 11:56:18 +0100 Subject: [cdi-dev] Shutting down CDI Instances In-Reply-To: References: Message-ID: After second thought, option 1 is my favorite. It?ll be easier to dedicate this subclass to SE bootstrap instead of forbidden usage of some methods in CDI (option 2). Concerning option 3, I don?t see the benefit on option 1. > Le 24 mars 2015 ? 19:00, John D. Ament a ?crit : > > All, > > In discussion today w/ Jozef, we found that the way of shutting down a container in the proposed SE API precluded the notion that multiple containers could be running. While we're not necessarily going to handle multiple containers right now, we don't want to preclude the idea either. With that said, there were three different approaches though up to handle how to shutdown a launched container. it obivously would only work with an SE booted container, but part of this does give a pointer in how we may implement initialize. > > Option 1 - Subclass CDI. The returned CDI instance when bootstrapped would return this subclass of CDI that has shutdown capability. > > Option 2 - Add method to CDI. Add the shutdown method to CDI directly, and throw an exception if called in an EE environment. > > Option 3 - Return a different object all together when initializing. Return something else from initialize, e.g. CDIContext, which has a shutdown method when you initialize. That class would also have a getter for the CDI instance backing it. > > Let us know your thoughts. > > Thanks, > > John > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- 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/20150326/9bad8d07/attachment.bin From pmuir at redhat.com Thu Mar 26 07:51:05 2015 From: pmuir at redhat.com (Pete Muir) Date: Thu, 26 Mar 2015 11:51:05 +0000 Subject: [cdi-dev] Shutting down CDI Instances In-Reply-To: References: Message-ID: <6159D8A5-4C3D-4658-B892-B4E1BE11B480@redhat.com> I think I prefer (2). > On 26 Mar 2015, at 10:56, Antoine Sabot-Durand wrote: > > After second thought, option 1 is my favorite. It?ll be easier to dedicate this subclass to SE bootstrap instead of forbidden usage of some methods in CDI (option 2). Concerning option 3, I don?t see the benefit on option 1. > > > >> Le 24 mars 2015 ? 19:00, John D. Ament a ?crit : >> >> All, >> >> In discussion today w/ Jozef, we found that the way of shutting down a container in the proposed SE API precluded the notion that multiple containers could be running. While we're not necessarily going to handle multiple containers right now, we don't want to preclude the idea either. With that said, there were three different approaches though up to handle how to shutdown a launched container. it obivously would only work with an SE booted container, but part of this does give a pointer in how we may implement initialize. >> >> Option 1 - Subclass CDI. The returned CDI instance when bootstrapped would return this subclass of CDI that has shutdown capability. >> >> Option 2 - Add method to CDI. Add the shutdown method to CDI directly, and throw an exception if called in an EE environment. >> >> Option 3 - Return a different object all together when initializing. Return something else from initialize, e.g. CDIContext, which has a shutdown method when you initialize. That class would also have a getter for the CDI instance backing it. >> >> Let us know your thoughts. >> >> Thanks, >> >> John >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From rmannibucau at gmail.com Thu Mar 26 08:23:11 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Thu, 26 Mar 2015 13:23:11 +0100 Subject: [cdi-dev] Shutting down CDI Instances In-Reply-To: <6159D8A5-4C3D-4658-B892-B4E1BE11B480@redhat.com> References: <6159D8A5-4C3D-4658-B892-B4E1BE11B480@redhat.com> Message-ID: in these choices I prefer 2 as well maybe stupid but why not firing an event? evt.fire(new StandaloneContainerShutdown()); Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-03-26 12:51 GMT+01:00 Pete Muir : > I think I prefer (2). > > > On 26 Mar 2015, at 10:56, Antoine Sabot-Durand > wrote: > > > > After second thought, option 1 is my favorite. It?ll be easier to > dedicate this subclass to SE bootstrap instead of forbidden usage of some > methods in CDI (option 2). Concerning option 3, I don?t see the benefit on > option 1. > > > > > > > >> Le 24 mars 2015 ? 19:00, John D. Ament a > ?crit : > >> > >> All, > >> > >> In discussion today w/ Jozef, we found that the way of shutting down a > container in the proposed SE API precluded the notion that multiple > containers could be running. While we're not necessarily going to handle > multiple containers right now, we don't want to preclude the idea either. > With that said, there were three different approaches though up to handle > how to shutdown a launched container. it obivously would only work with an > SE booted container, but part of this does give a pointer in how we may > implement initialize. > >> > >> Option 1 - Subclass CDI. The returned CDI instance when bootstrapped > would return this subclass of CDI that has shutdown capability. > >> > >> Option 2 - Add method to CDI. Add the shutdown method to CDI directly, > and throw an exception if called in an EE environment. > >> > >> Option 3 - Return a different object all together when initializing. > Return something else from initialize, e.g. CDIContext, which has a > shutdown method when you initialize. That class would also have a getter > for the CDI instance backing it. > >> > >> Let us know your thoughts. > >> > >> Thanks, > >> > >> John > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150326/213f7633/attachment.html From mpaluch at paluch.biz Thu Mar 26 08:26:11 2015 From: mpaluch at paluch.biz (Mark Paluch) Date: Thu, 26 Mar 2015 13:26:11 +0100 Subject: [cdi-dev] Previously on "Double end async events activation" In-Reply-To: <5A3152B6-3AC0-4B9E-9183-C540972339A7@sabot-durand.net> References: <8C6A9139-6FF9-4A0B-B89B-AEAD06A7EB78@sabot-durand.net> <5A3152B6-3AC0-4B9E-9183-C540972339A7@sabot-durand.net> Message-ID: <592CEF2C-EB71-4F0E-931D-40427271CA20@paluch.biz> Hi Antoine, thanks for your response. I added my feedback inline. I fear, I got your last point (What about changing default behavior for the local jar) wrong and clarified my statement (see below). Best regards, Mark > Am 26.03.2015 um 10:59 schrieb Antoine Sabot-Durand : > >> >> Le 25 mars 2015 ? 20:28, Mark Paluch a ?crit : >> >> Hi Antoine, >> >> thanks for your input and this summary. >> I placed my comments inline. >> >> Best regards, Mark >> >> >>> Am 25.03.2015 um 14:45 schrieb Antoine Sabot-Durand : >>> >>> Hi all, >>> >>> >>> This mail is quite long, but if you want to catch up on this double end activation for async event and bring your help on this point, you should take the 10 mn to read it and make your feedback. We?ve been talking of this for more thant on month now, so it?s normal that reflection and proposition take a few lines to synthesize >>> Discussion is going back to solution avoiding this double activation stuff for async event. To avoid explaining again why we should care and the solution we already explore here is a small wrap up of previous episodes : >>> >>> 1) Why is it important to take time on this? >>> Some of you may find we already spend too many time on this question, but remember. Async events are the 1st requested stuff from the community. It has been asked for a long time (Jira ticket is CDI-4). We didn?t provided a solution for CDI 1.1 so now people are waiting this feature and they probably hope it?ll be nicely designed. >>> To make short : if we don?t deliver users will be very disappointed, if we propose a lousy solution people will be very critic. I know that it?s better to not deliver than delivering something we are not happy with, but we really should be careful here >> >> +1 CDI 2.0 without async events seems a no-go >> >>> >>> >>> 2) Why this double activation is needed? >>> For the producer (fire()) side it?s rather obvious : we cannot magically change all synchronous event call to async. We need an handle on the work in progress (so a new method signature with CompletionStage), the payload mutation mechanism would break as all transactional events. So there?s no debate on fireAsync() >> >> +1 on fireAsync >> >> fireAsync triggers always asynchronous event processing. Currently we?re talking about interference between observers, but there are lots of other ways to do nasty things (e.g. modifying the payload from the firing thread). Any caller expects a method returning CompletionStage returning instantly, before any work is done. This leads to the point that disabling async on legacy observers would lead that fireAsync would return after those legacy observers are processed. > > yes, it will behave like a standard fire(). > > BTW the interesting part of my paragraph is "why it is needed on observer". As you seem to exclude that constraint in your following proposal, I?d like to read why you think so I get your point, we want to restore old behavior in certain cases although observers are called using fireAsync and in the end it?s still sync (somehow). The invoker of fireAsync needs to be aware of what he/she is causing by that and that observers of a certain event might not be capable (yet) of handling the async nature. Same would apply if any client code would be called by an external authority in a callable/runnable instead of a sync way. A happy coder?s approach of "hey, there?s a fireAsync, let?s use it" on existing events does not work here, too much can be broken. If someone uses a certain functionality, he/she must be aware of the consequences. I like the approach of providing the new fireAsync method, so you can explicitly opt-in. > >> >>> >>> >>> 3) Implementing this observer activation >>> >>> I?m listing here all the solution to deal with this requirement. For some of them I?ll add the reason we won?t adopt it or my feeling about it >>> >> >> I would add another case which might help to clarify @Priority as well: >> >> 1. fire with @Observers: same behavior as CDI 1.x >> 2. fireAsync with @Observes: observers are processed in any order in sequence but in a different thread > > How do you deal with transactional observer or observer injecting contextual beans? I?d propagate the context/scope of contextual beans from the caller of fireAsync. These instances behave like they would have been fired the old way. I?m aware that especially @RequestScoped and even @SessionScoped (plus custom scopes) can get cleared while an async event is being processed. It?s a no-go raising context not active during the request. Creating new instances might be not useful since these instances can carry data which is needed for processing. Same applies for transactional observers. I understood from Jozef, that some transactional observers are notified already on different threads which is sort of semi-async. It?s at least decoupled from the firing thread. > >> - nothing new until now - >> 3. fireAsync with @Observers and @Concurrent (obviously not async to prevent confusion): Observers carrying @Concurrent are running concurrently to each other (that?s the double-opt in case). Observers not having @Concurrent are handled like point 2. observer methods are not allowed to to have both, @Priority and @Concurrent >> 4. fire with @Observes and @Concurrent: Ability to use fire with some level of async. The behavior on the caller side does not change, fire waits until all observer method invocations are finished >> >> We should think also about ProcessObserverMethod. That?s the place where you can override any priority/(async|concurrent) settings and perhaps even the asyncSupported flag. This sort of opt-out is maybe sufficient. Now what happens, if asyncSupported=false and fireAsync? How about just skipping the observer? > > How can you choose observer to opt out? Do you suggest a case by case approach? Won?t it be a bit complicated for standard end user to add an extension for that. I expect the opt-out case as exception. Therefore this approach. I?m with you, if the opt-out becomes a standard case, an extension is too complex. > > Mark, you?re describing additional interesting features for async event, but don?t react on the necessity of async support flag on observer and what would be your favorite choice. I?ve a different viewpoint on the necessity of the async support flag on the observer. If you decide to use fireAsync on the one side (which might be located in framework code not under own control) and you decide to use a newer version of the framework jar, you?re required to adjust your code to keep it working. Blindly using fireAsync is a no-go from my perspective. I like @ObservesAsync since it is a marker for new functionality. We do not pollute the class path with a second @Async and since we have already double opt-in (fire and @Observes) it would fit into the current patterns. > >>> >>> 4) What about changing default behavior for the local jar? >>> >>> Idea launched by some of us. We could extend the chosen scenario by activating AsyncSupport by default on all observer on the current jar (BDA). Since the main backward compatibility issue is linked to have different CDI jar from different owners and version we could give local control to the user for his own code and jars. >>> That could be done in beans.xml like we did for bean-discovery with an async-event attributes for instance or in code by a config annotation or event in extension (but we probably should expose the BDA concept in SPI if we go that way?) >> >> This feels like a dirty hack and in the end you can?t tell how your application will behave. > > It?s like your ProcessObserverMethod solution but limited to one Bean Archive that user controls. It?s only a convenient way to replace async opt-in addition on 99 observer by one opt-out on 1 observer? I oversaw the bean archive limitation. If we really expose more parts of BDA in the SPI it can lead to some generic control over CDI for the deployment of the user and has the chance of getting a sort of control center for CDI within one deployment (control over multiple BDA?s). Could be also useful for specific enabling/disabling of extensions in the future. > >> >>> >>> 5)Conclusion: >>> Now you have the whole picture. If I missed things, tell me. If you like an idea please tell it, if you have a new idea or a different POV, feel free to speak. >>> >>> Thanks for reading. >>> >>> Antoine >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150326/da4db228/attachment-0001.html From antoine at sabot-durand.net Tue Mar 31 07:44:38 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 31 Mar 2015 13:44:38 +0200 Subject: [cdi-dev] No meeting today Message-ID: Hi all, I have to cancel the meeting today for personal reason. Let?s continue the discussion on SE and async on ML. 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/20150331/325a080d/attachment.bin From j.j.snyder at oracle.com Tue Mar 31 11:19:55 2015 From: j.j.snyder at oracle.com (JJ Snyder) Date: Tue, 31 Mar 2015 11:19:55 -0400 Subject: [cdi-dev] Shutting down CDI Instances In-Reply-To: References: Message-ID: <551ABB1B.7060908@oracle.com> Option 2 On 03/24/2015 02:00 PM, John D. Ament wrote: > All, > > In discussion today w/ Jozef, we found that the way of shutting down a > container in the proposed SE API precluded the notion that multiple > containers could be running. While we're not necessarily going to > handle multiple containers right now, we don't want to preclude the > idea either. With that said, there were three different approaches > though up to handle how to shutdown a launched container. it > obivously would only work with an SE booted container, but part of > this does give a pointer in how we may implement initialize. > > Option 1 - Subclass CDI. The returned CDI instance when bootstrapped > would return this subclass of CDI that has shutdown capability. > > Option 2 - Add method to CDI. Add the shutdown method to CDI > directly, and throw an exception if called in an EE environment. > > Option 3 - Return a different object all together when initializing. > Return something else from initialize, e.g. CDIContext, which has a > shutdown method when you initialize. That class would also have a > getter for the CDI instance backing it. > > Let us know your thoughts. > > Thanks, > > John > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150331/7b751587/attachment.html From rmannibucau at gmail.com Tue Mar 31 12:00:32 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 31 Mar 2015 18:00:32 +0200 Subject: [cdi-dev] async activation on observers, why not CompletableFuture Message-ID: Hi guys, on async topic if I followed we are at the point where we are looking for an activation on the observer side. Since Java 8 has now CompletableFuture it would be great to use it. Today the spec doesnt use observer returned values so it is mainly a bad practise to have one even if not strictly forbidden - BTW never saw it in real applications - plus spec is not compatible - not specified at all - with CompletableFuture since it is a new API so we can use it as a marker. This is quite interesting for few reasons: 1- we have our double activation 2- API is user friendly (observer is async and has an async signature) 3- open door for future async enhancements (hopefully not in CDI) with composition of these observers Only point I'm not sure is should these observers support sync events. I don't see anything blocking to do it but can have missed something. wdyt? Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150331/74d3d3ac/attachment.html From sven.linstaedt at gmail.com Tue Mar 31 12:15:52 2015 From: sven.linstaedt at gmail.com (Sven Linstaedt) Date: Tue, 31 Mar 2015 18:15:52 +0200 Subject: [cdi-dev] async activation on observers, why not CompletableFuture In-Reply-To: References: Message-ID: Hi Romain, I am not sure, I have fully understand how an observer with CompletableFuture could look like. Could you give us an example? Afair CompletableFuture was considered to be used in the "trigger" side in order to track async event invocation completion. br, Sven 2015-03-31 18:00 GMT+02:00 Romain Manni-Bucau : > Hi guys, > > on async topic if I followed we are at the point where we are looking for > an activation on the observer side. > > Since Java 8 has now CompletableFuture it would be great to use it. Today > the spec doesnt use observer returned values so it is mainly a bad practise > to have one even if not strictly forbidden - BTW never saw it in real > applications - plus spec is not compatible - not specified at all - > with CompletableFuture since it is a new API so we can use it as a marker. > > This is quite interesting for few reasons: > 1- we have our double activation > 2- API is user friendly (observer is async and has an async signature) > 3- open door for future async enhancements (hopefully not in CDI) with > composition of these observers > > > Only point I'm not sure is should these observers support sync events. I > don't see anything blocking to do it but can have missed something. > > > wdyt? > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150331/961a90b3/attachment.html From rmannibucau at gmail.com Tue Mar 31 12:21:12 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 31 Mar 2015 18:21:12 +0200 Subject: [cdi-dev] async activation on observers, why not CompletableFuture In-Reply-To: References: Message-ID: // fire side event.fireAsync(new LetTheWorldKnow()).thenRun(() -> System.out.println("We did it!")); // observer side CompletableFuture iWantToKnow(@Observes LetTheWorldKnow event) {} // impl behavior would be like CompletableFuture.allOf(allObserverReturnedInstances) to be aligned on CompletableFuture behavior I think Am I clearer? Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-03-31 18:15 GMT+02:00 Sven Linstaedt : > Hi Romain, > > I am not sure, I have fully understand how an observer with CompletableFuture could > look like. Could you give us an example? > > Afair CompletableFuture was considered to be used in the "trigger" side > in order to track async event invocation completion. > > br, Sven > > 2015-03-31 18:00 GMT+02:00 Romain Manni-Bucau : > >> Hi guys, >> >> on async topic if I followed we are at the point where we are looking for >> an activation on the observer side. >> >> Since Java 8 has now CompletableFuture it would be great to use it. Today >> the spec doesnt use observer returned values so it is mainly a bad practise >> to have one even if not strictly forbidden - BTW never saw it in real >> applications - plus spec is not compatible - not specified at all - >> with CompletableFuture since it is a new API so we can use it as a marker. >> >> This is quite interesting for few reasons: >> 1- we have our double activation >> 2- API is user friendly (observer is async and has an async signature) >> 3- open door for future async enhancements (hopefully not in CDI) with >> composition of these observers >> >> >> Only point I'm not sure is should these observers support sync events. I >> don't see anything blocking to do it but can have missed something. >> >> >> wdyt? >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150331/72d7146b/attachment-0001.html