From issues at jboss.org Tue Dec 2 02:56:39 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Tue, 2 Dec 2014 02:56:39 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-494) Clarify that a type variable that resolves to a wildcard is not resolvable In-Reply-To: References: Message-ID: Jozef Hartinger created CDI-494: ----------------------------------- Summary: Clarify that a type variable that resolves to a wildcard is not resolvable Key: CDI-494 URL: https://issues.jboss.org/browse/CDI-494 Project: CDI Specification Issues Issue Type: Clarification Components: Events Affects Versions: 1.2.Final Reporter: Jozef Hartinger This is implicit but I've seen people confused about this several times. See e.g. https://issues.jboss.org/browse/WELD-1799 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From antoine at sabot-durand.net Wed Dec 3 08:45:50 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 3 Dec 2014 14:45:50 +0100 Subject: [cdi-dev] Cancelling today's meeting Message-ID: <780D9C61-8DA4-490C-B2A5-F3F0C6EF63E4@sabot-durand.net> Hi guys, Unfortunately I have to cancel today?s meeting. See you next week. By then I?ll provide revamping of events workshop doc with all your feedback. Antoine From pavel.bucek at oracle.com Wed Dec 3 11:55:27 2014 From: pavel.bucek at oracle.com (Pavel Bucek) Date: Wed, 03 Dec 2014 17:55:27 +0100 Subject: [cdi-dev] New Servlet related scope - @UpgradeScoped (?) Message-ID: <547F407F.1080505@oracle.com> Hi all, I'm trying to figure out how to solve issue in JSR 356 - Java API for WebSocket, related to CDI scope usable from WebSocket endpoints. Problem is, that "standard" scopes do not apply, because there is no @RequestScoped (http response is already sent), HttpSession does not need to be created and the rest does not seem to be applicable, ... I believe that CDI specification should define @UpgradeScoped, which would cover usages of HttpUpgradeHandler from Servlet API. (Similarly as it does for @RequestScoped, @SessionScoped, ... ) What are your thoughts about this? Thanks and regards, Pavel From arjan.tijms at gmail.com Wed Dec 3 13:44:35 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Wed, 3 Dec 2014 19:44:35 +0100 Subject: [cdi-dev] New Servlet related scope - @UpgradeScoped (?) In-Reply-To: <547F407F.1080505@oracle.com> References: <547F407F.1080505@oracle.com> Message-ID: Hi, On Wednesday, December 3, 2014, Pavel Bucek wrote: > Hi all, > > I'm trying to figure out how to solve issue in JSR 356 - Java API for > WebSocket, related to CDI scope usable from WebSocket endpoints. Problem > is, that "standard" scopes do not apply, because there is no > @RequestScoped (http response is already sent), HttpSession does not > need to be created and the rest does not seem to be applicable, ... > > I believe that CDI specification should define @UpgradeScoped, which > would cover usages of HttpUpgradeHandler from Servlet API. (Similarly as > it does for @RequestScoped, @SessionScoped, ... ) Wouldn't it be a better option to have WebSocket define that scope, using CDI to implement it? > > What are your thoughts about this? > > Thanks and regards, > Pavel > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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/20141203/a3bfd51d/attachment.html From mkouba at redhat.com Thu Dec 4 03:00:53 2014 From: mkouba at redhat.com (Martin Kouba) Date: Thu, 04 Dec 2014 09:00:53 +0100 Subject: [cdi-dev] New Servlet related scope - @UpgradeScoped (?) In-Reply-To: References: <547F407F.1080505@oracle.com> Message-ID: <548014B5.7020000@redhat.com> Dne 3.12.2014 v 19:44 arjan tijms napsal(a): > Hi, > > On Wednesday, December 3, 2014, Pavel Bucek > wrote: > > Hi all, > > I'm trying to figure out how to solve issue in JSR 356 - Java API for > WebSocket, related to CDI scope usable from WebSocket endpoints. Problem > is, that "standard" scopes do not apply, because there is no > @RequestScoped (http response is already sent), HttpSession does not > need to be created and the rest does not seem to be applicable, ... > > I believe that CDI specification should define @UpgradeScoped, which > would cover usages of HttpUpgradeHandler from Servlet API. (Similarly as > it does for @RequestScoped, @SessionScoped, ... ) > > > Wouldn't it be a better option to have WebSocket define that scope, > using CDI to implement it? +1 It's the same case as JSF @FlowScoped. > > > What are your thoughts about this? > > Thanks and regards, > Pavel > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.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 pavel.bucek at oracle.com Thu Dec 4 03:28:07 2014 From: pavel.bucek at oracle.com (Pavel Bucek) Date: Thu, 04 Dec 2014 09:28:07 +0100 Subject: [cdi-dev] New Servlet related scope - @UpgradeScoped (?) In-Reply-To: References: <547F407F.1080505@oracle.com> Message-ID: <54801B17.1050102@oracle.com> Hello Arjan, On 03/12/14 19:44, arjan tijms wrote: > Hi, > > On Wednesday, December 3, 2014, Pavel Bucek > wrote: > > Hi all, > > I'm trying to figure out how to solve issue in JSR 356 - Java API for > WebSocket, related to CDI scope usable from WebSocket endpoints. > Problem > is, that "standard" scopes do not apply, because there is no > @RequestScoped (http response is already sent), HttpSession does not > need to be created and the rest does not seem to be applicable, ... > > I believe that CDI specification should define @UpgradeScoped, which > would cover usages of HttpUpgradeHandler from Servlet API. > (Similarly as > it does for @RequestScoped, @SessionScoped, ... ) > > > Wouldn't it be a better option to have WebSocket define that scope, > using CDI to implement it? That is one possibility, but @UpgradeScoped would be more general than just for WebSocket - it would apply for all HTTP/1.1+ Upgrade applications. In my eyes, it is something which was forgotten to do in Java EE 7 release, since HttpUpgradeHandler was introduced in it. Also please note, that other Servlet related scopes are already in CDI spec, so it seems like it belongs there more than anywhere else. This might have multiple reasons - for example, you can easily define relationship between @UpgradeScoped and others, already existing ones. In this sense, CDI specification now depends on Servlet API (it references some of the classes defined in it), but Servlet does not do that for CDI. I don't think that Servlet spec should introduce similar dependency just because of new scope. Thanks, Pavel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141204/a0d3df36/attachment.html From mkouba at redhat.com Thu Dec 4 04:04:56 2014 From: mkouba at redhat.com (Martin Kouba) Date: Thu, 04 Dec 2014 10:04:56 +0100 Subject: [cdi-dev] New Servlet related scope - @UpgradeScoped (?) In-Reply-To: <54801B17.1050102@oracle.com> References: <547F407F.1080505@oracle.com> <54801B17.1050102@oracle.com> Message-ID: <548023B8.2060404@redhat.com> Dne 4.12.2014 v 09:28 Pavel Bucek napsal(a): > Hello Arjan, > > On 03/12/14 19:44, arjan tijms wrote: >> Hi, >> >> On Wednesday, December 3, 2014, Pavel Bucek > > wrote: >> >> Hi all, >> >> I'm trying to figure out how to solve issue in JSR 356 - Java API for >> WebSocket, related to CDI scope usable from WebSocket endpoints. >> Problem >> is, that "standard" scopes do not apply, because there is no >> @RequestScoped (http response is already sent), HttpSession does not >> need to be created and the rest does not seem to be applicable, ... >> >> I believe that CDI specification should define @UpgradeScoped, which >> would cover usages of HttpUpgradeHandler from Servlet API. >> (Similarly as >> it does for @RequestScoped, @SessionScoped, ... ) >> >> >> Wouldn't it be a better option to have WebSocket define that scope, >> using CDI to implement it? > > That is one possibility, but @UpgradeScoped would be more general than > just for WebSocket - it would apply for all HTTP/1.1+ Upgrade > applications. In my eyes, it is something which was forgotten to do in > Java EE 7 release, since HttpUpgradeHandler was introduced in it. > > Also please note, that other Servlet related scopes are already in CDI > spec, so it seems like it belongs there more than anywhere else. This > might have multiple reasons - for example, you can easily define > relationship between @UpgradeScoped and others, already existing ones. > In this sense, CDI specification now depends on Servlet API (it > references some of the classes defined in it), but Servlet does not do > that for CDI. I don't think that Servlet spec should introduce similar > dependency just because of new scope. That's a good point. However, I don't think it's a good path to follow. I mean if it were in CDI spec, CDI implementations would be required to implement this. However, Servlet spec is not very clear in many areas and doesn't always provide a powerful enough SPI. Even now there are technical issues with similar requirements (e.g. @RequestScoped during AsyncListener invocations). I'm not so sure about HttpUpgradeHandler though... > > Thanks, > Pavel > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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 antonio.goncalves at gmail.com Thu Dec 4 04:17:48 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Thu, 4 Dec 2014 10:17:48 +0100 Subject: [cdi-dev] New Servlet related scope - @UpgradeScoped (?) In-Reply-To: <54801B17.1050102@oracle.com> References: <547F407F.1080505@oracle.com> <54801B17.1050102@oracle.com> Message-ID: Hi FYI we are hoping to have no Servlet related topics in the CDI 2.0 specification. The idea is for other specifications to use CDI to create their own scope (@ViewScoped/@FlowScoped in JSF, but also @TransactionScoped in JTA). Following this logic, the @UpgradeScoped would make sense in the WebSocket spec. Antonio On Thu, Dec 4, 2014 at 9:28 AM, Pavel Bucek wrote: > Hello Arjan, > > On 03/12/14 19:44, arjan tijms wrote: > > Hi, > > On Wednesday, December 3, 2014, Pavel Bucek > wrote: > >> Hi all, >> >> I'm trying to figure out how to solve issue in JSR 356 - Java API for >> WebSocket, related to CDI scope usable from WebSocket endpoints. Problem >> is, that "standard" scopes do not apply, because there is no >> @RequestScoped (http response is already sent), HttpSession does not >> need to be created and the rest does not seem to be applicable, ... >> >> I believe that CDI specification should define @UpgradeScoped, which >> would cover usages of HttpUpgradeHandler from Servlet API. (Similarly as >> it does for @RequestScoped, @SessionScoped, ... ) > > > Wouldn't it be a better option to have WebSocket define that scope, using > CDI to implement it? > > > That is one possibility, but @UpgradeScoped would be more general than > just for WebSocket - it would apply for all HTTP/1.1+ Upgrade applications. > In my eyes, it is something which was forgotten to do in Java EE 7 release, > since HttpUpgradeHandler was introduced in it. > > Also please note, that other Servlet related scopes are already in CDI > spec, so it seems like it belongs there more than anywhere else. This might > have multiple reasons - for example, you can easily define relationship > between @UpgradeScoped and others, already existing ones. In this sense, > CDI specification now depends on Servlet API (it references some of the > classes defined in it), but Servlet does not do that for CDI. I don't think > that Servlet spec should introduce similar dependency just because of new > scope. > > Thanks, > Pavel > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141204/1facbab2/attachment-0001.html From arjan.tijms at gmail.com Thu Dec 4 04:30:06 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 4 Dec 2014 10:30:06 +0100 Subject: [cdi-dev] New Servlet related scope - @UpgradeScoped (?) In-Reply-To: <54801B17.1050102@oracle.com> References: <547F407F.1080505@oracle.com> <54801B17.1050102@oracle.com> Message-ID: Hi there, On Thursday, December 4, 2014, Pavel Bucek wrote: > Hello Arjan, > > On 03/12/14 19:44, arjan tijms wrote: > > Hi, > > On Wednesday, December 3, 2014, Pavel Bucek > wrote: > >> Hi all, >> >> I'm trying to figure out how to solve issue in JSR 356 - Java API for >> WebSocket, related to CDI scope usable from WebSocket endpoints. Problem >> is, that "standard" scopes do not apply, because there is no >> @RequestScoped (http response is already sent), HttpSession does not >> need to be created and the rest does not seem to be applicable, ... >> >> I believe that CDI specification should define @UpgradeScoped, which >> would cover usages of HttpUpgradeHandler from Servlet API. (Similarly as >> it does for @RequestScoped, @SessionScoped, ... ) > > > Wouldn't it be a better option to have WebSocket define that scope, using > CDI to implement it? > > > That is one possibility, but @UpgradeScoped would be more general than > just for WebSocket - it would apply for all HTTP/1.1+ Upgrade applications. > Okay, so in a more broader application than just WebSocket it could be defined somewhere lower in the spec hierarchy. If it's specific to HTTP upgrades as you mention, then Servlet may be the next candidate to consider. > In my eyes, it is something which was forgotten to do in Java EE 7 > release, since HttpUpgradeHandler was introduced in it. > > Also please note, that other Servlet related scopes are already in CDI > spec, so it seems like it belongs there more than anywhere else. > But some of these may not actually belong there. They may have been put there originally since as a new spec that had yet to be proven, CDI could not right away ask other specs to support it. There are discussions going on to move some of the Servlet things from CDI to Servlet. > This might have multiple reasons - for example, you can easily define > relationship between @UpgradeScoped and others, already existing ones. In > this sense, CDI specification now depends on Servlet API (it references > some of the classes defined in it), but Servlet does not do that for CDI. I > don't think that Servlet spec should introduce similar dependency just > because of new scope. > There are plenty of other reasons too ;) For Servlet I expect the dependencies to be optional. Servlet in a EE environment will then provide scope X & Y, and producers for types Q & R, but it will continue to run standalone without needing any CDI. In short, it would provides things for CDI then but in its core wouldn't need CDI. Just my 2 cents ;) > > > Thanks, > Pavel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141204/ffa9eaac/attachment.html From pavel.bucek at oracle.com Thu Dec 4 04:39:46 2014 From: pavel.bucek at oracle.com (Pavel Bucek) Date: Thu, 04 Dec 2014 10:39:46 +0100 Subject: [cdi-dev] New Servlet related scope - @UpgradeScoped (?) In-Reply-To: References: <547F407F.1080505@oracle.com> <54801B17.1050102@oracle.com> Message-ID: <54802BE2.5060307@oracle.com> Hi Antonio, I saw one thread about moving Servlet related scopes to servlet spec (I agree with that step!), but there was no clear conclusion stating that it will actually happen. Just one correction - @UpgradeScoped belongs to Servlet spec; If you would want to introduce something into WebSocket spec, it would need to be something like @WebSocketSessionScoped; upgrade is defined in Servlet and if there is any scope derived from it, it should be there. @ViewScoped/@FlowScoped are different - there are specific to JSF. @UpgradeScoped is specific to Servlet and WebSocket spec just depends on that. Regards, Pavel On 04/12/14 10:17, Antonio Goncalves wrote: > Hi > > FYI we are hoping to have no Servlet related topics in the CDI 2.0 > specification. The idea is for other specifications to use CDI to > create their own scope (@ViewScoped/@FlowScoped in JSF, but also > @TransactionScoped in JTA). Following this logic, the @UpgradeScoped > would make sense in the WebSocket spec. > > Antonio > > On Thu, Dec 4, 2014 at 9:28 AM, Pavel Bucek > wrote: > > Hello Arjan, > > On 03/12/14 19:44, arjan tijms wrote: >> Hi, >> >> On Wednesday, December 3, 2014, Pavel Bucek >> > wrote: >> >> Hi all, >> >> I'm trying to figure out how to solve issue in JSR 356 - Java >> API for >> WebSocket, related to CDI scope usable from WebSocket >> endpoints. Problem >> is, that "standard" scopes do not apply, because there is no >> @RequestScoped (http response is already sent), HttpSession >> does not >> need to be created and the rest does not seem to be >> applicable, ... >> >> I believe that CDI specification should define >> @UpgradeScoped, which >> would cover usages of HttpUpgradeHandler from Servlet API. >> (Similarly as >> it does for @RequestScoped, @SessionScoped, ... ) >> >> >> Wouldn't it be a better option to have WebSocket define that >> scope, using CDI to implement it? > > That is one possibility, but @UpgradeScoped would be more general > than just for WebSocket - it would apply for all HTTP/1.1+ Upgrade > applications. In my eyes, it is something which was forgotten to > do in Java EE 7 release, since HttpUpgradeHandler was introduced > in it. > > Also please note, that other Servlet related scopes are already in > CDI spec, so it seems like it belongs there more than anywhere > else. This might have multiple reasons - for example, you can > easily define relationship between @UpgradeScoped and others, > already existing ones. In this sense, CDI specification now > depends on Servlet API (it references some of the classes defined > in it), but Servlet does not do that for CDI. I don't think that > Servlet spec should introduce similar dependency just because of > new scope. > > Thanks, > Pavel > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider > licenses the code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > ideas provided on this list, the provider waives all patent and > other intellectual property rights inherent in such information. > > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter > | LinkedIn > | Pluralsight > | > Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141204/40456878/attachment.html From pavel.bucek at oracle.com Thu Dec 4 04:51:32 2014 From: pavel.bucek at oracle.com (Pavel Bucek) Date: Thu, 04 Dec 2014 10:51:32 +0100 Subject: [cdi-dev] New Servlet related scope - @UpgradeScoped (?) In-Reply-To: References: <547F407F.1080505@oracle.com> <54801B17.1050102@oracle.com> Message-ID: <54802EA4.5090604@oracle.com> please see inline. On 04/12/14 10:30, arjan tijms wrote: > Hi there, > > On Thursday, December 4, 2014, Pavel Bucek > wrote: > > Hello Arjan, > > On 03/12/14 19:44, arjan tijms wrote: >> Hi, >> >> On Wednesday, December 3, 2014, Pavel Bucek >> > > wrote: >> >> Hi all, >> >> I'm trying to figure out how to solve issue in JSR 356 - Java >> API for >> WebSocket, related to CDI scope usable from WebSocket >> endpoints. Problem >> is, that "standard" scopes do not apply, because there is no >> @RequestScoped (http response is already sent), HttpSession >> does not >> need to be created and the rest does not seem to be >> applicable, ... >> >> I believe that CDI specification should define >> @UpgradeScoped, which >> would cover usages of HttpUpgradeHandler from Servlet API. >> (Similarly as >> it does for @RequestScoped, @SessionScoped, ... ) >> >> >> Wouldn't it be a better option to have WebSocket define that >> scope, using CDI to implement it? > > That is one possibility, but @UpgradeScoped would be more general > than just for WebSocket - it would apply for all HTTP/1.1+ Upgrade > applications. > > Okay, so in a more broader application than just WebSocket it could be > defined somewhere lower in the spec hierarchy. If it's specific to > HTTP upgrades as you mention, then Servlet may be the next candidate > to consider. As you most likely already know, Servlet spec does not contain any scope definition (yet). The natural way for me is to add the new stuff somewhere near the "old" declaration, which would seem logical for all users. (please see below for comment to possible move of these declarations to Servlet spec). > In my eyes, it is something which was forgotten to do in Java EE > 7 release, since HttpUpgradeHandler was introduced in it. > > Also please note, that other Servlet related scopes are already in > CDI spec, so it seems like it belongs there more than anywhere else. > > > But some of these may not actually belong there. They may have been > put there originally since as a new spec that had yet to be proven, > CDI could not right away ask other specs to support it. > > There are discussions going on to move some of the Servlet things from > CDI to Servlet. Do you know about thread like that somewhere? (CDI / Servlet mailing list)? I'm for moving this to Servlet, since it seems like it should belong there, but current scope definitions are well established and known and deprecating/moving the @*Scoped declarations might not be perceived as positive change. Anyway, I'd like to joint that discussion to make sure that the new scope will be introduced. > This might have multiple reasons - for example, you can easily > define relationship between @UpgradeScoped and others, already > existing ones. In this sense, CDI specification now depends on > Servlet API (it references some of the classes defined in it), but > Servlet does not do that for CDI. I don't think that Servlet spec > should introduce similar dependency just because of new scope. > > > There are plenty of other reasons too ;) For Servlet I expect the > dependencies to be optional. Servlet in a EE environment will then > provide scope X & Y, and producers for types Q & R, but it will > continue to run standalone without needing any CDI. In short, it > would provides things for CDI then but in its core wouldn't need CDI. > > Just my 2 cents ;) Thanks! :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141204/dfc4b0da/attachment-0001.html From jharting at redhat.com Fri Dec 5 10:50:09 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Fri, 05 Dec 2014 16:50:09 +0100 Subject: [cdi-dev] microbenchmark for CDI performance In-Reply-To: <544657F2.3050604@redhat.com> References: <1413885572.13711.YahooMailNeo@web28905.mail.ir2.yahoo.com> <544646FD.7090801@redhat.com> <54464C68.5020105@redhat.com> <1413895586.91151.YahooMailNeo@web28902.mail.ir2.yahoo.com> <544657F2.3050604@redhat.com> Message-ID: <5481D431.3010601@redhat.com> Actually, I was wrong. This *is* a valid optimization for CDI 1.0. It however *is not valid* for CDI 1.1+ as it breaks AlterableContext.destroy(). This is fixed in Weld 2.2.7.Final http://weld.cdi-spec.org/download/ On 10/21/2014 02:56 PM, Jozef Hartinger wrote: > For certain combinations of scopes this is a perfectly legal > optimization ;-) It's even mentioned in the spec (see 6.5.5). > > On 10/21/2014 02:46 PM, Mark Struberg wrote: >> Folks, you really scare me a bit! >> >> I debugged into it and for the first BeanManger#getReference I get a proxy. >> >> But for all other BeanManager#getReference I get the bare metal SimpleBeanWithoutInterceptor WITHOUT ANY PROXY. >> Can you confirm this? >> If so, then please tell me how you make this Serializable if it gets stored e.g in a Http Session? >> >> >> This is just not conform to the CDI spec I fear. I even consider this a blocker bug... >> >> LieGrue, >> strub >> >> >> >>> On Tuesday, 21 October 2014, 14:07, Jozef Hartinger wrote: >>>> Btw I've run your benchmark locally and observed the following results: >>> OWB 1.2.6: 9827ms >>> Weld 2.2.5.Final: 20ms >>> >>> ;-) >>> >>> I did however tweak the test a bit so that Weld's optimizations can be >>> leveraged[1]. I admit that in certain situations (like your test without >>> my change) Weld performs worse than it should and this is a good input >>> for us. >>> >>> As for the NPE you observed not sure what is going on there. Perhaps >>> WeldContextControl implementation in DeltaSpike is not really thread safe? >>> >>> Jozef >>> >>> [1] https://github.com/jharting/cdi-performance/commits/weld >>> >>> On 10/21/2014 01:43 PM, Jozef Hartinger wrote: >>>> Hi Mark, >>>> >>>> thanks for showcasting your new feature. Great to see OWB getting >>>> faster! As for the micro benchmark I suggest that you check out JMH[1]. >>>> >>>> If you need an input from the Weld team, use weld-dev at lists.jboss.org >>>> >>>> [1] http://openjdk.java.net/projects/code-tools/jmh/ >>>> >>>> On 10/21/2014 11:59 AM, Mark Struberg wrote: >>>>> Hi! >>>>> >>>>> Weld folks, I need some help with a micro benchmark: >>>>> >>>>> You know we've talked about disk footprint in SE, so I hacked >>> together a small microbenchmark and as a side effect we also got what is really >>> needed to have CDI running >>>>> https://github.com/struberg/cdi-performance >>>>> >>>>> I'm curious about missing some dependency excludes for Weld. >>>>> >>>>> could you please run >>>>> >>>>> $> mvn clean dependency:copy-dependencies -DincludeScope=compile >>> -PWeld -Dweld.version=2.2.5.Final >>>>> $> ls -al target/dependency/ >>>>> >>>>> and tell me which dependencies can be without having some CDI >>> functionality missing? >>>>> Feel free to pimp the pom and ship a pull request. >>>>> >>>>> >>>>> txs and 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. >>> > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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 pavel.bucek at oracle.com Fri Dec 5 11:58:04 2014 From: pavel.bucek at oracle.com (Pavel Bucek) Date: Fri, 05 Dec 2014 17:58:04 +0100 Subject: [cdi-dev] New Servlet related scope - @UpgradeScoped (?) In-Reply-To: <548023B8.2060404@redhat.com> References: <547F407F.1080505@oracle.com> <54801B17.1050102@oracle.com> <548023B8.2060404@redhat.com> Message-ID: <5481E41C.40400@oracle.com> please see inline. On 04/12/14 10:04, Martin Kouba wrote: > Dne 4.12.2014 v 09:28 Pavel Bucek napsal(a): >> Hello Arjan, >> >> On 03/12/14 19:44, arjan tijms wrote: >>> Hi, >>> >>> On Wednesday, December 3, 2014, Pavel Bucek >> > wrote: >>> >>> Hi all, >>> >>> I'm trying to figure out how to solve issue in JSR 356 - Java API for >>> WebSocket, related to CDI scope usable from WebSocket endpoints. >>> Problem >>> is, that "standard" scopes do not apply, because there is no >>> @RequestScoped (http response is already sent), HttpSession does not >>> need to be created and the rest does not seem to be applicable, ... >>> >>> I believe that CDI specification should define @UpgradeScoped, which >>> would cover usages of HttpUpgradeHandler from Servlet API. >>> (Similarly as >>> it does for @RequestScoped, @SessionScoped, ... ) >>> >>> >>> Wouldn't it be a better option to have WebSocket define that scope, >>> using CDI to implement it? >> That is one possibility, but @UpgradeScoped would be more general than >> just for WebSocket - it would apply for all HTTP/1.1+ Upgrade >> applications. In my eyes, it is something which was forgotten to do in >> Java EE 7 release, since HttpUpgradeHandler was introduced in it. >> >> Also please note, that other Servlet related scopes are already in CDI >> spec, so it seems like it belongs there more than anywhere else. This >> might have multiple reasons - for example, you can easily define >> relationship between @UpgradeScoped and others, already existing ones. >> In this sense, CDI specification now depends on Servlet API (it >> references some of the classes defined in it), but Servlet does not do >> that for CDI. I don't think that Servlet spec should introduce similar >> dependency just because of new scope. > That's a good point. However, I don't think it's a good path to follow. > I mean if it were in CDI spec, CDI implementations would be required to > implement this. However, Servlet spec is not very clear in many areas > and doesn't always provide a powerful enough SPI. Even now there are > technical issues with similar requirements (e.g. @RequestScoped during > AsyncListener invocations). I'm not so sure about HttpUpgradeHandler > though... And what if the @UpgradeScoped definition would need to state something like "this scope is part of @ApplicationScoped"? That would result even in more confusion and cross references CDI to Servlet and vice versa. I could see this being part of Servlet spec only if all other "Servlet-related" scopes are there as well. Con somebody suggest what should I do next? I can file an issue against CDI spec and even against Servlet spec, but my feeling is that it might be deferred on both issue trackers as "not in scope, it should be done somewhere else". I know I already asked, but - is there any discussion between CDI and Servlet spec leads about this topic? Thanks and regards, Pavel From arjan.tijms at gmail.com Fri Dec 5 17:02:43 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Fri, 5 Dec 2014 23:02:43 +0100 Subject: [cdi-dev] New Servlet related scope - @UpgradeScoped (?) In-Reply-To: <5481E41C.40400@oracle.com> References: <547F407F.1080505@oracle.com> <54801B17.1050102@oracle.com> <548023B8.2060404@redhat.com> <5481E41C.40400@oracle.com> Message-ID: Hi, On Friday, December 5, 2014, Pavel Bucek wrote: > please see inline. > > On 04/12/14 10:04, Martin Kouba wrote: > > Dne 4.12.2014 v 09:28 Pavel Bucek napsal(a): > >> Hello Arjan, > >> > >> On 03/12/14 19:44, arjan tijms wrote: > >>> Hi, > >>> > >>> On Wednesday, December 3, 2014, Pavel Bucek > >>> >> wrote: > >>> > >>> Hi all, > >>> > >>> I'm trying to figure out how to solve issue in JSR 356 - Java API > for > >>> WebSocket, related to CDI scope usable from WebSocket endpoints. > >>> Problem > >>> is, that "standard" scopes do not apply, because there is no > >>> @RequestScoped (http response is already sent), HttpSession does > not > >>> need to be created and the rest does not seem to be applicable, > ... > >>> > >>> I believe that CDI specification should define @UpgradeScoped, > which > >>> would cover usages of HttpUpgradeHandler from Servlet API. > >>> (Similarly as > >>> it does for @RequestScoped, @SessionScoped, ... ) > >>> > >>> > >>> Wouldn't it be a better option to have WebSocket define that scope, > >>> using CDI to implement it? > >> That is one possibility, but @UpgradeScoped would be more general than > >> just for WebSocket - it would apply for all HTTP/1.1+ Upgrade > >> applications. In my eyes, it is something which was forgotten to do in > >> Java EE 7 release, since HttpUpgradeHandler was introduced in it. > >> > >> Also please note, that other Servlet related scopes are already in CDI > >> spec, so it seems like it belongs there more than anywhere else. This > >> might have multiple reasons - for example, you can easily define > >> relationship between @UpgradeScoped and others, already existing ones. > >> In this sense, CDI specification now depends on Servlet API (it > >> references some of the classes defined in it), but Servlet does not do > >> that for CDI. I don't think that Servlet spec should introduce similar > >> dependency just because of new scope. > > That's a good point. However, I don't think it's a good path to follow. > > I mean if it were in CDI spec, CDI implementations would be required to > > implement this. However, Servlet spec is not very clear in many areas > > and doesn't always provide a powerful enough SPI. Even now there are > > technical issues with similar requirements (e.g. @RequestScoped during > > AsyncListener invocations). I'm not so sure about HttpUpgradeHandler > > though... > > And what if the @UpgradeScoped definition would need to state something > like "this scope is part of @ApplicationScoped"? That would result even > in more confusion and cross references CDI to Servlet and vice versa. I'm not so sure that would necessarily be confusing. If Servlet is "layered" on top of CDI, then a scope in Servlet could reference other things within the Servlet spec, or things in lower layers, which is CDI in this case. There would be no cross-references there, would there? > I could see this being part of Servlet spec only if all other > "Servlet-related" scopes are there as well. Correct me if I'm wrong, but there's only one scope in CDI that at the moment exclusively references Servlet, and that's @SessionScoped. Both @RequestScoped and @ApplicationScoped have a (much) broader definition than being just a Servlet scope. I'm not entirely sure, but the way these 3 scopes are now set up may not exclude @SessionScoped being applied to other things as well. The one problem may be that CDI here lists all other specs that give meaning to the scope. Even though it's just text and not an actual API dependency, this may not be entirely consistent (but how could it be done better?) Kind regards, Arjan Tijms > > Con somebody suggest what should I do next? I can file an issue against > CDI spec and even against Servlet spec, but my feeling is that it might > be deferred on both issue trackers as "not in scope, it should be done > somewhere else". I know I already asked, but - is there any discussion > between CDI and Servlet spec leads about this topic? > > Thanks and regards, > Pavel > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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/20141205/203b44c8/attachment.html From struberg at yahoo.de Sat Dec 6 07:17:00 2014 From: struberg at yahoo.de (Mark Struberg) Date: Sat, 6 Dec 2014 12:17:00 +0000 (UTC) Subject: [cdi-dev] microbenchmark for CDI performance In-Reply-To: <5481D431.3010601@redhat.com> References: <5481D431.3010601@redhat.com> Message-ID: <824054139.6378720.1417868220715.JavaMail.yahoo@jws11117.mail.ir2.yahoo.com> Hi Jozef! Well, in any case, Weld-2.2.7.Final got 15x faster now than older Weld versions. So congratulations on this! LieGrue, strub > On Friday, 5 December 2014, 16:50, Jozef Hartinger wrote: > > Actually, I was wrong. This *is* a valid optimization for CDI 1.0. It > however *is not valid* for CDI 1.1+ as it breaks > AlterableContext.destroy(). This is fixed in Weld 2.2.7.Final > http://weld.cdi-spec.org/download/ > > On 10/21/2014 02:56 PM, Jozef Hartinger wrote: >> For certain combinations of scopes this is a perfectly legal >> optimization ;-) It's even mentioned in the spec (see 6.5.5). >> >> On 10/21/2014 02:46 PM, Mark Struberg wrote: >>> Folks, you really scare me a bit! >>> >>> I debugged into it and for the first BeanManger#getReference I get a > proxy. >>> >>> But for all other BeanManager#getReference I get the bare metal > SimpleBeanWithoutInterceptor WITHOUT ANY PROXY. >>> Can you confirm this? >>> If so, then please tell me how you make this Serializable if it gets > stored e.g in a Http Session? >>> >>> >>> This is just not conform to the CDI spec I fear. I even consider this a > blocker bug... >>> >>> LieGrue, >>> strub >>> >>> >>> >>>> On Tuesday, 21 October 2014, 14:07, Jozef Hartinger > wrote: >>>>> Btw I've run your benchmark locally and observed the > following results: >>>> OWB 1.2.6: 9827ms >>>> Weld 2.2.5.Final: 20ms >>>> >>>> ;-) >>>> >>>> I did however tweak the test a bit so that Weld's optimizations > can be >>>> leveraged[1]. I admit that in certain situations (like your test > without >>>> my change) Weld performs worse than it should and this is a good > input >>>> for us. >>>> >>>> As for the NPE you observed not sure what is going on there. > Perhaps >>>> WeldContextControl implementation in DeltaSpike is not really > thread safe? >>>> >>>> Jozef >>>> >>>> [1] https://github.com/jharting/cdi-performance/commits/weld >>>> >>>> On 10/21/2014 01:43 PM, Jozef Hartinger wrote: >>>>> Hi Mark, >>>>> >>>>> thanks for showcasting your new feature. Great to see OWB > getting >>>>> faster! As for the micro benchmark I suggest that you check > out JMH[1]. >>>>> >>>>> If you need an input from the Weld team, use > weld-dev at lists.jboss.org >>>>> >>>>> [1] http://openjdk.java.net/projects/code-tools/jmh/ >>>>> >>>>> On 10/21/2014 11:59 AM, Mark Struberg wrote: >>>>>> Hi! >>>>>> >>>>>> Weld folks, I need some help with a micro benchmark: >>>>>> >>>>>> You know we've talked about disk footprint in SE, so > I hacked >>>> together a small microbenchmark and as a side effect we also got > what is really >>>> needed to have CDI running >>>>>> https://github.com/struberg/cdi-performance >>>>>> >>>>>> I'm curious about missing some dependency excludes > for Weld. >>>>>> >>>>>> could you please run >>>>>> >>>>>> $> mvn clean dependency:copy-dependencies > -DincludeScope=compile >>>> -PWeld -Dweld.version=2.2.5.Final >>>>>> $> ls -al target/dependency/ >>>>>> >>>>>> and tell me which dependencies can be without having > some CDI >>>> functionality missing? >>>>>> Feel free to pimp the pom and ship a pull request. >>>>>> >>>>>> >>>>>> txs and 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. >>>> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.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 pavel.bucek at oracle.com Mon Dec 8 09:50:12 2014 From: pavel.bucek at oracle.com (Pavel Bucek) Date: Mon, 08 Dec 2014 15:50:12 +0100 Subject: [cdi-dev] New Servlet related scope - @UpgradeScoped (?) In-Reply-To: References: <547F407F.1080505@oracle.com> <54801B17.1050102@oracle.com> <548023B8.2060404@redhat.com> <5481E41C.40400@oracle.com> Message-ID: <5485BAA4.60502@oracle.com> Hello, please see inline. On 05/12/14 23:02, arjan tijms wrote: > On Friday, December 5, 2014, Pavel Bucek > wrote: > > > On 04/12/14 10:04, Martin Kouba wrote: > > Dne 4.12.2014 v 09:28 Pavel Bucek napsal(a): > >> > >> On 03/12/14 19:44, arjan tijms wrote: > >>> > >>> On Wednesday, December 3, 2014, Pavel Bucek > > >>> >> wrote: > >>> > >>> I'm trying to figure out how to solve issue in JSR 356 - > Java API for > >>> WebSocket, related to CDI scope usable from WebSocket > endpoints. > >>> Problem > >>> is, that "standard" scopes do not apply, because there is no > >>> @RequestScoped (http response is already sent), > HttpSession does not > >>> need to be created and the rest does not seem to be > applicable, ... > >>> > >>> I believe that CDI specification should define > @UpgradeScoped, which > >>> would cover usages of HttpUpgradeHandler from Servlet API. > >>> (Similarly as > >>> it does for @RequestScoped, @SessionScoped, ... ) > >>> > >>> > >>> Wouldn't it be a better option to have WebSocket define that > scope, > >>> using CDI to implement it? > >> That is one possibility, but @UpgradeScoped would be more > general than > >> just for WebSocket - it would apply for all HTTP/1.1+ Upgrade > >> applications. In my eyes, it is something which was forgotten > to do in > >> Java EE 7 release, since HttpUpgradeHandler was introduced in it. > >> > >> Also please note, that other Servlet related scopes are already > in CDI > >> spec, so it seems like it belongs there more than anywhere > else. This > >> might have multiple reasons - for example, you can easily define > >> relationship between @UpgradeScoped and others, already > existing ones. > >> In this sense, CDI specification now depends on Servlet API (it > >> references some of the classes defined in it), but Servlet does > not do > >> that for CDI. I don't think that Servlet spec should introduce > similar > >> dependency just because of new scope. > > That's a good point. However, I don't think it's a good path to > follow. > > I mean if it were in CDI spec, CDI implementations would be > required to > > implement this. However, Servlet spec is not very clear in many > areas > > and doesn't always provide a powerful enough SPI. Even now there are > > technical issues with similar requirements (e.g. @RequestScoped > during > > AsyncListener invocations). I'm not so sure about HttpUpgradeHandler > > though... > > And what if the @UpgradeScoped definition would need to state > something > like "this scope is part of @ApplicationScoped"? That would result > even > in more confusion and cross references CDI to Servlet and vice versa. > > > I'm not so sure that would necessarily be confusing. If Servlet is > "layered" on top of CDI, then a scope in Servlet could reference other > things within the Servlet spec, or things in lower layers, which is > CDI in this case. > > There would be no cross-references there, would there? well.. I'm not the expert in Servlet nor CDI spec, but what I see in Servlet is NOT related to CDI directly. Simple search does not include any "RequestScoped" appearance. There is only brief reference to it in chapter 15.5.15, but that refers only to Java EE 7 umbrella specification definition. So, from my point of view, Servlet DOES NOT depend on CDI. On the other hand, CDI specification references directly to Servlet classes/methods in multiple chapters: 3.8, 5.5.2, 5.5.3, 6.7.1, 6.7.2, 6.7.3, 6.7.4, ... . Please note that I'm using last released versions of spec documents - Servlet 3.1 and CDI 1.2. > I could see this being part of Servlet spec only if all other > "Servlet-related" scopes are there as well. > > > Correct me if I'm wrong, but there's only one scope in CDI that at the > moment exclusively references Servlet, and that's @SessionScoped. > > Both @RequestScoped and @ApplicationScoped have a (much) broader > definition than being just a Servlet scope. > > I'm not entirely sure, but the way these 3 scopes are now set up may > not exclude @SessionScoped being applied to other things as well. Same for @UpgradeScoped - it might be applied to other things as well (little bit far fetched from my side, I know - @SessionScoped is much more general than @UpgradeScoped). > The one problem may be that CDI here lists all other specs that give > meaning to the scope. Even though it's just text and not an actual API > dependency, this may not be entirely consistent (but how could it be > done better?) That is not exactly correct - CDI spec defines how these scopes should be implemented - it *gives* the meaning to the scopes (at least in this case) in other specifications (see my note about no @*Scoped references in Servlet spec). Please don't take this as "@UpgradeScoped" must be introduced and it must be in CDI spec. I'm just trying to see where it should be and currently I think it should be near other scope definitions. As I said, I can start similar discussion with Servlet spec group, but it would be nice to have some conclusion from here.. Thanks and regards, Pavel > > Kind regards, > Arjan Tijms > > > Con somebody suggest what should I do next? I can file an issue > against > CDI spec and even against Servlet spec, but my feeling is that it > might > be deferred on both issue trackers as "not in scope, it should be done > somewhere else". I know I already asked, but - is there any discussion > between CDI and Servlet spec leads about this topic? > > Thanks and regards, > Pavel > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider > licenses the code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.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/20141208/50bfa5b3/attachment.html From arjan.tijms at gmail.com Mon Dec 8 10:34:00 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Mon, 8 Dec 2014 16:34:00 +0100 Subject: [cdi-dev] New Servlet related scope - @UpgradeScoped (?) In-Reply-To: <5485BAA4.60502@oracle.com> References: <547F407F.1080505@oracle.com> <54801B17.1050102@oracle.com> <548023B8.2060404@redhat.com> <5481E41C.40400@oracle.com> <5485BAA4.60502@oracle.com> Message-ID: Hi, On Mon, Dec 8, 2014 at 3:50 PM, Pavel Bucek wrote: >> I'm not so sure that would necessarily be confusing. If Servlet is "layered" >> on top of CDI, then a scope in Servlet could reference other things within >> the Servlet spec, or things in lower layers, which is CDI in this case. > >> There would be no cross-references there, would there? > > well.. I'm not the expert in Servlet nor CDI spec, but what I see in Servlet > is NOT related to CDI directly. Simple search does not include any > "RequestScoped" appearance. No, but the idea is that if Servlet would make use of CDI, then there still would be no cross-references. If the @UpgradeScoped would be in Servlet, then it could reference things in either Servlet (=same layer) or in CDI (one layer lower). In that case, independent of whether any scope would move from CDI to Servlet, or whether those scopes will stay in CDI, there will be no cross-references. > So, from my point of view, Servlet DOES NOT depend on CDI. It doesn't, but who ever said that it does at the moment? >> The one problem may be that CDI here lists all other specs that give meaning >> to the scope. Even though it's just text and not an actual API dependency, >> this may not be entirely consistent (but how could it be done better?) > > > That is not exactly correct - CDI spec defines how these scopes should be > implemented - it *gives* the meaning to the scopes (at least in this case) > in other specifications (see my note about no @*Scoped references in Servlet > spec). Well, it defines when the scope should be active for each spec, but what I meant is that the actual implementation of what the scope means is in the other spec. E.g. @RequestScope says it's active: "during any remote method invocation of any EJB" Naturally, what the time during a "remote method invocation of any EJB" is, is defined in the EJB spec. CDI just says this scope should match that, but it doesn't say what an EJB is, and what a "remote method invocation" exactly is. Eventually it's an architectural decision; should CDI have knowledge of all other specs and depend on events or hooks in those specs to do what I needs to do, OR should CDI be more about a lower level set of primitive functionality that is used by all other specs? We now unfortunately have both situations. JSF has scopes like @ViewScoped and @FlowScoped that USE CDI. JSF will get producers for several artefacts that USE CDI. CDI in those cases does not know JSF. JTA has an interceptor @Transactional that USES CDI. In this case, CDI does not know JTA. On the other hand, CDI has scopes like @RequestScoped that references Servlet, Web Services, EJB and JMS. Here, Servlet, Web Services etc do not know CDI. CDI also has producers for several types like HttpServletRequest (Servlet), Principal (technically JASPIC but can also be Servlet proprietary) and UserTransaction (JTA). Here, Servlet, JASPIC and JTA do not know CDI. Especially for the producers it seems rather random of when it appears in CDI, and when it appears in the spec that owns the produced artefacts. As mentioned, the 3 scopes in CDI are somewhat more complicated as at least two of them are broadly applicable. Should CDI continue to define them, or should CDI give a very general description, with the more specific description being given by each spec itself? I don't really know what's best there. Kind regards, Arjan Tijms > > Please don't take this as "@UpgradeScoped" must be introduced and it must be > in CDI spec. I'm just trying to see where it should be and currently I think > it should be near other scope definitions. As I said, I can start similar > discussion with Servlet spec group, but it would be nice to have some > conclusion from here.. > > Thanks and regards, > Pavel > > > Kind regards, > Arjan Tijms > >> >> >> Con somebody suggest what should I do next? I can file an issue against >> CDI spec and even against Servlet spec, but my feeling is that it might >> be deferred on both issue trackers as "not in scope, it should be done >> somewhere else". I know I already asked, but - is there any discussion >> between CDI and Servlet spec leads about this topic? >> >> Thanks and regards, >> Pavel >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.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 pavel.bucek at oracle.com Mon Dec 8 11:12:52 2014 From: pavel.bucek at oracle.com (Pavel Bucek) Date: Mon, 08 Dec 2014 17:12:52 +0100 Subject: [cdi-dev] New Servlet related scope - @UpgradeScoped (?) In-Reply-To: References: <547F407F.1080505@oracle.com> <54801B17.1050102@oracle.com> <548023B8.2060404@redhat.com> <5481E41C.40400@oracle.com> <5485BAA4.60502@oracle.com> Message-ID: <5485CE04.7070105@oracle.com> On 08/12/14 16:34, arjan tijms wrote: > Hi, > > On Mon, Dec 8, 2014 at 3:50 PM, Pavel Bucek wrote: >>> I'm not so sure that would necessarily be confusing. If Servlet is "layered" >>> on top of CDI, then a scope in Servlet could reference other things within >>> the Servlet spec, or things in lower layers, which is CDI in this case. >>> There would be no cross-references there, would there? >> well.. I'm not the expert in Servlet nor CDI spec, but what I see in Servlet >> is NOT related to CDI directly. Simple search does not include any >> "RequestScoped" appearance. > No, but the idea is that if Servlet would make use of CDI, then there > still would be no cross-references. > > If the @UpgradeScoped would be in Servlet, then it could reference > things in either Servlet (=same layer) or in CDI (one layer lower). > > In that case, independent of whether any scope would move from CDI to > Servlet, or whether those scopes will stay in CDI, there will be no > cross-references. > >> So, from my point of view, Servlet DOES NOT depend on CDI. > It doesn't, but who ever said that it does at the moment? it was meant as a reply to the discussion about cross references, which would be introduced by adding reference to CDI to Servlet. Based on our discussion, it seems like CDI should just declare generic cases where @*Scoped should be used and the rest (Servlet related definitions) should be somewhere else (Java EE umbrella? Servlet?). If that would be that case, CDI could be clean and "independent".. (current state almost implies CDI release when some of the referenced class/method is changed/removed/deprecated/...). >>> The one problem may be that CDI here lists all other specs that give meaning >>> to the scope. Even though it's just text and not an actual API dependency, >>> this may not be entirely consistent (but how could it be done better?) >> >> That is not exactly correct - CDI spec defines how these scopes should be >> implemented - it *gives* the meaning to the scopes (at least in this case) >> in other specifications (see my note about no @*Scoped references in Servlet >> spec). > Well, it defines when the scope should be active for each spec, but > what I meant is that the actual implementation of what the scope means > is in the other spec. > > E.g. @RequestScope says it's active: > > "during any remote method invocation of any EJB" > > Naturally, what the time during a "remote method invocation of any > EJB" is, is defined in the EJB spec. CDI just says this scope should > match that, but it doesn't say what an EJB is, and what a "remote > method invocation" exactly is. > > Eventually it's an architectural decision; should CDI have knowledge > of all other specs and depend on events or hooks in those specs to do > what I needs to do, OR should CDI be more about a lower level set of > primitive functionality that is used by all other specs? > > We now unfortunately have both situations. > > JSF has scopes like @ViewScoped and @FlowScoped that USE CDI. JSF will > get producers for several artefacts that USE CDI. CDI in those cases > does not know JSF. > > JTA has an interceptor @Transactional that USES CDI. In this case, CDI > does not know JTA. > > On the other hand, CDI has scopes like @RequestScoped that references > Servlet, Web Services, EJB and JMS. Here, Servlet, Web Services etc do > not know CDI. > > CDI also has producers for several types like HttpServletRequest > (Servlet), Principal (technically JASPIC but can also be Servlet > proprietary) and UserTransaction (JTA). Here, Servlet, JASPIC and JTA > do not know CDI. > > Especially for the producers it seems rather random of when it appears > in CDI, and when it appears in the spec that owns the produced > artefacts. As mentioned, the 3 scopes in CDI are somewhat more > complicated as at least two of them are broadly applicable. Should CDI > continue to define them, or should CDI give a very general > description, with the more specific description being given by each > spec itself? I don't really know what's best there. Thanks for this summary, that is really useful (specially for me, since I really don't know that much about CDI :-) ). It would be nice to have some feedback from Pete and/or Antione. Thanks and regards, Pavel From smillidge at c2b2.co.uk Mon Dec 8 12:08:51 2014 From: smillidge at c2b2.co.uk (Steve Millidge) Date: Mon, 8 Dec 2014 17:08:51 +0000 Subject: [cdi-dev] Unexplained change in behavior between Java EE 6 and Java EE 7 Message-ID: Hi We are investigating a change in behaviour between Java EE 6 and Java EE 7 and were wondering if this is a bug or a specification change; If there is a RequestScoped bean and SFSB like below, and I call invokeStatefulService() on the Request Scoped Bean the behaviour changes depending on Java EE version; On GFv3 and JBoss EAP 6 the method returns "init" implying we have 2 separate SFSB instances. and on GFv4 and WildFly the method returns "stateFromFirst" implying there is 1 SFSB instance. I would've imagined that the second result i.e. 1 SFSB as there is 1 client bean which exists for the duration of the call is the correct behaviour. However I am not sure. As both appservers above use JBoss Weld for CDI is this a Weld bug or did the behaviour change between Java EE 6 and Java EE 7? @RequestScoped public class Injection { @Inject StatefulService first; @Inject StatefulService second; public String invokeStatefulService(){ first.setState("stateFromFirst"); return second.getState(); } } @Stateful public class StatefulService { private String state; @PostConstruct public void init(){ this.state = "init"; } public void setState(String state) { this.state = state; } public String getState() { return state; } } Steve Millidge Director C2B2 The Leading Independent Middleware Experts. T: 08450 539457 | M: 07920 100626 | W: www.c2b2.co.uk | E: smillidge at c2b2.co.uk [Main SIgnature May 14] --------------------------------------------------------------------------------------------------------------- C2B2 Consulting Limited, Malvern Hills Science Park, Geraldine Road, Malvern, Worcestershire, WR14 3SZ Registered in England and Wales: 4563419, Registered Office: Ardendale, Old Hollow, Malvern, Worcestershire -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141208/973db343/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 20712 bytes Desc: image001.jpg Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20141208/973db343/attachment-0001.jpg From jharting at redhat.com Mon Dec 8 12:44:33 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Mon, 08 Dec 2014 18:44:33 +0100 Subject: [cdi-dev] Unexplained change in behavior between Java EE 6 and Java EE 7 In-Reply-To: References: Message-ID: <5485E381.5010208@redhat.com> Hi Steve, this is not caused by a change in the specification nor in Weld. It is probably a regression in GlassFish integration. The correct behavior is the former (2 instances) as that is aligned with how @Dependent instances work in general. If you need the bean instance to be shared across injection points, you can give it a scope other than @Dependent. HTH, Jozef On 12/08/2014 06:08 PM, Steve Millidge wrote: > > Hi > > We are investigating a change in behaviour between Java EE 6 and Java > EE 7 and were wondering if this is a bug or a specification change; > > If there is a RequestScoped bean and SFSB like below, and I call > invokeStatefulService() on the Request Scoped Bean the behaviour > changes depending on Java EE version; > > On GFv3 and JBoss EAP 6 the method returns "init" implying we have 2 > separate SFSB instances. > > and on GFv4 and WildFly the method returns "stateFromFirst" implying > there is 1 SFSB instance. > > I would?ve imagined that the second result i.e. 1 SFSB as there is 1 > client bean which exists for the duration of the call is the correct > behaviour. However I am not sure. > > As both appservers above use JBoss Weld for CDI is this a Weld bug or > did the behaviour change between Java EE 6 and Java EE 7? > > @RequestScoped > > public class Injection { > > @Inject > > StatefulService first; > > @Inject > > StatefulService second; > > public String invokeStatefulService(){ > > first.setState("stateFromFirst"); > > return second.getState(); > > } > > } > > @Stateful > > public class StatefulService { > > private String state; > > @PostConstruct > > public void init(){ > > this.state = "init"; > > } > > public void setState(String state) { > > this.state = state; > > } > > public String getState() { > > return state; > > } > > } > > Steve Millidge > Director > > C2B2 > *The Leading Independent Middleware Experts.* > T: 08450 539457*|*M: 07920 100626*|*W: www.c2b2.co.uk > *|*E: smillidge at c2b2.co.uk > > > Main SIgnature May 14 > --------------------------------------------------------------------------------------------------------------- > C2B2 Consulting Limited, Malvern Hills Science Park, Geraldine Road, > Malvern, Worcestershire, WR14 3SZ > Registered in England and Wales: 4563419, Registered Office: > Ardendale, Old Hollow, Malvern, Worcestershire > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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/20141208/aaffada0/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 20712 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20141208/aaffada0/attachment-0001.jpe From arjan.tijms at gmail.com Mon Dec 8 13:20:41 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Mon, 8 Dec 2014 19:20:41 +0100 Subject: [cdi-dev] Unexplained change in behavior between Java EE 6 and Java EE 7 In-Reply-To: <5485E381.5010208@redhat.com> References: <5485E381.5010208@redhat.com> Message-ID: Hi, I agree that there should be two instances of the stateful bean, so GF3/EAP6 is correct. It's remarkable then that seemingly GF4 and WF8 have the exact same integration regression. At any length this would be a good case for adding an extra test to the TCK ;) Kind regards, Arjan On Monday, December 8, 2014, Jozef Hartinger wrote: > Hi Steve, > > this is not caused by a change in the specification nor in Weld. It is > probably a regression in GlassFish integration. The correct behavior is the > former (2 instances) as that is aligned with how @Dependent instances work > in general. If you need the bean instance to be shared across injection > points, you can give it a scope other than @Dependent. > > HTH, > > Jozef > > On 12/08/2014 06:08 PM, Steve Millidge wrote: > > Hi > > > > We are investigating a change in behaviour between Java EE 6 and Java EE 7 > and were wondering if this is a bug or a specification change; > > > > If there is a RequestScoped bean and SFSB like below, and I call > invokeStatefulService() on the Request Scoped Bean the behaviour changes > depending on Java EE version; > > > > On GFv3 and JBoss EAP 6 the method returns "init" implying we have 2 > separate SFSB instances. > > and on GFv4 and WildFly the method returns "stateFromFirst" implying there > is 1 SFSB instance. > > > > I would?ve imagined that the second result i.e. 1 SFSB as there is 1 > client bean which exists for the duration of the call is the correct > behaviour. However I am not sure. > > > > As both appservers above use JBoss Weld for CDI is this a Weld bug or did > the behaviour change between Java EE 6 and Java EE 7? > > > > @RequestScoped > > public class Injection { > > > > @Inject > > StatefulService first; > > > > @Inject > > StatefulService second; > > > > public String invokeStatefulService(){ > > first.setState("stateFromFirst"); > > return second.getState(); > > } > > } > > > > @Stateful > > public class StatefulService { > > > > private String state; > > > > @PostConstruct > > public void init(){ > > this.state = "init"; > > } > > > > public void setState(String state) { > > this.state = state; > > } > > > > public String getState() { > > return state; > > } > > } > > > > > > Steve Millidge > Director > > C2B2 > *The Leading Independent Middleware Experts.* > T: 08450 539457 *|* M: 07920 100626 *|* W: www.c2b2.co.uk *|* E: > smillidge at c2b2.co.uk > > > [image: Main SIgnature May 14] > > --------------------------------------------------------------------------------------------------------------- > C2B2 Consulting Limited, Malvern Hills Science Park, Geraldine Road, > Malvern, Worcestershire, WR14 3SZ > Registered in England and Wales: 4563419, Registered Office: Ardendale, > Old Hollow, Malvern, Worcestershire > > > > > _______________________________________________ > cdi-dev mailing listcdi-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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/20141208/195f28d7/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 20712 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20141208/195f28d7/attachment-0001.jpe From smillidge at c2b2.co.uk Mon Dec 8 13:24:46 2014 From: smillidge at c2b2.co.uk (Steve Millidge) Date: Mon, 8 Dec 2014 18:24:46 +0000 Subject: [cdi-dev] Unexplained change in behavior between Java EE 6 and Java EE 7 In-Reply-To: References: <5485E381.5010208@redhat.com> Message-ID: I?ll start debugging Payara (GF) then ? From: arjan tijms [mailto:arjan.tijms at gmail.com] Sent: 08 December 2014 18:21 To: Jozef Hartinger Cc: Steve Millidge; cdi-dev at lists.jboss.org Subject: Re: [cdi-dev] Unexplained change in behavior between Java EE 6 and Java EE 7 Hi, I agree that there should be two instances of the stateful bean, so GF3/EAP6 is correct. It's remarkable then that seemingly GF4 and WF8 have the exact same integration regression. At any length this would be a good case for adding an extra test to the TCK ;) Kind regards, Arjan On Monday, December 8, 2014, Jozef Hartinger > wrote: Hi Steve, this is not caused by a change in the specification nor in Weld. It is probably a regression in GlassFish integration. The correct behavior is the former (2 instances) as that is aligned with how @Dependent instances work in general. If you need the bean instance to be shared across injection points, you can give it a scope other than @Dependent. HTH, Jozef On 12/08/2014 06:08 PM, Steve Millidge wrote: Hi We are investigating a change in behaviour between Java EE 6 and Java EE 7 and were wondering if this is a bug or a specification change; If there is a RequestScoped bean and SFSB like below, and I call invokeStatefulService() on the Request Scoped Bean the behaviour changes depending on Java EE version; On GFv3 and JBoss EAP 6 the method returns "init" implying we have 2 separate SFSB instances. and on GFv4 and WildFly the method returns "stateFromFirst" implying there is 1 SFSB instance. I would?ve imagined that the second result i.e. 1 SFSB as there is 1 client bean which exists for the duration of the call is the correct behaviour. However I am not sure. As both appservers above use JBoss Weld for CDI is this a Weld bug or did the behaviour change between Java EE 6 and Java EE 7? @RequestScoped public class Injection { @Inject StatefulService first; @Inject StatefulService second; public String invokeStatefulService(){ first.setState("stateFromFirst"); return second.getState(); } } @Stateful public class StatefulService { private String state; @PostConstruct public void init(){ this.state = "init"; } public void setState(String state) { this.state = state; } public String getState() { return state; } } Steve Millidge Director C2B2 The Leading Independent Middleware Experts. T: 08450 539457 | M: 07920 100626 | W: www.c2b2.co.uk | E: smillidge at c2b2.co.uk [Main SIgnature May 14] --------------------------------------------------------------------------------------------------------------- C2B2 Consulting Limited, Malvern Hills Science Park, Geraldine Road, Malvern, Worcestershire, WR14 3SZ Registered in England and Wales: 4563419, Registered Office: Ardendale, Old Hollow, Malvern, Worcestershire _______________________________________________ cdi-dev mailing list cdi-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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/20141208/d4c21470/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 20712 bytes Desc: image001.jpg Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20141208/d4c21470/attachment-0001.jpg From jharting at redhat.com Tue Dec 9 04:23:58 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Tue, 09 Dec 2014 10:23:58 +0100 Subject: [cdi-dev] Unexplained change in behavior between Java EE 6 and Java EE 7 In-Reply-To: References: <5485E381.5010208@redhat.com> Message-ID: <5486BFAE.40106@redhat.com> Actually it passes on WF8/9 with the latest version of Weld but fails with older ones so it seems that it was a regression in Weld after all. Sorry for confusion. On 12/08/2014 07:20 PM, arjan tijms wrote: > Hi, > > I agree that there should be two instances of the stateful bean, so > GF3/EAP6 is correct. > > It's remarkable then that seemingly GF4 and WF8 have the exact same > integration regression. > > At any length this would be a good case for adding an extra test to > the TCK ;) > > Kind regards, > Arjan > > On Monday, December 8, 2014, Jozef Hartinger > wrote: > > Hi Steve, > > this is not caused by a change in the specification nor in Weld. > It is probably a regression in GlassFish integration. The correct > behavior is the former (2 instances) as that is aligned with how > @Dependent instances work in general. If you need the bean > instance to be shared across injection points, you can give it a > scope other than @Dependent. > > HTH, > > Jozef > > On 12/08/2014 06:08 PM, Steve Millidge wrote: >> >> Hi >> >> We are investigating a change in behaviour between Java EE 6 and >> Java EE 7 and were wondering if this is a bug or a specification >> change; >> >> If there is a RequestScoped bean and SFSB like below, and I call >> invokeStatefulService() on the Request Scoped Bean the behaviour >> changes depending on Java EE version; >> >> On GFv3 and JBoss EAP 6 the method returns "init" implying we >> have 2 separate SFSB instances. >> >> and on GFv4 and WildFly the method returns "stateFromFirst" >> implying there is 1 SFSB instance. >> >> I would?ve imagined that the second result i.e. 1 SFSB as there >> is 1 client bean which exists for the duration of the call is the >> correct behaviour. However I am not sure. >> >> As both appservers above use JBoss Weld for CDI is this a Weld >> bug or did the behaviour change between Java EE 6 and Java EE 7? >> >> @RequestScoped >> >> public class Injection { >> >> @Inject >> >> StatefulService first; >> >> @Inject >> >> StatefulService second; >> >> public String invokeStatefulService(){ >> >> first.setState("stateFromFirst"); >> >> return second.getState(); >> >> } >> >> } >> >> @Stateful >> >> public class StatefulService { >> >> private String state; >> >> @PostConstruct >> >> public void init(){ >> >> this.state = "init"; >> >> } >> >> public void setState(String state) { >> >> this.state = state; >> >> } >> >> public String getState() { >> >> return state; >> >> } >> >> } >> >> Steve Millidge >> Director >> >> C2B2 >> *The Leading Independent Middleware Experts.* >> T: 08450 539457*|*M: 07920 100626*|*W: www.c2b2.co.uk >> *|*E: smillidge at c2b2.co.uk >> >> >> Main SIgnature May 14 >> --------------------------------------------------------------------------------------------------------------- >> C2B2 Consulting Limited, Malvern Hills Science Park, Geraldine >> Road, Malvern, Worcestershire, WR14 3SZ >> Registered in England and Wales: 4563419, Registered Office: >> Ardendale, Old Hollow, Malvern, Worcestershire >> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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/20141209/ec06a007/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 20712 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20141209/ec06a007/attachment-0001.jpe From smillidge at c2b2.co.uk Tue Dec 9 05:22:21 2014 From: smillidge at c2b2.co.uk (Steve Millidge) Date: Tue, 9 Dec 2014 10:22:21 +0000 Subject: [cdi-dev] Unexplained change in behavior between Java EE 6 and Java EE 7 In-Reply-To: <5486BFAE.40106@redhat.com> References: <5485E381.5010208@redhat.com> <5486BFAE.40106@redhat.com> Message-ID: Hi Jozef, Thanks for that is it passing on 2.2.7.Final ? Steve From: Jozef Hartinger [mailto:jharting at redhat.com] Sent: 09 December 2014 09:24 To: arjan tijms Cc: Steve Millidge; cdi-dev at lists.jboss.org Subject: Re: [cdi-dev] Unexplained change in behavior between Java EE 6 and Java EE 7 Actually it passes on WF8/9 with the latest version of Weld but fails with older ones so it seems that it was a regression in Weld after all. Sorry for confusion. On 12/08/2014 07:20 PM, arjan tijms wrote: Hi, I agree that there should be two instances of the stateful bean, so GF3/EAP6 is correct. It's remarkable then that seemingly GF4 and WF8 have the exact same integration regression. At any length this would be a good case for adding an extra test to the TCK ;) Kind regards, Arjan On Monday, December 8, 2014, Jozef Hartinger > wrote: Hi Steve, this is not caused by a change in the specification nor in Weld. It is probably a regression in GlassFish integration. The correct behavior is the former (2 instances) as that is aligned with how @Dependent instances work in general. If you need the bean instance to be shared across injection points, you can give it a scope other than @Dependent. HTH, Jozef On 12/08/2014 06:08 PM, Steve Millidge wrote: Hi We are investigating a change in behaviour between Java EE 6 and Java EE 7 and were wondering if this is a bug or a specification change; If there is a RequestScoped bean and SFSB like below, and I call invokeStatefulService() on the Request Scoped Bean the behaviour changes depending on Java EE version; On GFv3 and JBoss EAP 6 the method returns "init" implying we have 2 separate SFSB instances. and on GFv4 and WildFly the method returns "stateFromFirst" implying there is 1 SFSB instance. I would?ve imagined that the second result i.e. 1 SFSB as there is 1 client bean which exists for the duration of the call is the correct behaviour. However I am not sure. As both appservers above use JBoss Weld for CDI is this a Weld bug or did the behaviour change between Java EE 6 and Java EE 7? @RequestScoped public class Injection { @Inject StatefulService first; @Inject StatefulService second; public String invokeStatefulService(){ first.setState("stateFromFirst"); return second.getState(); } } @Stateful public class StatefulService { private String state; @PostConstruct public void init(){ this.state = "init"; } public void setState(String state) { this.state = state; } public String getState() { return state; } } Steve Millidge Director C2B2 The Leading Independent Middleware Experts. T: 08450 539457 | M: 07920 100626 | W: www.c2b2.co.uk | E: smillidge at c2b2.co.uk [Main SIgnature May 14] --------------------------------------------------------------------------------------------------------------- C2B2 Consulting Limited, Malvern Hills Science Park, Geraldine Road, Malvern, Worcestershire, WR14 3SZ Registered in England and Wales: 4563419, Registered Office: Ardendale, Old Hollow, Malvern, Worcestershire _______________________________________________ cdi-dev mailing list cdi-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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/20141209/2c563680/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 20712 bytes Desc: image001.jpg Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20141209/2c563680/attachment-0001.jpg From antoine at sabot-durand.net Wed Dec 10 10:29:53 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 10 Dec 2014 16:29:53 +0100 Subject: [cdi-dev] Today's meeting agenda Message-ID: Hi guys, As said before, the discussion in async event workshop is very rich but reached a high level of confusion preventing us to go further on these important features. After getting very precious feedback from Jos? and documenting myself on new asynchronous feature in JDK 8 I rewrote a more broader doc about async operation in CDI 2.0. In this doc I try a new approach to help us take decision step by step. Once these points discussed, I think it will be easier to get back to Async Event workshop since we?ll have taken basic approach for Async operation in CDI 2.0. I?m currently working on this doc but you can reach it here https://docs.google.com/document/d/1pDO7gru6YuEyTDdK3XBozvXZYucT9uC7McZMffSZun4/edit?usp=sharing There?s already big decision to make in the beginning of the doc (adoption of JDK 8 CompletableFuture API and support of Async method call). I don?t know if we?ll be able to take these decision in today?s meeting but I propose we use this doc to debate today. Antoine Sabot-Durand -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141210/afce2a25/attachment.html From jharting at redhat.com Wed Dec 10 10:45:06 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 10 Dec 2014 16:45:06 +0100 Subject: [cdi-dev] Weld 3.0.0.Alpha3 released Message-ID: <54886A82.4050602@redhat.com> With fireAsync prototype! http://weld.cdi-spec.org/news/2014/12/10/an-update-on-weld-3/ From antoine at sabot-durand.net Wed Dec 10 10:57:13 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 10 Dec 2014 16:57:13 +0100 Subject: [cdi-dev] Weld 3.0.0.Alpha3 released In-Reply-To: <54886A82.4050602@redhat.com> References: <54886A82.4050602@redhat.com> Message-ID: Thanks Jozef. Great job. > Le 10 d?c. 2014 ? 16:45, Jozef Hartinger a ?crit : > > With fireAsync prototype! > > http://weld.cdi-spec.org/news/2014/12/10/an-update-on-weld-3/ > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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/20141210/df0582b6/attachment.bin From jharting at redhat.com Thu Dec 11 13:10:35 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Thu, 11 Dec 2014 19:10:35 +0100 Subject: [cdi-dev] Unexplained change in behavior between Java EE 6 and Java EE 7 In-Reply-To: References: <5485E381.5010208@redhat.com> <5486BFAE.40106@redhat.com> Message-ID: <5489DE1B.2090602@redhat.com> Yes, it works fine on both 2.2.7.Final and 2.2.8.Final On 12/09/2014 11:22 AM, Steve Millidge wrote: > > Hi Jozef, > > Thanks for that is it passing on 2.2.7.Final ? > > Steve > > *From:*Jozef Hartinger [mailto:jharting at redhat.com] > *Sent:* 09 December 2014 09:24 > *To:* arjan tijms > *Cc:* Steve Millidge; cdi-dev at lists.jboss.org > *Subject:* Re: [cdi-dev] Unexplained change in behavior between Java > EE 6 and Java EE 7 > > Actually it passes on WF8/9 with the latest version of Weld but fails > with older ones so it seems that it was a regression in Weld after > all. Sorry for confusion. > > On 12/08/2014 07:20 PM, arjan tijms wrote: > > Hi, > > I agree that there should be two instances of the stateful bean, > so GF3/EAP6 is correct. > > It's remarkable then that seemingly GF4 and WF8 have the exact > same integration regression. > > At any length this would be a good case for adding an extra test > to the TCK ;) > > Kind regards, > > Arjan > > On Monday, December 8, 2014, Jozef Hartinger > wrote: > > Hi Steve, > > this is not caused by a change in the specification nor in > Weld. It is probably a regression in GlassFish integration. > The correct behavior is the former (2 instances) as that is > aligned with how @Dependent instances work in general. If you > need the bean instance to be shared across injection points, > you can give it a scope other than @Dependent. > > HTH, > > Jozef > > On 12/08/2014 06:08 PM, Steve Millidge wrote: > > Hi > > We are investigating a change in behaviour between Java EE > 6 and Java EE 7 and were wondering if this is a bug or a > specification change; > > If there is a RequestScoped bean and SFSB like below, and > I call invokeStatefulService() on the Request Scoped Bean > the behaviour changes depending on Java EE version; > > On GFv3 and JBoss EAP 6 the method returns "init" implying > we have 2 separate SFSB instances. > > and on GFv4 and WildFly the method returns > "stateFromFirst" implying there is 1 SFSB instance. > > I would?ve imagined that the second result i.e. 1 SFSB as > there is 1 client bean which exists for the duration of > the call is the correct behaviour. However I am not sure. > > As both appservers above use JBoss Weld for CDI is this a > Weld bug or did the behaviour change between Java EE 6 and > Java EE 7? > > @RequestScoped > > public class Injection { > > @Inject > > StatefulService first; > > @Inject > > StatefulService second; > > public String invokeStatefulService(){ > > first.setState("stateFromFirst"); > > return second.getState(); > > } > > } > > @Stateful > > public class StatefulService { > > private String state; > > @PostConstruct > > public void init(){ > > this.state = "init"; > > } > > public void setState(String state) { > > this.state = state; > > } > > public String getState() { > > return state; > > } > > } > > Steve Millidge > Director > > C2B2 > *The Leading Independent Middleware Experts.* > T: 08450 539457*|* M: 07920 100626*|* W: www.c2b2.co.uk > *|* E: smillidge at c2b2.co.uk > > > Main SIgnature May 14 > --------------------------------------------------------------------------------------------------------------- > C2B2 Consulting Limited, Malvern Hills Science Park, > Geraldine Road, Malvern, Worcestershire, WR14 3SZ > Registered in England and Wales: 4563419, Registered > Office: Ardendale, Old Hollow, Malvern, Worcestershire > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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/20141211/0bd97971/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 20712 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20141211/0bd97971/attachment-0001.jpe From antoine at sabot-durand.net Tue Dec 16 11:31:32 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 16 Dec 2014 17:31:32 +0100 Subject: [cdi-dev] Is the concept of mutable event payload specified Message-ID: <213B41E0-D73F-4CED-95B0-AFB50451B791@sabot-durand.net> Hi guys, Always working on Async event concept and discussion around mutable payloads. I was looking where in the spec we specified the fact that fired payload are mutable. I red-read chapter 10 (http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#events ) twice and didn?t found. I also browsed JIRA and TCK to find any ref to this feature and found nothing. On the other hand it is not specified that payload should be immutable ;) I?d be happy if some of you could have a look and see if I missed something. If I?m not wrong, the mutable payload we (including myself) advertise in CDI is a non portable feature (I?m the firs surprised here). So I propose that : 1) We decide to write something in the specification about allowing or forbidding it (I know some people not happy with this mix between observer and visitor pattern) 1bis) Should we decide to forbid it by default, we should provide an alternative mode to allow people using this unspecified feature 2) Forbid it for fireAsync() Thanks for your feedback and your correction if I missed the feature in the spec. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141216/6aef8552/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/20141216/6aef8552/attachment.bin From john.d.ament at gmail.com Tue Dec 16 11:44:37 2014 From: john.d.ament at gmail.com (John D. Ament) Date: Tue, 16 Dec 2014 16:44:37 +0000 Subject: [cdi-dev] Is the concept of mutable event payload specified References: <213B41E0-D73F-4CED-95B0-AFB50451B791@sabot-durand.net> Message-ID: What's the issue w/ fire async and mutable payload? Non-deterministic behavior depending on thread? On Tue Dec 16 2014 at 11:32:53 AM Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi guys, > > > Always working on Async event concept and discussion around mutable > payloads. I was looking where in the spec we specified the fact that fired > payload are mutable. I red-read chapter 10 ( > http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#events) twice and didn?t > found. I also browsed JIRA and TCK to find any ref to this feature and > found nothing. On the other hand it is not specified that payload should be > immutable ;) > > I?d be happy if some of you could have a look and see if I missed > something. > > If I?m not wrong, the mutable payload we (including myself) advertise in > CDI is a non portable feature (I?m the firs surprised here). So I propose > that : > > 1) We decide to write something in the specification about allowing or > forbidding it (I know some people not happy with this mix between observer > and visitor pattern) > 1bis) Should we decide to forbid it by default, we should provide an > alternative mode to allow people using this unspecified feature > 2) Forbid it for fireAsync() > > > Thanks for your feedback and your correction if I missed the feature in > the spec. > > 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/20141216/81b4a0a5/attachment.html From pmuir at redhat.com Tue Dec 16 12:39:19 2014 From: pmuir at redhat.com (Pete Muir) Date: Tue, 16 Dec 2014 17:39:19 +0000 Subject: [cdi-dev] Is the concept of mutable event payload specified In-Reply-To: <213B41E0-D73F-4CED-95B0-AFB50451B791@sabot-durand.net> References: <213B41E0-D73F-4CED-95B0-AFB50451B791@sabot-durand.net> Message-ID: I don?t think it?s specified. As objects are, by default in Java, mutable, I would assume that payloads are implicitly mutable. > On 16 Dec 2014, at 16:31, Antoine Sabot-Durand wrote: > > Hi guys, > > > Always working on Async event concept and discussion around mutable payloads. I was looking where in the spec we specified the fact that fired payload are mutable. I red-read chapter 10 (http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#events ) twice and didn?t found. I also browsed JIRA and TCK to find any ref to this feature and found nothing. On the other hand it is not specified that payload should be immutable ;) > > I?d be happy if some of you could have a look and see if I missed something. > > If I?m not wrong, the mutable payload we (including myself) advertise in CDI is a non portable feature (I?m the firs surprised here). So I propose that : > > 1) We decide to write something in the specification about allowing or forbidding it (I know some people not happy with this mix between observer and visitor pattern) > 1bis) Should we decide to forbid it by default, we should provide an alternative mode to allow people using this unspecified feature > 2) Forbid it for fireAsync() > > > Thanks for your feedback and your correction if I missed the feature in the spec. > > 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/20141216/00b88212/attachment.html From rmannibucau at gmail.com Tue Dec 16 12:46:50 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 16 Dec 2014 18:46:50 +0100 Subject: [cdi-dev] Is the concept of mutable event payload specified In-Reply-To: References: <213B41E0-D73F-4CED-95B0-AFB50451B791@sabot-durand.net> Message-ID: Hi Antoine, why isn't it portable? Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-12-16 18:39 GMT+01:00 Pete Muir : > I don?t think it?s specified. As objects are, by default in Java, mutable, I > would assume that payloads are implicitly mutable. > > On 16 Dec 2014, at 16:31, Antoine Sabot-Durand > wrote: > > Hi guys, > > > Always working on Async event concept and discussion around mutable > payloads. I was looking where in the spec we specified the fact that fired > payload are mutable. I red-read chapter 10 > (http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#events) twice and didn?t > found. I also browsed JIRA and TCK to find any ref to this feature and found > nothing. On the other hand it is not specified that payload should be > immutable ;) > > I?d be happy if some of you could have a look and see if I missed something. > > If I?m not wrong, the mutable payload we (including myself) advertise in CDI > is a non portable feature (I?m the firs surprised here). So I propose that : > > 1) We decide to write something in the specification about allowing or > forbidding it (I know some people not happy with this mix between observer > and visitor pattern) > 1bis) Should we decide to forbid it by default, we should provide an > alternative mode to allow people using this unspecified feature > 2) Forbid it for fireAsync() > > > Thanks for your feedback and your correction if I missed the feature in the > spec. > > 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. From thjanssen123 at gmail.com Tue Dec 16 13:21:48 2014 From: thjanssen123 at gmail.com (Thorben Janssen) Date: Tue, 16 Dec 2014 19:21:48 +0100 Subject: [cdi-dev] Is the concept of mutable event payload specified In-Reply-To: References: <213B41E0-D73F-4CED-95B0-AFB50451B791@sabot-durand.net> Message-ID: We should be careful with making the payload imutable. I know of several applications (and companies) that change the payload to send some information back to to the event producer. We shouldn't break these apps, if we can solve it in a different way. -- *Thorben Janssen* @thjanssen123 www.thoughts-on-java.org 2014-12-16 18:46 GMT+01:00 Romain Manni-Bucau : > > Hi Antoine, > > why isn't it portable? > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2014-12-16 18:39 GMT+01:00 Pete Muir : > > I don?t think it?s specified. As objects are, by default in Java, > mutable, I > > would assume that payloads are implicitly mutable. > > > > On 16 Dec 2014, at 16:31, Antoine Sabot-Durand > > > wrote: > > > > Hi guys, > > > > > > Always working on Async event concept and discussion around mutable > > payloads. I was looking where in the spec we specified the fact that > fired > > payload are mutable. I red-read chapter 10 > > (http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#events) twice and > didn?t > > found. I also browsed JIRA and TCK to find any ref to this feature and > found > > nothing. On the other hand it is not specified that payload should be > > immutable ;) > > > > I?d be happy if some of you could have a look and see if I missed > something. > > > > If I?m not wrong, the mutable payload we (including myself) advertise in > CDI > > is a non portable feature (I?m the firs surprised here). So I propose > that : > > > > 1) We decide to write something in the specification about allowing or > > forbidding it (I know some people not happy with this mix between > observer > > and visitor pattern) > > 1bis) Should we decide to forbid it by default, we should provide an > > alternative mode to allow people using this unspecified feature > > 2) Forbid it for fireAsync() > > > > > > Thanks for your feedback and your correction if I missed the feature in > the > > spec. > > > > 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/20141216/f74fbdb4/attachment-0001.html From jens.schumann at openknowledge.de Tue Dec 16 13:37:47 2014 From: jens.schumann at openknowledge.de (Jens Schumann) Date: Tue, 16 Dec 2014 18:37:47 +0000 Subject: [cdi-dev] Is the concept of mutable event payload specified In-Reply-To: References: <213B41E0-D73F-4CED-95B0-AFB50451B791@sabot-durand.net> , Message-ID: <9458C9BD-CB33-4A6A-95BC-60DB4A1FFC96@openknowledge.de> Same here. For instance we use mutable events to collect data. Just checked EJB 3.1 spec @Asynchronous regarding parameter immutability: As far I can tell it's not defined either. Jens On 16 Dec 2014, at 19:22, Thorben Janssen > wrote: We should be careful with making the payload imutable. I know of several applications (and companies) that change the payload to send some information back to to the event producer. We shouldn't break these apps, if we can solve it in a different way. -- Thorben Janssen @thjanssen123 www.thoughts-on-java.org 2014-12-16 18:46 GMT+01:00 Romain Manni-Bucau >: Hi Antoine, why isn't it portable? Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-12-16 18:39 GMT+01:00 Pete Muir >: > I don?t think it?s specified. As objects are, by default in Java, mutable, I > would assume that payloads are implicitly mutable. > > On 16 Dec 2014, at 16:31, Antoine Sabot-Durand > > wrote: > > Hi guys, > > > Always working on Async event concept and discussion around mutable > payloads. I was looking where in the spec we specified the fact that fired > payload are mutable. I red-read chapter 10 > (http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#events) twice and didn?t > found. I also browsed JIRA and TCK to find any ref to this feature and found > nothing. On the other hand it is not specified that payload should be > immutable ;) > > I?d be happy if some of you could have a look and see if I missed something. > > If I?m not wrong, the mutable payload we (including myself) advertise in CDI > is a non portable feature (I?m the firs surprised here). So I propose that : > > 1) We decide to write something in the specification about allowing or > forbidding it (I know some people not happy with this mix between observer > and visitor pattern) > 1bis) Should we decide to forbid it by default, we should provide an > alternative mode to allow people using this unspecified feature > 2) Forbid it for fireAsync() > > > Thanks for your feedback and your correction if I missed the feature in the > spec. > > 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. _______________________________________________ cdi-dev mailing list cdi-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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/20141216/a3d69cd1/attachment.html From rmannibucau at gmail.com Tue Dec 16 14:05:41 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 16 Dec 2014 20:05:41 +0100 Subject: [cdi-dev] Is the concept of mutable event payload specified In-Reply-To: <9458C9BD-CB33-4A6A-95BC-60DB4A1FFC96@openknowledge.de> References: <213B41E0-D73F-4CED-95B0-AFB50451B791@sabot-durand.net> <9458C9BD-CB33-4A6A-95BC-60DB4A1FFC96@openknowledge.de> Message-ID: +1, not defined is good IMO since it stays align on java. Nothing prevents giving an event holding a lock which is good IMO since it allows to use any pattern you want. @Asynch also doesn't always mean concurrent which is yet another case. Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-12-16 19:37 GMT+01:00 Jens Schumann : > Same here. For instance we use mutable events to collect data. > > Just checked EJB 3.1 spec @Asynchronous regarding parameter immutability: As > far I can tell it's not defined either. > > Jens > > > > On 16 Dec 2014, at 19:22, Thorben Janssen wrote: > > We should be careful with making the payload imutable. I know of several > applications (and companies) that change the payload to send some > information back to to the event producer. > We shouldn't break these apps, if we can solve it in a different way. > > -- > Thorben Janssen > > @thjanssen123 > www.thoughts-on-java.org > > 2014-12-16 18:46 GMT+01:00 Romain Manni-Bucau : >> >> Hi Antoine, >> >> why isn't it portable? >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2014-12-16 18:39 GMT+01:00 Pete Muir : >> > I don?t think it?s specified. As objects are, by default in Java, >> > mutable, I >> > would assume that payloads are implicitly mutable. >> > >> > On 16 Dec 2014, at 16:31, Antoine Sabot-Durand >> > >> > wrote: >> > >> > Hi guys, >> > >> > >> > Always working on Async event concept and discussion around mutable >> > payloads. I was looking where in the spec we specified the fact that >> > fired >> > payload are mutable. I red-read chapter 10 >> > (http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#events) twice and >> > didn?t >> > found. I also browsed JIRA and TCK to find any ref to this feature and >> > found >> > nothing. On the other hand it is not specified that payload should be >> > immutable ;) >> > >> > I?d be happy if some of you could have a look and see if I missed >> > something. >> > >> > If I?m not wrong, the mutable payload we (including myself) advertise in >> > CDI >> > is a non portable feature (I?m the firs surprised here). So I propose >> > that : >> > >> > 1) We decide to write something in the specification about allowing or >> > forbidding it (I know some people not happy with this mix between >> > observer >> > and visitor pattern) >> > 1bis) Should we decide to forbid it by default, we should provide an >> > alternative mode to allow people using this unspecified feature >> > 2) Forbid it for fireAsync() >> > >> > >> > Thanks for your feedback and your correction if I missed the feature in >> > the >> > spec. >> > >> > 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. > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code > under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.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 johndament at apache.org Tue Dec 16 13:30:00 2014 From: johndament at apache.org (John D. Ament) Date: Tue, 16 Dec 2014 18:30:00 +0000 Subject: [cdi-dev] Is the concept of mutable event payload specified References: <213B41E0-D73F-4CED-95B0-AFB50451B791@sabot-durand.net> Message-ID: Agreed.. I have mutable events all over my current code base. On Tue Dec 16 2014 at 1:22:05 PM Thorben Janssen wrote: > We should be careful with making the payload imutable. I know of several > applications (and companies) that change the payload to send some > information back to to the event producer. > We shouldn't break these apps, if we can solve it in a different way. > > -- > *Thorben Janssen* > > @thjanssen123 > www.thoughts-on-java.org > > 2014-12-16 18:46 GMT+01:00 Romain Manni-Bucau : >> >> Hi Antoine, >> >> why isn't it portable? >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2014-12-16 18:39 GMT+01:00 Pete Muir : >> > I don?t think it?s specified. As objects are, by default in Java, >> mutable, I >> > would assume that payloads are implicitly mutable. >> > >> > On 16 Dec 2014, at 16:31, Antoine Sabot-Durand < >> antoine at sabot-durand.net> >> > wrote: >> > >> > Hi guys, >> > >> > >> > Always working on Async event concept and discussion around mutable >> > payloads. I was looking where in the spec we specified the fact that >> fired >> > payload are mutable. I red-read chapter 10 >> > (http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#events) twice and >> didn?t >> > found. I also browsed JIRA and TCK to find any ref to this feature and >> found >> > nothing. On the other hand it is not specified that payload should be >> > immutable ;) >> > >> > I?d be happy if some of you could have a look and see if I missed >> something. >> > >> > If I?m not wrong, the mutable payload we (including myself) advertise >> in CDI >> > is a non portable feature (I?m the firs surprised here). So I propose >> that : >> > >> > 1) We decide to write something in the specification about allowing or >> > forbidding it (I know some people not happy with this mix between >> observer >> > and visitor pattern) >> > 1bis) Should we decide to forbid it by default, we should provide an >> > alternative mode to allow people using this unspecified feature >> > 2) Forbid it for fireAsync() >> > >> > >> > Thanks for your feedback and your correction if I missed the feature in >> the >> > spec. >> > >> > 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. >> > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 (http://www.apache.org/ > licenses/LICENSE-2.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/20141216/c9110dea/attachment.html From antonin at stefanutti.fr Wed Dec 17 04:49:49 2014 From: antonin at stefanutti.fr (Antonin Stefanutti) Date: Wed, 17 Dec 2014 09:49:49 +0000 Subject: [cdi-dev] Is the concept of mutable event payload specified In-Reply-To: References: <213B41E0-D73F-4CED-95B0-AFB50451B791@sabot-durand.net> , Message-ID: <1418809749672.21827@stefanutti.fr> Hi Antoine, We're using mutable event payloads to support extensibility of Camel routes AOP in our Camel CDI extension. Antonin ________________________________ From: cdi-dev-bounces at lists.jboss.org on behalf of John D. Ament Sent: Tuesday, December 16, 2014 7:30 PM To: Thorben Janssen; cdi-dev Subject: Re: [cdi-dev] Is the concept of mutable event payload specified Agreed.. I have mutable events all over my current code base. On Tue Dec 16 2014 at 1:22:05 PM Thorben Janssen > wrote: We should be careful with making the payload imutable. I know of several applications (and companies) that change the payload to send some information back to to the event producer. We shouldn't break these apps, if we can solve it in a different way. -- Thorben Janssen @thjanssen123 www.thoughts-on-java.org 2014-12-16 18:46 GMT+01:00 Romain Manni-Bucau >: Hi Antoine, why isn't it portable? Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-12-16 18:39 GMT+01:00 Pete Muir >: > I don?t think it?s specified. As objects are, by default in Java, mutable, I > would assume that payloads are implicitly mutable. > > On 16 Dec 2014, at 16:31, Antoine Sabot-Durand > > wrote: > > Hi guys, > > > Always working on Async event concept and discussion around mutable > payloads. I was looking where in the spec we specified the fact that fired > payload are mutable. I red-read chapter 10 > (http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#events) twice and didn?t > found. I also browsed JIRA and TCK to find any ref to this feature and found > nothing. On the other hand it is not specified that payload should be > immutable ;) > > I?d be happy if some of you could have a look and see if I missed something. > > If I?m not wrong, the mutable payload we (including myself) advertise in CDI > is a non portable feature (I?m the firs surprised here). So I propose that : > > 1) We decide to write something in the specification about allowing or > forbidding it (I know some people not happy with this mix between observer > and visitor pattern) > 1bis) Should we decide to forbid it by default, we should provide an > alternative mode to allow people using this unspecified feature > 2) Forbid it for fireAsync() > > > Thanks for your feedback and your correction if I missed the feature in the > spec. > > 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. _______________________________________________ cdi-dev mailing list cdi-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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/20141217/5f024579/attachment-0001.html From werner.keil at gmail.com Wed Dec 17 09:46:23 2014 From: werner.keil at gmail.com (Werner Keil) Date: Wed, 17 Dec 2014 15:46:23 +0100 Subject: [cdi-dev] cdi-dev Digest, Vol 49, Issue 13 In-Reply-To: References: Message-ID: Fully agree with Pete's assessment. Unless the (still very experimental and not even used by Co Spec Lead Oracle anywhere in Java 8;-) new type annotations that are at least in theory available from Java SE 8 onward were applied, objects are always mutable Werner On Tue, Dec 16, 2014 at 7:21 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. Is the concept of mutable event payload specified > (Antoine Sabot-Durand) > 2. Re: Is the concept of mutable event payload specified > (John D. Ament) > 3. Re: Is the concept of mutable event payload specified (Pete Muir) > 4. Re: Is the concept of mutable event payload specified > (Romain Manni-Bucau) > 5. Re: Is the concept of mutable event payload specified > (Thorben Janssen) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 16 Dec 2014 17:31:32 +0100 > From: Antoine Sabot-Durand > Subject: [cdi-dev] Is the concept of mutable event payload specified > To: cdi-dev > Message-ID: <213B41E0-D73F-4CED-95B0-AFB50451B791 at sabot-durand.net> > Content-Type: text/plain; charset="utf-8" > > Hi guys, > > > Always working on Async event concept and discussion around mutable > payloads. I was looking where in the spec we specified the fact that fired > payload are mutable. I red-read chapter 10 ( > http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#events < > http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#events>) twice and > didn?t found. I also browsed JIRA and TCK to find any ref to this feature > and found nothing. On the other hand it is not specified that payload > should be immutable ;) > > I?d be happy if some of you could have a look and see if I missed > something. > > If I?m not wrong, the mutable payload we (including myself) advertise in > CDI is a non portable feature (I?m the firs surprised here). So I propose > that : > > 1) We decide to write something in the specification about allowing or > forbidding it (I know some people not happy with this mix between observer > and visitor pattern) > 1bis) Should we decide to forbid it by default, we should provide an > alternative mode to allow people using this unspecified feature > 2) Forbid it for fireAsync() > > > Thanks for your feedback and your correction if I missed the feature in > the spec. > > Antoine > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20141216/6aef8552/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/20141216/6aef8552/attachment-0001.bin > > ------------------------------ > > Message: 2 > Date: Tue, 16 Dec 2014 16:44:37 +0000 > From: "John D. Ament" > Subject: Re: [cdi-dev] Is the concept of mutable event payload > specified > To: Antoine Sabot-Durand , cdi-dev > > Message-ID: > DVAUYPoaRoAm_Edp31-nXQM9r8rhVQ4w at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > What's the issue w/ fire async and mutable payload? Non-deterministic > behavior depending on thread? > > On Tue Dec 16 2014 at 11:32:53 AM Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > > > Hi guys, > > > > > > Always working on Async event concept and discussion around mutable > > payloads. I was looking where in the spec we specified the fact that > fired > > payload are mutable. I red-read chapter 10 ( > > http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#events) twice and > didn?t > > found. I also browsed JIRA and TCK to find any ref to this feature and > > found nothing. On the other hand it is not specified that payload should > be > > immutable ;) > > > > I?d be happy if some of you could have a look and see if I missed > > something. > > > > If I?m not wrong, the mutable payload we (including myself) advertise in > > CDI is a non portable feature (I?m the firs surprised here). So I propose > > that : > > > > 1) We decide to write something in the specification about allowing or > > forbidding it (I know some people not happy with this mix between > observer > > and visitor pattern) > > 1bis) Should we decide to forbid it by default, we should provide an > > alternative mode to allow people using this unspecified feature > > 2) Forbid it for fireAsync() > > > > > > Thanks for your feedback and your correction if I missed the feature in > > the spec. > > > > 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/20141216/81b4a0a5/attachment-0001.html > > ------------------------------ > > Message: 3 > Date: Tue, 16 Dec 2014 17:39:19 +0000 > From: Pete Muir > Subject: Re: [cdi-dev] Is the concept of mutable event payload > specified > To: Antoine Sabot-Durand > Cc: cdi-dev > Message-ID: > Content-Type: text/plain; charset="utf-8" > > I don?t think it?s specified. As objects are, by default in Java, mutable, > I would assume that payloads are implicitly mutable. > > > On 16 Dec 2014, at 16:31, Antoine Sabot-Durand > wrote: > > > > Hi guys, > > > > > > Always working on Async event concept and discussion around mutable > payloads. I was looking where in the spec we specified the fact that fired > payload are mutable. I red-read chapter 10 ( > http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#events < > http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#events>) twice and > didn?t found. I also browsed JIRA and TCK to find any ref to this feature > and found nothing. On the other hand it is not specified that payload > should be immutable ;) > > > > I?d be happy if some of you could have a look and see if I missed > something. > > > > If I?m not wrong, the mutable payload we (including myself) advertise in > CDI is a non portable feature (I?m the firs surprised here). So I propose > that : > > > > 1) We decide to write something in the specification about allowing or > forbidding it (I know some people not happy with this mix between observer > and visitor pattern) > > 1bis) Should we decide to forbid it by default, we should provide an > alternative mode to allow people using this unspecified feature > > 2) Forbid it for fireAsync() > > > > > > Thanks for your feedback and your correction if I missed the feature in > the spec. > > > > 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/20141216/00b88212/attachment-0001.html > > ------------------------------ > > Message: 4 > Date: Tue, 16 Dec 2014 18:46:50 +0100 > From: Romain Manni-Bucau > Subject: Re: [cdi-dev] Is the concept of mutable event payload > specified > To: Pete Muir > Cc: cdi-dev > Message-ID: > wOmPEO9Xw at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi Antoine, > > why isn't it portable? > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2014-12-16 18:39 GMT+01:00 Pete Muir : > > I don?t think it?s specified. As objects are, by default in Java, > mutable, I > > would assume that payloads are implicitly mutable. > > > > On 16 Dec 2014, at 16:31, Antoine Sabot-Durand > > > wrote: > > > > Hi guys, > > > > > > Always working on Async event concept and discussion around mutable > > payloads. I was looking where in the spec we specified the fact that > fired > > payload are mutable. I red-read chapter 10 > > (http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#events) twice and > didn?t > > found. I also browsed JIRA and TCK to find any ref to this feature and > found > > nothing. On the other hand it is not specified that payload should be > > immutable ;) > > > > I?d be happy if some of you could have a look and see if I missed > something. > > > > If I?m not wrong, the mutable payload we (including myself) advertise in > CDI > > is a non portable feature (I?m the firs surprised here). So I propose > that : > > > > 1) We decide to write something in the specification about allowing or > > forbidding it (I know some people not happy with this mix between > observer > > and visitor pattern) > > 1bis) Should we decide to forbid it by default, we should provide an > > alternative mode to allow people using this unspecified feature > > 2) Forbid it for fireAsync() > > > > > > Thanks for your feedback and your correction if I missed the feature in > the > > spec. > > > > 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. > > > > ------------------------------ > > Message: 5 > Date: Tue, 16 Dec 2014 19:21:48 +0100 > From: Thorben Janssen > Subject: Re: [cdi-dev] Is the concept of mutable event payload > specified > To: cdi-dev > Message-ID: > PHg++iQ4vr8ymEm0eH0zEabbHLWf7U-_cX_zBmZYQ at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > We should be careful with making the payload imutable. I know of several > applications (and companies) that change the payload to send some > information back to to the event producer. > We shouldn't break these apps, if we can solve it in a different way. > > -- > *Thorben Janssen* > > @thjanssen123 > www.thoughts-on-java.org > > 2014-12-16 18:46 GMT+01:00 Romain Manni-Bucau : > > > > Hi Antoine, > > > > why isn't it portable? > > > > > > Romain Manni-Bucau > > @rmannibucau > > http://www.tomitribe.com > > http://rmannibucau.wordpress.com > > https://github.com/rmannibucau > > > > > > 2014-12-16 18:39 GMT+01:00 Pete Muir : > > > I don?t think it?s specified. As objects are, by default in Java, > > mutable, I > > > would assume that payloads are implicitly mutable. > > > > > > On 16 Dec 2014, at 16:31, Antoine Sabot-Durand < > antoine at sabot-durand.net > > > > > > wrote: > > > > > > Hi guys, > > > > > > > > > Always working on Async event concept and discussion around mutable > > > payloads. I was looking where in the spec we specified the fact that > > fired > > > payload are mutable. I red-read chapter 10 > > > (http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#events) twice and > > didn?t > > > found. I also browsed JIRA and TCK to find any ref to this feature and > > found > > > nothing. On the other hand it is not specified that payload should be > > > immutable ;) > > > > > > I?d be happy if some of you could have a look and see if I missed > > something. > > > > > > If I?m not wrong, the mutable payload we (including myself) advertise > in > > CDI > > > is a non portable feature (I?m the firs surprised here). So I propose > > that : > > > > > > 1) We decide to write something in the specification about allowing or > > > forbidding it (I know some people not happy with this mix between > > observer > > > and visitor pattern) > > > 1bis) Should we decide to forbid it by default, we should provide an > > > alternative mode to allow people using this unspecified feature > > > 2) Forbid it for fireAsync() > > > > > > > > > Thanks for your feedback and your correction if I missed the feature in > > the > > > spec. > > > > > > 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/20141216/f74fbdb4/attachment.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 49, Issue 13 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141217/fb48f43d/attachment-0001.html From antoine at sabot-durand.net Wed Dec 17 10:40:25 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 17 Dec 2014 16:40:25 +0100 Subject: [cdi-dev] Today's meeting will be shorter and about SE Message-ID: Hi all, I have business matter and will have to shorten the meeting tonight (half an hour instead of 1h). I updated the SE doc and Antonio added useful annexes : https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing I propose we focus on this in these 30 mn regards, Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141217/4dec4ad2/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/20141217/4dec4ad2/attachment.bin From pmuir at redhat.com Wed Dec 17 11:49:02 2014 From: pmuir at redhat.com (Peter Muir) Date: Wed, 17 Dec 2014 11:49:02 -0500 (EST) Subject: [cdi-dev] PermGen with JBoss add-on In-Reply-To: References: Message-ID: <106157076.49037.1418834942084.JavaMail.zimbra@redhat.com> Antonio, did you mean to send this to cdi-dev? This seems to have more to do with WildFly... ----- Original Message ----- > Hi all, > > The other day on #IRC I mentioned having PermGen issues with the JBossAS > add-on. It's confirmed. During the HoL there are plenty of people who had > the same issue : install the JBoss add-on, start wildfly 8.1, build the app, > deploy it, go to the index.html page (fine), click on an Entity, bang ! > PermGen > > Alexis Hassler investigated it during the lab (see below). Basically, no > matter what PermGen you set, it's not taken into account. > > Again, I really think this add-on should be looked after carefully, it's very > unstable. > > Antonio > > ---------- Forwarded message ---------- > From: Alexis Hassler < alexis.hassler at gmail.com > > Date: Tue, Nov 11, 2014 at 11:37 AM > Subject: Re: Forge + Wildfly VM arguments > To: Antonio Goncalves < antonio.goncalves at gmail.com > > > > Pas de changement avec > as-setup --server wildfly8 --installDir /opt/java/wildfly-8.1.0.Final/ > --jvmargs "-Xmx512m -XX:MaxPermSize=256m" > > > Alexis > http://www.jtips.info , http://blog.alexis-hassler.com , > http://www.lyonjug.org > > 2014-11-11 11:22 GMT+01:00 Alexis Hassler < alexis.hassler at gmail.com > : > > > > Avec un wf externe, d?marr? avec as-start. > > > > ? > Pour info, en d?marrant un wf 8.1 en ligne de commande "normale" : > -D[Standalone] -Xms64m -Xmx512m -XX:MaxPermSize=256m > -Djava.net.preferIPv4Stack=true > -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true > -Dorg.jboss.boot.log.file=/opt/java/wildfly-8.1.0.Final/standalone/log/server.log > -Dlogging.configuration=file:/opt/java/wildfly-8.1.0.Final/standalone/configuration/logging.properties > > Alexis > http://www.jtips.info , http://blog.alexis-hassler.com , > http://www.lyonjug.org > > > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code > under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other intellectual > property rights inherent in such information. From antoine at sabot-durand.net Wed Dec 17 11:49:26 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 17 Dec 2014 17:49:26 +0100 Subject: [cdi-dev] Is the concept of mutable event payload specified In-Reply-To: <1418809749672.21827@stefanutti.fr> References: <213B41E0-D73F-4CED-95B0-AFB50451B791@sabot-durand.net> <, > <1418809749672.21827@stefanutti.fr> Message-ID: <1EFACDFC-267C-4F36-8B0D-22B44FF43B6A@sabot-durand.net> Ok guys, Let?s do it again. I didn?t say we have to forbid the mutability I said we have at least to explicitly write that it?s mutable and seriously think of having it immutable for event fired asynchronously. > (Pete) I don?t think it?s specified. As objects are, by default in Java, mutable, I would assume that payloads are implicitly mutable. Sorry @Pete I don?t agree with your point. Yes, in Java object are mutable but firing an event is not a standard Java feature : you send your object to a black box and let this box dispatch your object to listeners transforming one call to multiple call : it?s far from standard Java rules. Even if it?s not written it?s an observer pattern and there are people out there thinking that introducing mutability in observer is an anti-pattern since some listener will receive a different payload than the one that was sent to them. It?s like making a method call and having no guarantee that the parameter received in the callee has the same value that in the caller... I won?t start discussion on bad practice or anti pattern as I also use mutability in event but there as much reason for user to assume their payload will be mutable than the other way around. I can assure you that when I give a talk on CDI, this payload mutability is often a surprise for attendees... > (Romain) why isn't it portable? So yes @Romain it?s not portable (in theory of course, since both implementations support mutability). Someone could write a CDI implementation with event payload immutability without any issue with the spec and TCK. Most of you are so dependent of this feature that you only reacted to the idea or forbidding it (which wasn?t the content of my mail) ;). So we all agree that it?s an important feature. Therefore what?s the issue to specify this mutability and add TCK test for it ? Now I don?t deal with that subject for nothing, we are planning to introduce Async events. I think that it?ll bring extra complexity if we support mutability in async events. And even if I?m wrong and we finally go for mutability in async events, this will lead to possible side effect (lock) that could have impact on perf, so it should be explicitly written IMO. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141217/532f9d18/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/20141217/532f9d18/attachment.bin From rmannibucau at gmail.com Wed Dec 17 11:52:07 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 17 Dec 2014 17:52:07 +0100 Subject: [cdi-dev] Is the concept of mutable event payload specified In-Reply-To: <1EFACDFC-267C-4F36-8B0D-22B44FF43B6A@sabot-durand.net> References: <213B41E0-D73F-4CED-95B0-AFB50451B791@sabot-durand.net> <1418809749672.21827@stefanutti.fr> <1EFACDFC-267C-4F36-8B0D-22B44FF43B6A@sabot-durand.net> Message-ID: Not sure I follow completely your last point: you would like to add a locking mecanism in CDI? I think keeping it simple and as in plain java would be the best for a first release (2.0) You can still rely on @Singleton (ejb) for locking and surely on something in concurrency utilities wdyt? Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-12-17 17:49 GMT+01:00 Antoine Sabot-Durand : > Ok guys, > > Let?s do it again. I didn?t say we have to forbid the mutability I said we > have at least to explicitly write that it?s mutable and seriously think of > having it immutable for event fired asynchronously. > > (Pete) I don?t think it?s specified. As objects are, by default in Java, > mutable, I would assume that payloads are implicitly mutable. > > > Sorry @Pete I don?t agree with your point. Yes, in Java object are mutable > but firing an event is not a standard Java feature : you send your object to > a black box and let this box dispatch your object to listeners transforming > one call to multiple call : it?s far from standard Java rules. Even if it?s > not written it?s an observer pattern and there are people out there thinking > that introducing mutability in observer is an anti-pattern since some > listener will receive a different payload than the one that was sent to > them. > It?s like making a method call and having no guarantee that the parameter > received in the callee has the same value that in the caller... > I won?t start discussion on bad practice or anti pattern as I also use > mutability in event but there as much reason for user to assume their > payload will be mutable than the other way around. > I can assure you that when I give a talk on CDI, this payload mutability is > often a surprise for attendees... > > (Romain) why isn't it portable? > > > So yes @Romain it?s not portable (in theory of course, since both > implementations support mutability). Someone could write a CDI > implementation with event payload immutability without any issue with the > spec and TCK. > > Most of you are so dependent of this feature that you only reacted to the > idea or forbidding it (which wasn?t the content of my mail) ;). So we all > agree that it?s an important feature. Therefore what?s the issue to specify > this mutability and add TCK test for it ? > > Now I don?t deal with that subject for nothing, we are planning to introduce > Async events. I think that it?ll bring extra complexity if we support > mutability in async events. And even if I?m wrong and we finally go for > mutability in async events, this will lead to possible side effect (lock) > that could have impact on perf, so it should be explicitly written IMO. > > 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 antonio.goncalves at gmail.com Wed Dec 17 11:53:16 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Wed, 17 Dec 2014 17:53:16 +0100 Subject: [cdi-dev] PermGen with JBoss add-on In-Reply-To: <106157076.49037.1418834942084.JavaMail.zimbra@redhat.com> References: <106157076.49037.1418834942084.JavaMail.zimbra@redhat.com> Message-ID: My bad, sorry ;o) Le 17 d?c. 2014 17:49, "Peter Muir" a ?crit : > Antonio, did you mean to send this to cdi-dev? This seems to have more to > do with WildFly... > > ----- Original Message ----- > > Hi all, > > > > The other day on #IRC I mentioned having PermGen issues with the JBossAS > > add-on. It's confirmed. During the HoL there are plenty of people who had > > the same issue : install the JBoss add-on, start wildfly 8.1, build the > app, > > deploy it, go to the index.html page (fine), click on an Entity, bang ! > > PermGen > > > > Alexis Hassler investigated it during the lab (see below). Basically, no > > matter what PermGen you set, it's not taken into account. > > > > Again, I really think this add-on should be looked after carefully, it's > very > > unstable. > > > > Antonio > > > > ---------- Forwarded message ---------- > > From: Alexis Hassler < alexis.hassler at gmail.com > > > Date: Tue, Nov 11, 2014 at 11:37 AM > > Subject: Re: Forge + Wildfly VM arguments > > To: Antonio Goncalves < antonio.goncalves at gmail.com > > > > > > > Pas de changement avec > > as-setup --server wildfly8 --installDir /opt/java/wildfly-8.1.0.Final/ > > --jvmargs "-Xmx512m -XX:MaxPermSize=256m" > > > > > > Alexis > > http://www.jtips.info , http://blog.alexis-hassler.com , > > http://www.lyonjug.org > > > > 2014-11-11 11:22 GMT+01:00 Alexis Hassler < alexis.hassler at gmail.com > : > > > > > > > > Avec un wf externe, d?marr? avec as-start. > > > > > > > > ? > > Pour info, en d?marrant un wf 8.1 en ligne de commande "normale" : > > -D[Standalone] -Xms64m -Xmx512m -XX:MaxPermSize=256m > > -Djava.net.preferIPv4Stack=true > > -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true > > > -Dorg.jboss.boot.log.file=/opt/java/wildfly-8.1.0.Final/standalone/log/server.log > > > -Dlogging.configuration=file:/opt/java/wildfly-8.1.0.Final/standalone/configuration/logging.properties > > > > Alexis > > http://www.jtips.info , http://blog.alexis-hassler.com , > > http://www.lyonjug.org > > > > > > > > > > > > -- > > Antonio Goncalves > > Software architect, Java Champion and Pluralsight author > > > > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code > > under the Apache License, Version 2 > > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > > provided on this list, the provider waives all patent and other > intellectual > > property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141217/2603101f/attachment-0001.html From pmuir at redhat.com Wed Dec 17 11:53:20 2014 From: pmuir at redhat.com (Peter Muir) Date: Wed, 17 Dec 2014 11:53:20 -0500 (EST) Subject: [cdi-dev] Is the concept of mutable event payload specified In-Reply-To: <1EFACDFC-267C-4F36-8B0D-22B44FF43B6A@sabot-durand.net> References: <213B41E0-D73F-4CED-95B0-AFB50451B791@sabot-durand.net> <, > <1418809749672.21827@stefanutti.fr> <1EFACDFC-267C-4F36-8B0D-22B44FF43B6A@sabot-durand.net> Message-ID: <2056034464.50708.1418835200188.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Ok guys, > > Let?s do it again. I didn?t say we have to forbid the mutability I said we > have at least to explicitly write that it?s mutable and seriously think of > having it immutable for event fired asynchronously. > > > (Pete) I don?t think it?s specified. As objects are, by default in Java, > > mutable, I would assume that payloads are implicitly mutable. > > > Sorry @Pete I don?t agree with your point. Yes, in Java object are mutable > but firing an event is not a standard Java feature : you send your object to > a black box and let this box dispatch your object to listeners transforming > one call to multiple call : it?s far from standard Java rules. Even if it?s > not written it?s an observer pattern and there are people out there thinking > that introducing mutability in observer is an anti-pattern since some > listener will receive a different payload than the one that was sent to > them. I agree it should be tidied up. I'm simply stating that currently I would interpret the spec as allowing mutable payloads. > It?s like making a method call and having no guarantee that the parameter > received in the callee has the same value that in the caller... > I won?t start discussion on bad practice or anti pattern as I also use > mutability in event but there as much reason for user to assume their > payload will be mutable than the other way around. > I can assure you that when I give a talk on CDI, this payload mutability is > often a surprise for attendees... > > > (Romain) why isn't it portable? > > > So yes @Romain it?s not portable (in theory of course, since both > implementations support mutability). Someone could write a CDI > implementation with event payload immutability without any issue with the > spec and TCK. > > Most of you are so dependent of this feature that you only reacted to the > idea or forbidding it (which wasn?t the content of my mail) ;). So we all > agree that it?s an important feature. Therefore what?s the issue to specify > this mutability and add TCK test for it ? > > Now I don?t deal with that subject for nothing, we are planning to introduce > Async events. I think that it?ll bring extra complexity if we support > mutability in async events. And even if I?m wrong and we finally go for > mutability in async events, this will lead to possible side effect (lock) > that could have impact on perf, so it should be explicitly written IMO. > > Antoine > > > > > > > > From jose.paumard at gmail.com Wed Dec 17 13:20:44 2014 From: jose.paumard at gmail.com (=?UTF-8?Q?Jos=C3=A9_Paumard?=) Date: Wed, 17 Dec 2014 19:20:44 +0100 Subject: [cdi-dev] Is the concept of mutable event payload specified In-Reply-To: <2056034464.50708.1418835200188.JavaMail.zimbra@redhat.com> References: <213B41E0-D73F-4CED-95B0-AFB50451B791@sabot-durand.net> <1418809749672.21827@stefanutti.fr> <1EFACDFC-267C-4F36-8B0D-22B44FF43B6A@sabot-durand.net> <2056034464.50708.1418835200188.JavaMail.zimbra@redhat.com> Message-ID: There's defnitely a bug in the spec on that point, because nowhere it is stated that the event are consumed in the same thread as the one that fired the event. So, the spec allows for mutable event payload and does not state that this event should be consumed in the same thread. It is thus possible to have concurrency (incl. but not limited to visibility) issues. While introducing async events, we definitely need to do some clean up here. And be careful about not breaking existing code, of course. Jos? 2014-12-17 17:53 GMT+01:00 Peter Muir : > > > > ----- Original Message ----- > > Ok guys, > > > > Let?s do it again. I didn?t say we have to forbid the mutability I said > we > > have at least to explicitly write that it?s mutable and seriously think > of > > having it immutable for event fired asynchronously. > > > > > (Pete) I don?t think it?s specified. As objects are, by default in > Java, > > > mutable, I would assume that payloads are implicitly mutable. > > > > > > Sorry @Pete I don?t agree with your point. Yes, in Java object are > mutable > > but firing an event is not a standard Java feature : you send your > object to > > a black box and let this box dispatch your object to listeners > transforming > > one call to multiple call : it?s far from standard Java rules. Even if > it?s > > not written it?s an observer pattern and there are people out there > thinking > > that introducing mutability in observer is an anti-pattern since some > > listener will receive a different payload than the one that was sent to > > them. > > I agree it should be tidied up. I'm simply stating that currently I would > interpret the spec as allowing mutable payloads. > > > It?s like making a method call and having no guarantee that the parameter > > received in the callee has the same value that in the caller... > > I won?t start discussion on bad practice or anti pattern as I also use > > mutability in event but there as much reason for user to assume their > > payload will be mutable than the other way around. > > I can assure you that when I give a talk on CDI, this payload mutability > is > > often a surprise for attendees... > > > > > (Romain) why isn't it portable? > > > > > > So yes @Romain it?s not portable (in theory of course, since both > > implementations support mutability). Someone could write a CDI > > implementation with event payload immutability without any issue with the > > spec and TCK. > > > > Most of you are so dependent of this feature that you only reacted to the > > idea or forbidding it (which wasn?t the content of my mail) ;). So we all > > agree that it?s an important feature. Therefore what?s the issue to > specify > > this mutability and add TCK test for it ? > > > > Now I don?t deal with that subject for nothing, we are planning to > introduce > > Async events. I think that it?ll bring extra complexity if we support > > mutability in async events. And even if I?m wrong and we finally go for > > mutability in async events, this will lead to possible side effect (lock) > > that could have impact on perf, so it should be explicitly written IMO. > > > > 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. > -- 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/20141217/0ffb9811/attachment.html From struberg at yahoo.de Wed Dec 17 15:55:13 2014 From: struberg at yahoo.de (Mark Struberg) Date: Wed, 17 Dec 2014 20:55:13 +0000 (UTC) Subject: [cdi-dev] Is the concept of mutable event payload specified In-Reply-To: References: Message-ID: <78831251.539225.1418849713934.JavaMail.yahoo@jws11150.mail.ir2.yahoo.com> +1 for that interpretation. Also remember that even our own events (ProcessAnnotatedType, etc) are mutable. LieGrue, strub On Tuesday, 16 December 2014, 18:41, Pete Muir wrote: >I don?t think it?s specified. As objects are, by default in Java, mutable, I would assume that payloads are implicitly mutable. > > >On 16 Dec 2014, at 16:31, Antoine Sabot-Durand wrote: >> >Hi guys, > > > > >Always working on Async event concept and discussion around mutable payloads. I was looking where in the spec we specified the fact that fired payload are mutable. I red-read chapter 10 (http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#events) twice and didn?t found. I also browsed JIRA and TCK to find any ref to this feature and found nothing. On the other hand it is not specified that payload should be immutable ;) > > >I?d be happy if some of you could have a look and see if I missed something. > > >If I?m not wrong, the mutable payload we (including myself) advertise in CDI is a non portable feature (I?m the firs surprised here). So I propose that : > > >1) We decide to write something in the specification about allowing or forbidding it (I know some people not happy with this mix between observer and visitor pattern) >1bis) Should we decide to forbid it by default, we should provide an alternative mode to allow people using this unspecified feature >2) Forbid it for fireAsync() > > > > >Thanks for your feedback and your correction if I missed the feature in the spec. > > >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. > > From john.d.ament at gmail.com Wed Dec 17 22:33:41 2014 From: john.d.ament at gmail.com (John D. Ament) Date: Thu, 18 Dec 2014 03:33:41 +0000 Subject: [cdi-dev] Today's meeting will be shorter and about SE References: Message-ID: I thought today's meeting was pretty good. Based on one of the discussion points, I wanted to try putting together an interface that described the boot paradigm. Unfortunately even in Java 8 it doesn't work too well, I cannot assign a static variable in an interface the way I can in an abstract class. More importantly, it doesn't give us the private level expectation I would look for in this case. I best I could come up with using an interface is: public interface CDIBooter { default BeanManager initialize() { return initialize(new HashMap<>()); } BeanManager initialize(Map properties); void shutdown(); class BootHolder { static CDIBooter instance = null; } static CDIBooter instance() { if(BootHolder.instance == null) { ServiceLoader serviceLoader = ServiceLoader.load(CDIBooter.class); for(CDIBooter booter : serviceLoader) { BootHolder.instance = booter; break; } } return BootHolder.instance; } } where as the abstract class is a bit briefer, while also being private. public abstract class CDIBooter { public BeanManager initialize() { return initialize(new HashMap<>()); } public abstract BeanManager initialize(Map properties); public abstract void shutdown(); private static CDIBooter instance = null; public static CDIBooter instance() { if(instance == null) { ServiceLoader serviceLoader = ServiceLoader.load(CDIBooter.class); for(CDIBooter booter : serviceLoader) { instance = booter; break; } } return instance; } } Obviously ignore concurrency issues, etc. It does look to be safer to do an abstract class, rather than a factory-interface. John On Wed Dec 17 2014 at 10:40:44 AM Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi all, > > > I have business matter and will have to shorten the meeting tonight (half > an hour instead of 1h). > > I updated the SE doc and Antonio added useful annexes : > https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing > > I propose we focus on this in these 30 mn > > regards, > > 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/20141218/eea1b3e8/attachment-0001.html From jharting at redhat.com Thu Dec 18 02:37:43 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Thu, 18 Dec 2014 08:37:43 +0100 Subject: [cdi-dev] Today's meeting will be shorter and about SE In-Reply-To: References: Message-ID: <54928447.8090605@redhat.com> On 12/18/2014 04:33 AM, John D. Ament wrote: > I thought today's meeting was pretty good. Based on one of the > discussion points, I wanted to try putting together an interface that > described the boot paradigm. Unfortunately even in Java 8 it doesn't > work too well, I cannot assign a static variable in an interface the > way I can in an abstract class. More importantly, it doesn't give us > the private level expectation I would look for in this case. I best I > could come up with using an interface is: > > public interface CDIBooter { > default BeanManager initialize() { > return initialize(new HashMap<>()); > } > > BeanManager initialize(Map properties); Why BeanManager? I think it would be better to return CDI or its subclass rather than this low-level SPI. With the CDI class we get more user-friendly Instance for free. We could also expose Event similarly. > > void shutdown(); > > class BootHolder { > > static CDIBooter instance = null; > > } > > static CDIBooter instance() { > if(BootHolder.instance == null) { > ServiceLoader serviceLoader = > ServiceLoader.load(CDIBooter.class); > for(CDIBooter booter : serviceLoader) { > BootHolder.instance = booter; > break; > } > } > return BootHolder.instance; > } > } > > where as the abstract class is a bit briefer, while also being private. > > public abstract class CDIBooter { > public BeanManager initialize() { > return initialize(new HashMap<>()); > } > > public abstract BeanManager initialize(Map properties); > > public abstract void shutdown(); > > private static CDIBooter instance = null; > public static CDIBooter instance() { > if(instance == null) { > ServiceLoader serviceLoader = > ServiceLoader.load(CDIBooter.class); > for(CDIBooter booter : serviceLoader) { > instance = booter; > break; > } > } > return instance; > } > } > > Obviously ignore concurrency issues, etc. It does look to be safer to > do an abstract class, rather than a factory-interface. > > John > > > On Wed Dec 17 2014 at 10:40:44 AM Antoine Sabot-Durand > > wrote: > > Hi all, > > > I have business matter and will have to shorten the meeting > tonight (half an hour instead of 1h). > > I updated the SE doc and Antonio added useful annexes : > https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing > > I propose we focus on this in these 30 mn > > regards, > > 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/20141218/84ca0629/attachment.html From rmannibucau at gmail.com Thu Dec 18 02:48:30 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Thu, 18 Dec 2014 08:48:30 +0100 Subject: [cdi-dev] Today's meeting will be shorter and about SE In-Reply-To: <54928447.8090605@redhat.com> References: <54928447.8090605@redhat.com> Message-ID: Hi guys, - why shutdown and not AutoClosable? - about instance: it uses TCCL to load the impls, not sure it is intended but depending the deployment it can be an issue (is this api 100% JavaSE + flat classpath - ie more constrained than JavaSE?) + most of javax SPI creates a new instance each time "creator" is called. - Why Booter and not Container (better than factory IMO)? 1) for consistency with other spec, 2) why can I shutdown a booter ;)? Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-12-18 8:37 GMT+01:00 Jozef Hartinger : > > On 12/18/2014 04:33 AM, John D. Ament wrote: > > I thought today's meeting was pretty good. Based on one of the discussion > points, I wanted to try putting together an interface that described the > boot paradigm. Unfortunately even in Java 8 it doesn't work too well, I > cannot assign a static variable in an interface the way I can in an abstract > class. More importantly, it doesn't give us the private level expectation I > would look for in this case. I best I could come up with using an interface > is: > > public interface CDIBooter { > default BeanManager initialize() { > return initialize(new HashMap<>()); > } > > BeanManager initialize(Map properties); > > Why BeanManager? I think it would be better to return CDI or its subclass > rather than this low-level SPI. With the CDI class we get more user-friendly > Instance for free. We could also expose Event similarly. > > > void shutdown(); > > class BootHolder { > > static CDIBooter instance = null; > > } > > static CDIBooter instance() { > if(BootHolder.instance == null) { > ServiceLoader serviceLoader = > ServiceLoader.load(CDIBooter.class); > for(CDIBooter booter : serviceLoader) { > BootHolder.instance = booter; > break; > } > } > return BootHolder.instance; > } > } > > where as the abstract class is a bit briefer, while also being private. > > public abstract class CDIBooter { > public BeanManager initialize() { > return initialize(new HashMap<>()); > } > > public abstract BeanManager initialize(Map properties); > > public abstract void shutdown(); > > private static CDIBooter instance = null; > > public static CDIBooter instance() { > if(instance == null) { > ServiceLoader serviceLoader = > ServiceLoader.load(CDIBooter.class); > for(CDIBooter booter : serviceLoader) { > instance = booter; > break; > } > } > return instance; > } > } > > Obviously ignore concurrency issues, etc. It does look to be safer to do an > abstract class, rather than a factory-interface. > > John > > > On Wed Dec 17 2014 at 10:40:44 AM Antoine Sabot-Durand > wrote: >> >> Hi all, >> >> >> I have business matter and will have to shorten the meeting tonight (half >> an hour instead of 1h). >> >> I updated the SE doc and Antonio added useful annexes : >> https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing >> >> I propose we focus on this in these 30 mn >> >> regards, >> >> 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. From jharting at redhat.com Thu Dec 18 02:58:03 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Thu, 18 Dec 2014 08:58:03 +0100 Subject: [cdi-dev] Today's meeting will be shorter and about SE In-Reply-To: References: <54928447.8090605@redhat.com> Message-ID: <5492890B.1070307@redhat.com> On 12/18/2014 08:48 AM, Romain Manni-Bucau wrote: > Hi guys, > > - why shutdown and not AutoClosable? I like this idea. > - about instance: it uses TCCL to load the impls, not sure it is > intended but depending the deployment it can be an issue (is this api > 100% JavaSE + flat classpath - ie more constrained than JavaSE?) + > most of javax SPI creates a new instance each time "creator" is > called. I don't follow. Who uses TCCL? > - Why Booter and not Container (better than factory IMO)? 1) for > consistency with other spec, 2) why can I shutdown a booter ;)? Exactly > > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2014-12-18 8:37 GMT+01:00 Jozef Hartinger : >> On 12/18/2014 04:33 AM, John D. Ament wrote: >> >> I thought today's meeting was pretty good. Based on one of the discussion >> points, I wanted to try putting together an interface that described the >> boot paradigm. Unfortunately even in Java 8 it doesn't work too well, I >> cannot assign a static variable in an interface the way I can in an abstract >> class. More importantly, it doesn't give us the private level expectation I >> would look for in this case. I best I could come up with using an interface >> is: >> >> public interface CDIBooter { >> default BeanManager initialize() { >> return initialize(new HashMap<>()); >> } >> >> BeanManager initialize(Map properties); >> >> Why BeanManager? I think it would be better to return CDI or its subclass >> rather than this low-level SPI. With the CDI class we get more user-friendly >> Instance for free. We could also expose Event similarly. >> >> >> void shutdown(); >> >> class BootHolder { >> >> static CDIBooter instance = null; >> >> } >> >> static CDIBooter instance() { >> if(BootHolder.instance == null) { >> ServiceLoader serviceLoader = >> ServiceLoader.load(CDIBooter.class); >> for(CDIBooter booter : serviceLoader) { >> BootHolder.instance = booter; >> break; >> } >> } >> return BootHolder.instance; >> } >> } >> >> where as the abstract class is a bit briefer, while also being private. >> >> public abstract class CDIBooter { >> public BeanManager initialize() { >> return initialize(new HashMap<>()); >> } >> >> public abstract BeanManager initialize(Map properties); >> >> public abstract void shutdown(); >> >> private static CDIBooter instance = null; >> >> public static CDIBooter instance() { >> if(instance == null) { >> ServiceLoader serviceLoader = >> ServiceLoader.load(CDIBooter.class); >> for(CDIBooter booter : serviceLoader) { >> instance = booter; >> break; >> } >> } >> return instance; >> } >> } >> >> Obviously ignore concurrency issues, etc. It does look to be safer to do an >> abstract class, rather than a factory-interface. >> >> John >> >> >> On Wed Dec 17 2014 at 10:40:44 AM Antoine Sabot-Durand >> wrote: >>> Hi all, >>> >>> >>> I have business matter and will have to shorten the meeting tonight (half >>> an hour instead of 1h). >>> >>> I updated the SE doc and Antonio added useful annexes : >>> https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing >>> >>> I propose we focus on this in these 30 mn >>> >>> regards, >>> >>> 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. From jharting at redhat.com Thu Dec 18 03:03:01 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Thu, 18 Dec 2014 09:03:01 +0100 Subject: [cdi-dev] Is the concept of mutable event payload specified In-Reply-To: <1EFACDFC-267C-4F36-8B0D-22B44FF43B6A@sabot-durand.net> References: <213B41E0-D73F-4CED-95B0-AFB50451B791@sabot-durand.net> <, > <1418809749672.21827@stefanutti.fr> <1EFACDFC-267C-4F36-8B0D-22B44FF43B6A@sabot-durand.net> Message-ID: <54928A35.5090807@redhat.com> On 12/17/2014 05:49 PM, Antoine Sabot-Durand wrote: > Ok guys, > > Let?s do it again. I didn?t say we have to forbid the mutability I > said we have at least to explicitly write that it?s mutable Agreed. > and seriously think of having it immutable for event fired asynchronously. I agree that we should have a discussion about pros/cons. From what I saw working on a fireAsync prototype to me the possible benefits of allowing immutable events only are not worth the limitations. > >> (Pete) I don?t think it?s specified. As objects are, by default in >> Java, mutable, I would assume that payloads are implicitly mutable. > > Sorry @Pete I don?t agree with your point. Yes, in Java object are > mutable but firing an event is not a standard Java feature : you send > your object to a black box and let this box dispatch your object to > listeners transforming one call to multiple call : it?s far from > standard Java rules. Even if it?s not written it?s an observer pattern > and there are people out there thinking that introducing mutability in > observer is an anti-pattern since some listener will receive a > different payload than the one that was sent to them. > It?s like making a method call and having no guarantee that the > parameter received in the callee has the same value that in the caller... > I won?t start discussion on bad practice or anti pattern as I also > use mutability in event but there as much reason for user to assume > their payload will be mutable than the other way around. > I can assure you that when I give a talk on CDI, this payload > mutability is often a surprise for attendees... > >> (Romain) why isn't it portable? > > So yes @Romain it?s not portable (in theory of course, since both > implementations support mutability). Someone could write a CDI > implementation with event payload immutability without any issue with > the spec and TCK. > > Most of you are so dependent of this feature that you only reacted to > the idea or forbidding it (which wasn?t the content of my mail) ;). So > we all agree that it?s an important feature. Therefore what?s the > issue to specify this mutability and add TCK test for it ? > > Now I don?t deal with that subject for nothing, we are planning to > introduce Async events. I think that it?ll bring extra complexity if > we support mutability in async events. And even if I?m wrong and we > finally go for mutability in async events, this will lead to possible > side effect (lock) that could have impact on perf, so it should be > explicitly written IMO. > > 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/20141218/43674926/attachment-0001.html From rmannibucau at gmail.com Thu Dec 18 03:14:15 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Thu, 18 Dec 2014 09:14:15 +0100 Subject: [cdi-dev] Today's meeting will be shorter and about SE In-Reply-To: <5492890B.1070307@redhat.com> References: <54928447.8090605@redhat.com> <5492890B.1070307@redhat.com> Message-ID: ServiceLoader.load() = ServiceLoader.load(, tccl) I was thinking to a plain servlet engine (tomcat to not say any name) and CDI container API to boot in webapps. Having cdi API in tomcat itself and CDI impl in webapps (Weld in webapp1, OWB in webapp2 for instance). This would mean using one webapp classloader to find the booter/container. This is fine excepted if the instance is cached. Same thought in more complicated about OSGi but I guess it is not yet the target. Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-12-18 8:58 GMT+01:00 Jozef Hartinger : > > On 12/18/2014 08:48 AM, Romain Manni-Bucau wrote: >> >> Hi guys, >> >> - why shutdown and not AutoClosable? > > I like this idea. >> >> - about instance: it uses TCCL to load the impls, not sure it is >> intended but depending the deployment it can be an issue (is this api >> 100% JavaSE + flat classpath - ie more constrained than JavaSE?) + >> most of javax SPI creates a new instance each time "creator" is >> called. > > I don't follow. Who uses TCCL? >> >> - Why Booter and not Container (better than factory IMO)? 1) for >> consistency with other spec, 2) why can I shutdown a booter ;)? > > Exactly > >> >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2014-12-18 8:37 GMT+01:00 Jozef Hartinger : >>> >>> On 12/18/2014 04:33 AM, John D. Ament wrote: >>> >>> I thought today's meeting was pretty good. Based on one of the >>> discussion >>> points, I wanted to try putting together an interface that described the >>> boot paradigm. Unfortunately even in Java 8 it doesn't work too well, I >>> cannot assign a static variable in an interface the way I can in an >>> abstract >>> class. More importantly, it doesn't give us the private level >>> expectation I >>> would look for in this case. I best I could come up with using an >>> interface >>> is: >>> >>> public interface CDIBooter { >>> default BeanManager initialize() { >>> return initialize(new HashMap<>()); >>> } >>> >>> BeanManager initialize(Map properties); >>> >>> Why BeanManager? I think it would be better to return CDI or its subclass >>> rather than this low-level SPI. With the CDI class we get more >>> user-friendly >>> Instance for free. We could also expose Event similarly. >>> >>> >>> void shutdown(); >>> >>> class BootHolder { >>> >>> static CDIBooter instance = null; >>> >>> } >>> >>> static CDIBooter instance() { >>> if(BootHolder.instance == null) { >>> ServiceLoader serviceLoader = >>> ServiceLoader.load(CDIBooter.class); >>> for(CDIBooter booter : serviceLoader) { >>> BootHolder.instance = booter; >>> break; >>> } >>> } >>> return BootHolder.instance; >>> } >>> } >>> >>> where as the abstract class is a bit briefer, while also being private. >>> >>> public abstract class CDIBooter { >>> public BeanManager initialize() { >>> return initialize(new HashMap<>()); >>> } >>> >>> public abstract BeanManager initialize(Map properties); >>> >>> public abstract void shutdown(); >>> >>> private static CDIBooter instance = null; >>> >>> public static CDIBooter instance() { >>> if(instance == null) { >>> ServiceLoader serviceLoader = >>> ServiceLoader.load(CDIBooter.class); >>> for(CDIBooter booter : serviceLoader) { >>> instance = booter; >>> break; >>> } >>> } >>> return instance; >>> } >>> } >>> >>> Obviously ignore concurrency issues, etc. It does look to be safer to do >>> an >>> abstract class, rather than a factory-interface. >>> >>> John >>> >>> >>> On Wed Dec 17 2014 at 10:40:44 AM Antoine Sabot-Durand >>> wrote: >>>> >>>> Hi all, >>>> >>>> >>>> I have business matter and will have to shorten the meeting tonight >>>> (half >>>> an hour instead of 1h). >>>> >>>> I updated the SE doc and Antonio added useful annexes : >>>> >>>> https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing >>>> >>>> I propose we focus on this in these 30 mn >>>> >>>> regards, >>>> >>>> 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. > > From jose.paumard at gmail.com Thu Dec 18 03:19:27 2014 From: jose.paumard at gmail.com (=?UTF-8?Q?Jos=C3=A9_Paumard?=) Date: Thu, 18 Dec 2014 09:19:27 +0100 Subject: [cdi-dev] Today's meeting will be shorter and about SE In-Reply-To: References: <54928447.8090605@redhat.com> <5492890B.1070307@redhat.com> Message-ID: I think we need to think more about how to close the Container. We need to take into account the fact that there wil be async process running in ExecutorServices (SE) or ManagedExecutorServices (EE). So the shutting down the container will mean shutting down these ES too. So I think we should need to carefully look at the way ES are closed. The question being : what do we do with async tasks that are still running : should we abruptely interrupt them ? give them a chance to complete ? All these are exposed in different methods of ES : shutdown(), shutdownNow() and awaitTermination(timeout). Since the container will have to call one of these methods per ES it will manage, I think we should also expose them. Jos? 2014-12-18 9:14 GMT+01:00 Romain Manni-Bucau : > > ServiceLoader.load() = ServiceLoader.load(, tccl) > > I was thinking to a plain servlet engine (tomcat to not say any name) > and CDI container API to boot in webapps. Having cdi API in tomcat > itself and CDI impl in webapps (Weld in webapp1, OWB in webapp2 for > instance). This would mean using one webapp classloader to find the > booter/container. This is fine excepted if the instance is cached. > > Same thought in more complicated about OSGi but I guess it is not yet > the target. > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2014-12-18 8:58 GMT+01:00 Jozef Hartinger : > > > > On 12/18/2014 08:48 AM, Romain Manni-Bucau wrote: > >> > >> Hi guys, > >> > >> - why shutdown and not AutoClosable? > > > > I like this idea. > >> > >> - about instance: it uses TCCL to load the impls, not sure it is > >> intended but depending the deployment it can be an issue (is this api > >> 100% JavaSE + flat classpath - ie more constrained than JavaSE?) + > >> most of javax SPI creates a new instance each time "creator" is > >> called. > > > > I don't follow. Who uses TCCL? > >> > >> - Why Booter and not Container (better than factory IMO)? 1) for > >> consistency with other spec, 2) why can I shutdown a booter ;)? > > > > Exactly > > > >> > >> > >> > >> Romain Manni-Bucau > >> @rmannibucau > >> http://www.tomitribe.com > >> http://rmannibucau.wordpress.com > >> https://github.com/rmannibucau > >> > >> > >> 2014-12-18 8:37 GMT+01:00 Jozef Hartinger : > >>> > >>> On 12/18/2014 04:33 AM, John D. Ament wrote: > >>> > >>> I thought today's meeting was pretty good. Based on one of the > >>> discussion > >>> points, I wanted to try putting together an interface that described > the > >>> boot paradigm. Unfortunately even in Java 8 it doesn't work too well, > I > >>> cannot assign a static variable in an interface the way I can in an > >>> abstract > >>> class. More importantly, it doesn't give us the private level > >>> expectation I > >>> would look for in this case. I best I could come up with using an > >>> interface > >>> is: > >>> > >>> public interface CDIBooter { > >>> default BeanManager initialize() { > >>> return initialize(new HashMap<>()); > >>> } > >>> > >>> BeanManager initialize(Map properties); > >>> > >>> Why BeanManager? I think it would be better to return CDI or its > subclass > >>> rather than this low-level SPI. With the CDI class we get more > >>> user-friendly > >>> Instance for free. We could also expose Event similarly. > >>> > >>> > >>> void shutdown(); > >>> > >>> class BootHolder { > >>> > >>> static CDIBooter instance = null; > >>> > >>> } > >>> > >>> static CDIBooter instance() { > >>> if(BootHolder.instance == null) { > >>> ServiceLoader serviceLoader = > >>> ServiceLoader.load(CDIBooter.class); > >>> for(CDIBooter booter : serviceLoader) { > >>> BootHolder.instance = booter; > >>> break; > >>> } > >>> } > >>> return BootHolder.instance; > >>> } > >>> } > >>> > >>> where as the abstract class is a bit briefer, while also being private. > >>> > >>> public abstract class CDIBooter { > >>> public BeanManager initialize() { > >>> return initialize(new HashMap<>()); > >>> } > >>> > >>> public abstract BeanManager initialize(Map properties); > >>> > >>> public abstract void shutdown(); > >>> > >>> private static CDIBooter instance = null; > >>> > >>> public static CDIBooter instance() { > >>> if(instance == null) { > >>> ServiceLoader serviceLoader = > >>> ServiceLoader.load(CDIBooter.class); > >>> for(CDIBooter booter : serviceLoader) { > >>> instance = booter; > >>> break; > >>> } > >>> } > >>> return instance; > >>> } > >>> } > >>> > >>> Obviously ignore concurrency issues, etc. It does look to be safer to > do > >>> an > >>> abstract class, rather than a factory-interface. > >>> > >>> John > >>> > >>> > >>> On Wed Dec 17 2014 at 10:40:44 AM Antoine Sabot-Durand > >>> wrote: > >>>> > >>>> Hi all, > >>>> > >>>> > >>>> I have business matter and will have to shorten the meeting tonight > >>>> (half > >>>> an hour instead of 1h). > >>>> > >>>> I updated the SE doc and Antonio added useful annexes : > >>>> > >>>> > https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing > >>>> > >>>> I propose we focus on this in these 30 mn > >>>> > >>>> regards, > >>>> > >>>> 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. > > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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/20141218/470f4454/attachment-0001.html From rmannibucau at gmail.com Thu Dec 18 03:28:24 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Thu, 18 Dec 2014 09:28:24 +0100 Subject: [cdi-dev] Today's meeting will be shorter and about SE In-Reply-To: References: <54928447.8090605@redhat.com> <5492890B.1070307@redhat.com> Message-ID: Why exposing them? When not simply exposing the executor service (in "init" method). CDIContainer cdi = CDIContainer.init(singletonMap(ExecutorService.class, myEs)); // do something awesome shutdownAsIwant(myEs); cdi.close(); Would avoid to have a lot of method several users will not care about. By default it would do a if (timeout <= 0 || !defaultEs.awaitTermination(timeout, MILLISECONDS)) { for (Runnable r : defaultEs.shutdownNow()) { try { r.cancel(); } catch(e) { log(e); } } } with timeout a property of the init map with a default in CDIContainer (constant) wdyt? Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-12-18 9:19 GMT+01:00 Jos? Paumard : > I think we need to think more about how to close the Container. > > We need to take into account the fact that there wil be async process > running in ExecutorServices (SE) or ManagedExecutorServices (EE). So the > shutting down the container will mean shutting down these ES too. > > So I think we should need to carefully look at the way ES are closed. The > question being : what do we do with async tasks that are still running : > should we abruptely interrupt them ? give them a chance to complete ? All > these are exposed in different methods of ES : shutdown(), shutdownNow() and > awaitTermination(timeout). Since the container will have to call one of > these methods per ES it will manage, I think we should also expose them. > > Jos? > > > 2014-12-18 9:14 GMT+01:00 Romain Manni-Bucau : >> >> ServiceLoader.load() = ServiceLoader.load(, tccl) >> >> I was thinking to a plain servlet engine (tomcat to not say any name) >> and CDI container API to boot in webapps. Having cdi API in tomcat >> itself and CDI impl in webapps (Weld in webapp1, OWB in webapp2 for >> instance). This would mean using one webapp classloader to find the >> booter/container. This is fine excepted if the instance is cached. >> >> Same thought in more complicated about OSGi but I guess it is not yet >> the target. >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2014-12-18 8:58 GMT+01:00 Jozef Hartinger : >> > >> > On 12/18/2014 08:48 AM, Romain Manni-Bucau wrote: >> >> >> >> Hi guys, >> >> >> >> - why shutdown and not AutoClosable? >> > >> > I like this idea. >> >> >> >> - about instance: it uses TCCL to load the impls, not sure it is >> >> intended but depending the deployment it can be an issue (is this api >> >> 100% JavaSE + flat classpath - ie more constrained than JavaSE?) + >> >> most of javax SPI creates a new instance each time "creator" is >> >> called. >> > >> > I don't follow. Who uses TCCL? >> >> >> >> - Why Booter and not Container (better than factory IMO)? 1) for >> >> consistency with other spec, 2) why can I shutdown a booter ;)? >> > >> > Exactly >> > >> >> >> >> >> >> >> >> Romain Manni-Bucau >> >> @rmannibucau >> >> http://www.tomitribe.com >> >> http://rmannibucau.wordpress.com >> >> https://github.com/rmannibucau >> >> >> >> >> >> 2014-12-18 8:37 GMT+01:00 Jozef Hartinger : >> >>> >> >>> On 12/18/2014 04:33 AM, John D. Ament wrote: >> >>> >> >>> I thought today's meeting was pretty good. Based on one of the >> >>> discussion >> >>> points, I wanted to try putting together an interface that described >> >>> the >> >>> boot paradigm. Unfortunately even in Java 8 it doesn't work too well, >> >>> I >> >>> cannot assign a static variable in an interface the way I can in an >> >>> abstract >> >>> class. More importantly, it doesn't give us the private level >> >>> expectation I >> >>> would look for in this case. I best I could come up with using an >> >>> interface >> >>> is: >> >>> >> >>> public interface CDIBooter { >> >>> default BeanManager initialize() { >> >>> return initialize(new HashMap<>()); >> >>> } >> >>> >> >>> BeanManager initialize(Map properties); >> >>> >> >>> Why BeanManager? I think it would be better to return CDI or its >> >>> subclass >> >>> rather than this low-level SPI. With the CDI class we get more >> >>> user-friendly >> >>> Instance for free. We could also expose Event similarly. >> >>> >> >>> >> >>> void shutdown(); >> >>> >> >>> class BootHolder { >> >>> >> >>> static CDIBooter instance = null; >> >>> >> >>> } >> >>> >> >>> static CDIBooter instance() { >> >>> if(BootHolder.instance == null) { >> >>> ServiceLoader serviceLoader = >> >>> ServiceLoader.load(CDIBooter.class); >> >>> for(CDIBooter booter : serviceLoader) { >> >>> BootHolder.instance = booter; >> >>> break; >> >>> } >> >>> } >> >>> return BootHolder.instance; >> >>> } >> >>> } >> >>> >> >>> where as the abstract class is a bit briefer, while also being >> >>> private. >> >>> >> >>> public abstract class CDIBooter { >> >>> public BeanManager initialize() { >> >>> return initialize(new HashMap<>()); >> >>> } >> >>> >> >>> public abstract BeanManager initialize(Map properties); >> >>> >> >>> public abstract void shutdown(); >> >>> >> >>> private static CDIBooter instance = null; >> >>> >> >>> public static CDIBooter instance() { >> >>> if(instance == null) { >> >>> ServiceLoader serviceLoader = >> >>> ServiceLoader.load(CDIBooter.class); >> >>> for(CDIBooter booter : serviceLoader) { >> >>> instance = booter; >> >>> break; >> >>> } >> >>> } >> >>> return instance; >> >>> } >> >>> } >> >>> >> >>> Obviously ignore concurrency issues, etc. It does look to be safer to >> >>> do >> >>> an >> >>> abstract class, rather than a factory-interface. >> >>> >> >>> John >> >>> >> >>> >> >>> On Wed Dec 17 2014 at 10:40:44 AM Antoine Sabot-Durand >> >>> wrote: >> >>>> >> >>>> Hi all, >> >>>> >> >>>> >> >>>> I have business matter and will have to shorten the meeting tonight >> >>>> (half >> >>>> an hour instead of 1h). >> >>>> >> >>>> I updated the SE doc and Antonio added useful annexes : >> >>>> >> >>>> >> >>>> https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing >> >>>> >> >>>> I propose we focus on this in these 30 mn >> >>>> >> >>>> regards, >> >>>> >> >>>> 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. >> > >> > >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.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 From jose.paumard at gmail.com Thu Dec 18 03:58:41 2014 From: jose.paumard at gmail.com (=?UTF-8?Q?Jos=C3=A9_Paumard?=) Date: Thu, 18 Dec 2014 09:58:41 +0100 Subject: [cdi-dev] Today's meeting will be shorter and about SE In-Reply-To: References: <54928447.8090605@redhat.com> <5492890B.1070307@redhat.com> Message-ID: >From what we wrote about async events, ES can be submitted through the fireAsync call, following the patterns of CompletionStage. We can also submit a default ES while building a CDI container (a you wrote), and if we dont the default ES will probably be the default ForkJoinPool. So we may have more than one ES, making things more complicated than the pattern you wrote. I think that having the user to close all the ESes will lead to the same pattern again and again : for (ES es : cdi.getESes()) { myShutdown(es) ; } I'd prefer to have a cdi.shutdown(), cdi.shudownNow() or cdi.awaitTermination(...) or whatever we call those methods, to encapsulate this code. Seems cleaner to me. It might look like CDI is becoming an ES itself, but it's delegation, not inheritance. 2014-12-18 9:28 GMT+01:00 Romain Manni-Bucau : > > Why exposing them? When not simply exposing the executor service (in > "init" method). > > CDIContainer cdi = CDIContainer.init(singletonMap(ExecutorService.class, > myEs)); > // do something awesome > shutdownAsIwant(myEs); > cdi.close(); > > Would avoid to have a lot of method several users will not care about. > > By default it would do a if (timeout <= 0 || > !defaultEs.awaitTermination(timeout, MILLISECONDS)) { for (Runnable r > : defaultEs.shutdownNow()) { try { r.cancel(); } catch(e) { log(e); } > } } with timeout a property of the init map with a default in > CDIContainer (constant) > > wdyt? > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2014-12-18 9:19 GMT+01:00 Jos? Paumard : > > I think we need to think more about how to close the Container. > > > > We need to take into account the fact that there wil be async process > > running in ExecutorServices (SE) or ManagedExecutorServices (EE). So the > > shutting down the container will mean shutting down these ES too. > > > > So I think we should need to carefully look at the way ES are closed. The > > question being : what do we do with async tasks that are still running : > > should we abruptely interrupt them ? give them a chance to complete ? All > > these are exposed in different methods of ES : shutdown(), shutdownNow() > and > > awaitTermination(timeout). Since the container will have to call one of > > these methods per ES it will manage, I think we should also expose them. > > > > Jos? > > > > > > 2014-12-18 9:14 GMT+01:00 Romain Manni-Bucau : > >> > >> ServiceLoader.load() = ServiceLoader.load(, tccl) > >> > >> I was thinking to a plain servlet engine (tomcat to not say any name) > >> and CDI container API to boot in webapps. Having cdi API in tomcat > >> itself and CDI impl in webapps (Weld in webapp1, OWB in webapp2 for > >> instance). This would mean using one webapp classloader to find the > >> booter/container. This is fine excepted if the instance is cached. > >> > >> Same thought in more complicated about OSGi but I guess it is not yet > >> the target. > >> > >> > >> Romain Manni-Bucau > >> @rmannibucau > >> http://www.tomitribe.com > >> http://rmannibucau.wordpress.com > >> https://github.com/rmannibucau > >> > >> > >> 2014-12-18 8:58 GMT+01:00 Jozef Hartinger : > >> > > >> > On 12/18/2014 08:48 AM, Romain Manni-Bucau wrote: > >> >> > >> >> Hi guys, > >> >> > >> >> - why shutdown and not AutoClosable? > >> > > >> > I like this idea. > >> >> > >> >> - about instance: it uses TCCL to load the impls, not sure it is > >> >> intended but depending the deployment it can be an issue (is this api > >> >> 100% JavaSE + flat classpath - ie more constrained than JavaSE?) + > >> >> most of javax SPI creates a new instance each time "creator" is > >> >> called. > >> > > >> > I don't follow. Who uses TCCL? > >> >> > >> >> - Why Booter and not Container (better than factory IMO)? 1) for > >> >> consistency with other spec, 2) why can I shutdown a booter ;)? > >> > > >> > Exactly > >> > > >> >> > >> >> > >> >> > >> >> Romain Manni-Bucau > >> >> @rmannibucau > >> >> http://www.tomitribe.com > >> >> http://rmannibucau.wordpress.com > >> >> https://github.com/rmannibucau > >> >> > >> >> > >> >> 2014-12-18 8:37 GMT+01:00 Jozef Hartinger : > >> >>> > >> >>> On 12/18/2014 04:33 AM, John D. Ament wrote: > >> >>> > >> >>> I thought today's meeting was pretty good. Based on one of the > >> >>> discussion > >> >>> points, I wanted to try putting together an interface that described > >> >>> the > >> >>> boot paradigm. Unfortunately even in Java 8 it doesn't work too > well, > >> >>> I > >> >>> cannot assign a static variable in an interface the way I can in an > >> >>> abstract > >> >>> class. More importantly, it doesn't give us the private level > >> >>> expectation I > >> >>> would look for in this case. I best I could come up with using an > >> >>> interface > >> >>> is: > >> >>> > >> >>> public interface CDIBooter { > >> >>> default BeanManager initialize() { > >> >>> return initialize(new HashMap<>()); > >> >>> } > >> >>> > >> >>> BeanManager initialize(Map properties); > >> >>> > >> >>> Why BeanManager? I think it would be better to return CDI or its > >> >>> subclass > >> >>> rather than this low-level SPI. With the CDI class we get more > >> >>> user-friendly > >> >>> Instance for free. We could also expose Event similarly. > >> >>> > >> >>> > >> >>> void shutdown(); > >> >>> > >> >>> class BootHolder { > >> >>> > >> >>> static CDIBooter instance = null; > >> >>> > >> >>> } > >> >>> > >> >>> static CDIBooter instance() { > >> >>> if(BootHolder.instance == null) { > >> >>> ServiceLoader serviceLoader = > >> >>> ServiceLoader.load(CDIBooter.class); > >> >>> for(CDIBooter booter : serviceLoader) { > >> >>> BootHolder.instance = booter; > >> >>> break; > >> >>> } > >> >>> } > >> >>> return BootHolder.instance; > >> >>> } > >> >>> } > >> >>> > >> >>> where as the abstract class is a bit briefer, while also being > >> >>> private. > >> >>> > >> >>> public abstract class CDIBooter { > >> >>> public BeanManager initialize() { > >> >>> return initialize(new HashMap<>()); > >> >>> } > >> >>> > >> >>> public abstract BeanManager initialize(Map properties); > >> >>> > >> >>> public abstract void shutdown(); > >> >>> > >> >>> private static CDIBooter instance = null; > >> >>> > >> >>> public static CDIBooter instance() { > >> >>> if(instance == null) { > >> >>> ServiceLoader serviceLoader = > >> >>> ServiceLoader.load(CDIBooter.class); > >> >>> for(CDIBooter booter : serviceLoader) { > >> >>> instance = booter; > >> >>> break; > >> >>> } > >> >>> } > >> >>> return instance; > >> >>> } > >> >>> } > >> >>> > >> >>> Obviously ignore concurrency issues, etc. It does look to be safer > to > >> >>> do > >> >>> an > >> >>> abstract class, rather than a factory-interface. > >> >>> > >> >>> John > >> >>> > >> >>> > >> >>> On Wed Dec 17 2014 at 10:40:44 AM Antoine Sabot-Durand > >> >>> wrote: > >> >>>> > >> >>>> Hi all, > >> >>>> > >> >>>> > >> >>>> I have business matter and will have to shorten the meeting tonight > >> >>>> (half > >> >>>> an hour instead of 1h). > >> >>>> > >> >>>> I updated the SE doc and Antonio added useful annexes : > >> >>>> > >> >>>> > >> >>>> > https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing > >> >>>> > >> >>>> I propose we focus on this in these 30 mn > >> >>>> > >> >>>> regards, > >> >>>> > >> >>>> 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. > >> > > >> > > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> Note that for all code provided on this list, the provider licenses the > >> code under the Apache License, Version 2 > >> (http://www.apache.org/licenses/LICENSE-2.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/20141218/0db13c55/attachment-0001.html From rmannibucau at gmail.com Thu Dec 18 04:18:59 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Thu, 18 Dec 2014 10:18:59 +0100 Subject: [cdi-dev] Today's meeting will be shorter and about SE In-Reply-To: References: <54928447.8090605@redhat.com> <5492890B.1070307@redhat.com> Message-ID: 2014-12-18 9:58 GMT+01:00 Jos? Paumard : > From what we wrote about async events, ES can be submitted through the > fireAsync call, following the patterns of CompletionStage. We can also > submit a default ES while building a CDI container (a you wrote), and if we > dont the default ES will probably be the default ForkJoinPool. > > So we may have more than one ES, making things more complicated than the > pattern you wrote. I think that having the user to close all the ESes will > lead to the same pattern again and again : > for (ES es : cdi.getESes()) { > myShutdown(es) ; > } > Sorry I missed something here: how can we get multiple ES? Basically if CDI needs a ES behing the scene I expect it expose few config like potential concurrent calls number etc...In such a case I'm not sure if having multiple ES would be a good idea. > I'd prefer to have a cdi.shutdown(), cdi.shudownNow() or > cdi.awaitTermination(...) or whatever we call those methods, to encapsulate > this code. Seems cleaner to me. It might look like CDI is becoming an ES > itself, but it's delegation, not inheritance. > > > > 2014-12-18 9:28 GMT+01:00 Romain Manni-Bucau : >> >> Why exposing them? When not simply exposing the executor service (in >> "init" method). >> >> CDIContainer cdi = CDIContainer.init(singletonMap(ExecutorService.class, >> myEs)); >> // do something awesome >> shutdownAsIwant(myEs); >> cdi.close(); >> >> Would avoid to have a lot of method several users will not care about. >> >> By default it would do a if (timeout <= 0 || >> !defaultEs.awaitTermination(timeout, MILLISECONDS)) { for (Runnable r >> : defaultEs.shutdownNow()) { try { r.cancel(); } catch(e) { log(e); } >> } } with timeout a property of the init map with a default in >> CDIContainer (constant) >> >> wdyt? >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2014-12-18 9:19 GMT+01:00 Jos? Paumard : >> > I think we need to think more about how to close the Container. >> > >> > We need to take into account the fact that there wil be async process >> > running in ExecutorServices (SE) or ManagedExecutorServices (EE). So the >> > shutting down the container will mean shutting down these ES too. >> > >> > So I think we should need to carefully look at the way ES are closed. >> > The >> > question being : what do we do with async tasks that are still running : >> > should we abruptely interrupt them ? give them a chance to complete ? >> > All >> > these are exposed in different methods of ES : shutdown(), shutdownNow() >> > and >> > awaitTermination(timeout). Since the container will have to call one of >> > these methods per ES it will manage, I think we should also expose them. >> > >> > Jos? >> > >> > >> > 2014-12-18 9:14 GMT+01:00 Romain Manni-Bucau : >> >> >> >> ServiceLoader.load() = ServiceLoader.load(, tccl) >> >> >> >> I was thinking to a plain servlet engine (tomcat to not say any name) >> >> and CDI container API to boot in webapps. Having cdi API in tomcat >> >> itself and CDI impl in webapps (Weld in webapp1, OWB in webapp2 for >> >> instance). This would mean using one webapp classloader to find the >> >> booter/container. This is fine excepted if the instance is cached. >> >> >> >> Same thought in more complicated about OSGi but I guess it is not yet >> >> the target. >> >> >> >> >> >> Romain Manni-Bucau >> >> @rmannibucau >> >> http://www.tomitribe.com >> >> http://rmannibucau.wordpress.com >> >> https://github.com/rmannibucau >> >> >> >> >> >> 2014-12-18 8:58 GMT+01:00 Jozef Hartinger : >> >> > >> >> > On 12/18/2014 08:48 AM, Romain Manni-Bucau wrote: >> >> >> >> >> >> Hi guys, >> >> >> >> >> >> - why shutdown and not AutoClosable? >> >> > >> >> > I like this idea. >> >> >> >> >> >> - about instance: it uses TCCL to load the impls, not sure it is >> >> >> intended but depending the deployment it can be an issue (is this >> >> >> api >> >> >> 100% JavaSE + flat classpath - ie more constrained than JavaSE?) + >> >> >> most of javax SPI creates a new instance each time "creator" is >> >> >> called. >> >> > >> >> > I don't follow. Who uses TCCL? >> >> >> >> >> >> - Why Booter and not Container (better than factory IMO)? 1) for >> >> >> consistency with other spec, 2) why can I shutdown a booter ;)? >> >> > >> >> > Exactly >> >> > >> >> >> >> >> >> >> >> >> >> >> >> Romain Manni-Bucau >> >> >> @rmannibucau >> >> >> http://www.tomitribe.com >> >> >> http://rmannibucau.wordpress.com >> >> >> https://github.com/rmannibucau >> >> >> >> >> >> >> >> >> 2014-12-18 8:37 GMT+01:00 Jozef Hartinger : >> >> >>> >> >> >>> On 12/18/2014 04:33 AM, John D. Ament wrote: >> >> >>> >> >> >>> I thought today's meeting was pretty good. Based on one of the >> >> >>> discussion >> >> >>> points, I wanted to try putting together an interface that >> >> >>> described >> >> >>> the >> >> >>> boot paradigm. Unfortunately even in Java 8 it doesn't work too >> >> >>> well, >> >> >>> I >> >> >>> cannot assign a static variable in an interface the way I can in an >> >> >>> abstract >> >> >>> class. More importantly, it doesn't give us the private level >> >> >>> expectation I >> >> >>> would look for in this case. I best I could come up with using an >> >> >>> interface >> >> >>> is: >> >> >>> >> >> >>> public interface CDIBooter { >> >> >>> default BeanManager initialize() { >> >> >>> return initialize(new HashMap<>()); >> >> >>> } >> >> >>> >> >> >>> BeanManager initialize(Map properties); >> >> >>> >> >> >>> Why BeanManager? I think it would be better to return CDI or its >> >> >>> subclass >> >> >>> rather than this low-level SPI. With the CDI class we get more >> >> >>> user-friendly >> >> >>> Instance for free. We could also expose Event similarly. >> >> >>> >> >> >>> >> >> >>> void shutdown(); >> >> >>> >> >> >>> class BootHolder { >> >> >>> >> >> >>> static CDIBooter instance = null; >> >> >>> >> >> >>> } >> >> >>> >> >> >>> static CDIBooter instance() { >> >> >>> if(BootHolder.instance == null) { >> >> >>> ServiceLoader serviceLoader = >> >> >>> ServiceLoader.load(CDIBooter.class); >> >> >>> for(CDIBooter booter : serviceLoader) { >> >> >>> BootHolder.instance = booter; >> >> >>> break; >> >> >>> } >> >> >>> } >> >> >>> return BootHolder.instance; >> >> >>> } >> >> >>> } >> >> >>> >> >> >>> where as the abstract class is a bit briefer, while also being >> >> >>> private. >> >> >>> >> >> >>> public abstract class CDIBooter { >> >> >>> public BeanManager initialize() { >> >> >>> return initialize(new HashMap<>()); >> >> >>> } >> >> >>> >> >> >>> public abstract BeanManager initialize(Map properties); >> >> >>> >> >> >>> public abstract void shutdown(); >> >> >>> >> >> >>> private static CDIBooter instance = null; >> >> >>> >> >> >>> public static CDIBooter instance() { >> >> >>> if(instance == null) { >> >> >>> ServiceLoader serviceLoader = >> >> >>> ServiceLoader.load(CDIBooter.class); >> >> >>> for(CDIBooter booter : serviceLoader) { >> >> >>> instance = booter; >> >> >>> break; >> >> >>> } >> >> >>> } >> >> >>> return instance; >> >> >>> } >> >> >>> } >> >> >>> >> >> >>> Obviously ignore concurrency issues, etc. It does look to be safer >> >> >>> to >> >> >>> do >> >> >>> an >> >> >>> abstract class, rather than a factory-interface. >> >> >>> >> >> >>> John >> >> >>> >> >> >>> >> >> >>> On Wed Dec 17 2014 at 10:40:44 AM Antoine Sabot-Durand >> >> >>> wrote: >> >> >>>> >> >> >>>> Hi all, >> >> >>>> >> >> >>>> >> >> >>>> I have business matter and will have to shorten the meeting >> >> >>>> tonight >> >> >>>> (half >> >> >>>> an hour instead of 1h). >> >> >>>> >> >> >>>> I updated the SE doc and Antonio added useful annexes : >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing >> >> >>>> >> >> >>>> I propose we focus on this in these 30 mn >> >> >>>> >> >> >>>> regards, >> >> >>>> >> >> >>>> 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. >> >> > >> >> > >> >> _______________________________________________ >> >> cdi-dev mailing list >> >> cdi-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> >> >> Note that for all code provided on this list, the provider licenses the >> >> code under the Apache License, Version 2 >> >> (http://www.apache.org/licenses/LICENSE-2.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 From jose.paumard at gmail.com Thu Dec 18 05:57:12 2014 From: jose.paumard at gmail.com (=?UTF-8?Q?Jos=C3=A9_Paumard?=) Date: Thu, 18 Dec 2014 11:57:12 +0100 Subject: [cdi-dev] Today's meeting will be shorter and about SE In-Reply-To: References: <54928447.8090605@redhat.com> <5492890B.1070307@redhat.com> Message-ID: Yes, there are good use cases for letting the user provide his own ES to have async calls executed in them. They are the same kind of use cases we have for CompletionStage. Jos? 2014-12-18 10:18 GMT+01:00 Romain Manni-Bucau : > > 2014-12-18 9:58 GMT+01:00 Jos? Paumard : > > From what we wrote about async events, ES can be submitted through the > > fireAsync call, following the patterns of CompletionStage. We can also > > submit a default ES while building a CDI container (a you wrote), and if > we > > dont the default ES will probably be the default ForkJoinPool. > > > > So we may have more than one ES, making things more complicated than the > > pattern you wrote. I think that having the user to close all the ESes > will > > lead to the same pattern again and again : > > for (ES es : cdi.getESes()) { > > myShutdown(es) ; > > } > > > > Sorry I missed something here: how can we get multiple ES? Basically > if CDI needs a ES behing the scene I expect it expose few config like > potential concurrent calls number etc...In such a case I'm not sure if > having multiple ES would be a good idea. > > > I'd prefer to have a cdi.shutdown(), cdi.shudownNow() or > > cdi.awaitTermination(...) or whatever we call those methods, to > encapsulate > > this code. Seems cleaner to me. It might look like CDI is becoming an ES > > itself, but it's delegation, not inheritance. > > > > > > > > 2014-12-18 9:28 GMT+01:00 Romain Manni-Bucau : > >> > >> Why exposing them? When not simply exposing the executor service (in > >> "init" method). > >> > >> CDIContainer cdi = CDIContainer.init(singletonMap(ExecutorService.class, > >> myEs)); > >> // do something awesome > >> shutdownAsIwant(myEs); > >> cdi.close(); > >> > >> Would avoid to have a lot of method several users will not care about. > >> > >> By default it would do a if (timeout <= 0 || > >> !defaultEs.awaitTermination(timeout, MILLISECONDS)) { for (Runnable r > >> : defaultEs.shutdownNow()) { try { r.cancel(); } catch(e) { log(e); } > >> } } with timeout a property of the init map with a default in > >> CDIContainer (constant) > >> > >> wdyt? > >> > >> > >> Romain Manni-Bucau > >> @rmannibucau > >> http://www.tomitribe.com > >> http://rmannibucau.wordpress.com > >> https://github.com/rmannibucau > >> > >> > >> 2014-12-18 9:19 GMT+01:00 Jos? Paumard : > >> > I think we need to think more about how to close the Container. > >> > > >> > We need to take into account the fact that there wil be async process > >> > running in ExecutorServices (SE) or ManagedExecutorServices (EE). So > the > >> > shutting down the container will mean shutting down these ES too. > >> > > >> > So I think we should need to carefully look at the way ES are closed. > >> > The > >> > question being : what do we do with async tasks that are still > running : > >> > should we abruptely interrupt them ? give them a chance to complete ? > >> > All > >> > these are exposed in different methods of ES : shutdown(), > shutdownNow() > >> > and > >> > awaitTermination(timeout). Since the container will have to call one > of > >> > these methods per ES it will manage, I think we should also expose > them. > >> > > >> > Jos? > >> > > >> > > >> > 2014-12-18 9:14 GMT+01:00 Romain Manni-Bucau : > >> >> > >> >> ServiceLoader.load() = ServiceLoader.load(, tccl) > >> >> > >> >> I was thinking to a plain servlet engine (tomcat to not say any name) > >> >> and CDI container API to boot in webapps. Having cdi API in tomcat > >> >> itself and CDI impl in webapps (Weld in webapp1, OWB in webapp2 for > >> >> instance). This would mean using one webapp classloader to find the > >> >> booter/container. This is fine excepted if the instance is cached. > >> >> > >> >> Same thought in more complicated about OSGi but I guess it is not yet > >> >> the target. > >> >> > >> >> > >> >> Romain Manni-Bucau > >> >> @rmannibucau > >> >> http://www.tomitribe.com > >> >> http://rmannibucau.wordpress.com > >> >> https://github.com/rmannibucau > >> >> > >> >> > >> >> 2014-12-18 8:58 GMT+01:00 Jozef Hartinger : > >> >> > > >> >> > On 12/18/2014 08:48 AM, Romain Manni-Bucau wrote: > >> >> >> > >> >> >> Hi guys, > >> >> >> > >> >> >> - why shutdown and not AutoClosable? > >> >> > > >> >> > I like this idea. > >> >> >> > >> >> >> - about instance: it uses TCCL to load the impls, not sure it is > >> >> >> intended but depending the deployment it can be an issue (is this > >> >> >> api > >> >> >> 100% JavaSE + flat classpath - ie more constrained than JavaSE?) + > >> >> >> most of javax SPI creates a new instance each time "creator" is > >> >> >> called. > >> >> > > >> >> > I don't follow. Who uses TCCL? > >> >> >> > >> >> >> - Why Booter and not Container (better than factory IMO)? 1) for > >> >> >> consistency with other spec, 2) why can I shutdown a booter ;)? > >> >> > > >> >> > Exactly > >> >> > > >> >> >> > >> >> >> > >> >> >> > >> >> >> Romain Manni-Bucau > >> >> >> @rmannibucau > >> >> >> http://www.tomitribe.com > >> >> >> http://rmannibucau.wordpress.com > >> >> >> https://github.com/rmannibucau > >> >> >> > >> >> >> > >> >> >> 2014-12-18 8:37 GMT+01:00 Jozef Hartinger : > >> >> >>> > >> >> >>> On 12/18/2014 04:33 AM, John D. Ament wrote: > >> >> >>> > >> >> >>> I thought today's meeting was pretty good. Based on one of the > >> >> >>> discussion > >> >> >>> points, I wanted to try putting together an interface that > >> >> >>> described > >> >> >>> the > >> >> >>> boot paradigm. Unfortunately even in Java 8 it doesn't work too > >> >> >>> well, > >> >> >>> I > >> >> >>> cannot assign a static variable in an interface the way I can in > an > >> >> >>> abstract > >> >> >>> class. More importantly, it doesn't give us the private level > >> >> >>> expectation I > >> >> >>> would look for in this case. I best I could come up with using > an > >> >> >>> interface > >> >> >>> is: > >> >> >>> > >> >> >>> public interface CDIBooter { > >> >> >>> default BeanManager initialize() { > >> >> >>> return initialize(new HashMap<>()); > >> >> >>> } > >> >> >>> > >> >> >>> BeanManager initialize(Map properties); > >> >> >>> > >> >> >>> Why BeanManager? I think it would be better to return CDI or its > >> >> >>> subclass > >> >> >>> rather than this low-level SPI. With the CDI class we get more > >> >> >>> user-friendly > >> >> >>> Instance for free. We could also expose Event similarly. > >> >> >>> > >> >> >>> > >> >> >>> void shutdown(); > >> >> >>> > >> >> >>> class BootHolder { > >> >> >>> > >> >> >>> static CDIBooter instance = null; > >> >> >>> > >> >> >>> } > >> >> >>> > >> >> >>> static CDIBooter instance() { > >> >> >>> if(BootHolder.instance == null) { > >> >> >>> ServiceLoader serviceLoader = > >> >> >>> ServiceLoader.load(CDIBooter.class); > >> >> >>> for(CDIBooter booter : serviceLoader) { > >> >> >>> BootHolder.instance = booter; > >> >> >>> break; > >> >> >>> } > >> >> >>> } > >> >> >>> return BootHolder.instance; > >> >> >>> } > >> >> >>> } > >> >> >>> > >> >> >>> where as the abstract class is a bit briefer, while also being > >> >> >>> private. > >> >> >>> > >> >> >>> public abstract class CDIBooter { > >> >> >>> public BeanManager initialize() { > >> >> >>> return initialize(new HashMap<>()); > >> >> >>> } > >> >> >>> > >> >> >>> public abstract BeanManager initialize(Map properties); > >> >> >>> > >> >> >>> public abstract void shutdown(); > >> >> >>> > >> >> >>> private static CDIBooter instance = null; > >> >> >>> > >> >> >>> public static CDIBooter instance() { > >> >> >>> if(instance == null) { > >> >> >>> ServiceLoader serviceLoader = > >> >> >>> ServiceLoader.load(CDIBooter.class); > >> >> >>> for(CDIBooter booter : serviceLoader) { > >> >> >>> instance = booter; > >> >> >>> break; > >> >> >>> } > >> >> >>> } > >> >> >>> return instance; > >> >> >>> } > >> >> >>> } > >> >> >>> > >> >> >>> Obviously ignore concurrency issues, etc. It does look to be > safer > >> >> >>> to > >> >> >>> do > >> >> >>> an > >> >> >>> abstract class, rather than a factory-interface. > >> >> >>> > >> >> >>> John > >> >> >>> > >> >> >>> > >> >> >>> On Wed Dec 17 2014 at 10:40:44 AM Antoine Sabot-Durand > >> >> >>> wrote: > >> >> >>>> > >> >> >>>> Hi all, > >> >> >>>> > >> >> >>>> > >> >> >>>> I have business matter and will have to shorten the meeting > >> >> >>>> tonight > >> >> >>>> (half > >> >> >>>> an hour instead of 1h). > >> >> >>>> > >> >> >>>> I updated the SE doc and Antonio added useful annexes : > >> >> >>>> > >> >> >>>> > >> >> >>>> > >> >> >>>> > https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing > >> >> >>>> > >> >> >>>> I propose we focus on this in these 30 mn > >> >> >>>> > >> >> >>>> regards, > >> >> >>>> > >> >> >>>> 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. > >> >> > > >> >> > > >> >> _______________________________________________ > >> >> cdi-dev mailing list > >> >> cdi-dev at lists.jboss.org > >> >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> >> > >> >> Note that for all code provided on this list, the provider licenses > the > >> >> code under the Apache License, Version 2 > >> >> (http://www.apache.org/licenses/LICENSE-2.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 > -- 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/20141218/45538b9a/attachment-0001.html From john.d.ament at gmail.com Thu Dec 18 07:26:02 2014 From: john.d.ament at gmail.com (John D. Ament) Date: Thu, 18 Dec 2014 07:26:02 -0500 Subject: [cdi-dev] Today's meeting will be shorter and about SE In-Reply-To: References: <54928447.8090605@redhat.com> <5492890B.1070307@redhat.com> Message-ID: I would recommend that at least some of these comments make their way into the google doc. Things like BeanManager come from there. I simply dropped a huge code snippet in here since there was no easy way to include it in the doc. On Thu, Dec 18, 2014 at 5:57 AM, Jos? Paumard wrote: > > Yes, there are good use cases for letting the user provide his own ES to > have async calls executed in them. They are the same kind of use cases we > have for CompletionStage. > > Jos? > > 2014-12-18 10:18 GMT+01:00 Romain Manni-Bucau : >> >> 2014-12-18 9:58 GMT+01:00 Jos? Paumard : >> > From what we wrote about async events, ES can be submitted through the >> > fireAsync call, following the patterns of CompletionStage. We can also >> > submit a default ES while building a CDI container (a you wrote), and >> if we >> > dont the default ES will probably be the default ForkJoinPool. >> > >> > So we may have more than one ES, making things more complicated than the >> > pattern you wrote. I think that having the user to close all the ESes >> will >> > lead to the same pattern again and again : >> > for (ES es : cdi.getESes()) { >> > myShutdown(es) ; >> > } >> > >> >> Sorry I missed something here: how can we get multiple ES? Basically >> if CDI needs a ES behing the scene I expect it expose few config like >> potential concurrent calls number etc...In such a case I'm not sure if >> having multiple ES would be a good idea. >> >> > I'd prefer to have a cdi.shutdown(), cdi.shudownNow() or >> > cdi.awaitTermination(...) or whatever we call those methods, to >> encapsulate >> > this code. Seems cleaner to me. It might look like CDI is becoming an ES >> > itself, but it's delegation, not inheritance. >> > >> > >> > >> > 2014-12-18 9:28 GMT+01:00 Romain Manni-Bucau : >> >> >> >> Why exposing them? When not simply exposing the executor service (in >> >> "init" method). >> >> >> >> CDIContainer cdi = >> CDIContainer.init(singletonMap(ExecutorService.class, >> >> myEs)); >> >> // do something awesome >> >> shutdownAsIwant(myEs); >> >> cdi.close(); >> >> >> >> Would avoid to have a lot of method several users will not care about. >> >> >> >> By default it would do a if (timeout <= 0 || >> >> !defaultEs.awaitTermination(timeout, MILLISECONDS)) { for (Runnable r >> >> : defaultEs.shutdownNow()) { try { r.cancel(); } catch(e) { log(e); } >> >> } } with timeout a property of the init map with a default in >> >> CDIContainer (constant) >> >> >> >> wdyt? >> >> >> >> >> >> Romain Manni-Bucau >> >> @rmannibucau >> >> http://www.tomitribe.com >> >> http://rmannibucau.wordpress.com >> >> https://github.com/rmannibucau >> >> >> >> >> >> 2014-12-18 9:19 GMT+01:00 Jos? Paumard : >> >> > I think we need to think more about how to close the Container. >> >> > >> >> > We need to take into account the fact that there wil be async process >> >> > running in ExecutorServices (SE) or ManagedExecutorServices (EE). So >> the >> >> > shutting down the container will mean shutting down these ES too. >> >> > >> >> > So I think we should need to carefully look at the way ES are closed. >> >> > The >> >> > question being : what do we do with async tasks that are still >> running : >> >> > should we abruptely interrupt them ? give them a chance to complete ? >> >> > All >> >> > these are exposed in different methods of ES : shutdown(), >> shutdownNow() >> >> > and >> >> > awaitTermination(timeout). Since the container will have to call one >> of >> >> > these methods per ES it will manage, I think we should also expose >> them. >> >> > >> >> > Jos? >> >> > >> >> > >> >> > 2014-12-18 9:14 GMT+01:00 Romain Manni-Bucau > >: >> >> >> >> >> >> ServiceLoader.load() = ServiceLoader.load(, tccl) >> >> >> >> >> >> I was thinking to a plain servlet engine (tomcat to not say any >> name) >> >> >> and CDI container API to boot in webapps. Having cdi API in tomcat >> >> >> itself and CDI impl in webapps (Weld in webapp1, OWB in webapp2 for >> >> >> instance). This would mean using one webapp classloader to find the >> >> >> booter/container. This is fine excepted if the instance is cached. >> >> >> >> >> >> Same thought in more complicated about OSGi but I guess it is not >> yet >> >> >> the target. >> >> >> >> >> >> >> >> >> Romain Manni-Bucau >> >> >> @rmannibucau >> >> >> http://www.tomitribe.com >> >> >> http://rmannibucau.wordpress.com >> >> >> https://github.com/rmannibucau >> >> >> >> >> >> >> >> >> 2014-12-18 8:58 GMT+01:00 Jozef Hartinger : >> >> >> > >> >> >> > On 12/18/2014 08:48 AM, Romain Manni-Bucau wrote: >> >> >> >> >> >> >> >> Hi guys, >> >> >> >> >> >> >> >> - why shutdown and not AutoClosable? >> >> >> > >> >> >> > I like this idea. >> >> >> >> >> >> >> >> - about instance: it uses TCCL to load the impls, not sure it is >> >> >> >> intended but depending the deployment it can be an issue (is this >> >> >> >> api >> >> >> >> 100% JavaSE + flat classpath - ie more constrained than JavaSE?) >> + >> >> >> >> most of javax SPI creates a new instance each time "creator" is >> >> >> >> called. >> >> >> > >> >> >> > I don't follow. Who uses TCCL? >> >> >> >> >> >> >> >> - Why Booter and not Container (better than factory IMO)? 1) for >> >> >> >> consistency with other spec, 2) why can I shutdown a booter ;)? >> >> >> > >> >> >> > Exactly >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Romain Manni-Bucau >> >> >> >> @rmannibucau >> >> >> >> http://www.tomitribe.com >> >> >> >> http://rmannibucau.wordpress.com >> >> >> >> https://github.com/rmannibucau >> >> >> >> >> >> >> >> >> >> >> >> 2014-12-18 8:37 GMT+01:00 Jozef Hartinger : >> >> >> >>> >> >> >> >>> On 12/18/2014 04:33 AM, John D. Ament wrote: >> >> >> >>> >> >> >> >>> I thought today's meeting was pretty good. Based on one of the >> >> >> >>> discussion >> >> >> >>> points, I wanted to try putting together an interface that >> >> >> >>> described >> >> >> >>> the >> >> >> >>> boot paradigm. Unfortunately even in Java 8 it doesn't work too >> >> >> >>> well, >> >> >> >>> I >> >> >> >>> cannot assign a static variable in an interface the way I can >> in an >> >> >> >>> abstract >> >> >> >>> class. More importantly, it doesn't give us the private level >> >> >> >>> expectation I >> >> >> >>> would look for in this case. I best I could come up with using >> an >> >> >> >>> interface >> >> >> >>> is: >> >> >> >>> >> >> >> >>> public interface CDIBooter { >> >> >> >>> default BeanManager initialize() { >> >> >> >>> return initialize(new HashMap<>()); >> >> >> >>> } >> >> >> >>> >> >> >> >>> BeanManager initialize(Map properties); >> >> >> >>> >> >> >> >>> Why BeanManager? I think it would be better to return CDI or its >> >> >> >>> subclass >> >> >> >>> rather than this low-level SPI. With the CDI class we get more >> >> >> >>> user-friendly >> >> >> >>> Instance for free. We could also expose Event similarly. >> >> >> >>> >> >> >> >>> >> >> >> >>> void shutdown(); >> >> >> >>> >> >> >> >>> class BootHolder { >> >> >> >>> >> >> >> >>> static CDIBooter instance = null; >> >> >> >>> >> >> >> >>> } >> >> >> >>> >> >> >> >>> static CDIBooter instance() { >> >> >> >>> if(BootHolder.instance == null) { >> >> >> >>> ServiceLoader serviceLoader = >> >> >> >>> ServiceLoader.load(CDIBooter.class); >> >> >> >>> for(CDIBooter booter : serviceLoader) { >> >> >> >>> BootHolder.instance = booter; >> >> >> >>> break; >> >> >> >>> } >> >> >> >>> } >> >> >> >>> return BootHolder.instance; >> >> >> >>> } >> >> >> >>> } >> >> >> >>> >> >> >> >>> where as the abstract class is a bit briefer, while also being >> >> >> >>> private. >> >> >> >>> >> >> >> >>> public abstract class CDIBooter { >> >> >> >>> public BeanManager initialize() { >> >> >> >>> return initialize(new HashMap<>()); >> >> >> >>> } >> >> >> >>> >> >> >> >>> public abstract BeanManager initialize(Map >> properties); >> >> >> >>> >> >> >> >>> public abstract void shutdown(); >> >> >> >>> >> >> >> >>> private static CDIBooter instance = null; >> >> >> >>> >> >> >> >>> public static CDIBooter instance() { >> >> >> >>> if(instance == null) { >> >> >> >>> ServiceLoader serviceLoader = >> >> >> >>> ServiceLoader.load(CDIBooter.class); >> >> >> >>> for(CDIBooter booter : serviceLoader) { >> >> >> >>> instance = booter; >> >> >> >>> break; >> >> >> >>> } >> >> >> >>> } >> >> >> >>> return instance; >> >> >> >>> } >> >> >> >>> } >> >> >> >>> >> >> >> >>> Obviously ignore concurrency issues, etc. It does look to be >> safer >> >> >> >>> to >> >> >> >>> do >> >> >> >>> an >> >> >> >>> abstract class, rather than a factory-interface. >> >> >> >>> >> >> >> >>> John >> >> >> >>> >> >> >> >>> >> >> >> >>> On Wed Dec 17 2014 at 10:40:44 AM Antoine Sabot-Durand >> >> >> >>> wrote: >> >> >> >>>> >> >> >> >>>> Hi all, >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> I have business matter and will have to shorten the meeting >> >> >> >>>> tonight >> >> >> >>>> (half >> >> >> >>>> an hour instead of 1h). >> >> >> >>>> >> >> >> >>>> I updated the SE doc and Antonio added useful annexes : >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing >> >> >> >>>> >> >> >> >>>> I propose we focus on this in these 30 mn >> >> >> >>>> >> >> >> >>>> regards, >> >> >> >>>> >> >> >> >>>> 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. >> >> >> > >> >> >> > >> >> >> _______________________________________________ >> >> >> cdi-dev mailing list >> >> >> cdi-dev at lists.jboss.org >> >> >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> >> >> >> >> Note that for all code provided on this list, the provider licenses >> the >> >> >> code under the Apache License, Version 2 >> >> >> (http://www.apache.org/licenses/LICENSE-2.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 >> > > > -- > 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/20141218/dd583504/attachment-0001.html From john.d.ament at gmail.com Thu Dec 18 07:29:51 2014 From: john.d.ament at gmail.com (John D. Ament) Date: Thu, 18 Dec 2014 07:29:51 -0500 Subject: [cdi-dev] Is the concept of mutable event payload specified In-Reply-To: <54928A35.5090807@redhat.com> References: <213B41E0-D73F-4CED-95B0-AFB50451B791@sabot-durand.net> <1418809749672.21827@stefanutti.fr> <1EFACDFC-267C-4F36-8B0D-22B44FF43B6A@sabot-durand.net> <54928A35.5090807@redhat.com> Message-ID: I don't think this is something we can state outright. If I BeanManager.fireEvent("some string"); then it's not mutable. On Thu, Dec 18, 2014 at 3:03 AM, Jozef Hartinger wrote: > > > On 12/17/2014 05:49 PM, Antoine Sabot-Durand wrote: > > Ok guys, > > Let?s do it again. I didn?t say we have to forbid the mutability I said > we have at least to explicitly write that it?s mutable > > Agreed. > > and seriously think of having it immutable for event fired asynchronously. > > I agree that we should have a discussion about pros/cons. From what I saw > working on a fireAsync prototype to me the possible benefits of allowing > immutable events only are not worth the limitations. > > > (Pete) I don?t think it?s specified. As objects are, by default in Java, > mutable, I would assume that payloads are implicitly mutable. > > > Sorry @Pete I don?t agree with your point. Yes, in Java object are > mutable but firing an event is not a standard Java feature : you send your > object to a black box and let this box dispatch your object to listeners > transforming one call to multiple call : it?s far from standard Java rules. > Even if it?s not written it?s an observer pattern and there are people out > there thinking that introducing mutability in observer is an anti-pattern > since some listener will receive a different payload than the one that was > sent to them. > It?s like making a method call and having no guarantee that the parameter > received in the callee has the same value that in the caller... > I won?t start discussion on bad practice or anti pattern as I also use > mutability in event but there as much reason for user to assume their > payload will be mutable than the other way around. > I can assure you that when I give a talk on CDI, this payload mutability > is often a surprise for attendees... > > (Romain) why isn't it portable? > > > So yes @Romain it?s not portable (in theory of course, since both > implementations support mutability). Someone could write a CDI > implementation with event payload immutability without any issue with the > spec and TCK. > > Most of you are so dependent of this feature that you only reacted to > the idea or forbidding it (which wasn?t the content of my mail) ;). So we > all agree that it?s an important feature. Therefore what?s the issue to > specify this mutability and add TCK test for it ? > > Now I don?t deal with that subject for nothing, we are planning to > introduce Async events. I think that it?ll bring extra complexity if we > support mutability in async events. And even if I?m wrong and we finally go > for mutability in async events, this will lead to possible side effect > (lock) that could have impact on perf, so it should be explicitly written > IMO. > > Antoine > > > > > > > > > > _______________________________________________ > 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/20141218/8c3e8a83/attachment.html From werner.keil at gmail.com Thu Dec 18 07:46:36 2014 From: werner.keil at gmail.com (Werner Keil) Date: Thu, 18 Dec 2014 13:46:36 +0100 Subject: [cdi-dev] Today's meeting will be shorter and about SE Message-ID: I suppose the part "Specifications that define an SPI" only covers those under the EE umbrella, though the document is about SE? Werner On Thu, Dec 18, 2014 at 1:26 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: Today's meeting will be shorter and about SE (John D. Ament) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 18 Dec 2014 07:26:02 -0500 > From: "John D. Ament" > Subject: Re: [cdi-dev] Today's meeting will be shorter and about SE > To: Jos? Paumard > Cc: cdi-dev > Message-ID: > 10RA at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > I would recommend that at least some of these comments make their way into > the google doc. Things like BeanManager come from there. > > I simply dropped a huge code snippet in here since there was no easy way to > include it in the doc. > > On Thu, Dec 18, 2014 at 5:57 AM, Jos? Paumard > wrote: > > > > Yes, there are good use cases for letting the user provide his own ES to > > have async calls executed in them. They are the same kind of use cases we > > have for CompletionStage. > > > > Jos? > > > > 2014-12-18 10:18 GMT+01:00 Romain Manni-Bucau : > >> > >> 2014-12-18 9:58 GMT+01:00 Jos? Paumard : > >> > From what we wrote about async events, ES can be submitted through the > >> > fireAsync call, following the patterns of CompletionStage. We can also > >> > submit a default ES while building a CDI container (a you wrote), and > >> if we > >> > dont the default ES will probably be the default ForkJoinPool. > >> > > >> > So we may have more than one ES, making things more complicated than > the > >> > pattern you wrote. I think that having the user to close all the ESes > >> will > >> > lead to the same pattern again and again : > >> > for (ES es : cdi.getESes()) { > >> > myShutdown(es) ; > >> > } > >> > > >> > >> Sorry I missed something here: how can we get multiple ES? Basically > >> if CDI needs a ES behing the scene I expect it expose few config like > >> potential concurrent calls number etc...In such a case I'm not sure if > >> having multiple ES would be a good idea. > >> > >> > I'd prefer to have a cdi.shutdown(), cdi.shudownNow() or > >> > cdi.awaitTermination(...) or whatever we call those methods, to > >> encapsulate > >> > this code. Seems cleaner to me. It might look like CDI is becoming an > ES > >> > itself, but it's delegation, not inheritance. > >> > > >> > > >> > > >> > 2014-12-18 9:28 GMT+01:00 Romain Manni-Bucau : > >> >> > >> >> Why exposing them? When not simply exposing the executor service (in > >> >> "init" method). > >> >> > >> >> CDIContainer cdi = > >> CDIContainer.init(singletonMap(ExecutorService.class, > >> >> myEs)); > >> >> // do something awesome > >> >> shutdownAsIwant(myEs); > >> >> cdi.close(); > >> >> > >> >> Would avoid to have a lot of method several users will not care > about. > >> >> > >> >> By default it would do a if (timeout <= 0 || > >> >> !defaultEs.awaitTermination(timeout, MILLISECONDS)) { for (Runnable r > >> >> : defaultEs.shutdownNow()) { try { r.cancel(); } catch(e) { log(e); } > >> >> } } with timeout a property of the init map with a default in > >> >> CDIContainer (constant) > >> >> > >> >> wdyt? > >> >> > >> >> > >> >> Romain Manni-Bucau > >> >> @rmannibucau > >> >> http://www.tomitribe.com > >> >> http://rmannibucau.wordpress.com > >> >> https://github.com/rmannibucau > >> >> > >> >> > >> >> 2014-12-18 9:19 GMT+01:00 Jos? Paumard : > >> >> > I think we need to think more about how to close the Container. > >> >> > > >> >> > We need to take into account the fact that there wil be async > process > >> >> > running in ExecutorServices (SE) or ManagedExecutorServices (EE). > So > >> the > >> >> > shutting down the container will mean shutting down these ES too. > >> >> > > >> >> > So I think we should need to carefully look at the way ES are > closed. > >> >> > The > >> >> > question being : what do we do with async tasks that are still > >> running : > >> >> > should we abruptely interrupt them ? give them a chance to > complete ? > >> >> > All > >> >> > these are exposed in different methods of ES : shutdown(), > >> shutdownNow() > >> >> > and > >> >> > awaitTermination(timeout). Since the container will have to call > one > >> of > >> >> > these methods per ES it will manage, I think we should also expose > >> them. > >> >> > > >> >> > Jos? > >> >> > > >> >> > > >> >> > 2014-12-18 9:14 GMT+01:00 Romain Manni-Bucau < > rmannibucau at gmail.com > >> >: > >> >> >> > >> >> >> ServiceLoader.load() = ServiceLoader.load(, tccl) > >> >> >> > >> >> >> I was thinking to a plain servlet engine (tomcat to not say any > >> name) > >> >> >> and CDI container API to boot in webapps. Having cdi API in tomcat > >> >> >> itself and CDI impl in webapps (Weld in webapp1, OWB in webapp2 > for > >> >> >> instance). This would mean using one webapp classloader to find > the > >> >> >> booter/container. This is fine excepted if the instance is cached. > >> >> >> > >> >> >> Same thought in more complicated about OSGi but I guess it is not > >> yet > >> >> >> the target. > >> >> >> > >> >> >> > >> >> >> Romain Manni-Bucau > >> >> >> @rmannibucau > >> >> >> http://www.tomitribe.com > >> >> >> http://rmannibucau.wordpress.com > >> >> >> https://github.com/rmannibucau > >> >> >> > >> >> >> > >> >> >> 2014-12-18 8:58 GMT+01:00 Jozef Hartinger : > >> >> >> > > >> >> >> > On 12/18/2014 08:48 AM, Romain Manni-Bucau wrote: > >> >> >> >> > >> >> >> >> Hi guys, > >> >> >> >> > >> >> >> >> - why shutdown and not AutoClosable? > >> >> >> > > >> >> >> > I like this idea. > >> >> >> >> > >> >> >> >> - about instance: it uses TCCL to load the impls, not sure it > is > >> >> >> >> intended but depending the deployment it can be an issue (is > this > >> >> >> >> api > >> >> >> >> 100% JavaSE + flat classpath - ie more constrained than > JavaSE?) > >> + > >> >> >> >> most of javax SPI creates a new instance each time "creator" is > >> >> >> >> called. > >> >> >> > > >> >> >> > I don't follow. Who uses TCCL? > >> >> >> >> > >> >> >> >> - Why Booter and not Container (better than factory IMO)? 1) > for > >> >> >> >> consistency with other spec, 2) why can I shutdown a booter ;)? > >> >> >> > > >> >> >> > Exactly > >> >> >> > > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> Romain Manni-Bucau > >> >> >> >> @rmannibucau > >> >> >> >> http://www.tomitribe.com > >> >> >> >> http://rmannibucau.wordpress.com > >> >> >> >> https://github.com/rmannibucau > >> >> >> >> > >> >> >> >> > >> >> >> >> 2014-12-18 8:37 GMT+01:00 Jozef Hartinger >: > >> >> >> >>> > >> >> >> >>> On 12/18/2014 04:33 AM, John D. Ament wrote: > >> >> >> >>> > >> >> >> >>> I thought today's meeting was pretty good. Based on one of > the > >> >> >> >>> discussion > >> >> >> >>> points, I wanted to try putting together an interface that > >> >> >> >>> described > >> >> >> >>> the > >> >> >> >>> boot paradigm. Unfortunately even in Java 8 it doesn't work > too > >> >> >> >>> well, > >> >> >> >>> I > >> >> >> >>> cannot assign a static variable in an interface the way I can > >> in an > >> >> >> >>> abstract > >> >> >> >>> class. More importantly, it doesn't give us the private level > >> >> >> >>> expectation I > >> >> >> >>> would look for in this case. I best I could come up with > using > >> an > >> >> >> >>> interface > >> >> >> >>> is: > >> >> >> >>> > >> >> >> >>> public interface CDIBooter { > >> >> >> >>> default BeanManager initialize() { > >> >> >> >>> return initialize(new HashMap<>()); > >> >> >> >>> } > >> >> >> >>> > >> >> >> >>> BeanManager initialize(Map properties); > >> >> >> >>> > >> >> >> >>> Why BeanManager? I think it would be better to return CDI or > its > >> >> >> >>> subclass > >> >> >> >>> rather than this low-level SPI. With the CDI class we get more > >> >> >> >>> user-friendly > >> >> >> >>> Instance for free. We could also expose Event similarly. > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> void shutdown(); > >> >> >> >>> > >> >> >> >>> class BootHolder { > >> >> >> >>> > >> >> >> >>> static CDIBooter instance = null; > >> >> >> >>> > >> >> >> >>> } > >> >> >> >>> > >> >> >> >>> static CDIBooter instance() { > >> >> >> >>> if(BootHolder.instance == null) { > >> >> >> >>> ServiceLoader serviceLoader = > >> >> >> >>> ServiceLoader.load(CDIBooter.class); > >> >> >> >>> for(CDIBooter booter : serviceLoader) { > >> >> >> >>> BootHolder.instance = booter; > >> >> >> >>> break; > >> >> >> >>> } > >> >> >> >>> } > >> >> >> >>> return BootHolder.instance; > >> >> >> >>> } > >> >> >> >>> } > >> >> >> >>> > >> >> >> >>> where as the abstract class is a bit briefer, while also being > >> >> >> >>> private. > >> >> >> >>> > >> >> >> >>> public abstract class CDIBooter { > >> >> >> >>> public BeanManager initialize() { > >> >> >> >>> return initialize(new HashMap<>()); > >> >> >> >>> } > >> >> >> >>> > >> >> >> >>> public abstract BeanManager initialize(Map > >> properties); > >> >> >> >>> > >> >> >> >>> public abstract void shutdown(); > >> >> >> >>> > >> >> >> >>> private static CDIBooter instance = null; > >> >> >> >>> > >> >> >> >>> public static CDIBooter instance() { > >> >> >> >>> if(instance == null) { > >> >> >> >>> ServiceLoader serviceLoader = > >> >> >> >>> ServiceLoader.load(CDIBooter.class); > >> >> >> >>> for(CDIBooter booter : serviceLoader) { > >> >> >> >>> instance = booter; > >> >> >> >>> break; > >> >> >> >>> } > >> >> >> >>> } > >> >> >> >>> return instance; > >> >> >> >>> } > >> >> >> >>> } > >> >> >> >>> > >> >> >> >>> Obviously ignore concurrency issues, etc. It does look to be > >> safer > >> >> >> >>> to > >> >> >> >>> do > >> >> >> >>> an > >> >> >> >>> abstract class, rather than a factory-interface. > >> >> >> >>> > >> >> >> >>> John > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> On Wed Dec 17 2014 at 10:40:44 AM Antoine Sabot-Durand > >> >> >> >>> wrote: > >> >> >> >>>> > >> >> >> >>>> Hi all, > >> >> >> >>>> > >> >> >> >>>> > >> >> >> >>>> I have business matter and will have to shorten the meeting > >> >> >> >>>> tonight > >> >> >> >>>> (half > >> >> >> >>>> an hour instead of 1h). > >> >> >> >>>> > >> >> >> >>>> I updated the SE doc and Antonio added useful annexes : > >> >> >> >>>> > >> >> >> >>>> > >> >> >> >>>> > >> >> >> >>>> > >> > https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing > >> >> >> >>>> > >> >> >> >>>> I propose we focus on this in these 30 mn > >> >> >> >>>> > >> >> >> >>>> regards, > >> >> >> >>>> > >> >> >> >>>> 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. > >> >> >> > > >> >> >> > > >> >> >> _______________________________________________ > >> >> >> cdi-dev mailing list > >> >> >> cdi-dev at lists.jboss.org > >> >> >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> >> >> > >> >> >> Note that for all code provided on this list, the provider > licenses > >> the > >> >> >> code under the Apache License, Version 2 > >> >> >> (http://www.apache.org/licenses/LICENSE-2.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 > >> > > > > > > -- > > 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/20141218/dd583504/attachment.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 49, Issue 23 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141218/818f3d0a/attachment-0001.html From pmuir at redhat.com Thu Dec 18 08:10:24 2014 From: pmuir at redhat.com (Pete Muir) Date: Thu, 18 Dec 2014 13:10:24 +0000 Subject: [cdi-dev] Today's meeting will be shorter and about SE In-Reply-To: <5492890B.1070307@redhat.com> References: <54928447.8090605@redhat.com> <5492890B.1070307@redhat.com> Message-ID: > On 18 Dec 2014, at 07:58, Jozef Hartinger wrote: > > > On 12/18/2014 08:48 AM, Romain Manni-Bucau wrote: >> Hi guys, >> >> - why shutdown and not AutoClosable? > I like this idea. >> - about instance: it uses TCCL to load the impls, not sure it is >> intended but depending the deployment it can be an issue (is this api >> 100% JavaSE + flat classpath - ie more constrained than JavaSE?) + >> most of javax SPI creates a new instance each time "creator" is >> called. > I don't follow. Who uses TCCL? This is exactly the way java.util.ServiceLoader works. Note that it doesn?t use the TCCL to load the impl, it uses the TCCL, or the class loader of the API, or the system loader, to load the ?CDIProvider?. This CDIProvider can use whatever mechanism it needs to load the actual impl. This certainly provides some limitations, but I think writing an OSGi provider that uses some of OSGi?s DI features could work to look up the current CDI container would work here? >> - Why Booter and not Container (better than factory IMO)? 1) for >> consistency with other spec, 2) why can I shutdown a booter ;)? > Exactly >> >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2014-12-18 8:37 GMT+01:00 Jozef Hartinger : >>> On 12/18/2014 04:33 AM, John D. Ament wrote: >>> >>> I thought today's meeting was pretty good. Based on one of the discussion >>> points, I wanted to try putting together an interface that described the >>> boot paradigm. Unfortunately even in Java 8 it doesn't work too well, I >>> cannot assign a static variable in an interface the way I can in an abstract >>> class. More importantly, it doesn't give us the private level expectation I >>> would look for in this case. I best I could come up with using an interface >>> is: >>> >>> public interface CDIBooter { >>> default BeanManager initialize() { >>> return initialize(new HashMap<>()); >>> } >>> >>> BeanManager initialize(Map properties); >>> >>> Why BeanManager? I think it would be better to return CDI or its subclass >>> rather than this low-level SPI. With the CDI class we get more user-friendly >>> Instance for free. We could also expose Event similarly. >>> >>> >>> void shutdown(); >>> >>> class BootHolder { >>> >>> static CDIBooter instance = null; >>> >>> } >>> >>> static CDIBooter instance() { >>> if(BootHolder.instance == null) { >>> ServiceLoader serviceLoader = >>> ServiceLoader.load(CDIBooter.class); >>> for(CDIBooter booter : serviceLoader) { >>> BootHolder.instance = booter; >>> break; >>> } >>> } >>> return BootHolder.instance; >>> } >>> } >>> >>> where as the abstract class is a bit briefer, while also being private. >>> >>> public abstract class CDIBooter { >>> public BeanManager initialize() { >>> return initialize(new HashMap<>()); >>> } >>> >>> public abstract BeanManager initialize(Map properties); >>> >>> public abstract void shutdown(); >>> >>> private static CDIBooter instance = null; >>> >>> public static CDIBooter instance() { >>> if(instance == null) { >>> ServiceLoader serviceLoader = >>> ServiceLoader.load(CDIBooter.class); >>> for(CDIBooter booter : serviceLoader) { >>> instance = booter; >>> break; >>> } >>> } >>> return instance; >>> } >>> } >>> >>> Obviously ignore concurrency issues, etc. It does look to be safer to do an >>> abstract class, rather than a factory-interface. >>> >>> John >>> >>> >>> On Wed Dec 17 2014 at 10:40:44 AM Antoine Sabot-Durand >>> wrote: >>>> Hi all, >>>> >>>> >>>> I have business matter and will have to shorten the meeting tonight (half >>>> an hour instead of 1h). >>>> >>>> I updated the SE doc and Antonio added useful annexes : >>>> https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing >>>> >>>> I propose we focus on this in these 30 mn >>>> >>>> regards, >>>> >>>> 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. > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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/20141218/4b55ca83/attachment.html From pmuir at redhat.com Thu Dec 18 08:59:37 2014 From: pmuir at redhat.com (Pete Muir) Date: Thu, 18 Dec 2014 13:59:37 +0000 Subject: [cdi-dev] Today's meeting will be shorter and about SE In-Reply-To: References: <54928447.8090605@redhat.com> <5492890B.1070307@redhat.com> Message-ID: <5D0AC155-84DC-47E0-B957-5E5C40445E75@redhat.com> Have you reported this? Issues so I can look at the details? > On 18 Dec 2014, at 13:56, Romain Manni-Bucau wrote: > > Would be great to have portable api jar. We had issues for some ee jars and this is a pain to not have the same behavior depending your coordinates > > Le 18 d?c. 2014 14:54, "Pete Muir" > a ?crit : > >> On 18 Dec 2014, at 13:48, Romain Manni-Bucau > wrote: >> >> >> Le 18 d?c. 2014 14:10, "Pete Muir" > a ?crit : >> > >> > >> >> On 18 Dec 2014, at 07:58, Jozef Hartinger > wrote: >> >> >> >> >> >> On 12/18/2014 08:48 AM, Romain Manni-Bucau wrote: >> >>> >> >>> Hi guys, >> >>> >> >>> - why shutdown and not AutoClosable? >> >> >> >> I like this idea. >> >>> >> >>> - about instance: it uses TCCL to load the impls, not sure it is >> >>> intended but depending the deployment it can be an issue (is this api >> >>> 100% JavaSE + flat classpath - ie more constrained than JavaSE?) + >> >>> most of javax SPI creates a new instance each time "creator" is >> >>> called. >> >> >> >> I don't follow. Who uses TCCL? >> > >> > >> > This is exactly the way java.util.ServiceLoader works. >> > >> > Note that it doesn?t use the TCCL to load the impl, it uses the TCCL, or the class loader of the API, or the system loader, to load the ?CDIProvider?. This CDIProvider can use whatever mechanism it needs to load the actual impl. >> > >> > This certainly provides some limitations, but I think writing an OSGi provider that uses some of OSGi?s DI features could work to look up the current CDI container would work here? >> > >> >> If not stored sure. If stored then you can use a provider you dont expect or broker >> > The provider is stored. However there is no requirement on the provider to cache/store what it calls in order to load the implementation of the CDI class. So, it might make sense to introduce an extra level of indirection here for OSGi. This doesn?t need to be in the spec though. >> >>> - Why Booter and not Container (better than factory IMO)? 1) for >> >>> consistency with other spec, 2) why can I shutdown a booter ;)? >> >> >> >> Exactly >> >>> >> >>> >> >>> >> >>> >> >>> Romain Manni-Bucau >> >>> @rmannibucau >> >>> http://www.tomitribe.com >> >>> http://rmannibucau.wordpress.com >> >>> https://github.com/rmannibucau >> >>> >> >>> >> >>> 2014-12-18 8:37 GMT+01:00 Jozef Hartinger >: >> >>>> >> >>>> On 12/18/2014 04:33 AM, John D. Ament wrote: >> >>>> >> >>>> I thought today's meeting was pretty good. Based on one of the discussion >> >>>> points, I wanted to try putting together an interface that described the >> >>>> boot paradigm. Unfortunately even in Java 8 it doesn't work too well, I >> >>>> cannot assign a static variable in an interface the way I can in an abstract >> >>>> class. More importantly, it doesn't give us the private level expectation I >> >>>> would look for in this case. I best I could come up with using an interface >> >>>> is: >> >>>> >> >>>> public interface CDIBooter { >> >>>> default BeanManager initialize() { >> >>>> return initialize(new HashMap<>()); >> >>>> } >> >>>> >> >>>> BeanManager initialize(Map properties); >> >>>> >> >>>> Why BeanManager? I think it would be better to return CDI or its subclass >> >>>> rather than this low-level SPI. With the CDI class we get more user-friendly >> >>>> Instance for free. We could also expose Event similarly. >> >>>> >> >>>> >> >>>> void shutdown(); >> >>>> >> >>>> class BootHolder { >> >>>> >> >>>> static CDIBooter instance = null; >> >>>> >> >>>> } >> >>>> >> >>>> static CDIBooter instance() { >> >>>> if(BootHolder.instance == null) { >> >>>> ServiceLoader serviceLoader = >> >>>> ServiceLoader.load(CDIBooter.class); >> >>>> for(CDIBooter booter : serviceLoader) { >> >>>> BootHolder.instance = booter; >> >>>> break; >> >>>> } >> >>>> } >> >>>> return BootHolder.instance; >> >>>> } >> >>>> } >> >>>> >> >>>> where as the abstract class is a bit briefer, while also being private. >> >>>> >> >>>> public abstract class CDIBooter { >> >>>> public BeanManager initialize() { >> >>>> return initialize(new HashMap<>()); >> >>>> } >> >>>> >> >>>> public abstract BeanManager initialize(Map properties); >> >>>> >> >>>> public abstract void shutdown(); >> >>>> >> >>>> private static CDIBooter instance = null; >> >>>> >> >>>> public static CDIBooter instance() { >> >>>> if(instance == null) { >> >>>> ServiceLoader serviceLoader = >> >>>> ServiceLoader.load(CDIBooter.class); >> >>>> for(CDIBooter booter : serviceLoader) { >> >>>> instance = booter; >> >>>> break; >> >>>> } >> >>>> } >> >>>> return instance; >> >>>> } >> >>>> } >> >>>> >> >>>> Obviously ignore concurrency issues, etc. It does look to be safer to do an >> >>>> abstract class, rather than a factory-interface. >> >>>> >> >>>> John >> >>>> >> >>>> >> >>>> On Wed Dec 17 2014 at 10:40:44 AM Antoine Sabot-Durand >> >>>> > wrote: >> >>>>> >> >>>>> Hi all, >> >>>>> >> >>>>> >> >>>>> I have business matter and will have to shorten the meeting tonight (half >> >>>>> an hour instead of 1h). >> >>>>> >> >>>>> I updated the SE doc and Antonio added useful annexes : >> >>>>> https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing >> >>>>> >> >>>>> I propose we focus on this in these 30 mn >> >>>>> >> >>>>> regards, >> >>>>> >> >>>>> 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. >> >> >> >> >> >> _______________________________________________ >> >> cdi-dev mailing list >> >> cdi-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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/20141218/b18281be/attachment-0001.html From jharting at redhat.com Thu Dec 18 09:12:27 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Thu, 18 Dec 2014 15:12:27 +0100 Subject: [cdi-dev] Today's meeting will be shorter and about SE In-Reply-To: References: <54928447.8090605@redhat.com> <5492890B.1070307@redhat.com> Message-ID: <5492E0CB.5010000@redhat.com> But we should only be shutting down thread pools that we manage. Just like CompletableFuture won't shut down your thread pool if you pass it to *Async method. On 12/18/2014 11:57 AM, Jos? Paumard wrote: > Yes, there are good use cases for letting the user provide his own ES > to have async calls executed in them. They are the same kind of use > cases we have for CompletionStage. > > Jos? > > 2014-12-18 10:18 GMT+01:00 Romain Manni-Bucau >: > > 2014-12-18 9:58 GMT+01:00 Jos? Paumard >: > > From what we wrote about async events, ES can be submitted > through the > > fireAsync call, following the patterns of CompletionStage. We > can also > > submit a default ES while building a CDI container (a you > wrote), and if we > > dont the default ES will probably be the default ForkJoinPool. > > > > So we may have more than one ES, making things more complicated > than the > > pattern you wrote. I think that having the user to close all the > ESes will > > lead to the same pattern again and again : > > for (ES es : cdi.getESes()) { > > myShutdown(es) ; > > } > > > > Sorry I missed something here: how can we get multiple ES? Basically > if CDI needs a ES behing the scene I expect it expose few config like > potential concurrent calls number etc...In such a case I'm not sure if > having multiple ES would be a good idea. > > > I'd prefer to have a cdi.shutdown(), cdi.shudownNow() or > > cdi.awaitTermination(...) or whatever we call those methods, to > encapsulate > > this code. Seems cleaner to me. It might look like CDI is > becoming an ES > > itself, but it's delegation, not inheritance. > > > > > > > > 2014-12-18 9:28 GMT+01:00 Romain Manni-Bucau > >: > >> > >> Why exposing them? When not simply exposing the executor > service (in > >> "init" method). > >> > >> CDIContainer cdi = > CDIContainer.init(singletonMap(ExecutorService.class, > >> myEs)); > >> // do something awesome > >> shutdownAsIwant(myEs); > >> cdi.close(); > >> > >> Would avoid to have a lot of method several users will not care > about. > >> > >> By default it would do a if (timeout <= 0 || > >> !defaultEs.awaitTermination(timeout, MILLISECONDS)) { for > (Runnable r > >> : defaultEs.shutdownNow()) { try { r.cancel(); } catch(e) { > log(e); } > >> } } with timeout a property of the init map with a default in > >> CDIContainer (constant) > >> > >> wdyt? > >> > >> > >> Romain Manni-Bucau > >> @rmannibucau > >> http://www.tomitribe.com > >> http://rmannibucau.wordpress.com > >> https://github.com/rmannibucau > >> > >> > >> 2014-12-18 9:19 GMT+01:00 Jos? Paumard >: > >> > I think we need to think more about how to close the Container. > >> > > >> > We need to take into account the fact that there wil be async > process > >> > running in ExecutorServices (SE) or ManagedExecutorServices > (EE). So the > >> > shutting down the container will mean shutting down these ES too. > >> > > >> > So I think we should need to carefully look at the way ES are > closed. > >> > The > >> > question being : what do we do with async tasks that are > still running : > >> > should we abruptely interrupt them ? give them a chance to > complete ? > >> > All > >> > these are exposed in different methods of ES : shutdown(), > shutdownNow() > >> > and > >> > awaitTermination(timeout). Since the container will have to > call one of > >> > these methods per ES it will manage, I think we should also > expose them. > >> > > >> > Jos? > >> > > >> > > >> > 2014-12-18 9:14 GMT+01:00 Romain Manni-Bucau > >: > >> >> > >> >> ServiceLoader.load() = ServiceLoader.load(, tccl) > >> >> > >> >> I was thinking to a plain servlet engine (tomcat to not say > any name) > >> >> and CDI container API to boot in webapps. Having cdi API in > tomcat > >> >> itself and CDI impl in webapps (Weld in webapp1, OWB in > webapp2 for > >> >> instance). This would mean using one webapp classloader to > find the > >> >> booter/container. This is fine excepted if the instance is > cached. > >> >> > >> >> Same thought in more complicated about OSGi but I guess it > is not yet > >> >> the target. > >> >> > >> >> > >> >> Romain Manni-Bucau > >> >> @rmannibucau > >> >> http://www.tomitribe.com > >> >> http://rmannibucau.wordpress.com > >> >> https://github.com/rmannibucau > >> >> > >> >> > >> >> 2014-12-18 8:58 GMT+01:00 Jozef Hartinger > >: > >> >> > > >> >> > On 12/18/2014 08:48 AM, Romain Manni-Bucau wrote: > >> >> >> > >> >> >> Hi guys, > >> >> >> > >> >> >> - why shutdown and not AutoClosable? > >> >> > > >> >> > I like this idea. > >> >> >> > >> >> >> - about instance: it uses TCCL to load the impls, not > sure it is > >> >> >> intended but depending the deployment it can be an issue > (is this > >> >> >> api > >> >> >> 100% JavaSE + flat classpath - ie more constrained than > JavaSE?) + > >> >> >> most of javax SPI creates a new instance each time > "creator" is > >> >> >> called. > >> >> > > >> >> > I don't follow. Who uses TCCL? > >> >> >> > >> >> >> - Why Booter and not Container (better than factory IMO)? > 1) for > >> >> >> consistency with other spec, 2) why can I shutdown a > booter ;)? > >> >> > > >> >> > Exactly > >> >> > > >> >> >> > >> >> >> > >> >> >> > >> >> >> Romain Manni-Bucau > >> >> >> @rmannibucau > >> >> >> http://www.tomitribe.com > >> >> >> http://rmannibucau.wordpress.com > >> >> >> https://github.com/rmannibucau > >> >> >> > >> >> >> > >> >> >> 2014-12-18 8:37 GMT+01:00 Jozef Hartinger > >: > >> >> >>> > >> >> >>> On 12/18/2014 04:33 AM, John D. Ament wrote: > >> >> >>> > >> >> >>> I thought today's meeting was pretty good. Based on one > of the > >> >> >>> discussion > >> >> >>> points, I wanted to try putting together an interface that > >> >> >>> described > >> >> >>> the > >> >> >>> boot paradigm. Unfortunately even in Java 8 it doesn't > work too > >> >> >>> well, > >> >> >>> I > >> >> >>> cannot assign a static variable in an interface the way > I can in an > >> >> >>> abstract > >> >> >>> class. More importantly, it doesn't give us the private > level > >> >> >>> expectation I > >> >> >>> would look for in this case. I best I could come up > with using an > >> >> >>> interface > >> >> >>> is: > >> >> >>> > >> >> >>> public interface CDIBooter { > >> >> >>> default BeanManager initialize() { > >> >> >>> return initialize(new HashMap<>()); > >> >> >>> } > >> >> >>> > >> >> >>> BeanManager initialize(Map properties); > >> >> >>> > >> >> >>> Why BeanManager? I think it would be better to return > CDI or its > >> >> >>> subclass > >> >> >>> rather than this low-level SPI. With the CDI class we > get more > >> >> >>> user-friendly > >> >> >>> Instance for free. We could also expose Event > similarly. > >> >> >>> > >> >> >>> > >> >> >>> void shutdown(); > >> >> >>> > >> >> >>> class BootHolder { > >> >> >>> > >> >> >>> static CDIBooter instance = null; > >> >> >>> > >> >> >>> } > >> >> >>> > >> >> >>> static CDIBooter instance() { > >> >> >>> if(BootHolder.instance == null) { > >> >> >>> ServiceLoader serviceLoader = > >> >> >>> ServiceLoader.load(CDIBooter.class); > >> >> >>> for(CDIBooter booter : serviceLoader) { > >> >> >>> BootHolder.instance = booter; > >> >> >>> break; > >> >> >>> } > >> >> >>> } > >> >> >>> return BootHolder.instance; > >> >> >>> } > >> >> >>> } > >> >> >>> > >> >> >>> where as the abstract class is a bit briefer, while also > being > >> >> >>> private. > >> >> >>> > >> >> >>> public abstract class CDIBooter { > >> >> >>> public BeanManager initialize() { > >> >> >>> return initialize(new HashMap<>()); > >> >> >>> } > >> >> >>> > >> >> >>> public abstract BeanManager initialize(Map > properties); > >> >> >>> > >> >> >>> public abstract void shutdown(); > >> >> >>> > >> >> >>> private static CDIBooter instance = null; > >> >> >>> > >> >> >>> public static CDIBooter instance() { > >> >> >>> if(instance == null) { > >> >> >>> ServiceLoader serviceLoader = > >> >> >>> ServiceLoader.load(CDIBooter.class); > >> >> >>> for(CDIBooter booter : serviceLoader) { > >> >> >>> instance = booter; > >> >> >>> break; > >> >> >>> } > >> >> >>> } > >> >> >>> return instance; > >> >> >>> } > >> >> >>> } > >> >> >>> > >> >> >>> Obviously ignore concurrency issues, etc. It does look > to be safer > >> >> >>> to > >> >> >>> do > >> >> >>> an > >> >> >>> abstract class, rather than a factory-interface. > >> >> >>> > >> >> >>> John > >> >> >>> > >> >> >>> > >> >> >>> On Wed Dec 17 2014 at 10:40:44 AM Antoine Sabot-Durand > >> >> >>> > wrote: > >> >> >>>> > >> >> >>>> Hi all, > >> >> >>>> > >> >> >>>> > >> >> >>>> I have business matter and will have to shorten the meeting > >> >> >>>> tonight > >> >> >>>> (half > >> >> >>>> an hour instead of 1h). > >> >> >>>> > >> >> >>>> I updated the SE doc and Antonio added useful annexes : > >> >> >>>> > >> >> >>>> > >> >> >>>> > >> >> >>>> > https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing > >> >> >>>> > >> >> >>>> I propose we focus on this in these 30 mn > >> >> >>>> > >> >> >>>> regards, > >> >> >>>> > >> >> >>>> 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. > >> >> > > >> >> > > >> >> _______________________________________________ > >> >> cdi-dev mailing list > >> >> cdi-dev at lists.jboss.org > >> >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> >> > >> >> Note that for all code provided on this list, the provider > licenses the > >> >> code under the Apache License, Version 2 > >> >> (http://www.apache.org/licenses/LICENSE-2.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 > > > > -- > 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/20141218/7a7ad98a/attachment-0001.html From antoine at sabot-durand.net Thu Dec 18 13:07:15 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 18 Dec 2014 19:07:15 +0100 Subject: [cdi-dev] Today's meeting will be shorter and about SE In-Reply-To: References: <54928447.8090605@redhat.com> <5492890B.1070307@redhat.com> Message-ID: Sorry John I thought you had the permission. Just gave them to you Antoine > Le 18 d?c. 2014 ? 13:26, John D. Ament a ?crit : > > I would recommend that at least some of these comments make their way into the google doc. Things like BeanManager come from there. > > I simply dropped a huge code snippet in here since there was no easy way to include it in the doc. > > On Thu, Dec 18, 2014 at 5:57 AM, Jos? Paumard > wrote: > Yes, there are good use cases for letting the user provide his own ES to have async calls executed in them. They are the same kind of use cases we have for CompletionStage. > > Jos? > > 2014-12-18 10:18 GMT+01:00 Romain Manni-Bucau >: > 2014-12-18 9:58 GMT+01:00 Jos? Paumard >: > > From what we wrote about async events, ES can be submitted through the > > fireAsync call, following the patterns of CompletionStage. We can also > > submit a default ES while building a CDI container (a you wrote), and if we > > dont the default ES will probably be the default ForkJoinPool. > > > > So we may have more than one ES, making things more complicated than the > > pattern you wrote. I think that having the user to close all the ESes will > > lead to the same pattern again and again : > > for (ES es : cdi.getESes()) { > > myShutdown(es) ; > > } > > > > Sorry I missed something here: how can we get multiple ES? Basically > if CDI needs a ES behing the scene I expect it expose few config like > potential concurrent calls number etc...In such a case I'm not sure if > having multiple ES would be a good idea. > > > I'd prefer to have a cdi.shutdown(), cdi.shudownNow() or > > cdi.awaitTermination(...) or whatever we call those methods, to encapsulate > > this code. Seems cleaner to me. It might look like CDI is becoming an ES > > itself, but it's delegation, not inheritance. > > > > > > > > 2014-12-18 9:28 GMT+01:00 Romain Manni-Bucau >: > >> > >> Why exposing them? When not simply exposing the executor service (in > >> "init" method). > >> > >> CDIContainer cdi = CDIContainer.init(singletonMap(ExecutorService.class, > >> myEs)); > >> // do something awesome > >> shutdownAsIwant(myEs); > >> cdi.close(); > >> > >> Would avoid to have a lot of method several users will not care about. > >> > >> By default it would do a if (timeout <= 0 || > >> !defaultEs.awaitTermination(timeout, MILLISECONDS)) { for (Runnable r > >> : defaultEs.shutdownNow()) { try { r.cancel(); } catch(e) { log(e); } > >> } } with timeout a property of the init map with a default in > >> CDIContainer (constant) > >> > >> wdyt? > >> > >> > >> Romain Manni-Bucau > >> @rmannibucau > >> http://www.tomitribe.com > >> http://rmannibucau.wordpress.com > >> https://github.com/rmannibucau > >> > >> > >> 2014-12-18 9:19 GMT+01:00 Jos? Paumard >: > >> > I think we need to think more about how to close the Container. > >> > > >> > We need to take into account the fact that there wil be async process > >> > running in ExecutorServices (SE) or ManagedExecutorServices (EE). So the > >> > shutting down the container will mean shutting down these ES too. > >> > > >> > So I think we should need to carefully look at the way ES are closed. > >> > The > >> > question being : what do we do with async tasks that are still running : > >> > should we abruptely interrupt them ? give them a chance to complete ? > >> > All > >> > these are exposed in different methods of ES : shutdown(), shutdownNow() > >> > and > >> > awaitTermination(timeout). Since the container will have to call one of > >> > these methods per ES it will manage, I think we should also expose them. > >> > > >> > Jos? > >> > > >> > > >> > 2014-12-18 9:14 GMT+01:00 Romain Manni-Bucau >: > >> >> > >> >> ServiceLoader.load() = ServiceLoader.load(, tccl) > >> >> > >> >> I was thinking to a plain servlet engine (tomcat to not say any name) > >> >> and CDI container API to boot in webapps. Having cdi API in tomcat > >> >> itself and CDI impl in webapps (Weld in webapp1, OWB in webapp2 for > >> >> instance). This would mean using one webapp classloader to find the > >> >> booter/container. This is fine excepted if the instance is cached. > >> >> > >> >> Same thought in more complicated about OSGi but I guess it is not yet > >> >> the target. > >> >> > >> >> > >> >> Romain Manni-Bucau > >> >> @rmannibucau > >> >> http://www.tomitribe.com > >> >> http://rmannibucau.wordpress.com > >> >> https://github.com/rmannibucau > >> >> > >> >> > >> >> 2014-12-18 8:58 GMT+01:00 Jozef Hartinger >: > >> >> > > >> >> > On 12/18/2014 08:48 AM, Romain Manni-Bucau wrote: > >> >> >> > >> >> >> Hi guys, > >> >> >> > >> >> >> - why shutdown and not AutoClosable? > >> >> > > >> >> > I like this idea. > >> >> >> > >> >> >> - about instance: it uses TCCL to load the impls, not sure it is > >> >> >> intended but depending the deployment it can be an issue (is this > >> >> >> api > >> >> >> 100% JavaSE + flat classpath - ie more constrained than JavaSE?) + > >> >> >> most of javax SPI creates a new instance each time "creator" is > >> >> >> called. > >> >> > > >> >> > I don't follow. Who uses TCCL? > >> >> >> > >> >> >> - Why Booter and not Container (better than factory IMO)? 1) for > >> >> >> consistency with other spec, 2) why can I shutdown a booter ;)? > >> >> > > >> >> > Exactly > >> >> > > >> >> >> > >> >> >> > >> >> >> > >> >> >> Romain Manni-Bucau > >> >> >> @rmannibucau > >> >> >> http://www.tomitribe.com > >> >> >> http://rmannibucau.wordpress.com > >> >> >> https://github.com/rmannibucau > >> >> >> > >> >> >> > >> >> >> 2014-12-18 8:37 GMT+01:00 Jozef Hartinger >: > >> >> >>> > >> >> >>> On 12/18/2014 04:33 AM, John D. Ament wrote: > >> >> >>> > >> >> >>> I thought today's meeting was pretty good. Based on one of the > >> >> >>> discussion > >> >> >>> points, I wanted to try putting together an interface that > >> >> >>> described > >> >> >>> the > >> >> >>> boot paradigm. Unfortunately even in Java 8 it doesn't work too > >> >> >>> well, > >> >> >>> I > >> >> >>> cannot assign a static variable in an interface the way I can in an > >> >> >>> abstract > >> >> >>> class. More importantly, it doesn't give us the private level > >> >> >>> expectation I > >> >> >>> would look for in this case. I best I could come up with using an > >> >> >>> interface > >> >> >>> is: > >> >> >>> > >> >> >>> public interface CDIBooter { > >> >> >>> default BeanManager initialize() { > >> >> >>> return initialize(new HashMap<>()); > >> >> >>> } > >> >> >>> > >> >> >>> BeanManager initialize(Map properties); > >> >> >>> > >> >> >>> Why BeanManager? I think it would be better to return CDI or its > >> >> >>> subclass > >> >> >>> rather than this low-level SPI. With the CDI class we get more > >> >> >>> user-friendly > >> >> >>> Instance for free. We could also expose Event similarly. > >> >> >>> > >> >> >>> > >> >> >>> void shutdown(); > >> >> >>> > >> >> >>> class BootHolder { > >> >> >>> > >> >> >>> static CDIBooter instance = null; > >> >> >>> > >> >> >>> } > >> >> >>> > >> >> >>> static CDIBooter instance() { > >> >> >>> if(BootHolder.instance == null) { > >> >> >>> ServiceLoader serviceLoader = > >> >> >>> ServiceLoader.load(CDIBooter.class); > >> >> >>> for(CDIBooter booter : serviceLoader) { > >> >> >>> BootHolder.instance = booter; > >> >> >>> break; > >> >> >>> } > >> >> >>> } > >> >> >>> return BootHolder.instance; > >> >> >>> } > >> >> >>> } > >> >> >>> > >> >> >>> where as the abstract class is a bit briefer, while also being > >> >> >>> private. > >> >> >>> > >> >> >>> public abstract class CDIBooter { > >> >> >>> public BeanManager initialize() { > >> >> >>> return initialize(new HashMap<>()); > >> >> >>> } > >> >> >>> > >> >> >>> public abstract BeanManager initialize(Map properties); > >> >> >>> > >> >> >>> public abstract void shutdown(); > >> >> >>> > >> >> >>> private static CDIBooter instance = null; > >> >> >>> > >> >> >>> public static CDIBooter instance() { > >> >> >>> if(instance == null) { > >> >> >>> ServiceLoader serviceLoader = > >> >> >>> ServiceLoader.load(CDIBooter.class); > >> >> >>> for(CDIBooter booter : serviceLoader) { > >> >> >>> instance = booter; > >> >> >>> break; > >> >> >>> } > >> >> >>> } > >> >> >>> return instance; > >> >> >>> } > >> >> >>> } > >> >> >>> > >> >> >>> Obviously ignore concurrency issues, etc. It does look to be safer > >> >> >>> to > >> >> >>> do > >> >> >>> an > >> >> >>> abstract class, rather than a factory-interface. > >> >> >>> > >> >> >>> John > >> >> >>> > >> >> >>> > >> >> >>> On Wed Dec 17 2014 at 10:40:44 AM Antoine Sabot-Durand > >> >> >>> > wrote: > >> >> >>>> > >> >> >>>> Hi all, > >> >> >>>> > >> >> >>>> > >> >> >>>> I have business matter and will have to shorten the meeting > >> >> >>>> tonight > >> >> >>>> (half > >> >> >>>> an hour instead of 1h). > >> >> >>>> > >> >> >>>> I updated the SE doc and Antonio added useful annexes : > >> >> >>>> > >> >> >>>> > >> >> >>>> > >> >> >>>> https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing > >> >> >>>> > >> >> >>>> I propose we focus on this in these 30 mn > >> >> >>>> > >> >> >>>> regards, > >> >> >>>> > >> >> >>>> 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. > >> >> > > >> >> > > >> >> _______________________________________________ > >> >> cdi-dev mailing list > >> >> cdi-dev at lists.jboss.org > >> >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> >> > >> >> Note that for all code provided on this list, the provider licenses the > >> >> code under the Apache License, Version 2 > >> >> (http://www.apache.org/licenses/LICENSE-2.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 > > > -- > 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/20141218/90c8ddee/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/20141218/90c8ddee/attachment-0001.bin From werner.keil at gmail.com Thu Dec 18 14:37:50 2014 From: werner.keil at gmail.com (Werner Keil) Date: Thu, 18 Dec 2014 20:37:50 +0100 Subject: [cdi-dev] Today's meeting will be shorter and about SE Message-ID: Seems nobody else in the EG even has comment rights to the Google doc? Werner On Thu, Dec 18, 2014 at 7:07 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: Today's meeting will be shorter and about SE > (Antoine Sabot-Durand) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 18 Dec 2014 19:07:15 +0100 > From: Antoine Sabot-Durand > Subject: Re: [cdi-dev] Today's meeting will be shorter and about SE > To: John Ament > Cc: Jos? Paumard , cdi-dev > > Message-ID: > Content-Type: text/plain; charset="utf-8" > > Sorry John I thought you had the permission. Just gave them to you > > Antoine > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141218/7e128b78/attachment.html From atsticks at gmail.com Thu Dec 18 16:57:44 2014 From: atsticks at gmail.com (Anatole Tresch) Date: Thu, 18 Dec 2014 22:57:44 +0100 Subject: [cdi-dev] Is the concept of mutable event payload specified In-Reply-To: <1EFACDFC-267C-4F36-8B0D-22B44FF43B6A@sabot-durand.net> References: <213B41E0-D73F-4CED-95B0-AFB50451B791@sabot-durand.net> <1418809749672.21827@stefanutti.fr> <1EFACDFC-267C-4F36-8B0D-22B44FF43B6A@sabot-durand.net> Message-ID: Hi all I would say we can also see mutability/immutability as simply two options.. In general it is a decision of the event/payload designer, If the event is mutable or not, and if it is mutable, it should be implemented in a thread safe way with (hopefully) minimal locking/synch efforts. To mention the ladder somewhere in the spec might be useful. I would hereby tend to follow the same policy for synch and asynch events (you never know what else payload consumers do with the event). I think it is sufficient to warn users that mutable asynch events basically can create race conditions and locks if thread-safety is not given, but I would not generally disable/disallow it. -Anatole 2014-12-17 17:49 GMT+01:00 Antoine Sabot-Durand : > > Ok guys, > > Let?s do it again. I didn?t say we have to forbid the mutability I said we > have at least to explicitly write that it?s mutable and seriously think of > having it immutable for event fired asynchronously. > > (Pete) I don?t think it?s specified. As objects are, by default in Java, > mutable, I would assume that payloads are implicitly mutable. > > > Sorry @Pete I don?t agree with your point. Yes, in Java object are mutable > but firing an event is not a standard Java feature : you send your object > to a black box and let this box dispatch your object to listeners > transforming one call to multiple call : it?s far from standard Java rules. > Even if it?s not written it?s an observer pattern and there are people out > there thinking that introducing mutability in observer is an anti-pattern > since some listener will receive a different payload than the one that was > sent to them. > It?s like making a method call and having no guarantee that the parameter > received in the callee has the same value that in the caller... > I won?t start discussion on bad practice or anti pattern as I also use > mutability in event but there as much reason for user to assume their > payload will be mutable than the other way around. > I can assure you that when I give a talk on CDI, this payload mutability > is often a surprise for attendees... > > (Romain) why isn't it portable? > > > So yes @Romain it?s not portable (in theory of course, since both > implementations support mutability). Someone could write a CDI > implementation with event payload immutability without any issue with the > spec and TCK. > > Most of you are so dependent of this feature that you only reacted to the > idea or forbidding it (which wasn?t the content of my mail) ;). So we all > agree that it?s an important feature. Therefore what?s the issue to specify > this mutability and add TCK test for it ? > > Now I don?t deal with that subject for nothing, we are planning to > introduce Async events. I think that it?ll bring extra complexity if we > support mutability in async events. And even if I?m wrong and we finally go > for mutability in async events, this will lead to possible side effect > (lock) that could have impact on perf, so it should be explicitly written > IMO. > > 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. > -- *Anatole Tresch* Java Engineer & Architect, JSR Spec Lead Gl?rnischweg 10 CH - 8620 Wetzikon *Switzerland, Europe Zurich, GMT+1* *Twitter: @atsticks* *Blogs: **http://javaremarkables.blogspot.ch/ * *Google: atsticksMobile +41-76 344 62 79* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141218/8118c813/attachment.html From antoine at sabot-durand.net Fri Dec 19 06:03:47 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 19 Dec 2014 12:03:47 +0100 Subject: [cdi-dev] Do we already have a kind of CDI SE in 1.1+ ? Message-ID: <447840BC-5B62-430D-BA64-F66C382F3CC2@sabot-durand.net> Hi guys, As I said during last meeting I was puzzled by the non use of CDI and CDIProvider to address CDI boot in Java SE. I just made a small test adding this class to weld-se : public class WeldSEProvider extends WeldProvider { private static boolean firstTime = true; @Override public CDI getCDI() { if (firstTime) { new Weld().initialize(); firstTime = false; } return super.getCDI(); } } and replaced the content of META-INF/services/javax.enterprise.inject.spi.CDIProvider by my provider org.jboss.weld.environment.se.WeldSEProvider Using this new version of Weld-se in my project Iw as able to boot CDI without implementation classes : public class Main { public static void main(String[] args) throws Exception { CDI cdi = CDI.current(); BeanManager bm = cdi.getBeanManager(); } } Code is available in my weld fork : https://github.com/antoinesd/weld-core/blob/2.2-SE/environments/se/core/src/main/java/org/jboss/weld/environment/se/WeldSEProvider.java Similar CDIProvider can be written for OWB as well. I may have missed something, but I think we can figure out something like that to provide SE support in CDI today, even if it?s not as complete as the one we plan to push in CDI 2.0 Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141219/72114d94/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/20141219/72114d94/attachment.bin From pmuir at redhat.com Fri Dec 19 06:14:55 2014 From: pmuir at redhat.com (Pete Muir) Date: Fri, 19 Dec 2014 11:14:55 +0000 Subject: [cdi-dev] Do we already have a kind of CDI SE in 1.1+ ? In-Reply-To: <447840BC-5B62-430D-BA64-F66C382F3CC2@sabot-durand.net> References: <447840BC-5B62-430D-BA64-F66C382F3CC2@sabot-durand.net> Message-ID: <6D9D0A51-FBD9-4353-A4C7-95351CDCB4E3@redhat.com> I think the main reason we wanted to split it was due to not confusing the use cases of booting CDI and accessing the CDI container. > On 19 Dec 2014, at 11:03, Antoine Sabot-Durand wrote: > > Hi guys, > > As I said during last meeting I was puzzled by the non use of CDI and CDIProvider to address CDI boot in Java SE. > > I just made a small test adding this class to weld-se : > > public class WeldSEProvider extends WeldProvider { > > private static boolean firstTime = true; > > @Override > public CDI getCDI() { > if (firstTime) { > new Weld().initialize(); > firstTime = false; > } > > return super.getCDI(); > } > > } > > and replaced the content of META-INF/services/javax.enterprise.inject.spi.CDIProvider by my provider > > org.jboss.weld.environment.se.WeldSEProvider > > Using this new version of Weld-se in my project Iw as able to boot CDI without implementation classes : > > public class Main { > > public static void main(String[] args) throws Exception { > CDI cdi = CDI.current(); > BeanManager bm = cdi.getBeanManager(); > > } > > } > > Code is available in my weld fork : https://github.com/antoinesd/weld-core/blob/2.2-SE/environments/se/core/src/main/java/org/jboss/weld/environment/se/WeldSEProvider.java > > Similar CDIProvider can be written for OWB as well. > > I may have missed something, but I think we can figure out something like that to provide SE support in CDI today, even if it?s not as complete as the one we plan to push in CDI 2.0 > > Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141219/2dab1cab/attachment-0001.html From jharting at redhat.com Fri Dec 19 06:24:10 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Fri, 19 Dec 2014 12:24:10 +0100 Subject: [cdi-dev] Do we already have a kind of CDI SE in 1.1+ ? In-Reply-To: <447840BC-5B62-430D-BA64-F66C382F3CC2@sabot-durand.net> References: <447840BC-5B62-430D-BA64-F66C382F3CC2@sabot-durand.net> Message-ID: <54940ADA.80702@redhat.com> Interesting idea (for CDI 1.2 containers running in SE). As you wrote for CDI 2.0 we need much more. On 12/19/2014 12:03 PM, Antoine Sabot-Durand wrote: > Hi guys, > > As I said during last meeting I was puzzled by the non use of CDI and > CDIProvider to address CDI boot in Java SE. > > I just made a small test adding this class to weld-se : > > public class WeldSEProvider extends WeldProvider { > > private static boolean firstTime = true; > > @Override > public CDI getCDI() { > if (firstTime) { > new Weld().initialize(); > firstTime = false; > } > > return super.getCDI(); > } > > } > > and replaced the content of > META-INF/services/javax.enterprise.inject.spi.CDIProvider by my provider > > org.jboss.weld.environment.se.WeldSEProvider > > Using this new version of Weld-se in my project Iw as able to boot CDI > without implementation classes : > > public class Main { > > public static void main(String[] args) throws Exception { > CDI cdi = CDI.current(); > BeanManager bm = cdi.getBeanManager(); > > } > > } > > Code is available in my weld fork : > https://github.com/antoinesd/weld-core/blob/2.2-SE/environments/se/core/src/main/java/org/jboss/weld/environment/se/WeldSEProvider.java > > Similar CDIProvider can be written for OWB as well. > > I may have missed something, but I think we can figure out something > like that to provide SE support in CDI today, even if it?s not as > complete as the one we plan to push in CDI 2.0 > > Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141219/865e4038/attachment.html From antoine at sabot-durand.net Fri Dec 19 06:44:29 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 19 Dec 2014 12:44:29 +0100 Subject: [cdi-dev] Do we already have a kind of CDI SE in 1.1+ ? In-Reply-To: <54940ADA.80702@redhat.com> References: <447840BC-5B62-430D-BA64-F66C382F3CC2@sabot-durand.net> <54940ADA.80702@redhat.com> Message-ID: <86F888CF-7509-49B8-8DE4-AE0631C7C04A@sabot-durand.net> Of course Jozef: We need something more controllable in CDI 2.0. But it can be a basic alternative that works right now in CDI 1.2. Antoine Sabot-Durand > Le 19 d?c. 2014 ? 12:24, Jozef Hartinger a ?crit : > > Interesting idea (for CDI 1.2 containers running in SE). As you wrote for CDI 2.0 we need much more. > >> On 12/19/2014 12:03 PM, Antoine Sabot-Durand wrote: >> Hi guys, >> >> As I said during last meeting I was puzzled by the non use of CDI and CDIProvider to address CDI boot in Java SE. >> >> I just made a small test adding this class to weld-se : >> >> public class WeldSEProvider extends WeldProvider { >> >> private static boolean firstTime = true; >> >> @Override >> public CDI getCDI() { >> if (firstTime) { >> new Weld().initialize(); >> firstTime = false; >> } >> >> return super.getCDI(); >> } >> >> } >> >> and replaced the content of META-INF/services/javax.enterprise.inject.spi.CDIProvider by my provider >> >> org.jboss.weld.environment.se.WeldSEProvider >> >> Using this new version of Weld-se in my project Iw as able to boot CDI without implementation classes : >> >> public class Main { >> >> public static void main(String[] args) throws Exception { >> CDI cdi = CDI.current(); >> BeanManager bm = cdi.getBeanManager(); >> >> } >> >> } >> >> Code is available in my weld fork : https://github.com/antoinesd/weld-core/blob/2.2-SE/environments/se/core/src/main/java/org/jboss/weld/environment/se/WeldSEProvider.java >> >> Similar CDIProvider can be written for OWB as well. >> >> I may have missed something, but I think we can figure out something like that to provide SE support in CDI today, even if it?s not as complete as the one we plan to push in CDI 2.0 >> >> Antoine > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141219/1a1e543e/attachment.html From struberg at yahoo.de Fri Dec 19 17:48:25 2014 From: struberg at yahoo.de (Mark Struberg) Date: Fri, 19 Dec 2014 22:48:25 +0000 (UTC) Subject: [cdi-dev] Do we already have a kind of CDI SE in 1.1+ ? In-Reply-To: <86F888CF-7509-49B8-8DE4-AE0631C7C04A@sabot-durand.net> References: <86F888CF-7509-49B8-8DE4-AE0631C7C04A@sabot-durand.net> Message-ID: <2074070856.943898.1419029305893.JavaMail.yahoo@jws11139.mail.ir2.yahoo.com> This is nowhere near portable as far as I can see. And we had container specific hacks since day 1 so to say... Or maybe I don't get it? How would that work in OWB? Would it even work in older Weld versions (1.2.x)? LieGrue, strub On Friday, 19 December 2014, 12:45, Antoine Sabot-Durand wrote: > > >Of course Jozef: We need something more controllable in CDI 2.0. But it can be a basic alternative that works right now in CDI 1.2. > >Antoine Sabot-Durand > >Le 19 d?c. 2014 ? 12:24, Jozef Hartinger a ?crit : > > >Interesting idea (for CDI 1.2 containers running in SE). As you wrote for CDI 2.0 we need much more. > > >On 12/19/2014 12:03 PM, Antoine Sabot-Durand wrote: > >Hi guys, > > >As I said during last meeting I was puzzled by the non use of CDI and CDIProvider to address CDI boot in Java SE. > > >I just made a small test adding this class to weld-se : > > >public class WeldSEProvider extends WeldProvider { > > private static boolean firstTime = true; > > @Override > public CDI getCDI() { > if (firstTime) { > new Weld().initialize(); > firstTime = false; > } > > return super.getCDI(); > } > >} > > > >and replaced the content of META-INF/services/javax.enterprise.inject.spi.CDIProvider by my provider > > >org.jboss.weld.environment.se.WeldSEProvider > > >Using this new version of Weld-se in my project Iw as able to boot CDI without implementation classes : > > >public class Main { > > public static void main(String[] args) throws Exception { > CDI cdi = CDI.current(); > BeanManager bm = cdi.getBeanManager(); > > } > >} > > >Code is available in my weld fork : https://github.com/antoinesd/weld-core/blob/2.2-SE/environments/se/core/src/main/java/org/jboss/weld/environment/se/WeldSEProvider.java > > >Similar CDIProvider can be written for OWB as well. > > >I may have missed something, but I think we can figure out something like that to provide SE support in CDI today, even if it?s not as complete as the one we plan to push in CDI 2.0 > > >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 struberg at yahoo.de Sat Dec 20 05:16:08 2014 From: struberg at yahoo.de (Mark Struberg) Date: Sat, 20 Dec 2014 10:16:08 +0000 (UTC) Subject: [cdi-dev] @Alternative without extends or implements? Message-ID: <1961725612.1034023.1419070568514.JavaMail.yahoo@jws11138.mail.ir2.yahoo.com> Hi! Some TCK tests have @Alternative classes which neither extend nor implement a class. Of course they explicitly extend Object.class, but that does not really make sense, doesn't it? LieGrue, strub From struberg at yahoo.de Sat Dec 20 05:26:57 2014 From: struberg at yahoo.de (Mark Struberg) Date: Sat, 20 Dec 2014 10:26:57 +0000 (UTC) Subject: [cdi-dev] Ordering of AfterTypeDiscovery#getAlternatives() et al Message-ID: <1570974989.1030075.1419071217856.JavaMail.yahoo@jws11143.mail.ir2.yahoo.com> Hi! If I have a @Priority(100) public class MyAlternative implements Foo .. and @Priority(101) public class ABetterAlternative implements Foo .. Then ABetterAlternative will finally be chosen. This ordering can be changed via AfterTypeDiscovery#getAlternatives(). But the spec only says "returns the ordered list of enabled alternatives for the application.." But it does NOT define in which sorting this list is ordered ;) In OWB we hat the 'most important' alternative come first. It seems in Weld it is the other way around. I have no problem with changing this in OWB, but I would like to get this clarified in our JavaDocs and spec. LieGrue, strub From antoine at sabot-durand.net Sat Dec 20 11:35:03 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Sat, 20 Dec 2014 17:35:03 +0100 Subject: [cdi-dev] Do we already have a kind of CDI SE in 1.1+ ? In-Reply-To: <2074070856.943898.1419029305893.JavaMail.yahoo@jws11139.mail.ir2.yahoo.com> References: <86F888CF-7509-49B8-8DE4-AE0631C7C04A@sabot-durand.net> <2074070856.943898.1419029305893.JavaMail.yahoo@jws11139.mail.ir2.yahoo.com> Message-ID: <3A12C6DD-000A-48FF-A2A9-7F62C572772F@sabot-durand.net> > Le 19 d?c. 2014 ? 23:48, Mark Struberg a ?crit : > > This is nowhere near portable as far as I can see. That?s probably why it took me 5 minutes to port it successfully to OpenWebBeans 1.5.0 ;) look at the modified file : https://github.com/antoinesd/openwebbeans/blob/1.5.0-with-se/webbeans-impl/src/main/java/org/apache/webbeans/container/OwbCDIProvider.java It probably needs something nicer to detect if OWB is running in SE or EE but the idea is here > And we had container specific hacks since day 1 so to say? I?m not talking about container. After having added specific part in each implementation, we have the same way to start CDI I demonstrated that CDI 1.1+ this piece of code could boot CDI in SE if the implementation has what is required Look at new version of OWB standalone-sample: https://github.com/antoinesd/openwebbeans/blob/1.5.0-with-se/samples/standalone-sample/src/main/java/org/apache/webbeans/se/sample/Boot.java No more import of OWB specific classes and yet it runs. > Or maybe I don't get it? How would that work in OWB? > Would it even work in older Weld versions (1.2.x)? Of course not because Weld 1.2 -> CDI 1.0. I?m talking about CDI 1.1 and 1.2 as it is written in this email subject. Of course there are limitation especially regarding shutdown. But it is portable way of booting CDI at spec level. Could be interesting to addd this trick to our simple and communicate on it to say that portable CDI support for SE is already here. We?ll provide a better support in CDI 2.0 but in the meantime this can be useful. Antoine > > LieGrue, > strub > > > > On Friday, 19 December 2014, 12:45, Antoine Sabot-Durand wrote: > > >> >> >> Of course Jozef: We need something more controllable in CDI 2.0. But it can be a basic alternative that works right now in CDI 1.2. >> >> Antoine Sabot-Durand >> >> Le 19 d?c. 2014 ? 12:24, Jozef Hartinger a ?crit : >> >> >> Interesting idea (for CDI 1.2 containers running in SE). As you wrote for CDI 2.0 we need much more. >> >> >> On 12/19/2014 12:03 PM, Antoine Sabot-Durand wrote: >> >> Hi guys, >> >> >> As I said during last meeting I was puzzled by the non use of CDI and CDIProvider to address CDI boot in Java SE. >> >> >> I just made a small test adding this class to weld-se : >> >> >> public class WeldSEProvider extends WeldProvider { >> >> private static boolean firstTime = true; >> >> @Override >> public CDI getCDI() { >> if (firstTime) { >> new Weld().initialize(); >> firstTime = false; >> } >> >> return super.getCDI(); >> } >> >> } >> >> >> >> and replaced the content of META-INF/services/javax.enterprise.inject.spi.CDIProvider by my provider >> >> >> org.jboss.weld.environment.se.WeldSEProvider >> >> >> Using this new version of Weld-se in my project Iw as able to boot CDI without implementation classes : >> >> >> public class Main { >> >> public static void main(String[] args) throws Exception { >> CDI cdi = CDI.current(); >> BeanManager bm = cdi.getBeanManager(); >> >> } >> >> } >> >> >> Code is available in my weld fork : https://github.com/antoinesd/weld-core/blob/2.2-SE/environments/se/core/src/main/java/org/jboss/weld/environment/se/WeldSEProvider.java >> >> >> Similar CDIProvider can be written for OWB as well. >> >> >> I may have missed something, but I think we can figure out something like that to provide SE support in CDI today, even if it?s not as complete as the one we plan to push in CDI 2.0 >> >> >> 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/20141220/6a7e247e/attachment-0001.bin From struberg at yahoo.de Sat Dec 20 12:04:51 2014 From: struberg at yahoo.de (Mark Struberg) Date: Sat, 20 Dec 2014 17:04:51 +0000 (UTC) Subject: [cdi-dev] Do we already have a kind of CDI SE in 1.1+ ? In-Reply-To: <3A12C6DD-000A-48FF-A2A9-7F62C572772F@sabot-durand.net> References: <3A12C6DD-000A-48FF-A2A9-7F62C572772F@sabot-durand.net> Message-ID: <1342202599.1141088.1419095091366.JavaMail.yahoo@jws11144.mail.ir2.yahoo.com> I see. What you did is to leverage the existing CDI-1.1 API and enhance it with new functionality. But actually it is not in the CDI spec yet. That was the part which confused me. Regarding shutdown: well that's not a small issue I fear. And you still have no whatever control over the contexts. Which is another blocker imo. It's always good to re-think other usages of our APIs. Let me sleep a few days thinking about it. LieGrue, strub > On Saturday, 20 December 2014, 17:40, Antoine Sabot-Durand wrote: > > >> Le 19 d?c. 2014 ? 23:48, Mark Struberg a ?crit : >> >> This is nowhere near portable as far as I can see. > > > That?s probably why it took me 5 minutes to port it successfully to OpenWebBeans > 1.5.0 ;) > > look at the modified file : > https://github.com/antoinesd/openwebbeans/blob/1.5.0-with-se/webbeans-impl/src/main/java/org/apache/webbeans/container/OwbCDIProvider.java > > It probably needs something nicer to detect if OWB is running in SE or EE but > the idea is here > > >> And we had container specific hacks since day 1 so to say? > > I?m not talking about container. After having added specific part in each > implementation, we have the same way to start CDI > I demonstrated that CDI 1.1+ this piece of code could boot CDI in SE if the > implementation has what is required > > Look at new version of OWB standalone-sample: > > https://github.com/antoinesd/openwebbeans/blob/1.5.0-with-se/samples/standalone-sample/src/main/java/org/apache/webbeans/se/sample/Boot.java > > No more import of OWB specific classes and yet it runs. > > >> Or maybe I don't get it? How would that work in OWB? >> Would it even work in older Weld versions (1.2.x)? > > Of course not because Weld 1.2 -> CDI 1.0. I?m talking about CDI 1.1 and 1.2 > as it is written in this email subject. > > Of course there are limitation especially regarding shutdown. But it is portable > way of booting CDI at spec level. Could be interesting to addd this trick to our > simple and communicate on it to say that portable CDI support for SE is already > here. > > We?ll provide a better support in CDI 2.0 but in the meantime this can be > useful. > > > Antoine > > > > >> >> LieGrue, >> strub >> >> >> >> On Friday, 19 December 2014, 12:45, Antoine Sabot-Durand > wrote: >> >> >>> >>> >>> Of course Jozef: We need something more controllable in CDI 2.0. But it > can be a basic alternative that works right now in CDI 1.2. >>> >>> Antoine Sabot-Durand >>> >>> Le 19 d?c. 2014 ? 12:24, Jozef Hartinger a > ?crit : >>> >>> >>> Interesting idea (for CDI 1.2 containers running in SE). As you wrote > for CDI 2.0 we need much more. >>> >>> >>> On 12/19/2014 12:03 PM, Antoine Sabot-Durand wrote: >>> >>> Hi guys, >>> >>> >>> As I said during last meeting I was puzzled by the non use of CDI and > CDIProvider to address CDI boot in Java SE. >>> >>> >>> I just made a small test adding this class to weld-se : >>> >>> >>> public class WeldSEProvider extends WeldProvider { >>> >>> private static boolean firstTime = true; >>> >>> @Override >>> public CDI getCDI() { >>> if (firstTime) { >>> new Weld().initialize(); >>> firstTime = false; >>> } >>> >>> return super.getCDI(); >>> } >>> >>> } >>> >>> >>> >>> and replaced the content of > META-INF/services/javax.enterprise.inject.spi.CDIProvider by my provider >>> >>> >>> org.jboss.weld.environment.se.WeldSEProvider >>> >>> >>> Using this new version of Weld-se in my project Iw as able to boot CDI > without implementation classes : >>> >>> >>> public class Main { >>> >>> public static void main(String[] args) throws Exception { >>> CDI cdi = CDI.current(); >>> BeanManager bm = cdi.getBeanManager(); >>> >>> } >>> >>> } >>> >>> >>> Code is available in my weld fork : > https://github.com/antoinesd/weld-core/blob/2.2-SE/environments/se/core/src/main/java/org/jboss/weld/environment/se/WeldSEProvider.java >>> >>> >>> Similar CDIProvider can be written for OWB as well. >>> >>> >>> I may have missed something, but I think we can figure out something > like that to provide SE support in CDI today, even if it?s not as complete as > the one we plan to push in CDI 2.0 >>> >>> >>> 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 arjan.tijms at gmail.com Sat Dec 20 15:21:33 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Sat, 20 Dec 2014 21:21:33 +0100 Subject: [cdi-dev] Do we already have a kind of CDI SE in 1.1+ ? In-Reply-To: <3A12C6DD-000A-48FF-A2A9-7F62C572772F@sabot-durand.net> References: <86F888CF-7509-49B8-8DE4-AE0631C7C04A@sabot-durand.net> <2074070856.943898.1419029305893.JavaMail.yahoo@jws11139.mail.ir2.yahoo.com> <3A12C6DD-000A-48FF-A2A9-7F62C572772F@sabot-durand.net> Message-ID: On Sat, Dec 20, 2014 at 5:35 PM, Antoine Sabot-Durand wrote: > That?s probably why it took me 5 minutes to port it successfully to OpenWebBeans 1.5.0 ;) But perhaps the real challenge is whether it can be done in CanDI ;) Grtz, Arjan Tijms > > look at the modified file : https://github.com/antoinesd/openwebbeans/blob/1.5.0-with-se/webbeans-impl/src/main/java/org/apache/webbeans/container/OwbCDIProvider.java > > It probably needs something nicer to detect if OWB is running in SE or EE but the idea is here > > >> And we had container specific hacks since day 1 so to say? > > I?m not talking about container. After having added specific part in each implementation, we have the same way to start CDI > I demonstrated that CDI 1.1+ this piece of code could boot CDI in SE if the implementation has what is required > > Look at new version of OWB standalone-sample: > > https://github.com/antoinesd/openwebbeans/blob/1.5.0-with-se/samples/standalone-sample/src/main/java/org/apache/webbeans/se/sample/Boot.java > > No more import of OWB specific classes and yet it runs. > > >> Or maybe I don't get it? How would that work in OWB? >> Would it even work in older Weld versions (1.2.x)? > > Of course not because Weld 1.2 -> CDI 1.0. I?m talking about CDI 1.1 and 1.2 as it is written in this email subject. > > Of course there are limitation especially regarding shutdown. But it is portable way of booting CDI at spec level. Could be interesting to addd this trick to our simple and communicate on it to say that portable CDI support for SE is already here. > > We?ll provide a better support in CDI 2.0 but in the meantime this can be useful. > > > Antoine > > > >> >> LieGrue, >> strub >> >> >> >> On Friday, 19 December 2014, 12:45, Antoine Sabot-Durand wrote: >> >> >>> >>> >>> Of course Jozef: We need something more controllable in CDI 2.0. But it can be a basic alternative that works right now in CDI 1.2. >>> >>> Antoine Sabot-Durand >>> >>> Le 19 d?c. 2014 ? 12:24, Jozef Hartinger a ?crit : >>> >>> >>> Interesting idea (for CDI 1.2 containers running in SE). As you wrote for CDI 2.0 we need much more. >>> >>> >>> On 12/19/2014 12:03 PM, Antoine Sabot-Durand wrote: >>> >>> Hi guys, >>> >>> >>> As I said during last meeting I was puzzled by the non use of CDI and CDIProvider to address CDI boot in Java SE. >>> >>> >>> I just made a small test adding this class to weld-se : >>> >>> >>> public class WeldSEProvider extends WeldProvider { >>> >>> private static boolean firstTime = true; >>> >>> @Override >>> public CDI getCDI() { >>> if (firstTime) { >>> new Weld().initialize(); >>> firstTime = false; >>> } >>> >>> return super.getCDI(); >>> } >>> >>> } >>> >>> >>> >>> and replaced the content of META-INF/services/javax.enterprise.inject.spi.CDIProvider by my provider >>> >>> >>> org.jboss.weld.environment.se.WeldSEProvider >>> >>> >>> Using this new version of Weld-se in my project Iw as able to boot CDI without implementation classes : >>> >>> >>> public class Main { >>> >>> public static void main(String[] args) throws Exception { >>> CDI cdi = CDI.current(); >>> BeanManager bm = cdi.getBeanManager(); >>> >>> } >>> >>> } >>> >>> >>> Code is available in my weld fork : https://github.com/antoinesd/weld-core/blob/2.2-SE/environments/se/core/src/main/java/org/jboss/weld/environment/se/WeldSEProvider.java >>> >>> >>> Similar CDIProvider can be written for OWB as well. >>> >>> >>> I may have missed something, but I think we can figure out something like that to provide SE support in CDI today, even if it?s not as complete as the one we plan to push in CDI 2.0 >>> >>> >>> 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. From struberg at yahoo.de Sun Dec 21 15:47:35 2014 From: struberg at yahoo.de (Mark Struberg) Date: Sun, 21 Dec 2014 20:47:35 +0000 (UTC) Subject: [cdi-dev] TCK and spec question Message-ID: <1266337261.131805.1419194855711.JavaMail.yahoo@jws11174.mail.ir2.yahoo.com> Hi! I just came across this little sentence in the spec 11.5.6 "If any ProcessAnnotatedType method is called outside of the observer method invocation, an IllegalStateException is thrown." I don't believe such a limitation helps much. What about extensions who do a setAnnotatedType and change this instance in a later phase? We have no whatever chance to prevent this anyway. So why not just say that if a CDI System Event gets modified outside of the method it gets injected into then non portable behaviour results. LieGrue, strub From jharting at redhat.com Mon Dec 22 03:23:08 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Mon, 22 Dec 2014 09:23:08 +0100 Subject: [cdi-dev] Ordering of AfterTypeDiscovery#getAlternatives() et al In-Reply-To: <1570974989.1030075.1419071217856.JavaMail.yahoo@jws11143.mail.ir2.yahoo.com> References: <1570974989.1030075.1419071217856.JavaMail.yahoo@jws11143.mail.ir2.yahoo.com> Message-ID: <5497D4EC.9040907@redhat.com> On 12/20/2014 11:26 AM, Mark Struberg wrote: > Hi! > > If I have a > > > @Priority(100) > public class MyAlternative implements Foo .. > > and > > > @Priority(101) > public class ABetterAlternative implements Foo .. > > > Then ABetterAlternative will finally be chosen. > > This ordering can be changed via AfterTypeDiscovery#getAlternatives(). > > But the spec only says "returns the ordered list of enabled alternatives for the application.." > > But it does NOT define in which sorting this list is ordered ;) > > In OWB we hat the 'most important' alternative come first. It seems in Weld it is the other way around. What sorting do you use for interceptors and decorators? > > I have no problem with changing this in OWB, but I would like to get this clarified in our JavaDocs and spec. Agreed. Go ahead and file an issue. > > 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 rmannibucau at gmail.com Mon Dec 22 03:24:40 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 22 Dec 2014 09:24:40 +0100 Subject: [cdi-dev] Ordering of AfterTypeDiscovery#getAlternatives() et al In-Reply-To: <5497D4EC.9040907@redhat.com> References: <1570974989.1030075.1419071217856.JavaMail.yahoo@jws11143.mail.ir2.yahoo.com> <5497D4EC.9040907@redhat.com> Message-ID: hi 2014-12-22 9:23 GMT+01:00 Jozef Hartinger : > > On 12/20/2014 11:26 AM, Mark Struberg wrote: >> Hi! >> >> If I have a >> >> >> @Priority(100) >> public class MyAlternative implements Foo .. >> >> and >> >> >> @Priority(101) >> public class ABetterAlternative implements Foo .. >> >> >> Then ABetterAlternative will finally be chosen. >> >> This ordering can be changed via AfterTypeDiscovery#getAlternatives(). >> >> But the spec only says "returns the ordered list of enabled alternatives for the application.." >> >> But it does NOT define in which sorting this list is ordered ;) >> >> In OWB we hat the 'most important' alternative come first. It seems in Weld it is the other way around. > What sorting do you use for interceptors and decorators? >> until yesterday the same as for runtime >> I have no problem with changing this in OWB, but I would like to get this clarified in our JavaDocs and spec. > Agreed. Go ahead and file an issue. >> >> 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 jharting at redhat.com Mon Dec 22 03:29:49 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Mon, 22 Dec 2014 09:29:49 +0100 Subject: [cdi-dev] TCK and spec question In-Reply-To: <1266337261.131805.1419194855711.JavaMail.yahoo@jws11174.mail.ir2.yahoo.com> References: <1266337261.131805.1419194855711.JavaMail.yahoo@jws11174.mail.ir2.yahoo.com> Message-ID: <5497D67D.4090005@redhat.com> On 12/21/2014 09:47 PM, Mark Struberg wrote: > Hi! > > I just came across this little sentence in the spec > > > > 11.5.6 "If any ProcessAnnotatedType method is called outside of the observer method invocation, an IllegalStateException is thrown." > > > I don't believe such a limitation helps much. What about extensions who do a setAnnotatedType and change this instance in a later phase? Such as? > We have no whatever chance to prevent this anyway. We can prevent that by throwing the exception, rather than silently ignoring that the extension is doing something wrong. > > So why not just say that if a CDI System Event gets modified outside of the method it gets injected into then non portable behaviour results. > > 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 Mon Dec 22 03:33:44 2014 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 22 Dec 2014 08:33:44 +0000 (UTC) Subject: [cdi-dev] TCK and spec question In-Reply-To: <5497D67D.4090005@redhat.com> References: <5497D67D.4090005@redhat.com> Message-ID: <675565509.45226.1419237224192.JavaMail.yahoo@jws11153.mail.ir2.yahoo.com> No you can NOT I fear. How do you make sure that the AnnotatedType someone added doesn't get changed later? We have no whatever control over it. If some programmer like to make it mutable, well then it is that way and we have no chance to detect that :( Imo the only thing we can do is to point programmers to the fact that this is stupid -> non-portable behaviour. LieGrue, strub > On Monday, 22 December 2014, 9:29, Jozef Hartinger wrote: > > > On 12/21/2014 09:47 PM, Mark Struberg wrote: >> Hi! >> >> I just came across this little sentence in the spec >> >> >> >> 11.5.6 "If any ProcessAnnotatedType method is called outside of the > observer method invocation, an IllegalStateException is thrown." >> >> >> I don't believe such a limitation helps much. What about extensions who > do a setAnnotatedType and change this instance in a later phase? > Such as? >> We have no whatever chance to prevent this anyway. > We can prevent that by throwing the exception, rather than silently > ignoring that the extension is doing something wrong. > >> >> So why not just say that if a CDI System Event gets modified outside of the > method it gets injected into then non portable behaviour results. >> >> 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 rmannibucau at gmail.com Mon Dec 22 03:35:01 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 22 Dec 2014 09:35:01 +0100 Subject: [cdi-dev] TCK and spec question In-Reply-To: <675565509.45226.1419237224192.JavaMail.yahoo@jws11153.mail.ir2.yahoo.com> References: <5497D67D.4090005@redhat.com> <675565509.45226.1419237224192.JavaMail.yahoo@jws11153.mail.ir2.yahoo.com> Message-ID: you can only event it gets changed again...but actually if the user has such a limitation he will always change it then mutte the AT he set Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-12-22 9:33 GMT+01:00 Mark Struberg : > No you can NOT I fear. > > How do you make sure that the AnnotatedType someone added doesn't get changed later? We have no whatever control over it. If some programmer like to make it mutable, well then it is that way and we have no chance to detect that :( > Imo the only thing we can do is to point programmers to the fact that this is stupid -> non-portable behaviour. > > > LieGrue, > strub > > > > > >> On Monday, 22 December 2014, 9:29, Jozef Hartinger wrote: >> > >> On 12/21/2014 09:47 PM, Mark Struberg wrote: >>> Hi! >>> >>> I just came across this little sentence in the spec >>> >>> >>> >>> 11.5.6 "If any ProcessAnnotatedType method is called outside of the >> observer method invocation, an IllegalStateException is thrown." >>> >>> >>> I don't believe such a limitation helps much. What about extensions who >> do a setAnnotatedType and change this instance in a later phase? >> Such as? >>> We have no whatever chance to prevent this anyway. >> We can prevent that by throwing the exception, rather than silently >> ignoring that the extension is doing something wrong. >> >>> >>> So why not just say that if a CDI System Event gets modified outside of the >> method it gets injected into then non portable behaviour results. >>> >>> 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 jharting at redhat.com Mon Dec 22 03:41:57 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Mon, 22 Dec 2014 09:41:57 +0100 Subject: [cdi-dev] TCK and spec question In-Reply-To: <675565509.45226.1419237224192.JavaMail.yahoo@jws11153.mail.ir2.yahoo.com> References: <5497D67D.4090005@redhat.com> <675565509.45226.1419237224192.JavaMail.yahoo@jws11153.mail.ir2.yahoo.com> Message-ID: <5497D955.607@redhat.com> On 12/22/2014 09:33 AM, Mark Struberg wrote: > No you can NOT I fear. > > How do you make sure that the AnnotatedType someone added doesn't get changed later? We have no whatever control over it. If some programmer like to make it mutable, well then it is that way and we have no chance to detect that :( > Imo the only thing we can do is to point programmers to the fact that this is stupid -> non-portable behaviour. Correct. This is stupid. But allowing setAnnotatedType() to be called anytime does not help this at all. The fact that we throw the exception on setAnnotatedType() prevents a class of bad things from happening. At the same time it does not prevent the other one that you mentioned. The fact that we cannot prevent all of them does not mean that we should not try to prevent those we can. > > > LieGrue, > strub > > > > > >> On Monday, 22 December 2014, 9:29, Jozef Hartinger wrote: >> On 12/21/2014 09:47 PM, Mark Struberg wrote: >>> Hi! >>> >>> I just came across this little sentence in the spec >>> >>> >>> >>> 11.5.6 "If any ProcessAnnotatedType method is called outside of the >> observer method invocation, an IllegalStateException is thrown." >>> >>> I don't believe such a limitation helps much. What about extensions who >> do a setAnnotatedType and change this instance in a later phase? >> Such as? >>> We have no whatever chance to prevent this anyway. >> We can prevent that by throwing the exception, rather than silently >> ignoring that the extension is doing something wrong. >> >>> So why not just say that if a CDI System Event gets modified outside of the >> method it gets injected into then non portable behaviour results. >>> 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 jharting at redhat.com Mon Dec 22 03:44:03 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Mon, 22 Dec 2014 09:44:03 +0100 Subject: [cdi-dev] Ordering of AfterTypeDiscovery#getAlternatives() et al In-Reply-To: References: <1570974989.1030075.1419071217856.JavaMail.yahoo@jws11143.mail.ir2.yahoo.com> <5497D4EC.9040907@redhat.com> Message-ID: <5497D9D3.7080303@redhat.com> On 12/22/2014 09:24 AM, Romain Manni-Bucau wrote: > hi > > 2014-12-22 9:23 GMT+01:00 Jozef Hartinger : >> On 12/20/2014 11:26 AM, Mark Struberg wrote: >>> Hi! >>> >>> If I have a >>> >>> >>> @Priority(100) >>> public class MyAlternative implements Foo .. >>> >>> and >>> >>> >>> @Priority(101) >>> public class ABetterAlternative implements Foo .. >>> >>> >>> Then ABetterAlternative will finally be chosen. >>> >>> This ordering can be changed via AfterTypeDiscovery#getAlternatives(). >>> >>> But the spec only says "returns the ordered list of enabled alternatives for the application.." >>> >>> But it does NOT define in which sorting this list is ordered ;) >>> >>> In OWB we hat the 'most important' alternative come first. It seems in Weld it is the other way around. >> What sorting do you use for interceptors and decorators? > until yesterday the same as for runtime Why did you change that for interceptors and decorators? > >>> I have no problem with changing this in OWB, but I would like to get this clarified in our JavaDocs and spec. >> Agreed. Go ahead and file an issue. >>> 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 rmannibucau at gmail.com Mon Dec 22 03:45:31 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 22 Dec 2014 09:45:31 +0100 Subject: [cdi-dev] Ordering of AfterTypeDiscovery#getAlternatives() et al In-Reply-To: <5497D9D3.7080303@redhat.com> References: <1570974989.1030075.1419071217856.JavaMail.yahoo@jws11143.mail.ir2.yahoo.com> <5497D4EC.9040907@redhat.com> <5497D9D3.7080303@redhat.com> Message-ID: 2014-12-22 9:44 GMT+01:00 Jozef Hartinger : > > On 12/22/2014 09:24 AM, Romain Manni-Bucau wrote: >> >> hi >> >> 2014-12-22 9:23 GMT+01:00 Jozef Hartinger : >>> >>> On 12/20/2014 11:26 AM, Mark Struberg wrote: >>>> >>>> Hi! >>>> >>>> If I have a >>>> >>>> >>>> @Priority(100) >>>> public class MyAlternative implements Foo .. >>>> >>>> and >>>> >>>> >>>> @Priority(101) >>>> public class ABetterAlternative implements Foo .. >>>> >>>> >>>> Then ABetterAlternative will finally be chosen. >>>> >>>> This ordering can be changed via AfterTypeDiscovery#getAlternatives(). >>>> >>>> But the spec only says "returns the ordered list of enabled alternatives >>>> for the application.." >>>> >>>> But it does NOT define in which sorting this list is ordered ;) >>>> >>>> In OWB we hat the 'most important' alternative come first. It seems in >>>> Weld it is the other way around. >>> >>> What sorting do you use for interceptors and decorators? >> >> until yesterday the same as for runtime > > Why did you change that for interceptors and decorators? > made the TCK test passing basically. Can't ensure you I changed all orderings. Interceptor one - for the event - is not tested BTW >> >>>> I have no problem with changing this in OWB, but I would like to get >>>> this clarified in our JavaDocs and spec. >>> >>> Agreed. Go ahead and file an issue. >>>> >>>> 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 struberg at yahoo.de Mon Dec 22 03:49:21 2014 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 22 Dec 2014 08:49:21 +0000 (UTC) Subject: [cdi-dev] TCK and spec question In-Reply-To: <5497D955.607@redhat.com> References: <5497D955.607@redhat.com> Message-ID: <41726295.51747.1419238161646.JavaMail.yahoo@jws11153.mail.ir2.yahoo.com> well, it's just the tip of the iceberg. It would be way easier to just define any 'modification' as non-portable. That would be much more precise and easier as well. And really covers al the edge cases as well. LieGrue, strub > On Monday, 22 December 2014, 9:42, Jozef Hartinger wrote: > > > On 12/22/2014 09:33 AM, Mark Struberg wrote: >> No you can NOT I fear. >> >> How do you make sure that the AnnotatedType someone added doesn't get > changed later? We have no whatever control over it. If some programmer like to > make it mutable, well then it is that way and we have no chance to detect that > :( >> Imo the only thing we can do is to point programmers to the fact that this > is stupid -> non-portable behaviour. > Correct. This is stupid. But allowing setAnnotatedType() to be called > anytime does not help this at all. > > The fact that we throw the exception on setAnnotatedType() prevents a > class of bad things from happening. At the same time it does not prevent > the other one that you mentioned. The fact that we cannot prevent all of > them does not mean that we should not try to prevent those we can. > >> >> >> LieGrue, >> strub >> >> >> >> >> >>> On Monday, 22 December 2014, 9:29, Jozef Hartinger > wrote: >>> On 12/21/2014 09:47 PM, Mark Struberg wrote: >>>> Hi! >>>> >>>> I just came across this little sentence in the spec >>>> >>>> >>>> >>>> 11.5.6 "If any ProcessAnnotatedType method is called outside > of the >>> observer method invocation, an IllegalStateException is thrown." >>>> >>>> I don't believe such a limitation helps much. What about > extensions who >>> do a setAnnotatedType and change this instance in a later phase? >>> Such as? >>>> We have no whatever chance to prevent this anyway. >>> We can prevent that by throwing the exception, rather than silently >>> ignoring that the extension is doing something wrong. >>> >>>> So why not just say that if a CDI System Event gets modified > outside of the >>> method it gets injected into then non portable behaviour results. >>>> 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 mkouba at redhat.com Mon Dec 22 03:52:14 2014 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 22 Dec 2014 09:52:14 +0100 Subject: [cdi-dev] Ordering of AfterTypeDiscovery#getAlternatives() et al In-Reply-To: <5497D4EC.9040907@redhat.com> References: <1570974989.1030075.1419071217856.JavaMail.yahoo@jws11143.mail.ir2.yahoo.com> <5497D4EC.9040907@redhat.com> Message-ID: <5497DBBE.4070302@redhat.com> The issue already exists for a long time ;) https://issues.jboss.org/browse/CDI-434?focusedCommentId=12963824&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12963824 And this is also related: https://issues.jboss.org/browse/CDI-437 M Dne 22.12.2014 v 09:23 Jozef Hartinger napsal(a): > > On 12/20/2014 11:26 AM, Mark Struberg wrote: >> Hi! >> >> If I have a >> >> >> @Priority(100) >> public class MyAlternative implements Foo .. >> >> and >> >> >> @Priority(101) >> public class ABetterAlternative implements Foo .. >> >> >> Then ABetterAlternative will finally be chosen. >> >> This ordering can be changed via AfterTypeDiscovery#getAlternatives(). >> >> But the spec only says "returns the ordered list of enabled alternatives for the application.." >> >> But it does NOT define in which sorting this list is ordered ;) >> >> In OWB we hat the 'most important' alternative come first. It seems in Weld it is the other way around. > What sorting do you use for interceptors and decorators? >> >> I have no problem with changing this in OWB, but I would like to get this clarified in our JavaDocs and spec. > Agreed. Go ahead and file an issue. >> >> 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 rmannibucau at gmail.com Mon Dec 22 03:53:00 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 22 Dec 2014 09:53:00 +0100 Subject: [cdi-dev] TCK and spec question In-Reply-To: <41726295.51747.1419238161646.JavaMail.yahoo@jws11153.mail.ir2.yahoo.com> References: <5497D955.607@redhat.com> <41726295.51747.1419238161646.JavaMail.yahoo@jws11153.mail.ir2.yahoo.com> Message-ID: +1 Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-12-22 9:49 GMT+01:00 Mark Struberg : > well, it's just the tip of the iceberg. It would be way easier to just define any 'modification' as non-portable. That would be much more precise and easier as well. And really covers al the edge cases as well. > > LieGrue, > strub > > > > > >> On Monday, 22 December 2014, 9:42, Jozef Hartinger wrote: >> > >> On 12/22/2014 09:33 AM, Mark Struberg wrote: >>> No you can NOT I fear. >>> >>> How do you make sure that the AnnotatedType someone added doesn't get >> changed later? We have no whatever control over it. If some programmer like to >> make it mutable, well then it is that way and we have no chance to detect that >> :( >>> Imo the only thing we can do is to point programmers to the fact that this >> is stupid -> non-portable behaviour. >> Correct. This is stupid. But allowing setAnnotatedType() to be called >> anytime does not help this at all. >> >> The fact that we throw the exception on setAnnotatedType() prevents a >> class of bad things from happening. At the same time it does not prevent >> the other one that you mentioned. The fact that we cannot prevent all of >> them does not mean that we should not try to prevent those we can. >> >>> >>> >>> LieGrue, >>> strub >>> >>> >>> >>> >>> >>>> On Monday, 22 December 2014, 9:29, Jozef Hartinger >> wrote: >>>> On 12/21/2014 09:47 PM, Mark Struberg wrote: >>>>> Hi! >>>>> >>>>> I just came across this little sentence in the spec >>>>> >>>>> >>>>> >>>>> 11.5.6 "If any ProcessAnnotatedType method is called outside >> of the >>>> observer method invocation, an IllegalStateException is thrown." >>>>> >>>>> I don't believe such a limitation helps much. What about >> extensions who >>>> do a setAnnotatedType and change this instance in a later phase? >>>> Such as? >>>>> We have no whatever chance to prevent this anyway. >>>> We can prevent that by throwing the exception, rather than silently >>>> ignoring that the extension is doing something wrong. >>>> >>>>> So why not just say that if a CDI System Event gets modified >> outside of the >>>> method it gets injected into then non portable behaviour results. >>>>> 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 jharting at redhat.com Mon Dec 22 03:56:04 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Mon, 22 Dec 2014 09:56:04 +0100 Subject: [cdi-dev] TCK and spec question In-Reply-To: <41726295.51747.1419238161646.JavaMail.yahoo@jws11153.mail.ir2.yahoo.com> References: <5497D955.607@redhat.com> <41726295.51747.1419238161646.JavaMail.yahoo@jws11153.mail.ir2.yahoo.com> Message-ID: <5497DCA4.6080807@redhat.com> Yes, we should explicitly define those other cases as non-portable if it has not been done yet. On 12/22/2014 09:49 AM, Mark Struberg wrote: > well, it's just the tip of the iceberg. It would be way easier to just define any 'modification' as non-portable. That would be much more precise and easier as well. And really covers al the edge cases as well. > > LieGrue, > strub > > > > > >> On Monday, 22 December 2014, 9:42, Jozef Hartinger wrote: >> On 12/22/2014 09:33 AM, Mark Struberg wrote: >>> No you can NOT I fear. >>> >>> How do you make sure that the AnnotatedType someone added doesn't get >> changed later? We have no whatever control over it. If some programmer like to >> make it mutable, well then it is that way and we have no chance to detect that >> :( >>> Imo the only thing we can do is to point programmers to the fact that this >> is stupid -> non-portable behaviour. >> Correct. This is stupid. But allowing setAnnotatedType() to be called >> anytime does not help this at all. >> >> The fact that we throw the exception on setAnnotatedType() prevents a >> class of bad things from happening. At the same time it does not prevent >> the other one that you mentioned. The fact that we cannot prevent all of >> them does not mean that we should not try to prevent those we can. >> >>> >>> LieGrue, >>> strub >>> >>> >>> >>> >>> >>>> On Monday, 22 December 2014, 9:29, Jozef Hartinger >> wrote: >>>> On 12/21/2014 09:47 PM, Mark Struberg wrote: >>>>> Hi! >>>>> >>>>> I just came across this little sentence in the spec >>>>> >>>>> >>>>> >>>>> 11.5.6 "If any ProcessAnnotatedType method is called outside >> of the >>>> observer method invocation, an IllegalStateException is thrown." >>>>> I don't believe such a limitation helps much. What about >> extensions who >>>> do a setAnnotatedType and change this instance in a later phase? >>>> Such as? >>>>> We have no whatever chance to prevent this anyway. >>>> We can prevent that by throwing the exception, rather than silently >>>> ignoring that the extension is doing something wrong. >>>> >>>>> So why not just say that if a CDI System Event gets modified >> outside of the >>>> method it gets injected into then non portable behaviour results. >>>>> 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 Mon Dec 22 03:59:07 2014 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 22 Dec 2014 08:59:07 +0000 (UTC) Subject: [cdi-dev] TCK and spec question In-Reply-To: <5497DCA4.6080807@redhat.com> References: <5497DCA4.6080807@redhat.com> Message-ID: <1829956508.56346.1419238747850.JavaMail.yahoo@jws11107.mail.ir2.yahoo.com> While we are at it: This is actually true for ALL System Events, right? So we should not define it in PAT but somewhere more general imo. LieGrue, strub > On Monday, 22 December 2014, 9:56, Jozef Hartinger wrote: > > Yes, we should explicitly define those other cases as non-portable if it > has not been done yet. > > On 12/22/2014 09:49 AM, Mark Struberg wrote: >> well, it's just the tip of the iceberg. It would be way easier to just > define any 'modification' as non-portable. That would be much more > precise and easier as well. And really covers al the edge cases as well. >> >> LieGrue, >> strub >> >> >> >> >> >>> On Monday, 22 December 2014, 9:42, Jozef Hartinger > wrote: >>> On 12/22/2014 09:33 AM, Mark Struberg wrote: >>>> No you can NOT I fear. >>>> >>>> How do you make sure that the AnnotatedType someone added > doesn't get >>> changed later? We have no whatever control over it. If some programmer > like to >>> make it mutable, well then it is that way and we have no chance to > detect that >>> :( >>>> Imo the only thing we can do is to point programmers to the fact > that this >>> is stupid -> non-portable behaviour. >>> Correct. This is stupid. But allowing setAnnotatedType() to be called >>> anytime does not help this at all. >>> >>> The fact that we throw the exception on setAnnotatedType() prevents a >>> class of bad things from happening. At the same time it does not > prevent >>> the other one that you mentioned. The fact that we cannot prevent all > of >>> them does not mean that we should not try to prevent those we can. >>> >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> >>>> >>>> >>>>> On Monday, 22 December 2014, 9:29, Jozef Hartinger >>> wrote: >>>>> On 12/21/2014 09:47 PM, Mark Struberg wrote: >>>>>> Hi! >>>>>> >>>>>> I just came across this little sentence in the spec >>>>>> >>>>>> >>>>>> >>>>>> 11.5.6 "If any ProcessAnnotatedType method is > called outside >>> of the >>>>> observer method invocation, an IllegalStateException is > thrown." >>>>>> I don't believe such a limitation helps much. What > about >>> extensions who >>>>> do a setAnnotatedType and change this instance in a later > phase? >>>>> Such as? >>>>>> We have no whatever chance to prevent this anyway. >>>>> We can prevent that by throwing the exception, rather than > silently >>>>> ignoring that the extension is doing something wrong. >>>>> >>>>>> So why not just say that if a CDI System Event gets > modified >>> outside of the >>>>> method it gets injected into then non portable behaviour > results. >>>>>> 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 jharting at redhat.com Mon Dec 22 03:59:52 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Mon, 22 Dec 2014 09:59:52 +0100 Subject: [cdi-dev] TCK and spec question In-Reply-To: <1829956508.56346.1419238747850.JavaMail.yahoo@jws11107.mail.ir2.yahoo.com> References: <5497DCA4.6080807@redhat.com> <1829956508.56346.1419238747850.JavaMail.yahoo@jws11107.mail.ir2.yahoo.com> Message-ID: <5497DD88.1000900@redhat.com> Correct. On 12/22/2014 09:59 AM, Mark Struberg wrote: > While we are at it: This is actually true for ALL System Events, right? > So we should not define it in PAT but somewhere more general imo. > > LieGrue, > strub > > > > > >> On Monday, 22 December 2014, 9:56, Jozef Hartinger wrote: >>> Yes, we should explicitly define those other cases as non-portable if it >> has not been done yet. >> >> On 12/22/2014 09:49 AM, Mark Struberg wrote: >>> well, it's just the tip of the iceberg. It would be way easier to just >> define any 'modification' as non-portable. That would be much more >> precise and easier as well. And really covers al the edge cases as well. >>> LieGrue, >>> strub >>> >>> >>> >>> >>> >>>> On Monday, 22 December 2014, 9:42, Jozef Hartinger >> wrote: >>>> On 12/22/2014 09:33 AM, Mark Struberg wrote: >>>>> No you can NOT I fear. >>>>> >>>>> How do you make sure that the AnnotatedType someone added >> doesn't get >>>> changed later? We have no whatever control over it. If some programmer >> like to >>>> make it mutable, well then it is that way and we have no chance to >> detect that >>>> :( >>>>> Imo the only thing we can do is to point programmers to the fact >> that this >>>> is stupid -> non-portable behaviour. >>>> Correct. This is stupid. But allowing setAnnotatedType() to be called >>>> anytime does not help this at all. >>>> >>>> The fact that we throw the exception on setAnnotatedType() prevents a >>>> class of bad things from happening. At the same time it does not >> prevent >>>> the other one that you mentioned. The fact that we cannot prevent all >> of >>>> them does not mean that we should not try to prevent those we can. >>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> On Monday, 22 December 2014, 9:29, Jozef Hartinger >>>> wrote: >>>>>> On 12/21/2014 09:47 PM, Mark Struberg wrote: >>>>>>> Hi! >>>>>>> >>>>>>> I just came across this little sentence in the spec >>>>>>> >>>>>>> >>>>>>> >>>>>>> 11.5.6 "If any ProcessAnnotatedType method is >> called outside >>>> of the >>>>>> observer method invocation, an IllegalStateException is >> thrown." >>>>>>> I don't believe such a limitation helps much. What >> about >>>> extensions who >>>>>> do a setAnnotatedType and change this instance in a later >> phase? >>>>>> Such as? >>>>>>> We have no whatever chance to prevent this anyway. >>>>>> We can prevent that by throwing the exception, rather than >> silently >>>>>> ignoring that the extension is doing something wrong. >>>>>> >>>>>>> So why not just say that if a CDI System Event gets >> modified >>>> outside of the >>>>>> method it gets injected into then non portable behaviour >> results. >>>>>>> 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 Mon Dec 22 04:00:35 2014 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 22 Dec 2014 09:00:35 +0000 (UTC) Subject: [cdi-dev] Ordering of AfterTypeDiscovery#getAlternatives() et al In-Reply-To: <5497DBBE.4070302@redhat.com> References: <5497DBBE.4070302@redhat.com> Message-ID: <975409738.55077.1419238835905.JavaMail.yahoo@jws11142.mail.ir2.yahoo.com> Agree, we should think about that again for CDI-2.0. But I did not find an easy and backward compatible solution right now. Still waiting for an idea to struck me ;) LieGrue, strub > On Monday, 22 December 2014, 9:52, Martin Kouba wrote: > >T he issue already exists for a long time ;) > > https://issues.jboss.org/browse/CDI-434?focusedCommentId=12963824&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12963824 > > And this is also related: https://issues.jboss.org/browse/CDI-437 > > M > > Dne 22.12.2014 v 09:23 Jozef Hartinger napsal(a): >> >> On 12/20/2014 11:26 AM, Mark Struberg wrote: >>> Hi! >>> >>> If I have a >>> >>> >>> @Priority(100) >>> public class MyAlternative implements Foo .. >>> >>> and >>> >>> >>> @Priority(101) >>> public class ABetterAlternative implements Foo .. >>> >>> >>> Then ABetterAlternative will finally be chosen. >>> >>> This ordering can be changed via AfterTypeDiscovery#getAlternatives(). >>> >>> But the spec only says "returns the ordered list of enabled > alternatives for the application.." >>> >>> But it does NOT define in which sorting this list is ordered ;) >>> >>> In OWB we hat the 'most important' alternative come first. It > seems in Weld it is the other way around. >> What sorting do you use for interceptors and decorators? >>> >>> I have no problem with changing this in OWB, but I would like to get > this clarified in our JavaDocs and spec. >> Agreed. Go ahead and file an issue. >>> >>> 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 rmannibucau at gmail.com Mon Dec 22 04:04:24 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 22 Dec 2014 10:04:24 +0100 Subject: [cdi-dev] Ordering of AfterTypeDiscovery#getAlternatives() et al In-Reply-To: <975409738.55077.1419238835905.JavaMail.yahoo@jws11142.mail.ir2.yahoo.com> References: <5497DBBE.4070302@redhat.com> <975409738.55077.1419238835905.JavaMail.yahoo@jws11142.mail.ir2.yahoo.com> Message-ID: wrap the list and provide getHighest(index) etc?. extending List we can be compatible. Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-12-22 10:00 GMT+01:00 Mark Struberg : > Agree, we should think about that again for CDI-2.0. But I did not find an easy and backward compatible solution right now. Still waiting for an idea to struck me ;) > > LieGrue, > strub > > > > > >> On Monday, 22 December 2014, 9:52, Martin Kouba wrote: >> >T he issue already exists for a long time ;) >> >> https://issues.jboss.org/browse/CDI-434?focusedCommentId=12963824&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12963824 >> >> And this is also related: https://issues.jboss.org/browse/CDI-437 >> >> M >> >> Dne 22.12.2014 v 09:23 Jozef Hartinger napsal(a): >>> >>> On 12/20/2014 11:26 AM, Mark Struberg wrote: >>>> Hi! >>>> >>>> If I have a >>>> >>>> >>>> @Priority(100) >>>> public class MyAlternative implements Foo .. >>>> >>>> and >>>> >>>> >>>> @Priority(101) >>>> public class ABetterAlternative implements Foo .. >>>> >>>> >>>> Then ABetterAlternative will finally be chosen. >>>> >>>> This ordering can be changed via AfterTypeDiscovery#getAlternatives(). >>>> >>>> But the spec only says "returns the ordered list of enabled >> alternatives for the application.." >>>> >>>> But it does NOT define in which sorting this list is ordered ;) >>>> >>>> In OWB we hat the 'most important' alternative come first. It >> seems in Weld it is the other way around. >>> What sorting do you use for interceptors and decorators? >>>> >>>> I have no problem with changing this in OWB, but I would like to get >> this clarified in our JavaDocs and spec. >>> Agreed. Go ahead and file an issue. >>>> >>>> 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. >>> >> > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From issues at jboss.org Mon Dec 22 05:12:29 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 22 Dec 2014 05:12:29 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-495) What happens if an illegal bean type is found in the set of bean types In-Reply-To: References: Message-ID: Martin Kouba created CDI-495: -------------------------------- Summary: What happens if an illegal bean type is found in the set of bean types Key: CDI-495 URL: https://issues.jboss.org/browse/CDI-495 Project: CDI Specification Issues Issue Type: Clarification Affects Versions: 1.2.Final Reporter: Martin Kouba The spec clearly defines what the legal bean types are (2.2.1. Legal bean types). and also that an illegal injection point type results in definition error (5.2.3. Legal injection point types). However, it's not clear what should happen if an illegal bean type is found in the set of bean types and is not used in an injection point. I think that it would be reasonable to just ignore the type (and possibly log some warning). -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Dec 22 05:13:29 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 22 Dec 2014 05:13:29 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-495) What happens if an illegal bean type is found in the set of bean types In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-495: ----------------------------- Description: The spec clearly defines what the legal bean types are (2.2.1. Legal bean types). and also that an illegal injection point type results in definition error (5.2.3. Legal injection point types). However, it's not clear what should happen if an illegal bean type is found in the set of bean types and *is not used* in an injection point. I think that it would be reasonable to just ignore the type (and possibly log some warning). (was: The spec clearly defines what the legal bean types are (2.2.1. Legal bean types). and also that an illegal injection point type results in definition error (5.2.3. Legal injection point types). However, it's not clear what should happen if an illegal bean type is found in the set of bean types and is not used in an injection point. I think that it would be reasonable to just ignore the type (and possibly log some warning).) > What happens if an illegal bean type is found in the set of bean types > ---------------------------------------------------------------------- > > Key: CDI-495 > URL: https://issues.jboss.org/browse/CDI-495 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > > The spec clearly defines what the legal bean types are (2.2.1. Legal bean types). and also that an illegal injection point type results in definition error (5.2.3. Legal injection point types). However, it's not clear what should happen if an illegal bean type is found in the set of bean types and *is not used* in an injection point. I think that it would be reasonable to just ignore the type (and possibly log some warning). -- This message was sent by Atlassian JIRA (v6.3.11#6341) From mkouba at redhat.com Mon Dec 22 07:26:29 2014 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 22 Dec 2014 13:26:29 +0100 Subject: [cdi-dev] @Alternative without extends or implements? In-Reply-To: <1961725612.1034023.1419070568514.JavaMail.yahoo@jws11138.mail.ir2.yahoo.com> References: <1961725612.1034023.1419070568514.JavaMail.yahoo@jws11138.mail.ir2.yahoo.com> Message-ID: <54980DF5.8090205@redhat.com> Yes, it does not make much sense. Yet it's legal and should work. So feel free to create a new TCK Enhancement issue... M Dne 20.12.2014 v 11:16 Mark Struberg napsal(a): > Hi! > > Some TCK tests have @Alternative classes which neither extend nor implement a class. > > Of course they explicitly extend Object.class, but that does not really make sense, doesn't it? > > > 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 Mon Dec 22 07:36:44 2014 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 22 Dec 2014 12:36:44 +0000 (UTC) Subject: [cdi-dev] Ordering of AfterTypeDiscovery#getAlternatives() et al In-Reply-To: <5497D9D3.7080303@redhat.com> References: <5497D9D3.7080303@redhat.com> Message-ID: <101161120.171272.1419251804611.JavaMail.yahoo@jws11160.mail.ir2.yahoo.com> > Why did you change that for interceptors and decorators? Oh that's totally fine. Remember that the ordering in the list defines the ordering of the invocation. An if someone would re-sort that list then he must know if it is ascending or descending. LieGrue, strub > On Monday, 22 December 2014, 10:42, Jozef Hartinger wrote: > > > On 12/22/2014 09:24 AM, Romain Manni-Bucau wrote: >> hi >> >> 2014-12-22 9:23 GMT+01:00 Jozef Hartinger : >>> On 12/20/2014 11:26 AM, Mark Struberg wrote: >>>> Hi! >>>> >>>> If I have a >>>> >>>> >>>> @Priority(100) >>>> public class MyAlternative implements Foo .. >>>> >>>> and >>>> >>>> >>>> @Priority(101) >>>> public class ABetterAlternative implements Foo .. >>>> >>>> >>>> Then ABetterAlternative will finally be chosen. >>>> >>>> This ordering can be changed via > AfterTypeDiscovery#getAlternatives(). >>>> >>>> But the spec only says "returns the ordered list of enabled > alternatives for the application.." >>>> >>>> But it does NOT define in which sorting this list is ordered ;) >>>> >>>> In OWB we hat the 'most important' alternative come first. > It seems in Weld it is the other way around. >>> What sorting do you use for interceptors and decorators? >> until yesterday the same as for runtime > Why did you change that for interceptors and decorators? > >> >>>> I have no problem with changing this in OWB, but I would like to > get this clarified in our JavaDocs and spec. >>> Agreed. Go ahead and file an issue. >>>> 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 antoine at sabot-durand.net Mon Dec 22 12:35:37 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 22 Dec 2014 18:35:37 +0100 Subject: [cdi-dev] Next meeting on wed 7 jan 2015 Message-ID: <1B250F8E-8EC6-440B-952A-61EA82B61BEB@sabot-durand.net> Hi all, Most of us will be on holiday in the coming 2 weeks. So I propose we set the newt IRC meeting in 2015. Wish you best for this end of year. 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/20141222/d1831a59/attachment.bin From antonio.goncalves at gmail.com Mon Dec 22 12:49:56 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Mon, 22 Dec 2014 18:49:56 +0100 Subject: [cdi-dev] Thoughts on Phases and Events for the Security spec Message-ID: Hi all, The CDI spec defines the "Transactional observer methods" (?10.4.5) with a TransactionPhase : public enum TransactionPhase { IN_PROGRESS, BEFORE_COMPLETION, AFTER_COMPLETION, AFTER_FAILURE, AFTER_SUCCESS } void onDocumentUpdate(@Observes(*during=AFTER_SUCCESS*) @Updated Document doc) { ... } Now that there is a new Security specification coming along, it would be helpful to be able to *observe before/after the user logs-in or logs-out*, for example. First I thought "well, the Security spec defines a set of events, fires them, and we just have to observe them". But what about the "during" phase ? What would make more sense in such use case ? Using the same "during" mechanism or events ? public enum LoginPhase { BEFORE_LOGIN, AFTER_LOGIN, BEFORE_LOGOUT, AFTER_LOGOUT, } void onLogout(@Observes(*during=BEFORE_LOGOUT*) User user) { ... } Any thoughts ? -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141222/acc245d4/attachment.html From struberg at yahoo.de Mon Dec 22 12:58:47 2014 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 22 Dec 2014 17:58:47 +0000 (UTC) Subject: [cdi-dev] Possible cycle with ProcessBeanAttributes only for enabled beans Message-ID: <1814799008.327138.1419271127269.JavaMail.yahoo@jws11175.mail.ir2.yahoo.com> The JavaDoc of ProcessBeanAttributes defines that ProcessBeanAttributes must only get fired for ENABLED beans: "The container fires an event of this type for each enabled bean, interceptor or decorator deployed in a bean archive before registering the Bean object." The test org.jboss.cdi.tck.tests.extensions.lifecycle.processBeanAttributes.specialization.SpecializationTest has a nice example @Specializes class Charly extends -> @Specializes class Bravo extends -> class Alpha Which ProcessBeanAttributes events would you except to get fired? *) Alpha? No, because it's specialized away (5.1.2. Enabled and disabled beans). *) Bravo? No, because it's specialized away as well, right? *) Charly? Yes, because that's the only _enabled_ bean! So far, so clear. But now comes the tricky part! This test also has an Extension which observes ProcessBeanAttributes and disables Charly. This means that finally Bravo is enabled, Charly disabled (is there actually a difference btw disabled and vetoed spec wording wise?) The problem is now that we only know this AFTER the ProcessBeanAttributes for Charly got fired. And this introduces an ordering issue: If the BeanAttributes for Bravo gets scanned BEFORE the ones of Charly, then we do not know YET that Charly will get disabled. Thus we fire the ProcessBeanAttributes for Bravo as well. But as we know that should not happen! Otoh if Charly gets scanned first, then Bravo will not get processed. Can you follow me? LieGrue, strub From arjan.tijms at gmail.com Mon Dec 22 14:11:32 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Mon, 22 Dec 2014 20:11:32 +0100 Subject: [cdi-dev] Thoughts on Phases and Events for the Security spec In-Reply-To: References: Message-ID: Hi, On Monday, December 22, 2014, Antonio Goncalves > wrote: > Hi all, > > The CDI spec defines the "Transactional observer methods" (?10.4.5) with a > TransactionPhase : > > public enum TransactionPhase { > IN_PROGRESS, > BEFORE_COMPLETION, > AFTER_COMPLETION, > AFTER_FAILURE, > AFTER_SUCCESS > } > > void onDocumentUpdate(@Observes(*during=AFTER_SUCCESS*) @Updated Document > doc) { ... } > > > Now that there is a new Security specification coming along, it would be > helpful to be able to *observe before/after the user logs-in or logs-out*, > for example. First I thought "well, the Security spec defines a set of > events, fires them, and we just have to observe them". But what about the > "during" phase ? What would make more sense in such use case ? Using the > same "during" mechanism or events ? > I think separate events may be better. Maybe I'm mistaken but the way I think the transactional events are used is that during a transactional method an event is fired. The event is then not delivered right away to all observers, but for those using during=after_success only when the TX commits. This is kinda like what JMS does; a message is only send when the TX commits, or send right away. CDI offers 3 other cases, but I feel that those first two are the main ones. For authentication events I don't think we can really speak of a "logging-in" method. Even if we would appoint one (e.g. validateRequest() in a SAM) then I'm not sure whether any random event published during that method would have any need to be queued until just before or after authentication actually happens. Instead, we would merely be interested in the actual events; the moment the container is about to authenticate (so we can potentially veto) and the moment right after that (so we can take an action such as loading data related to the user into the current session). Just my 2 cents. Hope I understood the case correctly. Kind regards, Arjan > > public enum LoginPhase { > BEFORE_LOGIN, > AFTER_LOGIN, > BEFORE_LOGOUT, > AFTER_LOGOUT, > } > > void onLogout(@Observes(*during=BEFORE_LOGOUT*) User user) { ... } > > > Any thoughts ? > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter > | LinkedIn > | Pluralsight > | Paris > JUG | Devoxx France > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141222/0e2f7b60/attachment-0001.html From struberg at yahoo.de Mon Dec 22 14:54:42 2014 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 22 Dec 2014 19:54:42 +0000 (UTC) Subject: [cdi-dev] Thoughts on Phases and Events for the Security spec In-Reply-To: References: Message-ID: <1763093679.219526.1419278082146.JavaMail.yahoo@jws11101g.mail.ir2.yahoo.com> To be honest I'm not sure if I'd do any of this. All this should imo not belong to the EE spec at all. It is probably just far too business specific. What if the application needs some kind of role change. E.g. you temporarily switch roles, change the preferred language, etc? All these things are heavily depending on the application and are not technical at all. LieGrue, strub On Monday, 22 December 2014, 20:12, arjan tijms wrote: > > >Hi, > >On Monday, December 22, 2014, Antonio Goncalves wrote: > >Hi all, >> >> >> >>The CDI spec defines the "Transactional observer methods" (?10.4.5) with a TransactionPhase : >> >> >>public enum TransactionPhase { >> IN_PROGRESS, >> BEFORE_COMPLETION, >> AFTER_COMPLETION, >> AFTER_FAILURE, >> AFTER_SUCCESS >>} >> >> >>void onDocumentUpdate(@Observes(during=AFTER_SUCCESS) @Updated Document doc) { ... } >> >> >> >> >>Now that there is a new Security specification coming along, it would be helpful to be able to observe before/after the user logs-in or logs-out, for example. First I thought "well, the Security spec defines a set of events, fires them, and we just have to observe them". But what about the "during" phase ? What would make more sense in such use case ? Using the same "during" mechanism or events ? > > >I think separate events may be better. > > >Maybe I'm mistaken but the way I think the transactional events are used is that during a transactional method an event is fired. The event is then not delivered right away to all observers, but for those using during=after_success only when the TX commits. This is kinda like what JMS does; a message is only send when the TX commits, or send right away. CDI offers 3 other cases, but I feel that those first two are the main ones. > > >For authentication events I don't think we can really speak of a "logging-in" method. Even if we would appoint one (e.g. validateRequest() in a SAM) then I'm not sure whether any random event published during that method would have any need to be queued until just before or after authentication actually happens. > > >Instead, we would merely be interested in the actual events; the moment the container is about to authenticate (so we can potentially veto) and the moment right after that (so we can take an action such as loading data related to the user into the current session). > > >Just my 2 cents. Hope I understood the case correctly. > > >Kind regards, >Arjan > > > > > > >> >>public enum LoginPhase { >> BEFORE_LOGIN, >> AFTER_LOGIN, >> BEFORE_LOGOUT, >> AFTER_LOGOUT, >>} >> >> >>void onLogout(@Observes(during=BEFORE_LOGOUT) User user) { ... } >> >> >> >> >>Any thoughts ? >> >>-- >> >>Antonio Goncalves >>Software architect, Java Champion and Pluralsight author >> >>Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France > >_______________________________________________ >cdi-dev mailing list >cdi-dev at lists.jboss.org >https://lists.jboss.org/mailman/listinfo/cdi-dev > >Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > From arjan.tijms at gmail.com Mon Dec 22 15:57:03 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Mon, 22 Dec 2014 21:57:03 +0100 Subject: [cdi-dev] Thoughts on Phases and Events for the Security spec In-Reply-To: <1763093679.219526.1419278082146.JavaMail.yahoo@jws11101g.mail.ir2.yahoo.com> References: <1763093679.219526.1419278082146.JavaMail.yahoo@jws11101g.mail.ir2.yahoo.com> Message-ID: Hi, On Mon, Dec 22, 2014 at 8:54 PM, Mark Struberg wrote: > To be honest I'm not sure if I'd do any of this. All this should imo not belong to the EE spec at all. It is probably just far too business specific. What exactly should not be done? Authentication events, or the enumeration Antonio mentioned? > What if the application needs some kind of role change. E.g. you temporarily switch roles, change the preferred language, etc? All these things are heavily depending on the application and are not technical at all. I'm not sure what the preferred language has to do with this. This is not an authentication concern, but simply a user preference and indeed an application concern. Switching roles however is an authentication concern. It's IMHO not business specific. There are two variations, a temporarily one as you mention, and a "permanent" one (permanent within a session, or as authentication in Java EE is by default per request, even do this for just the remainder of the request). The temporary one can be implemented via authentication stacks, and this can definitely be implemented in a completely non business specific way. In a declarative way @RunAs already does this in a way. A programmatic API could look like the following: request.authenticateStacked(); // Starts new authentication dialog, if authenticated previous identity is stored on stack request.authenticateStackedAs(String username); // Programmatic equivalent of @RunAs request.authenticateStacked(Callback... callbacks); // Generic variant, supporting extendible options such as adding/removing roles request.logoutCurrent(); // logs out current user, goes back one level on the stack request.logout(); // existing API, totally logs user out A "permanent" change is typical when for instance a username is linked to a user email, and the user changes his email. The act of changing this email is application specific, but just signaling this change to the container is a general action (see https://java.net/jira/browse/JASPIC_SPEC-22). Events can be largely orthogonal to all of this, although perhaps some properties of the event could give information about the authenticate type (new one, or stacked one). Kind regards, Arjan Tijms > > LieGrue, > strub > > > > On Monday, 22 December 2014, 20:12, arjan tijms wrote: > > >> >> >>Hi, >> >>On Monday, December 22, 2014, Antonio Goncalves wrote: >> >>Hi all, >>> >>> >>> >>>The CDI spec defines the "Transactional observer methods" (?10.4.5) with a TransactionPhase : >>> >>> >>>public enum TransactionPhase { >>> IN_PROGRESS, >>> BEFORE_COMPLETION, >>> AFTER_COMPLETION, >>> AFTER_FAILURE, >>> AFTER_SUCCESS >>>} >>> >>> >>>void onDocumentUpdate(@Observes(during=AFTER_SUCCESS) @Updated Document doc) { ... } >>> >>> >>> >>> >>>Now that there is a new Security specification coming along, it would be helpful to be able to observe before/after the user logs-in or logs-out, for example. First I thought "well, the Security spec defines a set of events, fires them, and we just have to observe them". But what about the "during" phase ? What would make more sense in such use case ? Using the same "during" mechanism or events ? >> >> >>I think separate events may be better. >> >> >>Maybe I'm mistaken but the way I think the transactional events are used is that during a transactional method an event is fired. The event is then not delivered right away to all observers, but for those using during=after_success only when the TX commits. This is kinda like what JMS does; a message is only send when the TX commits, or send right away. CDI offers 3 other cases, but I feel that those first two are the main ones. >> >> >>For authentication events I don't think we can really speak of a "logging-in" method. Even if we would appoint one (e.g. validateRequest() in a SAM) then I'm not sure whether any random event published during that method would have any need to be queued until just before or after authentication actually happens. >> >> >>Instead, we would merely be interested in the actual events; the moment the container is about to authenticate (so we can potentially veto) and the moment right after that (so we can take an action such as loading data related to the user into the current session). >> >> >>Just my 2 cents. Hope I understood the case correctly. >> >> >>Kind regards, >>Arjan >> >> >> >> >> >> >>> >>>public enum LoginPhase { >>> BEFORE_LOGIN, >>> AFTER_LOGIN, >>> BEFORE_LOGOUT, >>> AFTER_LOGOUT, >>>} >>> >>> >>>void onLogout(@Observes(during=BEFORE_LOGOUT) User user) { ... } >>> >>> >>> >>> >>>Any thoughts ? >>> >>>-- >>> >>>Antonio Goncalves >>>Software architect, Java Champion and Pluralsight author >>> >>>Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France >> >>_______________________________________________ >>cdi-dev mailing list >>cdi-dev at lists.jboss.org >>https://lists.jboss.org/mailman/listinfo/cdi-dev >> >>Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> >> From antoine at sabot-durand.net Tue Dec 23 03:17:04 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 23 Dec 2014 09:17:04 +0100 Subject: [cdi-dev] TCK and spec question In-Reply-To: <1829956508.56346.1419238747850.JavaMail.yahoo@jws11107.mail.ir2.yahoo.com> References: <5497DCA4.6080807@redhat.com> <1829956508.56346.1419238747850.JavaMail.yahoo@jws11107.mail.ir2.yahoo.com> Message-ID: <1228284F-15AE-4363-91DD-E28FB865ACF1@sabot-durand.net> Mark, Could you add a ticket for that. Antoine Sabot-Durand > Le 22 d?c. 2014 ? 09:59, Mark Struberg a ?crit : > > While we are at it: This is actually true for ALL System Events, right? > So we should not define it in PAT but somewhere more general imo. > > LieGrue, > strub > > > > > >>> On Monday, 22 December 2014, 9:56, Jozef Hartinger wrote: >>> Yes, we should explicitly define those other cases as non-portable if it >> has not been done yet. >> >>> On 12/22/2014 09:49 AM, Mark Struberg wrote: >>> well, it's just the tip of the iceberg. It would be way easier to just >> define any 'modification' as non-portable. That would be much more >> precise and easier as well. And really covers al the edge cases as well. >>> >>> LieGrue, >>> strub >>> >>> >>> >>> >>> >>>> On Monday, 22 December 2014, 9:42, Jozef Hartinger >> wrote: >>>> On 12/22/2014 09:33 AM, Mark Struberg wrote: >>>>> No you can NOT I fear. >>>>> >>>>> How do you make sure that the AnnotatedType someone added >> doesn't get >>>> changed later? We have no whatever control over it. If some programmer >> like to >>>> make it mutable, well then it is that way and we have no chance to >> detect that >>>> :( >>>>> Imo the only thing we can do is to point programmers to the fact >> that this >>>> is stupid -> non-portable behaviour. >>>> Correct. This is stupid. But allowing setAnnotatedType() to be called >>>> anytime does not help this at all. >>>> >>>> The fact that we throw the exception on setAnnotatedType() prevents a >>>> class of bad things from happening. At the same time it does not >> prevent >>>> the other one that you mentioned. The fact that we cannot prevent all >> of >>>> them does not mean that we should not try to prevent those we can. >>>> >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> On Monday, 22 December 2014, 9:29, Jozef Hartinger >>>> wrote: >>>>>> On 12/21/2014 09:47 PM, Mark Struberg wrote: >>>>>>> Hi! >>>>>>> >>>>>>> I just came across this little sentence in the spec >>>>>>> >>>>>>> >>>>>>> >>>>>>> 11.5.6 "If any ProcessAnnotatedType method is >> called outside >>>> of the >>>>>> observer method invocation, an IllegalStateException is >> thrown." >>>>>>> I don't believe such a limitation helps much. What >> about >>>> extensions who >>>>>> do a setAnnotatedType and change this instance in a later >> phase? >>>>>> Such as? >>>>>>> We have no whatever chance to prevent this anyway. >>>>>> We can prevent that by throwing the exception, rather than >> silently >>>>>> ignoring that the extension is doing something wrong. >>>>>> >>>>>>> So why not just say that if a CDI System Event gets >> modified >>>> outside of the >>>>>> method it gets injected into then non portable behaviour >> results. >>>>>>> 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 struberg at yahoo.de Tue Dec 23 04:03:26 2014 From: struberg at yahoo.de (Mark Struberg) Date: Tue, 23 Dec 2014 09:03:26 +0000 (UTC) Subject: [cdi-dev] Thoughts on Phases and Events for the Security spec In-Reply-To: References: Message-ID: <962066034.538980.1419325406827.JavaMail.yahoo@jws11111.mail.ir2.yahoo.com> Switching languages is a business concern in some companies. And the example with the role switching was just ONE example. There are dozen others. Now you could go on and add all those things into a next spec adding another 450++ classes. But no one gonna use that! JASPIC and EE security is pretty much a disaster area right now because it did NOT step back a few meters and tried to just introduce APIs which are generic (or specific) enough to be very flexible. I can do 100% of what you can do with JavaEE security in a simple Servlet Filter, a CDI producer and an interceptor within 300 lines. And all this is really extensible and works perfectly for all my customers weirdest use cases (like integration into HOST security, etc). I think JASPIC & Co has to be ditched and a totally new approach needs to be made. I know this might be an extreme position and we might finally meet in the middle. But this is what I've seen in MANY companies. EE security is a.) to hard to understand and thus b.) not well understood c.) too complex d.) without giving you all the bits you need in practice thus it's really way easier to simply hack a ServletFilter and an own Principal system to guard your secured resources. You then also have the ability to use the same mechanism in e.g. batches, standalone SE programs etc. And the best thing: it is really portable, which most of the EE security stuff is NOT. There you always need to tweak container specific config, add LoginModule totally different each time, etc LieGrue, strub > On Monday, 22 December 2014, 22:55, arjan tijms wrote: > > Hi, > > On Mon, Dec 22, 2014 at 8:54 PM, Mark Struberg wrote: >> To be honest I'm not sure if I'd do any of this. All this should > imo not belong to the EE spec at all. It is probably just far too business > specific. > > What exactly should not be done? Authentication events, or the > enumeration Antonio mentioned? > > >> What if the application needs some kind of role change. E.g. you > temporarily switch roles, change the preferred language, etc? All these things > are heavily depending on the application and are not technical at all. > > I'm not sure what the preferred language has to do with this. This is > not an authentication concern, but simply a user preference and indeed > an application concern. > > Switching roles however is an authentication concern. It's IMHO not > business specific. There are two variations, a temporarily one as you > mention, and a "permanent" one (permanent within a session, or as > authentication in Java EE is by default per request, even do this for > just the remainder of the request). > > The temporary one can be implemented via authentication stacks, and > this can definitely be implemented in a completely non business > specific way. In a declarative way @RunAs already does this in a way. > A programmatic API could look like the following: > > request.authenticateStacked(); // Starts new authentication dialog, if > authenticated previous identity is stored on stack > request.authenticateStackedAs(String username); // Programmatic > equivalent of @RunAs > request.authenticateStacked(Callback... callbacks); // Generic > variant, supporting extendible options such as adding/removing roles > request.logoutCurrent(); // logs out current user, goes back one level > on the stack > request.logout(); // existing API, totally logs user out > > A "permanent" change is typical when for instance a username is linked > to a user email, and the user changes his email. The act of changing > this email is application specific, but just signaling this change to > the container is a general action (see > https://java.net/jira/browse/JASPIC_SPEC-22). > > Events can be largely orthogonal to all of this, although perhaps some > properties of the event could give information about the authenticate > type (new one, or stacked one). > > Kind regards, > Arjan Tijms > > > > > > > > >> >> LieGrue, >> strub >> >> >> >> On Monday, 22 December 2014, 20:12, arjan tijms > wrote: >> >> >>> >>> >>> Hi, >>> >>> On Monday, December 22, 2014, Antonio Goncalves > wrote: >>> >>> Hi all, >>>> >>>> >>>> >>>> The CDI spec defines the "Transactional observer methods" > (?10.4.5) with a TransactionPhase : >>>> >>>> >>>> public enum TransactionPhase { >>>> IN_PROGRESS, >>>> BEFORE_COMPLETION, >>>> AFTER_COMPLETION, >>>> AFTER_FAILURE, >>>> AFTER_SUCCESS >>>> } >>>> >>>> >>>> void onDocumentUpdate(@Observes(during=AFTER_SUCCESS) @Updated > Document doc) { ... } >>>> >>>> >>>> >>>> >>>> Now that there is a new Security specification coming along, it > would be helpful to be able to observe before/after the user logs-in or > logs-out, for example. First I thought "well, the Security spec defines a > set of events, fires them, and we just have to observe them". But what > about the "during" phase ? What would make more sense in such use case > ? Using the same "during" mechanism or events ? >>> >>> >>> I think separate events may be better. >>> >>> >>> Maybe I'm mistaken but the way I think the transactional events are > used is that during a transactional method an event is fired. The event is then > not delivered right away to all observers, but for those using > during=after_success only when the TX commits. This is kinda like what JMS does; > a message is only send when the TX commits, or send right away. CDI offers 3 > other cases, but I feel that those first two are the main ones. >>> >>> >>> For authentication events I don't think we can really speak of a > "logging-in" method. Even if we would appoint one (e.g. > validateRequest() in a SAM) then I'm not sure whether any random event > published during that method would have any need to be queued until just before > or after authentication actually happens. >>> >>> >>> Instead, we would merely be interested in the actual events; the moment > the container is about to authenticate (so we can potentially veto) and the > moment right after that (so we can take an action such as loading data related > to the user into the current session). >>> >>> >>> Just my 2 cents. Hope I understood the case correctly. >>> >>> >>> Kind regards, >>> Arjan >>> >>> >>> >>> >>> >>> >>>> >>>> public enum LoginPhase { >>>> BEFORE_LOGIN, >>>> AFTER_LOGIN, >>>> BEFORE_LOGOUT, >>>> AFTER_LOGOUT, >>>> } >>>> >>>> >>>> void onLogout(@Observes(during=BEFORE_LOGOUT) User user) { ... > } >>>> >>>> >>>> >>>> >>>> Any thoughts ? >>>> >>>> -- >>>> >>>> Antonio Goncalves >>>> Software architect, Java Champion and Pluralsight author >>>> >>>> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx > France >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided > on this list, the provider waives all patent and other intellectual property > rights inherent in such information. >>> >>> > From rmannibucau at gmail.com Tue Dec 23 05:08:37 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 23 Dec 2014 11:08:37 +0100 Subject: [cdi-dev] Thoughts on Phases and Events for the Security spec In-Reply-To: <962066034.538980.1419325406827.JavaMail.yahoo@jws11111.mail.ir2.yahoo.com> References: <962066034.538980.1419325406827.JavaMail.yahoo@jws11111.mail.ir2.yahoo.com> Message-ID: Agree, I'd like to see JAAS enhanced to be really portable and configurable by app + supporting roles in its principal API (not only getName but getRoles as well) + being integrated with CDI. Would also be great to be simplified when customized, ie writing a LoginModule could be just implementing Principal authenticate(user, password); like HttpServletRequest was enhanced. Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-12-23 10:03 GMT+01:00 Mark Struberg : > Switching languages is a business concern in some companies. > > And the example with the role switching was just ONE example. There are dozen others. Now you could go on and add all those things into a next spec adding another 450++ classes. But no one gonna use that! > > JASPIC and EE security is pretty much a disaster area right now because it did NOT step back a few meters and tried to just introduce APIs which are generic (or specific) enough to be very flexible. > > > I can do 100% of what you can do with JavaEE security in a simple Servlet Filter, a CDI producer and an interceptor within 300 lines. And all this is really extensible and works perfectly for all my customers weirdest use cases (like integration into HOST security, etc). > > > > I think JASPIC & Co has to be ditched and a totally new approach needs to be made. > > > I know this might be an extreme position and we might finally meet in the middle. But this is what I've seen in MANY companies. EE security is > > a.) to hard to understand and thus > > b.) not well understood > > c.) too complex > d.) without giving you all the bits you need in practice > > thus it's really way easier to simply hack a ServletFilter and an own Principal system to guard your secured resources. You then also have the ability to use the same mechanism in e.g. batches, standalone SE programs etc. > > > And the best thing: it is really portable, which most of the EE security stuff is NOT. There you always need to tweak container specific config, add LoginModule totally different each time, etc > > > LieGrue, > strub > > > > > >> On Monday, 22 December 2014, 22:55, arjan tijms wrote: >> > Hi, >> >> On Mon, Dec 22, 2014 at 8:54 PM, Mark Struberg wrote: >>> To be honest I'm not sure if I'd do any of this. All this should >> imo not belong to the EE spec at all. It is probably just far too business >> specific. >> >> What exactly should not be done? Authentication events, or the >> enumeration Antonio mentioned? >> >> >>> What if the application needs some kind of role change. E.g. you >> temporarily switch roles, change the preferred language, etc? All these things >> are heavily depending on the application and are not technical at all. >> >> I'm not sure what the preferred language has to do with this. This is >> not an authentication concern, but simply a user preference and indeed >> an application concern. >> >> Switching roles however is an authentication concern. It's IMHO not >> business specific. There are two variations, a temporarily one as you >> mention, and a "permanent" one (permanent within a session, or as >> authentication in Java EE is by default per request, even do this for >> just the remainder of the request). >> >> The temporary one can be implemented via authentication stacks, and >> this can definitely be implemented in a completely non business >> specific way. In a declarative way @RunAs already does this in a way. >> A programmatic API could look like the following: >> >> request.authenticateStacked(); // Starts new authentication dialog, if >> authenticated previous identity is stored on stack >> request.authenticateStackedAs(String username); // Programmatic >> equivalent of @RunAs >> request.authenticateStacked(Callback... callbacks); // Generic >> variant, supporting extendible options such as adding/removing roles >> request.logoutCurrent(); // logs out current user, goes back one level >> on the stack >> request.logout(); // existing API, totally logs user out >> >> A "permanent" change is typical when for instance a username is linked >> to a user email, and the user changes his email. The act of changing >> this email is application specific, but just signaling this change to >> the container is a general action (see >> https://java.net/jira/browse/JASPIC_SPEC-22). >> >> Events can be largely orthogonal to all of this, although perhaps some >> properties of the event could give information about the authenticate >> type (new one, or stacked one). >> >> Kind regards, >> Arjan Tijms >> >> >> >> >> >> >> >> >>> >>> LieGrue, >>> strub >>> >>> >>> >>> On Monday, 22 December 2014, 20:12, arjan tijms >> wrote: >>> >>> >>>> >>>> >>>> Hi, >>>> >>>> On Monday, December 22, 2014, Antonio Goncalves >> wrote: >>>> >>>> Hi all, >>>>> >>>>> >>>>> >>>>> The CDI spec defines the "Transactional observer methods" >> (?10.4.5) with a TransactionPhase : >>>>> >>>>> >>>>> public enum TransactionPhase { >>>>> IN_PROGRESS, >>>>> BEFORE_COMPLETION, >>>>> AFTER_COMPLETION, >>>>> AFTER_FAILURE, >>>>> AFTER_SUCCESS >>>>> } >>>>> >>>>> >>>>> void onDocumentUpdate(@Observes(during=AFTER_SUCCESS) @Updated >> Document doc) { ... } >>>>> >>>>> >>>>> >>>>> >>>>> Now that there is a new Security specification coming along, it >> would be helpful to be able to observe before/after the user logs-in or >> logs-out, for example. First I thought "well, the Security spec defines a >> set of events, fires them, and we just have to observe them". But what >> about the "during" phase ? What would make more sense in such use case >> ? Using the same "during" mechanism or events ? >>>> >>>> >>>> I think separate events may be better. >>>> >>>> >>>> Maybe I'm mistaken but the way I think the transactional events are >> used is that during a transactional method an event is fired. The event is then >> not delivered right away to all observers, but for those using >> during=after_success only when the TX commits. This is kinda like what JMS does; >> a message is only send when the TX commits, or send right away. CDI offers 3 >> other cases, but I feel that those first two are the main ones. >>>> >>>> >>>> For authentication events I don't think we can really speak of a >> "logging-in" method. Even if we would appoint one (e.g. >> validateRequest() in a SAM) then I'm not sure whether any random event >> published during that method would have any need to be queued until just before >> or after authentication actually happens. >>>> >>>> >>>> Instead, we would merely be interested in the actual events; the moment >> the container is about to authenticate (so we can potentially veto) and the >> moment right after that (so we can take an action such as loading data related >> to the user into the current session). >>>> >>>> >>>> Just my 2 cents. Hope I understood the case correctly. >>>> >>>> >>>> Kind regards, >>>> Arjan >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> public enum LoginPhase { >>>>> BEFORE_LOGIN, >>>>> AFTER_LOGIN, >>>>> BEFORE_LOGOUT, >>>>> AFTER_LOGOUT, >>>>> } >>>>> >>>>> >>>>> void onLogout(@Observes(during=BEFORE_LOGOUT) User user) { ... >> } >>>>> >>>>> >>>>> >>>>> >>>>> Any thoughts ? >>>>> >>>>> -- >>>>> >>>>> Antonio Goncalves >>>>> Software architect, Java Champion and Pluralsight author >>>>> >>>>> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx >> France >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided >> on this list, the provider waives all patent and other intellectual property >> rights inherent in such information. >>>> >>>> >> > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From arjan.tijms at gmail.com Tue Dec 23 07:44:28 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Tue, 23 Dec 2014 13:44:28 +0100 Subject: [cdi-dev] Thoughts on Phases and Events for the Security spec In-Reply-To: <962066034.538980.1419325406827.JavaMail.yahoo@jws11111.mail.ir2.yahoo.com> References: <962066034.538980.1419325406827.JavaMail.yahoo@jws11111.mail.ir2.yahoo.com> Message-ID: Hi, On Tue, Dec 23, 2014 at 10:03 AM, Mark Struberg wrote: > Switching languages is a business concern in some companies. I think you're right and it is, but I still don't really see what it has to do with communicating the authentication details to the container. > And the example with the role switching was just ONE example. There are dozen others. Now you could go on and add all those things into a next spec adding another 450++ classes. But no one gonna use that! Sorry, but I really don't understand your concern. There are only two pieces of information to be communicated: 1. The caller principal name 2. The groups (roles) That's all. Things like language switching, the number of posts a user gets to see on the front page of your site, the background color and what have you just aren't related. There are no 450 classes needed and none of those dozens of other examples have to be added to the spec. It's just different variants of communicating that caller principal name and groups. The only thing that was asked for here to be added are two events: 1. User logs in (i.e. caller principal and groups are applied by the container) 2. User logs out (i.e. caller principal and groups are removed by the container) Then Antonio wondered about one variant of that; the just-before event and whether there's any notion of a "during". Undertow for instance already throws these events, and they can be easily bridged to CDI events. See http://jdevelopment.nl/bridging-undertows-authentication-events-cdi Kind regards, Arjan Tijms > > > LieGrue, > strub > > > > > >> On Monday, 22 December 2014, 22:55, arjan tijms wrote: >> > Hi, >> >> On Mon, Dec 22, 2014 at 8:54 PM, Mark Struberg wrote: >>> To be honest I'm not sure if I'd do any of this. All this should >> imo not belong to the EE spec at all. It is probably just far too business >> specific. >> >> What exactly should not be done? Authentication events, or the >> enumeration Antonio mentioned? >> >> >>> What if the application needs some kind of role change. E.g. you >> temporarily switch roles, change the preferred language, etc? All these things >> are heavily depending on the application and are not technical at all. >> >> I'm not sure what the preferred language has to do with this. This is >> not an authentication concern, but simply a user preference and indeed >> an application concern. >> >> Switching roles however is an authentication concern. It's IMHO not >> business specific. There are two variations, a temporarily one as you >> mention, and a "permanent" one (permanent within a session, or as >> authentication in Java EE is by default per request, even do this for >> just the remainder of the request). >> >> The temporary one can be implemented via authentication stacks, and >> this can definitely be implemented in a completely non business >> specific way. In a declarative way @RunAs already does this in a way. >> A programmatic API could look like the following: >> >> request.authenticateStacked(); // Starts new authentication dialog, if >> authenticated previous identity is stored on stack >> request.authenticateStackedAs(String username); // Programmatic >> equivalent of @RunAs >> request.authenticateStacked(Callback... callbacks); // Generic >> variant, supporting extendible options such as adding/removing roles >> request.logoutCurrent(); // logs out current user, goes back one level >> on the stack >> request.logout(); // existing API, totally logs user out >> >> A "permanent" change is typical when for instance a username is linked >> to a user email, and the user changes his email. The act of changing >> this email is application specific, but just signaling this change to >> the container is a general action (see >> https://java.net/jira/browse/JASPIC_SPEC-22). >> >> Events can be largely orthogonal to all of this, although perhaps some >> properties of the event could give information about the authenticate >> type (new one, or stacked one). >> >> Kind regards, >> Arjan Tijms >> >> >> >> >> >> >> >> >>> >>> LieGrue, >>> strub >>> >>> >>> >>> On Monday, 22 December 2014, 20:12, arjan tijms >> wrote: >>> >>> >>>> >>>> >>>> Hi, >>>> >>>> On Monday, December 22, 2014, Antonio Goncalves >> wrote: >>>> >>>> Hi all, >>>>> >>>>> >>>>> >>>>> The CDI spec defines the "Transactional observer methods" >> (?10.4.5) with a TransactionPhase : >>>>> >>>>> >>>>> public enum TransactionPhase { >>>>> IN_PROGRESS, >>>>> BEFORE_COMPLETION, >>>>> AFTER_COMPLETION, >>>>> AFTER_FAILURE, >>>>> AFTER_SUCCESS >>>>> } >>>>> >>>>> >>>>> void onDocumentUpdate(@Observes(during=AFTER_SUCCESS) @Updated >> Document doc) { ... } >>>>> >>>>> >>>>> >>>>> >>>>> Now that there is a new Security specification coming along, it >> would be helpful to be able to observe before/after the user logs-in or >> logs-out, for example. First I thought "well, the Security spec defines a >> set of events, fires them, and we just have to observe them". But what >> about the "during" phase ? What would make more sense in such use case >> ? Using the same "during" mechanism or events ? >>>> >>>> >>>> I think separate events may be better. >>>> >>>> >>>> Maybe I'm mistaken but the way I think the transactional events are >> used is that during a transactional method an event is fired. The event is then >> not delivered right away to all observers, but for those using >> during=after_success only when the TX commits. This is kinda like what JMS does; >> a message is only send when the TX commits, or send right away. CDI offers 3 >> other cases, but I feel that those first two are the main ones. >>>> >>>> >>>> For authentication events I don't think we can really speak of a >> "logging-in" method. Even if we would appoint one (e.g. >> validateRequest() in a SAM) then I'm not sure whether any random event >> published during that method would have any need to be queued until just before >> or after authentication actually happens. >>>> >>>> >>>> Instead, we would merely be interested in the actual events; the moment >> the container is about to authenticate (so we can potentially veto) and the >> moment right after that (so we can take an action such as loading data related >> to the user into the current session). >>>> >>>> >>>> Just my 2 cents. Hope I understood the case correctly. >>>> >>>> >>>> Kind regards, >>>> Arjan >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> public enum LoginPhase { >>>>> BEFORE_LOGIN, >>>>> AFTER_LOGIN, >>>>> BEFORE_LOGOUT, >>>>> AFTER_LOGOUT, >>>>> } >>>>> >>>>> >>>>> void onLogout(@Observes(during=BEFORE_LOGOUT) User user) { ... >> } >>>>> >>>>> >>>>> >>>>> >>>>> Any thoughts ? >>>>> >>>>> -- >>>>> >>>>> Antonio Goncalves >>>>> Software architect, Java Champion and Pluralsight author >>>>> >>>>> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx >> France >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided >> on this list, the provider waives all patent and other intellectual property >> rights inherent in such information. >>>> >>>> >> From arjan.tijms at gmail.com Tue Dec 23 08:01:48 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Tue, 23 Dec 2014 14:01:48 +0100 Subject: [cdi-dev] Improving EE security (was: Thoughts on Phases and Events for the Security spec) Message-ID: Hi, Since the discussion went away from throwing events and to general security in Java EE I'm replying in this new thread here. Eventually I think this discussion is better at home with the Security API, but that one doesn't have its mailing list open yet. Hi, On Tue, Dec 23, 2014 at 11:08 AM, Romain Manni-Bucau wrote: > Agree, > > I'd like to see JAAS enhanced to be really portable and configurable > by app + supporting roles in its principal API (not only getName but > getRoles as well) + being integrated with CDI. Would also be great to > be simplified when customized, ie writing a LoginModule could be just > implementing Principal authenticate(user, password); like > HttpServletRequest was enhanced. I agree with that. There are various existing issues on the EE tracker covering most of this: https://java.net/jira/browse/JAVAEE_SPEC-42 (Standardise user/caller and group/role principals in Subject) https://java.net/jira/browse/JAVAEE_SPEC-28 (Standardize Simple Security Providers) https://java.net/jira/browse/JAVAEE_SPEC-25 (Deploy JAAS Artifacts in Application) https://java.net/jira/browse/JAVAEE_SPEC-9 (Simplify and standardize authentication & role mapping) The following is also related: https://java.net/jira/browse/JAVAEE_SPEC-37 (Better integration between Servlet's auth-method, JASPIC's auth modules and realms/JAAS login modules/simple security providers) In short, JAAS LoginModules represent a repository of users/roles, but at some point they have to put the user name and roles into a Subject, and the way this is done is not standardized. It should be possible to easily declare JAAS LoginModules using an annotation and portable XML, and we should have a small set of the most common ones standardized (e.g. DB, LDAP, users.xml) Finally we should not forget that JAAS LoginModules only define a repository, not a method to interact with the user in a client/server environment. E.g. you can't do FORM or OAuth http redirects from such module. Kind regards, Arjan Tijms > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2014-12-23 10:03 GMT+01:00 Mark Struberg : >> Switching languages is a business concern in some companies. >> >> And the example with the role switching was just ONE example. There are dozen others. Now you could go on and add all those things into a next spec adding another 450++ classes. But no one gonna use that! >> >> JASPIC and EE security is pretty much a disaster area right now because it did NOT step back a few meters and tried to just introduce APIs which are generic (or specific) enough to be very flexible. >> >> >> I can do 100% of what you can do with JavaEE security in a simple Servlet Filter, a CDI producer and an interceptor within 300 lines. And all this is really extensible and works perfectly for all my customers weirdest use cases (like integration into HOST security, etc). >> >> >> >> I think JASPIC & Co has to be ditched and a totally new approach needs to be made. >> >> >> I know this might be an extreme position and we might finally meet in the middle. But this is what I've seen in MANY companies. EE security is >> >> a.) to hard to understand and thus >> >> b.) not well understood >> >> c.) too complex >> d.) without giving you all the bits you need in practice >> >> thus it's really way easier to simply hack a ServletFilter and an own Principal system to guard your secured resources. You then also have the ability to use the same mechanism in e.g. batches, standalone SE programs etc. >> >> >> And the best thing: it is really portable, which most of the EE security stuff is NOT. There you always need to tweak container specific config, add LoginModule totally different each time, etc >> >> >> LieGrue, >> strub >> >> >> >> >> >>> On Monday, 22 December 2014, 22:55, arjan tijms wrote: >>> > Hi, >>> >>> On Mon, Dec 22, 2014 at 8:54 PM, Mark Struberg wrote: >>>> To be honest I'm not sure if I'd do any of this. All this should >>> imo not belong to the EE spec at all. It is probably just far too business >>> specific. >>> >>> What exactly should not be done? Authentication events, or the >>> enumeration Antonio mentioned? >>> >>> >>>> What if the application needs some kind of role change. E.g. you >>> temporarily switch roles, change the preferred language, etc? All these things >>> are heavily depending on the application and are not technical at all. >>> >>> I'm not sure what the preferred language has to do with this. This is >>> not an authentication concern, but simply a user preference and indeed >>> an application concern. >>> >>> Switching roles however is an authentication concern. It's IMHO not >>> business specific. There are two variations, a temporarily one as you >>> mention, and a "permanent" one (permanent within a session, or as >>> authentication in Java EE is by default per request, even do this for >>> just the remainder of the request). >>> >>> The temporary one can be implemented via authentication stacks, and >>> this can definitely be implemented in a completely non business >>> specific way. In a declarative way @RunAs already does this in a way. >>> A programmatic API could look like the following: >>> >>> request.authenticateStacked(); // Starts new authentication dialog, if >>> authenticated previous identity is stored on stack >>> request.authenticateStackedAs(String username); // Programmatic >>> equivalent of @RunAs >>> request.authenticateStacked(Callback... callbacks); // Generic >>> variant, supporting extendible options such as adding/removing roles >>> request.logoutCurrent(); // logs out current user, goes back one level >>> on the stack >>> request.logout(); // existing API, totally logs user out >>> >>> A "permanent" change is typical when for instance a username is linked >>> to a user email, and the user changes his email. The act of changing >>> this email is application specific, but just signaling this change to >>> the container is a general action (see >>> https://java.net/jira/browse/JASPIC_SPEC-22). >>> >>> Events can be largely orthogonal to all of this, although perhaps some >>> properties of the event could give information about the authenticate >>> type (new one, or stacked one). >>> >>> Kind regards, >>> Arjan Tijms >>> >>> >>> >>> >>> >>> >>> >>> >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> >>>> On Monday, 22 December 2014, 20:12, arjan tijms >>> wrote: >>>> >>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> On Monday, December 22, 2014, Antonio Goncalves >>> wrote: >>>>> >>>>> Hi all, >>>>>> >>>>>> >>>>>> >>>>>> The CDI spec defines the "Transactional observer methods" >>> (?10.4.5) with a TransactionPhase : >>>>>> >>>>>> >>>>>> public enum TransactionPhase { >>>>>> IN_PROGRESS, >>>>>> BEFORE_COMPLETION, >>>>>> AFTER_COMPLETION, >>>>>> AFTER_FAILURE, >>>>>> AFTER_SUCCESS >>>>>> } >>>>>> >>>>>> >>>>>> void onDocumentUpdate(@Observes(during=AFTER_SUCCESS) @Updated >>> Document doc) { ... } >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Now that there is a new Security specification coming along, it >>> would be helpful to be able to observe before/after the user logs-in or >>> logs-out, for example. First I thought "well, the Security spec defines a >>> set of events, fires them, and we just have to observe them". But what >>> about the "during" phase ? What would make more sense in such use case >>> ? Using the same "during" mechanism or events ? >>>>> >>>>> >>>>> I think separate events may be better. >>>>> >>>>> >>>>> Maybe I'm mistaken but the way I think the transactional events are >>> used is that during a transactional method an event is fired. The event is then >>> not delivered right away to all observers, but for those using >>> during=after_success only when the TX commits. This is kinda like what JMS does; >>> a message is only send when the TX commits, or send right away. CDI offers 3 >>> other cases, but I feel that those first two are the main ones. >>>>> >>>>> >>>>> For authentication events I don't think we can really speak of a >>> "logging-in" method. Even if we would appoint one (e.g. >>> validateRequest() in a SAM) then I'm not sure whether any random event >>> published during that method would have any need to be queued until just before >>> or after authentication actually happens. >>>>> >>>>> >>>>> Instead, we would merely be interested in the actual events; the moment >>> the container is about to authenticate (so we can potentially veto) and the >>> moment right after that (so we can take an action such as loading data related >>> to the user into the current session). >>>>> >>>>> >>>>> Just my 2 cents. Hope I understood the case correctly. >>>>> >>>>> >>>>> Kind regards, >>>>> Arjan >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> public enum LoginPhase { >>>>>> BEFORE_LOGIN, >>>>>> AFTER_LOGIN, >>>>>> BEFORE_LOGOUT, >>>>>> AFTER_LOGOUT, >>>>>> } >>>>>> >>>>>> >>>>>> void onLogout(@Observes(during=BEFORE_LOGOUT) User user) { ... >>> } >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Any thoughts ? >>>>>> >>>>>> -- >>>>>> >>>>>> Antonio Goncalves >>>>>> Software architect, Java Champion and Pluralsight author >>>>>> >>>>>> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx >>> France >>>>> >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 >>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided >>> on this list, the provider waives all patent and other intellectual property >>> rights inherent in such information. >>>>> >>>>> >>> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From arjan.tijms at gmail.com Tue Dec 23 08:08:23 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Tue, 23 Dec 2014 14:08:23 +0100 Subject: [cdi-dev] Improving EE security (was: Thoughts on Phases and Events for the Security spec) In-Reply-To: References: Message-ID: Hi, On Tue, Dec 23, 2014 at 10:03 AM, Mark Struberg wrote: > JASPIC and EE security is pretty much a disaster area right now because it did NOT step back a few meters and tried to just introduce APIs which are generic (or specific) enough to be very flexible. Are we really talking about the same thing here? JASPIC is really generic and flexible, almost to its fault. There are no specific use cases coded into JASPIC. It's essentially a Servlet filter, with the main difference that you get a callback handler from the container. There are two callbacks that you can pass in; the CallerPrincipalCallback and the GroupPrincipalCallback, which you use to pass the two above mentioned data items to the container. And that's basically it. Check http://arjan-tijms.omnifaces.org/2014/11/header-based-stateless-token.html to see what a simple JASPIC SAM looks like. > I can do 100% of what you can do with JavaEE security in a simple Servlet Filter, a CDI producer and an interceptor within 300 lines. And all this is really extensible and works perfectly for all my customers weirdest use cases (like integration into HOST security, etc). Essentially JASPIC is closer to that than you might think. And there's a little more to it than just a filter, producer and an interceptor. You'd also want some method to determine if the resource you're accessing is protected (secured) or not and a way to propagate the caller principal and roles to another context (such as a remote EJB call, or a container managed thread). And you need to be able to trigger the mechanism programmatically (which HttpServletRequest#authenticate does). You can't just cause a Filter to be called again mid request. Finally, and although I'm personally not a big fan of it for all application types, there is a strong use case for having security modules installed AS wide instead of embedded with an application archive. A JASPIC SAM can be either installed AS wide (using proprietary means) as well as embedded with an application archive (using a standard API). > I know this might be an extreme position and we might finally meet in the middle. But this is what I've seen in MANY companies. EE security is > > a.) to hard to understand and thus > > b.) not well understood > > c.) too complex > d.) without giving you all the bits you need in practice That's definitely true, hence the dire need to improve things in Java EE 8. I just don't think any of the existing infrastructure needs to be thrown away. In case of JASPIC it just needs a few convenience methods and a base for the Servlet case (not entirely unlike HttpServlet vs Servlet and GenericServlet) and always having CDI available when a SAM is called. Furthermore we need a clear distinction of the auth mechanism being used (e.g. FORM) and the repository used to check credentials (e.g. LDAP or DB) with users having a clear declarative and programmatic way to specify either of those. Servlet now lets you specify a fixed mechanism really easy, but the custom option is missing and the repository (domain/realm/provider/...) is left opaque. JASPIC lets you specify a custom mechanism, but there's no declarative option and the programmatic way is overly verbose. Adding a convenience method to make the programmatic option in JASPIC really easy is not that hard (I've already did this in OmniSecurity and for the EE 7 samples project) and building a declarative option on top of that is almost trivial. > And the best thing: it is really portable, which most of the EE security stuff is NOT. There you always need to tweak container specific config, add LoginModule totally different each time, etc JASPIC itself is portable, but some containers have mandatory role to group mapping which makes it necessary to indeed tweak container specific config. IMHO this *completely ruins* the experience of having portable modules. The answer though is relatively simple; don't have -mandatory- role to group mapping. A somewhat less simple answer (but should still be doable); standardize role to group mapping. But I get what you're saying and I fully agree as I've been pushing the exact same point; it should be possible to configure security without any container specific tweaks whatsoever. Kind regards, Arjan From antonio.goncalves at gmail.com Tue Dec 23 08:44:48 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Tue, 23 Dec 2014 14:44:48 +0100 Subject: [cdi-dev] Thoughts on Phases and Events for the Security spec In-Reply-To: References: <962066034.538980.1419325406827.JavaMail.yahoo@jws11111.mail.ir2.yahoo.com> Message-ID: Arjan, I really like what Undertow does, and that was exactly my question : should it through specific events or phases. In this example Undertow chooses events. My concern is about spreading CDI to other specifications. Security being a brand new one, I wonder if this new spec had something like that in mind. Other specs might use events handling and, therefore, use the CDI event mechanism for it. If they do want to use events, the question is "should they define there own events or phases ?". Just trying to find common patterns to spread the word on other specs. Antonio On Tue, Dec 23, 2014 at 1:44 PM, arjan tijms wrote: > Hi, > > On Tue, Dec 23, 2014 at 10:03 AM, Mark Struberg wrote: > > Switching languages is a business concern in some companies. > > I think you're right and it is, but I still don't really see what it > has to do with communicating the authentication details to the > container. > > > > And the example with the role switching was just ONE example. There are > dozen others. Now you could go on and add all those things into a next spec > adding another 450++ classes. But no one gonna use that! > > Sorry, but I really don't understand your concern. There are only two > pieces of information to be communicated: > > 1. The caller principal name > 2. The groups (roles) > > That's all. > > Things like language switching, the number of posts a user gets to see > on the front page of your site, the background color and what have you > just aren't related. > > There are no 450 classes needed and none of those dozens of other > examples have to be added to the spec. It's just different variants of > communicating that caller principal name and groups. > > The only thing that was asked for here to be added are two events: > > 1. User logs in (i.e. caller principal and groups are applied by the > container) > 2. User logs out (i.e. caller principal and groups are removed by the > container) > > Then Antonio wondered about one variant of that; the just-before event > and whether there's any notion of a "during". > > Undertow for instance already throws these events, and they can be > easily bridged to CDI events. See > http://jdevelopment.nl/bridging-undertows-authentication-events-cdi > > Kind regards, > Arjan Tijms > > > > > > > > > > > > > LieGrue, > > strub > > > > > > > > > > > >> On Monday, 22 December 2014, 22:55, arjan tijms > wrote: > >> > Hi, > >> > >> On Mon, Dec 22, 2014 at 8:54 PM, Mark Struberg > wrote: > >>> To be honest I'm not sure if I'd do any of this. All this should > >> imo not belong to the EE spec at all. It is probably just far too > business > >> specific. > >> > >> What exactly should not be done? Authentication events, or the > >> enumeration Antonio mentioned? > >> > >> > >>> What if the application needs some kind of role change. E.g. you > >> temporarily switch roles, change the preferred language, etc? All these > things > >> are heavily depending on the application and are not technical at all. > >> > >> I'm not sure what the preferred language has to do with this. This is > >> not an authentication concern, but simply a user preference and indeed > >> an application concern. > >> > >> Switching roles however is an authentication concern. It's IMHO not > >> business specific. There are two variations, a temporarily one as you > >> mention, and a "permanent" one (permanent within a session, or as > >> authentication in Java EE is by default per request, even do this for > >> just the remainder of the request). > >> > >> The temporary one can be implemented via authentication stacks, and > >> this can definitely be implemented in a completely non business > >> specific way. In a declarative way @RunAs already does this in a way. > >> A programmatic API could look like the following: > >> > >> request.authenticateStacked(); // Starts new authentication dialog, if > >> authenticated previous identity is stored on stack > >> request.authenticateStackedAs(String username); // Programmatic > >> equivalent of @RunAs > >> request.authenticateStacked(Callback... callbacks); // Generic > >> variant, supporting extendible options such as adding/removing roles > >> request.logoutCurrent(); // logs out current user, goes back one level > >> on the stack > >> request.logout(); // existing API, totally logs user out > >> > >> A "permanent" change is typical when for instance a username is linked > >> to a user email, and the user changes his email. The act of changing > >> this email is application specific, but just signaling this change to > >> the container is a general action (see > >> https://java.net/jira/browse/JASPIC_SPEC-22). > >> > >> Events can be largely orthogonal to all of this, although perhaps some > >> properties of the event could give information about the authenticate > >> type (new one, or stacked one). > >> > >> Kind regards, > >> Arjan Tijms > >> > >> > >> > >> > >> > >> > >> > >> > >>> > >>> LieGrue, > >>> strub > >>> > >>> > >>> > >>> On Monday, 22 December 2014, 20:12, arjan tijms > >> wrote: > >>> > >>> > >>>> > >>>> > >>>> Hi, > >>>> > >>>> On Monday, December 22, 2014, Antonio Goncalves > >> wrote: > >>>> > >>>> Hi all, > >>>>> > >>>>> > >>>>> > >>>>> The CDI spec defines the "Transactional observer methods" > >> (?10.4.5) with a TransactionPhase : > >>>>> > >>>>> > >>>>> public enum TransactionPhase { > >>>>> IN_PROGRESS, > >>>>> BEFORE_COMPLETION, > >>>>> AFTER_COMPLETION, > >>>>> AFTER_FAILURE, > >>>>> AFTER_SUCCESS > >>>>> } > >>>>> > >>>>> > >>>>> void onDocumentUpdate(@Observes(during=AFTER_SUCCESS) @Updated > >> Document doc) { ... } > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Now that there is a new Security specification coming along, it > >> would be helpful to be able to observe before/after the user logs-in or > >> logs-out, for example. First I thought "well, the Security spec defines > a > >> set of events, fires them, and we just have to observe them". But what > >> about the "during" phase ? What would make more sense in such use case > >> ? Using the same "during" mechanism or events ? > >>>> > >>>> > >>>> I think separate events may be better. > >>>> > >>>> > >>>> Maybe I'm mistaken but the way I think the transactional events are > >> used is that during a transactional method an event is fired. The event > is then > >> not delivered right away to all observers, but for those using > >> during=after_success only when the TX commits. This is kinda like what > JMS does; > >> a message is only send when the TX commits, or send right away. CDI > offers 3 > >> other cases, but I feel that those first two are the main ones. > >>>> > >>>> > >>>> For authentication events I don't think we can really speak of a > >> "logging-in" method. Even if we would appoint one (e.g. > >> validateRequest() in a SAM) then I'm not sure whether any random event > >> published during that method would have any need to be queued until > just before > >> or after authentication actually happens. > >>>> > >>>> > >>>> Instead, we would merely be interested in the actual events; the > moment > >> the container is about to authenticate (so we can potentially veto) and > the > >> moment right after that (so we can take an action such as loading data > related > >> to the user into the current session). > >>>> > >>>> > >>>> Just my 2 cents. Hope I understood the case correctly. > >>>> > >>>> > >>>> Kind regards, > >>>> Arjan > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> > >>>>> public enum LoginPhase { > >>>>> BEFORE_LOGIN, > >>>>> AFTER_LOGIN, > >>>>> BEFORE_LOGOUT, > >>>>> AFTER_LOGOUT, > >>>>> } > >>>>> > >>>>> > >>>>> void onLogout(@Observes(during=BEFORE_LOGOUT) User user) { ... > >> } > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Any thoughts ? > >>>>> > >>>>> -- > >>>>> > >>>>> Antonio Goncalves > >>>>> Software architect, Java Champion and Pluralsight author > >>>>> > >>>>> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx > >> France > >>>> > >>>> _______________________________________________ > >>>> cdi-dev mailing list > >>>> cdi-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>> > >>>> Note that for all code provided on this list, the provider licenses > the > >> code under the Apache License, Version 2 > >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided > >> on this list, the provider waives all patent and other intellectual > property > >> rights inherent in such information. > >>>> > >>>> > >> > -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141223/83383748/attachment-0001.html From arjan.tijms at gmail.com Tue Dec 23 10:23:58 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Tue, 23 Dec 2014 16:23:58 +0100 Subject: [cdi-dev] Thoughts on Phases and Events for the Security spec In-Reply-To: References: <962066034.538980.1419325406827.JavaMail.yahoo@jws11111.mail.ir2.yahoo.com> Message-ID: Hi, >Arjan, I really like what Undertow does Yeah, the API and class design Undertow uses is rather neat indeed. It's much closer to JASPIC + LoginModules than to Servlet Filters + CDI producers, but it definitely has a more modern touch. (*Something to think about is that Undertow when faced with the need for a security system *again* choose to build its own one. It's a very nice one, nothing against that, but it's yet another option.*) > and that was exactly my question : should it through specific events or phases. In this example Undertow chooses events. Indeed, Undertow chooses events but using its own API. No CDI is involved at that level. Although Undertow is build in such a way that CDI can be (and is) initialized before auth modules are invoked. Because of that it's so trivial in Undertow to bridge their native events to CDI ones. I'd personally say that Undertow has made the right decision to use events instead of phases or something else, but I'm also aware that I'm not fully up to date with all pros and cons of both approaches. >My concern is about spreading CDI to other specifications. Security being a brand new one, I wonder if this new spec had something like that in mind. Other specs might use events handling and, therefore, use the CDI event mechanism for it. If they do want to use events, the question is "should they define there own events or phases ?". I hear you. The thing is that the Security API cannot really throw the event directly itself, but has to ask the containers that actually log a user in to do so (e.g. the Servlet, EJB and JCA containers). This is something that is perhaps not entirely clear to everyone, but something like JASPIC too is not a separate implementation. There is no JASPIC RI jar that you download and add to your project. Instead, there's a Servlet Container Profile, which compatible Servlet containers (e.g. Undertow) then implement. So if the login/logout events are to be published via CDI, then effectively Servlet containers have to use CDI. While I don't want to rule this out, especially if there's wording in the spec like: "If CDI is available in the environment, the event should be published via CDI's eventing mechanism", it's a slightly more complicated task politically speaking than just the Security API deciding to use CDI. Another option is that Servlet uses their native event mechanism (@WebListener + a new interface, say ServletAuthListener) and that the Security API installs a default listener that bridges this event to CDI. Kind regards, Arjan Tijms On Tue, Dec 23, 2014 at 2:44 PM, Antonio Goncalves < antonio.goncalves at gmail.com> wrote: > > Arjan, I really like what Undertow does, and that was exactly my question > : should it through specific events or phases. In this example Undertow > chooses events. > > My concern is about spreading CDI to other specifications. Security being > a brand new one, I wonder if this new spec had something like that in mind. > Other specs might use events handling and, therefore, use the CDI event > mechanism for it. If they do want to use events, the question is "should > they define there own events or phases ?". Just trying to find common > patterns to spread the word on other specs. > > Antonio > > On Tue, Dec 23, 2014 at 1:44 PM, arjan tijms > wrote: > >> Hi, >> >> On Tue, Dec 23, 2014 at 10:03 AM, Mark Struberg >> wrote: >> > Switching languages is a business concern in some companies. >> >> I think you're right and it is, but I still don't really see what it >> has to do with communicating the authentication details to the >> container. >> >> >> > And the example with the role switching was just ONE example. There are >> dozen others. Now you could go on and add all those things into a next spec >> adding another 450++ classes. But no one gonna use that! >> >> Sorry, but I really don't understand your concern. There are only two >> pieces of information to be communicated: >> >> 1. The caller principal name >> 2. The groups (roles) >> >> That's all. >> >> Things like language switching, the number of posts a user gets to see >> on the front page of your site, the background color and what have you >> just aren't related. >> >> There are no 450 classes needed and none of those dozens of other >> examples have to be added to the spec. It's just different variants of >> communicating that caller principal name and groups. >> >> The only thing that was asked for here to be added are two events: >> >> 1. User logs in (i.e. caller principal and groups are applied by the >> container) >> 2. User logs out (i.e. caller principal and groups are removed by the >> container) >> >> Then Antonio wondered about one variant of that; the just-before event >> and whether there's any notion of a "during". >> >> Undertow for instance already throws these events, and they can be >> easily bridged to CDI events. See >> http://jdevelopment.nl/bridging-undertows-authentication-events-cdi >> >> Kind regards, >> Arjan Tijms >> >> >> >> >> >> >> >> > >> > >> > LieGrue, >> > strub >> > >> > >> > >> > >> > >> >> On Monday, 22 December 2014, 22:55, arjan tijms >> wrote: >> >> > Hi, >> >> >> >> On Mon, Dec 22, 2014 at 8:54 PM, Mark Struberg >> wrote: >> >>> To be honest I'm not sure if I'd do any of this. All this should >> >> imo not belong to the EE spec at all. It is probably just far too >> business >> >> specific. >> >> >> >> What exactly should not be done? Authentication events, or the >> >> enumeration Antonio mentioned? >> >> >> >> >> >>> What if the application needs some kind of role change. E.g. you >> >> temporarily switch roles, change the preferred language, etc? All >> these things >> >> are heavily depending on the application and are not technical at all. >> >> >> >> I'm not sure what the preferred language has to do with this. This is >> >> not an authentication concern, but simply a user preference and indeed >> >> an application concern. >> >> >> >> Switching roles however is an authentication concern. It's IMHO not >> >> business specific. There are two variations, a temporarily one as you >> >> mention, and a "permanent" one (permanent within a session, or as >> >> authentication in Java EE is by default per request, even do this for >> >> just the remainder of the request). >> >> >> >> The temporary one can be implemented via authentication stacks, and >> >> this can definitely be implemented in a completely non business >> >> specific way. In a declarative way @RunAs already does this in a way. >> >> A programmatic API could look like the following: >> >> >> >> request.authenticateStacked(); // Starts new authentication dialog, if >> >> authenticated previous identity is stored on stack >> >> request.authenticateStackedAs(String username); // Programmatic >> >> equivalent of @RunAs >> >> request.authenticateStacked(Callback... callbacks); // Generic >> >> variant, supporting extendible options such as adding/removing roles >> >> request.logoutCurrent(); // logs out current user, goes back one level >> >> on the stack >> >> request.logout(); // existing API, totally logs user out >> >> >> >> A "permanent" change is typical when for instance a username is linked >> >> to a user email, and the user changes his email. The act of changing >> >> this email is application specific, but just signaling this change to >> >> the container is a general action (see >> >> https://java.net/jira/browse/JASPIC_SPEC-22). >> >> >> >> Events can be largely orthogonal to all of this, although perhaps some >> >> properties of the event could give information about the authenticate >> >> type (new one, or stacked one). >> >> >> >> Kind regards, >> >> Arjan Tijms >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>> >> >>> LieGrue, >> >>> strub >> >>> >> >>> >> >>> >> >>> On Monday, 22 December 2014, 20:12, arjan tijms >> >> wrote: >> >>> >> >>> >> >>>> >> >>>> >> >>>> Hi, >> >>>> >> >>>> On Monday, December 22, 2014, Antonio Goncalves >> >> wrote: >> >>>> >> >>>> Hi all, >> >>>>> >> >>>>> >> >>>>> >> >>>>> The CDI spec defines the "Transactional observer methods" >> >> (?10.4.5) with a TransactionPhase : >> >>>>> >> >>>>> >> >>>>> public enum TransactionPhase { >> >>>>> IN_PROGRESS, >> >>>>> BEFORE_COMPLETION, >> >>>>> AFTER_COMPLETION, >> >>>>> AFTER_FAILURE, >> >>>>> AFTER_SUCCESS >> >>>>> } >> >>>>> >> >>>>> >> >>>>> void onDocumentUpdate(@Observes(during=AFTER_SUCCESS) @Updated >> >> Document doc) { ... } >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> Now that there is a new Security specification coming along, it >> >> would be helpful to be able to observe before/after the user logs-in or >> >> logs-out, for example. First I thought "well, the Security spec >> defines a >> >> set of events, fires them, and we just have to observe them". But what >> >> about the "during" phase ? What would make more sense in such use case >> >> ? Using the same "during" mechanism or events ? >> >>>> >> >>>> >> >>>> I think separate events may be better. >> >>>> >> >>>> >> >>>> Maybe I'm mistaken but the way I think the transactional events are >> >> used is that during a transactional method an event is fired. The >> event is then >> >> not delivered right away to all observers, but for those using >> >> during=after_success only when the TX commits. This is kinda like what >> JMS does; >> >> a message is only send when the TX commits, or send right away. CDI >> offers 3 >> >> other cases, but I feel that those first two are the main ones. >> >>>> >> >>>> >> >>>> For authentication events I don't think we can really speak of a >> >> "logging-in" method. Even if we would appoint one (e.g. >> >> validateRequest() in a SAM) then I'm not sure whether any random event >> >> published during that method would have any need to be queued until >> just before >> >> or after authentication actually happens. >> >>>> >> >>>> >> >>>> Instead, we would merely be interested in the actual events; the >> moment >> >> the container is about to authenticate (so we can potentially veto) >> and the >> >> moment right after that (so we can take an action such as loading data >> related >> >> to the user into the current session). >> >>>> >> >>>> >> >>>> Just my 2 cents. Hope I understood the case correctly. >> >>>> >> >>>> >> >>>> Kind regards, >> >>>> Arjan >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>>> >> >>>>> public enum LoginPhase { >> >>>>> BEFORE_LOGIN, >> >>>>> AFTER_LOGIN, >> >>>>> BEFORE_LOGOUT, >> >>>>> AFTER_LOGOUT, >> >>>>> } >> >>>>> >> >>>>> >> >>>>> void onLogout(@Observes(during=BEFORE_LOGOUT) User user) { ... >> >> } >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> Any thoughts ? >> >>>>> >> >>>>> -- >> >>>>> >> >>>>> Antonio Goncalves >> >>>>> Software architect, Java Champion and Pluralsight author >> >>>>> >> >>>>> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx >> >> France >> >>>> >> >>>> _______________________________________________ >> >>>> cdi-dev mailing list >> >>>> cdi-dev at lists.jboss.org >> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >>>> >> >>>> Note that for all code provided on this list, the provider licenses >> the >> >> code under the Apache License, Version 2 >> >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >> ideas provided >> >> on this list, the provider waives all patent and other intellectual >> property >> >> rights inherent in such information. >> >>>> >> >>>> >> >> >> > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter > | LinkedIn > | Pluralsight > | Paris > JUG | Devoxx France > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141223/759eb270/attachment-0001.html From rmannibucau at gmail.com Tue Dec 23 14:58:16 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 23 Dec 2014 20:58:16 +0100 Subject: [cdi-dev] session destroyed event Message-ID: Hi why org.jboss.cdi.tck.tests.context.session.event.Servlet#doGet ensures destroyed == observer.getDestroyedSessionCount().get() For me invalidate call should trigger the destroy event: you can create N session in a single requests Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau From rmannibucau at gmail.com Tue Dec 23 15:07:20 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 23 Dec 2014 21:07:20 +0100 Subject: [cdi-dev] unproxyable constraint for ejbs Message-ID: Hi org.jboss.cdi.tck.tests.interceptors.definition.broken.finalClassInterceptor.FinalMethodClassLevelMissile will make the container throw a DeploymentException cause of public final void finalManeuver() which is final...but it is not in the EJB API so CDI shouldn't even know it. Is the test buggy - org.jboss.cdi.tck.tests.interceptors.definition.broken.finalClassInterceptor.FinalMethodClassLevelInterceptorTest? IMO this has not to be tested since the EJB container already does it. Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau From rmannibucau at gmail.com Wed Dec 24 12:13:38 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 24 Dec 2014 18:13:38 +0100 Subject: [cdi-dev] org.jboss.cdi.tck.tests.context.conversation.ClientConversationContextTest#testNonexistentConversationExceptionThrown and exception handling Message-ID: Hi isnt "client.setThrowExceptionOnFailingStatusCode(false);" missing in org.jboss.cdi.tck.tests.context.conversation.ClientConversationContextTest#testNonexistentConversationExceptionThrown? Cause it expects an exception but by default httpclient will throw an exception before any validation is done what do I miss? Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau From john.d.ament at gmail.com Wed Dec 24 12:39:09 2014 From: john.d.ament at gmail.com (John D. Ament) Date: Wed, 24 Dec 2014 17:39:09 +0000 Subject: [cdi-dev] org.jboss.cdi.tck.tests.context.conversation.ClientConversationContextTest#testNonexistentConversationExceptionThrown and exception handling References: Message-ID: Why is the http client throwing an exception? AFAIK http client is just making requests and generating the responding response as string or otherwise. html unit is trying to then convert it to a page to process the content. On Wed Dec 24 2014 at 12:14:15 PM Romain Manni-Bucau wrote: > Hi > > isnt "client.setThrowExceptionOnFailingStatusCode(false);" missing in > org.jboss.cdi.tck.tests.context.conversation. > ClientConversationContextTest#testNonexistentConversationExceptionThrown? > > Cause it expects an exception but by default httpclient will throw an > exception before any validation is done > > what do I miss? > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 (http://www.apache.org/ > licenses/LICENSE-2.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/20141224/faa37d97/attachment.html From rmannibucau at gmail.com Wed Dec 24 12:57:55 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 24 Dec 2014 18:57:55 +0100 Subject: [cdi-dev] org.jboss.cdi.tck.tests.context.conversation.ClientConversationContextTest#testNonexistentConversationExceptionThrown and exception handling In-Reply-To: References: Message-ID: there is a NonexistentConversationException (sorry dont have the exact name right now). It is what is expected then the outermostfilter write few things in the response but it is "too late" status is 500. All other tests relying on the same thing do the set to avoid the exception but not this one. Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-12-24 18:39 GMT+01:00 John D. Ament : > Why is the http client throwing an exception? AFAIK http client is just > making requests and generating the responding response as string or > otherwise. html unit is trying to then convert it to a page to process the > content. > > On Wed Dec 24 2014 at 12:14:15 PM Romain Manni-Bucau > wrote: >> >> Hi >> >> isnt "client.setThrowExceptionOnFailingStatusCode(false);" missing in >> >> org.jboss.cdi.tck.tests.context.conversation.ClientConversationContextTest#testNonexistentConversationExceptionThrown? >> >> Cause it expects an exception but by default httpclient will throw an >> exception before any validation is done >> >> what do I miss? >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other intellectual >> property rights inherent in such information. From rmannibucau at gmail.com Fri Dec 26 06:52:37 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Fri, 26 Dec 2014 12:52:37 +0100 Subject: [cdi-dev] org.jboss.cdi.tck.tests.context.application.async.StatusServlet and content type Message-ID: Hi doesn't org.jboss.cdi.tck.tests.context.application.async.StatusServlet forget to set content type to text/plain? org.jboss.cdi.tck.tests.context.application.async.ApplicationContextAsyncListenerTest relies on it like it: TextPage results = webClient.getPage(contextPath + "Status"); but since the content type of the response is not set it uses servlet default one (text/html) and them htmlunit can't cast a HtmlPage to a TextPage. is it expected? Is it an issue on my local setup? Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau From antonio.goncalves at gmail.com Sun Dec 28 07:38:37 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Sun, 28 Dec 2014 13:38:37 +0100 Subject: [cdi-dev] Would @PostActivate, @PrePassivate and @Remove make sense in JSR 250 ? Message-ID: Hi all, I was playing with @SessionScoped beans... and wondered if @PostActivate, @PrePassivate and @Remove would make sense in JSR 250 ? At the moment these annotations belong to the javax.ejb package and are only used in @Stateful EJBs. With CDI scopes, we end up with a few "stateful" scopes (@SessionScoped, but also @ConversationScoped, @ViewScoped...) so why not having the same functionality in CDI ? @PreDestroy and @PostConstruct are already part of JSR 250. So why not having @PostActivate and @PrePassivate as well so they could be used in every bean ? BTW, while I was playing with @SessionScoped beans, I asked Antoine to show me how to remove a bean from the session. It's only a few lines of code, but again, why not having a @Remove annotation that does that (the exact same one of javax.ejb.Remove) ? To summarize, why not taking some of those stateful EJB concerns back to JSR 250 so they could be used anywhere ? Any thoughts ? -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141228/b23a4ac6/attachment.html From john.d.ament at gmail.com Sun Dec 28 07:52:34 2014 From: john.d.ament at gmail.com (John D. Ament) Date: Sun, 28 Dec 2014 12:52:34 +0000 Subject: [cdi-dev] Would @PostActivate, @PrePassivate and @Remove make sense in JSR 250 ? References: Message-ID: PostActivate/PrePassivate are only applicable to EJBs (as of now). EJBs work off of a pool of objects and these life cycle methods are typically used (from the use cases I've dealt with them) to initiate or destroy some end user data for the context in which they are used. I think you might be thinking of PostConstruct/PreDestroy which match to the CDI/ManagedBean paradigm better. There's no pool of these objects around, they simply get created and destroyed when done. For each of the scopes you mentioned, I would use a PostConstruct/PreDestroy method to do the same thing. John On Sun Dec 28 2014 at 7:39:14 AM Antonio Goncalves < antonio.goncalves at gmail.com> wrote: > Hi all, > > I was playing with @SessionScoped beans... and wondered if @PostActivate, > @PrePassivate and @Remove would make sense in JSR 250 ? > > At the moment these annotations belong to the javax.ejb package and are > only used in @Stateful EJBs. With CDI scopes, we end up with a few > "stateful" scopes (@SessionScoped, but also @ConversationScoped, > @ViewScoped...) so why not having the same functionality in CDI ? > @PreDestroy and @PostConstruct are already part of JSR 250. So why not > having @PostActivate and @PrePassivate as well so they could be used in > every bean ? > > BTW, while I was playing with @SessionScoped beans, I asked Antoine to > show me how to remove a bean from the session. It's only a few lines of > code, but again, why not having a @Remove annotation that does that (the > exact same one of javax.ejb.Remove) ? > > To summarize, why not taking some of those stateful EJB concerns back to > JSR 250 so they could be used anywhere ? > > Any thoughts ? > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter > | LinkedIn > | Pluralsight > | Paris > JUG | Devoxx France > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 (http://www.apache.org/ > licenses/LICENSE-2.0.html). For all other ideas provided on this list, > the provider waives all patent and other intellectual property rights > inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141228/16d2d101/attachment.html From rmannibucau at gmail.com Sun Dec 28 10:06:16 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sun, 28 Dec 2014 16:06:16 +0100 Subject: [cdi-dev] Would @PostActivate, @PrePassivate and @Remove make sense in JSR 250 ? In-Reply-To: References: Message-ID: Issue with XActivate is nothing is specified on what does mean activate (think to a cluster) Le 28 d?c. 2014 13:52, "John D. Ament" a ?crit : > PostActivate/PrePassivate are only applicable to EJBs (as of now). EJBs > work off of a pool of objects and these life cycle methods are typically > used (from the use cases I've dealt with them) to initiate or destroy some > end user data for the context in which they are used. > > I think you might be thinking of PostConstruct/PreDestroy which match to > the CDI/ManagedBean paradigm better. There's no pool of these objects > around, they simply get created and destroyed when done. For each of the > scopes you mentioned, I would use a PostConstruct/PreDestroy method to do > the same thing. > > John > > On Sun Dec 28 2014 at 7:39:14 AM Antonio Goncalves < > antonio.goncalves at gmail.com> wrote: > >> Hi all, >> >> I was playing with @SessionScoped beans... and wondered if @PostActivate, >> @PrePassivate and @Remove would make sense in JSR 250 ? >> >> At the moment these annotations belong to the javax.ejb package and are >> only used in @Stateful EJBs. With CDI scopes, we end up with a few >> "stateful" scopes (@SessionScoped, but also @ConversationScoped, >> @ViewScoped...) so why not having the same functionality in CDI ? >> @PreDestroy and @PostConstruct are already part of JSR 250. So why not >> having @PostActivate and @PrePassivate as well so they could be used in >> every bean ? >> >> BTW, while I was playing with @SessionScoped beans, I asked Antoine to >> show me how to remove a bean from the session. It's only a few lines of >> code, but again, why not having a @Remove annotation that does that (the >> exact same one of javax.ejb.Remove) ? >> >> To summarize, why not taking some of those stateful EJB concerns back to >> JSR 250 so they could be used anywhere ? >> >> Any thoughts ? >> >> -- >> Antonio Goncalves >> Software architect, Java Champion and Pluralsight author >> >> Web site | Twitter >> | LinkedIn >> | Pluralsight >> | Paris >> JUG | Devoxx France >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 (http://www.apache.org/ >> licenses/LICENSE-2.0.html). For all other ideas provided on this list, >> the provider waives all patent and other intellectual property rights >> inherent in such information. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141228/cfbbffb6/attachment-0001.html From john.d.ament at gmail.com Sun Dec 28 10:20:28 2014 From: john.d.ament at gmail.com (John D. Ament) Date: Sun, 28 Dec 2014 15:20:28 +0000 Subject: [cdi-dev] Would @PostActivate, @PrePassivate and @Remove make sense in JSR 250 ? References: Message-ID: What would cluster have to do with it? I believe standard practice (since EE doesn't define "cluster") is that when an EJB is used in a cluster, it's expected that SFSB's get replicated to other nodes w/ state in tact. So the bean wouldn't be "re-activated" per se. On Sun Dec 28 2014 at 10:06:16 AM Romain Manni-Bucau wrote: > Issue with XActivate is nothing is specified on what does mean activate > (think to a cluster) > Le 28 d?c. 2014 13:52, "John D. Ament" a ?crit : > > PostActivate/PrePassivate are only applicable to EJBs (as of now). EJBs >> work off of a pool of objects and these life cycle methods are typically >> used (from the use cases I've dealt with them) to initiate or destroy some >> end user data for the context in which they are used. >> >> I think you might be thinking of PostConstruct/PreDestroy which match to >> the CDI/ManagedBean paradigm better. There's no pool of these objects >> around, they simply get created and destroyed when done. For each of the >> scopes you mentioned, I would use a PostConstruct/PreDestroy method to do >> the same thing. >> >> John >> >> On Sun Dec 28 2014 at 7:39:14 AM Antonio Goncalves < >> antonio.goncalves at gmail.com> wrote: >> >>> Hi all, >>> >>> I was playing with @SessionScoped beans... and wondered if >>> @PostActivate, @PrePassivate and @Remove would make sense in JSR 250 ? >>> >>> At the moment these annotations belong to the javax.ejb package and are >>> only used in @Stateful EJBs. With CDI scopes, we end up with a few >>> "stateful" scopes (@SessionScoped, but also @ConversationScoped, >>> @ViewScoped...) so why not having the same functionality in CDI ? >>> @PreDestroy and @PostConstruct are already part of JSR 250. So why not >>> having @PostActivate and @PrePassivate as well so they could be used in >>> every bean ? >>> >>> BTW, while I was playing with @SessionScoped beans, I asked Antoine to >>> show me how to remove a bean from the session. It's only a few lines of >>> code, but again, why not having a @Remove annotation that does that (the >>> exact same one of javax.ejb.Remove) ? >>> >>> To summarize, why not taking some of those stateful EJB concerns back to >>> JSR 250 so they could be used anywhere ? >>> >>> Any thoughts ? >>> >>> -- >>> Antonio Goncalves >>> Software architect, Java Champion and Pluralsight author >>> >>> Web site | Twitter >>> | LinkedIn >>> | Pluralsight >>> | Paris >>> JUG | Devoxx France >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 (http://www.apache.org/ >>> licenses/LICENSE-2.0.html). For all other ideas provided on this list, >>> the provider waives all patent and other intellectual property rights >>> inherent in such information. >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141228/3fc2f074/attachment.html From rmannibucau at gmail.com Sun Dec 28 11:05:28 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sun, 28 Dec 2014 17:05:28 +0100 Subject: [cdi-dev] Would @PostActivate, @PrePassivate and @Remove make sense in JSR 250 ? In-Reply-To: References: Message-ID: it is not specified if called when duplicated or single time for instance. Basically we have an API with no associated behavior so these annotations are not that useful today. BTW it would be useful in JCache N+1...but if we put all in common annotation then we could just use javaee-api.jar since all will be mixed up again, no? Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-12-28 16:20 GMT+01:00 John D. Ament : > What would cluster have to do with it? I believe standard practice (since > EE doesn't define "cluster") is that when an EJB is used in a cluster, it's > expected that SFSB's get replicated to other nodes w/ state in tact. So the > bean wouldn't be "re-activated" per se. > > > On Sun Dec 28 2014 at 10:06:16 AM Romain Manni-Bucau > wrote: >> >> Issue with XActivate is nothing is specified on what does mean activate >> (think to a cluster) >> >> Le 28 d?c. 2014 13:52, "John D. Ament" a ?crit : >> >>> PostActivate/PrePassivate are only applicable to EJBs (as of now). EJBs >>> work off of a pool of objects and these life cycle methods are typically >>> used (from the use cases I've dealt with them) to initiate or destroy some >>> end user data for the context in which they are used. >>> >>> I think you might be thinking of PostConstruct/PreDestroy which match to >>> the CDI/ManagedBean paradigm better. There's no pool of these objects >>> around, they simply get created and destroyed when done. For each of the >>> scopes you mentioned, I would use a PostConstruct/PreDestroy method to do >>> the same thing. >>> >>> John >>> >>> On Sun Dec 28 2014 at 7:39:14 AM Antonio Goncalves >>> wrote: >>>> >>>> Hi all, >>>> >>>> I was playing with @SessionScoped beans... and wondered if >>>> @PostActivate, @PrePassivate and @Remove would make sense in JSR 250 ? >>>> >>>> At the moment these annotations belong to the javax.ejb package and are >>>> only used in @Stateful EJBs. With CDI scopes, we end up with a few >>>> "stateful" scopes (@SessionScoped, but also @ConversationScoped, >>>> @ViewScoped...) so why not having the same functionality in CDI ? >>>> @PreDestroy and @PostConstruct are already part of JSR 250. So why not >>>> having @PostActivate and @PrePassivate as well so they could be used in >>>> every bean ? >>>> >>>> BTW, while I was playing with @SessionScoped beans, I asked Antoine to >>>> show me how to remove a bean from the session. It's only a few lines of >>>> code, but again, why not having a @Remove annotation that does that (the >>>> exact same one of javax.ejb.Remove) ? >>>> >>>> To summarize, why not taking some of those stateful EJB concerns back to >>>> JSR 250 so they could be used anywhere ? >>>> >>>> Any thoughts ? >>>> >>>> -- >>>> Antonio Goncalves >>>> Software architect, Java Champion and Pluralsight author >>>> >>>> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider licenses the >>>> code under the Apache License, Version 2 >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>>> provided on this list, the provider waives all patent and other intellectual >>>> property rights inherent in such information. >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 >>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>> provided on this list, the provider waives all patent and other intellectual >>> property rights inherent in such information. From struberg at yahoo.de Sun Dec 28 11:06:40 2014 From: struberg at yahoo.de (Mark Struberg) Date: Sun, 28 Dec 2014 16:06:40 +0000 (UTC) Subject: [cdi-dev] Would @PostActivate, @PrePassivate and @Remove make sense in JSR 250 ? In-Reply-To: References: Message-ID: <1329913386.2000949.1419782800705.JavaMail.yahoo@jws11161.mail.ir2.yahoo.com> I agree with Romain. @John The problem is that there are many different kind of clusters. And with many of them the serialize/deserialize are not 'symmetric' Think about having e.g. having sticky sessions and a memcached which gets each session pushed to after each request. And if there really is a node outage then the load balancer will move the traffic from this node to another one. On this new node the first thing is to try to load the session from the memcached. And only if there is no such a session it will create a fresh one (ofc rewrite the sessionId to allow subsequent fails). In this scenario you have multiple serializations, but the deserialize only happens at maximum once (after an actual fail over). The PrePassivate/PostActivate just doesn't work well with most of this situations. LieGrue, strub On Sunday, 28 December 2014, 16:21, John D. Ament wrote: > > >What would cluster have to do with it? I believe standard practice (since EE doesn't define "cluster") is that when an EJB is used in a cluster, it's expected that SFSB's get replicated to other nodes w/ state in tact. So the bean wouldn't be "re-activated" per se. > > >On Sun Dec 28 2014 at 10:06:16 AM Romain Manni-Bucau wrote: > >Issue with XActivate is nothing is specified on what does mean activate (think to a cluster) >>Le 28 d?c. 2014 13:52, "John D. Ament" a ?crit : >> >> >>PostActivate/PrePassivate are only applicable to EJBs (as of now). EJBs work off of a pool of objects and these life cycle methods are typically used (from the use cases I've dealt with them) to initiate or destroy some end user data for the context in which they are used. >>> >>> >>> >>>I think you might be thinking of PostConstruct/PreDestroy which match to the CDI/ManagedBean paradigm better. There's no pool of these objects around, they simply get created and destroyed when done. For each of the scopes you mentioned, I would use a PostConstruct/PreDestroy method to do the same thing. >>> >>> >>>John >>> >>>On Sun Dec 28 2014 at 7:39:14 AM Antonio Goncalves wrote: >>> >>>Hi all, >>>> >>>> >>>>I was playing with @SessionScoped beans... and wondered if @PostActivate, @PrePassivate and @Remove would make sense in JSR 250 ? >>>> >>>> >>>>At the moment these annotations belong to the javax.ejb package and are only used in @Stateful EJBs. With CDI scopes, we end up with a few "stateful" scopes (@SessionScoped, but also @ConversationScoped, @ViewScoped...) so why not having the same functionality in CDI ? @PreDestroy and @PostConstruct are already part of JSR 250. So why not having @PostActivate and @PrePassivate as well so they could be used in every bean ? >>>> >>>> >>>>BTW, while I was playing with @SessionScoped beans, I asked Antoine to show me how to remove a bean from the session. It's only a few lines of code, but again, why not having a @Remove annotation that does that (the exact same one of javax.ejb.Remove) ? >>>> >>>> >>>> >>>>To summarize, why not taking some of those stateful EJB concerns back to JSR 250 so they could be used anywhere ? >>>> >>>> >>>>Any thoughts ? >>>> >>>>-- >>>> >>>>Antonio Goncalves >>>>Software architect, Java Champion and Pluralsight author >>>> >>>>Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France _______________________________________________ >>>>cdi-dev mailing list >>>>cdi-dev at lists.jboss.org >>>>https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>>Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>>_______________________________________________ >>>cdi-dev mailing list >>>cdi-dev at lists.jboss.org >>>https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>>Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>> > >_______________________________________________ >cdi-dev mailing list >cdi-dev at lists.jboss.org >https://lists.jboss.org/mailman/listinfo/cdi-dev > >Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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 Sun Dec 28 11:08:35 2014 From: john.d.ament at gmail.com (John D. Ament) Date: Sun, 28 Dec 2014 16:08:35 +0000 Subject: [cdi-dev] Would @PostActivate, @PrePassivate and @Remove make sense in JSR 250 ? References: <1329913386.2000949.1419782800705.JavaMail.yahoo@jws11161.mail.ir2.yahoo.com> Message-ID: Seems like the clustering topic is going off course compared to Antonio's original question... On Sun Dec 28 2014 at 11:06:42 AM Mark Struberg wrote: > I agree with Romain. > > @John > > The problem is that there are many different kind of clusters. > And with many of them the serialize/deserialize are not 'symmetric' > > > Think about having e.g. having sticky sessions and a memcached which gets > each session pushed to after each request. And if there really is a node > outage then the load balancer will move the traffic from this node to > another one. On this new node the first thing is to try to load the session > from the memcached. And only if there is no such a session it will create a > fresh one (ofc rewrite the sessionId to allow subsequent fails). > > In this scenario you have multiple serializations, but the deserialize > only happens at maximum once (after an actual fail over). The > PrePassivate/PostActivate just doesn't work well with most of this > situations. > > > LieGrue, > strub > > > > On Sunday, 28 December 2014, 16:21, John D. Ament > wrote: > > > > > > > >What would cluster have to do with it? I believe standard practice > (since EE doesn't define "cluster") is that when an EJB is used in a > cluster, it's expected that SFSB's get replicated to other nodes w/ state > in tact. So the bean wouldn't be "re-activated" per se. > > > > > >On Sun Dec 28 2014 at 10:06:16 AM Romain Manni-Bucau < > rmannibucau at gmail.com> wrote: > > > >Issue with XActivate is nothing is specified on what does mean activate > (think to a cluster) > >>Le 28 d?c. 2014 13:52, "John D. Ament" a ?crit > : > >> > >> > >>PostActivate/PrePassivate are only applicable to EJBs (as of now). EJBs > work off of a pool of objects and these life cycle methods are typically > used (from the use cases I've dealt with them) to initiate or destroy some > end user data for the context in which they are used. > >>> > >>> > >>> > >>>I think you might be thinking of PostConstruct/PreDestroy which match > to the CDI/ManagedBean paradigm better. There's no pool of these objects > around, they simply get created and destroyed when done. For each of the > scopes you mentioned, I would use a PostConstruct/PreDestroy method to do > the same thing. > >>> > >>> > >>>John > >>> > >>>On Sun Dec 28 2014 at 7:39:14 AM Antonio Goncalves < > antonio.goncalves at gmail.com> wrote: > >>> > >>>Hi all, > >>>> > >>>> > >>>>I was playing with @SessionScoped beans... and wondered if > @PostActivate, @PrePassivate and @Remove would make sense in JSR 250 ? > >>>> > >>>> > >>>>At the moment these annotations belong to the javax.ejb package and > are only used in @Stateful EJBs. With CDI scopes, we end up with a few > "stateful" scopes (@SessionScoped, but also @ConversationScoped, > @ViewScoped...) so why not having the same functionality in CDI ? > @PreDestroy and @PostConstruct are already part of JSR 250. So why not > having @PostActivate and @PrePassivate as well so they could be used in > every bean ? > >>>> > >>>> > >>>>BTW, while I was playing with @SessionScoped beans, I asked Antoine to > show me how to remove a bean from the session. It's only a few lines of > code, but again, why not having a @Remove annotation that does that (the > exact same one of javax.ejb.Remove) ? > >>>> > >>>> > >>>> > >>>>To summarize, why not taking some of those stateful EJB concerns back > to JSR 250 so they could be used anywhere ? > >>>> > >>>> > >>>>Any thoughts ? > >>>> > >>>>-- > >>>> > >>>>Antonio Goncalves > >>>>Software architect, Java Champion and Pluralsight author > >>>> > >>>>Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France > _______________________________________________ > >>>>cdi-dev mailing list > >>>>cdi-dev at lists.jboss.org > >>>>https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>> > >>>>Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 (http://www.apache.org/ > licenses/LICENSE-2.0.html). For all other ideas provided on this list, > the provider waives all patent and other intellectual property rights > inherent in such information. > >>>_______________________________________________ > >>>cdi-dev mailing list > >>>cdi-dev at lists.jboss.org > >>>https://lists.jboss.org/mailman/listinfo/cdi-dev > >>> > >>>Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 (http://www.apache.org/ > licenses/LICENSE-2.0.html). For all other ideas provided on this list, > the provider waives all patent and other intellectual property rights > inherent in such information. > >>> > > > >_______________________________________________ > >cdi-dev mailing list > >cdi-dev at lists.jboss.org > >https://lists.jboss.org/mailman/listinfo/cdi-dev > > > >Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 (http://www.apache.org/ > licenses/LICENSE-2.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/20141228/dcd23f12/attachment-0001.html From rmannibucau at gmail.com Sun Dec 28 11:14:32 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sun, 28 Dec 2014 17:14:32 +0100 Subject: [cdi-dev] Would @PostActivate, @PrePassivate and @Remove make sense in JSR 250 ? In-Reply-To: References: <1329913386.2000949.1419782800705.JavaMail.yahoo@jws11161.mail.ir2.yahoo.com> Message-ID: not really the points are: 1) do we want a big bundle in common annotations? 2) are these annotations used enough to be common? Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-12-28 17:08 GMT+01:00 John D. Ament : > Seems like the clustering topic is going off course compared to Antonio's > original question... > > > On Sun Dec 28 2014 at 11:06:42 AM Mark Struberg wrote: >> >> I agree with Romain. >> >> @John >> >> The problem is that there are many different kind of clusters. >> And with many of them the serialize/deserialize are not 'symmetric' >> >> >> Think about having e.g. having sticky sessions and a memcached which gets >> each session pushed to after each request. And if there really is a node >> outage then the load balancer will move the traffic from this node to >> another one. On this new node the first thing is to try to load the session >> from the memcached. And only if there is no such a session it will create a >> fresh one (ofc rewrite the sessionId to allow subsequent fails). >> >> In this scenario you have multiple serializations, but the deserialize >> only happens at maximum once (after an actual fail over). The >> PrePassivate/PostActivate just doesn't work well with most of this >> situations. >> >> >> LieGrue, >> strub >> >> >> >> On Sunday, 28 December 2014, 16:21, John D. Ament >> wrote: >> >> >> > >> > >> >What would cluster have to do with it? I believe standard practice >> > (since EE doesn't define "cluster") is that when an EJB is used in a >> > cluster, it's expected that SFSB's get replicated to other nodes w/ state in >> > tact. So the bean wouldn't be "re-activated" per se. >> > >> > >> >On Sun Dec 28 2014 at 10:06:16 AM Romain Manni-Bucau >> > wrote: >> > >> >Issue with XActivate is nothing is specified on what does mean activate >> > (think to a cluster) >> >>Le 28 d?c. 2014 13:52, "John D. Ament" a ?crit >> >> : >> >> >> >> >> >>PostActivate/PrePassivate are only applicable to EJBs (as of now). EJBs >> >> work off of a pool of objects and these life cycle methods are typically >> >> used (from the use cases I've dealt with them) to initiate or destroy some >> >> end user data for the context in which they are used. >> >>> >> >>> >> >>> >> >>>I think you might be thinking of PostConstruct/PreDestroy which match >> >>> to the CDI/ManagedBean paradigm better. There's no pool of these objects >> >>> around, they simply get created and destroyed when done. For each of the >> >>> scopes you mentioned, I would use a PostConstruct/PreDestroy method to do >> >>> the same thing. >> >>> >> >>> >> >>>John >> >>> >> >>>On Sun Dec 28 2014 at 7:39:14 AM Antonio Goncalves >> >>> wrote: >> >>> >> >>>Hi all, >> >>>> >> >>>> >> >>>>I was playing with @SessionScoped beans... and wondered if >> >>>> @PostActivate, @PrePassivate and @Remove would make sense in JSR 250 ? >> >>>> >> >>>> >> >>>>At the moment these annotations belong to the javax.ejb package and >> >>>> are only used in @Stateful EJBs. With CDI scopes, we end up with a few >> >>>> "stateful" scopes (@SessionScoped, but also @ConversationScoped, >> >>>> @ViewScoped...) so why not having the same functionality in CDI ? >> >>>> @PreDestroy and @PostConstruct are already part of JSR 250. So why not >> >>>> having @PostActivate and @PrePassivate as well so they could be used in >> >>>> every bean ? >> >>>> >> >>>> >> >>>>BTW, while I was playing with @SessionScoped beans, I asked Antoine to >> >>>> show me how to remove a bean from the session. It's only a few lines of >> >>>> code, but again, why not having a @Remove annotation that does that (the >> >>>> exact same one of javax.ejb.Remove) ? >> >>>> >> >>>> >> >>>> >> >>>>To summarize, why not taking some of those stateful EJB concerns back >> >>>> to JSR 250 so they could be used anywhere ? >> >>>> >> >>>> >> >>>>Any thoughts ? >> >>>> >> >>>>-- >> >>>> >> >>>>Antonio Goncalves >> >>>>Software architect, Java Champion and Pluralsight author >> >>>> >> >>>>Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx >> >>>> France >> _______________________________________________ >> >>>>cdi-dev mailing list >> >>>>cdi-dev at lists.jboss.org >> >>>>https://lists.jboss.org/mailman/listinfo/cdi-dev >> >>>> >> >>>>Note that for all code provided on this list, the provider licenses >> >>>> the code under the Apache License, Version 2 >> >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> >>>> provided on this list, the provider waives all patent and other intellectual >> >>>> property rights inherent in such information. >> >>>_______________________________________________ >> >>>cdi-dev mailing list >> >>>cdi-dev at lists.jboss.org >> >>>https://lists.jboss.org/mailman/listinfo/cdi-dev >> >>> >> >>>Note that for all code provided on this list, the provider licenses the >> >>> code under the Apache License, Version 2 >> >>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> >>> provided on this list, the provider waives all patent and other intellectual >> >>> property rights inherent in such information. >> >>> >> > >> >_______________________________________________ >> >cdi-dev mailing list >> >cdi-dev at lists.jboss.org >> >https://lists.jboss.org/mailman/listinfo/cdi-dev >> > >> >Note that for all code provided on this list, the provider licenses the >> > code under the Apache License, Version 2 >> > (http://www.apache.org/licenses/LICENSE-2.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 Sun Dec 28 11:21:17 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Sun, 28 Dec 2014 17:21:17 +0100 Subject: [cdi-dev] Would @PostActivate, @PrePassivate and @Remove make sense in JSR 250 ? In-Reply-To: References: Message-ID: Hi, On Sun, Dec 28, 2014 at 1:52 PM, John D. Ament wrote: > EJBs work off of a pool of objects and these life cycle methods are > typically used (from the use cases I've dealt with them) to initiate or > destroy some end user data for the context in which they are used. > @PrePassivate/@PostActivate are used with @Stateful beans, which being unique instances are far less likely to be pooled. Pools are mostly used for @Stateless beans (if pools are used at all, the spec doesn't mandate those). Kind regards, Arjan Tijms > > I think you might be thinking of PostConstruct/PreDestroy which match to > the CDI/ManagedBean paradigm better. There's no pool of these objects > around, they simply get created and destroyed when done. For each of the > scopes you mentioned, I would use a PostConstruct/PreDestroy method to do > the same thing. > > John > > On Sun Dec 28 2014 at 7:39:14 AM Antonio Goncalves < > antonio.goncalves at gmail.com> wrote: > >> Hi all, >> >> I was playing with @SessionScoped beans... and wondered if @PostActivate, >> @PrePassivate and @Remove would make sense in JSR 250 ? >> >> At the moment these annotations belong to the javax.ejb package and are >> only used in @Stateful EJBs. With CDI scopes, we end up with a few >> "stateful" scopes (@SessionScoped, but also @ConversationScoped, >> @ViewScoped...) so why not having the same functionality in CDI ? >> @PreDestroy and @PostConstruct are already part of JSR 250. So why not >> having @PostActivate and @PrePassivate as well so they could be used in >> every bean ? >> >> BTW, while I was playing with @SessionScoped beans, I asked Antoine to >> show me how to remove a bean from the session. It's only a few lines of >> code, but again, why not having a @Remove annotation that does that (the >> exact same one of javax.ejb.Remove) ? >> >> To summarize, why not taking some of those stateful EJB concerns back to >> JSR 250 so they could be used anywhere ? >> >> Any thoughts ? >> >> -- >> Antonio Goncalves >> Software architect, Java Champion and Pluralsight author >> >> Web site | Twitter >> | LinkedIn >> | Pluralsight >> | Paris >> JUG | Devoxx France >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 (http://www.apache.org/ >> licenses/LICENSE-2.0.html). For all other ideas provided on this list, >> the provider waives all patent and other intellectual property rights >> inherent in such information. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141228/0c76095f/attachment.html From antonio.goncalves at gmail.com Sun Dec 28 11:42:50 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Sun, 28 Dec 2014 17:42:50 +0100 Subject: [cdi-dev] Would @PostActivate, @PrePassivate and @Remove make sense in JSR 250 ? Message-ID: I should have explained my PoV a bit better. I'm trying to take the EJB services, extract them, see if they could benefit for other components, if yes, in which spec could they go. Today, there is less and less difference between : @Stateful @SessionScoped public class MySessionBean { @PersistenceContext EntityManager em; ... } And : @Transactional @SessionScoped public class MySessionBean { @PersistenceContext EntityManager em; ... } So I wonder if it would make sense to bother with @PostActivate, @PrePassivate. I could see the benefit of @Remove though. Antonio On Sun, Dec 28, 2014 at 5:21 PM, arjan tijms wrote: > Hi, > > On Sun, Dec 28, 2014 at 1:52 PM, John D. Ament > wrote: > >> EJBs work off of a pool of objects and these life cycle methods are >> typically used (from the use cases I've dealt with them) to initiate or >> destroy some end user data for the context in which they are used. >> > > @PrePassivate/@PostActivate are used with @Stateful beans, which being > unique instances are far less likely to be pooled. Pools are mostly used > for @Stateless beans (if pools are used at all, the spec doesn't mandate > those). > > Kind regards, > Arjan Tijms > > > >> >> I think you might be thinking of PostConstruct/PreDestroy which match to >> the CDI/ManagedBean paradigm better. There's no pool of these objects >> around, they simply get created and destroyed when done. For each of the >> scopes you mentioned, I would use a PostConstruct/PreDestroy method to do >> the same thing. >> >> John >> >> On Sun Dec 28 2014 at 7:39:14 AM Antonio Goncalves < >> antonio.goncalves at gmail.com> wrote: >> >>> Hi all, >>> >>> I was playing with @SessionScoped beans... and wondered if >>> @PostActivate, @PrePassivate and @Remove would make sense in JSR 250 ? >>> >>> At the moment these annotations belong to the javax.ejb package and are >>> only used in @Stateful EJBs. With CDI scopes, we end up with a few >>> "stateful" scopes (@SessionScoped, but also @ConversationScoped, >>> @ViewScoped...) so why not having the same functionality in CDI ? >>> @PreDestroy and @PostConstruct are already part of JSR 250. So why not >>> having @PostActivate and @PrePassivate as well so they could be used in >>> every bean ? >>> >>> BTW, while I was playing with @SessionScoped beans, I asked Antoine to >>> show me how to remove a bean from the session. It's only a few lines of >>> code, but again, why not having a @Remove annotation that does that (the >>> exact same one of javax.ejb.Remove) ? >>> >>> To summarize, why not taking some of those stateful EJB concerns back to >>> JSR 250 so they could be used anywhere ? >>> >>> Any thoughts ? >>> >>> -- >>> Antonio Goncalves >>> Software architect, Java Champion and Pluralsight author >>> >>> Web site | Twitter >>> | LinkedIn >>> | Pluralsight >>> | Paris >>> JUG | Devoxx France >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 (http://www.apache.org/ >>> licenses/LICENSE-2.0.html). For all other ideas provided on this list, >>> the provider waives all patent and other intellectual property rights >>> inherent in such information. >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> > > -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141228/69ad5561/attachment-0001.html From rmannibucau at gmail.com Sun Dec 28 11:45:02 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sun, 28 Dec 2014 17:45:02 +0100 Subject: [cdi-dev] Would @PostActivate, @PrePassivate and @Remove make sense in JSR 250 ? In-Reply-To: References: Message-ID: you surely forgot a detail only @Stateful handle: extended PC. That's where stateful makes sense and @Transactional doesn't help. Then there is nowhere else ATM where passivation is defined (even not in CDI with passivable things). Do you plan to specify it in CDI? Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-12-28 17:42 GMT+01:00 Antonio Goncalves : > I should have explained my PoV a bit better. I'm trying to take the EJB > services, extract them, see if they could benefit for other components, if > yes, in which spec could they go. > > Today, there is less and less difference between : > > @Stateful > @SessionScoped > public class MySessionBean { > @PersistenceContext > EntityManager em; > ... > } > > And : > > @Transactional > @SessionScoped > public class MySessionBean { > @PersistenceContext > EntityManager em; > ... > } > > So I wonder if it would make sense to bother with @PostActivate, > @PrePassivate. I could see the benefit of @Remove though. > > Antonio > > > On Sun, Dec 28, 2014 at 5:21 PM, arjan tijms wrote: >> >> Hi, >> >> On Sun, Dec 28, 2014 at 1:52 PM, John D. Ament >> wrote: >>> >>> EJBs work off of a pool of objects and these life cycle methods are >>> typically used (from the use cases I've dealt with them) to initiate or >>> destroy some end user data for the context in which they are used. >> >> >> @PrePassivate/@PostActivate are used with @Stateful beans, which being >> unique instances are far less likely to be pooled. Pools are mostly used for >> @Stateless beans (if pools are used at all, the spec doesn't mandate those). >> >> Kind regards, >> Arjan Tijms >> >> >>> >>> >>> I think you might be thinking of PostConstruct/PreDestroy which match to >>> the CDI/ManagedBean paradigm better. There's no pool of these objects >>> around, they simply get created and destroyed when done. For each of the >>> scopes you mentioned, I would use a PostConstruct/PreDestroy method to do >>> the same thing. >>> >>> John >>> >>> On Sun Dec 28 2014 at 7:39:14 AM Antonio Goncalves >>> wrote: >>>> >>>> Hi all, >>>> >>>> I was playing with @SessionScoped beans... and wondered if >>>> @PostActivate, @PrePassivate and @Remove would make sense in JSR 250 ? >>>> >>>> At the moment these annotations belong to the javax.ejb package and are >>>> only used in @Stateful EJBs. With CDI scopes, we end up with a few >>>> "stateful" scopes (@SessionScoped, but also @ConversationScoped, >>>> @ViewScoped...) so why not having the same functionality in CDI ? >>>> @PreDestroy and @PostConstruct are already part of JSR 250. So why not >>>> having @PostActivate and @PrePassivate as well so they could be used in >>>> every bean ? >>>> >>>> BTW, while I was playing with @SessionScoped beans, I asked Antoine to >>>> show me how to remove a bean from the session. It's only a few lines of >>>> code, but again, why not having a @Remove annotation that does that (the >>>> exact same one of javax.ejb.Remove) ? >>>> >>>> To summarize, why not taking some of those stateful EJB concerns back to >>>> JSR 250 so they could be used anywhere ? >>>> >>>> Any thoughts ? >>>> >>>> -- >>>> Antonio Goncalves >>>> Software architect, Java Champion and Pluralsight author >>>> >>>> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider licenses the >>>> code under the Apache License, Version 2 >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>>> provided on this list, the provider waives all patent and other intellectual >>>> property rights inherent in such information. >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 >>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>> provided on this list, the provider waives all patent and other intellectual >>> property rights inherent in such information. >> >> > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code > under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other intellectual > property rights inherent in such information. From antonio.goncalves at gmail.com Sun Dec 28 12:04:57 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Sun, 28 Dec 2014 18:04:57 +0100 Subject: [cdi-dev] Would @PostActivate, @PrePassivate and @Remove make sense in JSR 250 ? In-Reply-To: References: Message-ID: Yes, really good point : Extended Persistence Context.... Hum.... Antonio On Sun, Dec 28, 2014 at 5:45 PM, Romain Manni-Bucau wrote: > you surely forgot a detail only @Stateful handle: extended PC. That's > where stateful makes sense and @Transactional doesn't help. Then there > is nowhere else ATM where passivation is defined (even not in CDI with > passivable things). Do you plan to specify it in CDI? > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2014-12-28 17:42 GMT+01:00 Antonio Goncalves >: > > I should have explained my PoV a bit better. I'm trying to take the EJB > > services, extract them, see if they could benefit for other components, > if > > yes, in which spec could they go. > > > > Today, there is less and less difference between : > > > > @Stateful > > @SessionScoped > > public class MySessionBean { > > @PersistenceContext > > EntityManager em; > > ... > > } > > > > And : > > > > @Transactional > > @SessionScoped > > public class MySessionBean { > > @PersistenceContext > > EntityManager em; > > ... > > } > > > > So I wonder if it would make sense to bother with @PostActivate, > > @PrePassivate. I could see the benefit of @Remove though. > > > > Antonio > > > > > > On Sun, Dec 28, 2014 at 5:21 PM, arjan tijms > wrote: > >> > >> Hi, > >> > >> On Sun, Dec 28, 2014 at 1:52 PM, John D. Ament > >> wrote: > >>> > >>> EJBs work off of a pool of objects and these life cycle methods are > >>> typically used (from the use cases I've dealt with them) to initiate or > >>> destroy some end user data for the context in which they are used. > >> > >> > >> @PrePassivate/@PostActivate are used with @Stateful beans, which being > >> unique instances are far less likely to be pooled. Pools are mostly > used for > >> @Stateless beans (if pools are used at all, the spec doesn't mandate > those). > >> > >> Kind regards, > >> Arjan Tijms > >> > >> > >>> > >>> > >>> I think you might be thinking of PostConstruct/PreDestroy which match > to > >>> the CDI/ManagedBean paradigm better. There's no pool of these objects > >>> around, they simply get created and destroyed when done. For each of > the > >>> scopes you mentioned, I would use a PostConstruct/PreDestroy method to > do > >>> the same thing. > >>> > >>> John > >>> > >>> On Sun Dec 28 2014 at 7:39:14 AM Antonio Goncalves > >>> wrote: > >>>> > >>>> Hi all, > >>>> > >>>> I was playing with @SessionScoped beans... and wondered if > >>>> @PostActivate, @PrePassivate and @Remove would make sense in JSR 250 ? > >>>> > >>>> At the moment these annotations belong to the javax.ejb package and > are > >>>> only used in @Stateful EJBs. With CDI scopes, we end up with a few > >>>> "stateful" scopes (@SessionScoped, but also @ConversationScoped, > >>>> @ViewScoped...) so why not having the same functionality in CDI ? > >>>> @PreDestroy and @PostConstruct are already part of JSR 250. So why not > >>>> having @PostActivate and @PrePassivate as well so they could be used > in > >>>> every bean ? > >>>> > >>>> BTW, while I was playing with @SessionScoped beans, I asked Antoine to > >>>> show me how to remove a bean from the session. It's only a few lines > of > >>>> code, but again, why not having a @Remove annotation that does that > (the > >>>> exact same one of javax.ejb.Remove) ? > >>>> > >>>> To summarize, why not taking some of those stateful EJB concerns back > to > >>>> JSR 250 so they could be used anywhere ? > >>>> > >>>> Any thoughts ? > >>>> > >>>> -- > >>>> Antonio Goncalves > >>>> Software architect, Java Champion and Pluralsight author > >>>> > >>>> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx > France > >>>> _______________________________________________ > >>>> cdi-dev mailing list > >>>> cdi-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>> > >>>> Note that for all code provided on this list, the provider licenses > the > >>>> code under the Apache License, Version 2 > >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > ideas > >>>> provided on this list, the provider waives all patent and other > intellectual > >>>> property rights inherent in such information. > >>> > >>> > >>> _______________________________________________ > >>> cdi-dev mailing list > >>> cdi-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>> > >>> Note that for all code provided on this list, the provider licenses the > >>> code under the Apache License, Version 2 > >>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > >>> provided on this list, the provider waives all patent and other > intellectual > >>> property rights inherent in such information. > >> > >> > > > > > > > > -- > > Antonio Goncalves > > Software architect, Java Champion and Pluralsight author > > > > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code > > under the Apache License, Version 2 > > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > > provided on this list, the provider waives all patent and other > intellectual > > property rights inherent in such information. > -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141228/02d6dcf8/attachment.html From rmannibucau at gmail.com Mon Dec 29 13:54:18 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 29 Dec 2014 19:54:18 +0100 Subject: [cdi-dev] where is defined javax.enterprise.context.conversation.id? Message-ID: Hi guys didnt find in CDI and JSF PDFs where is defined "javax.enterprise.context.conversation.id". Seems it should be available in ELs. Do you have any pointer please? Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau From antonio.goncalves at gmail.com Mon Dec 29 15:39:44 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Mon, 29 Dec 2014 21:39:44 +0100 Subject: [cdi-dev] where is defined javax.enterprise.context.conversation.id? In-Reply-To: References: Message-ID: Nothing in JSF nor in Servlet, but in CDI 1.2 Specification : *6.7.4. Conversation context lifecycle* *(...)* *The long-running conversation associated with a* *request may be propagated to any Servlet request via use of a request parameter named cid* *containing the unique identifier of the conversation. In this case, the application must manage this* *request parameter.* *(...)* *This is accomplished via use of a request parameter named cid containing the unique* *identifier of the conversation.* *(...)* On Mon, Dec 29, 2014 at 7:54 PM, Romain Manni-Bucau wrote: > Hi guys > > didnt find in CDI and JSF PDFs where is defined > "javax.enterprise.context.conversation.id". Seems it should be > available in ELs. > > Do you have any pointer please? > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141229/73b5381c/attachment-0001.html From rmannibucau at gmail.com Mon Dec 29 17:10:49 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 29 Dec 2014 23:10:49 +0100 Subject: [cdi-dev] where is defined javax.enterprise.context.conversation.id? In-Reply-To: References: Message-ID: Hmm this is the url param not the el one called javax.enterprise.context.conversation.id used in cdi tck and weld doc. Le 29 d?c. 2014 21:40, "Antonio Goncalves" a ?crit : > Nothing in JSF nor in Servlet, but in CDI 1.2 Specification : > > *6.7.4. Conversation context lifecycle* > *(...)* > *The long-running conversation associated with a* > *request may be propagated to any Servlet request via use of a request > parameter named cid* > *containing the unique identifier of the conversation. In this case, the > application must manage this* > *request parameter.* > *(...)* > *This is accomplished via use of a request parameter named cid containing > the unique* > *identifier of the conversation.* > *(...)* > > On Mon, Dec 29, 2014 at 7:54 PM, Romain Manni-Bucau > wrote: > >> Hi guys >> >> didnt find in CDI and JSF PDFs where is defined >> "javax.enterprise.context.conversation.id". Seems it should be >> available in ELs. >> >> Do you have any pointer please? >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter > | LinkedIn > | Pluralsight > | Paris > JUG | Devoxx France > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141229/a0617acf/attachment.html From struberg at yahoo.de Tue Dec 30 04:57:28 2014 From: struberg at yahoo.de (Mark Struberg) Date: Tue, 30 Dec 2014 09:57:28 +0000 (UTC) Subject: [cdi-dev] where is defined javax.enterprise.context.conversation.id? In-Reply-To: References: Message-ID: <1331379549.2620478.1419933448581.JavaMail.yahoo@jws11105.mail.ir2.yahoo.com> cid is a different thing. But I did nowhere (spec and api) find the one mentioned by Romain. So I think it's not specified and we need to exclude this test. LieGrue, strub On Monday, 29 December 2014, 21:41, Antonio Goncalves wrote: > > >Nothing in JSF nor in Servlet, but in CDI 1.2 Specification : > > >6.7.4. Conversation context lifecycle >(...) >The long-running conversation associated with a >request may be propagated to any Servlet request via use of a request parameter named cid >containing the unique identifier of the conversation. In this case, the application must manage this >request parameter. >(...) > >This is accomplished via use of a request parameter named cid containing the unique >identifier of the conversation. >(...) > > > >On Mon, Dec 29, 2014 at 7:54 PM, Romain Manni-Bucau wrote: > >Hi guys >> >>didnt find in CDI and JSF PDFs where is defined >>"javax.enterprise.context.conversation.id". Seems it should be >>available in ELs. >> >>Do you have any pointer please? >> >> >>Romain Manni-Bucau >>@rmannibucau >>http://www.tomitribe.com >>http://rmannibucau.wordpress.com >>https://github.com/rmannibucau >>_______________________________________________ >>cdi-dev mailing list >>cdi-dev at lists.jboss.org >>https://lists.jboss.org/mailman/listinfo/cdi-dev >> >>Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> > > > >-- > >Antonio Goncalves >Software architect, Java Champion and Pluralsight author > >Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France > >_______________________________________________ >cdi-dev mailing list >cdi-dev at lists.jboss.org >https://lists.jboss.org/mailman/listinfo/cdi-dev > >Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > From antonio.goncalves at gmail.com Wed Dec 17 01:00:39 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Wed, 17 Dec 2014 06:00:39 -0000 Subject: [cdi-dev] PermGen with JBoss add-on In-Reply-To: References: Message-ID: Wrong ML ;o) Antonio On Wed, Dec 17, 2014 at 2:03 AM, John D. Ament wrote: > > Add on for? Or wrong mailing list... ? ;-) > > On Tue Dec 16 2014 at 3:42:46 PM Antonio Goncalves < > antonio.goncalves at gmail.com> wrote: > >> Hi all, >> >> The other day on #IRC I mentioned having PermGen issues with the JBossAS >> add-on. It's confirmed. During the HoL there are plenty of people who had >> the same issue : install the JBoss add-on, start wildfly 8.1, build the >> app, deploy it, go to the index.html page (fine), click on an Entity, bang >> ! PermGen >> >> Alexis Hassler investigated it during the lab (see below). Basically, no >> matter what PermGen you set, it's not taken into account. >> >> Again, I really think this add-on should be looked after carefully, it's >> very unstable. >> >> Antonio >> >> ---------- Forwarded message ---------- >> From: Alexis Hassler >> Date: Tue, Nov 11, 2014 at 11:37 AM >> Subject: Re: Forge + Wildfly VM arguments >> To: Antonio Goncalves >> >> >> Pas de changement avec >> as-setup --server wildfly8 --installDir /opt/java/wildfly-8.1.0.Final/ >> --jvmargs "-Xmx512m -XX:MaxPermSize=256m" >> >> >> Alexis >> http://www.jtips.info, http://blog.alexis-hassler.com, >> http://www.lyonjug.org >> >> 2014-11-11 11:22 GMT+01:00 Alexis Hassler : >> >>> Avec un wf externe, d?marr? avec as-start. >>> >>> >>> >>> ? >>> Pour info, en d?marrant un wf 8.1 en ligne de commande "normale" : >>> -D[Standalone] -Xms64m -Xmx512m -XX:MaxPermSize=256m >>> -Djava.net.preferIPv4Stack=true >>> -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true >>> -Dorg.jboss.boot.log.file=/opt/java/wildfly-8.1.0.Final/standalone/log/server.log >>> -Dlogging.configuration=file:/opt/java/wildfly-8.1.0.Final/standalone/configuration/logging.properties >>> >>> Alexis >>> http://www.jtips.info, http://blog.alexis-hassler.com, >>> http://www.lyonjug.org >>> >>> >> >> >> >> -- >> Antonio Goncalves >> Software architect, Java Champion and Pluralsight author >> >> Web site | Twitter >> | LinkedIn >> | Pluralsight >> | Paris >> JUG | Devoxx France >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 (http://www.apache.org/ >> licenses/LICENSE-2.0.html). For all other ideas provided on this list, >> the provider waives all patent and other intellectual property rights >> inherent in such information. > > -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141217/16a25aa7/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: forge-wf-jconsole.png Type: image/png Size: 414948 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20141217/16a25aa7/attachment-0001.png