From issues at jboss.org Mon Feb 1 06:10:00 2016 From: issues at jboss.org (Arjan t (JIRA)) Date: Mon, 1 Feb 2016 06:10:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar as 'implicit bean archive'? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13156965#comment-13156965 ] Arjan t commented on CDI-579: ----------------------------- {quote}By adding a beans.xml with bd 'none' it would get picked up by CDI-1.0 containers...{quote} Indeed, however JSF 2.3 explicitly requires Java EE 8 so those old containers would not be an issue so much. Still something to be aware of though. Thanks! > Extension disqualifies a jar as 'implicit bean archive'? > -------------------------------------------------------- > > Key: CDI-579 > URL: https://issues.jboss.org/browse/CDI-579 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Mark Struberg > Priority: Minor > > The bean-discovery-wording is a bit odd. > This has been in since CDI-1.1 > {code} > An archive which: > ? contains a beans.xml file with the bean-discovery-mode of none, or, > ? contains an extension and no beans.xml file is not a bean archive. > is not a bean archive. > {code} > That means even if you have an @ApplicationScoped MyService class in a jar which has a single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least according to this wording? > Feels mega-weird to me and might conflict with the implicit beans archive definition a few lines below. > I'm pretty sure in OWB we will pick those beans up. How does Weld behave? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Feb 1 11:02:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 1 Feb 2016 11:02:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157171#comment-13157171 ] Martin Kouba commented on CDI-420: ---------------------------------- >From the bootstrap performance point of view the {{annotated}} mode allows much better optimization as you don't need to load "unsuitable" classes and fire PAT at all (so if you really care about bootstrap time of a large application, the workaround mentioned in one of the previous comments is the way to go). Memory footprint would be the same compared to {{annotated}}. Otherwise sounds good. Except for the mode name - "scoped" does not say much. And you may end with a bean class picked up even if it does not define any scope at all (e.g. if you add a stereotype annotation without scope to a class which previously has no bean defining annotation declared). Theoretically, we could also extend the meaning of {{@WithAnnotations}} and make all the annotation values bean defining annotations. E.g. once you add an extension with PAT annotated with {{@WithAnnotations(MessageBundle.class)}} then {{MessageBundle}} becomes a bean defining annotation. Just an idea I haven't thought about this properly. > add a bean-discovery-mode 'scoped' > ---------------------------------- > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: TBD > Reporter: Mark Struberg > Fix For: 2.0 (discussion) > > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > ? each Java class, interface or enum deployed in an explicit bean archive, and > ? each Java class with a bean defining annotation in an implicit bean archive. > ? each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Feb 1 13:05:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Mon, 1 Feb 2016 13:05:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157243#comment-13157243 ] Mark Struberg commented on CDI-420: ----------------------------------- Most of the performance gets lost by parsing the zipstreams from the jar. We also need to check the scopes + stereotypes or 'annotated' as well. The only difference in practice is to create the AnnotatedType + fire the PAT events. Of course this is a bit more than 'annotated', but not much. But the huge benefit is that most CDI Extensions would work with that mode, whereas they are broken with 'annotated'. Regarding using @WithAnnotations as input for the scanner. Imo that would be a chicken-egg problem. > add a bean-discovery-mode 'scoped' > ---------------------------------- > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: TBD > Reporter: Mark Struberg > Fix For: 2.0 (discussion) > > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > ? each Java class, interface or enum deployed in an explicit bean archive, and > ? each Java class with a bean defining annotation in an implicit bean archive. > ? each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Feb 1 17:28:00 2016 From: issues at jboss.org (Emily Jiang (JIRA)) Date: Mon, 1 Feb 2016 17:28:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157342#comment-13157342 ] Emily Jiang commented on CDI-420: --------------------------------- Sounds like a good idea! I agree with Martin that the name 'scoped' is not meaningful in this scenario. How about bean-discovery-mode = 'scanning', which means scanning each classes? As a result, only annotated classes are classified as beans while all other classes are scanned and the PAT events are fired. I am not 100% happy with the 'scanning'. Just thought to throw some random ideas. > add a bean-discovery-mode 'scoped' > ---------------------------------- > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: TBD > Reporter: Mark Struberg > Fix For: 2.0 (discussion) > > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > ? each Java class, interface or enum deployed in an explicit bean archive, and > ? each Java class with a bean defining annotation in an implicit bean archive. > ? each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Feb 2 03:19:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 2 Feb 2016 03:19:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157413#comment-13157413 ] Martin Kouba commented on CDI-420: ---------------------------------- bq. The only difference in practice is to create the AnnotatedType + fire the PAT events... Well, if a bytecode scanning lib such as [jandex|https://github.com/wildfly/jandex] is used then a user may supply a pre-built index and you only need to load the index from the jar to be able to skip irrelevant classes. But you're right that the difference probably will not be significant. bq. But the huge benefit is that most CDI Extensions would work... Maybe we should build a list of extensions not working with {{annotated}} and add a FAQ entry on [http://cdi-spec.org/]? bq. Regarding using @WithAnnotations as input for the scanner. Imo that would be a chicken-egg problem. Well, even now an extension is allowed to add a bean defining annotation, see for example {{BeforeBeanDiscovery.addStereotype()}}. But you're right that it's problematic (Weld does not support this in all environments atm). bq. How about bean-discovery-mode = 'scanning'... Sounds better. Let's continue with ideas. What about {{activated}} in the sense that a type is activated if it has a bean defining annotation after the type discovery finished? > add a bean-discovery-mode 'scoped' > ---------------------------------- > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: TBD > Reporter: Mark Struberg > Fix For: 2.0 (discussion) > > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > ? each Java class, interface or enum deployed in an explicit bean archive, and > ? each Java class with a bean defining annotation in an implicit bean archive. > ? each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Feb 2 03:56:06 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Tue, 2 Feb 2016 03:56:06 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157439#comment-13157439 ] Mark Struberg commented on CDI-420: ----------------------------------- Regarding bean-discovery-mode="annotated": I _never_ saw this in any real world app. Because it makes so many problems. Think about e.g. DeltaSpike @MessageBundle, or all the JPA Archive things. There you just annotated an interface and let the Extension create a Proxy for it. Basically all those who use ProcessAnnotatedType as a 'scanning' tool. All this doesn't work > add a bean-discovery-mode 'scoped' > ---------------------------------- > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: TBD > Reporter: Mark Struberg > Fix For: 2.0 (discussion) > > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > ? each Java class, interface or enum deployed in an explicit bean archive, and > ? each Java class with a bean defining annotation in an implicit bean archive. > ? each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Feb 2 04:02:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Tue, 2 Feb 2016 04:02:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157439#comment-13157439 ] Mark Struberg edited comment on CDI-420 at 2/2/16 4:01 AM: ----------------------------------------------------------- Regarding bean-discovery-mode="annotated": I _never_ saw this in any real world app. Because it makes so many problems. Think about e.g. DeltaSpike @MessageBundle, or all the JPA Archive things. There you just annotated an interface and let the Extension create a Proxy for it. Basically all those who use ProcessAnnotatedType as a 'scanning' tool. All these Extensions don't work with 'annotated' - and there are many, both public and also tons of company internal ones. Ad 'scoped' vs 'scanning' vs whatever. I thought pretty long about it. My first take was 'explicit'. Because you have to explicitly define the classes you like to get picked up. Otoh this term doesn't define _what_ you need to define. For example: just an @Inject somewhere would be nuts as the detection would be pretty expensive. And this was the point which did lead me to 'scoped'. Because that's what you need to do: Define a Scope OR an annotation which leads to a defined default scope (decorator, interceptor or stereotype). Those are _very_ easy and fast to find and are very clear rules imo. But I'm happy to get further nominations ;) was (Author: struberg): Regarding bean-discovery-mode="annotated": I _never_ saw this in any real world app. Because it makes so many problems. Think about e.g. DeltaSpike @MessageBundle, or all the JPA Archive things. There you just annotated an interface and let the Extension create a Proxy for it. Basically all those who use ProcessAnnotatedType as a 'scanning' tool. All this doesn't work > add a bean-discovery-mode 'scoped' > ---------------------------------- > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: TBD > Reporter: Mark Struberg > Fix For: 2.0 (discussion) > > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > ? each Java class, interface or enum deployed in an explicit bean archive, and > ? each Java class with a bean defining annotation in an implicit bean archive. > ? each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Feb 2 04:07:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Tue, 2 Feb 2016 04:07:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157450#comment-13157450 ] Mark Struberg commented on CDI-420: ----------------------------------- Btw the pull request should also include a beans_2_0.xsd with the additional bean-discovery-mode. I skipped that for now as the change is trivial and there is another pull request open which adds this file. We just should not forget about it. > add a bean-discovery-mode 'scoped' > ---------------------------------- > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: TBD > Reporter: Mark Struberg > Fix For: 2.0 (discussion) > > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > ? each Java class, interface or enum deployed in an explicit bean archive, and > ? each Java class with a bean defining annotation in an implicit bean archive. > ? each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Feb 2 08:44:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Tue, 2 Feb 2016 08:44:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to producer methods In-Reply-To: References: Message-ID: Mark Struberg created CDI-580: --------------------------------- Summary: Allow interceptors and decorators to be applied to producer methods Key: CDI-580 URL: https://issues.jboss.org/browse/CDI-580 Project: CDI Specification Issues Issue Type: Feature Request Components: Beans Affects Versions: 2.0-EDR1 Reporter: Mark Struberg Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Feb 2 09:31:00 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Tue, 2 Feb 2016 09:31:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to producer methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157708#comment-13157708 ] Romain Manni-Bucau commented on CDI-580: ---------------------------------------- I would go with @Produces(allowProxying=true) or a flag like that for compatibility reason but +1 for the feature missing since 1.0! > Allow interceptors and decorators to be applied to producer methods > ------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Feb 2 09:49:00 2016 From: issues at jboss.org (Stephan Knitelius (JIRA)) Date: Tue, 2 Feb 2016 09:49:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to producer methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157723#comment-13157723 ] Stephan Knitelius commented on CDI-580: --------------------------------------- Maybe we should differentiate between Interceptors applied to the producer method and the created bean. Something like @Produces(interceptors={MyInterceptorAnnotation.class}); > Allow interceptors and decorators to be applied to producer methods > ------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Feb 2 09:53:01 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Tue, 2 Feb 2016 09:53:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to producer methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157728#comment-13157728 ] Romain Manni-Bucau commented on CDI-580: ---------------------------------------- I dont think so, the flag will be for new methods so the user controls it. If an issue 2.1 can add interceptors method but an extension could, worse case, change the model anyway. > Allow interceptors and decorators to be applied to producer methods > ------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Feb 2 11:28:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Tue, 2 Feb 2016 11:28:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to producer methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157826#comment-13157826 ] Mark Struberg commented on CDI-580: ----------------------------------- Yes, you could have an @Transactional which needs to get applied for the method invocation itself, and another interceptor, say @Logging, which gets applied to the produced instance. > Allow interceptors and decorators to be applied to producer methods > ------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Feb 3 03:19:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 3 Feb 2016 03:19:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to producer methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158047#comment-13158047 ] Martin Kouba commented on CDI-580: ---------------------------------- I remember that this has been discussed many times and the main problem was how to declare the interceptor bindings - because the "product" class usually cannot be modified. > Allow interceptors and decorators to be applied to producer methods > ------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Feb 3 04:58:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 3 Feb 2016 04:58:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-515) Allow to obtain Bean metadata from javax.enterprise.inject.Instance In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158096#comment-13158096 ] Antoine Sabot-Durand commented on CDI-515: ------------------------------------------ If we want to provide the same service than in 5.5.8 we need to provide a {{getBean(T)}} to allow retrieving a bean from one of its instance. IMO this would be far more useful. > Allow to obtain Bean metadata from javax.enterprise.inject.Instance > ------------------------------------------------------------------- > > Key: CDI-515 > URL: https://issues.jboss.org/browse/CDI-515 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Assignee: Martin Kouba > Fix For: 2.0 (proposed) > > > Sometimes it might be useful to obtain Bean metadata from the {{javax.enterprise.inject.Instance}} (similarly as 5.5.8. Bean metadata). The method could be named {{getBean()}} and should have similar restrictions like {{get()}} (e.g. throw {{UnsatisfiedResolutionException}} if appropriate). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Feb 3 05:16:01 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 3 Feb 2016 05:16:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-515) Allow to obtain Bean metadata from javax.enterprise.inject.Instance In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158110#comment-13158110 ] Martin Kouba commented on CDI-515: ---------------------------------- That would be way more complicated if possible at all. Let's assume you have two producers for dependent {{Foo}} and each specifies a different qualifer. Then you inject {{Instance}} and select Instance for qualifier {{@A}} and get instance of Foo, and select Instance for qualifier {{@B}} and get instance of Foo. How would you differentiate these instances? What happens if you pass Foo {{@B}} reference to the Instance for Foo {{@A}}? You would have to track all the instances provied by each Instance. > Allow to obtain Bean metadata from javax.enterprise.inject.Instance > ------------------------------------------------------------------- > > Key: CDI-515 > URL: https://issues.jboss.org/browse/CDI-515 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Assignee: Martin Kouba > Fix For: 2.0 (proposed) > > > Sometimes it might be useful to obtain Bean metadata from the {{javax.enterprise.inject.Instance}} (similarly as 5.5.8. Bean metadata). The method could be named {{getBean()}} and should have similar restrictions like {{get()}} (e.g. throw {{UnsatisfiedResolutionException}} if appropriate). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Feb 3 07:19:00 2016 From: issues at jboss.org (Stephan Knitelius (JIRA)) Date: Wed, 3 Feb 2016 07:19:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to producer methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158175#comment-13158175 ] Stephan Knitelius commented on CDI-580: --------------------------------------- [~mkouba] Missing default constructor or why? Wouldn't that be the same issue as when applying a normal scope to the product.... WELD-001435: Normal scoped bean class com.knitelius.NonDefaultConBean is not proxyable because it has no no-args constructor > Allow interceptors and decorators to be applied to producer methods > ------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Feb 3 07:26:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 3 Feb 2016 07:26:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to producer methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158179#comment-13158179 ] Martin Kouba commented on CDI-580: ---------------------------------- bq. Missing default constructor or why? No. Producers are often used for integration with third-party libraries where the classes are not annotated at all. > Allow interceptors and decorators to be applied to producer methods > ------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Feb 3 07:27:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 3 Feb 2016 07:27:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-580: ----------------------------- Summary: Allow interceptors and decorators to be applied to the return value of a producer method (was: Allow interceptors and decorators to be applied to producer methods) > Allow interceptors and decorators to be applied to the return value of a producer method > ---------------------------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Feb 3 07:32:00 2016 From: issues at jboss.org (Stephan Knitelius (JIRA)) Date: Wed, 3 Feb 2016 07:32:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158182#comment-13158182 ] Stephan Knitelius commented on CDI-580: --------------------------------------- That would be solved by defining the interceptors for the product as an attribute of the produces annotation. @Produces(interceptors={MyInterceptor.class}) > Allow interceptors and decorators to be applied to the return value of a producer method > ---------------------------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Feb 3 07:32:00 2016 From: issues at jboss.org (Stephan Knitelius (JIRA)) Date: Wed, 3 Feb 2016 07:32:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158182#comment-13158182 ] Stephan Knitelius edited comment on CDI-580 at 2/3/16 7:31 AM: --------------------------------------------------------------- That would be solved by defining the interceptors for the product as an attribute of the produces annotation. {code} @Produces(interceptors={MyInterceptor.class}) {code} was (Author: sknitelius): That would be solved by defining the interceptors for the product as an attribute of the produces annotation. @Produces(interceptors={MyInterceptor.class}) > Allow interceptors and decorators to be applied to the return value of a producer method > ---------------------------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Feb 3 07:33:00 2016 From: issues at jboss.org (Stephan Knitelius (JIRA)) Date: Wed, 3 Feb 2016 07:33:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158182#comment-13158182 ] Stephan Knitelius edited comment on CDI-580 at 2/3/16 7:32 AM: --------------------------------------------------------------- That would be solved by defining the interceptors for the product as an attribute of the produces annotation. {code} @Produces(interceptors={MyInterceptor.class}) {code} Or am I missing something else? was (Author: sknitelius): That would be solved by defining the interceptors for the product as an attribute of the produces annotation. {code} @Produces(interceptors={MyInterceptor.class}) {code} > Allow interceptors and decorators to be applied to the return value of a producer method > ---------------------------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Feb 3 07:45:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 3 Feb 2016 07:45:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158190#comment-13158190 ] Martin Kouba commented on CDI-580: ---------------------------------- Yep, but it's not very flexible as you can only associate the interceptor at the class level (all methods). This may be ok in most cases though. > Allow interceptors and decorators to be applied to the return value of a producer method > ---------------------------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Feb 3 07:48:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Wed, 3 Feb 2016 07:48:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158191#comment-13158191 ] John Ament commented on CDI-580: -------------------------------- [~martinkouba] respectfully I disagree. Good development practices around integration isolation say that I really only have one entry point to an external lib. It may be a use case for producer methods/fields, but its not the only one. In that specific case, I typically don't even provide that entry point as a bean. In the main thing I've been working on, the main use for a producer method is to provide convenience to a default implementation of some interface, based on outside configuration. In this case, I'm usually providing an instance of a bean with a different set of qualifiers for that look up. > Allow interceptors and decorators to be applied to the return value of a producer method > ---------------------------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Feb 3 07:50:00 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Wed, 3 Feb 2016 07:50:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158193#comment-13158193 ] Romain Manni-Bucau commented on CDI-580: ---------------------------------------- [~mkouba] agree it would work most of the time so the feature does worth it. BTW {code} @Produces(interceptors={MyInterceptor.class}) {code} is quite odd compared to the "natural": {code} @Interceptors(MyInterceptor.class) // this is the natural way to set interceptors IMHO @Produces(superFlagToRenameActivatingProxying = true) // activate interceptors and decorators {code} > Allow interceptors and decorators to be applied to the return value of a producer method > ---------------------------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Feb 3 08:59:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 3 Feb 2016 08:59:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-515) Allow to obtain Bean metadata from javax.enterprise.inject.Instance In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158257#comment-13158257 ] Antoine Sabot-Durand commented on CDI-515: ------------------------------------------ I don't see that limited to instances provided by a given Instance<>. Like you can use Instance.destroy() to destroy any instance today. A use case could be: obtaining metadata for a bean defined by a class you don't own. Today we store all bean instances to manage their lifecycle, so how difficult would it be to compare a given instance with these stored instances and retrieving the bean used to generated it. It's probably costly but could be very useful. > Allow to obtain Bean metadata from javax.enterprise.inject.Instance > ------------------------------------------------------------------- > > Key: CDI-515 > URL: https://issues.jboss.org/browse/CDI-515 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Assignee: Martin Kouba > Fix For: 2.0 (proposed) > > > Sometimes it might be useful to obtain Bean metadata from the {{javax.enterprise.inject.Instance}} (similarly as 5.5.8. Bean metadata). The method could be named {{getBean()}} and should have similar restrictions like {{get()}} (e.g. throw {{UnsatisfiedResolutionException}} if appropriate). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Feb 3 09:02:00 2016 From: issues at jboss.org (Stephan Knitelius (JIRA)) Date: Wed, 3 Feb 2016 09:02:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158259#comment-13158259 ] Stephan Knitelius commented on CDI-580: --------------------------------------- {code} @Interceptors(MyInterceptor.class) {code} Certainly looks better and more "natural" :) But its not self explanatory, are the interceptors defined in @Interceptor applied to the producer method or the produced bean... > Allow interceptors and decorators to be applied to the return value of a producer method > ---------------------------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Feb 3 09:08:00 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Wed, 3 Feb 2016 09:08:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158265#comment-13158265 ] Romain Manni-Bucau commented on CDI-580: ---------------------------------------- should be to the bean for a produced instance, there is no real other option until we get a full annotation model which would likely fit better extension API than annotation cause of its verbosity. > Allow interceptors and decorators to be applied to the return value of a producer method > ---------------------------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Feb 3 09:39:00 2016 From: issues at jboss.org (Emily Jiang (JIRA)) Date: Wed, 3 Feb 2016 09:39:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158286#comment-13158286 ] Emily Jiang commented on CDI-580: --------------------------------- If it is possible to support interceptors on a producer's returned value, I would prefer the following: @Produces(interceptors={MyInterceptor.class}) as it is clear that MyInterceptor is for the producer's return value. > Allow interceptors and decorators to be applied to the return value of a producer method > ---------------------------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Feb 3 09:50:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 3 Feb 2016 09:50:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-485) Provide literals for built-in annotations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-485: ----------------------------- Description: Annotation literals are often useful and therefore many projects implement them themselves. For example: https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/literal/DefaultLiteral.java https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/literal/DefaultLiteral.java https://github.com/forge/furnace-cdi/blob/master/impl/src/main/java/org/jboss/forge/furnace/container/cdi/util/DefaultLiteral.java https://github.com/astefanutti/metrics-cdi/blob/master/impl/src/main/java/io/astefanutti/metrics/cdi/DefaultLiteral.java to name a few. It would be nice to provide these within the CDI API, e.g: {code:JAVA} @Target( { TYPE, METHOD, PARAMETER, FIELD }) @Retention(RUNTIME) @Documented @Qualifier public @interface Default { @SuppressWarnings("all") final class Literal extends AnnotationLiteral implements Default { private Literal() { } } final Default INSTANCE = new Literal(); } {code} was: Annotation literals are often useful and therefore many projects implement them themselves. For example: https://github.com/DeltaSpike/Mirror/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/literal/DefaultLiteral.java https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/literal/DefaultLiteral.java https://github.com/forge/furnace-cdi/blob/master/impl/src/main/java/org/jboss/forge/furnace/container/cdi/util/DefaultLiteral.java https://github.com/astefanutti/metrics-cdi/blob/master/impl/src/main/java/io/astefanutti/metrics/cdi/DefaultLiteral.java to name a few. It would be nice to provide these within the CDI API, e.g: {code:JAVA} @Target( { TYPE, METHOD, PARAMETER, FIELD }) @Retention(RUNTIME) @Documented @Qualifier public @interface Default { @SuppressWarnings("all") final class Literal extends AnnotationLiteral implements Default { private Literal() { } } final Default INSTANCE = new Literal(); } {code} > Provide literals for built-in annotations > ----------------------------------------- > > Key: CDI-485 > URL: https://issues.jboss.org/browse/CDI-485 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > > Annotation literals are often useful and therefore many projects implement them themselves. For example: > https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/literal/DefaultLiteral.java > https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/literal/DefaultLiteral.java > https://github.com/forge/furnace-cdi/blob/master/impl/src/main/java/org/jboss/forge/furnace/container/cdi/util/DefaultLiteral.java > https://github.com/astefanutti/metrics-cdi/blob/master/impl/src/main/java/io/astefanutti/metrics/cdi/DefaultLiteral.java > to name a few. > It would be nice to provide these within the CDI API, e.g: > {code:JAVA} > @Target( { TYPE, METHOD, PARAMETER, FIELD }) > @Retention(RUNTIME) > @Documented > @Qualifier > public @interface Default { > @SuppressWarnings("all") > final class Literal extends AnnotationLiteral implements Default { > private Literal() { > } > } > final Default INSTANCE = new Literal(); > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From mkouba at redhat.com Wed Feb 3 09:59:36 2016 From: mkouba at redhat.com (Martin Kouba) Date: Wed, 3 Feb 2016 15:59:36 +0100 Subject: [cdi-dev] CDI-485 Provide literals for built-in annotations Message-ID: <56B215D8.6050301@redhat.com> Hi all, I'd like to prepare a pull request for CDI-485 [1] and include this into CDI 2.0. Are there any objections? Thanks, [1] https://issues.jboss.org/browse/CDI-485 -- Martin Kouba Software Engineer Red Hat, Czech Republic From issues at jboss.org Wed Feb 3 10:20:00 2016 From: issues at jboss.org (Sven Linstaedt (JIRA)) Date: Wed, 3 Feb 2016 10:20:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158316#comment-13158316 ] Sven Linstaedt commented on CDI-580: ------------------------------------ One still has to make up the difference between interceptors, that are applied to the producer method and interceptors, that are applied to the product (bean instance). As {{javax.interceptor.Interceptors}} on method level is currently specified as intercepting invocations on the given method with the given interceptors at least for EJBs {quote}Only business method interception or timeout method interception may be specified by a method-level Interceptors declaration.{quote} I would suggest not to reuse the same annotation for a different purpose. Introducing either a new annotation type or adding an attribute to {{@Produces}} seems more understandable from my point of view. > Allow interceptors and decorators to be applied to the return value of a producer method > ---------------------------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Feb 3 11:55:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Wed, 3 Feb 2016 11:55:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158401#comment-13158401 ] Mark Struberg commented on CDI-580: ----------------------------------- [~rmannibucau]] @Interceptors on the method already works. But it intercepts the invocation of the producer method itself. Emily is right, we need some wrapping annotation or another idea ;) > Allow interceptors and decorators to be applied to the return value of a producer method > ---------------------------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Feb 3 12:10:00 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Wed, 3 Feb 2016 12:10:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158411#comment-13158411 ] Romain Manni-Bucau commented on CDI-580: ---------------------------------------- Yep, good catch. Then we would probably need a marker: {code} @Produces(annotated = Decoration.class) ProducedType p() {...} @Logged @Decorated @IsAdmin public static class Decoration {} {code} to be able to handle bindings with parameters > Allow interceptors and decorators to be applied to the return value of a producer method > ---------------------------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Feb 4 02:53:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 4 Feb 2016 02:53:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-515) Allow to obtain Bean metadata from javax.enterprise.inject.Instance In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158586#comment-13158586 ] Martin Kouba commented on CDI-515: ---------------------------------- bq. Like you can use Instance.destroy() to destroy any instance today. No, you can't. See also CDI-519. > Allow to obtain Bean metadata from javax.enterprise.inject.Instance > ------------------------------------------------------------------- > > Key: CDI-515 > URL: https://issues.jboss.org/browse/CDI-515 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Assignee: Martin Kouba > Fix For: 2.0 (proposed) > > > Sometimes it might be useful to obtain Bean metadata from the {{javax.enterprise.inject.Instance}} (similarly as 5.5.8. Bean metadata). The method could be named {{getBean()}} and should have similar restrictions like {{get()}} (e.g. throw {{UnsatisfiedResolutionException}} if appropriate). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Feb 4 18:08:00 2016 From: issues at jboss.org (Emily Jiang (JIRA)) Date: Thu, 4 Feb 2016 18:08:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-485) Provide literals for built-in annotations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13159016#comment-13159016 ] Emily Jiang commented on CDI-485: --------------------------------- +1 > Provide literals for built-in annotations > ----------------------------------------- > > Key: CDI-485 > URL: https://issues.jboss.org/browse/CDI-485 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > > Annotation literals are often useful and therefore many projects implement them themselves. For example: > https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/literal/DefaultLiteral.java > https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/literal/DefaultLiteral.java > https://github.com/forge/furnace-cdi/blob/master/impl/src/main/java/org/jboss/forge/furnace/container/cdi/util/DefaultLiteral.java > https://github.com/astefanutti/metrics-cdi/blob/master/impl/src/main/java/io/astefanutti/metrics/cdi/DefaultLiteral.java > to name a few. > It would be nice to provide these within the CDI API, e.g: > {code:JAVA} > @Target( { TYPE, METHOD, PARAMETER, FIELD }) > @Retention(RUNTIME) > @Documented > @Qualifier > public @interface Default { > @SuppressWarnings("all") > final class Literal extends AnnotationLiteral implements Default { > private Literal() { > } > } > final Default INSTANCE = new Literal(); > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From antoine at sabot-durand.net Fri Feb 5 09:24:01 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 05 Feb 2016 14:24:01 +0000 Subject: [cdi-dev] Full rewrite for CDI 558 / PR 270 Message-ID: Hi all, Following discussion during last meeting, I rewrote most of my PR for builders. We now have 2 clean and distinct ways of using them 1) in DSL style (with a Configurator interface without build() method) public void processAT(@Observes ProcessAnnotatedType pat) { pat.setAnnotatedType().read(pat.getAnnotatedType()).addToType(new AnnotationLiteral() {};); } 2) In classical reusable builder mode (builders extends configurator and only add build() method) public void processAT(@Observes ProcessAnnotatedType pat) { AnnotatedTypeBuilder atb = Builders.annotatedTypeBuilder(); atb.read(pat.getAnnotatedType()).addToType(new AnnotationLiteral() {};); pat.setAnnotatedType(atb.build()); } As Configurators don't have build() method there's no risk that users mix them with standard builders. For clarity sake, builders are no more available in lifecycle event but in Builders class for consistency. I'm quite happy with the result, but I'm sure you'll have comment ;). So thanks for your feedback https://github.com/cdi-spec/cdi/pull/270 Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160205/6d66234b/attachment.html From rmannibucau at gmail.com Fri Feb 5 10:01:09 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Fri, 5 Feb 2016 16:01:09 +0100 Subject: [cdi-dev] Full rewrite for CDI 558 / PR 270 In-Reply-To: References: Message-ID: Why not making all Annotated* mutable during boot lifecycle? Would allow to get rid of the annotated root in the modification code, for instance we could convert: type.getMethods().stream().filter(m -> m.isAnnotationPresent(Foo.class)).forEach(m ->event.setAnnotatedType().addToMethod(m, MyInterceptor.BINDING)); to type.getMethods().stream().filter(m -> m.isAnnotationPresent(Foo.class)).forEach(m -> m.mutate().add(MyInterceptor.BINDING)); or if we don't want to add mutate in the existing types we could use configurator as root for type type and recreate a Configurator graph matching annotated graph. Advatage is first code i a bit awkward in the sense you can call setAnnotatedType() multiple type (what would happen? only last modification will be saved? or you have to keep a reference to the configurator once called which breaks the fluent API provded by streams IMO. wdyt? Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2016-02-05 15:24 GMT+01:00 Antoine Sabot-Durand : > Hi all, > > Following discussion during last meeting, I rewrote most of my PR for > builders. > > We now have 2 clean and distinct ways of using them > > 1) in DSL style (with a Configurator interface without build() method) > > public void processAT(@Observes ProcessAnnotatedType pat) { > pat.setAnnotatedType().read(pat.getAnnotatedType()).addToType(new > AnnotationLiteral() {};); > } > > > 2) In classical reusable builder mode (builders extends configurator and > only add build() method) > > public void processAT(@Observes ProcessAnnotatedType pat) { > AnnotatedTypeBuilder atb = Builders.annotatedTypeBuilder(); > atb.read(pat.getAnnotatedType()).addToType(new > AnnotationLiteral() {};); > pat.setAnnotatedType(atb.build()); > } > > > As Configurators don't have build() method there's no risk that users mix > them with standard builders. > For clarity sake, builders are no more available in lifecycle event but in > Builders class for consistency. > > I'm quite happy with the result, but I'm sure you'll have comment ;). So > thanks for your feedback > > https://github.com/cdi-spec/cdi/pull/270 > > 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/20160205/47ea983e/attachment.html From issues at jboss.org Fri Feb 5 12:17:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 5 Feb 2016 12:17:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-568) Enhancing Java SE bootstrap API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-568 started by Antoine Sabot-Durand. ------------------------------------------------ > Enhancing Java SE bootstrap API > ------------------------------- > > Key: CDI-568 > URL: https://issues.jboss.org/browse/CDI-568 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java SE Integration > Affects Versions: 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > > As discussed during our Paris Face to Face meeting, we should work on enhancing the SE bootstrap API designed for EDR1. > The current version has the following flaws: > * Use existing classes was a bad idea (of mine). It prevents us to remove bootstrap classes in Java EE and force the impl to manage extra work if a user in EE try to use boostrap API. > * While the parameter map is useful, I find it's not fitting the CDI strong typed philosophy, so it would be better to use it as fallback for implementation specific configuration. > * Don't provide a nice way to programmatically configure the container behavior. > That's why I'd like to update the proposed API and provide a more complete approach. Starting with the new [Weld SE api|https://github.com/weld/core/blob/master/environments/se/core/src/main/java/org/jboss/weld/environment/se/Weld.java] could be interesting > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Feb 5 12:18:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 5 Feb 2016 12:18:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-568) Enhancing Java SE bootstrap API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-568: ------------------------------------- Fix Version/s: 2.0-EDR2 > Enhancing Java SE bootstrap API > ------------------------------- > > Key: CDI-568 > URL: https://issues.jboss.org/browse/CDI-568 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java SE Integration > Affects Versions: 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0 (proposed) > > > As discussed during our Paris Face to Face meeting, we should work on enhancing the SE bootstrap API designed for EDR1. > The current version has the following flaws: > * Use existing classes was a bad idea (of mine). It prevents us to remove bootstrap classes in Java EE and force the impl to manage extra work if a user in EE try to use boostrap API. > * While the parameter map is useful, I find it's not fitting the CDI strong typed philosophy, so it would be better to use it as fallback for implementation specific configuration. > * Don't provide a nice way to programmatically configure the container behavior. > That's why I'd like to update the proposed API and provide a more complete approach. Starting with the new [Weld SE api|https://github.com/weld/core/blob/master/environments/se/core/src/main/java/org/jboss/weld/environment/se/Weld.java] could be interesting > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Feb 5 12:18:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 5 Feb 2016 12:18:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-568) Enhancing Java SE bootstrap API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-568: ------------------------------------- Fix Version/s: 2.0 (proposed) (was: 2.0-EDR2) > Enhancing Java SE bootstrap API > ------------------------------- > > Key: CDI-568 > URL: https://issues.jboss.org/browse/CDI-568 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java SE Integration > Affects Versions: 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0 (proposed) > > > As discussed during our Paris Face to Face meeting, we should work on enhancing the SE bootstrap API designed for EDR1. > The current version has the following flaws: > * Use existing classes was a bad idea (of mine). It prevents us to remove bootstrap classes in Java EE and force the impl to manage extra work if a user in EE try to use boostrap API. > * While the parameter map is useful, I find it's not fitting the CDI strong typed philosophy, so it would be better to use it as fallback for implementation specific configuration. > * Don't provide a nice way to programmatically configure the container behavior. > That's why I'd like to update the proposed API and provide a more complete approach. Starting with the new [Weld SE api|https://github.com/weld/core/blob/master/environments/se/core/src/main/java/org/jboss/weld/environment/se/Weld.java] could be interesting > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sat Feb 6 05:56:00 2016 From: issues at jboss.org (arjan tijms (JIRA)) Date: Sat, 6 Feb 2016 05:56:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-485) Provide literals for built-in annotations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13159482#comment-13159482 ] arjan tijms commented on CDI-485: --------------------------------- JSF EG has implemented this too: https://github.com/javaserverfaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/cdi/DefaultAnnotationLiteral.java +1 > Provide literals for built-in annotations > ----------------------------------------- > > Key: CDI-485 > URL: https://issues.jboss.org/browse/CDI-485 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > > Annotation literals are often useful and therefore many projects implement them themselves. For example: > https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/literal/DefaultLiteral.java > https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/literal/DefaultLiteral.java > https://github.com/forge/furnace-cdi/blob/master/impl/src/main/java/org/jboss/forge/furnace/container/cdi/util/DefaultLiteral.java > https://github.com/astefanutti/metrics-cdi/blob/master/impl/src/main/java/io/astefanutti/metrics/cdi/DefaultLiteral.java > to name a few. > It would be nice to provide these within the CDI API, e.g: > {code:JAVA} > @Target( { TYPE, METHOD, PARAMETER, FIELD }) > @Retention(RUNTIME) > @Documented > @Qualifier > public @interface Default { > @SuppressWarnings("all") > final class Literal extends AnnotationLiteral implements Default { > private Literal() { > } > } > final Default INSTANCE = new Literal(); > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Feb 8 06:15:02 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Mon, 8 Feb 2016 06:15:02 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-581) possible chicken-egg problem with ProcessBeanAttributes#veto and specialization In-Reply-To: References: Message-ID: Mark Struberg created CDI-581: --------------------------------- Summary: possible chicken-egg problem with ProcessBeanAttributes#veto and specialization Key: CDI-581 URL: https://issues.jboss.org/browse/CDI-581 Project: CDI Specification Issues Issue Type: Bug Affects Versions: 1.2.Final Reporter: Mark Struberg Currently section 12 describes that ProcessBeanAttributes only should get fired for 'enabed beans'. {quote} 12.4.3. Bean discovery * if the class is an enabled bean, interceptor or decorator, fire an event of type ProcessBeanAttributes, as defined in ProcessBeanAttributes event, {quote} But if you have class B extends A and B is @Specializes then you don't know which PBA to fire. Because B could get vetoed in ProcessBeanAttributes. And then while you fire PBA you implicitly change the list of enabled beans. This gets even more complicated by the ability of ProcessBeanAttributes to change the isAlternative bit and even the types of the whole bean. I think this might be a left-over of the split between Bean and BeanAttributes. The ProcessBeanAttributes is right in the middle between ProcessAnnotatedType and ProcessBean. * ProcessBean die _not_ have a veto(), PAT does have it. * PAT gets fired for all discovered classes, ProcessBean only for enabled ones. I think the wording 'if the class is an enabled *bean*' is also misleading. We do _not_ have a bean at this early stage! We only have an AnnotatedType. Maybe it should read ''if the class is a not vetoed AnnotatedType'? I'm not sure if there is a way the current wording could get cleanly implemented. I just stumbled across this because we did _not_ fire a PBA for a class because the @Specialized bean got vetoed away. The same chicken-egg problem might apply to {quote} 11.5.9. ProcessBeanAttributes event The container must fire an event for each bean, interceptor or decorator deployed in a bean archive, before registering the Bean object." {quote} Reads "for every bean". But we don't have any beans yet. We can only make the Bean after the BeanAttributes get returned from PBA. Otherwise changing the bean attributes would have no effect on the Bean, right? What could work is roughly: * fire PAT for all detected classes * remove vetoed ones * fire PBA for all AnnotatedTypes * remove vetoed one * calculate disabled BeanAttributes (@Specializes rule for classes) * produce Beans -- This message was sent by Atlassian JIRA (v6.4.11#64026) From antoine at sabot-durand.net Tue Feb 9 11:36:51 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 09 Feb 2016 16:36:51 +0000 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods Message-ID: Hi all, There have been a lot of discussion around CDI-527 in the last weeks: https://issues.jboss.org/browse/CDI-527 Mark proposed a PR: https://github.com/cdi-spec/cdi/pull/271 But we don't agree on adding this feature to the spec. This vote is to decide if we should add this feature at the spec level now, or not. Should we vote this feature down, that won't mean it will be completely dropped: it could be implemented as non portable feature in both Spec or even be included as experimental feature in the spec (in annexes) as describe in the PR comments Vote starts now, only vote from EG members are binding (but you can give your opinion if not part of the EG) and will last 72 hours. You vote with the following values: +1 : I'm favorable for adding this feature in the spec -1 : I'm against adding this feature in the spec 0 : I don't care Thank you for your attention and your vote. Antoine Sabot-Durand -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160209/14edc8f5/attachment.html From antoine at sabot-durand.net Tue Feb 9 11:37:28 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 09 Feb 2016 16:37:28 +0000 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: -1 Le mar. 9 f?vr. 2016 ? 17:36, Antoine Sabot-Durand a ?crit : > Hi all, > > There have been a lot of discussion around CDI-527 in the last weeks: > https://issues.jboss.org/browse/CDI-527 > > Mark proposed a PR: > https://github.com/cdi-spec/cdi/pull/271 > > But we don't agree on adding this feature to the spec. > This vote is to decide if we should add this feature at the spec level > now, or not. > Should we vote this feature down, that won't mean it will be completely > dropped: it could be implemented as non portable feature in both Spec or > even be included as experimental feature in the spec (in annexes) as > describe in the PR comments > Vote starts now, only vote from EG members are binding (but you can give > your opinion if not part of the EG) and will last 72 hours. > > You vote with the following values: > +1 : I'm favorable for adding this feature in the spec > -1 : I'm against adding this feature in the spec > 0 : I don't care > > Thank you for your attention and your vote. > > Antoine Sabot-Durand > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160209/7f37bef5/attachment.html From rmannibucau at gmail.com Tue Feb 9 11:43:13 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 9 Feb 2016 17:43:13 +0100 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: +1 for the feature itself which allows to keep some basic backward compatibility (but I would add a way to notify the user of a - single - warning if this feature is actually needed and used) Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2016-02-09 17:37 GMT+01:00 Antoine Sabot-Durand : > -1 > > Le mar. 9 f?vr. 2016 ? 17:36, Antoine Sabot-Durand < > antoine at sabot-durand.net> a ?crit : > >> Hi all, >> >> There have been a lot of discussion around CDI-527 in the last weeks: >> https://issues.jboss.org/browse/CDI-527 >> >> Mark proposed a PR: >> https://github.com/cdi-spec/cdi/pull/271 >> >> But we don't agree on adding this feature to the spec. >> This vote is to decide if we should add this feature at the spec level >> now, or not. >> Should we vote this feature down, that won't mean it will be completely >> dropped: it could be implemented as non portable feature in both Spec or >> even be included as experimental feature in the spec (in annexes) as >> describe in the PR comments >> Vote starts now, only vote from EG members are binding (but you can give >> your opinion if not part of the EG) and will last 72 hours. >> >> You vote with the following values: >> +1 : I'm favorable for adding this feature in the spec >> -1 : I'm against adding this feature in the spec >> 0 : I don't care >> >> Thank you for your attention and your vote. >> >> Antoine Sabot-Durand >> > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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/20160209/f6dd5a64/attachment.html From struberg at yahoo.de Tue Feb 9 12:00:05 2016 From: struberg at yahoo.de (Mark Struberg) Date: Tue, 9 Feb 2016 18:00:05 +0100 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: <6A0D043D-AE4F-4AD1-AC57-2A0C4F5A9AD5@yahoo.de> +1 This is a real world problem and it would imo be a pitty to not have it in the spec in a portable way. LieGrue, strub > Am 09.02.2016 um 17:36 schrieb Antoine Sabot-Durand : > > Hi all, > > There have been a lot of discussion around CDI-527 in the last weeks: > https://issues.jboss.org/browse/CDI-527 > > Mark proposed a PR: > https://github.com/cdi-spec/cdi/pull/271 > > But we don't agree on adding this feature to the spec. > This vote is to decide if we should add this feature at the spec level now, or not. > Should we vote this feature down, that won't mean it will be completely dropped: it could be implemented as non portable feature in both Spec or even be included as experimental feature in the spec (in annexes) as describe in the PR comments > Vote starts now, only vote from EG members are binding (but you can give your opinion if not part of the EG) and will last 72 hours. > > You vote with the following values: > +1 : I'm favorable for adding this feature in the spec > -1 : I'm against adding this feature in the spec > 0 : I don't care > > Thank you for your attention and your vote. > > Antoine Sabot-Durand > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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 andraschko.thomas at gmail.com Tue Feb 9 12:08:53 2016 From: andraschko.thomas at gmail.com (Thomas Andraschko) Date: Tue, 9 Feb 2016 18:08:53 +0100 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: <6A0D043D-AE4F-4AD1-AC57-2A0C4F5A9AD5@yahoo.de> References: <6A0D043D-AE4F-4AD1-AC57-2A0C4F5A9AD5@yahoo.de> Message-ID: +1 not sure if the PR is the best way but as mark already said, it would solve a problem in a portable way which exists in some real world applications 2016-02-09 18:00 GMT+01:00 Mark Struberg : > +1 > > This is a real world problem and it would imo be a pitty to not have it in > the spec in a portable way. > > LieGrue, > strub > > > > Am 09.02.2016 um 17:36 schrieb Antoine Sabot-Durand < > antoine at sabot-durand.net>: > > > > Hi all, > > > > There have been a lot of discussion around CDI-527 in the last weeks: > > https://issues.jboss.org/browse/CDI-527 > > > > Mark proposed a PR: > > https://github.com/cdi-spec/cdi/pull/271 > > > > But we don't agree on adding this feature to the spec. > > This vote is to decide if we should add this feature at the spec level > now, or not. > > Should we vote this feature down, that won't mean it will be completely > dropped: it could be implemented as non portable feature in both Spec or > even be included as experimental feature in the spec (in annexes) as > describe in the PR comments > > Vote starts now, only vote from EG members are binding (but you can give > your opinion if not part of the EG) and will last 72 hours. > > > > You vote with the following values: > > +1 : I'm favorable for adding this feature in the spec > > -1 : I'm against adding this feature in the spec > > 0 : I don't care > > > > Thank you for your attention and your vote. > > > > Antoine Sabot-Durand > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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/20160209/b815dcb8/attachment.html From jens.schumann at openknowledge.de Tue Feb 9 12:13:50 2016 From: jens.schumann at openknowledge.de (Jens Schumann) Date: Tue, 9 Feb 2016 17:13:50 +0000 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: +1 (even though I can live with a portable alternative approach to the current PR) So far I did not express my support for this PR even though I promised to do so. Unable to proxy those classes is a major issue to me while migrating old software to a newer environment. As soon as you deal with 5 to 10+ years old software and try to migrate your large application step by step you will encounter framework base classes with (protected) final methods. CDI, @Inject and interceptors help a lot to cleanup the old stuff, however I have to extend (currently unproxyable) framework base classes to do so. Example: I have to extend AbstractFrameworkXyzAction with public and/ or protected final methods to implement use case logic, and the derived classes should be CDI beans. On the other hand - changing the old jar's is not an option either. With this feature I can stop copying the modified base classes to my local archive (mostly .war) in order to override the old classes. Jens Von: > on behalf of Antoine Sabot-Durand > Datum: Tuesday 9 February 2016 17:36 An: CDI-Dev > Betreff: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods Hi all, There have been a lot of discussion around CDI-527 in the last weeks: https://issues.jboss.org/browse/CDI-527 Mark proposed a PR: https://github.com/cdi-spec/cdi/pull/271 But we don't agree on adding this feature to the spec. This vote is to decide if we should add this feature at the spec level now, or not. Should we vote this feature down, that won't mean it will be completely dropped: it could be implemented as non portable feature in both Spec or even be included as experimental feature in the spec (in annexes) as describe in the PR comments Vote starts now, only vote from EG members are binding (but you can give your opinion if not part of the EG) and will last 72 hours. You vote with the following values: +1 : I'm favorable for adding this feature in the spec -1 : I'm against adding this feature in the spec 0 : I don't care Thank you for your attention and your vote. Antoine Sabot-Durand -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160209/3cafc912/attachment.html From EMIJIANG at uk.ibm.com Tue Feb 9 12:42:59 2016 From: EMIJIANG at uk.ibm.com (Emily Jiang) Date: Tue, 9 Feb 2016 17:42:59 +0000 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: <201602091743.u19Hh60g030078@d06av08.portsmouth.uk.ibm.com> +1. This is a really useful feature as more and more customers will move forward to Java8 and might hit this problem. Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB From: Jens Schumann To: cdi-dev , Date: 09/02/2016 17:15 Subject: Re: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods Sent by: cdi-dev-bounces at lists.jboss.org +1 (even though I can live with a portable alternative approach to the current PR) So far I did not express my support for this PR even though I promised to do so. Unable to proxy those classes is a major issue to me while migrating old software to a newer environment. As soon as you deal with 5 to 10+ years old software and try to migrate your large application step by step you will encounter framework base classes with (protected) final methods. CDI, @Inject and interceptors help a lot to cleanup the old stuff, however I have to extend (currently unproxyable) framework base classes to do so. Example: I have to extend AbstractFrameworkXyzAction with public and/ or protected final methods to implement use case logic, and the derived classes should be CDI beans. On the other hand - changing the old jar's is not an option either. With this feature I can stop copying the modified base classes to my local archive (mostly .war) in order to override the old classes. Jens Von: on behalf of Antoine Sabot-Durand < antoine at sabot-durand.net> Datum: Tuesday 9 February 2016 17:36 An: CDI-Dev Betreff: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods Hi all, There have been a lot of discussion around CDI-527 in the last weeks: https://issues.jboss.org/browse/CDI-527 Mark proposed a PR: https://github.com/cdi-spec/cdi/pull/271 But we don't agree on adding this feature to the spec. This vote is to decide if we should add this feature at the spec level now, or not. Should we vote this feature down, that won't mean it will be completely dropped: it could be implemented as non portable feature in both Spec or even be included as experimental feature in the spec (in annexes) as describe in the PR comments Vote starts now, only vote from EG members are binding (but you can give your opinion if not part of the EG) and will last 72 hours. You vote with the following values: +1 : I'm favorable for adding this feature in the spec -1 : I'm against adding this feature in the spec 0 : I don't care Thank you for your attention and your vote. Antoine Sabot-Durand_______________________________________________ cdi-dev mailing list cdi-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160209/4fcc1e81/attachment-0001.html From tremes at redhat.com Wed Feb 10 02:02:03 2016 From: tremes at redhat.com (Tomas Remes) Date: Wed, 10 Feb 2016 02:02:03 -0500 (EST) Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: <740970591.27425327.1455087723940.JavaMail.zimbra@redhat.com> -1 Tom ----- Original Message ----- From: "Antoine Sabot-Durand" To: "cdi-dev" Sent: Tuesday, February 9, 2016 5:36:51 PM Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods Hi all, There have been a lot of discussion around CDI-527 in the last weeks: https://issues.jboss.org/browse/CDI-527 Mark proposed a PR: https://github.com/cdi-spec/cdi/pull/271 But we don't agree on adding this feature to the spec. This vote is to decide if we should add this feature at the spec level now, or not. Should we vote this feature down, that won't mean it will be completely dropped: it could be implemented as non portable feature in both Spec or even be included as experimental feature in the spec (in annexes) as describe in the PR comments Vote starts now, only vote from EG members are binding (but you can give your opinion if not part of the EG) and will last 72 hours. You vote with the following values: +1 : I'm favorable for adding this feature in the spec -1 : I'm against adding this feature in the spec 0 : I don't care Thank you for your attention and your vote. Antoine Sabot-Durand _______________________________________________ cdi-dev mailing list cdi-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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 Wed Feb 10 02:41:24 2016 From: mkouba at redhat.com (Martin Kouba) Date: Wed, 10 Feb 2016 08:41:24 +0100 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: <56BAE9A4.9060809@redhat.com> -1 My explanation: https://github.com/cdi-spec/cdi/pull/271#issuecomment-179105513 We're going to release Weld 2.3.3.Final later this week. So both impls provide a non-portable solution already. However, if the EG decides to go this way I'm strongly in favor of: * unifying CDI configuration (something similar to Weld and OWB configurations) * NOT reusing beans.xml * NOT to take into account the environment variables Martin Dne 9.2.2016 v 17:36 Antoine Sabot-Durand napsal(a): > Hi all, > > There have been a lot of discussion around CDI-527 in the last weeks: > https://issues.jboss.org/browse/CDI-527 > > Mark proposed a PR: > https://github.com/cdi-spec/cdi/pull/271 > > But we don't agree on adding this feature to the spec. > This vote is to decide if we should add this feature at the spec level > now, or not. > Should we vote this feature down, that won't mean it will be completely > dropped: it could be implemented as non portable feature in both Spec or > even be included as experimental feature in the spec (in annexes) as > describe in the PR comments > Vote starts now, only vote from EG members are binding (but you can give > your opinion if not part of the EG) and will last 72 hours. > > You vote with the following values: > +1 : I'm favorable for adding this feature in the spec > -1 : I'm against adding this feature in the spec > 0 : I don't care > > Thank you for your attention and your vote. > > Antoine Sabot-Durand > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > -- Martin Kouba Software Engineer Red Hat, Czech Republic From issues at jboss.org Wed Feb 10 02:47:00 2016 From: issues at jboss.org (Stephan Knitelius (JIRA)) Date: Wed, 10 Feb 2016 02:47:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-582) Configurable concurrency control for CDI In-Reply-To: References: Message-ID: Stephan Knitelius created CDI-582: ------------------------------------- Summary: Configurable concurrency control for CDI Key: CDI-582 URL: https://issues.jboss.org/browse/CDI-582 Project: CDI Specification Issues Issue Type: Feature Request Components: Contexts Affects Versions: 2.0-EDR1 Reporter: Stephan Knitelius Currently the spec only defines, a non-configurable, concurrency control mechanism for conversation scope. All other build-in scopes remain unprotected, relaying on the developer. It would be useful to introduce EJB Singleton style concurrency control for CDI scopes. Allowing the developer to configure the concurrency behavior of ConversationScoped beans, and defining concurrency control for the other build-in scopes. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From manovotn at redhat.com Wed Feb 10 04:17:23 2016 From: manovotn at redhat.com (Matej Novotny) Date: Wed, 10 Feb 2016 04:17:23 -0500 (EST) Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: <466475503.16345643.1455095843289.JavaMail.zimbra@redhat.com> -1 I do not fancy polluting spec with optional config options like this. Imho this should be solved on an implementation level of Weld/OWB only. Matej ----- Original Message ----- From: "Antoine Sabot-Durand" To: "cdi-dev" Sent: Tuesday, February 9, 2016 5:36:51 PM Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods Hi all, There have been a lot of discussion around CDI-527 in the last weeks: https://issues.jboss.org/browse/CDI-527 Mark proposed a PR: https://github.com/cdi-spec/cdi/pull/271 But we don't agree on adding this feature to the spec. This vote is to decide if we should add this feature at the spec level now, or not. Should we vote this feature down, that won't mean it will be completely dropped: it could be implemented as non portable feature in both Spec or even be included as experimental feature in the spec (in annexes) as describe in the PR comments Vote starts now, only vote from EG members are binding (but you can give your opinion if not part of the EG) and will last 72 hours. You vote with the following values: +1 : I'm favorable for adding this feature in the spec -1 : I'm against adding this feature in the spec 0 : I don't care Thank you for your attention and your vote. Antoine Sabot-Durand _______________________________________________ cdi-dev mailing list cdi-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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 Wed Feb 10 04:23:44 2016 From: thjanssen123 at gmail.com (Thorben Janssen) Date: Wed, 10 Feb 2016 10:23:44 +0100 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: <56BAE9A4.9060809@redhat.com> References: <56BAE9A4.9060809@redhat.com> Message-ID: +1 to have this feature in the spec -- *Thorben Janssen* @thjanssen123 www.thoughts-on-java.org 2016-02-10 8:41 GMT+01:00 Martin Kouba : > -1 > > My explanation: > https://github.com/cdi-spec/cdi/pull/271#issuecomment-179105513 > > We're going to release Weld 2.3.3.Final later this week. So both impls > provide a non-portable solution already. > > However, if the EG decides to go this way I'm strongly in favor of: > * unifying CDI configuration (something similar to Weld and OWB > configurations) > * NOT reusing beans.xml > * NOT to take into account the environment variables > > Martin > > Dne 9.2.2016 v 17:36 Antoine Sabot-Durand napsal(a): > > Hi all, > > > > There have been a lot of discussion around CDI-527 in the last weeks: > > https://issues.jboss.org/browse/CDI-527 > > > > Mark proposed a PR: > > https://github.com/cdi-spec/cdi/pull/271 > > > > But we don't agree on adding this feature to the spec. > > This vote is to decide if we should add this feature at the spec level > > now, or not. > > Should we vote this feature down, that won't mean it will be completely > > dropped: it could be implemented as non portable feature in both Spec or > > even be included as experimental feature in the spec (in annexes) as > > describe in the PR comments > > Vote starts now, only vote from EG members are binding (but you can give > > your opinion if not part of the EG) and will last 72 hours. > > > > You vote with the following values: > > +1 : I'm favorable for adding this feature in the spec > > -1 : I'm against adding this feature in the spec > > 0 : I don't care > > > > Thank you for your attention and your vote. > > > > Antoine Sabot-Durand > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160210/7868bdf2/attachment.html From werner.keil at gmail.com Wed Feb 10 05:27:56 2016 From: werner.keil at gmail.com (Werner Keil) Date: Wed, 10 Feb 2016 11:27:56 +0100 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods Message-ID: +1 Werner On Tue, Feb 9, 2016 at 6:43 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: [Vote] for CDI-527 / PR 271 allow proxying of classes > with non-private final methods (Thomas Andraschko) > 2. Re: [Vote] for CDI-527 / PR 271 allow proxying of classes > with non-private final methods (Jens Schumann) > 3. Re: [Vote] for CDI-527 / PR 271 allow proxying of classes > with non-private final methods (Emily Jiang) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 9 Feb 2016 18:08:53 +0100 > From: Thomas Andraschko > Subject: Re: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of > classes with non-private final methods > To: Mark Struberg > Cc: cdi-dev > Message-ID: > cFDmwZ6ouA at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > +1 > > not sure if the PR is the best way but as mark already said, it would solve > a problem in a portable way which exists in some real world applications > > 2016-02-09 18:00 GMT+01:00 Mark Struberg : > > > +1 > > > > This is a real world problem and it would imo be a pitty to not have it > in > > the spec in a portable way. > > > > LieGrue, > > strub > > > > > > > Am 09.02.2016 um 17:36 schrieb Antoine Sabot-Durand < > > antoine at sabot-durand.net>: > > > > > > Hi all, > > > > > > There have been a lot of discussion around CDI-527 in the last weeks: > > > https://issues.jboss.org/browse/CDI-527 > > > > > > Mark proposed a PR: > > > https://github.com/cdi-spec/cdi/pull/271 > > > > > > But we don't agree on adding this feature to the spec. > > > This vote is to decide if we should add this feature at the spec level > > now, or not. > > > Should we vote this feature down, that won't mean it will be completely > > dropped: it could be implemented as non portable feature in both Spec or > > even be included as experimental feature in the spec (in annexes) as > > describe in the PR comments > > > Vote starts now, only vote from EG members are binding (but you can > give > > your opinion if not part of the EG) and will last 72 hours. > > > > > > You vote with the following values: > > > +1 : I'm favorable for adding this feature in the spec > > > -1 : I'm against adding this feature in the spec > > > 0 : I don't care > > > > > > Thank you for your attention and your vote. > > > > > > Antoine Sabot-Durand > > > _______________________________________________ > > > cdi-dev mailing list > > > cdi-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > > > Note that for all code provided on this list, the provider licenses the > > code under the Apache License, Version 2 ( > > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > > provided on this list, the provider waives all patent and other > > intellectual property rights inherent in such information. > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > > code under the Apache License, Version 2 ( > > http://www.apache.org/licenses/LICENSE-2.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/20160209/b815dcb8/attachment-0001.html > > ------------------------------ > > Message: 2 > Date: Tue, 9 Feb 2016 17:13:50 +0000 > From: Jens Schumann > Subject: Re: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of > classes with non-private final methods > To: cdi-dev > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > +1 > > (even though I can live with a portable alternative approach to the > current PR) > > So far I did not express my support for this PR even though I promised to > do so. Unable to proxy those classes is a major issue to me while migrating > old software to a newer environment. > > As soon as you deal with 5 to 10+ years old software and try to migrate > your large application step by step you will encounter framework base > classes with (protected) final methods. CDI, @Inject and interceptors help > a lot to cleanup the old stuff, however I have to extend (currently > unproxyable) framework base classes to do so. Example: I have to extend > AbstractFrameworkXyzAction with public and/ or protected final methods to > implement use case logic, and the derived classes should be CDI beans. > > On the other hand - changing the old jar's is not an option either. > > With this feature I can stop copying the modified base classes to my local > archive (mostly .war) in order to override the old classes. > > Jens > > > > > Von: cdi-dev-bounces at lists.jboss.org>> on behalf of Antoine Sabot-Durand < > antoine at sabot-durand.net> > Datum: Tuesday 9 February 2016 17:36 > An: CDI-Dev > > Betreff: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes > with non-private final methods > > Hi all, > > There have been a lot of discussion around CDI-527 in the last weeks: > https://issues.jboss.org/browse/CDI-527 > > Mark proposed a PR: > https://github.com/cdi-spec/cdi/pull/271 > > But we don't agree on adding this feature to the spec. > This vote is to decide if we should add this feature at the spec level > now, or not. > Should we vote this feature down, that won't mean it will be completely > dropped: it could be implemented as non portable feature in both Spec or > even be included as experimental feature in the spec (in annexes) as > describe in the PR comments > Vote starts now, only vote from EG members are binding (but you can give > your opinion if not part of the EG) and will last 72 hours. > > You vote with the following values: > +1 : I'm favorable for adding this feature in the spec > -1 : I'm against adding this feature in the spec > 0 : I don't care > > Thank you for your attention and your vote. > > Antoine Sabot-Durand > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20160209/3cafc912/attachment-0001.html > > ------------------------------ > > Message: 3 > Date: Tue, 9 Feb 2016 17:42:59 +0000 > From: Emily Jiang > Subject: Re: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of > classes with non-private final methods > To: cdi-dev > Message-ID: > <201602091743.u19Hh60g030078 at d06av08.portsmouth.uk.ibm.com> > Content-Type: text/plain; charset="us-ascii" > > +1. > This is a really useful feature as more and more customers will move > forward to Java8 and might hit this problem. > > Many thanks, > Emily > =========================== > Emily Jiang > WebSphere Application Server, CDI Development Lead > > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN > Phone: +44 (0)1962 816278 Internal: 246278 > > Email: emijiang at uk.ibm.com > Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > > > > From: Jens Schumann > To: cdi-dev , > Date: 09/02/2016 17:15 > Subject: Re: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying > of classes with non-private final methods > Sent by: cdi-dev-bounces at lists.jboss.org > > > > +1 > > (even though I can live with a portable alternative approach to the > current PR) > > So far I did not express my support for this PR even though I promised to > do so. Unable to proxy those classes is a major issue to me while > migrating old software to a newer environment. > > As soon as you deal with 5 to 10+ years old software and try to migrate > your large application step by step you will encounter framework base > classes with (protected) final methods. CDI, @Inject and interceptors help > a lot to cleanup the old stuff, however I have to extend (currently > unproxyable) framework base classes to do so. Example: I have to extend > AbstractFrameworkXyzAction with public and/ or protected final methods to > implement use case logic, and the derived classes should be CDI beans. > > On the other hand - changing the old jar's is not an option either. > > With this feature I can stop copying the modified base classes to my local > archive (mostly .war) in order to override the old classes. > > Jens > > > > > Von: on behalf of Antoine Sabot-Durand < > antoine at sabot-durand.net> > Datum: Tuesday 9 February 2016 17:36 > An: CDI-Dev > Betreff: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes > with non-private final methods > > Hi all, > > There have been a lot of discussion around CDI-527 in the last weeks: > https://issues.jboss.org/browse/CDI-527 > > Mark proposed a PR: > https://github.com/cdi-spec/cdi/pull/271 > > But we don't agree on adding this feature to the spec. > This vote is to decide if we should add this feature at the spec level > now, or not. > Should we vote this feature down, that won't mean it will be completely > dropped: it could be implemented as non portable feature in both Spec or > even be included as experimental feature in the spec (in annexes) as > describe in the PR comments > Vote starts now, only vote from EG members are binding (but you can give > your opinion if not part of the EG) and will last 72 hours. > > You vote with the following values: > +1 : I'm favorable for adding this feature in the spec > -1 : I'm against adding this feature in the spec > 0 : I don't care > > Thank you for your attention and your vote. > > Antoine Sabot-Durand_______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20160209/4fcc1e81/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 63, Issue 7 > ************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160210/c7ac0d87/attachment-0001.html From john.d.ament at gmail.com Wed Feb 10 07:48:24 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Wed, 10 Feb 2016 12:48:24 +0000 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: +1 for adding this feature to the spec. -1 for adding it the way it is written currently. This isn't to say that Mark's idea is bad, its just that it puts too much onus on the application developer to know the structure of its classes, both internally developed and externally provided. We should follow a pattern closer to EJB (in my opinion) where the non-proxyable methods are just not proxied - you won't get transactions, etc available. John On Tue, Feb 9, 2016 at 11:37 AM Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi all, > > There have been a lot of discussion around CDI-527 in the last weeks: > https://issues.jboss.org/browse/CDI-527 > > Mark proposed a PR: > https://github.com/cdi-spec/cdi/pull/271 > > But we don't agree on adding this feature to the spec. > This vote is to decide if we should add this feature at the spec level > now, or not. > Should we vote this feature down, that won't mean it will be completely > dropped: it could be implemented as non portable feature in both Spec or > even be included as experimental feature in the spec (in annexes) as > describe in the PR comments > Vote starts now, only vote from EG members are binding (but you can give > your opinion if not part of the EG) and will last 72 hours. > > You vote with the following values: > +1 : I'm favorable for adding this feature in the spec > -1 : I'm against adding this feature in the spec > 0 : I don't care > > Thank you for your attention and your vote. > > Antoine Sabot-Durand > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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/20160210/526c98c2/attachment.html From mkouba at redhat.com Wed Feb 10 08:07:22 2016 From: mkouba at redhat.com (Martin Kouba) Date: Wed, 10 Feb 2016 14:07:22 +0100 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: <56BB360A.2040906@redhat.com> Dne 10.2.2016 v 13:48 John D. Ament napsal(a): > +1 for adding this feature to the spec. > > -1 for adding it the way it is written currently. This isn't to say > that Mark's idea is bad, its just that it puts too much onus on the > application developer to know the structure of its classes, both > internally developed and externally provided. > > We should follow a pattern closer to EJB (in my opinion) where the > non-proxyable methods are just not proxied - you won't get transactions, > etc available. -1 I think you cannot declare a final method on a NIV session bean (you get validation error) and it's easy to create a proxy for local/remote interface - no such methods. I also think we cannot implement this in Weld as we're using subclassing for client proxies. If you don't override (i.e. if you ignore) such a method than it will not be invoked upon the contextual instance but upon the clien proxy instance (subclass). > > John > > On Tue, Feb 9, 2016 at 11:37 AM Antoine Sabot-Durand > > wrote: > > Hi all, > > There have been a lot of discussion around CDI-527 in the last weeks: > https://issues.jboss.org/browse/CDI-527 > > Mark proposed a PR: > https://github.com/cdi-spec/cdi/pull/271 > > But we don't agree on adding this feature to the spec. > This vote is to decide if we should add this feature at the spec > level now, or not. > Should we vote this feature down, that won't mean it will be > completely dropped: it could be implemented as non portable feature > in both Spec or even be included as experimental feature in the spec > (in annexes) as describe in the PR comments > Vote starts now, only vote from EG members are binding (but you can > give your opinion if not part of the EG) and will last 72 hours. > > You vote with the following values: > +1 : I'm favorable for adding this feature in the spec > -1 : I'm against adding this feature in the spec > 0 : I don't care > > Thank you for your attention and your vote. > > Antoine Sabot-Durand > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > ideas provided on this list, the provider waives all patent and > other intellectual property rights inherent in such information. > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > -- Martin Kouba Software Engineer Red Hat, Czech Republic From john.d.ament at gmail.com Wed Feb 10 08:12:05 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Wed, 10 Feb 2016 13:12:05 +0000 Subject: [cdi-dev] Can proxying be handled the way done in EJB? In-Reply-To: <56BB360A.2040906@redhat.com> References: <56BB360A.2040906@redhat.com> Message-ID: Not sure if we want to pollute the vote thread, so changing titles. I think to summarize my feelings, think about the relationship between interface Foo and implementation FooImpl. Foo is defined: interface Foo { String doWork(); } FooImpl is defined as: public class FooImpl implements Foo { public String doWork() { return "i'm done"; } public final String doSomethingElse() { return "something else"; } } The way CDI impls work right now, the proxy is created for the impl. The way EJBs proxy right now, they proxy the interface. If CDI proxied both the interface and impl separately, and substituted based on the injection point, this would work. On Wed, Feb 10, 2016 at 8:07 AM Martin Kouba wrote: > Dne 10.2.2016 v 13:48 John D. Ament napsal(a): > > +1 for adding this feature to the spec. > > > > -1 for adding it the way it is written currently. This isn't to say > > that Mark's idea is bad, its just that it puts too much onus on the > > application developer to know the structure of its classes, both > > internally developed and externally provided. > > > > We should follow a pattern closer to EJB (in my opinion) where the > > non-proxyable methods are just not proxied - you won't get transactions, > > etc available. > > -1 > > I think you cannot declare a final method on a NIV session bean (you get > validation error) and it's easy to create a proxy for local/remote > interface - no such methods. I also think we cannot implement this in > Weld as we're using subclassing for client proxies. If you don't > override (i.e. if you ignore) such a method than it will not be invoked > upon the contextual instance but upon the clien proxy instance (subclass). > > > > > John > > > > On Tue, Feb 9, 2016 at 11:37 AM Antoine Sabot-Durand > > > wrote: > > > > Hi all, > > > > There have been a lot of discussion around CDI-527 in the last weeks: > > https://issues.jboss.org/browse/CDI-527 > > > > Mark proposed a PR: > > https://github.com/cdi-spec/cdi/pull/271 > > > > But we don't agree on adding this feature to the spec. > > This vote is to decide if we should add this feature at the spec > > level now, or not. > > Should we vote this feature down, that won't mean it will be > > completely dropped: it could be implemented as non portable feature > > in both Spec or even be included as experimental feature in the spec > > (in annexes) as describe in the PR comments > > Vote starts now, only vote from EG members are binding (but you can > > give your opinion if not part of the EG) and will last 72 hours. > > > > You vote with the following values: > > +1 : I'm favorable for adding this feature in the spec > > -1 : I'm against adding this feature in the spec > > 0 : I don't care > > > > Thank you for your attention and your vote. > > > > Antoine Sabot-Durand > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses > > the code under the Apache License, Version 2 > > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > > ideas provided on this list, the provider waives all patent and > > other intellectual property rights inherent in such information. > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160210/b4dc648c/attachment.html From mkouba at redhat.com Wed Feb 10 08:19:23 2016 From: mkouba at redhat.com (Martin Kouba) Date: Wed, 10 Feb 2016 14:19:23 +0100 Subject: [cdi-dev] Can proxying be handled the way done in EJB? In-Reply-To: References: <56BB360A.2040906@redhat.com> Message-ID: <56BB38DB.4090308@redhat.com> Hi John, comments inline.. Dne 10.2.2016 v 14:12 John D. Ament napsal(a): > Not sure if we want to pollute the vote thread, so changing titles. Makes sense. > > I think to summarize my feelings, think about the relationship between > interface Foo and implementation FooImpl. Foo is defined: > > interface Foo { > String doWork(); > } > > FooImpl is defined as: > > public class FooImpl implements Foo { > public String doWork() { return "i'm done"; } > > public final String doSomethingElse() { return "something else"; } > > } > > The way CDI impls work right now, the proxy is created for the impl. > The way EJBs proxy right now, they proxy the interface. If CDI proxied > both the interface and impl separately, and substituted based on the > injection point, this would work. If you create two proxies, one for Foo and one for FooImpl, then it would only work for @Inject Foo - if we @Inject FooImpl then we have the same problem (at least with subclassing). > > > On Wed, Feb 10, 2016 at 8:07 AM Martin Kouba > wrote: > > Dne 10.2.2016 v 13:48 John D. Ament napsal(a): > > +1 for adding this feature to the spec. > > > > -1 for adding it the way it is written currently. This isn't to say > > that Mark's idea is bad, its just that it puts too much onus on the > > application developer to know the structure of its classes, both > > internally developed and externally provided. > > > > We should follow a pattern closer to EJB (in my opinion) where the > > non-proxyable methods are just not proxied - you won't get > transactions, > > etc available. > > -1 > > I think you cannot declare a final method on a NIV session bean (you get > validation error) and it's easy to create a proxy for local/remote > interface - no such methods. I also think we cannot implement this in > Weld as we're using subclassing for client proxies. If you don't > override (i.e. if you ignore) such a method than it will not be invoked > upon the contextual instance but upon the clien proxy instance > (subclass). > > > > > John > > > > On Tue, Feb 9, 2016 at 11:37 AM Antoine Sabot-Durand > > > >> > wrote: > > > > Hi all, > > > > There have been a lot of discussion around CDI-527 in the > last weeks: > > https://issues.jboss.org/browse/CDI-527 > > > > Mark proposed a PR: > > https://github.com/cdi-spec/cdi/pull/271 > > > > But we don't agree on adding this feature to the spec. > > This vote is to decide if we should add this feature at the spec > > level now, or not. > > Should we vote this feature down, that won't mean it will be > > completely dropped: it could be implemented as non portable > feature > > in both Spec or even be included as experimental feature in > the spec > > (in annexes) as describe in the PR comments > > Vote starts now, only vote from EG members are binding (but > you can > > give your opinion if not part of the EG) and will last 72 hours. > > > > You vote with the following values: > > +1 : I'm favorable for adding this feature in the spec > > -1 : I'm against adding this feature in the spec > > 0 : I don't care > > > > Thank you for your attention and your vote. > > > > Antoine Sabot-Durand > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider > licenses > > the code under the Apache License, Version 2 > > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > > ideas provided on this list, the provider waives all patent and > > other intellectual property rights inherent in such information. > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider > licenses the code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > ideas provided on this list, the provider waives all patent and > other intellectual property rights inherent in such information. > > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > -- Martin Kouba Software Engineer Red Hat, Czech Republic From struberg at yahoo.de Wed Feb 10 08:31:57 2016 From: struberg at yahoo.de (Mark Struberg) Date: Wed, 10 Feb 2016 14:31:57 +0100 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: <56E028B8-1CDB-4077-B4BD-ACCB49EA9D3E@yahoo.de> > We should follow a pattern closer to EJB (in my opinion) where the non-proxyable methods are just not proxied - you won?t get transactions, etc available. But that?s exactly what it does! If you have an EJB NIV then final methods are allowed and you don?t even get a warning. But if the user invokes this method then unforseeable things happen because the invocation will end up on the proxy instance and not on the internally delegated instance. That?s the reason why we have the UnproxyableResolutionException which you will _normally_ get for this cases in CDI. In that case the first thing to do is to remove the ?final? modifier from this method. But sometimes the developer simply doesn?t have any chance! For example if the classes to proxy are from a 3rd party library or even from the JDK itself! For those cases we now have a way to let the developer declare ?omg, I know it?s bad, but I need to do this anyway but I only add an exclusion to the rule for this very class!? txs and LieGrue, strub > Am 10.02.2016 um 13:48 schrieb John D. Ament : > > +1 for adding this feature to the spec. > > -1 for adding it the way it is written currently. This isn't to say that Mark's idea is bad, its just that it puts too much onus on the application developer to know the structure of its classes, both internally developed and externally provided. > > We should follow a pattern closer to EJB (in my opinion) where the non-proxyable methods are just not proxied - you won't get transactions, etc available. > > John > > On Tue, Feb 9, 2016 at 11:37 AM Antoine Sabot-Durand wrote: > Hi all, > > There have been a lot of discussion around CDI-527 in the last weeks: > https://issues.jboss.org/browse/CDI-527 > > Mark proposed a PR: > https://github.com/cdi-spec/cdi/pull/271 > > But we don't agree on adding this feature to the spec. > This vote is to decide if we should add this feature at the spec level now, or not. > Should we vote this feature down, that won't mean it will be completely dropped: it could be implemented as non portable feature in both Spec or even be included as experimental feature in the spec (in annexes) as describe in the PR comments > Vote starts now, only vote from EG members are binding (but you can give your opinion if not part of the EG) and will last 72 hours. > > You vote with the following values: > +1 : I'm favorable for adding this feature in the spec > -1 : I'm against adding this feature in the spec > 0 : I don't care > > Thank you for your attention and your vote. > > Antoine Sabot-Durand > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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 Wed Feb 10 08:32:30 2016 From: struberg at yahoo.de (Mark Struberg) Date: Wed, 10 Feb 2016 14:32:30 +0100 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: <56BB360A.2040906@redhat.com> References: <56BB360A.2040906@redhat.com> Message-ID: <4B42D4C9-36F5-4AF7-AFFB-3D9C5527987D@yahoo.de> go on and read the EJB-3.2 spec. sure you can! LieGrue, strub > Am 10.02.2016 um 14:07 schrieb Martin Kouba : > > Dne 10.2.2016 v 13:48 John D. Ament napsal(a): >> +1 for adding this feature to the spec. >> >> -1 for adding it the way it is written currently. This isn't to say >> that Mark's idea is bad, its just that it puts too much onus on the >> application developer to know the structure of its classes, both >> internally developed and externally provided. >> >> We should follow a pattern closer to EJB (in my opinion) where the >> non-proxyable methods are just not proxied - you won't get transactions, >> etc available. > > -1 > > I think you cannot declare a final method on a NIV session bean (you get > validation error) and it's easy to create a proxy for local/remote > interface - no such methods. I also think we cannot implement this in > Weld as we're using subclassing for client proxies. If you don't > override (i.e. if you ignore) such a method than it will not be invoked > upon the contextual instance but upon the clien proxy instance (subclass). > >> >> John >> >> On Tue, Feb 9, 2016 at 11:37 AM Antoine Sabot-Durand >> > wrote: >> >> Hi all, >> >> There have been a lot of discussion around CDI-527 in the last weeks: >> https://issues.jboss.org/browse/CDI-527 >> >> Mark proposed a PR: >> https://github.com/cdi-spec/cdi/pull/271 >> >> But we don't agree on adding this feature to the spec. >> This vote is to decide if we should add this feature at the spec >> level now, or not. >> Should we vote this feature down, that won't mean it will be >> completely dropped: it could be implemented as non portable feature >> in both Spec or even be included as experimental feature in the spec >> (in annexes) as describe in the PR comments >> Vote starts now, only vote from EG members are binding (but you can >> give your opinion if not part of the EG) and will last 72 hours. >> >> You vote with the following values: >> +1 : I'm favorable for adding this feature in the spec >> -1 : I'm against adding this feature in the spec >> 0 : I don't care >> >> Thank you for your attention and your vote. >> >> Antoine Sabot-Durand >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses >> the code under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >> ideas provided on this list, the provider waives all patent and >> other intellectual property rights inherent in such information. >> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From struberg at yahoo.de Wed Feb 10 08:36:58 2016 From: struberg at yahoo.de (Mark Struberg) Date: Wed, 10 Feb 2016 14:36:58 +0100 Subject: [cdi-dev] Can proxying be handled the way done in EJB? In-Reply-To: References: <56BB360A.2040906@redhat.com> Message-ID: <1791010B-70B2-4E18-A198-E44B4D794CAC@yahoo.de> Indeed, or as simple as having the producer not create a SomeBlaImpl but the SomeBla interface. That was my case a) in the CDI ticket. And of course this should be prefered to the allowProxing exception. BUT you 1.) not always have an interface and 2.) sometimes (like with some JDK classes) you really need the impl and 3.) sometimes you need to create subclasses of a 3rd party class. And with subclassing there is no way to get rid of a final method :/ LieGrue, strub > Am 10.02.2016 um 14:12 schrieb John D. Ament : > > Not sure if we want to pollute the vote thread, so changing titles. > > I think to summarize my feelings, think about the relationship between interface Foo and implementation FooImpl. Foo is defined: > > interface Foo { > String doWork(); > } > > FooImpl is defined as: > > public class FooImpl implements Foo { > public String doWork() { return "i'm done"; } > > public final String doSomethingElse() { return "something else"; } > > } > > The way CDI impls work right now, the proxy is created for the impl. The way EJBs proxy right now, they proxy the interface. If CDI proxied both the interface and impl separately, and substituted based on the injection point, this would work. > > > On Wed, Feb 10, 2016 at 8:07 AM Martin Kouba wrote: > Dne 10.2.2016 v 13:48 John D. Ament napsal(a): > > +1 for adding this feature to the spec. > > > > -1 for adding it the way it is written currently. This isn't to say > > that Mark's idea is bad, its just that it puts too much onus on the > > application developer to know the structure of its classes, both > > internally developed and externally provided. > > > > We should follow a pattern closer to EJB (in my opinion) where the > > non-proxyable methods are just not proxied - you won't get transactions, > > etc available. > > -1 > > I think you cannot declare a final method on a NIV session bean (you get > validation error) and it's easy to create a proxy for local/remote > interface - no such methods. I also think we cannot implement this in > Weld as we're using subclassing for client proxies. If you don't > override (i.e. if you ignore) such a method than it will not be invoked > upon the contextual instance but upon the clien proxy instance (subclass). > > > > > John > > > > On Tue, Feb 9, 2016 at 11:37 AM Antoine Sabot-Durand > > > wrote: > > > > Hi all, > > > > There have been a lot of discussion around CDI-527 in the last weeks: > > https://issues.jboss.org/browse/CDI-527 > > > > Mark proposed a PR: > > https://github.com/cdi-spec/cdi/pull/271 > > > > But we don't agree on adding this feature to the spec. > > This vote is to decide if we should add this feature at the spec > > level now, or not. > > Should we vote this feature down, that won't mean it will be > > completely dropped: it could be implemented as non portable feature > > in both Spec or even be included as experimental feature in the spec > > (in annexes) as describe in the PR comments > > Vote starts now, only vote from EG members are binding (but you can > > give your opinion if not part of the EG) and will last 72 hours. > > > > You vote with the following values: > > +1 : I'm favorable for adding this feature in the spec > > -1 : I'm against adding this feature in the spec > > 0 : I don't care > > > > Thank you for your attention and your vote. > > > > Antoine Sabot-Durand > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses > > the code under the Apache License, Version 2 > > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > > ideas provided on this list, the provider waives all patent and > > other intellectual property rights inherent in such information. > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From issues at jboss.org Wed Feb 10 09:26:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 10 Feb 2016 09:26:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-485) Provide literals for built-in annotations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba reassigned CDI-485: -------------------------------- Assignee: Martin Kouba > Provide literals for built-in annotations > ----------------------------------------- > > Key: CDI-485 > URL: https://issues.jboss.org/browse/CDI-485 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Assignee: Martin Kouba > > Annotation literals are often useful and therefore many projects implement them themselves. For example: > https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/literal/DefaultLiteral.java > https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/literal/DefaultLiteral.java > https://github.com/forge/furnace-cdi/blob/master/impl/src/main/java/org/jboss/forge/furnace/container/cdi/util/DefaultLiteral.java > https://github.com/astefanutti/metrics-cdi/blob/master/impl/src/main/java/io/astefanutti/metrics/cdi/DefaultLiteral.java > to name a few. > It would be nice to provide these within the CDI API, e.g: > {code:JAVA} > @Target( { TYPE, METHOD, PARAMETER, FIELD }) > @Retention(RUNTIME) > @Documented > @Qualifier > public @interface Default { > @SuppressWarnings("all") > final class Literal extends AnnotationLiteral implements Default { > private Literal() { > } > } > final Default INSTANCE = new Literal(); > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Feb 10 09:49:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 10 Feb 2016 09:49:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-485) Provide literals for built-in annotations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13161237#comment-13161237 ] Antoine Sabot-Durand commented on CDI-485: ------------------------------------------ +1 Don't forget {{NonBindingLiteral}} useful when declaring a 3rd party annotation as an interceptor binding. > Provide literals for built-in annotations > ----------------------------------------- > > Key: CDI-485 > URL: https://issues.jboss.org/browse/CDI-485 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Assignee: Martin Kouba > > Annotation literals are often useful and therefore many projects implement them themselves. For example: > https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/literal/DefaultLiteral.java > https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/literal/DefaultLiteral.java > https://github.com/forge/furnace-cdi/blob/master/impl/src/main/java/org/jboss/forge/furnace/container/cdi/util/DefaultLiteral.java > https://github.com/astefanutti/metrics-cdi/blob/master/impl/src/main/java/io/astefanutti/metrics/cdi/DefaultLiteral.java > to name a few. > It would be nice to provide these within the CDI API, e.g: > {code:JAVA} > @Target( { TYPE, METHOD, PARAMETER, FIELD }) > @Retention(RUNTIME) > @Documented > @Qualifier > public @interface Default { > @SuppressWarnings("all") > final class Literal extends AnnotationLiteral implements Default { > private Literal() { > } > } > final Default INSTANCE = new Literal(); > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Feb 11 05:07:01 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Thu, 11 Feb 2016 05:07:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-577) Non-Dependent scope specified on Decorator In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13161591#comment-13161591 ] Tomas Remes commented on CDI-577: --------------------------------- https://github.com/cdi-spec/cdi/pull/275 > Non-Dependent scope specified on Decorator > ------------------------------------------ > > Key: CDI-577 > URL: https://issues.jboss.org/browse/CDI-577 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Decorators > Affects Versions: 1.0, 1.2.Final > Reporter: Emily Jiang > Priority: Minor > Fix For: 2.0 (proposed) > > > In CDI specification, there lacks a clarification about what will happen if a scope other than Dependent specified on Decorators/Interceptors. > At the moment, if the RequestScoped is specified on a decorator, Weld throws NPE. I talked to Martin. Martin logged https://issues.jboss.org/browse/WELD-2085 to fix this. It is better for the spec to clearly define the behaviour. > Obviously, the lifecycle of interceptors/decorators are dependent on the bean instance they decorate. The spec should specify clearly what should happen if a scope other than Dependent is specified on decorators/interceptors. How about add the following on the spec: > If an interceptor or decorator specifies any scope other than Dependent, the container automatically detects the problem and threats as a definition error. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From ggastald at redhat.com Thu Feb 11 06:09:57 2016 From: ggastald at redhat.com (George Gastaldi) Date: Thu, 11 Feb 2016 12:09:57 +0100 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods Message-ID: +1 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160211/c0aa598e/attachment.html From subaochen at 126.com Thu Feb 11 09:46:56 2016 From: subaochen at 126.com (baochen su) Date: Thu, 11 Feb 2016 07:46:56 -0700 (MST) Subject: [cdi-dev] test weld 3.0.0-SNAPSHOT with wildfly 9.0 Message-ID: <1455202016675-5712457.post@n5.nabble.com> hi all, I want to test weld-core 3.0.0-SNAPSHOT with wildfly-9.0.2.Final, but because no probe directory exists in modules/system/layers/base/org/jboss/weld, so mvn package -Pupdate-jboss-as ... failed. I have modify jboss-as/pom.xml and add those lines just before : this works fine, but one problem remain: file "module.xml" for probe not provided by wildfly, so how can I find or create suitable module.xml for probe? Or, any patch needed for the missing module.xml file to pom.xml? Thanks in advance! -- View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/test-weld-3-0-0-SNAPSHOT-with-wildfly-9-0-tp5712457.html Sent from the CDI Development mailing list mailing list archive at Nabble.com. From subaochen at 126.com Thu Feb 11 09:53:01 2016 From: subaochen at 126.com (subaochen) Date: Thu, 11 Feb 2016 22:53:01 +0800 (CST) Subject: [cdi-dev] test weld 3.0.0-SNAPSHOT with wildfly-9.0.2? Message-ID: <564ad05e.1726.152d0d23095.Coremail.subaochen@126.com> hi all, I want to test weld-core 3.0.0-SNAPSHOT with wildfly-9.0.2.Final, but because no probe directory exists in modules/system/layers/base/org/jboss/weld, so mvn package -Pupdate-jboss-as ... failed. I have modify jboss-as/pom.xml and add those lines just before : this works fine, but one problem remain: file "module.xml" for probe not provided by wildfly, so how can I find or create suitable module.xml for probe? Or, any patch needed for the missing module.xml file to pom.xml? Thanks in advance! -- Best regards, ??? ----------------------------------------------------------- ??????http://dz.sdut.edu.cn/wiki ?????http://dz.sdut.edu.cn/blog/subaochen ?????http://weibo.com/subaochen ?????baochensu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160211/a9c918a1/attachment.html From mkouba at redhat.com Fri Feb 12 02:21:53 2016 From: mkouba at redhat.com (Martin Kouba) Date: Fri, 12 Feb 2016 08:21:53 +0100 Subject: [cdi-dev] test weld 3.0.0-SNAPSHOT with wildfly 9.0 In-Reply-To: <1455202016675-5712457.post@n5.nabble.com> References: <1455202016675-5712457.post@n5.nabble.com> Message-ID: <56BD8811.9010302@redhat.com> Hi, this question should have been sent to the weld-dev ML. I'm going to forward the message and leave out the cdi-dev. Martin Dne 11.2.2016 v 15:46 baochen su napsal(a): > hi all, > > I want to test weld-core 3.0.0-SNAPSHOT with wildfly-9.0.2.Final, but > because no probe directory exists in > modules/system/layers/base/org/jboss/weld, so mvn package -Pupdate-jboss-as > ... failed. > > I have modify jboss-as/pom.xml and add those lines just before : > > dir="${module.dir}/core/main"/> > dir="${module.dir}/spi/main"/> > dir="${module.dir}/api/main"/> > dir="${module.dir}/probe/main"/> > > this works fine, but one problem remain: file "module.xml" for probe not > provided by wildfly, so how can I find or create suitable module.xml for > probe? Or, any patch needed for the missing module.xml file to pom.xml? > > Thanks in advance! > > > > -- > View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/test-weld-3-0-0-SNAPSHOT-with-wildfly-9-0-tp5712457.html > Sent from the CDI Development mailing list mailing list archive at Nabble.com. > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > -- Martin Kouba Software Engineer Red Hat, Czech Republic From issues at jboss.org Fri Feb 12 03:07:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 12 Feb 2016 03:07:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13162035#comment-13162035 ] Antoine Sabot-Durand commented on CDI-580: ------------------------------------------ We discussed this feature during last F2F meeting. My suggestion was to introduce a {{BeanInstanceBuilder}} interface to generate an unmanaged instance for a given {{AnnotatedType}}. This is inspired by the existing {{UnManaged}} helper class for injecting and calling lifecycle callbacks unmanaged instances. {{UnManaged}} only uses a class (containing @Inject, @PostConstruct and @Presdetroy annotations) to create instances, {{BeanInstanceBuilder}} would use an {{AnnotatedType}} allowing the use of a synthetic {{AnnotatedType}} containing annotations added by the user like interceptor bindings or {{@Inject}} mentions not present in the original class. We should forbid or ignore other annotations (scope, qualifier on class This would allow applying interceptor on a produced class but also interceptor on method in the produced class. And finally it could also be used to have interceptor on custom beans. Code would look like this {code} public class MyAdvancedProducerBean { public BeanInstanceProducer bip = Builders.beanInstanceProducer(); @Produces @RequestScoped public MyClass produceTransactionalMyClass() { AnnotatedTypeBuilder atb = Builders.annotatedType(Myclass.class) .read(MyClass.class) .addToType(new TransactionalLiteral()); return bip.read(atb.build()).inject().postConstruct().intercept().decorate().get(); // injection, callbacks and proxies creation } public void disposeMyClass (@Disposes Myclass td) { bip.dispose(td); } } {code} The important point is that BeanInstanceProducer is an interface so implementation will use specific proxy feature of Weld or OWB. wdyt? > Allow interceptors and decorators to be applied to the return value of a producer method > ---------------------------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Feb 12 03:53:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Fri, 12 Feb 2016 03:53:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13162052#comment-13162052 ] Mark Struberg commented on CDI-580: ----------------------------------- BeanInstanceProducer which is stripped of almost everything a bean does (besides interceptors/decorators)? > Allow interceptors and decorators to be applied to the return value of a producer method > ---------------------------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Feb 12 04:04:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 12 Feb 2016 04:04:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13162063#comment-13162063 ] Antoine Sabot-Durand commented on CDI-580: ------------------------------------------ Or {{UnmanagedInstance}} plus interceptor and decorators. Delivered instances are not managed by the container. Of course in the Producer use case, the result will be managed but because of {{@Produces}} not {{BeanInstanceProducer}}. > Allow interceptors and decorators to be applied to the return value of a producer method > ---------------------------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Feb 12 04:18:01 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Fri, 12 Feb 2016 04:18:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13162074#comment-13162074 ] Romain Manni-Bucau commented on CDI-580: ---------------------------------------- Can't the disposal part be implicit? The container knows it destroys the produced instance and that it is an intercepted one so it should be able to destroy it alone, no? > Allow interceptors and decorators to be applied to the return value of a producer method > ---------------------------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Feb 12 04:55:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 12 Feb 2016 04:55:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13162094#comment-13162094 ] Antoine Sabot-Durand commented on CDI-580: ------------------------------------------ I'd like to have it implicit. But [~mkouba] raised some reason I don't remember to have this pattern. > Allow interceptors and decorators to be applied to the return value of a producer method > ---------------------------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Feb 12 05:24:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Fri, 12 Feb 2016 05:24:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13162114#comment-13162114 ] Mark Struberg commented on CDI-580: ----------------------------------- Or probably give the user the whole toolset for creating subclassing proxies in it's hand? A user could then basically do what I explained in https://struberg.wordpress.com/2016/01/30/applying-interceptors-to-producer-methods/ but not only for interfaces but also for classes. Means we introduce javax.proxy and create something similar to java.lang.reflect.Proxy but for subclassing proxies. > Allow interceptors and decorators to be applied to the return value of a producer method > ---------------------------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Feb 12 05:37:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 12 Feb 2016 05:37:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-581) possible chicken-egg problem with ProcessBeanAttributes#veto and specialization In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13162122#comment-13162122 ] Martin Kouba commented on CDI-581: ---------------------------------- Implementation notes: In Weld, {{ProcessBeanAttributes}} delivery is divided in multiple phases. Let's assume we have the following classes: {code:java} @Specializes class B extends A { } // This bean is specialized class A { } {code} The processing is roughly as follows: # Fire PBA for all beans which are not specialized and are enabled in any bean archive (i.e. not an alternative, or selected alternative) -> fire event for B # If any bean is vetoed within PBA delivery (e.g. during delivery for B), find alll specialized beans and repeat the process recursively (i.e. go to 1 for A) Most likely it does not work 100% but it should work in most cases. I agree that the wording _"if the class is an enabled bean"_ is not clear and should be clarified. > possible chicken-egg problem with ProcessBeanAttributes#veto and specialization > ------------------------------------------------------------------------------- > > Key: CDI-581 > URL: https://issues.jboss.org/browse/CDI-581 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Mark Struberg > > Currently section 12 describes that ProcessBeanAttributes only should get fired for 'enabed beans'. > {quote} > 12.4.3. Bean discovery > * if the class is an enabled bean, interceptor or decorator, fire an event of type ProcessBeanAttributes, as defined in ProcessBeanAttributes event, > {quote} > But if you have class B extends A and B is @Specializes then you don't know which PBA to fire. Because B could get vetoed in ProcessBeanAttributes. And then while you fire PBA you implicitly change the list of enabled beans. This gets even more complicated by the ability of ProcessBeanAttributes to change the isAlternative bit and even the types of the whole bean. > I think this might be a left-over of the split between Bean and BeanAttributes. The ProcessBeanAttributes is right in the middle between ProcessAnnotatedType and ProcessBean. > * ProcessBean die _not_ have a veto(), PAT does have it. > * PAT gets fired for all discovered classes, ProcessBean only for enabled ones. > I think the wording 'if the class is an enabled *bean*' is also misleading. We do _not_ have a bean at this early stage! We only have an AnnotatedType. Maybe it should read ''if the class is a not vetoed AnnotatedType'? > I'm not sure if there is a way the current wording could get cleanly implemented. I just stumbled across this because we did _not_ fire a PBA for a class because the @Specialized bean got vetoed away. > The same chicken-egg problem might apply to > {quote} > 11.5.9. ProcessBeanAttributes event > The container must fire an event for each bean, interceptor or decorator deployed in a bean > archive, before registering the Bean object." > {quote} > Reads "for every bean". But we don't have any beans yet. We can only make the Bean after the BeanAttributes get returned from PBA. Otherwise changing the bean attributes would have no effect on the Bean, right? > > What could work is roughly: > * fire PAT for all detected classes > * remove vetoed ones > * fire PBA for all AnnotatedTypes > * remove vetoed one > * calculate disabled BeanAttributes (@Specializes rule for classes) > * produce Beans -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Feb 12 05:51:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Fri, 12 Feb 2016 05:51:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-581) possible chicken-egg problem with ProcessBeanAttributes#veto and specialization In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13162128#comment-13162128 ] Mark Struberg commented on CDI-581: ----------------------------------- Thanks Martin. I also think that this solution will get 'close' but will not hit 100%. The question now is if we are happy with a 'somehow close' solution or we like to nail it down 100%? In my personal opinion it's much preferable to have a clear rule and the processing is always strictly unidirectional and acyclic. With having those 'cycles' in the processing we get 2 imo undesired results: 1.) It's pretty much almost unpredictable for a random joe user what will happen. That's imo a big drawback 2.) We the rest of the cases which isn't solved by the complex cycling will end up being non-deterministic. Thus having an app which will work at one boot but fail (or just have a different behaviour) on another boot. I really prefer to always send the ProcessBeanAttributes for all non-vetoed AnnotatedTypes and then have a clear sheet to determine which Bean are not enabled and thus could get skipped. A PBA event for a later disabled bean is imo way better than missing a PBA event for a bean which is finally valid and in production. > possible chicken-egg problem with ProcessBeanAttributes#veto and specialization > ------------------------------------------------------------------------------- > > Key: CDI-581 > URL: https://issues.jboss.org/browse/CDI-581 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Mark Struberg > > Currently section 12 describes that ProcessBeanAttributes only should get fired for 'enabed beans'. > {quote} > 12.4.3. Bean discovery > * if the class is an enabled bean, interceptor or decorator, fire an event of type ProcessBeanAttributes, as defined in ProcessBeanAttributes event, > {quote} > But if you have class B extends A and B is @Specializes then you don't know which PBA to fire. Because B could get vetoed in ProcessBeanAttributes. And then while you fire PBA you implicitly change the list of enabled beans. This gets even more complicated by the ability of ProcessBeanAttributes to change the isAlternative bit and even the types of the whole bean. > I think this might be a left-over of the split between Bean and BeanAttributes. The ProcessBeanAttributes is right in the middle between ProcessAnnotatedType and ProcessBean. > * ProcessBean die _not_ have a veto(), PAT does have it. > * PAT gets fired for all discovered classes, ProcessBean only for enabled ones. > I think the wording 'if the class is an enabled *bean*' is also misleading. We do _not_ have a bean at this early stage! We only have an AnnotatedType. Maybe it should read ''if the class is a not vetoed AnnotatedType'? > I'm not sure if there is a way the current wording could get cleanly implemented. I just stumbled across this because we did _not_ fire a PBA for a class because the @Specialized bean got vetoed away. > The same chicken-egg problem might apply to > {quote} > 11.5.9. ProcessBeanAttributes event > The container must fire an event for each bean, interceptor or decorator deployed in a bean > archive, before registering the Bean object." > {quote} > Reads "for every bean". But we don't have any beans yet. We can only make the Bean after the BeanAttributes get returned from PBA. Otherwise changing the bean attributes would have no effect on the Bean, right? > > What could work is roughly: > * fire PAT for all detected classes > * remove vetoed ones > * fire PBA for all AnnotatedTypes > * remove vetoed one > * calculate disabled BeanAttributes (@Specializes rule for classes) > * produce Beans -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Feb 12 05:52:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Fri, 12 Feb 2016 05:52:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-581) possible chicken-egg problem with ProcessBeanAttributes#veto and specialization In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13162128#comment-13162128 ] Mark Struberg edited comment on CDI-581 at 2/12/16 5:51 AM: ------------------------------------------------------------ Thanks Martin. I also think that this solution will get 'close' but will not hit 100%. The question now is if we are happy with a 'somehow close' solution or we like to nail it down 100%? In my personal opinion it's much preferable to have a clear rule and the processing is always strictly unidirectional and acyclic. With having those 'cycles' in the processing we get 2 imo undesired results: 1.) It's pretty much almost unpredictable for a random joe user what will happen. That's imo a big drawback 2.) The rest of the cases which isn't solved by the complex cycling will end up being non-deterministic. Thus having an app which will work at one boot but fail (or just have a different behaviour) on another boot. I really prefer to always send the ProcessBeanAttributes for all non-vetoed AnnotatedTypes and then have a clear sheet to determine which Bean are not enabled and thus could get skipped. A PBA event for a later disabled bean is imo way better than missing a PBA event for a bean which is finally valid and in production. was (Author: struberg): Thanks Martin. I also think that this solution will get 'close' but will not hit 100%. The question now is if we are happy with a 'somehow close' solution or we like to nail it down 100%? In my personal opinion it's much preferable to have a clear rule and the processing is always strictly unidirectional and acyclic. With having those 'cycles' in the processing we get 2 imo undesired results: 1.) It's pretty much almost unpredictable for a random joe user what will happen. That's imo a big drawback 2.) We the rest of the cases which isn't solved by the complex cycling will end up being non-deterministic. Thus having an app which will work at one boot but fail (or just have a different behaviour) on another boot. I really prefer to always send the ProcessBeanAttributes for all non-vetoed AnnotatedTypes and then have a clear sheet to determine which Bean are not enabled and thus could get skipped. A PBA event for a later disabled bean is imo way better than missing a PBA event for a bean which is finally valid and in production. > possible chicken-egg problem with ProcessBeanAttributes#veto and specialization > ------------------------------------------------------------------------------- > > Key: CDI-581 > URL: https://issues.jboss.org/browse/CDI-581 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Mark Struberg > > Currently section 12 describes that ProcessBeanAttributes only should get fired for 'enabed beans'. > {quote} > 12.4.3. Bean discovery > * if the class is an enabled bean, interceptor or decorator, fire an event of type ProcessBeanAttributes, as defined in ProcessBeanAttributes event, > {quote} > But if you have class B extends A and B is @Specializes then you don't know which PBA to fire. Because B could get vetoed in ProcessBeanAttributes. And then while you fire PBA you implicitly change the list of enabled beans. This gets even more complicated by the ability of ProcessBeanAttributes to change the isAlternative bit and even the types of the whole bean. > I think this might be a left-over of the split between Bean and BeanAttributes. The ProcessBeanAttributes is right in the middle between ProcessAnnotatedType and ProcessBean. > * ProcessBean die _not_ have a veto(), PAT does have it. > * PAT gets fired for all discovered classes, ProcessBean only for enabled ones. > I think the wording 'if the class is an enabled *bean*' is also misleading. We do _not_ have a bean at this early stage! We only have an AnnotatedType. Maybe it should read ''if the class is a not vetoed AnnotatedType'? > I'm not sure if there is a way the current wording could get cleanly implemented. I just stumbled across this because we did _not_ fire a PBA for a class because the @Specialized bean got vetoed away. > The same chicken-egg problem might apply to > {quote} > 11.5.9. ProcessBeanAttributes event > The container must fire an event for each bean, interceptor or decorator deployed in a bean > archive, before registering the Bean object." > {quote} > Reads "for every bean". But we don't have any beans yet. We can only make the Bean after the BeanAttributes get returned from PBA. Otherwise changing the bean attributes would have no effect on the Bean, right? > > What could work is roughly: > * fire PAT for all detected classes > * remove vetoed ones > * fire PBA for all AnnotatedTypes > * remove vetoed one > * calculate disabled BeanAttributes (@Specializes rule for classes) > * produce Beans -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Feb 12 06:03:00 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Fri, 12 Feb 2016 06:03:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-581) possible chicken-egg problem with ProcessBeanAttributes#veto and specialization In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13162131#comment-13162131 ] Romain Manni-Bucau commented on CDI-581: ---------------------------------------- Agree with Mark. Having anything not 100% reliable makes its usage impossible in practise. > possible chicken-egg problem with ProcessBeanAttributes#veto and specialization > ------------------------------------------------------------------------------- > > Key: CDI-581 > URL: https://issues.jboss.org/browse/CDI-581 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Mark Struberg > > Currently section 12 describes that ProcessBeanAttributes only should get fired for 'enabed beans'. > {quote} > 12.4.3. Bean discovery > * if the class is an enabled bean, interceptor or decorator, fire an event of type ProcessBeanAttributes, as defined in ProcessBeanAttributes event, > {quote} > But if you have class B extends A and B is @Specializes then you don't know which PBA to fire. Because B could get vetoed in ProcessBeanAttributes. And then while you fire PBA you implicitly change the list of enabled beans. This gets even more complicated by the ability of ProcessBeanAttributes to change the isAlternative bit and even the types of the whole bean. > I think this might be a left-over of the split between Bean and BeanAttributes. The ProcessBeanAttributes is right in the middle between ProcessAnnotatedType and ProcessBean. > * ProcessBean die _not_ have a veto(), PAT does have it. > * PAT gets fired for all discovered classes, ProcessBean only for enabled ones. > I think the wording 'if the class is an enabled *bean*' is also misleading. We do _not_ have a bean at this early stage! We only have an AnnotatedType. Maybe it should read ''if the class is a not vetoed AnnotatedType'? > I'm not sure if there is a way the current wording could get cleanly implemented. I just stumbled across this because we did _not_ fire a PBA for a class because the @Specialized bean got vetoed away. > The same chicken-egg problem might apply to > {quote} > 11.5.9. ProcessBeanAttributes event > The container must fire an event for each bean, interceptor or decorator deployed in a bean > archive, before registering the Bean object." > {quote} > Reads "for every bean". But we don't have any beans yet. We can only make the Bean after the BeanAttributes get returned from PBA. Otherwise changing the bean attributes would have no effect on the Bean, right? > > What could work is roughly: > * fire PAT for all detected classes > * remove vetoed ones > * fire PBA for all AnnotatedTypes > * remove vetoed one > * calculate disabled BeanAttributes (@Specializes rule for classes) > * produce Beans -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Feb 12 08:56:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 12 Feb 2016 08:56:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-583) Observer resolution doesn't support Lambdas In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-583: ---------------------------------------- Summary: Observer resolution doesn't support Lambdas Key: CDI-583 URL: https://issues.jboss.org/browse/CDI-583 Project: CDI Specification Issues Issue Type: Bug Components: Events Affects Versions: 2.0-EDR1, 1.2.Final Reporter: Antoine Sabot-Durand As stated in various discussion on JDK8, lambda expressions don't allow to retrieve parameter types by reflection. See: http://jdk8-dev.openjdk.java.narkive.com/bSPiKxap/jdk-8-lambda-reflection-issues As section 10.1 of the spec states: bq. The event types of the event include all superclasses and interfaces of the runtime class of the event object. In case of a lambda payload, observer resolution will fails when respecting the rule above since parameter type won't be retrieve from the lambda. For instance the following code {code} @Inject Event> stringSupplierEvent; ... Supplier stringSupplier = () -> "Hello world"; stringSupplierEvent.fire(stringSupplier); {code} will triggers an observer for {{Supplier}} but not an observer for {{Supplier}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Feb 12 09:02:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 12 Feb 2016 09:02:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-583) Observer resolution doesn't support Lambdas In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13162231#comment-13162231 ] Antoine Sabot-Durand commented on CDI-583: ------------------------------------------ As discussed in WELD-2108, we should consider adding to the event types, the type defined at Event injection point to satisfy this use case. But this should be done carefully to see if it doesn't add any regression to event behaviour. > Observer resolution doesn't support Lambdas > ------------------------------------------- > > Key: CDI-583 > URL: https://issues.jboss.org/browse/CDI-583 > Project: CDI Specification Issues > Issue Type: Bug > Components: Events > Affects Versions: 1.2.Final, 2.0-EDR1 > Reporter: Antoine Sabot-Durand > > As stated in various discussion on JDK8, lambda expressions don't allow to retrieve parameter types by reflection. > See: > http://jdk8-dev.openjdk.java.narkive.com/bSPiKxap/jdk-8-lambda-reflection-issues > As section 10.1 of the spec states: > bq. The event types of the event include all superclasses and interfaces of the runtime class of the event object. > In case of a lambda payload, observer resolution will fails when respecting the rule above since parameter type won't be retrieve from the lambda. > For instance the following code > {code} > @Inject > Event> stringSupplierEvent; > ... > Supplier stringSupplier = () -> "Hello world"; > stringSupplierEvent.fire(stringSupplier); > {code} > will triggers an observer for {{Supplier}} but not an observer for {{Supplier}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From jose.paumard at gmail.com Fri Feb 12 09:41:39 2016 From: jose.paumard at gmail.com (=?UTF-8?Q?Jos=C3=A9_Paumard?=) Date: Fri, 12 Feb 2016 15:41:39 +0100 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: -1 For me it looks like setting implementation details in the specification, a really wrong idea imho. Plus, what does "proxy" mean ? We need to define the term in the spec. Does it refer to java.lang.Proxy ? We all know that this class has been written a long time ago, it has poor performance, and has already submitted replacements based on MethodHandle and INDY. Jos? 2016-02-11 12:09 GMT+01:00 George Gastaldi : > +1 > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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 M : +33 6 76 82 91 47 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160212/f8238e3e/attachment.html From struberg at yahoo.de Fri Feb 12 09:55:45 2016 From: struberg at yahoo.de (Mark Struberg) Date: Fri, 12 Feb 2016 15:55:45 +0100 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: <0421B4DD-0A57-46FD-A959-749B3555CDC2@yahoo.de> I have no clue where some folks get the idea that I introduced a new concept! The term ?proxy? is well defined both in the the whole Java universe (see java.lang.reflect.Proxy) and also got introduced in the CDI spec as early as 2008. That makes 8 years now? Wanna get rid of all that? > it has poor performance, and FUD and not true anymore since ages! It?s an implementation detail. In OpenWebBeans we do 10 MILLION proxy invocations in 20 milliseconds on my notebook. I don?t call that slow? LieGrue, strub > Am 12.02.2016 um 15:41 schrieb Jos? Paumard : > > -1 > > For me it looks like setting implementation details in the specification, a really wrong idea imho. > > Plus, what does "proxy" mean ? We need to define the term in the spec. Does it refer to java.lang.Proxy ? We all know that this class has been written a long time ago, it has poor performance, and has already submitted replacements based on MethodHandle and INDY. > > Jos? > > > 2016-02-11 12:09 GMT+01:00 George Gastaldi : > +1 > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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 > M : +33 6 76 82 91 47 > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From j.j.snyder at oracle.com Fri Feb 12 10:02:51 2016 From: j.j.snyder at oracle.com (JJ Snyder) Date: Fri, 12 Feb 2016 10:02:51 -0500 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: <56BDF41B.5060003@oracle.com> +1 On 02/09/2016 11:36 AM, Antoine Sabot-Durand wrote: > Hi all, > > There have been a lot of discussion around CDI-527 in the last weeks: > https://issues.jboss.org/browse/CDI-527 > > Mark proposed a PR: > https://github.com/cdi-spec/cdi/pull/271 > > But we don't agree on adding this feature to the spec. > This vote is to decide if we should add this feature at the spec level > now, or not. > Should we vote this feature down, that won't mean it will be > completely dropped: it could be implemented as non portable feature in > both Spec or even be included as experimental feature in the spec (in > annexes) as describe in the PR comments > Vote starts now, only vote from EG members are binding (but you can > give your opinion if not part of the EG) and will last 72 hours. > > You vote with the following values: > +1 : I'm favorable for adding this feature in the spec > -1 : I'm against adding this feature in the spec > 0 : I don't care > > Thank you for your attention and your vote. > > Antoine Sabot-Durand > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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/20160212/82f84c5c/attachment.html From jose.paumard at gmail.com Fri Feb 12 10:03:50 2016 From: jose.paumard at gmail.com (=?UTF-8?Q?Jos=C3=A9_Paumard?=) Date: Fri, 12 Feb 2016 16:03:50 +0100 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: <0421B4DD-0A57-46FD-A959-749B3555CDC2@yahoo.de> References: <0421B4DD-0A57-46FD-A959-749B3555CDC2@yahoo.de> Message-ID: Sorry Mark I dont have the time nor the energy to go through one more useless polemic with you. You can check this: https://www.jfokus.se/jfokus15/preso/proxy2.pdf. 2016-02-12 15:55 GMT+01:00 Mark Struberg : > I have no clue where some folks get the idea that I introduced a new > concept! > The term ?proxy? is well defined both in the the whole Java universe (see > java.lang.reflect.Proxy) and also got introduced in the CDI spec as early > as 2008. That makes 8 years now? Wanna get rid of all that? > > > it has poor performance, and > FUD and not true anymore since ages! > It?s an implementation detail. In OpenWebBeans we do 10 MILLION proxy > invocations in 20 milliseconds on my notebook. I don?t call that slow? > > LieGrue, > strub > > > > Am 12.02.2016 um 15:41 schrieb Jos? Paumard : > > > > -1 > > > > For me it looks like setting implementation details in the > specification, a really wrong idea imho. > > > > Plus, what does "proxy" mean ? We need to define the term in the spec. > Does it refer to java.lang.Proxy ? We all know that this class has been > written a long time ago, it has poor performance, and has already submitted > replacements based on MethodHandle and INDY. > > > > Jos? > > > > > > 2016-02-11 12:09 GMT+01:00 George Gastaldi : > > +1 > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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 > > 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. > > -- Java le soir Cours Java en ligne Twitter Paris JUG M : +33 6 76 82 91 47 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160212/099e39be/attachment-0001.html From issues at jboss.org Fri Feb 12 10:29:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 12 Feb 2016 10:29:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-485) Provide literals for built-in annotations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13162322#comment-13162322 ] Martin Kouba commented on CDI-485: ---------------------------------- I'm going to add literals for: * {{javax.enterprise.inject.Any}} * {{javax.enterprise.inject.Default}} * {{javax.enterprise.inject.New}} * {{javax.enterprise.util.Nonbinding}} * {{javax.enterprise.context.Initialized}} * {{javax.enterprise.context.Destroyed}} * {{javax.enterprise.context.RequestScoped}} * {{javax.enterprise.context.SessionScoped}} * {{javax.enterprise.context.ApplicationScoped}} * {{javax.enterprise.context.Dependent}} * {{javax.enterprise.context.ConversationScoped}} * {{javax.enterprise.inject.Alternative}} * {{javax.enterprise.inject.Typed}} * {{javax.inject.Named}} * {{javax.inject.Qualifier}} * {{javax.inject.Singleton}} Any other tips? If possible I will place the literal as a static nested class inside the annotation definition (as Jozef suggested), so that one could use {{Any.Literal.INSTANCE}} or {{Initialized.Literal.of(RequestScoped.class)}}. > Provide literals for built-in annotations > ----------------------------------------- > > Key: CDI-485 > URL: https://issues.jboss.org/browse/CDI-485 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Assignee: Martin Kouba > > Annotation literals are often useful and therefore many projects implement them themselves. For example: > https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/literal/DefaultLiteral.java > https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/literal/DefaultLiteral.java > https://github.com/forge/furnace-cdi/blob/master/impl/src/main/java/org/jboss/forge/furnace/container/cdi/util/DefaultLiteral.java > https://github.com/astefanutti/metrics-cdi/blob/master/impl/src/main/java/io/astefanutti/metrics/cdi/DefaultLiteral.java > to name a few. > It would be nice to provide these within the CDI API, e.g: > {code:JAVA} > @Target( { TYPE, METHOD, PARAMETER, FIELD }) > @Retention(RUNTIME) > @Documented > @Qualifier > public @interface Default { > @SuppressWarnings("all") > final class Literal extends AnnotationLiteral implements Default { > private Literal() { > } > } > final Default INSTANCE = new Literal(); > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From struberg at yahoo.de Fri Feb 12 10:35:00 2016 From: struberg at yahoo.de (Mark Struberg) Date: Fri, 12 Feb 2016 16:35:00 +0100 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: References: <0421B4DD-0A57-46FD-A959-749B3555CDC2@yahoo.de> Message-ID: Jos?, the whole CDI spec requires proxying since almost the earliest betas (was about early 2008 when we introduced NormalScope). The UnPROXYableResolutionException + the wording about this implementation detail also exists since then. This is really nothing I freshly introduced (as your answer seemed to imply). Proxying is a design pattern and has not much to do with j.l.r.Proxy and it?s problems. jlr.Proxy (as most reflect stuff) also already became 100x faster since it?s introduction in java-1.3. The impl in older java versions was not great, but the API itself is not that bad. Of course it misses lambdas, etc. But all that doesn?t matter as we don?t use it anyway. proxying as pattern != jlr.Proxy Of course we miss an easy and portable way to create subclassing proxies in Java. I totally agree with R?my regarding this. But if you look at CDI-580 then we already proposed to introduce this feature. It has potential to be an own JSR but due to the overhead in the JCP and the limited time we could also do this as part of the CDI EG. Kind of how the Transaction, Interceptor and early JPA spec got handled inside the EJB EG. LieGrue, strub > Am 12.02.2016 um 16:03 schrieb Jos? Paumard : > > Sorry Mark I dont have the time nor the energy to go through one more useless polemic with you. > > You can check this: https://www.jfokus.se/jfokus15/preso/proxy2.pdf. > > 2016-02-12 15:55 GMT+01:00 Mark Struberg : > I have no clue where some folks get the idea that I introduced a new concept! > The term ?proxy? is well defined both in the the whole Java universe (see java.lang.reflect.Proxy) and also got introduced in the CDI spec as early as 2008. That makes 8 years now? Wanna get rid of all that? > > > it has poor performance, and > FUD and not true anymore since ages! > It?s an implementation detail. In OpenWebBeans we do 10 MILLION proxy invocations in 20 milliseconds on my notebook. I don?t call that slow? > > LieGrue, > strub > > > > Am 12.02.2016 um 15:41 schrieb Jos? Paumard : > > > > -1 > > > > For me it looks like setting implementation details in the specification, a really wrong idea imho. > > > > Plus, what does "proxy" mean ? We need to define the term in the spec. Does it refer to java.lang.Proxy ? We all know that this class has been written a long time ago, it has poor performance, and has already submitted replacements based on MethodHandle and INDY. > > > > Jos? > > > > > > 2016-02-11 12:09 GMT+01:00 George Gastaldi : > > +1 > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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 > > 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. > > > > > -- > Java le soir Cours Java en ligne > Twitter Paris JUG > M : +33 6 76 82 91 47 From issues at jboss.org Fri Feb 12 10:49:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 12 Feb 2016 10:49:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-485) Provide literals for built-in annotations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13162338#comment-13162338 ] Antoine Sabot-Durand commented on CDI-485: ------------------------------------------ And what about {{INSTANCE}} for annotations having members like {{@New}}, {{@Typed}}, {{@Destroyed}} or {{@Initialized}} ? > Provide literals for built-in annotations > ----------------------------------------- > > Key: CDI-485 > URL: https://issues.jboss.org/browse/CDI-485 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Assignee: Martin Kouba > > Annotation literals are often useful and therefore many projects implement them themselves. For example: > https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/literal/DefaultLiteral.java > https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/literal/DefaultLiteral.java > https://github.com/forge/furnace-cdi/blob/master/impl/src/main/java/org/jboss/forge/furnace/container/cdi/util/DefaultLiteral.java > https://github.com/astefanutti/metrics-cdi/blob/master/impl/src/main/java/io/astefanutti/metrics/cdi/DefaultLiteral.java > to name a few. > It would be nice to provide these within the CDI API, e.g: > {code:JAVA} > @Target( { TYPE, METHOD, PARAMETER, FIELD }) > @Retention(RUNTIME) > @Documented > @Qualifier > public @interface Default { > @SuppressWarnings("all") > final class Literal extends AnnotationLiteral implements Default { > private Literal() { > } > } > final Default INSTANCE = new Literal(); > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Feb 12 10:53:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 12 Feb 2016 10:53:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-485) Provide literals for built-in annotations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13162339#comment-13162339 ] Martin Kouba commented on CDI-485: ---------------------------------- A default instance only makes sense for annotations with default values, e.g. for {{@New}} and {{@Typed}}. For {{@Initialized}} it does not make sense. > Provide literals for built-in annotations > ----------------------------------------- > > Key: CDI-485 > URL: https://issues.jboss.org/browse/CDI-485 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Assignee: Martin Kouba > > Annotation literals are often useful and therefore many projects implement them themselves. For example: > https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/literal/DefaultLiteral.java > https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/literal/DefaultLiteral.java > https://github.com/forge/furnace-cdi/blob/master/impl/src/main/java/org/jboss/forge/furnace/container/cdi/util/DefaultLiteral.java > https://github.com/astefanutti/metrics-cdi/blob/master/impl/src/main/java/io/astefanutti/metrics/cdi/DefaultLiteral.java > to name a few. > It would be nice to provide these within the CDI API, e.g: > {code:JAVA} > @Target( { TYPE, METHOD, PARAMETER, FIELD }) > @Retention(RUNTIME) > @Documented > @Qualifier > public @interface Default { > @SuppressWarnings("all") > final class Literal extends AnnotationLiteral implements Default { > private Literal() { > } > } > final Default INSTANCE = new Literal(); > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From pmuir at redhat.com Fri Feb 12 11:12:58 2016 From: pmuir at redhat.com (Pete Muir) Date: Fri, 12 Feb 2016 16:12:58 +0000 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: -1 The problem seems real, but proposed approach doesn't sit right with me. I think it would be better to follow the EJB approach, and add a way to be able to declare a method as "not a business method" (a business method is also a thing in CDI IIRC). For example, e.g. using beans.xml and an annotation. This then allows the spec to consistently treat this public method as not a business method. On 9 February 2016 at 16:36, Antoine Sabot-Durand wrote: > Hi all, > > There have been a lot of discussion around CDI-527 in the last weeks: > https://issues.jboss.org/browse/CDI-527 > > Mark proposed a PR: > https://github.com/cdi-spec/cdi/pull/271 > > But we don't agree on adding this feature to the spec. > This vote is to decide if we should add this feature at the spec level now, > or not. > Should we vote this feature down, that won't mean it will be completely > dropped: it could be implemented as non portable feature in both Spec or > even be included as experimental feature in the spec (in annexes) as > describe in the PR comments > Vote starts now, only vote from EG members are binding (but you can give > your opinion if not part of the EG) and will last 72 hours. > > You vote with the following values: > +1 : I'm favorable for adding this feature in the spec > -1 : I'm against adding this feature in the spec > 0 : I don't care > > Thank you for your attention and your vote. > > Antoine Sabot-Durand > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code > under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other intellectual > property rights inherent in such information. From struberg at yahoo.de Fri Feb 12 11:23:38 2016 From: struberg at yahoo.de (Mark Struberg) Date: Fri, 12 Feb 2016 17:23:38 +0100 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: <67E00C2F-02F6-4950-8EBB-69B521A6F4F2@yahoo.de> Sure, that might probably be a viable way to do it. Oki, here are the two use cases which we need to solve: 1.) @Produces @ApplicationScoped public SomeWeirdThirdPartyClassWithFinalMethods createIt() {return ?}; 2.) @ApplicationSCoped public class MySubclass extends SomeWeirdThirdPartyClassWithFinalMethods {} Any other use case? Can you please elaborate how your idea will look like? Just a few ideas so we can get it running. txs and LieGrue, strub PS: Again: I?m NOT interested to get my approach in. All I?m interested in is a _solution_ for this real world problem. But there was simply no alternative proposed so far? > Am 12.02.2016 um 17:12 schrieb Pete Muir : > > -1 > > The problem seems real, but proposed approach doesn't sit right with > me. I think it would be better to follow the EJB approach, and add a > way to be able to declare a method as "not a business method" (a > business method is also a thing in CDI IIRC). > > For example, e.g. using beans.xml and an annotation. This then allows > the spec to consistently treat this public method as not a business > method. > > On 9 February 2016 at 16:36, Antoine Sabot-Durand > wrote: >> Hi all, >> >> There have been a lot of discussion around CDI-527 in the last weeks: >> https://issues.jboss.org/browse/CDI-527 >> >> Mark proposed a PR: >> https://github.com/cdi-spec/cdi/pull/271 >> >> But we don't agree on adding this feature to the spec. >> This vote is to decide if we should add this feature at the spec level now, >> or not. >> Should we vote this feature down, that won't mean it will be completely >> dropped: it could be implemented as non portable feature in both Spec or >> even be included as experimental feature in the spec (in annexes) as >> describe in the PR comments >> Vote starts now, only vote from EG members are binding (but you can give >> your opinion if not part of the EG) and will last 72 hours. >> >> You vote with the following values: >> +1 : I'm favorable for adding this feature in the spec >> -1 : I'm against adding this feature in the spec >> 0 : I don't care >> >> Thank you for your attention and your vote. >> >> Antoine Sabot-Durand >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code >> under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other intellectual >> property rights inherent in such information. > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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 Feb 12 11:56:42 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Fri, 12 Feb 2016 17:56:42 +0100 Subject: [cdi-dev] adding generic producers to CDI 2.0? Message-ID: Hi guys, could CDI 2 do step forward for generic producers? The need is to produce any type (with a particular qualifier) without the need of an extension: @Produces @MyQualifier Object create(InjectionPoint ip) { ... } This is actually a common pattern (for configuration, or to integrate with 3rd party libs) and today the only hope to do so is to write an extension which is a bit technical and verbose for the result IMO. I guess for compatibility reason we would need to do something like: @Produces @MyQualifier @Generic Object create(InjectionPoint ip) { ... } and say that if there is a unique resolved bean thanks to qualifiers which is annotated @Generic then use this producer. wdyt? Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160212/7758e022/attachment-0001.html From struberg at yahoo.de Fri Feb 12 12:18:44 2016 From: struberg at yahoo.de (Mark Struberg) Date: Fri, 12 Feb 2016 18:18:44 +0100 Subject: [cdi-dev] adding generic producers to CDI 2.0? In-Reply-To: References: Message-ID: I think that would need a multi-pass ?coercion? like it?s done in the jvm. Currently it?s a getBeans(type) (+ resolve). And after that only a single candidate must be left. To support your desired case we would need to do a ?nearest? search means if you have the following producers @Produces List .. @Produces List .. @Produces Object .. @Inject List x; // first producer would be taken @Inject List x; // second producer would be taken @Inject BlaBla x; // third producer would be taken; We?ve discussed similar things back then in CDI-304 I think. Of course that would only work if the producer has a chance to inspect the injection point. Means those producers would need to be @Dependent I guess? Do we go down this route? Or is this an overkill? No idea yet? Might be very powerful but maybe also very fragile? LieGrue, strub > Am 12.02.2016 um 17:56 schrieb Romain Manni-Bucau : > > Hi guys, > > could CDI 2 do step forward for generic producers? > > The need is to produce any type (with a particular qualifier) without the need of an extension: > > @Produces > @MyQualifier > Object create(InjectionPoint ip) { ... } > > This is actually a common pattern (for configuration, or to integrate with 3rd party libs) and today the only hope to do so is to write an extension which is a bit technical and verbose for the result IMO. > > I guess for compatibility reason we would need to do something like: > > @Produces > @MyQualifier > @Generic > Object create(InjectionPoint ip) { ... } > > and say that if there is a unique resolved bean thanks to qualifiers which is annotated @Generic then use this producer. > > wdyt? > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From antoine at sabot-durand.net Fri Feb 12 12:19:14 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 12 Feb 2016 17:19:14 +0000 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: <67E00C2F-02F6-4950-8EBB-69B521A6F4F2@yahoo.de> References: <67E00C2F-02F6-4950-8EBB-69B521A6F4F2@yahoo.de> Message-ID: Hi Guys, Some EG members (like David Blevins) asked to have until the ned of the week-end to vote here. I find interesting to have the more possible input but as the rules were to end the vote tonight, I wanted to be sure that nobody has any objection for closing the vote on sunday 11:59pm CET. Regards, Antoine Le ven. 12 f?vr. 2016 ? 17:23, Mark Struberg a ?crit : > Sure, that might probably be a viable way to do it. > > Oki, here are the two use cases which we need to solve: > > 1.) > @Produces > @ApplicationScoped > public SomeWeirdThirdPartyClassWithFinalMethods createIt() {return ?}; > > 2.) > @ApplicationSCoped > public class MySubclass extends SomeWeirdThirdPartyClassWithFinalMethods {} > > Any other use case? > > Can you please elaborate how your idea will look like? Just a few ideas so > we can get it running. > > txs and LieGrue, > strub > > > PS: Again: I?m NOT interested to get my approach in. All I?m interested in > is a _solution_ for this real world problem. But there was simply no > alternative proposed so far? > > > > > Am 12.02.2016 um 17:12 schrieb Pete Muir : > > > > -1 > > > > The problem seems real, but proposed approach doesn't sit right with > > me. I think it would be better to follow the EJB approach, and add a > > way to be able to declare a method as "not a business method" (a > > business method is also a thing in CDI IIRC). > > > > For example, e.g. using beans.xml and an annotation. This then allows > > the spec to consistently treat this public method as not a business > > method. > > > > On 9 February 2016 at 16:36, Antoine Sabot-Durand > > wrote: > >> Hi all, > >> > >> There have been a lot of discussion around CDI-527 in the last weeks: > >> https://issues.jboss.org/browse/CDI-527 > >> > >> Mark proposed a PR: > >> https://github.com/cdi-spec/cdi/pull/271 > >> > >> But we don't agree on adding this feature to the spec. > >> This vote is to decide if we should add this feature at the spec level > now, > >> or not. > >> Should we vote this feature down, that won't mean it will be completely > >> dropped: it could be implemented as non portable feature in both Spec or > >> even be included as experimental feature in the spec (in annexes) as > >> describe in the PR comments > >> Vote starts now, only vote from EG members are binding (but you can give > >> your opinion if not part of the EG) and will last 72 hours. > >> > >> You vote with the following values: > >> +1 : I'm favorable for adding this feature in the spec > >> -1 : I'm against adding this feature in the spec > >> 0 : I don't care > >> > >> Thank you for your attention and your vote. > >> > >> Antoine Sabot-Durand > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> Note that for all code provided on this list, the provider licenses the > code > >> under the Apache License, Version 2 > >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > >> provided on this list, the provider waives all patent and other > intellectual > >> property rights inherent in such information. > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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/20160212/323a90e2/attachment.html From rmannibucau at gmail.com Fri Feb 12 12:23:27 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Fri, 12 Feb 2016 18:23:27 +0100 Subject: [cdi-dev] adding generic producers to CDI 2.0? In-Reply-To: References: Message-ID: 2016-02-12 18:18 GMT+01:00 Mark Struberg : > I think that would need a multi-pass ?coercion? like it?s done in the jvm. > Nop cause of the constraint I associated to @generic > Currently it?s a getBeans(type) (+ resolve). > And after that only a single candidate must be left. > > To support your desired case we would need to do a ?nearest? search means > if you have the following producers > > @Produces List .. > @Produces List .. > @Produces Object .. > > This would fail at deploy time if they all have @generic, if not then the @Generic producer is just ignored and overriden with the rules with have today if it matches (see @Generic as a fallback if nothing matched but the qualifier). > > @Inject List x; // first producer would be taken > @Inject List x; // second producer would be taken > @Inject BlaBla x; // third producer would be taken; > > We?ve discussed similar things back then in CDI-304 I think. > > Of course that would only work if the producer has a chance to inspect the > injection point. Means those producers would need to be @Dependent I guess? > > Yep > Do we go down this route? Or is this an overkill? No idea yet? Might be > very powerful but maybe also very fragile? > > LieGrue, > strub > > > > Am 12.02.2016 um 17:56 schrieb Romain Manni-Bucau >: > > > > Hi guys, > > > > could CDI 2 do step forward for generic producers? > > > > The need is to produce any type (with a particular qualifier) without > the need of an extension: > > > > @Produces > > @MyQualifier > > Object create(InjectionPoint ip) { ... } > > > > This is actually a common pattern (for configuration, or to integrate > with 3rd party libs) and today the only hope to do so is to write an > extension which is a bit technical and verbose for the result IMO. > > > > I guess for compatibility reason we would need to do something like: > > > > @Produces > > @MyQualifier > > @Generic > > Object create(InjectionPoint ip) { ... } > > > > and say that if there is a unique resolved bean thanks to qualifiers > which is annotated @Generic then use this producer. > > > > wdyt? > > > > Romain Manni-Bucau > > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160212/866863c7/attachment.html From struberg at yahoo.de Fri Feb 12 12:42:51 2016 From: struberg at yahoo.de (Mark Struberg) Date: Fri, 12 Feb 2016 18:42:51 +0100 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: References: <67E00C2F-02F6-4950-8EBB-69B521A6F4F2@yahoo.de> Message-ID: Sure, let?s extend the period but also please let?s actively evalutate all viable alternatives. The more options we have the better the solution will potentially be. Thinking about the BusinessMethod proposal a bit: .) it is surely better in the sense that it does not go down the rabbit hole of implementation details with the JVM .) it might be more complex to configure. At the end you inverses the allowProxying configuration from an ?exclude class?? to an ?include business methods?, right? Might be a bit much to configure. But let?s first check how that might look like for the users. LieGrue, strub > Am 12.02.2016 um 18:19 schrieb Antoine Sabot-Durand : > > Hi Guys, > > Some EG members (like David Blevins) asked to have until the ned of the week-end to vote here. > I find interesting to have the more possible input but as the rules were to end the vote tonight, I wanted to be sure that nobody has any objection for closing the vote on sunday 11:59pm CET. > > Regards, > > Antoine > > Le ven. 12 f?vr. 2016 ? 17:23, Mark Struberg a ?crit : > Sure, that might probably be a viable way to do it. > > Oki, here are the two use cases which we need to solve: > > 1.) > @Produces > @ApplicationScoped > public SomeWeirdThirdPartyClassWithFinalMethods createIt() {return ?}; > > 2.) > @ApplicationSCoped > public class MySubclass extends SomeWeirdThirdPartyClassWithFinalMethods {} > > Any other use case? > > Can you please elaborate how your idea will look like? Just a few ideas so we can get it running. > > txs and LieGrue, > strub > > > PS: Again: I?m NOT interested to get my approach in. All I?m interested in is a _solution_ for this real world problem. But there was simply no alternative proposed so far? > > > > > Am 12.02.2016 um 17:12 schrieb Pete Muir : > > > > -1 > > > > The problem seems real, but proposed approach doesn't sit right with > > me. I think it would be better to follow the EJB approach, and add a > > way to be able to declare a method as "not a business method" (a > > business method is also a thing in CDI IIRC). > > > > For example, e.g. using beans.xml and an annotation. This then allows > > the spec to consistently treat this public method as not a business > > method. > > > > On 9 February 2016 at 16:36, Antoine Sabot-Durand > > wrote: > >> Hi all, > >> > >> There have been a lot of discussion around CDI-527 in the last weeks: > >> https://issues.jboss.org/browse/CDI-527 > >> > >> Mark proposed a PR: > >> https://github.com/cdi-spec/cdi/pull/271 > >> > >> But we don't agree on adding this feature to the spec. > >> This vote is to decide if we should add this feature at the spec level now, > >> or not. > >> Should we vote this feature down, that won't mean it will be completely > >> dropped: it could be implemented as non portable feature in both Spec or > >> even be included as experimental feature in the spec (in annexes) as > >> describe in the PR comments > >> Vote starts now, only vote from EG members are binding (but you can give > >> your opinion if not part of the EG) and will last 72 hours. > >> > >> You vote with the following values: > >> +1 : I'm favorable for adding this feature in the spec > >> -1 : I'm against adding this feature in the spec > >> 0 : I don't care > >> > >> Thank you for your attention and your vote. > >> > >> Antoine Sabot-Durand > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> Note that for all code provided on this list, the provider licenses the code > >> under the Apache License, Version 2 > >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > >> provided on this list, the provider waives all patent and other intellectual > >> property rights inherent in such information. > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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 Fri Feb 12 22:22:06 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: 13 Feb 2016 03:22:06 +0000 Subject: [cdi-dev] Cancelled: CDI weekly meeting Message-ID: <201602130322.u1D3M6j9019404@lists01.dmz-a.mwc.hst.phx2.redhat.com> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160213/f8cc8149/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 6562 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20160213/f8cc8149/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 6562 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20160213/f8cc8149/attachment-0001.bin From fbenoit at codenvy.com Sat Feb 13 04:36:46 2016 From: fbenoit at codenvy.com (Florent Benoit) Date: Sat, 13 Feb 2016 10:36:46 +0100 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: +1 : I'm favorable for adding this feature in the spec On Tue, Feb 9, 2016 at 5:36 PM, Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi all, > > There have been a lot of discussion around CDI-527 in the last weeks: > https://issues.jboss.org/browse/CDI-527 > > Mark proposed a PR: > https://github.com/cdi-spec/cdi/pull/271 > > But we don't agree on adding this feature to the spec. > This vote is to decide if we should add this feature at the spec level > now, or not. > Should we vote this feature down, that won't mean it will be completely > dropped: it could be implemented as non portable feature in both Spec or > even be included as experimental feature in the spec (in annexes) as > describe in the PR comments > Vote starts now, only vote from EG members are binding (but you can give > your opinion if not part of the EG) and will last 72 hours. > > You vote with the following values: > +1 : I'm favorable for adding this feature in the spec > -1 : I'm against adding this feature in the spec > 0 : I don't care > > Thank you for your attention and your vote. > > Antoine Sabot-Durand > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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/20160213/a437a240/attachment-0001.html From fbenoit at codenvy.com Fri Feb 12 09:38:55 2016 From: fbenoit at codenvy.com (Florent Benoit) Date: Fri, 12 Feb 2016 15:38:55 +0100 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods Message-ID: +1 : I'm favorable for adding this feature in the spec On Tue, Feb 9, 2016 at 5:36 PM, Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi all, > > There have been a lot of discussion around CDI-527 in the last weeks: > https://issues.jboss.org/browse/CDI-527 > > Mark proposed a PR: > https://github.com/cdi-spec/cdi/pull/271 > > But we don't agree on adding this feature to the spec. > This vote is to decide if we should add this feature at the spec level > now, or not. > Should we vote this feature down, that won't mean it will be completely > dropped: it could be implemented as non portable feature in both Spec or > even be included as experimental feature in the spec (in annexes) as > describe in the PR comments > Vote starts now, only vote from EG members are binding (but you can give > your opinion if not part of the EG) and will last 72 hours. > > You vote with the following values: > +1 : I'm favorable for adding this feature in the spec > -1 : I'm against adding this feature in the spec > 0 : I don't care > > Thank you for your attention and your vote. > > Antoine Sabot-Durand > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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/20160212/f17cc72c/attachment.html From david.blevins at gmail.com Sat Feb 13 16:21:45 2016 From: david.blevins at gmail.com (David Blevins) Date: Sat, 13 Feb 2016 13:21:45 -0800 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: References: <67E00C2F-02F6-4950-8EBB-69B521A6F4F2@yahoo.de> Message-ID: <87214B11-E9F4-4A52-83E1-39756243DDC3@gmail.com> Read what I could get my hands on. Unfortunately the JIRA itself has 36 comments which won?t load/expand in Safari or Chrome. But I think I get the summary. High level, I agree with both Mark and Martin. - Agree with Mark: Where I see this feature being important is in our EJB/CDI alignment efforts. This appears to be the rare case where the CDI spec is more strict than the EJB spec and a speed bump in someone?s efforts to port an EJB application to CDI. For that reason, this to me upgrades from nice-to-have to we-must-find-a-way. - Agree with Martin: I also strongly dislike the use of beans.xml in any fashion and system properties even more. Aside from being cumbersome for users, I?m particularly against setting a trend of using system properties to bail us out of hard API design issues. This concern trumps the above and I would -1 this vote as-is. That said, I?m not sure if this approach is workable in any way, but here goes: We keep the default rule of beans with final methods being unproxyable unless explicit action in code is taken and the class is: - explicitly produced via @Produces - added explicitly via an extension Effectively the BeanManager would continue to ignore beans with final methods as proxyable in a classpath scan, but the application could ?go back? and explicitly put them into the BeanManager as proxyable. Thoughts? Big holes in there? -David > On Feb 12, 2016, at 9:19 AM, Antoine Sabot-Durand wrote: > > Hi Guys, > > Some EG members (like David Blevins) asked to have until the ned of the week-end to vote here. > I find interesting to have the more possible input but as the rules were to end the vote tonight, I wanted to be sure that nobody has any objection for closing the vote on sunday 11:59pm CET. > > Regards, > > Antoine > > Le ven. 12 f?vr. 2016 ? 17:23, Mark Struberg > a ?crit : > Sure, that might probably be a viable way to do it. > > Oki, here are the two use cases which we need to solve: > > 1.) > @Produces > @ApplicationScoped > public SomeWeirdThirdPartyClassWithFinalMethods createIt() {return ?}; > > 2.) > @ApplicationSCoped > public class MySubclass extends SomeWeirdThirdPartyClassWithFinalMethods {} > > Any other use case? > > Can you please elaborate how your idea will look like? Just a few ideas so we can get it running. > > txs and LieGrue, > strub > > > PS: Again: I?m NOT interested to get my approach in. All I?m interested in is a _solution_ for this real world problem. But there was simply no alternative proposed so far? > > > > > Am 12.02.2016 um 17:12 schrieb Pete Muir >: > > > > -1 > > > > The problem seems real, but proposed approach doesn't sit right with > > me. I think it would be better to follow the EJB approach, and add a > > way to be able to declare a method as "not a business method" (a > > business method is also a thing in CDI IIRC). > > > > For example, e.g. using beans.xml and an annotation. This then allows > > the spec to consistently treat this public method as not a business > > method. > > > > On 9 February 2016 at 16:36, Antoine Sabot-Durand > > > wrote: > >> Hi all, > >> > >> There have been a lot of discussion around CDI-527 in the last weeks: > >> https://issues.jboss.org/browse/CDI-527 > >> > >> Mark proposed a PR: > >> https://github.com/cdi-spec/cdi/pull/271 > >> > >> But we don't agree on adding this feature to the spec. > >> This vote is to decide if we should add this feature at the spec level now, > >> or not. > >> Should we vote this feature down, that won't mean it will be completely > >> dropped: it could be implemented as non portable feature in both Spec or > >> even be included as experimental feature in the spec (in annexes) as > >> describe in the PR comments > >> Vote starts now, only vote from EG members are binding (but you can give > >> your opinion if not part of the EG) and will last 72 hours. > >> > >> You vote with the following values: > >> +1 : I'm favorable for adding this feature in the spec > >> -1 : I'm against adding this feature in the spec > >> 0 : I don't care > >> > >> Thank you for your attention and your vote. > >> > >> Antoine Sabot-Durand > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> Note that for all code provided on this list, the provider licenses the code > >> under the Apache License, Version 2 > >> (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas > >> provided on this list, the provider waives all patent and other intellectual > >> property rights inherent in such information. > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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/20160213/b8061822/attachment.html From john.d.ament at gmail.com Sat Feb 13 17:24:32 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Sat, 13 Feb 2016 22:24:32 +0000 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: <87214B11-E9F4-4A52-83E1-39756243DDC3@gmail.com> References: <67E00C2F-02F6-4950-8EBB-69B521A6F4F2@yahoo.de> <87214B11-E9F4-4A52-83E1-39756243DDC3@gmail.com> Message-ID: Some comments in line. On Sat, Feb 13, 2016 at 4:22 PM David Blevins wrote: > Read what I could get my hands on. Unfortunately the JIRA itself has 36 > comments which won?t load/expand in Safari or Chrome. But I think I get > the summary. > Sounds like a not too responsive UI. I wonder if Atlassian has a test for 36 comments. XD > > High level, I agree with both Mark and Martin. > > - Agree with Mark: Where I see this feature being important is in our > EJB/CDI alignment efforts. This appears to be the rare case where the CDI > spec is more strict than the EJB spec and a speed bump in someone?s efforts > to port an EJB application to CDI. For that reason, this to me upgrades > from nice-to-have to we-must-find-a-way. > Yep, and in thinking about past jobs have run into the issue. People don't read every line of a spec, and don't always understand why something stopped working. > > - Agree with Martin: I also strongly dislike the use of beans.xml in any > fashion and system properties even more. Aside from being cumbersome for > users, I?m particularly against setting a trend of using system properties > to bail us out of hard API design issues. This concern trumps the above > and I would -1 this vote as-is. > > That said, I?m not sure if this approach is workable in any way, but here > goes: > > We keep the default rule of beans with final methods being unproxyable > unless explicit action in code is taken and the class is: > > - explicitly produced via @Produces > - added explicitly via an extension > I don't see a reason that the bean manager needs to ignore classes with final methods. More-so, I don't see the strategy as being comprehensible to the typical developer that they need a producer. Sure, for 3PL's you're probably already creating a producer. For cases where I just made my class with a final method, I shouldn't be penalized. Less boilerplate, that's one of the goals right? If so, I don't see why we can't just deal with a final method in a proxy - don't extend it. The gotcha that I still see is around interceptor bindings. They need to be explicitly disallowed on final methods, and big ole warning put in when you have interceptors on classes with final methods. > > Effectively the BeanManager would continue to ignore beans with final > methods as proxyable in a classpath scan, but the application could ?go > back? and explicitly put them into the BeanManager as proxyable. > > > Thoughts? Big holes in there? > > > -David > > > On Feb 12, 2016, at 9:19 AM, Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > > Hi Guys, > > Some EG members (like David Blevins) asked to have until the ned of the > week-end to vote here. > I find interesting to have the more possible input but as the rules were > to end the vote tonight, I wanted to be sure that nobody has any objection > for closing the vote on sunday 11:59pm CET. > > Regards, > > Antoine > > Le ven. 12 f?vr. 2016 ? 17:23, Mark Struberg a ?crit : > >> Sure, that might probably be a viable way to do it. >> >> Oki, here are the two use cases which we need to solve: >> >> 1.) >> @Produces >> @ApplicationScoped >> public SomeWeirdThirdPartyClassWithFinalMethods createIt() {return ?}; >> >> 2.) >> @ApplicationSCoped >> public class MySubclass extends SomeWeirdThirdPartyClassWithFinalMethods >> {} >> >> Any other use case? >> >> Can you please elaborate how your idea will look like? Just a few ideas >> so we can get it running. >> >> txs and LieGrue, >> strub >> >> >> PS: Again: I?m NOT interested to get my approach in. All I?m interested >> in is a _solution_ for this real world problem. But there was simply no >> alternative proposed so far? >> >> >> >> > Am 12.02.2016 um 17:12 schrieb Pete Muir : >> > >> > -1 >> > >> > The problem seems real, but proposed approach doesn't sit right with >> > me. I think it would be better to follow the EJB approach, and add a >> > way to be able to declare a method as "not a business method" (a >> > business method is also a thing in CDI IIRC). >> > >> > For example, e.g. using beans.xml and an annotation. This then allows >> > the spec to consistently treat this public method as not a business >> > method. >> > >> > On 9 February 2016 at 16:36, Antoine Sabot-Durand >> > wrote: >> >> Hi all, >> >> >> >> There have been a lot of discussion around CDI-527 in the last weeks: >> >> https://issues.jboss.org/browse/CDI-527 >> >> >> >> Mark proposed a PR: >> >> https://github.com/cdi-spec/cdi/pull/271 >> >> >> >> But we don't agree on adding this feature to the spec. >> >> This vote is to decide if we should add this feature at the spec level >> now, >> >> or not. >> >> Should we vote this feature down, that won't mean it will be completely >> >> dropped: it could be implemented as non portable feature in both Spec >> or >> >> even be included as experimental feature in the spec (in annexes) as >> >> describe in the PR comments >> >> Vote starts now, only vote from EG members are binding (but you can >> give >> >> your opinion if not part of the EG) and will last 72 hours. >> >> >> >> You vote with the following values: >> >> +1 : I'm favorable for adding this feature in the spec >> >> -1 : I'm against adding this feature in the spec >> >> 0 : I don't care >> >> >> >> Thank you for your attention and your vote. >> >> >> >> Antoine Sabot-Durand >> >> >> >> _______________________________________________ >> >> cdi-dev mailing list >> >> cdi-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> >> >> Note that for all code provided on this list, the provider licenses >> the code >> >> under the Apache License, Version 2 >> >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> >> provided on this list, the provider waives all patent and other >> intellectual >> >> property rights inherent in such information. >> > _______________________________________________ >> > cdi-dev mailing list >> > cdi-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/cdi-dev >> > >> > Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> >> _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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/20160213/4867871a/attachment-0001.html From rmannibucau at gmail.com Sat Feb 13 17:30:42 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sat, 13 Feb 2016 23:30:42 +0100 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: References: <67E00C2F-02F6-4950-8EBB-69B521A6F4F2@yahoo.de> <87214B11-E9F4-4A52-83E1-39756243DDC3@gmail.com> Message-ID: You can also extend 3rd party classes - no producer but same constraint - so needs to be global - ie not limited to producers - or doesnt help. Le 13 f?vr. 2016 23:25, "John D. Ament" a ?crit : > Some comments in line. > > On Sat, Feb 13, 2016 at 4:22 PM David Blevins > wrote: > >> Read what I could get my hands on. Unfortunately the JIRA itself has 36 >> comments which won?t load/expand in Safari or Chrome. But I think I get >> the summary. >> > > Sounds like a not too responsive UI. I wonder if Atlassian has a test for > 36 comments. XD > > >> >> High level, I agree with both Mark and Martin. >> >> - Agree with Mark: Where I see this feature being important is in our >> EJB/CDI alignment efforts. This appears to be the rare case where the CDI >> spec is more strict than the EJB spec and a speed bump in someone?s efforts >> to port an EJB application to CDI. For that reason, this to me upgrades >> from nice-to-have to we-must-find-a-way. >> > > Yep, and in thinking about past jobs have run into the issue. People > don't read every line of a spec, and don't always understand why something > stopped working. > > >> >> - Agree with Martin: I also strongly dislike the use of beans.xml in any >> fashion and system properties even more. Aside from being cumbersome for >> users, I?m particularly against setting a trend of using system properties >> to bail us out of hard API design issues. This concern trumps the above >> and I would -1 this vote as-is. >> > >> That said, I?m not sure if this approach is workable in any way, but here >> goes: >> >> We keep the default rule of beans with final methods being unproxyable >> unless explicit action in code is taken and the class is: >> >> - explicitly produced via @Produces >> - added explicitly via an extension >> > > I don't see a reason that the bean manager needs to ignore classes with > final methods. More-so, I don't see the strategy as being comprehensible > to the typical developer that they need a producer. Sure, for 3PL's you're > probably already creating a producer. For cases where I just made my class > with a final method, I shouldn't be penalized. > > Less boilerplate, that's one of the goals right? If so, I don't see why > we can't just deal with a final method in a proxy - don't extend it. > > The gotcha that I still see is around interceptor bindings. They need to > be explicitly disallowed on final methods, and big ole warning put in when > you have interceptors on classes with final methods. > > >> >> Effectively the BeanManager would continue to ignore beans with final >> methods as proxyable in a classpath scan, but the application could ?go >> back? and explicitly put them into the BeanManager as proxyable. >> >> >> Thoughts? Big holes in there? >> > >> >> -David >> >> >> On Feb 12, 2016, at 9:19 AM, Antoine Sabot-Durand < >> antoine at sabot-durand.net> wrote: >> >> Hi Guys, >> >> Some EG members (like David Blevins) asked to have until the ned of the >> week-end to vote here. >> I find interesting to have the more possible input but as the rules were >> to end the vote tonight, I wanted to be sure that nobody has any objection >> for closing the vote on sunday 11:59pm CET. >> >> Regards, >> >> Antoine >> >> Le ven. 12 f?vr. 2016 ? 17:23, Mark Struberg a >> ?crit : >> >>> Sure, that might probably be a viable way to do it. >>> >>> Oki, here are the two use cases which we need to solve: >>> >>> 1.) >>> @Produces >>> @ApplicationScoped >>> public SomeWeirdThirdPartyClassWithFinalMethods createIt() {return ?}; >>> >>> 2.) >>> @ApplicationSCoped >>> public class MySubclass extends SomeWeirdThirdPartyClassWithFinalMethods >>> {} >>> >>> Any other use case? >>> >>> Can you please elaborate how your idea will look like? Just a few ideas >>> so we can get it running. >>> >>> txs and LieGrue, >>> strub >>> >>> >>> PS: Again: I?m NOT interested to get my approach in. All I?m interested >>> in is a _solution_ for this real world problem. But there was simply no >>> alternative proposed so far? >>> >>> >>> >>> > Am 12.02.2016 um 17:12 schrieb Pete Muir : >>> > >>> > -1 >>> > >>> > The problem seems real, but proposed approach doesn't sit right with >>> > me. I think it would be better to follow the EJB approach, and add a >>> > way to be able to declare a method as "not a business method" (a >>> > business method is also a thing in CDI IIRC). >>> > >>> > For example, e.g. using beans.xml and an annotation. This then allows >>> > the spec to consistently treat this public method as not a business >>> > method. >>> > >>> > On 9 February 2016 at 16:36, Antoine Sabot-Durand >>> > wrote: >>> >> Hi all, >>> >> >>> >> There have been a lot of discussion around CDI-527 in the last weeks: >>> >> https://issues.jboss.org/browse/CDI-527 >>> >> >>> >> Mark proposed a PR: >>> >> https://github.com/cdi-spec/cdi/pull/271 >>> >> >>> >> But we don't agree on adding this feature to the spec. >>> >> This vote is to decide if we should add this feature at the spec >>> level now, >>> >> or not. >>> >> Should we vote this feature down, that won't mean it will be >>> completely >>> >> dropped: it could be implemented as non portable feature in both Spec >>> or >>> >> even be included as experimental feature in the spec (in annexes) as >>> >> describe in the PR comments >>> >> Vote starts now, only vote from EG members are binding (but you can >>> give >>> >> your opinion if not part of the EG) and will last 72 hours. >>> >> >>> >> You vote with the following values: >>> >> +1 : I'm favorable for adding this feature in the spec >>> >> -1 : I'm against adding this feature in the spec >>> >> 0 : I don't care >>> >> >>> >> Thank you for your attention and your vote. >>> >> >>> >> Antoine Sabot-Durand >>> >> >>> >> _______________________________________________ >>> >> cdi-dev mailing list >>> >> cdi-dev at lists.jboss.org >>> >> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >> >>> >> Note that for all code provided on this list, the provider licenses >>> the code >>> >> under the Apache License, Version 2 >>> >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>> ideas >>> >> provided on this list, the provider waives all patent and other >>> intellectual >>> >> property rights inherent in such information. >>> > _______________________________________________ >>> > cdi-dev mailing list >>> > cdi-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/cdi-dev >>> > >>> > Note that for all code provided on this list, the provider licenses >>> the code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>> provided on this list, the provider waives all patent and other >>> intellectual property rights inherent in such information. >>> >>> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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/20160213/9cacf590/attachment.html From struberg at yahoo.de Sat Feb 13 18:04:36 2016 From: struberg at yahoo.de (Mark Struberg) Date: Sun, 14 Feb 2016 00:04:36 +0100 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: References: <67E00C2F-02F6-4950-8EBB-69B521A6F4F2@yahoo.de> <87214B11-E9F4-4A52-83E1-39756243DDC3@gmail.com> Message-ID: <13F7E41A-06D0-4247-A37B-286FE3C2F8F2@yahoo.de> > Am 13.02.2016 um 23:30 schrieb Romain Manni-Bucau : > > You can also extend 3rd party classes - no producer but same constraint - so needs to be global - ie not limited to producers - or doesnt help. I also think it should be an option which is not only required for producer methods but more generic. Also extending a 3rd party class in a bean archive creates this restriction. @David: that comes pretty close to my original proposal to have a @AllowProxying anntation on the producer field/method or managed bean. I like Pete?s last comment and we of course could also simply rename this to @ContainsNonBusinessMethods or something similar. It would avoid the term ?proxy? which some people seem to think is too low level. But I thin that not many user would grasp what that does in the end. It?s not as self-explaining as @AllowProxying imo. We probably would also need to extend the SPI in that case to allow Extensions to have full control. One more thing: This also hits already existing apps which move from Java6 to 7/8. I?m fine with supporting those on a non-portable basis. @John > The gotcha that I still see is around interceptor bindings. They need to be explicitly disallowed on final methods, and big ole warning put in when you have interceptors on classes with final methods. That could be a good thing to do. Of course it only is possible if the interceptor is applied on a method and not on the whole class. In the later case the final methods would simply not work on the proxy. LieGrue, strub > Am 13.02.2016 um 23:30 schrieb Romain Manni-Bucau : > > You can also extend 3rd party classes - no producer but same constraint - so needs to be global - ie not limited to producers - or doesnt help. > > Le 13 f?vr. 2016 23:25, "John D. Ament" a ?crit : > Some comments in line. > > On Sat, Feb 13, 2016 at 4:22 PM David Blevins wrote: > Read what I could get my hands on. Unfortunately the JIRA itself has 36 comments which won?t load/expand in Safari or Chrome. But I think I get the summary. > > Sounds like a not too responsive UI. I wonder if Atlassian has a test for 36 comments. XD > > > High level, I agree with both Mark and Martin. > > - Agree with Mark: Where I see this feature being important is in our EJB/CDI alignment efforts. This appears to be the rare case where the CDI spec is more strict than the EJB spec and a speed bump in someone?s efforts to port an EJB application to CDI. For that reason, this to me upgrades from nice-to-have to we-must-find-a-way. > > Yep, and in thinking about past jobs have run into the issue. People don't read every line of a spec, and don't always understand why something stopped working. > > > - Agree with Martin: I also strongly dislike the use of beans.xml in any fashion and system properties even more. Aside from being cumbersome for users, I?m particularly against setting a trend of using system properties to bail us out of hard API design issues. This concern trumps the above and I would -1 this vote as-is. > > That said, I?m not sure if this approach is workable in any way, but here goes: > > We keep the default rule of beans with final methods being unproxyable unless explicit action in code is taken and the class is: > > - explicitly produced via @Produces > - added explicitly via an extension > > I don't see a reason that the bean manager needs to ignore classes with final methods. More-so, I don't see the strategy as being comprehensible to the typical developer that they need a producer. Sure, for 3PL's you're probably already creating a producer. For cases where I just made my class with a final method, I shouldn't be penalized. > > Less boilerplate, that's one of the goals right? If so, I don't see why we can't just deal with a final method in a proxy - don't extend it. > > The gotcha that I still see is around interceptor bindings. They need to be explicitly disallowed on final methods, and big ole warning put in when you have interceptors on classes with final methods. > > > Effectively the BeanManager would continue to ignore beans with final methods as proxyable in a classpath scan, but the application could ?go back? and explicitly put them into the BeanManager as proxyable. > > > Thoughts? Big holes in there? > > > -David > > >> On Feb 12, 2016, at 9:19 AM, Antoine Sabot-Durand wrote: >> >> Hi Guys, >> >> Some EG members (like David Blevins) asked to have until the ned of the week-end to vote here. >> I find interesting to have the more possible input but as the rules were to end the vote tonight, I wanted to be sure that nobody has any objection for closing the vote on sunday 11:59pm CET. >> >> Regards, >> >> Antoine >> >> Le ven. 12 f?vr. 2016 ? 17:23, Mark Struberg a ?crit : >> Sure, that might probably be a viable way to do it. >> >> Oki, here are the two use cases which we need to solve: >> >> 1.) >> @Produces >> @ApplicationScoped >> public SomeWeirdThirdPartyClassWithFinalMethods createIt() {return ?}; >> >> 2.) >> @ApplicationSCoped >> public class MySubclass extends SomeWeirdThirdPartyClassWithFinalMethods {} >> >> Any other use case? >> >> Can you please elaborate how your idea will look like? Just a few ideas so we can get it running. >> >> txs and LieGrue, >> strub >> >> >> PS: Again: I?m NOT interested to get my approach in. All I?m interested in is a _solution_ for this real world problem. But there was simply no alternative proposed so far? >> >> >> >> > Am 12.02.2016 um 17:12 schrieb Pete Muir : >> > >> > -1 >> > >> > The problem seems real, but proposed approach doesn't sit right with >> > me. I think it would be better to follow the EJB approach, and add a >> > way to be able to declare a method as "not a business method" (a >> > business method is also a thing in CDI IIRC). >> > >> > For example, e.g. using beans.xml and an annotation. This then allows >> > the spec to consistently treat this public method as not a business >> > method. >> > >> > On 9 February 2016 at 16:36, Antoine Sabot-Durand >> > wrote: >> >> Hi all, >> >> >> >> There have been a lot of discussion around CDI-527 in the last weeks: >> >> https://issues.jboss.org/browse/CDI-527 >> >> >> >> Mark proposed a PR: >> >> https://github.com/cdi-spec/cdi/pull/271 >> >> >> >> But we don't agree on adding this feature to the spec. >> >> This vote is to decide if we should add this feature at the spec level now, >> >> or not. >> >> Should we vote this feature down, that won't mean it will be completely >> >> dropped: it could be implemented as non portable feature in both Spec or >> >> even be included as experimental feature in the spec (in annexes) as >> >> describe in the PR comments >> >> Vote starts now, only vote from EG members are binding (but you can give >> >> your opinion if not part of the EG) and will last 72 hours. >> >> >> >> You vote with the following values: >> >> +1 : I'm favorable for adding this feature in the spec >> >> -1 : I'm against adding this feature in the spec >> >> 0 : I don't care >> >> >> >> Thank you for your attention and your vote. >> >> >> >> Antoine Sabot-Durand >> >> >> >> _______________________________________________ >> >> cdi-dev mailing list >> >> cdi-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> >> >> Note that for all code provided on this list, the provider licenses the code >> >> under the Apache License, Version 2 >> >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> >> provided on this list, the provider waives all patent and other intellectual >> >> property rights inherent in such information. >> > _______________________________________________ >> > cdi-dev mailing list >> > cdi-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/cdi-dev >> > >> > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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 Sun Feb 14 02:43:30 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sun, 14 Feb 2016 08:43:30 +0100 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: <13F7E41A-06D0-4247-A37B-286FE3C2F8F2@yahoo.de> References: <67E00C2F-02F6-4950-8EBB-69B521A6F4F2@yahoo.de> <87214B11-E9F4-4A52-83E1-39756243DDC3@gmail.com> <13F7E41A-06D0-4247-A37B-286FE3C2F8F2@yahoo.de> Message-ID: Le 14 f?vr. 2016 00:04, "Mark Struberg" a ?crit : > > > Am 13.02.2016 um 23:30 schrieb Romain Manni-Bucau : > > > > You can also extend 3rd party classes - no producer but same constraint - so needs to be global - ie not limited to producers - or doesnt help. > > I also think it should be an option which is not only required for producer methods but more generic. Also extending a 3rd party class in a bean archive creates this restriction. > > @David: > that comes pretty close to my original proposal to have a @AllowProxying anntation on the producer field/method or managed bean. I like Pete?s last comment and we of course could also simply rename this to @ContainsNonBusinessMethods or something similar. It would avoid the term ?proxy? which some people seem to think is too low level. But I thin that not many user would grasp what that does in the end. It?s not as self-explaining as @AllowProxying imo. > We probably would also need to extend the SPI in that case to allow Extensions to have full control. > > One more thing: > This also hits already existing apps which move from Java6 to 7/8. I?m fine with supporting those on a non-portable basis. > If in a SPI we can probably accept to write a custom "migration" Extension then. Important is to not touch existing codebase. > @John > > The gotcha that I still see is around interceptor bindings. They need to be explicitly disallowed on final methods, and big ole warning put in when you have interceptors on classes with final methods. > That could be a good thing to do. Of course it only is possible if the interceptor is applied on a method and not on the whole class. In the later case the final methods would simply not work on the proxy. > > > LieGrue, > strub > > > > Am 13.02.2016 um 23:30 schrieb Romain Manni-Bucau : > > > > You can also extend 3rd party classes - no producer but same constraint - so needs to be global - ie not limited to producers - or doesnt help. > > > > Le 13 f?vr. 2016 23:25, "John D. Ament" a ?crit : > > Some comments in line. > > > > On Sat, Feb 13, 2016 at 4:22 PM David Blevins wrote: > > Read what I could get my hands on. Unfortunately the JIRA itself has 36 comments which won?t load/expand in Safari or Chrome. But I think I get the summary. > > > > Sounds like a not too responsive UI. I wonder if Atlassian has a test for 36 comments. XD > > > > > > High level, I agree with both Mark and Martin. > > > > - Agree with Mark: Where I see this feature being important is in our EJB/CDI alignment efforts. This appears to be the rare case where the CDI spec is more strict than the EJB spec and a speed bump in someone?s efforts to port an EJB application to CDI. For that reason, this to me upgrades from nice-to-have to we-must-find-a-way. > > > > Yep, and in thinking about past jobs have run into the issue. People don't read every line of a spec, and don't always understand why something stopped working. > > > > > > - Agree with Martin: I also strongly dislike the use of beans.xml in any fashion and system properties even more. Aside from being cumbersome for users, I?m particularly against setting a trend of using system properties to bail us out of hard API design issues. This concern trumps the above and I would -1 this vote as-is. > > > > That said, I?m not sure if this approach is workable in any way, but here goes: > > > > We keep the default rule of beans with final methods being unproxyable unless explicit action in code is taken and the class is: > > > > - explicitly produced via @Produces > > - added explicitly via an extension > > > > I don't see a reason that the bean manager needs to ignore classes with final methods. More-so, I don't see the strategy as being comprehensible to the typical developer that they need a producer. Sure, for 3PL's you're probably already creating a producer. For cases where I just made my class with a final method, I shouldn't be penalized. > > > > Less boilerplate, that's one of the goals right? If so, I don't see why we can't just deal with a final method in a proxy - don't extend it. > > > > The gotcha that I still see is around interceptor bindings. They need to be explicitly disallowed on final methods, and big ole warning put in when you have interceptors on classes with final methods. > > > > > > Effectively the BeanManager would continue to ignore beans with final methods as proxyable in a classpath scan, but the application could ?go back? and explicitly put them into the BeanManager as proxyable. > > > > > > Thoughts? Big holes in there? > > > > > > -David > > > > > >> On Feb 12, 2016, at 9:19 AM, Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > >> > >> Hi Guys, > >> > >> Some EG members (like David Blevins) asked to have until the ned of the week-end to vote here. > >> I find interesting to have the more possible input but as the rules were to end the vote tonight, I wanted to be sure that nobody has any objection for closing the vote on sunday 11:59pm CET. > >> > >> Regards, > >> > >> Antoine > >> > >> Le ven. 12 f?vr. 2016 ? 17:23, Mark Struberg a ?crit : > >> Sure, that might probably be a viable way to do it. > >> > >> Oki, here are the two use cases which we need to solve: > >> > >> 1.) > >> @Produces > >> @ApplicationScoped > >> public SomeWeirdThirdPartyClassWithFinalMethods createIt() {return ?}; > >> > >> 2.) > >> @ApplicationSCoped > >> public class MySubclass extends SomeWeirdThirdPartyClassWithFinalMethods {} > >> > >> Any other use case? > >> > >> Can you please elaborate how your idea will look like? Just a few ideas so we can get it running. > >> > >> txs and LieGrue, > >> strub > >> > >> > >> PS: Again: I?m NOT interested to get my approach in. All I?m interested in is a _solution_ for this real world problem. But there was simply no alternative proposed so far? > >> > >> > >> > >> > Am 12.02.2016 um 17:12 schrieb Pete Muir : > >> > > >> > -1 > >> > > >> > The problem seems real, but proposed approach doesn't sit right with > >> > me. I think it would be better to follow the EJB approach, and add a > >> > way to be able to declare a method as "not a business method" (a > >> > business method is also a thing in CDI IIRC). > >> > > >> > For example, e.g. using beans.xml and an annotation. This then allows > >> > the spec to consistently treat this public method as not a business > >> > method. > >> > > >> > On 9 February 2016 at 16:36, Antoine Sabot-Durand > >> > wrote: > >> >> Hi all, > >> >> > >> >> There have been a lot of discussion around CDI-527 in the last weeks: > >> >> https://issues.jboss.org/browse/CDI-527 > >> >> > >> >> Mark proposed a PR: > >> >> https://github.com/cdi-spec/cdi/pull/271 > >> >> > >> >> But we don't agree on adding this feature to the spec. > >> >> This vote is to decide if we should add this feature at the spec level now, > >> >> or not. > >> >> Should we vote this feature down, that won't mean it will be completely > >> >> dropped: it could be implemented as non portable feature in both Spec or > >> >> even be included as experimental feature in the spec (in annexes) as > >> >> describe in the PR comments > >> >> Vote starts now, only vote from EG members are binding (but you can give > >> >> your opinion if not part of the EG) and will last 72 hours. > >> >> > >> >> You vote with the following values: > >> >> +1 : I'm favorable for adding this feature in the spec > >> >> -1 : I'm against adding this feature in the spec > >> >> 0 : I don't care > >> >> > >> >> Thank you for your attention and your vote. > >> >> > >> >> Antoine Sabot-Durand > >> >> > >> >> _______________________________________________ > >> >> cdi-dev mailing list > >> >> cdi-dev at lists.jboss.org > >> >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> >> > >> >> Note that for all code provided on this list, the provider licenses the code > >> >> under the Apache License, Version 2 > >> >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > >> >> provided on this list, the provider waives all patent and other intellectual > >> >> property rights inherent in such information. > >> > _______________________________________________ > >> > cdi-dev mailing list > >> > cdi-dev at lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > > >> > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.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/20160214/ce07da16/attachment.html From jens.schumann at openknowledge.de Mon Feb 15 03:25:34 2016 From: jens.schumann at openknowledge.de (Jens Schumann) Date: Mon, 15 Feb 2016 08:25:34 +0000 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: References: <67E00C2F-02F6-4950-8EBB-69B521A6F4F2@yahoo.de> <87214B11-E9F4-4A52-83E1-39756243DDC3@gmail.com> Message-ID: Hey Romain, Von: > on behalf of Romain Manni-Bucau > Datum: Saturday 13 February 2016 23:30 An: "John D. Ament" > Cc: CDI-Dev > Betreff: Re: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods The gotcha that I still see is around interceptor bindings. They need to be explicitly disallowed on final methods, and big ole warning put in when you have interceptors on classes with final methods. In my experience legacy (framework) code tends to have protected final methods, so the problems might be less dangerous than they appear first place (regarding interceptors). I would just warn that a non-proxyable class is proxied, and certain problems arise by doing so. You can name the problems, sure. But I think it is ok to say (in bold): Yes, we do what you want. But live with the consequences. Jens -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160215/c73c9712/attachment-0001.html From mkouba at redhat.com Mon Feb 15 03:29:03 2016 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 15 Feb 2016 09:29:03 +0100 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: References: <67E00C2F-02F6-4950-8EBB-69B521A6F4F2@yahoo.de> <87214B11-E9F4-4A52-83E1-39756243DDC3@gmail.com> Message-ID: <56C18C4F.80600@redhat.com> Dne 13.2.2016 v 23:24 John D. Ament napsal(a): > Some comments in line. > > On Sat, Feb 13, 2016 at 4:22 PM David Blevins > wrote: > > Read what I could get my hands on. Unfortunately the JIRA itself > has 36 comments which won?t load/expand in Safari or Chrome. But I > think I get the summary. > > > Sounds like a not too responsive UI. I wonder if Atlassian has a test > for 36 comments. XD > > > High level, I agree with both Mark and Martin. > > - Agree with Mark: Where I see this feature being important is in > our EJB/CDI alignment efforts. This appears to be the rare case > where the CDI spec is more strict than the EJB spec and a speed bump > in someone?s efforts to port an EJB application to CDI. For that > reason, this to me upgrades from nice-to-have to we-must-find-a-way. > > > Yep, and in thinking about past jobs have run into the issue. People > don't read every line of a spec, and don't always understand why > something stopped working. > > > - Agree with Martin: I also strongly dislike the use of beans.xml > in any fashion and system properties even more. Aside from being > cumbersome for users, I?m particularly against setting a trend of > using system properties to bail us out of hard API design issues. > This concern trumps the above and I would -1 this vote as-is. > > > That said, I?m not sure if this approach is workable in any way, but > here goes: > > We keep the default rule of beans with final methods being > unproxyable unless explicit action in code is taken and the class is: > > - explicitly produced via @Produces > - added explicitly via an extension > > > I don't see a reason that the bean manager needs to ignore classes with > final methods. More-so, I don't see the strategy as being > comprehensible to the typical developer that they need a producer. > Sure, for 3PL's you're probably already creating a producer. For cases > where I just made my class with a final method, I shouldn't be penalized. > > Less boilerplate, that's one of the goals right? If so, I don't see why > we can't just deal with a final method in a proxy - don't extend it. Do you mean to simply ignore the method? If we do (the current non-portable solution of OWB and Weld) a user might be suprised why a method invoked on a proxy does not reach the target instance (it will be invoked upon a client proxy instance). Miserable default behavior I believe. And this will happen for a client proxy for non-interface bean types. > > The gotcha that I still see is around interceptor bindings. They need > to be explicitly disallowed on final methods, and big ole warning put in > when you have interceptors on classes with final methods. > > > Effectively the BeanManager would continue to ignore beans with > final methods as proxyable in a classpath scan, but the application > could ?go back? and explicitly put them into the BeanManager as > proxyable. > > > Thoughts? Big holes in there? > > > > -David > > >> On Feb 12, 2016, at 9:19 AM, Antoine Sabot-Durand >> > wrote: >> >> Hi Guys, >> >> Some EG members (like David Blevins) asked to have until the ned >> of the week-end to vote here. >> I find interesting to have the more possible input but as the >> rules were to end the vote tonight, I wanted to be sure that >> nobody has any objection for closing the vote on sunday 11:59pm CET. >> >> Regards, >> >> Antoine >> >> Le ven. 12 f?vr. 2016 ? 17:23, Mark Struberg > > a ?crit : >> >> Sure, that might probably be a viable way to do it. >> >> Oki, here are the two use cases which we need to solve: >> >> 1.) >> @Produces >> @ApplicationScoped >> public SomeWeirdThirdPartyClassWithFinalMethods createIt() >> {return ?}; >> >> 2.) >> @ApplicationSCoped >> public class MySubclass extends >> SomeWeirdThirdPartyClassWithFinalMethods {} >> >> Any other use case? >> >> Can you please elaborate how your idea will look like? Just a >> few ideas so we can get it running. >> >> txs and LieGrue, >> strub >> >> >> PS: Again: I?m NOT interested to get my approach in. All I?m >> interested in is a _solution_ for this real world problem. But >> there was simply no alternative proposed so far? >> >> >> >> > Am 12.02.2016 um 17:12 schrieb Pete Muir > >: >> > >> > -1 >> > >> > The problem seems real, but proposed approach doesn't sit >> right with >> > me. I think it would be better to follow the EJB approach, >> and add a >> > way to be able to declare a method as "not a business method" (a >> > business method is also a thing in CDI IIRC). >> > >> > For example, e.g. using beans.xml and an annotation. This >> then allows >> > the spec to consistently treat this public method as not a >> business >> > method. >> > >> > On 9 February 2016 at 16:36, Antoine Sabot-Durand >> > > >> wrote: >> >> Hi all, >> >> >> >> There have been a lot of discussion around CDI-527 in the >> last weeks: >> >> https://issues.jboss.org/browse/CDI-527 >> >> >> >> Mark proposed a PR: >> >> https://github.com/cdi-spec/cdi/pull/271 >> >> >> >> But we don't agree on adding this feature to the spec. >> >> This vote is to decide if we should add this feature at the >> spec level now, >> >> or not. >> >> Should we vote this feature down, that won't mean it will >> be completely >> >> dropped: it could be implemented as non portable feature in >> both Spec or >> >> even be included as experimental feature in the spec (in >> annexes) as >> >> describe in the PR comments >> >> Vote starts now, only vote from EG members are binding (but >> you can give >> >> your opinion if not part of the EG) and will last 72 hours. >> >> >> >> You vote with the following values: >> >> +1 : I'm favorable for adding this feature in the spec >> >> -1 : I'm against adding this feature in the spec >> >> 0 : I don't care >> >> >> >> Thank you for your attention and your vote. >> >> >> >> Antoine Sabot-Durand >> >> >> >> _______________________________________________ >> >> cdi-dev mailing list >> >> cdi-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> >> >> Note that for all code provided on this list, the provider >> licenses the code >> >> under the Apache License, Version 2 >> >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all >> other ideas >> >> provided on this list, the provider waives all patent and >> other intellectual >> >> property rights inherent in such information. >> > _______________________________________________ >> > cdi-dev mailing list >> > cdi-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/cdi-dev >> > >> > Note that for all code provided on this list, the provider >> licenses the code under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all >> other ideas provided on this list, the provider waives all >> patent and other intellectual property rights inherent in such >> information. >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider >> licenses the code under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >> ideas provided on this list, the provider waives all patent and >> other intellectual property rights inherent in such information. > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > ideas provided on this list, the provider waives all patent and > other intellectual property rights inherent in such information. > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > -- Martin Kouba Software Engineer Red Hat, Czech Republic From antoine at sabot-durand.net Mon Feb 15 04:16:48 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 15 Feb 2016 09:16:48 +0000 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: <56C18C4F.80600@redhat.com> References: <67E00C2F-02F6-4950-8EBB-69B521A6F4F2@yahoo.de> <87214B11-E9F4-4A52-83E1-39756243DDC3@gmail.com> <56C18C4F.80600@redhat.com> Message-ID: Guys, As I said at the beginning, this thread is not about a pros and cons about this feature. Everybody's agree that we should find a solution for this ticket even if some of us (including me) start to find that the ratio value for users on time spend discussed this is becoming very low. It was about adding the PR proposed by Mark in the spec. If I count the binding vote we have the following result -1: 4 +1: 9 So according to the vote I should merge the PR right away. As there were a lot of reserve in +1 vote I ask again to the -1 voters if they agree with the merging of PR 271 which was the initial question. Antoine Le lun. 15 f?vr. 2016 ? 09:29, Martin Kouba a ?crit : > > Dne 13.2.2016 v 23:24 John D. Ament napsal(a): > > Some comments in line. > > > > On Sat, Feb 13, 2016 at 4:22 PM David Blevins > > wrote: > > > > Read what I could get my hands on. Unfortunately the JIRA itself > > has 36 comments which won?t load/expand in Safari or Chrome. But I > > think I get the summary. > > > > > > Sounds like a not too responsive UI. I wonder if Atlassian has a test > > for 36 comments. XD > > > > > > High level, I agree with both Mark and Martin. > > > > - Agree with Mark: Where I see this feature being important is in > > our EJB/CDI alignment efforts. This appears to be the rare case > > where the CDI spec is more strict than the EJB spec and a speed bump > > in someone?s efforts to port an EJB application to CDI. For that > > reason, this to me upgrades from nice-to-have to we-must-find-a-way. > > > > > > Yep, and in thinking about past jobs have run into the issue. People > > don't read every line of a spec, and don't always understand why > > something stopped working. > > > > > > - Agree with Martin: I also strongly dislike the use of beans.xml > > in any fashion and system properties even more. Aside from being > > cumbersome for users, I?m particularly against setting a trend of > > using system properties to bail us out of hard API design issues. > > This concern trumps the above and I would -1 this vote as-is. > > > > > > That said, I?m not sure if this approach is workable in any way, but > > here goes: > > > > We keep the default rule of beans with final methods being > > unproxyable unless explicit action in code is taken and the class is: > > > > - explicitly produced via @Produces > > - added explicitly via an extension > > > > > > I don't see a reason that the bean manager needs to ignore classes with > > final methods. More-so, I don't see the strategy as being > > comprehensible to the typical developer that they need a producer. > > Sure, for 3PL's you're probably already creating a producer. For cases > > where I just made my class with a final method, I shouldn't be penalized. > > > > Less boilerplate, that's one of the goals right? If so, I don't see why > > we can't just deal with a final method in a proxy - don't extend it. > > Do you mean to simply ignore the method? If we do (the current > non-portable solution of OWB and Weld) a user might be suprised why a > method invoked on a proxy does not reach the target instance (it will be > invoked upon a client proxy instance). Miserable default behavior I > believe. And this will happen for a client proxy for non-interface bean > types. > > > > > The gotcha that I still see is around interceptor bindings. They need > > to be explicitly disallowed on final methods, and big ole warning put in > > when you have interceptors on classes with final methods. > > > > > > Effectively the BeanManager would continue to ignore beans with > > final methods as proxyable in a classpath scan, but the application > > could ?go back? and explicitly put them into the BeanManager as > > proxyable. > > > > > > Thoughts? Big holes in there? > > > > > > > > -David > > > > > >> On Feb 12, 2016, at 9:19 AM, Antoine Sabot-Durand > >> > wrote: > >> > >> Hi Guys, > >> > >> Some EG members (like David Blevins) asked to have until the ned > >> of the week-end to vote here. > >> I find interesting to have the more possible input but as the > >> rules were to end the vote tonight, I wanted to be sure that > >> nobody has any objection for closing the vote on sunday 11:59pm CET. > >> > >> Regards, > >> > >> Antoine > >> > >> Le ven. 12 f?vr. 2016 ? 17:23, Mark Struberg >> > a ?crit : > >> > >> Sure, that might probably be a viable way to do it. > >> > >> Oki, here are the two use cases which we need to solve: > >> > >> 1.) > >> @Produces > >> @ApplicationScoped > >> public SomeWeirdThirdPartyClassWithFinalMethods createIt() > >> {return ?}; > >> > >> 2.) > >> @ApplicationSCoped > >> public class MySubclass extends > >> SomeWeirdThirdPartyClassWithFinalMethods {} > >> > >> Any other use case? > >> > >> Can you please elaborate how your idea will look like? Just a > >> few ideas so we can get it running. > >> > >> txs and LieGrue, > >> strub > >> > >> > >> PS: Again: I?m NOT interested to get my approach in. All I?m > >> interested in is a _solution_ for this real world problem. But > >> there was simply no alternative proposed so far? > >> > >> > >> > >> > Am 12.02.2016 um 17:12 schrieb Pete Muir >> >: > >> > > >> > -1 > >> > > >> > The problem seems real, but proposed approach doesn't sit > >> right with > >> > me. I think it would be better to follow the EJB approach, > >> and add a > >> > way to be able to declare a method as "not a business method" > (a > >> > business method is also a thing in CDI IIRC). > >> > > >> > For example, e.g. using beans.xml and an annotation. This > >> then allows > >> > the spec to consistently treat this public method as not a > >> business > >> > method. > >> > > >> > On 9 February 2016 at 16:36, Antoine Sabot-Durand > >> > > > >> wrote: > >> >> Hi all, > >> >> > >> >> There have been a lot of discussion around CDI-527 in the > >> last weeks: > >> >> https://issues.jboss.org/browse/CDI-527 > >> >> > >> >> Mark proposed a PR: > >> >> https://github.com/cdi-spec/cdi/pull/271 > >> >> > >> >> But we don't agree on adding this feature to the spec. > >> >> This vote is to decide if we should add this feature at the > >> spec level now, > >> >> or not. > >> >> Should we vote this feature down, that won't mean it will > >> be completely > >> >> dropped: it could be implemented as non portable feature in > >> both Spec or > >> >> even be included as experimental feature in the spec (in > >> annexes) as > >> >> describe in the PR comments > >> >> Vote starts now, only vote from EG members are binding (but > >> you can give > >> >> your opinion if not part of the EG) and will last 72 hours. > >> >> > >> >> You vote with the following values: > >> >> +1 : I'm favorable for adding this feature in the spec > >> >> -1 : I'm against adding this feature in the spec > >> >> 0 : I don't care > >> >> > >> >> Thank you for your attention and your vote. > >> >> > >> >> Antoine Sabot-Durand > >> >> > >> >> _______________________________________________ > >> >> cdi-dev mailing list > >> >> cdi-dev at lists.jboss.org > >> >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> >> > >> >> Note that for all code provided on this list, the provider > >> licenses the code > >> >> under the Apache License, Version 2 > >> >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all > >> other ideas > >> >> provided on this list, the provider waives all patent and > >> other intellectual > >> >> property rights inherent in such information. > >> > _______________________________________________ > >> > cdi-dev mailing list > >> > cdi-dev at lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > > >> > Note that for all code provided on this list, the provider > >> licenses the code under the Apache License, Version 2 > >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all > >> other ideas provided on this list, the provider waives all > >> patent and other intellectual property rights inherent in such > >> information. > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> Note that for all code provided on this list, the provider > >> licenses the code under the Apache License, Version 2 > >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > >> ideas provided on this list, the provider waives all patent and > >> other intellectual property rights inherent in such information. > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses > > the code under the Apache License, Version 2 > > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > > ideas provided on this list, the provider waives all patent and > > other intellectual property rights inherent in such information. > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160215/1403a52c/attachment-0001.html From rmannibucau at gmail.com Mon Feb 15 04:35:06 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 15 Feb 2016 10:35:06 +0100 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: References: <67E00C2F-02F6-4950-8EBB-69B521A6F4F2@yahoo.de> <87214B11-E9F4-4A52-83E1-39756243DDC3@gmail.com> <56C18C4F.80600@redhat.com> Message-ID: Re-browsing this thread I think several +1 were "we need something and we didn't get anything better yet". The late proposal of a annotation and more important a SPI sounds to me a nice alternative since it allows to make broken code working back without modifying the application code (or even the war itself). Sounds also less hacky than a system property and portable. Would it be possible to evaluate this proposal as a replacement before closing this vote? Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2016-02-15 10:16 GMT+01:00 Antoine Sabot-Durand : > Guys, > > As I said at the beginning, this thread is not about a pros and cons about > this feature. Everybody's agree that we should find a solution for this > ticket even if some of us (including me) start to find that the ratio value > for users on time spend discussed this is becoming very low. > > It was about adding the PR proposed by Mark in the spec. > > If I count the binding vote we have the following result > -1: 4 > +1: 9 > > So according to the vote I should merge the PR right away. As there were a > lot of reserve in +1 vote I ask again to the -1 voters if they agree with > the merging of PR 271 which was the initial question. > > Antoine > Le lun. 15 f?vr. 2016 ? 09:29, Martin Kouba a ?crit : > >> >> Dne 13.2.2016 v 23:24 John D. Ament napsal(a): >> > Some comments in line. >> > >> > On Sat, Feb 13, 2016 at 4:22 PM David Blevins > > > wrote: >> > >> > Read what I could get my hands on. Unfortunately the JIRA itself >> > has 36 comments which won?t load/expand in Safari or Chrome. But I >> > think I get the summary. >> > >> > >> > Sounds like a not too responsive UI. I wonder if Atlassian has a test >> > for 36 comments. XD >> > >> > >> > High level, I agree with both Mark and Martin. >> > >> > - Agree with Mark: Where I see this feature being important is in >> > our EJB/CDI alignment efforts. This appears to be the rare case >> > where the CDI spec is more strict than the EJB spec and a speed bump >> > in someone?s efforts to port an EJB application to CDI. For that >> > reason, this to me upgrades from nice-to-have to we-must-find-a-way. >> > >> > >> > Yep, and in thinking about past jobs have run into the issue. People >> > don't read every line of a spec, and don't always understand why >> > something stopped working. >> > >> > >> > - Agree with Martin: I also strongly dislike the use of beans.xml >> > in any fashion and system properties even more. Aside from being >> > cumbersome for users, I?m particularly against setting a trend of >> > using system properties to bail us out of hard API design issues. >> > This concern trumps the above and I would -1 this vote as-is. >> > >> > >> > That said, I?m not sure if this approach is workable in any way, but >> > here goes: >> > >> > We keep the default rule of beans with final methods being >> > unproxyable unless explicit action in code is taken and the class >> is: >> > >> > - explicitly produced via @Produces >> > - added explicitly via an extension >> > >> > >> > I don't see a reason that the bean manager needs to ignore classes with >> > final methods. More-so, I don't see the strategy as being >> > comprehensible to the typical developer that they need a producer. >> > Sure, for 3PL's you're probably already creating a producer. For cases >> > where I just made my class with a final method, I shouldn't be >> penalized. >> > >> > Less boilerplate, that's one of the goals right? If so, I don't see why >> > we can't just deal with a final method in a proxy - don't extend it. >> >> Do you mean to simply ignore the method? If we do (the current >> non-portable solution of OWB and Weld) a user might be suprised why a >> method invoked on a proxy does not reach the target instance (it will be >> invoked upon a client proxy instance). Miserable default behavior I >> believe. And this will happen for a client proxy for non-interface bean >> types. >> >> > >> > The gotcha that I still see is around interceptor bindings. They need >> > to be explicitly disallowed on final methods, and big ole warning put in >> > when you have interceptors on classes with final methods. >> > >> > >> > Effectively the BeanManager would continue to ignore beans with >> > final methods as proxyable in a classpath scan, but the application >> > could ?go back? and explicitly put them into the BeanManager as >> > proxyable. >> > >> > >> > Thoughts? Big holes in there? >> > >> > >> > >> > -David >> > >> > >> >> On Feb 12, 2016, at 9:19 AM, Antoine Sabot-Durand >> >> > >> wrote: >> >> >> >> Hi Guys, >> >> >> >> Some EG members (like David Blevins) asked to have until the ned >> >> of the week-end to vote here. >> >> I find interesting to have the more possible input but as the >> >> rules were to end the vote tonight, I wanted to be sure that >> >> nobody has any objection for closing the vote on sunday 11:59pm >> CET. >> >> >> >> Regards, >> >> >> >> Antoine >> >> >> >> Le ven. 12 f?vr. 2016 ? 17:23, Mark Struberg > >> > a ?crit : >> >> >> >> Sure, that might probably be a viable way to do it. >> >> >> >> Oki, here are the two use cases which we need to solve: >> >> >> >> 1.) >> >> @Produces >> >> @ApplicationScoped >> >> public SomeWeirdThirdPartyClassWithFinalMethods createIt() >> >> {return ?}; >> >> >> >> 2.) >> >> @ApplicationSCoped >> >> public class MySubclass extends >> >> SomeWeirdThirdPartyClassWithFinalMethods {} >> >> >> >> Any other use case? >> >> >> >> Can you please elaborate how your idea will look like? Just a >> >> few ideas so we can get it running. >> >> >> >> txs and LieGrue, >> >> strub >> >> >> >> >> >> PS: Again: I?m NOT interested to get my approach in. All I?m >> >> interested in is a _solution_ for this real world problem. But >> >> there was simply no alternative proposed so far? >> >> >> >> >> >> >> >> > Am 12.02.2016 um 17:12 schrieb Pete Muir > >> >: >> >> > >> >> > -1 >> >> > >> >> > The problem seems real, but proposed approach doesn't sit >> >> right with >> >> > me. I think it would be better to follow the EJB approach, >> >> and add a >> >> > way to be able to declare a method as "not a business >> method" (a >> >> > business method is also a thing in CDI IIRC). >> >> > >> >> > For example, e.g. using beans.xml and an annotation. This >> >> then allows >> >> > the spec to consistently treat this public method as not a >> >> business >> >> > method. >> >> > >> >> > On 9 February 2016 at 16:36, Antoine Sabot-Durand >> >> > > >> >> wrote: >> >> >> Hi all, >> >> >> >> >> >> There have been a lot of discussion around CDI-527 in the >> >> last weeks: >> >> >> https://issues.jboss.org/browse/CDI-527 >> >> >> >> >> >> Mark proposed a PR: >> >> >> https://github.com/cdi-spec/cdi/pull/271 >> >> >> >> >> >> But we don't agree on adding this feature to the spec. >> >> >> This vote is to decide if we should add this feature at the >> >> spec level now, >> >> >> or not. >> >> >> Should we vote this feature down, that won't mean it will >> >> be completely >> >> >> dropped: it could be implemented as non portable feature in >> >> both Spec or >> >> >> even be included as experimental feature in the spec (in >> >> annexes) as >> >> >> describe in the PR comments >> >> >> Vote starts now, only vote from EG members are binding (but >> >> you can give >> >> >> your opinion if not part of the EG) and will last 72 hours. >> >> >> >> >> >> You vote with the following values: >> >> >> +1 : I'm favorable for adding this feature in the spec >> >> >> -1 : I'm against adding this feature in the spec >> >> >> 0 : I don't care >> >> >> >> >> >> Thank you for your attention and your vote. >> >> >> >> >> >> Antoine Sabot-Durand >> >> >> >> >> >> _______________________________________________ >> >> >> cdi-dev mailing list >> >> >> cdi-dev at lists.jboss.org >> >> >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> >> >> >> >> Note that for all code provided on this list, the provider >> >> licenses the code >> >> >> under the Apache License, Version 2 >> >> >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all >> >> other ideas >> >> >> provided on this list, the provider waives all patent and >> >> other intellectual >> >> >> property rights inherent in such information. >> >> > _______________________________________________ >> >> > cdi-dev mailing list >> >> > cdi-dev at lists.jboss.org >> >> > https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> > >> >> > Note that for all code provided on this list, the provider >> >> licenses the code under the Apache License, Version 2 >> >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all >> >> other ideas provided on this list, the provider waives all >> >> patent and other intellectual property rights inherent in such >> >> information. >> >> >> >> _______________________________________________ >> >> cdi-dev mailing list >> >> cdi-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> >> >> Note that for all code provided on this list, the provider >> >> licenses the code under the Apache License, Version 2 >> >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >> >> ideas provided on this list, the provider waives all patent and >> >> other intellectual property rights inherent in such information. >> > >> > _______________________________________________ >> > cdi-dev mailing list >> > cdi-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/cdi-dev >> > >> > Note that for all code provided on this list, the provider licenses >> > the code under the Apache License, Version 2 >> > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >> > ideas provided on this list, the provider waives all patent and >> > other intellectual property rights inherent in such information. >> > >> > >> > >> > _______________________________________________ >> > cdi-dev mailing list >> > cdi-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/cdi-dev >> > >> > Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> > >> >> -- >> Martin Kouba >> Software Engineer >> Red Hat, Czech Republic >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160215/f0ce06a6/attachment-0001.html From struberg at yahoo.de Mon Feb 15 06:08:49 2016 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 15 Feb 2016 12:08:49 +0100 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: <56C18C4F.80600@redhat.com> References: <67E00C2F-02F6-4950-8EBB-69B521A6F4F2@yahoo.de> <87214B11-E9F4-4A52-83E1-39756243DDC3@gmail.com> <56C18C4F.80600@redhat.com> Message-ID: <99E462FB-1C64-4CA7-9C2B-84A6FC8CC5ED@yahoo.de> > Am 15.02.2016 um 09:29 schrieb Martin Kouba : > > Do you mean to simply ignore the method? If we do (the current > non-portable solution of OWB and Weld) a user might be suprised why a > method invoked on a proxy does not reach the target instance (it will be > invoked upon a client proxy instance). Miserable default behavior I > believe. And this will happen for a client proxy for non-interface bean > types. Technically that is afaik the only possible option we do have as long as we don?t rewrite the bytecode of the _original_ class. And that might be pretty hard to do for classes coming from the JDK for example ;) As Jens perfectly nailed it: a.) The user explicitly declares ?Yes, I know what I do and I?ll live with the consequences? and b.) Those are most times protected or package-default methods. I think this will mostly happen with self-injection. And this will only happen to be a problem for CDI and NIV (as in ?classic? EJBs you only can call ?business methods? even for self injection. And business methods are always only public methods). Of course that is an important use case, which you really need from time to time. But how often does ?Random Jo/anna? programmer use this? In my experience there is a balance of 1:10000 self-injection methods vs general CDI method. It?s mostly used by experts who know what they do. LieGrue, strub From antoine at sabot-durand.net Tue Feb 16 05:18:49 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 16 Feb 2016 10:18:49 +0000 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: <99E462FB-1C64-4CA7-9C2B-84A6FC8CC5ED@yahoo.de> References: <67E00C2F-02F6-4950-8EBB-69B521A6F4F2@yahoo.de> <87214B11-E9F4-4A52-83E1-39756243DDC3@gmail.com> <56C18C4F.80600@redhat.com> <99E462FB-1C64-4CA7-9C2B-84A6FC8CC5ED@yahoo.de> Message-ID: Ok, guy, >From what I understand, the majority think this feature is useful in the spec but would like a better proposal than the PR. Got it. I received a lot of private message following my yesterday mail to express reserve for the proposed PR. So let's continue looking for a better approach and let's continue working on other CDI 2.0 features as well. Antoine Le lun. 15 f?vr. 2016 ? 12:09, Mark Struberg a ?crit : > > > Am 15.02.2016 um 09:29 schrieb Martin Kouba : > > > > Do you mean to simply ignore the method? If we do (the current > > non-portable solution of OWB and Weld) a user might be suprised why a > > method invoked on a proxy does not reach the target instance (it will be > > invoked upon a client proxy instance). Miserable default behavior I > > believe. And this will happen for a client proxy for non-interface bean > > types. > > Technically that is afaik the only possible option we do have as long as > we don?t rewrite the bytecode of the _original_ class. And that might be > pretty hard to do for classes coming from the JDK for example ;) > > > As Jens perfectly nailed it: > a.) The user explicitly declares ?Yes, I know what I do and I?ll live with > the consequences? and > b.) Those are most times protected or package-default methods. > > I think this will mostly happen with self-injection. And this will only > happen to be a problem for CDI and NIV (as in ?classic? EJBs you only can > call ?business methods? even for self injection. And business methods are > always only public methods). > Of course that is an important use case, which you really need from time > to time. But how often does ?Random Jo/anna? programmer use this? In my > experience there is a balance of 1:10000 self-injection methods vs general > CDI method. > It?s mostly used by experts who know what they do. > > LieGrue, > strub > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160216/ea6f51cc/attachment.html From rmannibucau at gmail.com Tue Feb 16 05:25:09 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 16 Feb 2016 11:25:09 +0100 Subject: [cdi-dev] Full rewrite for CDI 558 / PR 270 In-Reply-To: References: Message-ID: Hey guys, thinking more to it here few more remarks/requests: - as an extension writer think having an explicit build is better than an implicit one in particular when you manage several built instances. The fact it is sometimes implicit sometimes explicit has these drawbacks: -- API starts to be huge for a poor gain -- you actually don't know what is done more easily if not inline (which is likely the case for medium/advanced extensions) - why having Builders class with static methods where we could use the bean manager as entry point for them. Would be more natural since the BM already build some instance like AT and easier to find in the IDE and look less magic. -- bonus on this one: would also bind the calls to a CDI context which makes things easier to track and if we speak later of multiple contexts in the same classloader we wouldn't be broken wdyt? Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2016-02-05 16:01 GMT+01:00 Romain Manni-Bucau : > Why not making all Annotated* mutable during boot lifecycle? > > Would allow to get rid of the annotated root in the modification code, for > instance we could convert: > > type.getMethods().stream().filter(m -> > m.isAnnotationPresent(Foo.class)).forEach(m > ->event.setAnnotatedType().addToMethod(m, MyInterceptor.BINDING)); > > to > > type.getMethods().stream().filter(m -> > m.isAnnotationPresent(Foo.class)).forEach(m -> > m.mutate().add(MyInterceptor.BINDING)); > > or if we don't want to add mutate in the existing types we could use > configurator as root for type type and recreate a Configurator graph > matching annotated graph. > > Advatage is first code i a bit awkward in the sense you can call > setAnnotatedType() multiple type (what would happen? only last modification > will be saved? or you have to keep a reference to the configurator once > called which breaks the fluent API provded by streams IMO. > > wdyt? > > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2016-02-05 15:24 GMT+01:00 Antoine Sabot-Durand > : > >> Hi all, >> >> Following discussion during last meeting, I rewrote most of my PR for >> builders. >> >> We now have 2 clean and distinct ways of using them >> >> 1) in DSL style (with a Configurator interface without build() method) >> >> public void processAT(@Observes ProcessAnnotatedType pat) { >> pat.setAnnotatedType().read(pat.getAnnotatedType()).addToType(new >> AnnotationLiteral() {};); >> } >> >> >> 2) In classical reusable builder mode (builders extends configurator and >> only add build() method) >> >> public void processAT(@Observes ProcessAnnotatedType pat) { >> AnnotatedTypeBuilder atb = Builders.annotatedTypeBuilder(); >> atb.read(pat.getAnnotatedType()).addToType(new >> AnnotationLiteral() {};); >> pat.setAnnotatedType(atb.build()); >> } >> >> >> As Configurators don't have build() method there's no risk that users mix >> them with standard builders. >> For clarity sake, builders are no more available in lifecycle event but >> in Builders class for consistency. >> >> I'm quite happy with the result, but I'm sure you'll have comment ;). So >> thanks for your feedback >> >> https://github.com/cdi-spec/cdi/pull/270 >> >> 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/20160216/369d1344/attachment.html From antoine at sabot-durand.net Tue Feb 16 06:14:35 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 16 Feb 2016 11:14:35 +0000 Subject: [cdi-dev] Full rewrite for CDI 558 / PR 270 In-Reply-To: References: Message-ID: Le mar. 16 f?vr. 2016 ? 11:25, Romain Manni-Bucau a ?crit : > Hey guys, > > thinking more to it here few more remarks/requests: > > - as an extension writer think having an explicit build is better than an > implicit one in particular when you manage several built instances. The > fact it is sometimes implicit sometimes explicit has these drawbacks: > -- API starts to be huge for a poor gain > +1 > -- you actually don't know what is done more easily if not inline (which > is likely the case for medium/advanced extensions) > +1, I think we should remove this notion on Configurator I intoduced, the question ius do we keep specific SPI method returning a builder to be build in a DSL way or not > - why having Builders class with static methods where we could use the > bean manager as entry point for them. Would be more natural since the BM > already build some instance like AT and easier to find in the IDE and look > less magic. > -1 BM is already bloated with a zillion of methods and as discussed somewhere else some builders (mainly ATB) could be useful from outside CDI, especially in SE to prepare config before starting the container. > -- bonus on this one: would also bind the calls to a CDI context which > makes things easier to track and if we speak later of multiple contexts in > the same classloader we wouldn't be broken > Remember that built meta-data are mainly used during container bootstrap where context are not active... So I'm not sure to get the interest of this idea. Antoine > > > wdyt? > > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2016-02-05 16:01 GMT+01:00 Romain Manni-Bucau : > >> Why not making all Annotated* mutable during boot lifecycle? >> >> Would allow to get rid of the annotated root in the modification code, >> for instance we could convert: >> >> type.getMethods().stream().filter(m -> >> m.isAnnotationPresent(Foo.class)).forEach(m >> ->event.setAnnotatedType().addToMethod(m, MyInterceptor.BINDING)); >> >> to >> >> type.getMethods().stream().filter(m -> >> m.isAnnotationPresent(Foo.class)).forEach(m -> >> m.mutate().add(MyInterceptor.BINDING)); >> >> or if we don't want to add mutate in the existing types we could use >> configurator as root for type type and recreate a Configurator graph >> matching annotated graph. >> >> Advatage is first code i a bit awkward in the sense you can call >> setAnnotatedType() multiple type (what would happen? only last modification >> will be saved? or you have to keep a reference to the configurator once >> called which breaks the fluent API provded by streams IMO. >> >> wdyt? >> >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> 2016-02-05 15:24 GMT+01:00 Antoine Sabot-Durand > >: >> >>> Hi all, >>> >>> Following discussion during last meeting, I rewrote most of my PR for >>> builders. >>> >>> We now have 2 clean and distinct ways of using them >>> >>> 1) in DSL style (with a Configurator interface without build() method) >>> >>> public void processAT(@Observes ProcessAnnotatedType pat) { >>> pat.setAnnotatedType().read(pat.getAnnotatedType()).addToType(new >>> AnnotationLiteral() {};); >>> } >>> >>> >>> 2) In classical reusable builder mode (builders extends configurator and >>> only add build() method) >>> >>> public void processAT(@Observes ProcessAnnotatedType pat) { >>> AnnotatedTypeBuilder atb = Builders.annotatedTypeBuilder(); >>> atb.read(pat.getAnnotatedType()).addToType(new >>> AnnotationLiteral() {};); >>> pat.setAnnotatedType(atb.build()); >>> } >>> >>> >>> As Configurators don't have build() method there's no risk that users >>> mix them with standard builders. >>> For clarity sake, builders are no more available in lifecycle event but >>> in Builders class for consistency. >>> >>> I'm quite happy with the result, but I'm sure you'll have comment ;). So >>> thanks for your feedback >>> >>> https://github.com/cdi-spec/cdi/pull/270 >>> >>> 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/20160216/c273045a/attachment-0001.html From rmannibucau at gmail.com Tue Feb 16 06:45:59 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 16 Feb 2016 12:45:59 +0100 Subject: [cdi-dev] Full rewrite for CDI 558 / PR 270 In-Reply-To: References: Message-ID: 2016-02-16 12:14 GMT+01:00 Antoine Sabot-Durand : > > > Le mar. 16 f?vr. 2016 ? 11:25, Romain Manni-Bucau > a ?crit : > >> Hey guys, >> >> thinking more to it here few more remarks/requests: >> >> - as an extension writer think having an explicit build is better than an >> implicit one in particular when you manage several built instances. The >> fact it is sometimes implicit sometimes explicit has these drawbacks: >> -- API starts to be huge for a poor gain >> > > +1 > > >> -- you actually don't know what is done more easily if not inline (which >> is likely the case for medium/advanced extensions) >> > > +1, I think we should remove this notion on Configurator I intoduced, the > question ius do we keep specific SPI method returning a builder to be build > in a DSL way or not > > >> - why having Builders class with static methods where we could use the >> bean manager as entry point for them. Would be more natural since the BM >> already build some instance like AT and easier to find in the IDE and look >> less magic. >> > > -1 BM is already bloated with a zillion of methods and as discussed > somewhere else some builders (mainly ATB) could be useful from outside CDI, > especially in SE to prepare config before starting the container. > > Not a fan of BeanManager but it is the single entry point today. That said most of them are for boot work so events are a good alternative to put them. > -- bonus on this one: would also bind the calls to a CDI context which >> makes things easier to track and if we speak later of multiple contexts in >> the same classloader we wouldn't be broken >> > > Remember that built meta-data are mainly used during container bootstrap > where context are not active... So I'm not sure to get the interest of this > idea. > > don't want to use too much space/time on it since it is not yet on our plate but just to answer the idea was: // time execution CdiContainer c1 = .....provider(WeldProvider.class).start(); // c1 lifecycle as expected CdiContainer c2 = .....provider(OpenWeabBeansProvider.class).start(); // extension in c2 using OWB cause events - or BM in my first mail - are OWB ones and not Weld ones There are few builders we can use at runtime to integrate with 3rd party libs - main thing you want is an InjectionTarget - but guess we have most of them already in CDI 1.2 so think the event proposal works and wouldnt constrained too much integrations. > Antoine > > >> >> >> wdyt? >> >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> 2016-02-05 16:01 GMT+01:00 Romain Manni-Bucau : >> >>> Why not making all Annotated* mutable during boot lifecycle? >>> >>> Would allow to get rid of the annotated root in the modification code, >>> for instance we could convert: >>> >>> type.getMethods().stream().filter(m -> >>> m.isAnnotationPresent(Foo.class)).forEach(m >>> ->event.setAnnotatedType().addToMethod(m, MyInterceptor.BINDING)); >>> >>> to >>> >>> type.getMethods().stream().filter(m -> >>> m.isAnnotationPresent(Foo.class)).forEach(m -> >>> m.mutate().add(MyInterceptor.BINDING)); >>> >>> or if we don't want to add mutate in the existing types we could use >>> configurator as root for type type and recreate a Configurator graph >>> matching annotated graph. >>> >>> Advatage is first code i a bit awkward in the sense you can call >>> setAnnotatedType() multiple type (what would happen? only last modification >>> will be saved? or you have to keep a reference to the configurator once >>> called which breaks the fluent API provded by streams IMO. >>> >>> wdyt? >>> >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog >>> | Github >>> | LinkedIn >>> | Tomitriber >>> >>> >>> 2016-02-05 15:24 GMT+01:00 Antoine Sabot-Durand < >>> antoine at sabot-durand.net>: >>> >>>> Hi all, >>>> >>>> Following discussion during last meeting, I rewrote most of my PR for >>>> builders. >>>> >>>> We now have 2 clean and distinct ways of using them >>>> >>>> 1) in DSL style (with a Configurator interface without build() method) >>>> >>>> public void processAT(@Observes ProcessAnnotatedType pat) { >>>> pat.setAnnotatedType().read(pat.getAnnotatedType()).addToType(new >>>> AnnotationLiteral() {};); >>>> } >>>> >>>> >>>> 2) In classical reusable builder mode (builders extends configurator >>>> and only add build() method) >>>> >>>> public void processAT(@Observes ProcessAnnotatedType pat) { >>>> AnnotatedTypeBuilder atb = Builders.annotatedTypeBuilder(); >>>> atb.read(pat.getAnnotatedType()).addToType(new >>>> AnnotationLiteral() {};); >>>> pat.setAnnotatedType(atb.build()); >>>> } >>>> >>>> >>>> As Configurators don't have build() method there's no risk that users >>>> mix them with standard builders. >>>> For clarity sake, builders are no more available in lifecycle event but >>>> in Builders class for consistency. >>>> >>>> I'm quite happy with the result, but I'm sure you'll have comment ;). >>>> So thanks for your feedback >>>> >>>> https://github.com/cdi-spec/cdi/pull/270 >>>> >>>> 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/20160216/f98ec0ff/attachment.html From struberg at yahoo.de Tue Feb 16 10:38:01 2016 From: struberg at yahoo.de (Mark Struberg) Date: Tue, 16 Feb 2016 16:38:01 +0100 Subject: [cdi-dev] preparation for todays meeting Message-ID: <5A9ED9E5-8B14-4955-B270-F8345D6B03F1@yahoo.de> Hi folks! I would love to discuss CDI-420 today. This is open since 2 years now and I?ve shipped a pull request already 2 weeks ago. LieGrue, strub From antoine at sabot-durand.net Tue Feb 16 10:45:53 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 16 Feb 2016 15:45:53 +0000 Subject: [cdi-dev] Thoughts about CDI-527 Message-ID: Hi guys, Re-reading materials and all our discussion on CDI-527, I think there's an option we didn't explore Instead of introducing a new annotation, we could loose rules on proxied bean creation for class having final methods. Today if you declare a class requiring a proxy (because of scope or AOP) you'll get an exception, so nobody declares a bean with such a feature since the app wouldn't deploy. It's the same for producer: you won't declare an @ApplicationScoped producer for a type having final method since your app won't deploy. So in today existing code, final method are in non cdi code or in cdi code that doesn't requires proxy (@Dependent without AOP) If we decide to loose the rules in "3.15 Unproxyable bean types" [1] it won't have impact on existing code (unless I missed something), since you can't have proxied bean with final method without deployment error. It would only allow new proxied bean with final method in it. Change should also be made in "7.2. Container invocations and interception" [2] to explicitly exclude final methods from the list of business method. This change could be seen as not backward compatible, but since current code cannot have proxied bean with final class it doesn't change existing behavior but allow new usage. It also allow code with producer for class of the JDK introducing final in their code to continue working seamlessly in CDI 2.0. Finally that prevent us to introduce specific annotation or configuration looking like a hack. In the past we already introduce behavior changes when we changed the list of bean defining annotation in CDI 1.2 or when we loose usage of certain beanManager method in AfterBeanDiscovery event (I see this proposal very like this last example). Wdyt ? Antoine [1] http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#unproxyable [2] http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#biz_method -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160216/275ea3ae/attachment-0001.html From john.d.ament at gmail.com Tue Feb 16 10:51:11 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Tue, 16 Feb 2016 15:51:11 +0000 Subject: [cdi-dev] Thoughts about CDI-527 In-Reply-To: References: Message-ID: I don't believe that loosening the rules would introduce a backwards compatibility issues. John On Tue, Feb 16, 2016 at 10:46 AM Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi guys, > > Re-reading materials and all our discussion on CDI-527, I think there's an > option we didn't explore > > Instead of introducing a new annotation, we could loose rules on proxied > bean creation for class having final methods. > Today if you declare a class requiring a proxy (because of scope or AOP) > you'll get an exception, so nobody declares a bean with such a feature > since the app wouldn't deploy. > It's the same for producer: you won't declare an @ApplicationScoped > producer for a type having final method since your app won't deploy. > > So in today existing code, final method are in non cdi code or in cdi code > that doesn't requires proxy (@Dependent without AOP) > > If we decide to loose the rules in "3.15 Unproxyable bean types" [1] it > won't have impact on existing code (unless I missed something), since you > can't have proxied bean with final method without deployment error. > It would only allow new proxied bean with final method in it. > > Change should also be made in "7.2. Container invocations and > interception" [2] to explicitly exclude final methods from the list of > business method. > > This change could be seen as not backward compatible, but since current > code cannot have proxied bean with final class it doesn't change existing > behavior but allow new usage. > It also allow code with producer for class of the JDK introducing final in > their code to continue working seamlessly in CDI 2.0. > Finally that prevent us to introduce specific annotation or configuration > looking like a hack. > > In the past we already introduce behavior changes when we changed the list > of bean defining annotation in CDI 1.2 or when we loose usage of certain > beanManager method in AfterBeanDiscovery event (I see this proposal very > like this last example). > > Wdyt ? > > Antoine > > > [1] http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#unproxyable > [2] http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#biz_method > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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/20160216/e79e7d84/attachment.html From issues at jboss.org Tue Feb 16 11:06:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 16 Feb 2016 11:06:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13163727#comment-13163727 ] Antoine Sabot-Durand commented on CDI-420: ------------------------------------------ Could be useful to add this granularity, since we don't configure type discovery but bean discovery. I would prefer {{defined}} (because they have a bean defining annotation) or {{explicit}} for the name of the new bean discovery mode. > add a bean-discovery-mode 'scoped' > ---------------------------------- > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: TBD > Reporter: Mark Struberg > Fix For: 2.0 (discussion) > > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > ? each Java class, interface or enum deployed in an explicit bean archive, and > ? each Java class with a bean defining annotation in an implicit bean archive. > ? each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From struberg at yahoo.de Tue Feb 16 11:55:33 2016 From: struberg at yahoo.de (Mark Struberg) Date: Tue, 16 Feb 2016 17:55:33 +0100 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: <87214B11-E9F4-4A52-83E1-39756243DDC3@gmail.com> References: <67E00C2F-02F6-4950-8EBB-69B521A6F4F2@yahoo.de> <87214B11-E9F4-4A52-83E1-39756243DDC3@gmail.com> Message-ID: > - explicitly produced via @Produces There are other use cases beside produces e.g. @ApplicationScoped class MyClass extends ClassWithFinalMethods But if we add this as well, then there is no other use case left! You could also go on and remove the whole rule in that case. But that is exactly what we don?t like, right? Because Random Joe would fall into this trap way too easily. > - added explicitly via an extension Pretty hard for an average user to do. And would also trump backward compatibility. LieGrue, strub > Am 13.02.2016 um 22:21 schrieb David Blevins : > > Read what I could get my hands on. Unfortunately the JIRA itself has 36 comments which won?t load/expand in Safari or Chrome. But I think I get the summary. > > High level, I agree with both Mark and Martin. > > - Agree with Mark: Where I see this feature being important is in our EJB/CDI alignment efforts. This appears to be the rare case where the CDI spec is more strict than the EJB spec and a speed bump in someone?s efforts to port an EJB application to CDI. For that reason, this to me upgrades from nice-to-have to we-must-find-a-way. > > - Agree with Martin: I also strongly dislike the use of beans.xml in any fashion and system properties even more. Aside from being cumbersome for users, I?m particularly against setting a trend of using system properties to bail us out of hard API design issues. This concern trumps the above and I would -1 this vote as-is. > > That said, I?m not sure if this approach is workable in any way, but here goes: > > We keep the default rule of beans with final methods being unproxyable unless explicit action in code is taken and the class is: > > - explicitly produced via @Produces > - added explicitly via an extension > > Effectively the BeanManager would continue to ignore beans with final methods as proxyable in a classpath scan, but the application could ?go back? and explicitly put them into the BeanManager as proxyable. > > > Thoughts? Big holes in there? > > > -David From antoine at sabot-durand.net Wed Feb 17 05:31:39 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 17 Feb 2016 10:31:39 +0000 Subject: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods In-Reply-To: References: <67E00C2F-02F6-4950-8EBB-69B521A6F4F2@yahoo.de> <87214B11-E9F4-4A52-83E1-39756243DDC3@gmail.com> Message-ID: Hi all, Apparently, the preferred solution for CDI-527 is the first Mark proposed: a dedicated annotation. Since we are introducing an annotation dedicated to proxy perhaps we should think it in a more general proxy configuration way to be used for other tickets like CDI-414 [1] That would give something like: @ProxyConfig(force=true) to force proxy even if the class has final method and @ProxyConfig(force=false, self=true) to have internal code in the bean to be intercepted / deocrated wdyt [1] https://issues.jboss.org/browse/CDI-414 Le mar. 16 f?vr. 2016 ? 17:56, Mark Struberg a ?crit : > > - explicitly produced via @Produces > There are other use cases beside produces > e.g. @ApplicationScoped class MyClass extends ClassWithFinalMethods > > But if we add this as well, then there is no other use case left! > You could also go on and remove the whole rule in that case. > But that is exactly what we don?t like, right? > Because Random Joe would fall into this trap way too easily. > > > - added explicitly via an extension > > Pretty hard for an average user to do. > And would also trump backward compatibility. > > LieGrue, > strub > > > > > Am 13.02.2016 um 22:21 schrieb David Blevins : > > > > Read what I could get my hands on. Unfortunately the JIRA itself has 36 > comments which won?t load/expand in Safari or Chrome. But I think I get > the summary. > > > > High level, I agree with both Mark and Martin. > > > > - Agree with Mark: Where I see this feature being important is in our > EJB/CDI alignment efforts. This appears to be the rare case where the CDI > spec is more strict than the EJB spec and a speed bump in someone?s efforts > to port an EJB application to CDI. For that reason, this to me upgrades > from nice-to-have to we-must-find-a-way. > > > > - Agree with Martin: I also strongly dislike the use of beans.xml in > any fashion and system properties even more. Aside from being cumbersome > for users, I?m particularly against setting a trend of using system > properties to bail us out of hard API design issues. This concern trumps > the above and I would -1 this vote as-is. > > > > That said, I?m not sure if this approach is workable in any way, but > here goes: > > > > We keep the default rule of beans with final methods being unproxyable > unless explicit action in code is taken and the class is: > > > > - explicitly produced via @Produces > > - added explicitly via an extension > > > > Effectively the BeanManager would continue to ignore beans with final > methods as proxyable in a classpath scan, but the application could ?go > back? and explicitly put them into the BeanManager as proxyable. > > > > > > Thoughts? Big holes in there? > > > > > > -David > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.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/20160217/0255a864/attachment-0001.html From issues at jboss.org Wed Feb 17 07:54:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 17 Feb 2016 07:54:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-507) CDI support for Singleton Pseudo Scope In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164258#comment-13164258 ] Martin Kouba commented on CDI-507: ---------------------------------- Well, the CDI spec does not mention the {{javax.inject.Singleton}} scope in the relevant section "1.2.4. Relationship to Dependency Injection for Java": {quote} The Dependency Injection for Java specification defines a set of annotations for the declaring injected fields, methods and constructors of a bean. The dependency injection service makes use of these annotations. {quote} On the other hand, all CDI implementations should pass JSR 330 TCK (see also [CDI TCK reference guide|https://docs.jboss.org/cdi/tck/reference/latest/en-US/html/introduction.html#d0e427]) and so it is defacto supported. > CDI support for Singleton Pseudo Scope > -------------------------------------- > > Key: CDI-507 > URL: https://issues.jboss.org/browse/CDI-507 > Project: CDI Specification Issues > Issue Type: Clarification > Environment: --NA-- (documentation) > Reporter: Abhishek Gupta > > Section 2.4.1 states 5 built-in scope types including the pseudo scope @Dependent. > As per the Weld documentation, CDI also supports an additional pseudo scope - @javax.inject.Singleton (see here --> http://red.ht/1D3qu97) > Just wanted to confirm whether the CDI Specification document is missing this information or the content in the Weld documentation is incorrect? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Feb 17 07:58:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 17 Feb 2016 07:58:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-554) Additional built-in beans do not have a scope defined In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-554: ----------------------------- Affects Version/s: 1.2.Final > Additional built-in beans do not have a scope defined > ----------------------------------------------------- > > Key: CDI-554 > URL: https://issues.jboss.org/browse/CDI-554 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final, 2.0-EDR1 > Reporter: Martin Kouba > > See section 17.8. Additional built-in beans - a scope is not defined for UserTransaction, Principal, HttpServletRequest, etc. Maybe it's defined somewhere else but I cannot find anything. > In Weld, Java EE beans are {{@Dependent}}, HttpServletRequest and ServletContext are {{@RequestScoped}} and HttpSession is {{@SessionScoped}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Feb 17 13:19:01 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Wed, 17 Feb 2016 13:19:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-414) Support for "self" injection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164522#comment-13164522 ] Mark Struberg commented on CDI-414: ----------------------------------- Rolling a few ideas with Antoine, we thought it might be better to have a code sample about how it looks today. And then we can figure how it _might_ look in the future Here is the current solution to start with: {code} @ApplicationScoped public class CountryService { private List cachedCountries; private @Inject CountryService _self; // this method doesn't need to open any transaction // so keep it fast without any interceptor and TX handling public List getCountries() { if (cachedCountries == null) { _self.loadCountries(); } return cachedCountries; } // but over here we might need a transaction... @Transactional protected synchronized loadCountries() { if (countries != null) return; countries = em?. load all countries form DB } } {code} > Support for "self" injection > ---------------------------- > > Key: CDI-414 > URL: https://issues.jboss.org/browse/CDI-414 > Project: CDI Specification Issues > Issue Type: Bug > Components: Resolution > Reporter: arjan tijms > Fix For: 2.0 (discussion) > > > Many features of CDI and EJB work by means of a proxy that intercepts calls and adds 'aspects'. In Java it's however not possible to decorate the {{this}} pointer, so methods called on the same bean instance from within a method in the bean do not get their 'aspects' applied. > This is a well known limitation, but in EJB it's possible to work around this by injecting a bean into itself. E.g. > {code} > @Stateless > public class Foo { > @EJB > private Foo self; > // ... > } > {code} > Also see http://adam-bien.com/roller/abien/entry/how_to_self_invoke_ejb > Unfortunately using CDI and {{@Inject}} this doesn't work. Weld for instance fails the deployment and logs: > {noformat} > WELD-001443 Pseudo scoped bean has circular dependencies. > {noformat} > See also: http://adam-bien.com/roller/abien/entry/inject_vs_ejb > Although there are workarounds, it would be great if {{@Inject}} in combination with CDI could support self injection as well. > With that projects migrating from {{@EJB}} to {{@Inject}} can do so more easily and the capability can be convenient for new projects as well (e.g. calling two separate {{@Transactional}} methods from a single method without being required to create a new bean). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Feb 17 15:16:00 2016 From: issues at jboss.org (Stephan Knitelius (JIRA)) Date: Wed, 17 Feb 2016 15:16:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-507) CDI support for Singleton Pseudo Scope In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164570#comment-13164570 ] Stephan Knitelius commented on CDI-507: --------------------------------------- Maybe it would help if it was explecitly mentioned. Since it is only treated implicitly via {code}@Scoped{code} scopes being treated as pseudo scoped. Which can lead to some odd behavior when using javax.inject.Singleton instead of application scoped. > CDI support for Singleton Pseudo Scope > -------------------------------------- > > Key: CDI-507 > URL: https://issues.jboss.org/browse/CDI-507 > Project: CDI Specification Issues > Issue Type: Clarification > Environment: --NA-- (documentation) > Reporter: Abhishek Gupta > > Section 2.4.1 states 5 built-in scope types including the pseudo scope @Dependent. > As per the Weld documentation, CDI also supports an additional pseudo scope - @javax.inject.Singleton (see here --> http://red.ht/1D3qu97) > Just wanted to confirm whether the CDI Specification document is missing this information or the content in the Weld documentation is incorrect? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Feb 17 15:17:00 2016 From: issues at jboss.org (Stephan Knitelius (JIRA)) Date: Wed, 17 Feb 2016 15:17:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-507) CDI support for Singleton Pseudo Scope In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164570#comment-13164570 ] Stephan Knitelius edited comment on CDI-507 at 2/17/16 3:16 PM: ---------------------------------------------------------------- Maybe it would help if it was explecitly mentioned. Since it is only treated implicitly via @Scoped scopes being treated as pseudo scoped. Which can lead to some odd behavior when using javax.inject.Singleton instead of application scoped. was (Author: sknitelius): Maybe it would help if it was explecitly mentioned. Since it is only treated implicitly via {code}@Scoped{code} scopes being treated as pseudo scoped. Which can lead to some odd behavior when using javax.inject.Singleton instead of application scoped. > CDI support for Singleton Pseudo Scope > -------------------------------------- > > Key: CDI-507 > URL: https://issues.jboss.org/browse/CDI-507 > Project: CDI Specification Issues > Issue Type: Clarification > Environment: --NA-- (documentation) > Reporter: Abhishek Gupta > > Section 2.4.1 states 5 built-in scope types including the pseudo scope @Dependent. > As per the Weld documentation, CDI also supports an additional pseudo scope - @javax.inject.Singleton (see here --> http://red.ht/1D3qu97) > Just wanted to confirm whether the CDI Specification document is missing this information or the content in the Weld documentation is incorrect? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Feb 18 02:39:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Thu, 18 Feb 2016 02:39:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164705#comment-13164705 ] Mark Struberg commented on CDI-420: ----------------------------------- [~antoinesabot-durand] I thought about 'explicit' as well, but it isn't really describing what happens. See my previous comment. {quote} Ad 'scoped' vs 'scanning' vs whatever. I thought pretty long about it. My first take was 'explicit'. Because you have to explicitly define the classes you like to get picked up. Otoh this term doesn't define what you need to define. For example: just an @Inject somewhere would be nuts as the detection would be pretty expensive. And this was the point which did lead me to 'scoped'. Because that's what you need to do: Define a Scope OR an annotation which leads to a defined default scope (decorator, interceptor or stereotype). Those are very easy and fast to find and have very clear rules imo. {quote} > add a bean-discovery-mode 'scoped' > ---------------------------------- > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: TBD > Reporter: Mark Struberg > Fix For: 2.0 (discussion) > > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > ? each Java class, interface or enum deployed in an explicit bean archive, and > ? each Java class with a bean defining annotation in an implicit bean archive. > ? each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Feb 18 03:20:02 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 18 Feb 2016 03:20:02 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-414) Support for "self" injection or intercepted self invocation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-414: ------------------------------------- Summary: Support for "self" injection or intercepted self invocation (was: Support for "self" injection) > Support for "self" injection or intercepted self invocation > ----------------------------------------------------------- > > Key: CDI-414 > URL: https://issues.jboss.org/browse/CDI-414 > Project: CDI Specification Issues > Issue Type: Bug > Components: Resolution > Reporter: arjan tijms > Fix For: 2.0 (discussion) > > > Many features of CDI and EJB work by means of a proxy that intercepts calls and adds 'aspects'. In Java it's however not possible to decorate the {{this}} pointer, so methods called on the same bean instance from within a method in the bean do not get their 'aspects' applied. > This is a well known limitation, but in EJB it's possible to work around this by injecting a bean into itself. E.g. > {code} > @Stateless > public class Foo { > @EJB > private Foo self; > // ... > } > {code} > Also see http://adam-bien.com/roller/abien/entry/how_to_self_invoke_ejb > Unfortunately using CDI and {{@Inject}} this doesn't work. Weld for instance fails the deployment and logs: > {noformat} > WELD-001443 Pseudo scoped bean has circular dependencies. > {noformat} > See also: http://adam-bien.com/roller/abien/entry/inject_vs_ejb > Although there are workarounds, it would be great if {{@Inject}} in combination with CDI could support self injection as well. > With that projects migrating from {{@EJB}} to {{@Inject}} can do so more easily and the capability can be convenient for new projects as well (e.g. calling two separate {{@Transactional}} methods from a single method without being required to create a new bean). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Feb 18 03:47:02 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 18 Feb 2016 03:47:02 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-414) Support for "self" injection or intercepted self invocation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164732#comment-13164732 ] Antoine Sabot-Durand commented on CDI-414: ------------------------------------------ I relaunch discussion on this ticket since we are on the verge to introduce a new annotation related to "proxy" or "business methods" exception with CDI-527. This annotation could be designed to support broader proxy related feature than just CDI-527 and could provide a solution to extend proxy generation to self invocation. Suppose the annotation to be like {code} @Target({TYPE}) @Retention(RUNTIME) @Documented public @interface AllowProxy { boolean withFinalMethods() default true; boolean onSelfInvocations() default false; } {code} {{@AllowProxy}} alone could be used for CDI-527, but this annotation could be used for this ticket. The code provided by [~struberg] above would become {code} @ApplicationScoped @AllowProxy(selfInvocation=true) //ask the container to create proxy on all invocation public class CountryService { private List cachedCountries; public List getCountries() { if (cachedCountries == null) { loadCountries(); // this call would be a business method call thanks to the annotation } return cachedCountries; } // Transactional aspect will be activated for all calls including from method in the same instance @Transactional protected synchronized loadCountries() { if (countries != null) return; countries = em?. load all countries form DB } } {code} As [~jharting] stated multiple times above, it is technically doable thanks to subclassing proxy. It's not done today because CDI was initially aligned on EJB regarding interception. Today Interceptor spec is no more part EJB and refers to "business method" concept (without defining it) for interception. CDI has its own definition of "business method" in http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#biz_method, so we could imagine adding definition for business method with this new annotation and stay consistant with interceptor spec. > Support for "self" injection or intercepted self invocation > ----------------------------------------------------------- > > Key: CDI-414 > URL: https://issues.jboss.org/browse/CDI-414 > Project: CDI Specification Issues > Issue Type: Bug > Components: Resolution > Reporter: arjan tijms > Fix For: 2.0 (discussion) > > > Many features of CDI and EJB work by means of a proxy that intercepts calls and adds 'aspects'. In Java it's however not possible to decorate the {{this}} pointer, so methods called on the same bean instance from within a method in the bean do not get their 'aspects' applied. > This is a well known limitation, but in EJB it's possible to work around this by injecting a bean into itself. E.g. > {code} > @Stateless > public class Foo { > @EJB > private Foo self; > // ... > } > {code} > Also see http://adam-bien.com/roller/abien/entry/how_to_self_invoke_ejb > Unfortunately using CDI and {{@Inject}} this doesn't work. Weld for instance fails the deployment and logs: > {noformat} > WELD-001443 Pseudo scoped bean has circular dependencies. > {noformat} > See also: http://adam-bien.com/roller/abien/entry/inject_vs_ejb > Although there are workarounds, it would be great if {{@Inject}} in combination with CDI could support self injection as well. > With that projects migrating from {{@EJB}} to {{@Inject}} can do so more easily and the capability can be convenient for new projects as well (e.g. calling two separate {{@Transactional}} methods from a single method without being required to create a new bean). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Feb 18 03:56:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 18 Feb 2016 03:56:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164738#comment-13164738 ] Antoine Sabot-Durand commented on CDI-527: ------------------------------------------ This feature was voted by the EG on Feb 15th 2016, but a majority of users expressed preference for the introduction of a dedicated annotation to support this advanced feature. {{@AllowProxy}} was the name proposed by [~struberg] but we could also find a less low level name based on Business Method concept. suggestion are welcome. As we are about to introduce a new annotation related to proxy behavior, I thought interesting to think about using it for other requested feature. See for example my comment in [CDI-414|https://issues.jboss.org/browse/CDI-414?focusedCommentId=13164732&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13164732] > allow proxying of classes with non-private final methods > -------------------------------------------------------- > > Key: CDI-527 > URL: https://issues.jboss.org/browse/CDI-527 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Assignee: Mark Struberg > Fix For: 2.0 (proposed) > > > Currently we explicitly disallow proxying of classes with non-private final methods. > EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it. > We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Feb 18 04:15:02 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Thu, 18 Feb 2016 04:15:02 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-414) Support for "self" injection or intercepted self invocation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164754#comment-13164754 ] Mark Struberg commented on CDI-414: ----------------------------------- To further clarify what Jozef (assumingly) means: There are 2 technically possible ways 1.) split this out into 2 different chains 1.a.) a general interceptor proxy (as we have today) for all class level outside invocations 1.b.) an own subclassing proxy for all self interceptors. Maybe we even need an own subclass per interceptor. 2.) ThreadLocals to transport the info of a 'local' call. That totally trashes concurrency, and thus a -1 to require it I also think that the self interception is _not_ a question for the whole proxy but rather for the interceptor itself? or even for the interceptor + the class? You probably like to apply a generic log interceptor from 'outside' and just like to trigger the @Transactional for your locally invoked method? Not sure it is really worth all the hassle. At the end this feature is _very_ rarely used. Of course it IS used and sometimes needed. But for those occasions there is the well-known pattern of simply using self-injection manually. We would also need to take a very close look at @PostConstruct and @PreDestroy as those are per definition trigger different interceptor mechanics. PS: 'business method' _is_ a well defined term in the EJB spec. > Support for "self" injection or intercepted self invocation > ----------------------------------------------------------- > > Key: CDI-414 > URL: https://issues.jboss.org/browse/CDI-414 > Project: CDI Specification Issues > Issue Type: Bug > Components: Resolution > Reporter: arjan tijms > Fix For: 2.0 (discussion) > > > Many features of CDI and EJB work by means of a proxy that intercepts calls and adds 'aspects'. In Java it's however not possible to decorate the {{this}} pointer, so methods called on the same bean instance from within a method in the bean do not get their 'aspects' applied. > This is a well known limitation, but in EJB it's possible to work around this by injecting a bean into itself. E.g. > {code} > @Stateless > public class Foo { > @EJB > private Foo self; > // ... > } > {code} > Also see http://adam-bien.com/roller/abien/entry/how_to_self_invoke_ejb > Unfortunately using CDI and {{@Inject}} this doesn't work. Weld for instance fails the deployment and logs: > {noformat} > WELD-001443 Pseudo scoped bean has circular dependencies. > {noformat} > See also: http://adam-bien.com/roller/abien/entry/inject_vs_ejb > Although there are workarounds, it would be great if {{@Inject}} in combination with CDI could support self injection as well. > With that projects migrating from {{@EJB}} to {{@Inject}} can do so more easily and the capability can be convenient for new projects as well (e.g. calling two separate {{@Transactional}} methods from a single method without being required to create a new bean). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Feb 18 05:43:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 18 Feb 2016 05:43:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-414) Support for "self" injection or intercepted self invocation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164839#comment-13164839 ] Antoine Sabot-Durand commented on CDI-414: ------------------------------------------ bq.Not sure it is really worth all the hassle. At the end this feature is very rarely used. It is not used since it's not possible today. It's a new feature proposal bq. Of course it IS used and sometimes needed. But for those occasions there is the well-known pattern of simply using self-injection manually. IMO Self-Injection is not a design pattern, it's a smelly trick introduced to EJB implementation limitation The number of average joe who think that interceptor will be triggered from internal call is countless. Check on Stack Overflow bq. PS: 'business method' is a well defined term in the EJB spec. What's the interest of this remark? CDI is not EJB and had to give its own definition of "business method" since Interceptor spec doesn't. > Support for "self" injection or intercepted self invocation > ----------------------------------------------------------- > > Key: CDI-414 > URL: https://issues.jboss.org/browse/CDI-414 > Project: CDI Specification Issues > Issue Type: Bug > Components: Resolution > Reporter: arjan tijms > Fix For: 2.0 (discussion) > > > Many features of CDI and EJB work by means of a proxy that intercepts calls and adds 'aspects'. In Java it's however not possible to decorate the {{this}} pointer, so methods called on the same bean instance from within a method in the bean do not get their 'aspects' applied. > This is a well known limitation, but in EJB it's possible to work around this by injecting a bean into itself. E.g. > {code} > @Stateless > public class Foo { > @EJB > private Foo self; > // ... > } > {code} > Also see http://adam-bien.com/roller/abien/entry/how_to_self_invoke_ejb > Unfortunately using CDI and {{@Inject}} this doesn't work. Weld for instance fails the deployment and logs: > {noformat} > WELD-001443 Pseudo scoped bean has circular dependencies. > {noformat} > See also: http://adam-bien.com/roller/abien/entry/inject_vs_ejb > Although there are workarounds, it would be great if {{@Inject}} in combination with CDI could support self injection as well. > With that projects migrating from {{@EJB}} to {{@Inject}} can do so more easily and the capability can be convenient for new projects as well (e.g. calling two separate {{@Transactional}} methods from a single method without being required to create a new bean). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Feb 18 06:14:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 18 Feb 2016 06:14:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-584) Clarification needed on Set mutability returned by SPI In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-584: ---------------------------------------- Summary: Clarification needed on Set mutability returned by SPI Key: CDI-584 URL: https://issues.jboss.org/browse/CDI-584 Project: CDI Specification Issues Issue Type: Clarification Components: Portable Extensions Reporter: Antoine Sabot-Durand {{ProcessBean}} lifecycle event could be the occasion to add new Injection point to an existing bean, but when you call {{ProcessBean#getBean()#getInjectionPoints()}} the returned set mutable in OWB and immutable in Weld. As the spec doesn't precise if the Set should be mutable or not, each spec made its own choice. The result is a lack of consistency between both impl and an interesting feature harder to do with Weld (work with AnnotatedType or create a custom bean to add injection point) More generally we should clarify mutability of each Set returned in the SPI. And check if it wouldn't be better to add method to life cycle event to provide a "temporary" mutable set (i.e. {{ProcessBean#getInjectionPoints()}} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Feb 18 06:20:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 18 Feb 2016 06:20:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-584) Clarification needed on Set mutability returned by SPI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-584: ------------------------------------- Description: {{ProcessBean}} lifecycle event could be the occasion to add new Injection point to an existing bean, but when you call {{ProcessBean#getBean()#getInjectionPoints()}} the returned set is mutable in OWB and immutable in Weld. As the spec doesn't precise if the Set should be mutable or not, each spec made its own choice. The result is a lack of consistency between both impl and an interesting feature harder to do with Weld (work with AnnotatedType or create a custom bean to add injection point) More generally we should clarify mutability of each Set returned in the SPI. And check if it wouldn't be better to add method to life cycle event to provide a "temporary" mutable set (i.e. {{ProcessBean#getInjectionPoints()}} was: {{ProcessBean}} lifecycle event could be the occasion to add new Injection point to an existing bean, but when you call {{ProcessBean#getBean()#getInjectionPoints()}} the returned set mutable in OWB and immutable in Weld. As the spec doesn't precise if the Set should be mutable or not, each spec made its own choice. The result is a lack of consistency between both impl and an interesting feature harder to do with Weld (work with AnnotatedType or create a custom bean to add injection point) More generally we should clarify mutability of each Set returned in the SPI. And check if it wouldn't be better to add method to life cycle event to provide a "temporary" mutable set (i.e. {{ProcessBean#getInjectionPoints()}} > Clarification needed on Set mutability returned by SPI > ------------------------------------------------------ > > Key: CDI-584 > URL: https://issues.jboss.org/browse/CDI-584 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Reporter: Antoine Sabot-Durand > > {{ProcessBean}} lifecycle event could be the occasion to add new Injection point to an existing bean, but when you call {{ProcessBean#getBean()#getInjectionPoints()}} the returned set is mutable in OWB and immutable in Weld. > As the spec doesn't precise if the Set should be mutable or not, each spec made its own choice. > The result is a lack of consistency between both impl and an interesting feature harder to do with Weld (work with AnnotatedType or create a custom bean to add injection point) > More generally we should clarify mutability of each Set returned in the SPI. And check if it wouldn't be better to add method to life cycle event to provide a "temporary" mutable set (i.e. {{ProcessBean#getInjectionPoints()}} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Feb 18 06:20:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 18 Feb 2016 06:20:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-584) Clarification needed on Set mutability returned by SPI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-584: ------------------------------------- Description: {{ProcessBean}} lifecycle event could be the occasion to add new Injection point to an existing bean, but when you call {{ProcessBean#getBean()#getInjectionPoints()}} the returned set is mutable in OWB and immutable in Weld. As the spec doesn't precise if the Set should be mutable or not, each impl made its own choice. The result is a lack of consistency between both impl and an interesting feature harder to do with Weld (work with AnnotatedType or create a custom bean to add injection point) More generally we should clarify mutability of each Set returned in the SPI. And check if it wouldn't be better to add method to life cycle event to provide a "temporary" mutable set (i.e. {{ProcessBean#getInjectionPoints()}} was: {{ProcessBean}} lifecycle event could be the occasion to add new Injection point to an existing bean, but when you call {{ProcessBean#getBean()#getInjectionPoints()}} the returned set is mutable in OWB and immutable in Weld. As the spec doesn't precise if the Set should be mutable or not, each spec made its own choice. The result is a lack of consistency between both impl and an interesting feature harder to do with Weld (work with AnnotatedType or create a custom bean to add injection point) More generally we should clarify mutability of each Set returned in the SPI. And check if it wouldn't be better to add method to life cycle event to provide a "temporary" mutable set (i.e. {{ProcessBean#getInjectionPoints()}} > Clarification needed on Set mutability returned by SPI > ------------------------------------------------------ > > Key: CDI-584 > URL: https://issues.jboss.org/browse/CDI-584 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Reporter: Antoine Sabot-Durand > > {{ProcessBean}} lifecycle event could be the occasion to add new Injection point to an existing bean, but when you call {{ProcessBean#getBean()#getInjectionPoints()}} the returned set is mutable in OWB and immutable in Weld. > As the spec doesn't precise if the Set should be mutable or not, each impl made its own choice. > The result is a lack of consistency between both impl and an interesting feature harder to do with Weld (work with AnnotatedType or create a custom bean to add injection point) > More generally we should clarify mutability of each Set returned in the SPI. And check if it wouldn't be better to add method to life cycle event to provide a "temporary" mutable set (i.e. {{ProcessBean#getInjectionPoints()}} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Feb 18 09:14:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 18 Feb 2016 09:14:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-585) Add the possibility to remove a bean in AfterBeanDiscovery event In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-585: ---------------------------------------- Summary: Add the possibility to remove a bean in AfterBeanDiscovery event Key: CDI-585 URL: https://issues.jboss.org/browse/CDI-585 Project: CDI Specification Issues Issue Type: Feature Request Components: Portable Extensions Affects Versions: 2.0-EDR1, 1.2.Final Reporter: Antoine Sabot-Durand Right now, the last occasion to "veto" a bean is in {{ProcessBeanAttributes}}, but we sometimes need to have all the bean discovered to decide if a given Bean should be present or not. Sometimes we also need a way to decide lately for some bean properties, so it would be useful to remove the original bean and provide a custom one wrapping it in replacement. Adding the {{removeBean(Bean bean)}} to {{AfterBeanDiscoveryEvent}} would be helpful to perform easily these use case. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Feb 18 09:57:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Thu, 18 Feb 2016 09:57:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-585) Add the possibility to remove a bean in AfterBeanDiscovery event In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13165116#comment-13165116 ] Mark Struberg commented on CDI-585: ----------------------------------- I like this idea, BUT we _really_ have to be careful with all the 'disabled beans' stuff. It is again a chicken-egg problem. If you remove a @Specializes bean for example, then you king of change the whole constellation... > Add the possibility to remove a bean in AfterBeanDiscovery event > ---------------------------------------------------------------- > > Key: CDI-585 > URL: https://issues.jboss.org/browse/CDI-585 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.2.Final, 2.0-EDR1 > Reporter: Antoine Sabot-Durand > > Right now, the last occasion to "veto" a bean is in {{ProcessBeanAttributes}}, but we sometimes need to have all the bean discovered to decide if a given Bean should be present or not. > Sometimes we also need a way to decide lately for some bean properties, so it would be useful to remove the original bean and provide a custom one wrapping it in replacement. > Adding the {{removeBean(Bean bean)}} to {{AfterBeanDiscoveryEvent}} would be helpful to perform easily these use case. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Feb 18 10:18:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 18 Feb 2016 10:18:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-585) Add the possibility to remove a bean in AfterBeanDiscovery event In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13165148#comment-13165148 ] Antoine Sabot-Durand commented on CDI-585: ------------------------------------------ Yes there are probably limitation to take care of. This said, validation of the container comes just after and if you did a nasty thing you'll have a deployment error. > Add the possibility to remove a bean in AfterBeanDiscovery event > ---------------------------------------------------------------- > > Key: CDI-585 > URL: https://issues.jboss.org/browse/CDI-585 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.2.Final, 2.0-EDR1 > Reporter: Antoine Sabot-Durand > > Right now, the last occasion to "veto" a bean is in {{ProcessBeanAttributes}}, but we sometimes need to have all the bean discovered to decide if a given Bean should be present or not. > Sometimes we also need a way to decide lately for some bean properties, so it would be useful to remove the original bean and provide a custom one wrapping it in replacement. > Adding the {{removeBean(Bean bean)}} to {{AfterBeanDiscoveryEvent}} would be helpful to perform easily these use case. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Feb 19 02:59:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 19 Feb 2016 02:59:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-584) Clarification needed on Set mutability returned by SPI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13165526#comment-13165526 ] Martin Kouba commented on CDI-584: ---------------------------------- I'm a big fan of defensive programming and my assumption is all the metadata exposed to the user should be immutable. This "temporary mutable thing" is a bad idea and might only bring confusion. Also I think it's not a clear API if an interface behaves differently in different situations. > Clarification needed on Set mutability returned by SPI > ------------------------------------------------------ > > Key: CDI-584 > URL: https://issues.jboss.org/browse/CDI-584 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Reporter: Antoine Sabot-Durand > > {{ProcessBean}} lifecycle event could be the occasion to add new Injection point to an existing bean, but when you call {{ProcessBean#getBean()#getInjectionPoints()}} the returned set is mutable in OWB and immutable in Weld. > As the spec doesn't precise if the Set should be mutable or not, each impl made its own choice. > The result is a lack of consistency between both impl and an interesting feature harder to do with Weld (work with AnnotatedType or create a custom bean to add injection point) > More generally we should clarify mutability of each Set returned in the SPI. And check if it wouldn't be better to add method to life cycle event to provide a "temporary" mutable set (i.e. {{ProcessBean#getInjectionPoints()}} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Feb 19 03:10:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 19 Feb 2016 03:10:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-507) CDI support for Singleton Pseudo Scope In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13165533#comment-13165533 ] Martin Kouba commented on CDI-507: ---------------------------------- Well, {{javax.inject.Singleton}} will always be a pseudo-scope and will never behave in the same way as {{ApplicationScoped}} normal scope. See also [5.4. The singleton pseudo-scope|http://docs.jboss.org/weld/reference/latest/en-US/html/scopescontexts.html#_the_singleton_pseudo_scope] in the Weld reference guide. > CDI support for Singleton Pseudo Scope > -------------------------------------- > > Key: CDI-507 > URL: https://issues.jboss.org/browse/CDI-507 > Project: CDI Specification Issues > Issue Type: Clarification > Environment: --NA-- (documentation) > Reporter: Abhishek Gupta > > Section 2.4.1 states 5 built-in scope types including the pseudo scope @Dependent. > As per the Weld documentation, CDI also supports an additional pseudo scope - @javax.inject.Singleton (see here --> http://red.ht/1D3qu97) > Just wanted to confirm whether the CDI Specification document is missing this information or the content in the Weld documentation is incorrect? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Feb 19 04:53:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 19 Feb 2016 04:53:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13165596#comment-13165596 ] Martin Kouba commented on CDI-527: ---------------------------------- Correct me if I'm wrong, but if the only way of using this "feature" would be declaring an annotation than we *will not be able to help legacy apps* (compiled against older CDI API, no source available, etc.) - this was one of the requirements often cited in previous comments. Also it might be problematic *to integrate a class we're not able to modify*. Just for completeness - I'm ok with this as both impls provide a non-portable solution already. > allow proxying of classes with non-private final methods > -------------------------------------------------------- > > Key: CDI-527 > URL: https://issues.jboss.org/browse/CDI-527 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Assignee: Mark Struberg > Fix For: 2.0 (proposed) > > > Currently we explicitly disallow proxying of classes with non-private final methods. > EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it. > We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Feb 19 05:02:00 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Fri, 19 Feb 2016 05:02:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13165601#comment-13165601 ] Romain Manni-Bucau commented on CDI-527: ---------------------------------------- [~mkouba] annotation => spi so we can write an extension solving issues for legacy apps so this is fine IMO. Big advantage is to allow a *portable* solution which is reliable on the long term (opposed to impl solutions) > allow proxying of classes with non-private final methods > -------------------------------------------------------- > > Key: CDI-527 > URL: https://issues.jboss.org/browse/CDI-527 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Assignee: Mark Struberg > Fix For: 2.0 (proposed) > > > Currently we explicitly disallow proxying of classes with non-private final methods. > EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it. > We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Feb 19 05:03:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 19 Feb 2016 05:03:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-414) Support for "self" injection or intercepted self invocation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13165602#comment-13165602 ] Martin Kouba commented on CDI-414: ---------------------------------- {quote} bq. Of course it IS used and sometimes needed. But for those occasions there is the well-known pattern of simply using self-injection manually. IMO Self-Injection is not a design pattern, it's a smelly trick introduced to EJB implementation limitation The number of average joe who think that interceptor will be triggered from internal call is countless. Check on Stack Overflow {quote} I'm not really sure this "feature" would help ordinary users, we would basically replace self-injection trick with annotation trick (of course, except it's easier to use) - the feature will be disabled by default, right? Also I'm not sure it's a good idea to reuse the {{@AllowProxy}} (or whatever the name would be) annotation. > Support for "self" injection or intercepted self invocation > ----------------------------------------------------------- > > Key: CDI-414 > URL: https://issues.jboss.org/browse/CDI-414 > Project: CDI Specification Issues > Issue Type: Bug > Components: Resolution > Reporter: arjan tijms > Fix For: 2.0 (discussion) > > > Many features of CDI and EJB work by means of a proxy that intercepts calls and adds 'aspects'. In Java it's however not possible to decorate the {{this}} pointer, so methods called on the same bean instance from within a method in the bean do not get their 'aspects' applied. > This is a well known limitation, but in EJB it's possible to work around this by injecting a bean into itself. E.g. > {code} > @Stateless > public class Foo { > @EJB > private Foo self; > // ... > } > {code} > Also see http://adam-bien.com/roller/abien/entry/how_to_self_invoke_ejb > Unfortunately using CDI and {{@Inject}} this doesn't work. Weld for instance fails the deployment and logs: > {noformat} > WELD-001443 Pseudo scoped bean has circular dependencies. > {noformat} > See also: http://adam-bien.com/roller/abien/entry/inject_vs_ejb > Although there are workarounds, it would be great if {{@Inject}} in combination with CDI could support self injection as well. > With that projects migrating from {{@EJB}} to {{@Inject}} can do so more easily and the capability can be convenient for new projects as well (e.g. calling two separate {{@Transactional}} methods from a single method without being required to create a new bean). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Feb 19 05:24:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 19 Feb 2016 05:24:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13165620#comment-13165620 ] Martin Kouba commented on CDI-527: ---------------------------------- [~rmannibucau] Ok, so we would need a configurable extension which would detect problematic AnnotatedTypes and add this annotation where appropriate. Sounds doable. Also I'm aware of pros and cons of portable and non-portable solutions. > allow proxying of classes with non-private final methods > -------------------------------------------------------- > > Key: CDI-527 > URL: https://issues.jboss.org/browse/CDI-527 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Assignee: Mark Struberg > Fix For: 2.0 (proposed) > > > Currently we explicitly disallow proxying of classes with non-private final methods. > EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it. > We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From stephan at knitelius.com Fri Feb 19 05:27:42 2016 From: stephan at knitelius.com (Stephan Knitelius) Date: Fri, 19 Feb 2016 11:27:42 +0100 Subject: [cdi-dev] Concurrency Control Message-ID: Hi all, CDI spec does not define a common concurrency control mechanism. The time any type of concurrency control is mentioned is in conjunction with EJB and a rather restrictive one for conversation context. CDI Spec: The container ensures that a long-running conversation may be associated with at most one request at a time, by blocking or rejecting concurrent requests. If the container rejects a request, it must associate the request with a new transient conversation and throw an exception of type javax.enterprise.context.BusyConversationException. It would be helpful if a common configurable concurrency mechanism (EJB Singleton style locking?) could be established for all normal scopes. What are your thoughts on this? Regards, Stephan ______________________________________ *Stephan Knitelius* Alteburger Str. 274 50968 K?ln / Cologne Deutschland / Germany stephan at knitelius.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160219/73b03a10/attachment-0001.html From issues at jboss.org Fri Feb 19 05:44:00 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Fri, 19 Feb 2016 05:44:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-584) Clarification needed on Set mutability returned by SPI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13165637#comment-13165637 ] Romain Manni-Bucau commented on CDI-584: ---------------------------------------- Not sure in term of implementation but stating the user shouldnt modify it and it is not portable what happens if so sounds good. > Clarification needed on Set mutability returned by SPI > ------------------------------------------------------ > > Key: CDI-584 > URL: https://issues.jboss.org/browse/CDI-584 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Reporter: Antoine Sabot-Durand > > {{ProcessBean}} lifecycle event could be the occasion to add new Injection point to an existing bean, but when you call {{ProcessBean#getBean()#getInjectionPoints()}} the returned set is mutable in OWB and immutable in Weld. > As the spec doesn't precise if the Set should be mutable or not, each impl made its own choice. > The result is a lack of consistency between both impl and an interesting feature harder to do with Weld (work with AnnotatedType or create a custom bean to add injection point) > More generally we should clarify mutability of each Set returned in the SPI. And check if it wouldn't be better to add method to life cycle event to provide a "temporary" mutable set (i.e. {{ProcessBean#getInjectionPoints()}} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Feb 19 05:56:00 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Fri, 19 Feb 2016 05:56:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13165646#comment-13165646 ] Romain Manni-Bucau commented on CDI-527: ---------------------------------------- [~mkouba] it is doable as generic as you mention of with a hardcoded list for known types depending the type of application. The main point is to allow this type of usage and to allow to solve the broken applications without modifying the existing code. The SPI solves the second point and the annotation the first one so sounds like a good compromise for past and future to me. > allow proxying of classes with non-private final methods > -------------------------------------------------------- > > Key: CDI-527 > URL: https://issues.jboss.org/browse/CDI-527 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Assignee: Mark Struberg > Fix For: 2.0 (proposed) > > > Currently we explicitly disallow proxying of classes with non-private final methods. > EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it. > We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Feb 19 05:58:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 19 Feb 2016 05:58:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-584) Clarification needed on Set mutability returned by SPI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13165647#comment-13165647 ] Antoine Sabot-Durand commented on CDI-584: ------------------------------------------ [~mkouba] agree with you, but, that means we should check if some Lifecycle events (like ProcessBean) could have new method to change the underlying meta-data (i.e {{ProcessBean#addInjectionPoint()}}). [~rmannibucau] also agree. The idea is not to force OWB to change its behavior but to state that it's not portable. And we should provide standard way to perform these meta data mutation at the lifecycle event level (see my remark above). > Clarification needed on Set mutability returned by SPI > ------------------------------------------------------ > > Key: CDI-584 > URL: https://issues.jboss.org/browse/CDI-584 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Reporter: Antoine Sabot-Durand > > {{ProcessBean}} lifecycle event could be the occasion to add new Injection point to an existing bean, but when you call {{ProcessBean#getBean()#getInjectionPoints()}} the returned set is mutable in OWB and immutable in Weld. > As the spec doesn't precise if the Set should be mutable or not, each impl made its own choice. > The result is a lack of consistency between both impl and an interesting feature harder to do with Weld (work with AnnotatedType or create a custom bean to add injection point) > More generally we should clarify mutability of each Set returned in the SPI. And check if it wouldn't be better to add method to life cycle event to provide a "temporary" mutable set (i.e. {{ProcessBean#getInjectionPoints()}} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Feb 19 06:48:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 19 Feb 2016 06:48:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-584) Clarification needed on Set mutability returned by SPI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13165667#comment-13165667 ] Martin Kouba commented on CDI-584: ---------------------------------- I'm sorry to be so sceptical but why do I need to add an injection point to a bean at this phase? A simple example would be enough. > Clarification needed on Set mutability returned by SPI > ------------------------------------------------------ > > Key: CDI-584 > URL: https://issues.jboss.org/browse/CDI-584 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Reporter: Antoine Sabot-Durand > > {{ProcessBean}} lifecycle event could be the occasion to add new Injection point to an existing bean, but when you call {{ProcessBean#getBean()#getInjectionPoints()}} the returned set is mutable in OWB and immutable in Weld. > As the spec doesn't precise if the Set should be mutable or not, each impl made its own choice. > The result is a lack of consistency between both impl and an interesting feature harder to do with Weld (work with AnnotatedType or create a custom bean to add injection point) > More generally we should clarify mutability of each Set returned in the SPI. And check if it wouldn't be better to add method to life cycle event to provide a "temporary" mutable set (i.e. {{ProcessBean#getInjectionPoints()}} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Feb 19 09:18:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 19 Feb 2016 09:18:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-584) Clarification needed on Set mutability returned by SPI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13165772#comment-13165772 ] Antoine Sabot-Durand commented on CDI-584: ------------------------------------------ To that I could answer, "what's the use of ProcessBean if you can't do anything about the bean tied to the event" ;) ? But I have an example. I was asked to build a prototype extension to create an injection point when a given annotation ({{@CacheContext}}) is found on a field. Here's the portable code I had to wrote to create the feature : * An AnnotatedType [implementation|https://github.com/antoinesd/CDI-Sandbox/blob/fb18eb718ab93f68dcef6b934d70589b789d251b/auto-inject/src/main/java/org/cdisandbox/autoinject/Extension/AutoInjectingAnnotatedType.java] * An AnnotatedField [implementation|https://github.com/antoinesd/CDI-Sandbox/blob/fb18eb718ab93f68dcef6b934d70589b789d251b/auto-inject/src/main/java/org/cdisandbox/autoinject/Extension/AutoInjectingAnnotatedField.java] * and the [Extension|https://github.com/antoinesd/CDI-Sandbox/blob/fb18eb718ab93f68dcef6b934d70589b789d251b/auto-inject/src/main/java/org/cdisandbox/autoinject/Extension/AutoInjectExtension.java] Extension code is small but {{AnnotatedType}} and {{AnnotatedField }} are verbose and the whole is cumbersome to read and maintain (3 classes and 178 lines of code) If we only target OWB, the extension code is: {code} package org.cdisandbox.autoinject.Extension; import org.cdisandbox.autoinject.CacheContext; import javax.enterprise.event.Observes; import javax.enterprise.inject.spi.*; import java.util.HashSet; import java.util.Set; /** * Extension looking for the @CacheContext annotation to transform it in an InjectionPoint */ public class AutoInjectExtension implements Extension { private Set> atWithCacheContext = new HashSet<>(); /** * This Observer captures all AnnotatedType containing @CacheContext */ public void CreateInjectionPoint(@Observes @WithAnnotations(CacheContext.class) ProcessAnnotatedType pat) { atWithCacheContext.add(pat.getAnnotatedType()); } /** * This observer add an injection point in all bean having @Cachecontext annotaion on some field */ public void CheckBeansForCacheContext(@Observes ProcessManagedBean pmb, BeanManager bm) { AnnotatedType beanAT = pmb.getAnnotatedBeanClass(); if(atWithCacheContext.contains(beanAT)) { Bean bean = pmb.getBean(); Set ips = new HashSet(bean.getInjectionPoints()); for (AnnotatedField f : beanAT.getFields()) { if(f.isAnnotationPresent(CacheContext.class)) { ips.add(bm.createInjectionPoint(f)); } } } } } {code} One class, 42 lines. > Clarification needed on Set mutability returned by SPI > ------------------------------------------------------ > > Key: CDI-584 > URL: https://issues.jboss.org/browse/CDI-584 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Reporter: Antoine Sabot-Durand > > {{ProcessBean}} lifecycle event could be the occasion to add new Injection point to an existing bean, but when you call {{ProcessBean#getBean()#getInjectionPoints()}} the returned set is mutable in OWB and immutable in Weld. > As the spec doesn't precise if the Set should be mutable or not, each impl made its own choice. > The result is a lack of consistency between both impl and an interesting feature harder to do with Weld (work with AnnotatedType or create a custom bean to add injection point) > More generally we should clarify mutability of each Set returned in the SPI. And check if it wouldn't be better to add method to life cycle event to provide a "temporary" mutable set (i.e. {{ProcessBean#getInjectionPoints()}} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Feb 19 09:24:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 19 Feb 2016 09:24:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-584) Clarification needed on Set mutability returned by SPI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13165772#comment-13165772 ] Antoine Sabot-Durand edited comment on CDI-584 at 2/19/16 9:23 AM: ------------------------------------------------------------------- To that I could answer, "what's the use of ProcessBean if you can't do anything about the bean tied to the event" ;) ? But I have an example. I was asked to build a prototype extension to create an injection point when a given annotation ({{@CacheContext}}) is found on a field. Here's the portable code I had to wrote to create the feature : * An AnnotatedType [implementation|https://github.com/antoinesd/CDI-Sandbox/blob/fb18eb718ab93f68dcef6b934d70589b789d251b/auto-inject/src/main/java/org/cdisandbox/autoinject/Extension/AutoInjectingAnnotatedType.java] * An AnnotatedField [implementation|https://github.com/antoinesd/CDI-Sandbox/blob/fb18eb718ab93f68dcef6b934d70589b789d251b/auto-inject/src/main/java/org/cdisandbox/autoinject/Extension/AutoInjectingAnnotatedField.java] * and the [Extension|https://github.com/antoinesd/CDI-Sandbox/blob/fb18eb718ab93f68dcef6b934d70589b789d251b/auto-inject/src/main/java/org/cdisandbox/autoinject/Extension/AutoInjectExtension.java] Extension code is small but {{AnnotatedType}} and {{AnnotatedField}} impls are verbose and the whole is cumbersome to read and maintain (3 classes and 178 lines of code) If we only target OWB, the extension code is: {code} package org.cdisandbox.autoinject.Extension; import org.cdisandbox.autoinject.CacheContext; import javax.enterprise.event.Observes; import javax.enterprise.inject.spi.*; import java.util.HashSet; import java.util.Set; /** * Extension looking for the @CacheContext annotation to transform it in an InjectionPoint */ public class AutoInjectExtension implements Extension { private Set> atWithCacheContext = new HashSet<>(); /** * This Observer captures all AnnotatedType containing @CacheContext */ public void CreateInjectionPoint(@Observes @WithAnnotations(CacheContext.class) ProcessAnnotatedType pat) { atWithCacheContext.add(pat.getAnnotatedType()); } /** * This observer add an injection point in all bean having @Cachecontext annotaion on some field */ public void CheckBeansForCacheContext(@Observes ProcessManagedBean pmb, BeanManager bm) { AnnotatedType beanAT = pmb.getAnnotatedBeanClass(); if(atWithCacheContext.contains(beanAT)) { Bean bean = pmb.getBean(); Set ips = new HashSet(bean.getInjectionPoints()); for (AnnotatedField f : beanAT.getFields()) { if(f.isAnnotationPresent(CacheContext.class)) { ips.add(bm.createInjectionPoint(f)); } } } } } {code} One class, 42 lines. was (Author: antoinesabot-durand): To that I could answer, "what's the use of ProcessBean if you can't do anything about the bean tied to the event" ;) ? But I have an example. I was asked to build a prototype extension to create an injection point when a given annotation ({{@CacheContext}}) is found on a field. Here's the portable code I had to wrote to create the feature : * An AnnotatedType [implementation|https://github.com/antoinesd/CDI-Sandbox/blob/fb18eb718ab93f68dcef6b934d70589b789d251b/auto-inject/src/main/java/org/cdisandbox/autoinject/Extension/AutoInjectingAnnotatedType.java] * An AnnotatedField [implementation|https://github.com/antoinesd/CDI-Sandbox/blob/fb18eb718ab93f68dcef6b934d70589b789d251b/auto-inject/src/main/java/org/cdisandbox/autoinject/Extension/AutoInjectingAnnotatedField.java] * and the [Extension|https://github.com/antoinesd/CDI-Sandbox/blob/fb18eb718ab93f68dcef6b934d70589b789d251b/auto-inject/src/main/java/org/cdisandbox/autoinject/Extension/AutoInjectExtension.java] Extension code is small but {{AnnotatedType}} and {{AnnotatedField }} are verbose and the whole is cumbersome to read and maintain (3 classes and 178 lines of code) If we only target OWB, the extension code is: {code} package org.cdisandbox.autoinject.Extension; import org.cdisandbox.autoinject.CacheContext; import javax.enterprise.event.Observes; import javax.enterprise.inject.spi.*; import java.util.HashSet; import java.util.Set; /** * Extension looking for the @CacheContext annotation to transform it in an InjectionPoint */ public class AutoInjectExtension implements Extension { private Set> atWithCacheContext = new HashSet<>(); /** * This Observer captures all AnnotatedType containing @CacheContext */ public void CreateInjectionPoint(@Observes @WithAnnotations(CacheContext.class) ProcessAnnotatedType pat) { atWithCacheContext.add(pat.getAnnotatedType()); } /** * This observer add an injection point in all bean having @Cachecontext annotaion on some field */ public void CheckBeansForCacheContext(@Observes ProcessManagedBean pmb, BeanManager bm) { AnnotatedType beanAT = pmb.getAnnotatedBeanClass(); if(atWithCacheContext.contains(beanAT)) { Bean bean = pmb.getBean(); Set ips = new HashSet(bean.getInjectionPoints()); for (AnnotatedField f : beanAT.getFields()) { if(f.isAnnotationPresent(CacheContext.class)) { ips.add(bm.createInjectionPoint(f)); } } } } } {code} One class, 42 lines. > Clarification needed on Set mutability returned by SPI > ------------------------------------------------------ > > Key: CDI-584 > URL: https://issues.jboss.org/browse/CDI-584 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Reporter: Antoine Sabot-Durand > > {{ProcessBean}} lifecycle event could be the occasion to add new Injection point to an existing bean, but when you call {{ProcessBean#getBean()#getInjectionPoints()}} the returned set is mutable in OWB and immutable in Weld. > As the spec doesn't precise if the Set should be mutable or not, each impl made its own choice. > The result is a lack of consistency between both impl and an interesting feature harder to do with Weld (work with AnnotatedType or create a custom bean to add injection point) > More generally we should clarify mutability of each Set returned in the SPI. And check if it wouldn't be better to add method to life cycle event to provide a "temporary" mutable set (i.e. {{ProcessBean#getInjectionPoints()}} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Feb 19 09:43:01 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 19 Feb 2016 09:43:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-584) Clarification needed on Set mutability returned by SPI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13165806#comment-13165806 ] Martin Kouba commented on CDI-584: ---------------------------------- I see, that's a good example. So something like {{ProcessBean#setInjectionPoints()}} might be useful. > Clarification needed on Set mutability returned by SPI > ------------------------------------------------------ > > Key: CDI-584 > URL: https://issues.jboss.org/browse/CDI-584 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Reporter: Antoine Sabot-Durand > > {{ProcessBean}} lifecycle event could be the occasion to add new Injection point to an existing bean, but when you call {{ProcessBean#getBean()#getInjectionPoints()}} the returned set is mutable in OWB and immutable in Weld. > As the spec doesn't precise if the Set should be mutable or not, each impl made its own choice. > The result is a lack of consistency between both impl and an interesting feature harder to do with Weld (work with AnnotatedType or create a custom bean to add injection point) > More generally we should clarify mutability of each Set returned in the SPI. And check if it wouldn't be better to add method to life cycle event to provide a "temporary" mutable set (i.e. {{ProcessBean#getInjectionPoints()}} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Feb 19 09:43:01 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 19 Feb 2016 09:43:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-584) Clarification needed on Set mutability returned by SPI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13165806#comment-13165806 ] Martin Kouba edited comment on CDI-584 at 2/19/16 9:42 AM: ----------------------------------------------------------- I see, that's a good example. So something like {{ProcessBean#setBeanInjectionPoints()}} might be useful. was (Author: mkouba): I see, that's a good example. So something like {{ProcessBean#setInjectionPoints()}} might be useful. > Clarification needed on Set mutability returned by SPI > ------------------------------------------------------ > > Key: CDI-584 > URL: https://issues.jboss.org/browse/CDI-584 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Reporter: Antoine Sabot-Durand > > {{ProcessBean}} lifecycle event could be the occasion to add new Injection point to an existing bean, but when you call {{ProcessBean#getBean()#getInjectionPoints()}} the returned set is mutable in OWB and immutable in Weld. > As the spec doesn't precise if the Set should be mutable or not, each impl made its own choice. > The result is a lack of consistency between both impl and an interesting feature harder to do with Weld (work with AnnotatedType or create a custom bean to add injection point) > More generally we should clarify mutability of each Set returned in the SPI. And check if it wouldn't be better to add method to life cycle event to provide a "temporary" mutable set (i.e. {{ProcessBean#getInjectionPoints()}} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Feb 19 09:46:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 19 Feb 2016 09:46:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-584) Clarification needed on Set mutability returned by SPI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13165806#comment-13165806 ] Martin Kouba edited comment on CDI-584 at 2/19/16 9:45 AM: ----------------------------------------------------------- I see, that's a good example. So something like {{ProcessBean#setBeanInjectionPoints()}} might be useful. By the way, the example wouldn't work because {{ips}} is not a reference to the original set of injection points (it only contains all the elements from the original set ;-). was (Author: mkouba): I see, that's a good example. So something like {{ProcessBean#setBeanInjectionPoints()}} might be useful. > Clarification needed on Set mutability returned by SPI > ------------------------------------------------------ > > Key: CDI-584 > URL: https://issues.jboss.org/browse/CDI-584 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Reporter: Antoine Sabot-Durand > > {{ProcessBean}} lifecycle event could be the occasion to add new Injection point to an existing bean, but when you call {{ProcessBean#getBean()#getInjectionPoints()}} the returned set is mutable in OWB and immutable in Weld. > As the spec doesn't precise if the Set should be mutable or not, each impl made its own choice. > The result is a lack of consistency between both impl and an interesting feature harder to do with Weld (work with AnnotatedType or create a custom bean to add injection point) > More generally we should clarify mutability of each Set returned in the SPI. And check if it wouldn't be better to add method to life cycle event to provide a "temporary" mutable set (i.e. {{ProcessBean#getInjectionPoints()}} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Feb 19 09:58:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 19 Feb 2016 09:58:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-584) Clarification needed on Set mutability returned by SPI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13165820#comment-13165820 ] Antoine Sabot-Durand commented on CDI-584: ------------------------------------------ Good catch. Error was on purpose to check your attention ;)... Ok, bad version pasted. We should have {code} Set ips = bean.getInjectionPoints(); {code} I create the ticket for addition to {{ProcessBean}} > Clarification needed on Set mutability returned by SPI > ------------------------------------------------------ > > Key: CDI-584 > URL: https://issues.jboss.org/browse/CDI-584 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Reporter: Antoine Sabot-Durand > > {{ProcessBean}} lifecycle event could be the occasion to add new Injection point to an existing bean, but when you call {{ProcessBean#getBean()#getInjectionPoints()}} the returned set is mutable in OWB and immutable in Weld. > As the spec doesn't precise if the Set should be mutable or not, each impl made its own choice. > The result is a lack of consistency between both impl and an interesting feature harder to do with Weld (work with AnnotatedType or create a custom bean to add injection point) > More generally we should clarify mutability of each Set returned in the SPI. And check if it wouldn't be better to add method to life cycle event to provide a "temporary" mutable set (i.e. {{ProcessBean#getInjectionPoints()}} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Feb 22 04:57:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 22 Feb 2016 04:57:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-554) Additional built-in beans do not have a scope defined In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13166211#comment-13166211 ] Martin Kouba commented on CDI-554: ---------------------------------- I'm not so sure this clarification is needed any longer. From the user point of view, it doesn't seem to be necessary. > Additional built-in beans do not have a scope defined > ----------------------------------------------------- > > Key: CDI-554 > URL: https://issues.jboss.org/browse/CDI-554 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final, 2.0-EDR1 > Reporter: Martin Kouba > > See section 17.8. Additional built-in beans - a scope is not defined for UserTransaction, Principal, HttpServletRequest, etc. Maybe it's defined somewhere else but I cannot find anything. > In Weld, Java EE beans are {{@Dependent}}, HttpServletRequest and ServletContext are {{@RequestScoped}} and HttpSession is {{@SessionScoped}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Feb 22 07:33:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Mon, 22 Feb 2016 07:33:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-554) Additional built-in beans do not have a scope defined In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13166277#comment-13166277 ] John Ament commented on CDI-554: -------------------------------- Just one comment. ServletContext should probably be app scoped, no? https://docs.oracle.com/javaee/6/api/javax/servlet/ServletContext.html It provides access to the runtime, not any specific request. > Additional built-in beans do not have a scope defined > ----------------------------------------------------- > > Key: CDI-554 > URL: https://issues.jboss.org/browse/CDI-554 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final, 2.0-EDR1 > Reporter: Martin Kouba > > See section 17.8. Additional built-in beans - a scope is not defined for UserTransaction, Principal, HttpServletRequest, etc. Maybe it's defined somewhere else but I cannot find anything. > In Weld, Java EE beans are {{@Dependent}}, HttpServletRequest and ServletContext are {{@RequestScoped}} and HttpSession is {{@SessionScoped}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Feb 22 09:29:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 22 Feb 2016 09:29:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-554) Additional built-in beans do not have a scope defined In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13166373#comment-13166373 ] Martin Kouba commented on CDI-554: ---------------------------------- Yes, John {{@ApplicationScoped}} could be a better match for ServletContext. AFAIR there some problems with EAR deployments in Weld (see also WELD-1621). But it should be possible to identify the correct ServletContext by means of TCCL. In any case, it's not defined at the moment and in Weld the ServletContext is only available during HTTP request processing. > Additional built-in beans do not have a scope defined > ----------------------------------------------------- > > Key: CDI-554 > URL: https://issues.jboss.org/browse/CDI-554 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final, 2.0-EDR1 > Reporter: Martin Kouba > > See section 17.8. Additional built-in beans - a scope is not defined for UserTransaction, Principal, HttpServletRequest, etc. Maybe it's defined somewhere else but I cannot find anything. > In Weld, Java EE beans are {{@Dependent}}, HttpServletRequest and ServletContext are {{@RequestScoped}} and HttpSession is {{@SessionScoped}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Feb 22 09:49:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 22 Feb 2016 09:49:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-554) Additional built-in beans do not have a scope defined In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13166373#comment-13166373 ] Martin Kouba edited comment on CDI-554 at 2/22/16 9:48 AM: ----------------------------------------------------------- Yes, John {{@ApplicationScoped}} could be a better match for ServletContext. AFAIR there some problems with EAR deployments in Weld (see also WELD-1621). But it should be possible to identify the correct ServletContext by means of TCCL. In any case, it's not defined at the moment and in Weld the ServletContext is only available when the request scope is active (servlet {{service()}} invocation, {{@PostConstruct}} callback, etc.). was (Author: mkouba): Yes, John {{@ApplicationScoped}} could be a better match for ServletContext. AFAIR there some problems with EAR deployments in Weld (see also WELD-1621). But it should be possible to identify the correct ServletContext by means of TCCL. In any case, it's not defined at the moment and in Weld the ServletContext is only available during HTTP request processing. > Additional built-in beans do not have a scope defined > ----------------------------------------------------- > > Key: CDI-554 > URL: https://issues.jboss.org/browse/CDI-554 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final, 2.0-EDR1 > Reporter: Martin Kouba > > See section 17.8. Additional built-in beans - a scope is not defined for UserTransaction, Principal, HttpServletRequest, etc. Maybe it's defined somewhere else but I cannot find anything. > In Weld, Java EE beans are {{@Dependent}}, HttpServletRequest and ServletContext are {{@RequestScoped}} and HttpSession is {{@SessionScoped}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From Reza.Rahman at oracle.com Mon Feb 22 17:06:41 2016 From: Reza.Rahman at oracle.com (Reza Rahman) Date: Mon, 22 Feb 2016 17:06:41 -0500 Subject: [cdi-dev] Concurrency Control In-Reply-To: References: Message-ID: <56CB8671.8090408@oracle.com> We've discussed this issue before. I definitely still think @Lock belongs in a modular CDI specification. It would be highly useful to both @Singleton and @ApplicationScoped. Today if I need to use declarative concurrency control for a shared component I am essentially forced to use EJB singleton - which shouldn't be the case and perhaps should not have been the case past Java EE 6. On 2/19/2016 5:27 AM, Stephan Knitelius wrote: > Hi all, > > CDI spec does not define a common concurrency control mechanism. The > time any type of concurrency control is mentioned is in conjunction > with EJB and a rather restrictive one for conversation context. > > CDI Spec: > The container ensures that a long-running conversation may be > associated with at most one request at a time, by blocking or > rejecting concurrent requests. If the container rejects a request, it > must associate the request with a new transient conversation and throw > an exception of type|javax.enterprise.context.BusyConversationException|. > > > It would be helpful if a common configurable concurrency mechanism > (EJB Singleton style locking?) could be established for all normal > scopes. > > What are your thoughts on this? > > Regards, > > Stephan > > > > > > > > > > > ______________________________________ > *Stephan Knitelius* > Alteburger Str. 274 > 50968 K?ln / Cologne > Deutschland / Germany > stephan at knitelius.com > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160222/d0725442/attachment-0001.html From mkouba at redhat.com Tue Feb 23 03:14:46 2016 From: mkouba at redhat.com (Martin Kouba) Date: Tue, 23 Feb 2016 09:14:46 +0100 Subject: [cdi-dev] Type variable check for Event.select() and Event.fire() Message-ID: <56CC14F6.8050001@redhat.com> Hi all, I'd like to discuss the following two sentences taken from "10.2.1. The Event interface"). 1. Event.select() "If the specified type contains a type variable, an IllegalArgumentException is thrown." So what should happen if you pass a raw type like List.class? The Class.getTypeParameters() method returns [E]. Does it mean the type contains a type variable? And what about "event.select(new TypeLiteral>() {})"? 2. Event.fire() "If the runtime type of the event object contains an unresolvable type variable, an IllegalArgumentException is thrown." To my understanding: 1. the runtime type = eventPayload.getClass() 2. get type variables = getTypeParameters() 3. unresolvable = it's not possible to resolve the variable, nor from the Event injetion point nor from the selected type (Event.select()), anything else? 3. Example snippet Should the following snippet fail or not? It currently fails in Weld during event.select(). But even if we relax the check it will not be always possible to resolve all the type variables, i.e. the subsequent {{fire()}} invocation might fail. Or am I missing anything? @Inject Event event; public void testSelectSubtypeWithWildcard() { List updatedList = new ArrayList<>(); updatedList.add("foo"); Event> child = event.select(new TypeLiteral>() {}); child.fire(updatedList); } Thanks, Martin From antoine at sabot-durand.net Tue Feb 23 03:51:00 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 23 Feb 2016 08:51:00 +0000 Subject: [cdi-dev] Canceling meeting today Message-ID: Hi guys, I'm sick and won't be able to attend our meeting today. See you, Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160223/6bdcea02/attachment.html From manovotn at redhat.com Tue Feb 23 10:05:38 2016 From: manovotn at redhat.com (Matej Novotny) Date: Tue, 23 Feb 2016 10:05:38 -0500 (EST) Subject: [cdi-dev] Type variable check for Event.select() and Event.fire() In-Reply-To: <56CC14F6.8050001@redhat.com> References: <56CC14F6.8050001@redhat.com> Message-ID: <450463523.21357897.1456239938234.JavaMail.zimbra@redhat.com> Hi, tossing my 0.02$ in. I believe that anything you cannot boil down to a specific class during type var. resolution should result in exception. E.g. regarding your questions: > 1. Event.select() > ... if you pass a raw type like List.class? Type variable, as in any other case where you have a MyClass. As long as you do not define T, you have a type variable in place. >"event.select(new TypeLiteral>() {})" Same scenario I think. I probably fail to see any real difference here? (correct me please ;) > 2. Event.fire() > To my understanding:... My understanding is the same. Actually this brings it down to the very same problem as in Event.select(), on requirement on type variable are pretty much the same for select() and fire(). > 3. Example snippet IMHO the snippet SHOULD FAIL as soon as it hits select() method. Relaxing the conditions on select() doesn't make much sense to me for it should fail with the very same problem on fire(), right? BTW I am curious, what would the above snippet do in OWB? One more note: Be it one way or the other, the terms "to contain a type variable" and "unresolvable type variable" could use a clarification in the spec. Matej ----- Original Message ----- From: "Martin Kouba" To: "cdi-dev" Sent: Tuesday, February 23, 2016 9:14:46 AM Subject: [cdi-dev] Type variable check for Event.select() and Event.fire() Hi all, I'd like to discuss the following two sentences taken from "10.2.1. The Event interface"). 1. Event.select() "If the specified type contains a type variable, an IllegalArgumentException is thrown." So what should happen if you pass a raw type like List.class? The Class.getTypeParameters() method returns [E]. Does it mean the type contains a type variable? And what about "event.select(new TypeLiteral>() {})"? 2. Event.fire() "If the runtime type of the event object contains an unresolvable type variable, an IllegalArgumentException is thrown." To my understanding: 1. the runtime type = eventPayload.getClass() 2. get type variables = getTypeParameters() 3. unresolvable = it's not possible to resolve the variable, nor from the Event injetion point nor from the selected type (Event.select()), anything else? 3. Example snippet Should the following snippet fail or not? It currently fails in Weld during event.select(). But even if we relax the check it will not be always possible to resolve all the type variables, i.e. the subsequent {{fire()}} invocation might fail. Or am I missing anything? @Inject Event event; public void testSelectSubtypeWithWildcard() { List updatedList = new ArrayList<>(); updatedList.add("foo"); Event> child = event.select(new TypeLiteral>() {}); child.fire(updatedList); } Thanks, Martin _______________________________________________ cdi-dev mailing list cdi-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From stephan at knitelius.com Wed Feb 24 14:47:19 2016 From: stephan at knitelius.com (Stephan Knitelius) Date: Wed, 24 Feb 2016 19:47:19 +0000 Subject: [cdi-dev] Concurrency Control In-Reply-To: <56CB8671.8090408@oracle.com> References: <56CB8671.8090408@oracle.com> Message-ID: I just want to bring this to everyone attention one more time. The conversation scope concurrency control mechanism seems to be a frequent point of pain in many projects. Especially when working with browser triggered asynchronous requests, you can not rely on client-sided request synchronization. Weld, unlike OWB, grants a 1 second timeout prior to throwing a (the specified) BusyConversationException mitigating the effect a bit. This is a rather strict un-configurable type of CC. Also its completely out of alignment with the other build-in scopes, offering no CC what so ever. In the cases of Session- and Application-Scope, thread handling is left entirely to the developer, even so they are just as vulnerable in AJAX environments. We should really consider introducing a common configurable mechanism, that is aligned across all scopes (obviously accounting for backwards compatibility in the case of conversation scope). Would really appreciate some feedback. Kind regards, Stephan On Mon, 22 Feb 2016 at 23:10 Reza Rahman wrote: > We've discussed this issue before. I definitely still think @Lock belongs > in a modular CDI specification. It would be highly useful to both > @Singleton and @ApplicationScoped. Today if I need to use declarative > concurrency control for a shared component I am essentially forced to use > EJB singleton - which shouldn't be the case and perhaps should not have > been the case past Java EE 6. > > > On 2/19/2016 5:27 AM, Stephan Knitelius wrote: > > Hi all, > > CDI spec does not define a common concurrency control mechanism. The time > any type of concurrency control is mentioned is in conjunction with EJB and > a rather restrictive one for conversation context. > > CDI Spec: > The container ensures that a long-running conversation may be associated > with at most one request at a time, by blocking or rejecting concurrent > requests. If the container rejects a request, it must associate the request > with a new transient conversation and throw an exception of type > javax.enterprise.context.BusyConversationException. > > > It would be helpful if a common configurable concurrency mechanism (EJB > Singleton style locking?) could be established for all normal scopes. > > What are your thoughts on this? > > Regards, > > Stephan > > > > > > > > > > > > ______________________________________ > *Stephan Knitelius* > Alteburger Str. 274 > 50968 K?ln / Cologne > Deutschland / Germany > stephan at knitelius.com > > > _______________________________________________ > 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/20160224/8853889c/attachment.html From mkouba at redhat.com Thu Feb 25 05:30:44 2016 From: mkouba at redhat.com (Martin Kouba) Date: Thu, 25 Feb 2016 11:30:44 +0100 Subject: [cdi-dev] Is a wildcard type an unresolved type variable or not Message-ID: <56CED7D4.1020403@redhat.com> Hi all, This follows up on my last message to cdi-dev: "Type variable check for Event.select() and Event.fire()". After I spend some time searching I have to rephrase the question: Should a wildcard type be considered an unresolved type variable or not? Of course, in the scope of events. I believe the spec is not clear here. See also "10.1. Event types and qualifier types" and "10.2.1. The Event interface". There is CDI-494 which assumes a wildcard type _is_ an unresolved type variable [1]. From the TCK point of view - there is only FireEventTest.testTypeVariableEventTypeFails() which assumes that a type variable resolved to a wildcard (inferred from the Event injection point) is unresolvable - see also CDITCK-510 [2]. Note that in CDI 1.0 the container cannot use the Event specified type to infer the parameterized type. The current behavior ==================== Weld 1 allows to pass a wildcard to Event.select() but Event.fire() is problematic (e.g. the snippet [3] does fail). Weld 2+ is imho overly strict here and throws IllegalArgumentException whenever a type variable is resolved to a wildcard type (Event.select(), Event.fire()). The latest OWB seems to support this, but it does not always infer the parameterized type consistently (e.g. the TCK test mentioned above is passing even if it's possible to resolve the type variable to the wildcard type). Clarification ============= I'm no expert on generics but I think we shouldn't treat wildcard types as unresolved type variables, i.e. reject CDI-494 and clarify the snippet [3] and similar should work. At least I cannot see any problem. But maybe I'm missing somethig. Thanks for feedback, Martin [1] https://issues.jboss.org/browse/CDI-494 [2] https://issues.jboss.org/browse/CDITCK-510 [3] @Inject Event event; public void testSelectSubtypeWithWildcard() { List updatedList = new ArrayList<>(); updatedList.add("foo"); Event> child = event.select(new TypeLiteral>() {}); child.fire(updatedList); } From mkouba at redhat.com Thu Feb 25 09:13:39 2016 From: mkouba at redhat.com (Martin Kouba) Date: Thu, 25 Feb 2016 15:13:39 +0100 Subject: [cdi-dev] Concurrency Control In-Reply-To: References: <56CB8671.8090408@oracle.com> Message-ID: <56CF0C13.4030306@redhat.com> Hi Stephan, I like the idea of CDI interceptor solution you're proposing in your blogpost [1]. However, concurrency is a difficult topic. First of all, this only solves concurrent access to the bean instance (i.e. method-level locking) - the bean state is always up to the user. Also I'm not so sure it's a good idea to only apply @Lock at the method level (some methods are guarded some not - AFAIK EJB does not allow this either). I agree that conversation concurrentAccessTimeout in Weld should be configurable. In fact, it should be possible to change this timeout even now using Weld API and org.jboss.weld.context.ConversationContext. But it should be definitely more straightforward [2]. To sum it up - I wouldn't add concurrency control to the spec provided it's implementable using interceptors. This is a similar situation as to javax.transaction.Transactional and JTA. The best place to specify this is IMHO "Concurrency Utilities for Java EE". Martin [1] http://www.knitelius.com/2016/01/25/concurrency-control-for-cdi/ [2] https://issues.jboss.org/browse/WELD-2113 Dne 24.2.2016 v 20:47 Stephan Knitelius napsal(a): > I just want to bring this to everyone attention one more time. > > The conversation scope concurrency control mechanism seems to be a > frequent point of pain in many projects. > > Especially when working with browser triggered asynchronous requests, > you can not rely on client-sided request synchronization. > Weld, unlike OWB, grants a 1 second timeout prior to throwing a (the > specified) BusyConversationException mitigating the effect a bit. > > This is a rather strict un-configurable type of CC. Also its > completely out of alignment with the other build-in scopes, offering no > CC what so ever. > > In the cases of Session- and Application-Scope, thread handling is left > entirely to the developer, even so they are just as vulnerable in AJAX > environments. > > We should really consider introducing a common configurable mechanism, > that is aligned across all scopes (obviously accounting for backwards > compatibility in the case of conversation scope). > > Would really appreciate some feedback. > > Kind regards, > > Stephan > > > > > On Mon, 22 Feb 2016 at 23:10 Reza Rahman > wrote: > > We've discussed this issue before. I definitely still think @Lock > belongs in a modular CDI specification. It would be highly useful to > both @Singleton and @ApplicationScoped. Today if I need to use > declarative concurrency control for a shared component I am > essentially forced to use EJB singleton - which shouldn't be the > case and perhaps should not have been the case past Java EE 6. > > > On 2/19/2016 5:27 AM, Stephan Knitelius wrote: >> Hi all, >> >> CDI spec does not define a common concurrency control mechanism. >> The time any type of concurrency control is mentioned is in >> conjunction with EJB and a rather restrictive one for conversation >> context. >> >> CDI Spec: >> The container ensures that a long-running conversation may be >> associated with at most one request at a time, by blocking or >> rejecting concurrent requests. If the container rejects a request, >> it must associate the request with a new transient conversation >> and throw an exception of >> type|javax.enterprise.context.BusyConversationException|. >> >> >> It would be helpful if a common configurable concurrency mechanism >> (EJB Singleton style locking?) could be established for all normal >> scopes. >> >> What are your thoughts on this? >> >> Regards, >> >> Stephan >> >> >> >> >> >> >> >> >> >> >> ______________________________________ >> *Stephan Knitelius* >> Alteburger Str. 274 >> 50968 K?ln / Cologne >> Deutschland / Germany >> stephan at knitelius.com >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > ideas provided on this list, the provider waives all patent and > other intellectual property rights inherent in such information. > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > -- Martin Kouba Software Engineer Red Hat, Czech Republic From reza_rahman at lycos.com Thu Feb 25 09:50:21 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Thu, 25 Feb 2016 09:50:21 -0500 Subject: [cdi-dev] Concurrency Control In-Reply-To: <56CF0C13.4030306@redhat.com> References: <56CB8671.8090408@oracle.com> <56CF0C13.4030306@redhat.com> Message-ID: <44E77DCE-3217-4E6C-B361-C1409F6D20BE@lycos.com> Oracle has pretty much clearly stated it has absolutely no intention of updating the Java EE Concurrency Utilities specification any time soon. My guess is that it will also never allow anyone else to update it either since it owns that specification. If this is a valuable feature to the community (which I definitely think it is) I strongly suggest taking advantage of the fact that this is a gray area and include it in a modular CDI specification so this feature doesn't continue to remain locked into EJB for Java EE users that need to more effectively use things like @Stereotype for service composition. > On Feb 25, 2016, at 9:13 AM, Martin Kouba wrote: > > Hi Stephan, > > I like the idea of CDI interceptor solution you're proposing in your > blogpost [1]. However, concurrency is a difficult topic. First of all, > this only solves concurrent access to the bean instance (i.e. > method-level locking) - the bean state is always up to the user. Also > I'm not so sure it's a good idea to only apply @Lock at the method level > (some methods are guarded some not - AFAIK EJB does not allow this either). > > I agree that conversation concurrentAccessTimeout in Weld should be > configurable. In fact, it should be possible to change this timeout even > now using Weld API and org.jboss.weld.context.ConversationContext. But > it should be definitely more straightforward [2]. > > To sum it up - I wouldn't add concurrency control to the spec provided > it's implementable using interceptors. This is a similar situation as to > javax.transaction.Transactional and JTA. The best place to specify this > is IMHO "Concurrency Utilities for Java EE". > > Martin > > [1] > http://www.knitelius.com/2016/01/25/concurrency-control-for-cdi/ > > [2] > https://issues.jboss.org/browse/WELD-2113 > > Dne 24.2.2016 v 20:47 Stephan Knitelius napsal(a): >> I just want to bring this to everyone attention one more time. >> >> The conversation scope concurrency control mechanism seems to be a >> frequent point of pain in many projects. >> >> Especially when working with browser triggered asynchronous requests, >> you can not rely on client-sided request synchronization. >> Weld, unlike OWB, grants a 1 second timeout prior to throwing a (the >> specified) BusyConversationException mitigating the effect a bit. >> >> This is a rather strict un-configurable type of CC. Also its >> completely out of alignment with the other build-in scopes, offering no >> CC what so ever. >> >> In the cases of Session- and Application-Scope, thread handling is left >> entirely to the developer, even so they are just as vulnerable in AJAX >> environments. >> >> We should really consider introducing a common configurable mechanism, >> that is aligned across all scopes (obviously accounting for backwards >> compatibility in the case of conversation scope). >> >> Would really appreciate some feedback. >> >> Kind regards, >> >> Stephan >> >> >> >> >> On Mon, 22 Feb 2016 at 23:10 Reza Rahman > > wrote: >> >> We've discussed this issue before. I definitely still think @Lock >> belongs in a modular CDI specification. It would be highly useful to >> both @Singleton and @ApplicationScoped. Today if I need to use >> declarative concurrency control for a shared component I am >> essentially forced to use EJB singleton - which shouldn't be the >> case and perhaps should not have been the case past Java EE 6. >> >> >>> On 2/19/2016 5:27 AM, Stephan Knitelius wrote: >>> Hi all, >>> >>> CDI spec does not define a common concurrency control mechanism. >>> The time any type of concurrency control is mentioned is in >>> conjunction with EJB and a rather restrictive one for conversation >>> context. >>> >>> CDI Spec: >>> The container ensures that a long-running conversation may be >>> associated with at most one request at a time, by blocking or >>> rejecting concurrent requests. If the container rejects a request, >>> it must associate the request with a new transient conversation >>> and throw an exception of >>> type|javax.enterprise.context.BusyConversationException|. >>> >>> >>> It would be helpful if a common configurable concurrency mechanism >>> (EJB Singleton style locking?) could be established for all normal >>> scopes. >>> >>> What are your thoughts on this? >>> >>> Regards, >>> >>> Stephan >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> ______________________________________ >>> *Stephan Knitelius* >>> Alteburger Str. 274 >>> 50968 K?ln / Cologne >>> Deutschland / Germany >>> stephan at knitelius.com >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses >> the code under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >> ideas provided on this list, the provider waives all patent and >> other intellectual property rights inherent in such information. >> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From stephan at knitelius.com Thu Feb 25 15:24:24 2016 From: stephan at knitelius.com (Stephan Knitelius) Date: Thu, 25 Feb 2016 20:24:24 +0000 Subject: [cdi-dev] Concurrency Control In-Reply-To: <44E77DCE-3217-4E6C-B361-C1409F6D20BE@lycos.com> References: <56CB8671.8090408@oracle.com> <56CF0C13.4030306@redhat.com> <44E77DCE-3217-4E6C-B361-C1409F6D20BE@lycos.com> Message-ID: Hi Martin, yes this particular issue is about concurrent access control. You are right in pointing out that the lock should be applied to the whole been and only override-able on a per method basis (similar to EJB Singleton style locking). Regarding conversation context, its fair enough to point-out that weld allows for configure the conversation lock timeout. However this is only true for Weld, this should really be made part of the specification. Even if we were to specify a standard way to configure conversation locked timeouts in the CDI specification, it would still make the conversation scope the odd one out of the lot. Hence it would be more sensible to design a common way to handle concurrent access. Also I would argue that you cannot implement a common concurrent access control via interceptors, since the container will preempt any interceptor based attempt for conversation scoped beans. As Reza pointed out Oracle has no intend to reopen "Concurrency Utilities for Java EE" at this time and is not willing to hand it over to anyone else. The same seems to be true for JTA. Stephan On Thu, 25 Feb 2016 at 15:50 Reza Rahman wrote: > Oracle has pretty much clearly stated it has absolutely no intention of > updating the Java EE Concurrency Utilities specification any time soon. My > guess is that it will also never allow anyone else to update it either > since it owns that specification. If this is a valuable feature to the > community (which I definitely think it is) I strongly suggest taking > advantage of the fact that this is a gray area and include it in a modular > CDI specification so this feature doesn't continue to remain locked into > EJB for Java EE users that need to more effectively use things like > @Stereotype for service composition. > > > On Feb 25, 2016, at 9:13 AM, Martin Kouba wrote: > > > > Hi Stephan, > > > > I like the idea of CDI interceptor solution you're proposing in your > > blogpost [1]. However, concurrency is a difficult topic. First of all, > > this only solves concurrent access to the bean instance (i.e. > > method-level locking) - the bean state is always up to the user. Also > > I'm not so sure it's a good idea to only apply @Lock at the method level > > (some methods are guarded some not - AFAIK EJB does not allow this > either). > > > > I agree that conversation concurrentAccessTimeout in Weld should be > > configurable. In fact, it should be possible to change this timeout even > > now using Weld API and org.jboss.weld.context.ConversationContext. But > > it should be definitely more straightforward [2]. > > > > To sum it up - I wouldn't add concurrency control to the spec provided > > it's implementable using interceptors. This is a similar situation as to > > javax.transaction.Transactional and JTA. The best place to specify this > > is IMHO "Concurrency Utilities for Java EE". > > > > Martin > > > > [1] > > http://www.knitelius.com/2016/01/25/concurrency-control-for-cdi/ > > > > [2] > > https://issues.jboss.org/browse/WELD-2113 > > > > Dne 24.2.2016 v 20:47 Stephan Knitelius napsal(a): > >> I just want to bring this to everyone attention one more time. > >> > >> The conversation scope concurrency control mechanism seems to be a > >> frequent point of pain in many projects. > >> > >> Especially when working with browser triggered asynchronous requests, > >> you can not rely on client-sided request synchronization. > >> Weld, unlike OWB, grants a 1 second timeout prior to throwing a (the > >> specified) BusyConversationException mitigating the effect a bit. > >> > >> This is a rather strict un-configurable type of CC. Also its > >> completely out of alignment with the other build-in scopes, offering no > >> CC what so ever. > >> > >> In the cases of Session- and Application-Scope, thread handling is left > >> entirely to the developer, even so they are just as vulnerable in AJAX > >> environments. > >> > >> We should really consider introducing a common configurable mechanism, > >> that is aligned across all scopes (obviously accounting for backwards > >> compatibility in the case of conversation scope). > >> > >> Would really appreciate some feedback. > >> > >> Kind regards, > >> > >> Stephan > >> > >> > >> > >> > >> On Mon, 22 Feb 2016 at 23:10 Reza Rahman >> > wrote: > >> > >> We've discussed this issue before. I definitely still think @Lock > >> belongs in a modular CDI specification. It would be highly useful to > >> both @Singleton and @ApplicationScoped. Today if I need to use > >> declarative concurrency control for a shared component I am > >> essentially forced to use EJB singleton - which shouldn't be the > >> case and perhaps should not have been the case past Java EE 6. > >> > >> > >>> On 2/19/2016 5:27 AM, Stephan Knitelius wrote: > >>> Hi all, > >>> > >>> CDI spec does not define a common concurrency control mechanism. > >>> The time any type of concurrency control is mentioned is in > >>> conjunction with EJB and a rather restrictive one for conversation > >>> context. > >>> > >>> CDI Spec: > >>> The container ensures that a long-running conversation may be > >>> associated with at most one request at a time, by blocking or > >>> rejecting concurrent requests. If the container rejects a request, > >>> it must associate the request with a new transient conversation > >>> and throw an exception of > >>> type|javax.enterprise.context.BusyConversationException|. > >>> > >>> > >>> It would be helpful if a common configurable concurrency mechanism > >>> (EJB Singleton style locking?) could be established for all normal > >>> scopes. > >>> > >>> What are your thoughts on this? > >>> > >>> Regards, > >>> > >>> Stephan > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> ______________________________________ > >>> *Stephan Knitelius* > >>> Alteburger Str. 274 > >>> 50968 K?ln / Cologne > >>> Deutschland / Germany > >>> stephan at knitelius.com > >>> > >>> > >>> _______________________________________________ > >>> cdi-dev mailing list > >>> cdi-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>> > >>> Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> Note that for all code provided on this list, the provider licenses > >> the code under the Apache License, Version 2 > >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > >> ideas provided on this list, the provider waives all patent and > >> other intellectual property rights inherent in such information. > >> > >> > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > > -- > > Martin Kouba > > Software Engineer > > Red Hat, Czech Republic > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160225/ad70bf31/attachment-0001.html From EMIJIANG at uk.ibm.com Thu Feb 25 16:18:13 2016 From: EMIJIANG at uk.ibm.com (Emily Jiang) Date: Thu, 25 Feb 2016 21:18:13 +0000 Subject: [cdi-dev] Concurrency Control In-Reply-To: References: <56CB8671.8090408@oracle.com> <56CF0C13.4030306@redhat.com> <44E77DCE-3217-4E6C-B361-C1409F6D20BE@lycos.com> Message-ID: <201602252118.u1PLIIM6022868@d06av01.portsmouth.uk.ibm.com> It would be nice if JavaEE Concurrency defines @Lock as a CDI interceptor, similar to @Transactional . Since the JavaEE Concurrency spec is stale as per you and Raze point out, how about experiment in DeltaSpike? If DeltaSpike provides the support of @Lock, maybe it can be pushed to JavaEE concurrency as part of EE8 update. If not, maybe CDI should define an addendum for EE integration. I think we should seriously think about this. Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB From: Stephan Knitelius To: Reza Rahman , Martin Kouba , Cc: cdi-dev at lists.jboss.org Date: 25/02/2016 20:26 Subject: Re: [cdi-dev] Concurrency Control Sent by: cdi-dev-bounces at lists.jboss.org Hi Martin, yes this particular issue is about concurrent access control. You are right in pointing out that the lock should be applied to the whole been and only override-able on a per method basis (similar to EJB Singleton style locking). Regarding conversation context, its fair enough to point-out that weld allows for configure the conversation lock timeout. However this is only true for Weld, this should really be made part of the specification. Even if we were to specify a standard way to configure conversation locked timeouts in the CDI specification, it would still make the conversation scope the odd one out of the lot. Hence it would be more sensible to design a common way to handle concurrent access. Also I would argue that you cannot implement a common concurrent access control via interceptors, since the container will preempt any interceptor based attempt for conversation scoped beans. As Reza pointed out Oracle has no intend to reopen "Concurrency Utilities for Java EE" at this time and is not willing to hand it over to anyone else. The same seems to be true for JTA. Stephan On Thu, 25 Feb 2016 at 15:50 Reza Rahman wrote: Oracle has pretty much clearly stated it has absolutely no intention of updating the Java EE Concurrency Utilities specification any time soon. My guess is that it will also never allow anyone else to update it either since it owns that specification. If this is a valuable feature to the community (which I definitely think it is) I strongly suggest taking advantage of the fact that this is a gray area and include it in a modular CDI specification so this feature doesn't continue to remain locked into EJB for Java EE users that need to more effectively use things like @Stereotype for service composition. > On Feb 25, 2016, at 9:13 AM, Martin Kouba wrote: > > Hi Stephan, > > I like the idea of CDI interceptor solution you're proposing in your > blogpost [1]. However, concurrency is a difficult topic. First of all, > this only solves concurrent access to the bean instance (i.e. > method-level locking) - the bean state is always up to the user. Also > I'm not so sure it's a good idea to only apply @Lock at the method level > (some methods are guarded some not - AFAIK EJB does not allow this either). > > I agree that conversation concurrentAccessTimeout in Weld should be > configurable. In fact, it should be possible to change this timeout even > now using Weld API and org.jboss.weld.context.ConversationContext. But > it should be definitely more straightforward [2]. > > To sum it up - I wouldn't add concurrency control to the spec provided > it's implementable using interceptors. This is a similar situation as to > javax.transaction.Transactional and JTA. The best place to specify this > is IMHO "Concurrency Utilities for Java EE". > > Martin > > [1] > http://www.knitelius.com/2016/01/25/concurrency-control-for-cdi/ > > [2] > https://issues.jboss.org/browse/WELD-2113 > > Dne 24.2.2016 v 20:47 Stephan Knitelius napsal(a): >> I just want to bring this to everyone attention one more time. >> >> The conversation scope concurrency control mechanism seems to be a >> frequent point of pain in many projects. >> >> Especially when working with browser triggered asynchronous requests, >> you can not rely on client-sided request synchronization. >> Weld, unlike OWB, grants a 1 second timeout prior to throwing a (the >> specified) BusyConversationException mitigating the effect a bit. >> >> This is a rather strict un-configurable type of CC. Also its >> completely out of alignment with the other build-in scopes, offering no >> CC what so ever. >> >> In the cases of Session- and Application-Scope, thread handling is left >> entirely to the developer, even so they are just as vulnerable in AJAX >> environments. >> >> We should really consider introducing a common configurable mechanism, >> that is aligned across all scopes (obviously accounting for backwards >> compatibility in the case of conversation scope). >> >> Would really appreciate some feedback. >> >> Kind regards, >> >> Stephan >> >> >> >> >> On Mon, 22 Feb 2016 at 23:10 Reza Rahman > > wrote: >> >> We've discussed this issue before. I definitely still think @Lock >> belongs in a modular CDI specification. It would be highly useful to >> both @Singleton and @ApplicationScoped. Today if I need to use >> declarative concurrency control for a shared component I am >> essentially forced to use EJB singleton - which shouldn't be the >> case and perhaps should not have been the case past Java EE 6. >> >> >>> On 2/19/2016 5:27 AM, Stephan Knitelius wrote: >>> Hi all, >>> >>> CDI spec does not define a common concurrency control mechanism. >>> The time any type of concurrency control is mentioned is in >>> conjunction with EJB and a rather restrictive one for conversation >>> context. >>> >>> CDI Spec: >>> The container ensures that a long-running conversation may be >>> associated with at most one request at a time, by blocking or >>> rejecting concurrent requests. If the container rejects a request, >>> it must associate the request with a new transient conversation >>> and throw an exception of >>> type|javax.enterprise.context.BusyConversationException|. >>> >>> >>> It would be helpful if a common configurable concurrency mechanism >>> (EJB Singleton style locking?) could be established for all normal >>> scopes. >>> >>> What are your thoughts on this? >>> >>> Regards, >>> >>> Stephan >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> ______________________________________ >>> *Stephan Knitelius* >>> Alteburger Str. 274 >>> 50968 K?ln / Cologne >>> Deutschland / Germany >>> stephan at knitelius.com >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses >> the code under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >> ideas provided on this list, the provider waives all patent and >> other intellectual property rights inherent in such information. >> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. _______________________________________________ cdi-dev mailing list cdi-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160225/2ed65670/attachment-0001.html From reza_rahman at lycos.com Thu Feb 25 17:59:20 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Thu, 25 Feb 2016 17:59:20 -0500 Subject: [cdi-dev] Concurrency Control In-Reply-To: <201602252118.u1PLII2l029792@d06av08.portsmouth.uk.ibm.com> References: <56CB8671.8090408@oracle.com> <56CF0C13.4030306@redhat.com> <44E77DCE-3217-4E6C-B361-C1409F6D20BE@lycos.com> <201602252118.u1PLII2l029792@d06av08.portsmouth.uk.ibm.com> Message-ID: <71608FF8-5AE5-417E-A7D2-CE9DF3BF84A5@lycos.com> This is not just a problem with this one feature but a much broader one involving @Asynchronous, @Schedule and many others. Simply punting on this problem and not dealing with this class of problems vigorously is rather foolish. It winds up doing what it has done for years - undermining pretty much all efforts related to Java EE, especially compared to the velocity and effectiveness by which the clear competitors to everything Java EE solve these issues. In the end, we are collectively to blame for the dismal state of affairs in Java EE land because of this sort of thing. > On Feb 25, 2016, at 4:18 PM, Emily Jiang wrote: > > It would be nice if JavaEE Concurrency defines @Lock as a CDI interceptor, similar to @Transactional . Since the JavaEE Concurrency spec is stale as per you and Raze point out, how about experiment in DeltaSpike? If DeltaSpike provides the support of @Lock, maybe it can be pushed to JavaEE concurrency as part of EE8 update. If not, maybe CDI should define an addendum for EE integration. I think we should seriously think about this. > > > > Many thanks, > Emily > =========================== > Emily Jiang > WebSphere Application Server, CDI Development Lead > > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN > Phone: +44 (0)1962 816278 Internal: 246278 > > Email: emijiang at uk.ibm.com > Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > > > > From: Stephan Knitelius > To: Reza Rahman , Martin Kouba , > Cc: cdi-dev at lists.jboss.org > Date: 25/02/2016 20:26 > Subject: Re: [cdi-dev] Concurrency Control > Sent by: cdi-dev-bounces at lists.jboss.org > > > > Hi Martin, > > yes this particular issue is about concurrent access control. You are right in pointing out that the lock should be applied > to the whole been and only override-able on a per method basis (similar to EJB Singleton style locking). > > Regarding conversation context, its fair enough to point-out that weld allows for configure the conversation lock timeout. > However this is only true for Weld, this should really be made part of the specification. > > Even if we were to specify a standard way to configure conversation locked timeouts in the CDI specification, it would > still make the conversation scope the odd one out of the lot. Hence it would be more sensible to design a > common way to handle concurrent access. > > Also I would argue that you cannot implement a common concurrent access control via interceptors, > since the container will preempt any interceptor based attempt for conversation scoped beans. > > As Reza pointed out Oracle has no intend to reopen "Concurrency Utilities for Java EE" at this time and is not > willing to hand it over to anyone else. The same seems to be true for JTA. > > Stephan > > > > > > > > > > > > > > > > > > > On Thu, 25 Feb 2016 at 15:50 Reza Rahman wrote: > Oracle has pretty much clearly stated it has absolutely no intention of updating the Java EE Concurrency Utilities specification any time soon. My guess is that it will also never allow anyone else to update it either since it owns that specification. If this is a valuable feature to the community (which I definitely think it is) I strongly suggest taking advantage of the fact that this is a gray area and include it in a modular CDI specification so this feature doesn't continue to remain locked into EJB for Java EE users that need to more effectively use things like @Stereotype for service composition. > > > On Feb 25, 2016, at 9:13 AM, Martin Kouba wrote: > > > > Hi Stephan, > > > > I like the idea of CDI interceptor solution you're proposing in your > > blogpost [1]. However, concurrency is a difficult topic. First of all, > > this only solves concurrent access to the bean instance (i.e. > > method-level locking) - the bean state is always up to the user. Also > > I'm not so sure it's a good idea to only apply @Lock at the method level > > (some methods are guarded some not - AFAIK EJB does not allow this either). > > > > I agree that conversation concurrentAccessTimeout in Weld should be > > configurable. In fact, it should be possible to change this timeout even > > now using Weld API and org.jboss.weld.context.ConversationContext. But > > it should be definitely more straightforward [2]. > > > > To sum it up - I wouldn't add concurrency control to the spec provided > > it's implementable using interceptors. This is a similar situation as to > > javax.transaction.Transactional and JTA. The best place to specify this > > is IMHO "Concurrency Utilities for Java EE". > > > > Martin > > > > [1] > > http://www.knitelius.com/2016/01/25/concurrency-control-for-cdi/ > > > > [2] > > https://issues.jboss.org/browse/WELD-2113 > > > > Dne 24.2.2016 v 20:47 Stephan Knitelius napsal(a): > >> I just want to bring this to everyone attention one more time. > >> > >> The conversation scope concurrency control mechanism seems to be a > >> frequent point of pain in many projects. > >> > >> Especially when working with browser triggered asynchronous requests, > >> you can not rely on client-sided request synchronization. > >> Weld, unlike OWB, grants a 1 second timeout prior to throwing a (the > >> specified) BusyConversationException mitigating the effect a bit. > >> > >> This is a rather strict un-configurable type of CC. Also its > >> completely out of alignment with the other build-in scopes, offering no > >> CC what so ever. > >> > >> In the cases of Session- and Application-Scope, thread handling is left > >> entirely to the developer, even so they are just as vulnerable in AJAX > >> environments. > >> > >> We should really consider introducing a common configurable mechanism, > >> that is aligned across all scopes (obviously accounting for backwards > >> compatibility in the case of conversation scope). > >> > >> Would really appreciate some feedback. > >> > >> Kind regards, > >> > >> Stephan > >> > >> > >> > >> > >> On Mon, 22 Feb 2016 at 23:10 Reza Rahman >> > wrote: > >> > >> We've discussed this issue before. I definitely still think @Lock > >> belongs in a modular CDI specification. It would be highly useful to > >> both @Singleton and @ApplicationScoped. Today if I need to use > >> declarative concurrency control for a shared component I am > >> essentially forced to use EJB singleton - which shouldn't be the > >> case and perhaps should not have been the case past Java EE 6. > >> > >> > >>> On 2/19/2016 5:27 AM, Stephan Knitelius wrote: > >>> Hi all, > >>> > >>> CDI spec does not define a common concurrency control mechanism. > >>> The time any type of concurrency control is mentioned is in > >>> conjunction with EJB and a rather restrictive one for conversation > >>> context. > >>> > >>> CDI Spec: > >>> The container ensures that a long-running conversation may be > >>> associated with at most one request at a time, by blocking or > >>> rejecting concurrent requests. If the container rejects a request, > >>> it must associate the request with a new transient conversation > >>> and throw an exception of > >>> type|javax.enterprise.context.BusyConversationException|. > >>> > >>> > >>> It would be helpful if a common configurable concurrency mechanism > >>> (EJB Singleton style locking?) could be established for all normal > >>> scopes. > >>> > >>> What are your thoughts on this? > >>> > >>> Regards, > >>> > >>> Stephan > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> ______________________________________ > >>> *Stephan Knitelius* > >>> Alteburger Str. 274 > >>> 50968 K?ln / Cologne > >>> Deutschland / Germany > >>> stephan at knitelius.com > >>> > >>> > >>> _______________________________________________ > >>> cdi-dev mailing list > >>> cdi-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>> > >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> Note that for all code provided on this list, the provider licenses > >> the code under the Apache License, Version 2 > >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > >> ideas provided on this list, the provider waives all patent and > >> other intellectual property rights inherent in such information. > >> > >> > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > > > -- > > Martin Kouba > > Software Engineer > > Red Hat, Czech Republic > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information._______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160225/28a39c9f/attachment-0001.html From EMIJIANG at uk.ibm.com Fri Feb 26 04:32:20 2016 From: EMIJIANG at uk.ibm.com (Emily Jiang) Date: Fri, 26 Feb 2016 09:32:20 +0000 Subject: [cdi-dev] Concurrency Control In-Reply-To: <71608FF8-5AE5-417E-A7D2-CE9DF3BF84A5@lycos.com> References: <56CB8671.8090408@oracle.com> <56CF0C13.4030306@redhat.com> <44E77DCE-3217-4E6C-B361-C1409F6D20BE@lycos.com> <201602252118.u1PLII2l029792@d06av08.portsmouth.uk.ibm.com> <71608FF8-5AE5-417E-A7D2-CE9DF3BF84A5@lycos.com> Message-ID: <201602260932.u1Q9WSYN015408@d06av12.portsmouth.uk.ibm.com> Hi Reza, I understand your frustration. I would suggest you raising a CDI jira to get all options discussed. Any objections? Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB From: Reza Rahman To: Emily Jiang/UK/IBM at IBMGB, Cc: cdi-dev at lists.jboss.org Date: 25/02/2016 23:01 Subject: Re: [cdi-dev] Concurrency Control Sent by: cdi-dev-bounces at lists.jboss.org This is not just a problem with this one feature but a much broader one involving @Asynchronous, @Schedule and many others. Simply punting on this problem and not dealing with this class of problems vigorously is rather foolish. It winds up doing what it has done for years - undermining pretty much all efforts related to Java EE, especially compared to the velocity and effectiveness by which the clear competitors to everything Java EE solve these issues. In the end, we are collectively to blame for the dismal state of affairs in Java EE land because of this sort of thing. On Feb 25, 2016, at 4:18 PM, Emily Jiang wrote: It would be nice if JavaEE Concurrency defines @Lock as a CDI interceptor, similar to @Transactional . Since the JavaEE Concurrency spec is stale as per you and Raze point out, how about experiment in DeltaSpike? If DeltaSpike provides the support of @Lock, maybe it can be pushed to JavaEE concurrency as part of EE8 update. If not, maybe CDI should define an addendum for EE integration. I think we should seriously think about this. Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB From: Stephan Knitelius To: Reza Rahman , Martin Kouba < mkouba at redhat.com>, Cc: cdi-dev at lists.jboss.org Date: 25/02/2016 20:26 Subject: Re: [cdi-dev] Concurrency Control Sent by: cdi-dev-bounces at lists.jboss.org Hi Martin, yes this particular issue is about concurrent access control. You are right in pointing out that the lock should be applied to the whole been and only override-able on a per method basis (similar to EJB Singleton style locking). Regarding conversation context, its fair enough to point-out that weld allows for configure the conversation lock timeout. However this is only true for Weld, this should really be made part of the specification. Even if we were to specify a standard way to configure conversation locked timeouts in the CDI specification, it would still make the conversation scope the odd one out of the lot. Hence it would be more sensible to design a common way to handle concurrent access. Also I would argue that you cannot implement a common concurrent access control via interceptors, since the container will preempt any interceptor based attempt for conversation scoped beans. As Reza pointed out Oracle has no intend to reopen "Concurrency Utilities for Java EE" at this time and is not willing to hand it over to anyone else. The same seems to be true for JTA. Stephan On Thu, 25 Feb 2016 at 15:50 Reza Rahman wrote: Oracle has pretty much clearly stated it has absolutely no intention of updating the Java EE Concurrency Utilities specification any time soon. My guess is that it will also never allow anyone else to update it either since it owns that specification. If this is a valuable feature to the community (which I definitely think it is) I strongly suggest taking advantage of the fact that this is a gray area and include it in a modular CDI specification so this feature doesn't continue to remain locked into EJB for Java EE users that need to more effectively use things like @Stereotype for service composition. > On Feb 25, 2016, at 9:13 AM, Martin Kouba wrote: > > Hi Stephan, > > I like the idea of CDI interceptor solution you're proposing in your > blogpost [1]. However, concurrency is a difficult topic. First of all, > this only solves concurrent access to the bean instance (i.e. > method-level locking) - the bean state is always up to the user. Also > I'm not so sure it's a good idea to only apply @Lock at the method level > (some methods are guarded some not - AFAIK EJB does not allow this either). > > I agree that conversation concurrentAccessTimeout in Weld should be > configurable. In fact, it should be possible to change this timeout even > now using Weld API and org.jboss.weld.context.ConversationContext. But > it should be definitely more straightforward [2]. > > To sum it up - I wouldn't add concurrency control to the spec provided > it's implementable using interceptors. This is a similar situation as to > javax.transaction.Transactional and JTA. The best place to specify this > is IMHO "Concurrency Utilities for Java EE". > > Martin > > [1] > http://www.knitelius.com/2016/01/25/concurrency-control-for-cdi/ > > [2] > https://issues.jboss.org/browse/WELD-2113 > > Dne 24.2.2016 v 20:47 Stephan Knitelius napsal(a): >> I just want to bring this to everyone attention one more time. >> >> The conversation scope concurrency control mechanism seems to be a >> frequent point of pain in many projects. >> >> Especially when working with browser triggered asynchronous requests, >> you can not rely on client-sided request synchronization. >> Weld, unlike OWB, grants a 1 second timeout prior to throwing a (the >> specified) BusyConversationException mitigating the effect a bit. >> >> This is a rather strict un-configurable type of CC. Also its >> completely out of alignment with the other build-in scopes, offering no >> CC what so ever. >> >> In the cases of Session- and Application-Scope, thread handling is left >> entirely to the developer, even so they are just as vulnerable in AJAX >> environments. >> >> We should really consider introducing a common configurable mechanism, >> that is aligned across all scopes (obviously accounting for backwards >> compatibility in the case of conversation scope). >> >> Would really appreciate some feedback. >> >> Kind regards, >> >> Stephan >> >> >> >> >> On Mon, 22 Feb 2016 at 23:10 Reza Rahman > > wrote: >> >> We've discussed this issue before. I definitely still think @Lock >> belongs in a modular CDI specification. It would be highly useful to >> both @Singleton and @ApplicationScoped. Today if I need to use >> declarative concurrency control for a shared component I am >> essentially forced to use EJB singleton - which shouldn't be the >> case and perhaps should not have been the case past Java EE 6. >> >> >>> On 2/19/2016 5:27 AM, Stephan Knitelius wrote: >>> Hi all, >>> >>> CDI spec does not define a common concurrency control mechanism. >>> The time any type of concurrency control is mentioned is in >>> conjunction with EJB and a rather restrictive one for conversation >>> context. >>> >>> CDI Spec: >>> The container ensures that a long-running conversation may be >>> associated with at most one request at a time, by blocking or >>> rejecting concurrent requests. If the container rejects a request, >>> it must associate the request with a new transient conversation >>> and throw an exception of >>> type|javax.enterprise.context.BusyConversationException|. >>> >>> >>> It would be helpful if a common configurable concurrency mechanism >>> (EJB Singleton style locking?) could be established for all normal >>> scopes. >>> >>> What are your thoughts on this? >>> >>> Regards, >>> >>> Stephan >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> ______________________________________ >>> *Stephan Knitelius* >>> Alteburger Str. 274 >>> 50968 K?ln / Cologne >>> Deutschland / Germany >>> stephan at knitelius.com >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses >> the code under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >> ideas provided on this list, the provider waives all patent and >> other intellectual property rights inherent in such information. >> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. _______________________________________________ cdi-dev mailing list cdi-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU _______________________________________________ cdi-dev mailing list cdi-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160226/1a769cce/attachment-0001.html From mkouba at redhat.com Fri Feb 26 04:40:59 2016 From: mkouba at redhat.com (Martin Kouba) Date: Fri, 26 Feb 2016 10:40:59 +0100 Subject: [cdi-dev] Concurrency Control In-Reply-To: <201602260932.u1Q9WSYN015408@d06av12.portsmouth.uk.ibm.com> References: <56CB8671.8090408@oracle.com> <56CF0C13.4030306@redhat.com> <44E77DCE-3217-4E6C-B361-C1409F6D20BE@lycos.com> <201602252118.u1PLII2l029792@d06av08.portsmouth.uk.ibm.com> <71608FF8-5AE5-417E-A7D2-CE9DF3BF84A5@lycos.com> <201602260932.u1Q9WSYN015408@d06av12.portsmouth.uk.ibm.com> Message-ID: <56D01DAB.3090304@redhat.com> Well, I don't like this approach. Seems like making CDI an "EJB.next all-in-one spec". BTW there is already a JIRA issue [1]. Maybe a separate issue should be created for conversation access timeout. Martin [1] https://issues.jboss.org/browse/CDI-582 Dne 26.2.2016 v 10:32 Emily Jiang napsal(a): > Hi Reza, > > I understand your frustration. I would suggest you raising a CDI jira to > get all options discussed. Any objections? > > Many thanks, > Emily > =========================== > Emily Jiang > WebSphere Application Server, CDI Development Lead > > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN > Phone: +44 (0)1962 816278 Internal: 246278 > > Email: emijiang at uk.ibm.com > Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > > > > From: Reza Rahman > To: Emily Jiang/UK/IBM at IBMGB, > Cc: cdi-dev at lists.jboss.org > Date: 25/02/2016 23:01 > Subject: Re: [cdi-dev] Concurrency Control > Sent by: cdi-dev-bounces at lists.jboss.org > ------------------------------------------------------------------------ > > > > This is not just a problem with this one feature but a much broader one > involving @Asynchronous, @Schedule and many others. Simply punting on > this problem and not dealing with this class of problems vigorously is > rather foolish. It winds up doing what it has done for years - > undermining pretty much all efforts related to Java EE, especially > compared to the velocity and effectiveness by which the clear > competitors to everything Java EE solve these issues. In the end, we are > collectively to blame for the dismal state of affairs in Java EE land > because of this sort of thing. > > On Feb 25, 2016, at 4:18 PM, Emily Jiang <_EMIJIANG at uk.ibm.com_ > > wrote: > > It would be nice if JavaEE Concurrency defines @Lock as a CDI > interceptor, similar to @Transactional . Since the JavaEE Concurrency > spec is stale as per you and Raze point out, how about experiment in > DeltaSpike? If DeltaSpike provides the support of @Lock, maybe it can be > pushed to JavaEE concurrency as part of EE8 update. If not, maybe CDI > should define an addendum for EE integration. I think we should > seriously think about this. > > > > Many thanks, > Emily > =========================== > Emily Jiang > WebSphere Application Server, CDI Development Lead > > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN > Phone: +44 (0)1962 816278 Internal: 246278 > > Email: _emijiang at uk.ibm.com_ > Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > > > > From: Stephan Knitelius <_stephan at knitelius.com_ > > > To: Reza Rahman <_reza_rahman at lycos.com_ > >, Martin Kouba <_mkouba at redhat.com_ > >, > Cc: _cdi-dev at lists.jboss.org_ > Date: 25/02/2016 20:26 > Subject: Re: [cdi-dev] Concurrency Control > Sent by: _cdi-dev-bounces at lists.jboss.org_ > > ------------------------------------------------------------------------ > > > > Hi Martin, > > yes this particular issue is about concurrent access control. You are > right in pointing out that the lock should be applied > to the whole been and only override-able on a per method basis (similar > to EJB Singleton style locking). > > Regarding conversation context, its fair enough to point-out that weld > allows for configure the conversation lock timeout. > However this is only true for Weld, this should really be made part of > the specification. > > Even if we were to specify a standard way to configure conversation > locked timeouts in the CDI specification, it would > still make the conversation scope the odd one out of the lot. Hence it > would be more sensible to design a > common way to handle concurrent access. > > Also I would argue that you cannot implement a common concurrent access > control via interceptors, > since the container will preempt any interceptor based attempt for > conversation scoped beans. > > As Reza pointed out Oracle has no intend to reopen "Concurrency > Utilities for Java EE" at this time and is not > willing to hand it over to anyone else. The same seems to be true for JTA. > > Stephan > > > > > > > > > > > > > > > > > > > On Thu, 25 Feb 2016 at 15:50 Reza Rahman <_reza_rahman at lycos.com_ > > wrote: > Oracle has pretty much clearly stated it has absolutely no intention of > updating the Java EE Concurrency Utilities specification any time soon. > My guess is that it will also never allow anyone else to update it > either since it owns that specification. If this is a valuable feature > to the community (which I definitely think it is) I strongly suggest > taking advantage of the fact that this is a gray area and include it in > a modular CDI specification so this feature doesn't continue to remain > locked into EJB for Java EE users that need to more effectively use > things like @Stereotype for service composition. > > > On Feb 25, 2016, at 9:13 AM, Martin Kouba <_mkouba at redhat.com_ > > wrote: > > > > Hi Stephan, > > > > I like the idea of CDI interceptor solution you're proposing in your > > blogpost [1]. However, concurrency is a difficult topic. First of all, > > this only solves concurrent access to the bean instance (i.e. > > method-level locking) - the bean state is always up to the user. Also > > I'm not so sure it's a good idea to only apply @Lock at the method level > > (some methods are guarded some not - AFAIK EJB does not allow this > either). > > > > I agree that conversation concurrentAccessTimeout in Weld should be > > configurable. In fact, it should be possible to change this timeout even > > now using Weld API and org.jboss.weld.context.ConversationContext. But > > it should be definitely more straightforward [2]. > > > > To sum it up - I wouldn't add concurrency control to the spec provided > > it's implementable using interceptors. This is a similar situation as to > > javax.transaction.Transactional and JTA. The best place to specify this > > is IMHO "Concurrency Utilities for Java EE". > > > > Martin > > > > [1] > > _http://www.knitelius.com/2016/01/25/concurrency-control-for-cdi/_ > > > > [2] > > _https://issues.jboss.org/browse/WELD-2113_ > > > > Dne 24.2.2016 v 20:47 Stephan Knitelius napsal(a): > >> I just want to bring this to everyone attention one more time. > >> > >> The conversation scope concurrency control mechanism seems to be a > >> frequent point of pain in many projects. > >> > >> Especially when working with browser triggered asynchronous requests, > >> you can not rely on client-sided request synchronization. > >> Weld, unlike OWB, grants a 1 second timeout prior to throwing a (the > >> specified) BusyConversationException mitigating the effect a bit. > >> > >> This is a rather strict un-configurable type of CC. Also its > >> completely out of alignment with the other build-in scopes, offering no > >> CC what so ever. > >> > >> In the cases of Session- and Application-Scope, thread handling is left > >> entirely to the developer, even so they are just as vulnerable in AJAX > >> environments. > >> > >> We should really consider introducing a common configurable mechanism, > >> that is aligned across all scopes (obviously accounting for backwards > >> compatibility in the case of conversation scope). > >> > >> Would really appreciate some feedback. > >> > >> Kind regards, > >> > >> Stephan > >> > >> > >> > >> > >> On Mon, 22 Feb 2016 at 23:10 Reza Rahman <_Reza.Rahman at oracle.com_ > > >> >> > wrote: > >> > >> We've discussed this issue before. I definitely still think @Lock > >> belongs in a modular CDI specification. It would be highly useful to > >> both @Singleton and @ApplicationScoped. Today if I need to use > >> declarative concurrency control for a shared component I am > >> essentially forced to use EJB singleton - which shouldn't be the > >> case and perhaps should not have been the case past Java EE 6. > >> > >> > >>> On 2/19/2016 5:27 AM, Stephan Knitelius wrote: > >>> Hi all, > >>> > >>> CDI spec does not define a common concurrency control mechanism. > >>> The time any type of concurrency control is mentioned is in > >>> conjunction with EJB and a rather restrictive one for conversation > >>> context. > >>> > >>> CDI Spec: > >>> The container ensures that a long-running conversation may be > >>> associated with at most one request at a time, by blocking or > >>> rejecting concurrent requests. If the container rejects a request, > >>> it must associate the request with a new transient conversation > >>> and throw an exception of > >>> type|javax.enterprise.context.BusyConversationException|. > >>> > >>> > >>> It would be helpful if a common configurable concurrency mechanism > >>> (EJB Singleton style locking?) could be established for all normal > >>> scopes. > >>> > >>> What are your thoughts on this? > >>> > >>> Regards, > >>> > >>> Stephan > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> ______________________________________ > >>> *Stephan Knitelius* > >>> Alteburger Str. 274 > >>> 50968 K?ln / Cologne > >>> Deutschland / Germany > >>> _stephan at knitelius.com_ > > > >>> > >>> > >>> _______________________________________________ > >>> cdi-dev mailing list > >>> _cdi-dev at lists.jboss.org_ > > > >>> _https://lists.jboss.org/mailman/listinfo/cdi-dev_ > >>> > >>> Note that for all code provided on this list, the provider > licenses the code under the Apache License, Version 2 > (_http://www.apache.org/licenses/LICENSE-2.0.html_). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> _cdi-dev at lists.jboss.org_ > > > >> _https://lists.jboss.org/mailman/listinfo/cdi-dev_ > >> > >> Note that for all code provided on this list, the provider licenses > >> the code under the Apache License, Version 2 > >> (_http://www.apache.org/licenses/LICENSE-2.0.html_). For all other > >> ideas provided on this list, the provider waives all patent and > >> other intellectual property rights inherent in such information. > >> > >> > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> _cdi-dev at lists.jboss.org_ > >> _https://lists.jboss.org/mailman/listinfo/cdi-dev_ > >> > >> Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 > (_http://www.apache.org/licenses/LICENSE-2.0.html_). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > > -- > > Martin Kouba > > Software Engineer > > Red Hat, Czech Republic > > _______________________________________________ > > cdi-dev mailing list > > _cdi-dev at lists.jboss.org_ > > _https://lists.jboss.org/mailman/listinfo/cdi-dev_ > > > > Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 > (_http://www.apache.org/licenses/LICENSE-2.0.html_). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such > information._______________________________________________ > cdi-dev mailing list_ > __cdi-dev at lists.jboss.org_ _ > __https://lists.jboss.org/mailman/listinfo/cdi-dev_ > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 > (_http://www.apache.org/licenses/LICENSE-2.0.html_). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU_______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > -- Martin Kouba Software Engineer Red Hat, Czech Republic From EMIJIANG at uk.ibm.com Fri Feb 26 06:15:46 2016 From: EMIJIANG at uk.ibm.com (Emily Jiang) Date: Fri, 26 Feb 2016 11:15:46 +0000 Subject: [cdi-dev] Concurrency Control In-Reply-To: <56D01DAB.3090304@redhat.com> References: <56CB8671.8090408@oracle.com> <56CF0C13.4030306@redhat.com> <44E77DCE-3217-4E6C-B361-C1409F6D20BE@lycos.com> <201602252118.u1PLII2l029792@d06av08.portsmouth.uk.ibm.com> <71608FF8-5AE5-417E-A7D2-CE9DF3BF84A5@lycos.com> <201602260932.u1Q9WSYN015408@d06av12.portsmouth.uk.ibm.com> <56D01DAB.3090304@redhat.com> Message-ID: <201602261115.u1QBFqJn019370@d06av02.portsmouth.uk.ibm.com> Thank you Martin for pointing out CDI-582! Then we should log comments on the jira. Maybe Atoine has a better suggestion on how to handle this cross spec issue. Addressing the conversation access timeout in CDI might be a step forward. Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB From: Martin Kouba To: Emily Jiang/UK/IBM at IBMGB, Reza Rahman , Cc: cdi-dev at lists.jboss.org Date: 26/02/2016 09:41 Subject: Re: [cdi-dev] Concurrency Control Sent by: cdi-dev-bounces at lists.jboss.org Well, I don't like this approach. Seems like making CDI an "EJB.next all-in-one spec". BTW there is already a JIRA issue [1]. Maybe a separate issue should be created for conversation access timeout. Martin [1] https://issues.jboss.org/browse/CDI-582 Dne 26.2.2016 v 10:32 Emily Jiang napsal(a): > Hi Reza, > > I understand your frustration. I would suggest you raising a CDI jira to > get all options discussed. Any objections? > > Many thanks, > Emily > =========================== > Emily Jiang > WebSphere Application Server, CDI Development Lead > > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN > Phone: +44 (0)1962 816278 Internal: 246278 > > Email: emijiang at uk.ibm.com > Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > > > > From: Reza Rahman > To: Emily Jiang/UK/IBM at IBMGB, > Cc: cdi-dev at lists.jboss.org > Date: 25/02/2016 23:01 > Subject: Re: [cdi-dev] Concurrency Control > Sent by: cdi-dev-bounces at lists.jboss.org > ------------------------------------------------------------------------ > > > > This is not just a problem with this one feature but a much broader one > involving @Asynchronous, @Schedule and many others. Simply punting on > this problem and not dealing with this class of problems vigorously is > rather foolish. It winds up doing what it has done for years - > undermining pretty much all efforts related to Java EE, especially > compared to the velocity and effectiveness by which the clear > competitors to everything Java EE solve these issues. In the end, we are > collectively to blame for the dismal state of affairs in Java EE land > because of this sort of thing. > > On Feb 25, 2016, at 4:18 PM, Emily Jiang <_EMIJIANG at uk.ibm.com_ > > wrote: > > It would be nice if JavaEE Concurrency defines @Lock as a CDI > interceptor, similar to @Transactional . Since the JavaEE Concurrency > spec is stale as per you and Raze point out, how about experiment in > DeltaSpike? If DeltaSpike provides the support of @Lock, maybe it can be > pushed to JavaEE concurrency as part of EE8 update. If not, maybe CDI > should define an addendum for EE integration. I think we should > seriously think about this. > > > > Many thanks, > Emily > =========================== > Emily Jiang > WebSphere Application Server, CDI Development Lead > > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN > Phone: +44 (0)1962 816278 Internal: 246278 > > Email: _emijiang at uk.ibm.com_ > Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > > > > From: Stephan Knitelius <_stephan at knitelius.com_ > > > To: Reza Rahman <_reza_rahman at lycos.com_ > >, Martin Kouba <_mkouba at redhat.com_ > >, > Cc: _cdi-dev at lists.jboss.org_ > Date: 25/02/2016 20:26 > Subject: Re: [cdi-dev] Concurrency Control > Sent by: _cdi-dev-bounces at lists.jboss.org_ > > ------------------------------------------------------------------------ > > > > Hi Martin, > > yes this particular issue is about concurrent access control. You are > right in pointing out that the lock should be applied > to the whole been and only override-able on a per method basis (similar > to EJB Singleton style locking). > > Regarding conversation context, its fair enough to point-out that weld > allows for configure the conversation lock timeout. > However this is only true for Weld, this should really be made part of > the specification. > > Even if we were to specify a standard way to configure conversation > locked timeouts in the CDI specification, it would > still make the conversation scope the odd one out of the lot. Hence it > would be more sensible to design a > common way to handle concurrent access. > > Also I would argue that you cannot implement a common concurrent access > control via interceptors, > since the container will preempt any interceptor based attempt for > conversation scoped beans. > > As Reza pointed out Oracle has no intend to reopen "Concurrency > Utilities for Java EE" at this time and is not > willing to hand it over to anyone else. The same seems to be true for JTA. > > Stephan > > > > > > > > > > > > > > > > > > > On Thu, 25 Feb 2016 at 15:50 Reza Rahman <_reza_rahman at lycos.com_ > > wrote: > Oracle has pretty much clearly stated it has absolutely no intention of > updating the Java EE Concurrency Utilities specification any time soon. > My guess is that it will also never allow anyone else to update it > either since it owns that specification. If this is a valuable feature > to the community (which I definitely think it is) I strongly suggest > taking advantage of the fact that this is a gray area and include it in > a modular CDI specification so this feature doesn't continue to remain > locked into EJB for Java EE users that need to more effectively use > things like @Stereotype for service composition. > > > On Feb 25, 2016, at 9:13 AM, Martin Kouba <_mkouba at redhat.com_ > > wrote: > > > > Hi Stephan, > > > > I like the idea of CDI interceptor solution you're proposing in your > > blogpost [1]. However, concurrency is a difficult topic. First of all, > > this only solves concurrent access to the bean instance (i.e. > > method-level locking) - the bean state is always up to the user. Also > > I'm not so sure it's a good idea to only apply @Lock at the method level > > (some methods are guarded some not - AFAIK EJB does not allow this > either). > > > > I agree that conversation concurrentAccessTimeout in Weld should be > > configurable. In fact, it should be possible to change this timeout even > > now using Weld API and org.jboss.weld.context.ConversationContext. But > > it should be definitely more straightforward [2]. > > > > To sum it up - I wouldn't add concurrency control to the spec provided > > it's implementable using interceptors. This is a similar situation as to > > javax.transaction.Transactional and JTA. The best place to specify this > > is IMHO "Concurrency Utilities for Java EE". > > > > Martin > > > > [1] > > _http://www.knitelius.com/2016/01/25/concurrency-control-for-cdi/_ > > > > [2] > > _https://issues.jboss.org/browse/WELD-2113_ > > > > Dne 24.2.2016 v 20:47 Stephan Knitelius napsal(a): > >> I just want to bring this to everyone attention one more time. > >> > >> The conversation scope concurrency control mechanism seems to be a > >> frequent point of pain in many projects. > >> > >> Especially when working with browser triggered asynchronous requests, > >> you can not rely on client-sided request synchronization. > >> Weld, unlike OWB, grants a 1 second timeout prior to throwing a (the > >> specified) BusyConversationException mitigating the effect a bit. > >> > >> This is a rather strict un-configurable type of CC. Also its > >> completely out of alignment with the other build-in scopes, offering no > >> CC what so ever. > >> > >> In the cases of Session- and Application-Scope, thread handling is left > >> entirely to the developer, even so they are just as vulnerable in AJAX > >> environments. > >> > >> We should really consider introducing a common configurable mechanism, > >> that is aligned across all scopes (obviously accounting for backwards > >> compatibility in the case of conversation scope). > >> > >> Would really appreciate some feedback. > >> > >> Kind regards, > >> > >> Stephan > >> > >> > >> > >> > >> On Mon, 22 Feb 2016 at 23:10 Reza Rahman <_Reza.Rahman at oracle.com_ > > >> >> > wrote: > >> > >> We've discussed this issue before. I definitely still think @Lock > >> belongs in a modular CDI specification. It would be highly useful to > >> both @Singleton and @ApplicationScoped. Today if I need to use > >> declarative concurrency control for a shared component I am > >> essentially forced to use EJB singleton - which shouldn't be the > >> case and perhaps should not have been the case past Java EE 6. > >> > >> > >>> On 2/19/2016 5:27 AM, Stephan Knitelius wrote: > >>> Hi all, > >>> > >>> CDI spec does not define a common concurrency control mechanism. > >>> The time any type of concurrency control is mentioned is in > >>> conjunction with EJB and a rather restrictive one for conversation > >>> context. > >>> > >>> CDI Spec: > >>> The container ensures that a long-running conversation may be > >>> associated with at most one request at a time, by blocking or > >>> rejecting concurrent requests. If the container rejects a request, > >>> it must associate the request with a new transient conversation > >>> and throw an exception of > >>> type|javax.enterprise.context.BusyConversationException|. > >>> > >>> > >>> It would be helpful if a common configurable concurrency mechanism > >>> (EJB Singleton style locking?) could be established for all normal > >>> scopes. > >>> > >>> What are your thoughts on this? > >>> > >>> Regards, > >>> > >>> Stephan > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> ______________________________________ > >>> *Stephan Knitelius* > >>> Alteburger Str. 274 > >>> 50968 K?ln / Cologne > >>> Deutschland / Germany > >>> _stephan at knitelius.com_ > > > >>> > >>> > >>> _______________________________________________ > >>> cdi-dev mailing list > >>> _cdi-dev at lists.jboss.org_ > > > >>> _https://lists.jboss.org/mailman/listinfo/cdi-dev_ > >>> > >>> Note that for all code provided on this list, the provider > licenses the code under the Apache License, Version 2 > (_http://www.apache.org/licenses/LICENSE-2.0.html_). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> _cdi-dev at lists.jboss.org_ > > > >> _https://lists.jboss.org/mailman/listinfo/cdi-dev_ > >> > >> Note that for all code provided on this list, the provider licenses > >> the code under the Apache License, Version 2 > >> (_http://www.apache.org/licenses/LICENSE-2.0.html_). For all other > >> ideas provided on this list, the provider waives all patent and > >> other intellectual property rights inherent in such information. > >> > >> > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> _cdi-dev at lists.jboss.org_ > >> _https://lists.jboss.org/mailman/listinfo/cdi-dev_ > >> > >> Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 > (_http://www.apache.org/licenses/LICENSE-2.0.html_). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > > -- > > Martin Kouba > > Software Engineer > > Red Hat, Czech Republic > > _______________________________________________ > > cdi-dev mailing list > > _cdi-dev at lists.jboss.org_ > > _https://lists.jboss.org/mailman/listinfo/cdi-dev_ > > > > Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 > (_http://www.apache.org/licenses/LICENSE-2.0.html_). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such > information._______________________________________________ > cdi-dev mailing list_ > __cdi-dev at lists.jboss.org_ _ > __https://lists.jboss.org/mailman/listinfo/cdi-dev_ > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 > (_http://www.apache.org/licenses/LICENSE-2.0.html_). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU_______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > -- Martin Kouba Software Engineer Red Hat, Czech Republic _______________________________________________ cdi-dev mailing list cdi-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160226/458f2a4b/attachment-0001.html From reza_rahman at lycos.com Fri Feb 26 06:40:38 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Fri, 26 Feb 2016 06:40:38 -0500 Subject: [cdi-dev] Concurrency Control In-Reply-To: <201602260932.u1Q9WS8s005064@d06av07.portsmouth.uk.ibm.com> References: <56CB8671.8090408@oracle.com> <56CF0C13.4030306@redhat.com> <44E77DCE-3217-4E6C-B361-C1409F6D20BE@lycos.com> <201602252118.u1PLII2l029792@d06av08.portsmouth.uk.ibm.com> <71608FF8-5AE5-417E-A7D2-CE9DF3BF84A5@lycos.com> <201602260932.u1Q9WS8s005064@d06av07.portsmouth.uk.ibm.com> Message-ID: <7313A4E6-24FA-4427-964A-BADF7FBE4FB8@lycos.com> No objections whatsoever. I will put in the JIRAs ASAP so we can give this the attention it deserves. > On Feb 26, 2016, at 4:32 AM, Emily Jiang wrote: > > Hi Reza, > > I understand your frustration. I would suggest you raising a CDI jira to get all options discussed. Any objections? > > Many thanks, > Emily > =========================== > Emily Jiang > WebSphere Application Server, CDI Development Lead > > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN > Phone: +44 (0)1962 816278 Internal: 246278 > > Email: emijiang at uk.ibm.com > Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > > > > From: Reza Rahman > To: Emily Jiang/UK/IBM at IBMGB, > Cc: cdi-dev at lists.jboss.org > Date: 25/02/2016 23:01 > Subject: Re: [cdi-dev] Concurrency Control > Sent by: cdi-dev-bounces at lists.jboss.org > > > > This is not just a problem with this one feature but a much broader one involving @Asynchronous, @Schedule and many others. Simply punting on this problem and not dealing with this class of problems vigorously is rather foolish. It winds up doing what it has done for years - undermining pretty much all efforts related to Java EE, especially compared to the velocity and effectiveness by which the clear competitors to everything Java EE solve these issues. In the end, we are collectively to blame for the dismal state of affairs in Java EE land because of this sort of thing. > > On Feb 25, 2016, at 4:18 PM, Emily Jiang wrote: > > It would be nice if JavaEE Concurrency defines @Lock as a CDI interceptor, similar to @Transactional . Since the JavaEE Concurrency spec is stale as per you and Raze point out, how about experiment in DeltaSpike? If DeltaSpike provides the support of @Lock, maybe it can be pushed to JavaEE concurrency as part of EE8 update. If not, maybe CDI should define an addendum for EE integration. I think we should seriously think about this. > > > > Many thanks, > Emily > =========================== > Emily Jiang > WebSphere Application Server, CDI Development Lead > > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN > Phone: +44 (0)1962 816278 Internal: 246278 > > Email: emijiang at uk.ibm.com > Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > > > > From: Stephan Knitelius > To: Reza Rahman , Martin Kouba , > Cc: cdi-dev at lists.jboss.org > Date: 25/02/2016 20:26 > Subject: Re: [cdi-dev] Concurrency Control > Sent by: cdi-dev-bounces at lists.jboss.org > > > > Hi Martin, > > yes this particular issue is about concurrent access control. You are right in pointing out that the lock should be applied > to the whole been and only override-able on a per method basis (similar to EJB Singleton style locking). > > Regarding conversation context, its fair enough to point-out that weld allows for configure the conversation lock timeout. > However this is only true for Weld, this should really be made part of the specification. > > Even if we were to specify a standard way to configure conversation locked timeouts in the CDI specification, it would > still make the conversation scope the odd one out of the lot. Hence it would be more sensible to design a > common way to handle concurrent access. > > Also I would argue that you cannot implement a common concurrent access control via interceptors, > since the container will preempt any interceptor based attempt for conversation scoped beans. > > As Reza pointed out Oracle has no intend to reopen "Concurrency Utilities for Java EE" at this time and is not > willing to hand it over to anyone else. The same seems to be true for JTA. > > Stephan > > > > > > > > > > > > > > > > > > > On Thu, 25 Feb 2016 at 15:50 Reza Rahman wrote: > Oracle has pretty much clearly stated it has absolutely no intention of updating the Java EE Concurrency Utilities specification any time soon. My guess is that it will also never allow anyone else to update it either since it owns that specification. If this is a valuable feature to the community (which I definitely think it is) I strongly suggest taking advantage of the fact that this is a gray area and include it in a modular CDI specification so this feature doesn't continue to remain locked into EJB for Java EE users that need to more effectively use things like @Stereotype for service composition. > > > On Feb 25, 2016, at 9:13 AM, Martin Kouba wrote: > > > > Hi Stephan, > > > > I like the idea of CDI interceptor solution you're proposing in your > > blogpost [1]. However, concurrency is a difficult topic. First of all, > > this only solves concurrent access to the bean instance (i.e. > > method-level locking) - the bean state is always up to the user. Also > > I'm not so sure it's a good idea to only apply @Lock at the method level > > (some methods are guarded some not - AFAIK EJB does not allow this either). > > > > I agree that conversation concurrentAccessTimeout in Weld should be > > configurable. In fact, it should be possible to change this timeout even > > now using Weld API and org.jboss.weld.context.ConversationContext. But > > it should be definitely more straightforward [2]. > > > > To sum it up - I wouldn't add concurrency control to the spec provided > > it's implementable using interceptors. This is a similar situation as to > > javax.transaction.Transactional and JTA. The best place to specify this > > is IMHO "Concurrency Utilities for Java EE". > > > > Martin > > > > [1] > > http://www.knitelius.com/2016/01/25/concurrency-control-for-cdi/ > > > > [2] > > https://issues.jboss.org/browse/WELD-2113 > > > > Dne 24.2.2016 v 20:47 Stephan Knitelius napsal(a): > >> I just want to bring this to everyone attention one more time. > >> > >> The conversation scope concurrency control mechanism seems to be a > >> frequent point of pain in many projects. > >> > >> Especially when working with browser triggered asynchronous requests, > >> you can not rely on client-sided request synchronization. > >> Weld, unlike OWB, grants a 1 second timeout prior to throwing a (the > >> specified) BusyConversationException mitigating the effect a bit. > >> > >> This is a rather strict un-configurable type of CC. Also its > >> completely out of alignment with the other build-in scopes, offering no > >> CC what so ever. > >> > >> In the cases of Session- and Application-Scope, thread handling is left > >> entirely to the developer, even so they are just as vulnerable in AJAX > >> environments. > >> > >> We should really consider introducing a common configurable mechanism, > >> that is aligned across all scopes (obviously accounting for backwards > >> compatibility in the case of conversation scope). > >> > >> Would really appreciate some feedback. > >> > >> Kind regards, > >> > >> Stephan > >> > >> > >> > >> > >> On Mon, 22 Feb 2016 at 23:10 Reza Rahman >> > wrote: > >> > >> We've discussed this issue before. I definitely still think @Lock > >> belongs in a modular CDI specification. It would be highly useful to > >> both @Singleton and @ApplicationScoped. Today if I need to use > >> declarative concurrency control for a shared component I am > >> essentially forced to use EJB singleton - which shouldn't be the > >> case and perhaps should not have been the case past Java EE 6. > >> > >> > >>> On 2/19/2016 5:27 AM, Stephan Knitelius wrote: > >>> Hi all, > >>> > >>> CDI spec does not define a common concurrency control mechanism. > >>> The time any type of concurrency control is mentioned is in > >>> conjunction with EJB and a rather restrictive one for conversation > >>> context. > >>> > >>> CDI Spec: > >>> The container ensures that a long-running conversation may be > >>> associated with at most one request at a time, by blocking or > >>> rejecting concurrent requests. If the container rejects a request, > >>> it must associate the request with a new transient conversation > >>> and throw an exception of > >>> type|javax.enterprise.context.BusyConversationException|. > >>> > >>> > >>> It would be helpful if a common configurable concurrency mechanism > >>> (EJB Singleton style locking?) could be established for all normal > >>> scopes. > >>> > >>> What are your thoughts on this? > >>> > >>> Regards, > >>> > >>> Stephan > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> ______________________________________ > >>> *Stephan Knitelius* > >>> Alteburger Str. 274 > >>> 50968 K?ln / Cologne > >>> Deutschland / Germany > >>> stephan at knitelius.com > >>> > >>> > >>> _______________________________________________ > >>> cdi-dev mailing list > >>> cdi-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>> > >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> Note that for all code provided on this list, the provider licenses > >> the code under the Apache License, Version 2 > >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > >> ideas provided on this list, the provider waives all patent and > >> other intellectual property rights inherent in such information. > >> > >> > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > > > -- > > Martin Kouba > > Software Engineer > > Red Hat, Czech Republic > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information._______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU_______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160226/525ab6e5/attachment-0001.html From reza_rahman at lycos.com Fri Feb 26 06:47:52 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Fri, 26 Feb 2016 06:47:52 -0500 Subject: [cdi-dev] Concurrency Control In-Reply-To: <56D01DAB.3090304@redhat.com> References: <56CB8671.8090408@oracle.com> <56CF0C13.4030306@redhat.com> <44E77DCE-3217-4E6C-B361-C1409F6D20BE@lycos.com> <201602252118.u1PLII2l029792@d06av08.portsmouth.uk.ibm.com> <71608FF8-5AE5-417E-A7D2-CE9DF3BF84A5@lycos.com> <201602260932.u1Q9WSYN015408@d06av12.portsmouth.uk.ibm.com> <56D01DAB.3090304@redhat.com> Message-ID: <8BD11E95-1D3F-4B65-AF6A-C89ACE127334@lycos.com> Frankly I think the "we don't want scope creep" thinking on this EG has gone a bit too far. Some things are indeed OK as core DI concerns. For example, it's not as though I am suggesting CDI 2 take up the MDB alignment work that belongs in JMS.next. This EG should be thinking about what it needs to do to increase adoption. Finding reasonable ways to get rid of EJB and becoming a bit more competitive with other DI frameworks definitely helps. > On Feb 26, 2016, at 4:40 AM, Martin Kouba wrote: > > Well, I don't like this approach. Seems like making CDI an "EJB.next all-in-one spec". BTW there is already a JIRA issue [1]. Maybe a separate issue should be created for conversation access timeout. > > Martin > > [1] > https://issues.jboss.org/browse/CDI-582 > > Dne 26.2.2016 v 10:32 Emily Jiang napsal(a): >> Hi Reza, >> >> I understand your frustration. I would suggest you raising a CDI jira to >> get all options discussed. Any objections? >> >> Many thanks, >> Emily >> =========================== >> Emily Jiang >> WebSphere Application Server, CDI Development Lead >> >> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN >> Phone: +44 (0)1962 816278 Internal: 246278 >> >> Email: emijiang at uk.ibm.com >> Lotus Notes: Emily Jiang/UK/IBM at IBMGB >> >> >> >> >> From: Reza Rahman >> To: Emily Jiang/UK/IBM at IBMGB, >> Cc: cdi-dev at lists.jboss.org >> Date: 25/02/2016 23:01 >> Subject: Re: [cdi-dev] Concurrency Control >> Sent by: cdi-dev-bounces at lists.jboss.org >> ------------------------------------------------------------------------ >> >> >> >> This is not just a problem with this one feature but a much broader one >> involving @Asynchronous, @Schedule and many others. Simply punting on >> this problem and not dealing with this class of problems vigorously is >> rather foolish. It winds up doing what it has done for years - >> undermining pretty much all efforts related to Java EE, especially >> compared to the velocity and effectiveness by which the clear >> competitors to everything Java EE solve these issues. In the end, we are >> collectively to blame for the dismal state of affairs in Java EE land >> because of this sort of thing. >> >> On Feb 25, 2016, at 4:18 PM, Emily Jiang <_EMIJIANG at uk.ibm.com_ >> > wrote: >> >> It would be nice if JavaEE Concurrency defines @Lock as a CDI >> interceptor, similar to @Transactional . Since the JavaEE Concurrency >> spec is stale as per you and Raze point out, how about experiment in >> DeltaSpike? If DeltaSpike provides the support of @Lock, maybe it can be >> pushed to JavaEE concurrency as part of EE8 update. If not, maybe CDI >> should define an addendum for EE integration. I think we should >> seriously think about this. >> >> >> >> Many thanks, >> Emily >> =========================== >> Emily Jiang >> WebSphere Application Server, CDI Development Lead >> >> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN >> Phone: +44 (0)1962 816278 Internal: 246278 >> >> Email: _emijiang at uk.ibm.com_ >> Lotus Notes: Emily Jiang/UK/IBM at IBMGB >> >> >> >> >> From: Stephan Knitelius <_stephan at knitelius.com_ >> > >> To: Reza Rahman <_reza_rahman at lycos.com_ >> >, Martin Kouba <_mkouba at redhat.com_ >> >, >> Cc: _cdi-dev at lists.jboss.org_ >> Date: 25/02/2016 20:26 >> Subject: Re: [cdi-dev] Concurrency Control >> Sent by: _cdi-dev-bounces at lists.jboss.org_ >> >> ------------------------------------------------------------------------ >> >> >> >> Hi Martin, >> >> yes this particular issue is about concurrent access control. You are >> right in pointing out that the lock should be applied >> to the whole been and only override-able on a per method basis (similar >> to EJB Singleton style locking). >> >> Regarding conversation context, its fair enough to point-out that weld >> allows for configure the conversation lock timeout. >> However this is only true for Weld, this should really be made part of >> the specification. >> >> Even if we were to specify a standard way to configure conversation >> locked timeouts in the CDI specification, it would >> still make the conversation scope the odd one out of the lot. Hence it >> would be more sensible to design a >> common way to handle concurrent access. >> >> Also I would argue that you cannot implement a common concurrent access >> control via interceptors, >> since the container will preempt any interceptor based attempt for >> conversation scoped beans. >> >> As Reza pointed out Oracle has no intend to reopen "Concurrency >> Utilities for Java EE" at this time and is not >> willing to hand it over to anyone else. The same seems to be true for JTA. >> >> Stephan >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Thu, 25 Feb 2016 at 15:50 Reza Rahman <_reza_rahman at lycos.com_ >> > wrote: >> Oracle has pretty much clearly stated it has absolutely no intention of >> updating the Java EE Concurrency Utilities specification any time soon. >> My guess is that it will also never allow anyone else to update it >> either since it owns that specification. If this is a valuable feature >> to the community (which I definitely think it is) I strongly suggest >> taking advantage of the fact that this is a gray area and include it in >> a modular CDI specification so this feature doesn't continue to remain >> locked into EJB for Java EE users that need to more effectively use >> things like @Stereotype for service composition. >> >> > On Feb 25, 2016, at 9:13 AM, Martin Kouba <_mkouba at redhat.com_ >> > wrote: >> > >> > Hi Stephan, >> > >> > I like the idea of CDI interceptor solution you're proposing in your >> > blogpost [1]. However, concurrency is a difficult topic. First of all, >> > this only solves concurrent access to the bean instance (i.e. >> > method-level locking) - the bean state is always up to the user. Also >> > I'm not so sure it's a good idea to only apply @Lock at the method level >> > (some methods are guarded some not - AFAIK EJB does not allow this >> either). >> > >> > I agree that conversation concurrentAccessTimeout in Weld should be >> > configurable. In fact, it should be possible to change this timeout even >> > now using Weld API and org.jboss.weld.context.ConversationContext. But >> > it should be definitely more straightforward [2]. >> > >> > To sum it up - I wouldn't add concurrency control to the spec provided >> > it's implementable using interceptors. This is a similar situation as to >> > javax.transaction.Transactional and JTA. The best place to specify this >> > is IMHO "Concurrency Utilities for Java EE". >> > >> > Martin >> > >> > [1] >> > _http://www.knitelius.com/2016/01/25/concurrency-control-for-cdi/_ >> > >> > [2] >> > _https://issues.jboss.org/browse/WELD-2113_ >> > >> > Dne 24.2.2016 v 20:47 Stephan Knitelius napsal(a): >> >> I just want to bring this to everyone attention one more time. >> >> >> >> The conversation scope concurrency control mechanism seems to be a >> >> frequent point of pain in many projects. >> >> >> >> Especially when working with browser triggered asynchronous requests, >> >> you can not rely on client-sided request synchronization. >> >> Weld, unlike OWB, grants a 1 second timeout prior to throwing a (the >> >> specified) BusyConversationException mitigating the effect a bit. >> >> >> >> This is a rather strict un-configurable type of CC. Also its >> >> completely out of alignment with the other build-in scopes, offering no >> >> CC what so ever. >> >> >> >> In the cases of Session- and Application-Scope, thread handling is left >> >> entirely to the developer, even so they are just as vulnerable in AJAX >> >> environments. >> >> >> >> We should really consider introducing a common configurable mechanism, >> >> that is aligned across all scopes (obviously accounting for backwards >> >> compatibility in the case of conversation scope). >> >> >> >> Would really appreciate some feedback. >> >> >> >> Kind regards, >> >> >> >> Stephan >> >> >> >> >> >> >> >> >> >> On Mon, 22 Feb 2016 at 23:10 Reza Rahman <_Reza.Rahman at oracle.com_ >> >> >> >> >> wrote: >> >> >> >> We've discussed this issue before. I definitely still think @Lock >> >> belongs in a modular CDI specification. It would be highly useful to >> >> both @Singleton and @ApplicationScoped. Today if I need to use >> >> declarative concurrency control for a shared component I am >> >> essentially forced to use EJB singleton - which shouldn't be the >> >> case and perhaps should not have been the case past Java EE 6. >> >> >> >> >> >>> On 2/19/2016 5:27 AM, Stephan Knitelius wrote: >> >>> Hi all, >> >>> >> >>> CDI spec does not define a common concurrency control mechanism. >> >>> The time any type of concurrency control is mentioned is in >> >>> conjunction with EJB and a rather restrictive one for conversation >> >>> context. >> >>> >> >>> CDI Spec: >> >>> The container ensures that a long-running conversation may be >> >>> associated with at most one request at a time, by blocking or >> >>> rejecting concurrent requests. If the container rejects a request, >> >>> it must associate the request with a new transient conversation >> >>> and throw an exception of >> >>> type|javax.enterprise.context.BusyConversationException|. >> >>> >> >>> >> >>> It would be helpful if a common configurable concurrency mechanism >> >>> (EJB Singleton style locking?) could be established for all normal >> >>> scopes. >> >>> >> >>> What are your thoughts on this? >> >>> >> >>> Regards, >> >>> >> >>> Stephan >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> ______________________________________ >> >>> *Stephan Knitelius* >> >>> Alteburger Str. 274 >> >>> 50968 K?ln / Cologne >> >>> Deutschland / Germany >> >>> _stephan at knitelius.com_ >> > > >> >>> >> >>> >> >>> _______________________________________________ >> >>> cdi-dev mailing list >> >>> _cdi-dev at lists.jboss.org_ >> > > >> >>> _https://lists.jboss.org/mailman/listinfo/cdi-dev_ >> >>> >> >>> Note that for all code provided on this list, the provider >> licenses the code under the Apache License, Version 2 >> (_http://www.apache.org/licenses/LICENSE-2.0.html_). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> >> >> >> _______________________________________________ >> >> cdi-dev mailing list >> >> _cdi-dev at lists.jboss.org_ >> > > >> >> _https://lists.jboss.org/mailman/listinfo/cdi-dev_ >> >> >> >> Note that for all code provided on this list, the provider licenses >> >> the code under the Apache License, Version 2 >> >> (_http://www.apache.org/licenses/LICENSE-2.0.html_). For all other >> >> ideas provided on this list, the provider waives all patent and >> >> other intellectual property rights inherent in such information. >> >> >> >> >> >> >> >> _______________________________________________ >> >> cdi-dev mailing list >> >> _cdi-dev at lists.jboss.org_ >> >> _https://lists.jboss.org/mailman/listinfo/cdi-dev_ >> >> >> >> Note that for all code provided on this list, the provider licenses >> the code under the Apache License, Version 2 >> (_http://www.apache.org/licenses/LICENSE-2.0.html_). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> > >> > -- >> > Martin Kouba >> > Software Engineer >> > Red Hat, Czech Republic >> > _______________________________________________ >> > cdi-dev mailing list >> > _cdi-dev at lists.jboss.org_ >> > _https://lists.jboss.org/mailman/listinfo/cdi-dev_ >> > >> > Note that for all code provided on this list, the provider licenses >> the code under the Apache License, Version 2 >> (_http://www.apache.org/licenses/LICENSE-2.0.html_). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such >> information._______________________________________________ >> cdi-dev mailing list_ >> __cdi-dev at lists.jboss.org_ _ >> __https://lists.jboss.org/mailman/listinfo/cdi-dev_ >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 >> (_http://www.apache.org/licenses/LICENSE-2.0.html_). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >> 3AU_______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic From antoine at sabot-durand.net Fri Feb 26 08:57:08 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 26 Feb 2016 13:57:08 +0000 Subject: [cdi-dev] New version for CDI-558 Message-ID: Hi guys, I just push a new version for PR 270 https://github.com/cdi-spec/cdi/pull/270 No more strange inheritance, Builders now use Configurator by composition. I kept the distinction between configurator and builder to have different restriction between both. BeanConfigurator duplicates all methods from BeanAttributesConfigurator, an alternative might be to compose them (BeanConfigurator consumes a BeanAttributesConfigurator) Thanks for your review. This PR is important to decide how we may manage other ticket like new version of SE bootstrap (CDI-568) or interceptor on producer (CDI-580) Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160226/d05dde4c/attachment.html From antoine at sabot-durand.net Fri Feb 26 09:27:06 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 26 Feb 2016 14:27:06 +0000 Subject: [cdi-dev] PTO next week Message-ID: Hi guys, I'll be on vacation next week. Our next meeting will be on march 8th. Please take time to review open PR. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160226/7472e7cf/attachment.html From werner.keil at gmail.com Fri Feb 26 11:39:07 2016 From: werner.keil at gmail.com (Werner Keil) Date: Fri, 26 Feb 2016 17:39:07 +0100 Subject: [cdi-dev] Concurrency Control Message-ID: Reza/all, One of the biggest problems with Concurrency Utilities is, that it started in 2003, then went "dormant" (before the term existed) and was revived to be finalized 10 years later after little or no proper alignment with then state of the art Java EE standards and technologies. It duplicates things, especially in EJB or CDI. Similar to the even older JSR 107 which also has similar problems and technical debt (as members of this and other EGs confirmed or expressed their concern) We can't undo many of these problems, but it seems both these "relics" need at the very least a solid MR if not entirely new JSRs (before EE 8 wraps up the selected features) to address their age and fit in more nicely into the recent platform) JMS 2 did a great job in that direction and even has a new JSR for Java EE 8. Regards, Werner On Fri, Feb 26, 2016 at 12:40 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: Concurrency Control (Reza Rahman) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 26 Feb 2016 06:40:38 -0500 > From: Reza Rahman > Subject: Re: [cdi-dev] Concurrency Control > To: Emily Jiang > Cc: cdi-dev at lists.jboss.org > Message-ID: <7313A4E6-24FA-4427-964A-BADF7FBE4FB8 at lycos.com> > Content-Type: text/plain; charset="utf-8" > > No objections whatsoever. I will put in the JIRAs ASAP so we can give this > the attention it deserves. > > > On Feb 26, 2016, at 4:32 AM, Emily Jiang wrote: > > > > Hi Reza, > > > > I understand your frustration. I would suggest you raising a CDI jira to > get all options discussed. Any objections? > > > > Many thanks, > > Emily > > =========================== > > Emily Jiang > > WebSphere Application Server, CDI Development Lead > > > > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN > > Phone: +44 (0)1962 816278 Internal: 246278 > > > > Email: emijiang at uk.ibm.com > > Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > > > > > > > > > From: Reza Rahman > > To: Emily Jiang/UK/IBM at IBMGB, > > Cc: cdi-dev at lists.jboss.org > > Date: 25/02/2016 23:01 > > Subject: Re: [cdi-dev] Concurrency Control > > Sent by: cdi-dev-bounces at lists.jboss.org > > > > > > > > This is not just a problem with this one feature but a much broader one > involving @Asynchronous, @Schedule and many others. Simply punting on this > problem and not dealing with this class of problems vigorously is rather > foolish. It winds up doing what it has done for years - undermining pretty > much all efforts related to Java EE, especially compared to the velocity > and effectiveness by which the clear competitors to everything Java EE > solve these issues. In the end, we are collectively to blame for the dismal > state of affairs in Java EE land because of this sort of thing. > > > > On Feb 25, 2016, at 4:18 PM, Emily Jiang wrote: > > > > It would be nice if JavaEE Concurrency defines @Lock as a CDI > interceptor, similar to @Transactional . Since the JavaEE Concurrency spec > is stale as per you and Raze point out, how about experiment in DeltaSpike? > If DeltaSpike provides the support of @Lock, maybe it can be pushed to > JavaEE concurrency as part of EE8 update. If not, maybe CDI should define > an addendum for EE integration. I think we should seriously think about > this. > > > > > > > > Many thanks, > > Emily > > =========================== > > Emily Jiang > > WebSphere Application Server, CDI Development Lead > > > > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN > > Phone: +44 (0)1962 816278 Internal: 246278 > > > > Email: emijiang at uk.ibm.com > > Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > > > > > > > > > From: Stephan Knitelius > > To: Reza Rahman , Martin Kouba < > mkouba at redhat.com>, > > Cc: cdi-dev at lists.jboss.org > > Date: 25/02/2016 20:26 > > Subject: Re: [cdi-dev] Concurrency Control > > Sent by: cdi-dev-bounces at lists.jboss.org > > > > > > > > Hi Martin, > > > > yes this particular issue is about concurrent access control. You are > right in pointing out that the lock should be applied > > to the whole been and only override-able on a per method basis (similar > to EJB Singleton style locking). > > > > Regarding conversation context, its fair enough to point-out that weld > allows for configure the conversation lock timeout. > > However this is only true for Weld, this should really be made part of > the specification. > > > > Even if we were to specify a standard way to configure conversation > locked timeouts in the CDI specification, it would > > still make the conversation scope the odd one out of the lot. Hence it > would be more sensible to design a > > common way to handle concurrent access. > > > > Also I would argue that you cannot implement a common concurrent access > control via interceptors, > > since the container will preempt any interceptor based attempt for > conversation scoped beans. > > > > As Reza pointed out Oracle has no intend to reopen "Concurrency > Utilities for Java EE" at this time and is not > > willing to hand it over to anyone else. The same seems to be true for > JTA. > > > > Stephan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, 25 Feb 2016 at 15:50 Reza Rahman wrote: > > Oracle has pretty much clearly stated it has absolutely no intention of > updating the Java EE Concurrency Utilities specification any time soon. My > guess is that it will also never allow anyone else to update it either > since it owns that specification. If this is a valuable feature to the > community (which I definitely think it is) I strongly suggest taking > advantage of the fact that this is a gray area and include it in a modular > CDI specification so this feature doesn't continue to remain locked into > EJB for Java EE users that need to more effectively use things like > @Stereotype for service composition. > > > > > On Feb 25, 2016, at 9:13 AM, Martin Kouba wrote: > > > > > > Hi Stephan, > > > > > > I like the idea of CDI interceptor solution you're proposing in your > > > blogpost [1]. However, concurrency is a difficult topic. First of all, > > > this only solves concurrent access to the bean instance (i.e. > > > method-level locking) - the bean state is always up to the user. Also > > > I'm not so sure it's a good idea to only apply @Lock at the method > level > > > (some methods are guarded some not - AFAIK EJB does not allow this > either). > > > > > > I agree that conversation concurrentAccessTimeout in Weld should be > > > configurable. In fact, it should be possible to change this timeout > even > > > now using Weld API and org.jboss.weld.context.ConversationContext. But > > > it should be definitely more straightforward [2]. > > > > > > To sum it up - I wouldn't add concurrency control to the spec provided > > > it's implementable using interceptors. This is a similar situation as > to > > > javax.transaction.Transactional and JTA. The best place to specify this > > > is IMHO "Concurrency Utilities for Java EE". > > > > > > Martin > > > > > > [1] > > > http://www.knitelius.com/2016/01/25/concurrency-control-for-cdi/ > > > > > > [2] > > > https://issues.jboss.org/browse/WELD-2113 > > > > > > Dne 24.2.2016 v 20:47 Stephan Knitelius napsal(a): > > >> I just want to bring this to everyone attention one more time. > > >> > > >> The conversation scope concurrency control mechanism seems to be a > > >> frequent point of pain in many projects. > > >> > > >> Especially when working with browser triggered asynchronous requests, > > >> you can not rely on client-sided request synchronization. > > >> Weld, unlike OWB, grants a 1 second timeout prior to throwing a (the > > >> specified) BusyConversationException mitigating the effect a bit. > > >> > > >> This is a rather strict un-configurable type of CC. Also its > > >> completely out of alignment with the other build-in scopes, offering > no > > >> CC what so ever. > > >> > > >> In the cases of Session- and Application-Scope, thread handling is > left > > >> entirely to the developer, even so they are just as vulnerable in AJAX > > >> environments. > > >> > > >> We should really consider introducing a common configurable mechanism, > > >> that is aligned across all scopes (obviously accounting for backwards > > >> compatibility in the case of conversation scope). > > >> > > >> Would really appreciate some feedback. > > >> > > >> Kind regards, > > >> > > >> Stephan > > >> > > >> > > >> > > >> > > >> On Mon, 22 Feb 2016 at 23:10 Reza Rahman > >> > wrote: > > >> > > >> We've discussed this issue before. I definitely still think @Lock > > >> belongs in a modular CDI specification. It would be highly useful > to > > >> both @Singleton and @ApplicationScoped. Today if I need to use > > >> declarative concurrency control for a shared component I am > > >> essentially forced to use EJB singleton - which shouldn't be the > > >> case and perhaps should not have been the case past Java EE 6. > > >> > > >> > > >>> On 2/19/2016 5:27 AM, Stephan Knitelius wrote: > > >>> Hi all, > > >>> > > >>> CDI spec does not define a common concurrency control mechanism. > > >>> The time any type of concurrency control is mentioned is in > > >>> conjunction with EJB and a rather restrictive one for conversation > > >>> context. > > >>> > > >>> CDI Spec: > > >>> The container ensures that a long-running conversation may be > > >>> associated with at most one request at a time, by blocking or > > >>> rejecting concurrent requests. If the container rejects a request, > > >>> it must associate the request with a new transient conversation > > >>> and throw an exception of > > >>> type|javax.enterprise.context.BusyConversationException|. > > >>> > > >>> > > >>> It would be helpful if a common configurable concurrency mechanism > > >>> (EJB Singleton style locking?) could be established for all normal > > >>> scopes. > > >>> > > >>> What are your thoughts on this? > > >>> > > >>> Regards, > > >>> > > >>> Stephan > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> ______________________________________ > > >>> *Stephan Knitelius* > > >>> Alteburger Str. 274 > > >>> 50968 K?ln / Cologne > > >>> Deutschland / Germany > > >>> stephan at knitelius.com > > >>> > > >>> > > >>> _______________________________________________ > > >>> cdi-dev mailing list > > >>> cdi-dev at lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/cdi-dev > > >>> > > >>> Note that for all code provided on this list, the provider > licenses the code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > >> > > >> _______________________________________________ > > >> cdi-dev mailing list > > >> cdi-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > > >> > > >> Note that for all code provided on this list, the provider licenses > > >> the code under the Apache License, Version 2 > > >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > > >> ideas provided on this list, the provider waives all patent and > > >> other intellectual property rights inherent in such information. > > >> > > >> > > >> > > >> _______________________________________________ > > >> cdi-dev mailing list > > >> cdi-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > > >> > > >> Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > > > > -- > > > Martin Kouba > > > Software Engineer > > > Red Hat, Czech Republic > > > _______________________________________________ > > > cdi-dev mailing list > > > cdi-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > > > Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such > information._______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU_______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20160226/525ab6e5/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 63, Issue 36 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160226/8a4b5cca/attachment-0001.html From reza_rahman at lycos.com Fri Feb 26 12:12:35 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Fri, 26 Feb 2016 12:12:35 -0500 Subject: [cdi-dev] Concurrency Control In-Reply-To: References: Message-ID: <1D4BD148-BEF9-4A03-92CA-89192A863BAC@lycos.com> In parallel to whatever does or does not happen here, want to take up this discussion in the Java EE 8 EG? It will be good since you are an EG member and also had involvement in the EC. I think for now you can mention Stephan as a spec lead from the community with maybe Oracle being a co-spec lead to help ease any IP heartache that Oracle might get from this. What would be awesome of course is if Red Hat proposed to do this work and took over one more JSR from Oracle, but I won't hold my breadth on that one :-). > On Feb 26, 2016, at 11:39 AM, Werner Keil wrote: > > Reza/all, > > One of the biggest problems with can Concurrency Utilities is, that it started in 2003, then went "dormant" (before the term existed) and was revived to be finalized 10 years later after little or no proper alignment with then state of the art Java EE standards and technologies. It duplicates things, especially in EJB or CDI. > > Similar to the even older JSR 107 which also has similar problems and technical debt (as members of this and other EGs confirmed or expressed their concern) > We can't undo many of these problems, but it seems both these "relics" need at the very least a solid MR if not entirely new JSRs (before EE 8 wraps up the selected features) to address their age and fit in more nicely into the recent platform) JMS 2 did a great job in that direction and even has a new JSR for Java EE 8. > > Regards, > > Werner > >> On Fri, Feb 26, 2016 at 12:40 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: Concurrency Control (Reza Rahman) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Fri, 26 Feb 2016 06:40:38 -0500 >> From: Reza Rahman >> Subject: Re: [cdi-dev] Concurrency Control >> To: Emily Jiang >> Cc: cdi-dev at lists.jboss.org >> Message-ID: <7313A4E6-24FA-4427-964A-BADF7FBE4FB8 at lycos.com> >> Content-Type: text/plain; charset="utf-8" >> >> No objections whatsoever. I will put in the JIRAs ASAP so we can give this the attention it deserves. >> >> > On Feb 26, 2016, at 4:32 AM, Emily Jiang wrote: >> > >> > Hi Reza, >> > >> > I understand your frustration. I would suggest you raising a CDI jira to get all options discussed. Any objections? >> > >> > Many thanks, >> > Emily >> > =========================== >> > Emily Jiang >> > WebSphere Application Server, CDI Development Lead >> > >> > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN >> > Phone: +44 (0)1962 816278 Internal: 246278 >> > >> > Email: emijiang at uk.ibm.com >> > Lotus Notes: Emily Jiang/UK/IBM at IBMGB >> > >> > >> > >> > >> > From: Reza Rahman >> > To: Emily Jiang/UK/IBM at IBMGB, >> > Cc: cdi-dev at lists.jboss.org >> > Date: 25/02/2016 23:01 >> > Subject: Re: [cdi-dev] Concurrency Control >> > Sent by: cdi-dev-bounces at lists.jboss.org >> > >> > >> > >> > This is not just a problem with this one feature but a much broader one involving @Asynchronous, @Schedule and many others. Simply punting on this problem and not dealing with this class of problems vigorously is rather foolish. It winds up doing what it has done for years - undermining pretty much all efforts related to Java EE, especially compared to the velocity and effectiveness by which the clear competitors to everything Java EE solve these issues. In the end, we are collectively to blame for the dismal state of affairs in Java EE land because of this sort of thing. >> > >> > On Feb 25, 2016, at 4:18 PM, Emily Jiang wrote: >> > >> > It would be nice if JavaEE Concurrency defines @Lock as a CDI interceptor, similar to @Transactional . Since the JavaEE Concurrency spec is stale as per you and Raze point out, how about experiment in DeltaSpike? If DeltaSpike provides the support of @Lock, maybe it can be pushed to JavaEE concurrency as part of EE8 update. If not, maybe CDI should define an addendum for EE integration. I think we should seriously think about this. >> > >> > >> > >> > Many thanks, >> > Emily >> > =========================== >> > Emily Jiang >> > WebSphere Application Server, CDI Development Lead >> > >> > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN >> > Phone: +44 (0)1962 816278 Internal: 246278 >> > >> > Email: emijiang at uk.ibm.com >> > Lotus Notes: Emily Jiang/UK/IBM at IBMGB >> > >> > >> > >> > >> > From: Stephan Knitelius >> > To: Reza Rahman , Martin Kouba , >> > Cc: cdi-dev at lists.jboss.org >> > Date: 25/02/2016 20:26 >> > Subject: Re: [cdi-dev] Concurrency Control >> > Sent by: cdi-dev-bounces at lists.jboss.org >> > >> > >> > >> > Hi Martin, >> > >> > yes this particular issue is about concurrent access control. You are right in pointing out that the lock should be applied >> > to the whole been and only override-able on a per method basis (similar to EJB Singleton style locking). >> > >> > Regarding conversation context, its fair enough to point-out that weld allows for configure the conversation lock timeout. >> > However this is only true for Weld, this should really be made part of the specification. >> > >> > Even if we were to specify a standard way to configure conversation locked timeouts in the CDI specification, it would >> > still make the conversation scope the odd one out of the lot. Hence it would be more sensible to design a >> > common way to handle concurrent access. >> > >> > Also I would argue that you cannot implement a common concurrent access control via interceptors, >> > since the container will preempt any interceptor based attempt for conversation scoped beans. >> > >> > As Reza pointed out Oracle has no intend to reopen "Concurrency Utilities for Java EE" at this time and is not >> > willing to hand it over to anyone else. The same seems to be true for JTA. >> > >> > Stephan >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > On Thu, 25 Feb 2016 at 15:50 Reza Rahman wrote: >> > Oracle has pretty much clearly stated it has absolutely no intention of updating the Java EE Concurrency Utilities specification any time soon. My guess is that it will also never allow anyone else to update it either since it owns that specification. If this is a valuable feature to the community (which I definitely think it is) I strongly suggest taking advantage of the fact that this is a gray area and include it in a modular CDI specification so this feature doesn't continue to remain locked into EJB for Java EE users that need to more effectively use things like @Stereotype for service composition. >> > >> > > On Feb 25, 2016, at 9:13 AM, Martin Kouba wrote: >> > > >> > > Hi Stephan, >> > > >> > > I like the idea of CDI interceptor solution you're proposing in your >> > > blogpost [1]. However, concurrency is a difficult topic. First of all, >> > > this only solves concurrent access to the bean instance (i.e. >> > > method-level locking) - the bean state is always up to the user. Also >> > > I'm not so sure it's a good idea to only apply @Lock at the method level >> > > (some methods are guarded some not - AFAIK EJB does not allow this either). >> > > >> > > I agree that conversation concurrentAccessTimeout in Weld should be >> > > configurable. In fact, it should be possible to change this timeout even >> > > now using Weld API and org.jboss.weld.context.ConversationContext. But >> > > it should be definitely more straightforward [2]. >> > > >> > > To sum it up - I wouldn't add concurrency control to the spec provided >> > > it's implementable using interceptors. This is a similar situation as to >> > > javax.transaction.Transactional and JTA. The best place to specify this >> > > is IMHO "Concurrency Utilities for Java EE". >> > > >> > > Martin >> > > >> > > [1] >> > > http://www.knitelius.com/2016/01/25/concurrency-control-for-cdi/ >> > > >> > > [2] >> > > https://issues.jboss.org/browse/WELD-2113 >> > > >> > > Dne 24.2.2016 v 20:47 Stephan Knitelius napsal(a): >> > >> I just want to bring this to everyone attention one more time. >> > >> >> > >> The conversation scope concurrency control mechanism seems to be a >> > >> frequent point of pain in many projects. >> > >> >> > >> Especially when working with browser triggered asynchronous requests, >> > >> you can not rely on client-sided request synchronization. >> > >> Weld, unlike OWB, grants a 1 second timeout prior to throwing a (the >> > >> specified) BusyConversationException mitigating the effect a bit. >> > >> >> > >> This is a rather strict un-configurable type of CC. Also its >> > >> completely out of alignment with the other build-in scopes, offering no >> > >> CC what so ever. >> > >> >> > >> In the cases of Session- and Application-Scope, thread handling is left >> > >> entirely to the developer, even so they are just as vulnerable in AJAX >> > >> environments. >> > >> >> > >> We should really consider introducing a common configurable mechanism, >> > >> that is aligned across all scopes (obviously accounting for backwards >> > >> compatibility in the case of conversation scope). >> > >> >> > >> Would really appreciate some feedback. >> > >> >> > >> Kind regards, >> > >> >> > >> Stephan >> > >> >> > >> >> > >> >> > >> >> > >> On Mon, 22 Feb 2016 at 23:10 Reza Rahman > > >> > wrote: >> > >> >> > >> We've discussed this issue before. I definitely still think @Lock >> > >> belongs in a modular CDI specification. It would be highly useful to >> > >> both @Singleton and @ApplicationScoped. Today if I need to use >> > >> declarative concurrency control for a shared component I am >> > >> essentially forced to use EJB singleton - which shouldn't be the >> > >> case and perhaps should not have been the case past Java EE 6. >> > >> >> > >> >> > >>> On 2/19/2016 5:27 AM, Stephan Knitelius wrote: >> > >>> Hi all, >> > >>> >> > >>> CDI spec does not define a common concurrency control mechanism. >> > >>> The time any type of concurrency control is mentioned is in >> > >>> conjunction with EJB and a rather restrictive one for conversation >> > >>> context. >> > >>> >> > >>> CDI Spec: >> > >>> The container ensures that a long-running conversation may be >> > >>> associated with at most one request at a time, by blocking or >> > >>> rejecting concurrent requests. If the container rejects a request, >> > >>> it must associate the request with a new transient conversation >> > >>> and throw an exception of >> > >>> type|javax.enterprise.context.BusyConversationException|. >> > >>> >> > >>> >> > >>> It would be helpful if a common configurable concurrency mechanism >> > >>> (EJB Singleton style locking?) could be established for all normal >> > >>> scopes. >> > >>> >> > >>> What are your thoughts on this? >> > >>> >> > >>> Regards, >> > >>> >> > >>> Stephan >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> ______________________________________ >> > >>> *Stephan Knitelius* >> > >>> Alteburger Str. 274 >> > >>> 50968 K?ln / Cologne >> > >>> Deutschland / Germany >> > >>> stephan at knitelius.com >> > >>> >> > >>> >> > >>> _______________________________________________ >> > >>> cdi-dev mailing list >> > >>> cdi-dev at lists.jboss.org >> > >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> > >>> >> > >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> > >> >> > >> _______________________________________________ >> > >> cdi-dev mailing list >> > >> cdi-dev at lists.jboss.org >> > >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> > >> >> > >> Note that for all code provided on this list, the provider licenses >> > >> the code under the Apache License, Version 2 >> > >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >> > >> ideas provided on this list, the provider waives all patent and >> > >> other intellectual property rights inherent in such information. >> > >> >> > >> >> > >> >> > >> _______________________________________________ >> > >> cdi-dev mailing list >> > >> cdi-dev at lists.jboss.org >> > >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> > >> >> > >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> > > >> > > -- >> > > Martin Kouba >> > > Software Engineer >> > > Red Hat, Czech Republic >> > > _______________________________________________ >> > > cdi-dev mailing list >> > > cdi-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/cdi-dev >> > > >> > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information._______________________________________________ >> > cdi-dev mailing list >> > cdi-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/cdi-dev >> > >> > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> > >> > Unless stated otherwise above: >> > IBM United Kingdom Limited - Registered in England and Wales with number 741598. >> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU_______________________________________________ >> > cdi-dev mailing list >> > cdi-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/cdi-dev >> > >> > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> > >> > Unless stated otherwise above: >> > IBM United Kingdom Limited - Registered in England and Wales with number 741598. >> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160226/525ab6e5/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 63, Issue 36 >> *************************************** > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.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/20160226/72e9e090/attachment-0001.html From issues at jboss.org Sun Feb 28 12:02:00 2016 From: issues at jboss.org (Reza Rahman (JIRA)) Date: Sun, 28 Feb 2016 12:02:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-582) Configurable concurrency control for CDI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13169250#comment-13169250 ] Reza Rahman commented on CDI-582: --------------------------------- I think this is very important and way past due to further broaden CDI adoption. I'd say this class of CDI features is probably more important than what is currently slated for CDI 2 (which I seriously fear will be basically ignored as low-level stuff not relevant to most real world potential and current CDI users). > Configurable concurrency control for CDI > ---------------------------------------- > > Key: CDI-582 > URL: https://issues.jboss.org/browse/CDI-582 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 2.0-EDR1 > Reporter: Stephan Knitelius > > Currently the spec only defines, a non-configurable, concurrency control mechanism for conversation scope. All other build-in scopes remain unprotected, relaying on the developer. > It would be useful to introduce EJB Singleton style concurrency control for CDI scopes. > Allowing the developer to configure the concurrency behavior of ConversationScoped beans, and defining concurrency control for the other build-in scopes. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From struberg at yahoo.de Sun Feb 28 13:16:57 2016 From: struberg at yahoo.de (Mark Struberg) Date: Sun, 28 Feb 2016 19:16:57 +0100 Subject: [cdi-dev] Concurrency Control In-Reply-To: References: Message-ID: <40D8D200-79F6-4422-BAA9-81A119AC53F2@yahoo.de> > Am 26.02.2016 um 17:39 schrieb Werner Keil : > > Reza/all, > > One of the biggest problems with Concurrency Utilities is, that it started in 2003, then went "dormant" (before the term existed) and was revived to be finalized 10 years later after little or no proper alignment with then state of the art Java EE standards and technologies. It duplicates things, especially in EJB or CDI. > +1 that pretty much sums it up. Concurrency utils is pretty much broken and unusable as it is today. :/ Anyway, let?s not fight the past - we need a way forward. LieGrue, strub From rmannibucau at gmail.com Sun Feb 28 13:29:41 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sun, 28 Feb 2016 19:29:41 +0100 Subject: [cdi-dev] Concurrency Control In-Reply-To: <40D8D200-79F6-4422-BAA9-81A119AC53F2@yahoo.de> References: <40D8D200-79F6-4422-BAA9-81A119AC53F2@yahoo.de> Message-ID: At apache we have subprojects which can become top level project if they behaves well. Would it be possible at EE level? Idea would be to have cdi-concurrency subspec (under CDI umbrella but not part of CDI itself - know there was appendix in bval for instance). Then for EE 9 if the subspec is proven as good it would become its own spec. wdyt? Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2016-02-28 19:16 GMT+01:00 Mark Struberg : > > > Am 26.02.2016 um 17:39 schrieb Werner Keil : > > > > Reza/all, > > > > One of the biggest problems with Concurrency Utilities is, that it > started in 2003, then went "dormant" (before the term existed) and was > revived to be finalized 10 years later after little or no proper alignment > with then state of the art Java EE standards and technologies. It > duplicates things, especially in EJB or CDI. > > > > +1 that pretty much sums it up. Concurrency utils is pretty much broken > and unusable as it is today. :/ > > Anyway, let?s not fight the past - we need a way forward. > > LieGrue, > strub > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160228/f3a90785/attachment.html From reza_rahman at lycos.com Sun Feb 28 13:59:07 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Sun, 28 Feb 2016 13:59:07 -0500 Subject: [cdi-dev] Concurrency Control In-Reply-To: References: <40D8D200-79F6-4422-BAA9-81A119AC53F2@yahoo.de> Message-ID: I am unsure what this means. Firstly I think this functionality is way overdue. Secondly I see little value to having anything that is a pseudo-standard. I'd rather see the effort pursue another path to standardization or remain completely independent while clearly pointing out what the obstacles to standardization are/were. On the other hand if this is required to be implemented in Java EE 8 runtimes I don't think it matters what the particular structural gymnastics are. Purely from a JCP standpoint, it is possible to have a sub-specification but only if the eventual goal is to spin it out into a separate specification. Examples of this are JPA, interceptors and others. There is no precedent for an "incubator" specification that is somehow optional. In fact I am pretty sure the current JCP rules would disallow this. > On Feb 28, 2016, at 1:29 PM, Romain Manni-Bucau wrote: > > At apache we have subprojects which can become top level project if they behaves well. Would it be possible at EE level? Idea would be to have cdi-concurrency subspec (under CDI umbrella but not part of CDI itself - know there was appendix in bval for instance). Then for EE 9 if the subspec is proven as good it would become its own spec. wdyt? > > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > 2016-02-28 19:16 GMT+01:00 Mark Struberg : >> >> > Am 26.02.2016 um 17:39 schrieb Werner Keil : >> > >> > Reza/all, >> > >> > One of the biggest problems with Concurrency Utilities is, that it started in 2003, then went "dormant" (before the term existed) and was revived to be finalized 10 years later after little or no proper alignment with then state of the art Java EE standards and technologies. It duplicates things, especially in EJB or CDI. >> > >> >> +1 that pretty much sums it up. Concurrency utils is pretty much broken and unusable as it is today. :/ >> >> Anyway, let?s not fight the past - we need a way forward. >> >> LieGrue, >> strub >> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160228/b735c574/attachment.html From werner.keil at gmail.com Sun Feb 28 14:08:18 2016 From: werner.keil at gmail.com (Werner Keil) Date: Sun, 28 Feb 2016 20:08:18 +0100 Subject: [cdi-dev] Concurrency Control Message-ID: Yes, there's no "incubating" stage for JSRs other than "not Final", so as soon as a JSR or parts of it are final, they become part of an umbrella spec if that spec wants to contain them. Potentially from Java EE 9 on there could be much finer grained activation or deactivation of features and profiles as soon as the whole Jigsaw thing and SE 9 is out, but until then I think we' have to stick to what's available right now. For CDI 2 modularity or running in Java SE are already in scope, but other than e.g. having "ee-concurrency" only in the Java EE profile of CDI, I don't see how CDI should do things the platform will provide later anyway. Regards, Werner On Sun, Feb 28, 2016 at 7:59 PM, Reza Rahman wrote: > I am unsure what this means. Firstly I think this functionality is way > overdue. Secondly I see little value to having anything that is a > pseudo-standard. I'd rather see the effort pursue another path to > standardization or remain completely independent while clearly pointing out > what the obstacles to standardization are/were. > > On the other hand if this is required to be implemented in Java EE 8 > runtimes I don't think it matters what the particular structural gymnastics > are. Purely from a JCP standpoint, it is possible to have a > sub-specification but only if the eventual goal is to spin it out into a > separate specification. Examples of this are JPA, interceptors and others. > There is no precedent for an "incubator" specification that is somehow > optional. In fact I am pretty sure the current JCP rules would disallow > this. > > On Feb 28, 2016, at 1:29 PM, Romain Manni-Bucau > wrote: > > At apache we have subprojects which can become top level project if they > behaves well. Would it be possible at EE level? Idea would be to have > cdi-concurrency subspec (under CDI umbrella but not part of CDI itself - > know there was appendix in bval for instance). Then for EE 9 if the subspec > is proven as good it would become its own spec. wdyt? > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2016-02-28 19:16 GMT+01:00 Mark Struberg : > >> >> > Am 26.02.2016 um 17:39 schrieb Werner Keil : >> > >> > Reza/all, >> > >> > One of the biggest problems with Concurrency Utilities is, that it >> started in 2003, then went "dormant" (before the term existed) and was >> revived to be finalized 10 years later after little or no proper alignment >> with then state of the art Java EE standards and technologies. It >> duplicates things, especially in EJB or CDI. >> > >> >> +1 that pretty much sums it up. Concurrency utils is pretty much broken >> and unusable as it is today. :/ >> >> Anyway, let?s not fight the past - we need a way forward. >> >> LieGrue, >> strub >> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160228/4409ed44/attachment-0001.html From rmannibucau at gmail.com Sun Feb 28 14:10:51 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sun, 28 Feb 2016 20:10:51 +0100 Subject: [cdi-dev] Concurrency Control In-Reply-To: References: Message-ID: 2016-02-28 20:08 GMT+01:00 Werner Keil : > Yes, there's no "incubating" stage for JSRs other than "not Final", so as > soon as a JSR or parts of it are final, they become part of an umbrella > spec if that spec wants to contain them. > > Potentially from Java EE 9 on there could be much finer grained activation > or deactivation of features and profiles as soon as the whole Jigsaw thing > and SE 9 is out, but until then I think we' have to stick to what's > available right now. > > For CDI 2 modularity or running in Java SE are already in scope, but other > than e.g. having "ee-concurrency" only in the Java EE profile of CDI, I > don't see how CDI should do things the platform will provide later anyway. > > Fully agree, means @Lock shouldnt go in CDI as everyone stated so falling back on CDI cause concurrency spec is inactive is a bad choice. Question leaves CDI list then and is: how to make concurrency active? > Regards, > > Werner > > On Sun, Feb 28, 2016 at 7:59 PM, Reza Rahman > wrote: > >> I am unsure what this means. Firstly I think this functionality is way >> overdue. Secondly I see little value to having anything that is a >> pseudo-standard. I'd rather see the effort pursue another path to >> standardization or remain completely independent while clearly pointing out >> what the obstacles to standardization are/were. >> >> On the other hand if this is required to be implemented in Java EE 8 >> runtimes I don't think it matters what the particular structural gymnastics >> are. Purely from a JCP standpoint, it is possible to have a >> sub-specification but only if the eventual goal is to spin it out into a >> separate specification. Examples of this are JPA, interceptors and others. >> There is no precedent for an "incubator" specification that is somehow >> optional. In fact I am pretty sure the current JCP rules would disallow >> this. >> >> On Feb 28, 2016, at 1:29 PM, Romain Manni-Bucau >> wrote: >> >> At apache we have subprojects which can become top level project if they >> behaves well. Would it be possible at EE level? Idea would be to have >> cdi-concurrency subspec (under CDI umbrella but not part of CDI itself - >> know there was appendix in bval for instance). Then for EE 9 if the subspec >> is proven as good it would become its own spec. wdyt? >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> 2016-02-28 19:16 GMT+01:00 Mark Struberg : >> >>> >>> > Am 26.02.2016 um 17:39 schrieb Werner Keil : >>> > >>> > Reza/all, >>> > >>> > One of the biggest problems with Concurrency Utilities is, that it >>> started in 2003, then went "dormant" (before the term existed) and was >>> revived to be finalized 10 years later after little or no proper alignment >>> with then state of the art Java EE standards and technologies. It >>> duplicates things, especially in EJB or CDI. >>> > >>> >>> +1 that pretty much sums it up. Concurrency utils is pretty much broken >>> and unusable as it is today. :/ >>> >>> Anyway, let?s not fight the past - we need a way forward. >>> >>> LieGrue, >>> strub >>> >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>> provided on this list, the provider waives all patent and other >>> intellectual property rights inherent in such information. >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160228/947312b7/attachment.html From reza_rahman at lycos.com Sun Feb 28 14:25:53 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Sun, 28 Feb 2016 14:25:53 -0500 Subject: [cdi-dev] Concurrency Control In-Reply-To: References: Message-ID: <5E76B98D-F530-4D0D-B404-8995286B39D9@lycos.com> I am not so sure "everyone stated" this shouldn't be part of CDI. As some of us have already pointed out there might be a case for including it in CDI anyway and this should be part of the discussion equation here and elsewhere. Indeed I suggest putting together a questionnaire on this with the options that "everyone" on this EG indeed does vote on... > On Feb 28, 2016, at 2:10 PM, Romain Manni-Bucau wrote: > > > 2016-02-28 20:08 GMT+01:00 Werner Keil : >> Yes, there's no "incubating" stage for JSRs other than "not Final", so as soon as a JSR or parts of it are final, they become part of an umbrella spec if that spec wants to contain them. >> >> Potentially from Java EE 9 on there could be much finer grained activation or deactivation of features and profiles as soon as the whole Jigsaw thing and SE 9 is out, but until then I think we' have to stick to what's available right now. >> >> For CDI 2 modularity or running in Java SE are already in scope, but other than e.g. having "ee-concurrency" only in the Java EE profile of CDI, I don't see how CDI should do things the platform will provide later anyway. >> > > Fully agree, means @Lock shouldnt go in CDI as everyone stated so falling back on CDI cause concurrency spec is inactive is a bad choice. Question leaves CDI list then and is: how to make concurrency active? > >> Regards, >> Werner >> >>> On Sun, Feb 28, 2016 at 7:59 PM, Reza Rahman wrote: >>> I am unsure what this means. Firstly I think this functionality is way overdue. Secondly I see little value to having anything that is a pseudo-standard. I'd rather see the effort pursue another path to standardization or remain completely independent while clearly pointing out what the obstacles to standardization are/were. >>> >>> On the other hand if this is required to be implemented in Java EE 8 runtimes I don't think it matters what the particular structural gymnastics are. Purely from a JCP standpoint, it is possible to have a sub-specification but only if the eventual goal is to spin it out into a separate specification. Examples of this are JPA, interceptors and others. There is no precedent for an "incubator" specification that is somehow optional. In fact I am pretty sure the current JCP rules would disallow this. >>> >>> On Feb 28, 2016, at 1:29 PM, Romain Manni-Bucau wrote: >>> >>>> At apache we have subprojects which can become top level project if they behaves well. Would it be possible at EE level? Idea would be to have cdi-concurrency subspec (under CDI umbrella but not part of CDI itself - know there was appendix in bval for instance). Then for EE 9 if the subspec is proven as good it would become its own spec. wdyt? >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>> >>>> 2016-02-28 19:16 GMT+01:00 Mark Struberg : >>>>> >>>>> > Am 26.02.2016 um 17:39 schrieb Werner Keil : >>>>> > >>>>> > Reza/all, >>>>> > >>>>> > One of the biggest problems with Concurrency Utilities is, that it started in 2003, then went "dormant" (before the term existed) and was revived to be finalized 10 years later after little or no proper alignment with then state of the art Java EE standards and technologies. It duplicates things, especially in EJB or CDI. >>>>> > >>>>> >>>>> +1 that pretty much sums it up. Concurrency utils is pretty much broken and unusable as it is today. :/ >>>>> >>>>> Anyway, let?s not fight the past - we need a way forward. >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160228/770115fc/attachment-0001.html From arjan.tijms at gmail.com Sun Feb 28 17:13:23 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Sun, 28 Feb 2016 23:13:23 +0100 Subject: [cdi-dev] Concurrency Control In-Reply-To: <5E76B98D-F530-4D0D-B404-8995286B39D9@lycos.com> References: <5E76B98D-F530-4D0D-B404-8995286B39D9@lycos.com> Message-ID: What are exactly the rules of making something a sub-spec? There have been various examples of this in the past. Reza mentioned JPA, which started as a sub-spec of EJB, even though it was not directly split off from an existing EJB API (you could say it was conceptually a re-imagined EJB Entity Bean, but JPA entities are different enough to stand on their own). I wonder what the decisions were at the time to go for a sub-spec, instead of either directly putting it in EJB on the one hand, or going right away for a top-level spec on the other hand. Regardless, I think this points out a (practical) weakness in the Java EE umbrella/constituent specs setup. In general we like to split things out into several specs, so that those specs can evolve on their own and are useable by the rest of the platform. E.g. EL is a great example, it's now separate, and can be used everywhere without a dependency on say JSP or JSF. But the fact that top level specs need to be individually "active" and must each have assembled their own EG, is a serious process overhead. This is specifically so because with the current Java EE process not all constituent specs are active/open by default for a given spec cycle. On Sun, Feb 28, 2016 at 8:25 PM, Reza Rahman wrote: > I am not so sure "everyone stated" this shouldn't be part of CDI. As some > of us have already pointed out there might be a case for including it in > CDI anyway and this should be part of the discussion equation here and > elsewhere. Indeed I suggest putting together a questionnaire on this with > the options that "everyone" on this EG indeed does vote on... > > On Feb 28, 2016, at 2:10 PM, Romain Manni-Bucau > wrote: > > > 2016-02-28 20:08 GMT+01:00 Werner Keil : > >> Yes, there's no "incubating" stage for JSRs other than "not Final", so as >> soon as a JSR or parts of it are final, they become part of an umbrella >> spec if that spec wants to contain them. >> >> Potentially from Java EE 9 on there could be much finer grained >> activation or deactivation of features and profiles as soon as the whole >> Jigsaw thing and SE 9 is out, but until then I think we' have to stick to >> what's available right now. >> >> For CDI 2 modularity or running in Java SE are already in scope, but >> other than e.g. having "ee-concurrency" only in the Java EE profile of CDI, >> I don't see how CDI should do things the platform will provide later anyway. >> >> > Fully agree, means @Lock shouldnt go in CDI as everyone stated so falling > back on CDI cause concurrency spec is inactive is a bad choice. Question > leaves CDI list then and is: how to make concurrency active? > > >> Regards, >> >> Werner >> >> On Sun, Feb 28, 2016 at 7:59 PM, Reza Rahman >> wrote: >> >>> I am unsure what this means. Firstly I think this functionality is way >>> overdue. Secondly I see little value to having anything that is a >>> pseudo-standard. I'd rather see the effort pursue another path to >>> standardization or remain completely independent while clearly pointing out >>> what the obstacles to standardization are/were. >>> >>> On the other hand if this is required to be implemented in Java EE 8 >>> runtimes I don't think it matters what the particular structural gymnastics >>> are. Purely from a JCP standpoint, it is possible to have a >>> sub-specification but only if the eventual goal is to spin it out into a >>> separate specification. Examples of this are JPA, interceptors and others. >>> There is no precedent for an "incubator" specification that is somehow >>> optional. In fact I am pretty sure the current JCP rules would disallow >>> this. >>> >>> On Feb 28, 2016, at 1:29 PM, Romain Manni-Bucau >>> wrote: >>> >>> At apache we have subprojects which can become top level project if they >>> behaves well. Would it be possible at EE level? Idea would be to have >>> cdi-concurrency subspec (under CDI umbrella but not part of CDI itself - >>> know there was appendix in bval for instance). Then for EE 9 if the subspec >>> is proven as good it would become its own spec. wdyt? >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog >>> | Github >>> | LinkedIn >>> | Tomitriber >>> >>> >>> 2016-02-28 19:16 GMT+01:00 Mark Struberg : >>> >>>> >>>> > Am 26.02.2016 um 17:39 schrieb Werner Keil : >>>> > >>>> > Reza/all, >>>> > >>>> > One of the biggest problems with Concurrency Utilities is, that it >>>> started in 2003, then went "dormant" (before the term existed) and was >>>> revived to be finalized 10 years later after little or no proper alignment >>>> with then state of the art Java EE standards and technologies. It >>>> duplicates things, especially in EJB or CDI. >>>> > >>>> >>>> +1 that pretty much sums it up. Concurrency utils is pretty much broken >>>> and unusable as it is today. :/ >>>> >>>> Anyway, let?s not fight the past - we need a way forward. >>>> >>>> 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160228/bab4b4d1/attachment.html From reza_rahman at lycos.com Sun Feb 28 17:32:31 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Sun, 28 Feb 2016 17:32:31 -0500 Subject: [cdi-dev] Concurrency Control In-Reply-To: References: <5E76B98D-F530-4D0D-B404-8995286B39D9@lycos.com> Message-ID: <56150E68-7E47-4E57-B469-96D63689ADEA@lycos.com> This is a good question indeed. In the past the real stated rationale for a sub-spec was eventual or possible separation. It's a question that should be posed in the Java EE EG or even the EC. In the case of JPA/EJB there is an official reason and perhaps a few ulterior ones. The official reason is that the EJB EG had the initial skill set to deal with JPA but the spec should be eventually separate. Unofficially my guess is that too many vendors had bought into EJB Entity Beans for too long and they needed to deal it a soft blow to make themselves look better instead of a hard and fast death blow. Saving EJB from total collapse right away might have also been a motive and also giving Gavin/Red Hat less credit for Java EE 5 than he/they deserved... > On Feb 28, 2016, at 5:13 PM, arjan tijms wrote: > > What are exactly the rules of making something a sub-spec? > > There have been various examples of this in the past. Reza mentioned JPA, which started as a sub-spec of EJB, even though it was not directly split off from an existing EJB API (you could say it was conceptually a re-imagined EJB Entity Bean, but JPA entities are different enough to stand on their own). > > I wonder what the decisions were at the time to go for a sub-spec, instead of either directly putting it in EJB on the one hand, or going right away for a top-level spec on the other hand. > > Regardless, I think this points out a (practical) weakness in the Java EE umbrella/constituent specs setup. In general we like to split things out into several specs, so that those specs can evolve on their own and are useable by the rest of the platform. E.g. EL is a great example, it's now separate, and can be used everywhere without a dependency on say JSP or JSF. > > But the fact that top level specs need to be individually "active" and must each have assembled their own EG, is a serious process overhead. This is specifically so because with the current Java EE process not all constituent specs are active/open by default for a given spec cycle. > > >> On Sun, Feb 28, 2016 at 8:25 PM, Reza Rahman wrote: >> I am not so sure "everyone stated" this shouldn't be part of CDI. As some of us have already pointed out there might be a case for including it in CDI anyway and this should be part of the discussion equation here and elsewhere. Indeed I suggest putting together a questionnaire on this with the options that "everyone" on this EG indeed does vote on... >> >>> On Feb 28, 2016, at 2:10 PM, Romain Manni-Bucau wrote: >>> >>> >>> 2016-02-28 20:08 GMT+01:00 Werner Keil : >>>> Yes, there's no "incubating" stage for JSRs other than "not Final", so as soon as a JSR or parts of it are final, they become part of an umbrella spec if that spec wants to contain them. >>>> >>>> Potentially from Java EE 9 on there could be much finer grained activation or deactivation of features and profiles as soon as the whole Jigsaw thing and SE 9 is out, but until then I think we' have to stick to what's available right now. >>>> >>>> For CDI 2 modularity or running in Java SE are already in scope, but other than e.g. having "ee-concurrency" only in the Java EE profile of CDI, I don't see how CDI should do things the platform will provide later anyway. >>> >>> Fully agree, means @Lock shouldnt go in CDI as everyone stated so falling back on CDI cause concurrency spec is inactive is a bad choice. Question leaves CDI list then and is: how to make concurrency active? >>> >>>> Regards, >>>> Werner >>>> >>>>> On Sun, Feb 28, 2016 at 7:59 PM, Reza Rahman wrote: >>>>> I am unsure what this means. Firstly I think this functionality is way overdue. Secondly I see little value to having anything that is a pseudo-standard. I'd rather see the effort pursue another path to standardization or remain completely independent while clearly pointing out what the obstacles to standardization are/were. >>>>> >>>>> On the other hand if this is required to be implemented in Java EE 8 runtimes I don't think it matters what the particular structural gymnastics are. Purely from a JCP standpoint, it is possible to have a sub-specification but only if the eventual goal is to spin it out into a separate specification. Examples of this are JPA, interceptors and others. There is no precedent for an "incubator" specification that is somehow optional. In fact I am pretty sure the current JCP rules would disallow this. >>>>> >>>>> On Feb 28, 2016, at 1:29 PM, Romain Manni-Bucau wrote: >>>>> >>>>>> At apache we have subprojects which can become top level project if they behaves well. Would it be possible at EE level? Idea would be to have cdi-concurrency subspec (under CDI umbrella but not part of CDI itself - know there was appendix in bval for instance). Then for EE 9 if the subspec is proven as good it would become its own spec. wdyt? >>>>>> >>>>>> >>>>>> Romain Manni-Bucau >>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>> >>>>>> 2016-02-28 19:16 GMT+01:00 Mark Struberg : >>>>>>> >>>>>>> > Am 26.02.2016 um 17:39 schrieb Werner Keil : >>>>>>> > >>>>>>> > Reza/all, >>>>>>> > >>>>>>> > One of the biggest problems with Concurrency Utilities is, that it started in 2003, then went "dormant" (before the term existed) and was revived to be finalized 10 years later after little or no proper alignment with then state of the art Java EE standards and technologies. It duplicates things, especially in EJB or CDI. >>>>>>> > >>>>>>> >>>>>>> +1 that pretty much sums it up. Concurrency utils is pretty much broken and unusable as it is today. :/ >>>>>>> >>>>>>> Anyway, let?s not fight the past - we need a way forward. >>>>>>> >>>>>>> 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160228/09bf4cd2/attachment-0001.html From werner.keil at gmail.com Mon Feb 29 04:45:12 2016 From: werner.keil at gmail.com (Werner Keil) Date: Mon, 29 Feb 2016 10:45:12 +0100 Subject: [cdi-dev] Concurrency Control In-Reply-To: <56150E68-7E47-4E57-B469-96D63689ADEA@lycos.com> References: <5E76B98D-F530-4D0D-B404-8995286B39D9@lycos.com> <56150E68-7E47-4E57-B469-96D63689ADEA@lycos.com> Message-ID: That's why at least on the SE side (and to some extent ME/Embedded/IoT projects also start to show up there, although some with almost no activity;-) pretty much everything shifted to OpenJDK "JEPs" now as it seems. And there are not many JSRs. Except Jigsaw (don't know thy they bothered filing that) there is no Java SE 9 JSR. For SE 7 there were still a few individual SE JSRs like NIO, Diamond or Coin. For SE 8 the only real JSR was Lamba. Two "rudimentary" JSRs 308 and 310 were still added, but neither created proper deliverables of their own. 310 has no public API and the RI is baked into Java SE 8 in ways, that make independent implementations of the JSR impossible since all rudimentary interfaces are not only hidden under the surface, they also contain direct references to their RI types. Think of that in the EE world? A Servlet spec that only works in Glassfish?;-O JSR 308 is enforced by the compiler, but even the internals of Java SE 8 ignore it and make no use of it. Nor do any standard annotations exist elsewhere, e.g. under NetBeans making use of them. SE 8 included the Optional type instead to help with null values and NPEs, instead of proper integration of Type Annotations. So 308 is practically useless. Could have been avoided completely. There is a glimpse of hope for SE 10 or 11, but they could have left Type Annotations out until then. Java SE 9 does not even have an "Umbrella JSR" nor am I sure, if it makes sense. Mark Reinhold as Spec Lead for the Modularity/Jigsaw JSR keeps as argumenting for Renewal Ballots and it would be quite unlikely, the EC ever voted that one down, but IMHO it is almost a waste of (EC) time in that case. As there are independent implementations of pretty much every EE standard, there is more value here, but it's something the EC started to discuss and worry about, if Oracle may simply "tweak" its JEP mechanism to also work for EE. Regards, Werner On Sun, Feb 28, 2016 at 11:32 PM, Reza Rahman wrote: > This is a good question indeed. In the past the real stated rationale for > a sub-spec was eventual or possible separation. It's a question that should > be posed in the Java EE EG or even the EC. > > In the case of JPA/EJB there is an official reason and perhaps a few > ulterior ones. The official reason is that the EJB EG had the initial skill > set to deal with JPA but the spec should be eventually separate. > Unofficially my guess is that too many vendors had bought into EJB Entity > Beans for too long and they needed to deal it a soft blow to make > themselves look better instead of a hard and fast death blow. Saving EJB > from total collapse right away might have also been a motive and also > giving Gavin/Red Hat less credit for Java EE 5 than he/they deserved... > > On Feb 28, 2016, at 5:13 PM, arjan tijms wrote: > > What are exactly the rules of making something a sub-spec? > > There have been various examples of this in the past. Reza mentioned JPA, > which started as a sub-spec of EJB, even though it was not directly split > off from an existing EJB API (you could say it was conceptually a > re-imagined EJB Entity Bean, but JPA entities are different enough to stand > on their own). > > I wonder what the decisions were at the time to go for a sub-spec, instead > of either directly putting it in EJB on the one hand, or going right away > for a top-level spec on the other hand. > > Regardless, I think this points out a (practical) weakness in the Java EE > umbrella/constituent specs setup. In general we like to split things out > into several specs, so that those specs can evolve on their own and are > useable by the rest of the platform. E.g. EL is a great example, it's now > separate, and can be used everywhere without a dependency on say JSP or JSF. > > But the fact that top level specs need to be individually "active" and > must each have assembled their own EG, is a serious process overhead. This > is specifically so because with the current Java EE process not all > constituent specs are active/open by default for a given spec cycle. > > > On Sun, Feb 28, 2016 at 8:25 PM, Reza Rahman > wrote: > >> I am not so sure "everyone stated" this shouldn't be part of CDI. As some >> of us have already pointed out there might be a case for including it in >> CDI anyway and this should be part of the discussion equation here and >> elsewhere. Indeed I suggest putting together a questionnaire on this with >> the options that "everyone" on this EG indeed does vote on... >> >> On Feb 28, 2016, at 2:10 PM, Romain Manni-Bucau >> wrote: >> >> >> 2016-02-28 20:08 GMT+01:00 Werner Keil : >> >>> Yes, there's no "incubating" stage for JSRs other than "not Final", so >>> as soon as a JSR or parts of it are final, they become part of an umbrella >>> spec if that spec wants to contain them. >>> >>> Potentially from Java EE 9 on there could be much finer grained >>> activation or deactivation of features and profiles as soon as the whole >>> Jigsaw thing and SE 9 is out, but until then I think we' have to stick to >>> what's available right now. >>> >>> For CDI 2 modularity or running in Java SE are already in scope, but >>> other than e.g. having "ee-concurrency" only in the Java EE profile of CDI, >>> I don't see how CDI should do things the platform will provide later anyway. >>> >>> >> Fully agree, means @Lock shouldnt go in CDI as everyone stated so falling >> back on CDI cause concurrency spec is inactive is a bad choice. Question >> leaves CDI list then and is: how to make concurrency active? >> >> >>> Regards, >>> >>> Werner >>> >>> On Sun, Feb 28, 2016 at 7:59 PM, Reza Rahman >>> wrote: >>> >>>> I am unsure what this means. Firstly I think this functionality is way >>>> overdue. Secondly I see little value to having anything that is a >>>> pseudo-standard. I'd rather see the effort pursue another path to >>>> standardization or remain completely independent while clearly pointing out >>>> what the obstacles to standardization are/were. >>>> >>>> On the other hand if this is required to be implemented in Java EE 8 >>>> runtimes I don't think it matters what the particular structural gymnastics >>>> are. Purely from a JCP standpoint, it is possible to have a >>>> sub-specification but only if the eventual goal is to spin it out into a >>>> separate specification. Examples of this are JPA, interceptors and others. >>>> There is no precedent for an "incubator" specification that is somehow >>>> optional. In fact I am pretty sure the current JCP rules would disallow >>>> this. >>>> >>>> On Feb 28, 2016, at 1:29 PM, Romain Manni-Bucau >>>> wrote: >>>> >>>> At apache we have subprojects which can become top level project if >>>> they behaves well. Would it be possible at EE level? Idea would be to have >>>> cdi-concurrency subspec (under CDI umbrella but not part of CDI itself - >>>> know there was appendix in bval for instance). Then for EE 9 if the subspec >>>> is proven as good it would become its own spec. wdyt? >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau | Blog >>>> | Github >>>> | LinkedIn >>>> | Tomitriber >>>> >>>> >>>> 2016-02-28 19:16 GMT+01:00 Mark Struberg : >>>> >>>>> >>>>> > Am 26.02.2016 um 17:39 schrieb Werner Keil : >>>>> > >>>>> > Reza/all, >>>>> > >>>>> > One of the biggest problems with Concurrency Utilities is, that it >>>>> started in 2003, then went "dormant" (before the term existed) and was >>>>> revived to be finalized 10 years later after little or no proper alignment >>>>> with then state of the art Java EE standards and technologies. It >>>>> duplicates things, especially in EJB or CDI. >>>>> > >>>>> >>>>> +1 that pretty much sums it up. Concurrency utils is pretty much >>>>> broken and unusable as it is today. :/ >>>>> >>>>> Anyway, let?s not fight the past - we need a way forward. >>>>> >>>>> 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. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160229/ec35f076/attachment.html From reza_rahman at lycos.com Mon Feb 29 09:26:50 2016 From: reza_rahman at lycos.com (Reza Rahman) Date: Mon, 29 Feb 2016 09:26:50 -0500 Subject: [cdi-dev] Concurrency Control In-Reply-To: References: <5E76B98D-F530-4D0D-B404-8995286B39D9@lycos.com> <56150E68-7E47-4E57-B469-96D63689ADEA@lycos.com> Message-ID: <6BB524F5-7547-456F-88B7-9D40F9307743@lycos.com> I completely agree with you. The way Java SE operates is very closed in effect and totally contrary to how open standards work. The problem goes all the way including the TCK and the results show in lack of viable alternatives to Oracle dominated OpenJDK. Personally I would hate for enterprise Java to go this way - we would lose something very valuable and unique that many of us care about. > On Feb 29, 2016, at 4:45 AM, Werner Keil wrote: > > That's why at least on the SE side (and to some extent ME/Embedded/IoT projects also start to show up there, although some with almost no activity;-) pretty much everything shifted to OpenJDK "JEPs" now as it seems. And there are not many JSRs. Except Jigsaw (don't know thy they bothered filing that) there is no Java SE 9 JSR. For SE 7 there were still a few individual SE JSRs like NIO, Diamond or Coin. For SE 8 the only real JSR was Lamba. Two "rudimentary" JSRs 308 and 310 were still added, but neither created proper deliverables of their own. 310 has no public API and the RI is baked into Java SE 8 in ways, that make independent implementations of the JSR impossible since all rudimentary interfaces are not only hidden under the surface, they also contain direct references to their RI types. Think of that in the EE world? A Servlet spec that only works in Glassfish?;-O JSR 308 is enforced by the compiler, but even the internals of Java SE 8 ignore it and make no use of it. Nor do any standard annotations exist elsewhere, e.g. under NetBeans making use of them. SE 8 included the Optional type instead to help with null values and NPEs, instead of proper integration of Type Annotations. So 308 is practically useless. Could have been avoided completely. There is a glimpse of hope for SE 10 or 11, but they could have left Type Annotations out until then. > > Java SE 9 does not even have an "Umbrella JSR" nor am I sure, if it makes sense. Mark Reinhold as Spec Lead for the Modularity/Jigsaw JSR keeps as argumenting for Renewal Ballots and it would be quite unlikely, the EC ever voted that one down, but IMHO it is almost a waste of (EC) time in that case. As there are independent implementations of pretty much every EE standard, there is more value here, but it's something the EC started to discuss and worry about, if Oracle may simply "tweak" its JEP mechanism to also work for EE. > > Regards, > Werner > >> On Sun, Feb 28, 2016 at 11:32 PM, Reza Rahman wrote: >> This is a good question indeed. In the past the real stated rationale for a sub-spec was eventual or possible separation. It's a question that should be posed in the Java EE EG or even the EC. >> >> In the case of JPA/EJB there is an official reason and perhaps a few ulterior ones. The official reason is that the EJB EG had the initial skill set to deal with JPA but the spec should be eventually separate. Unofficially my guess is that too many vendors had bought into EJB Entity Beans for too long and they needed to deal it a soft blow to make themselves look better instead of a hard and fast death blow. Saving EJB from total collapse right away might have also been a motive and also giving Gavin/Red Hat less credit for Java EE 5 than he/they deserved... >> >>> On Feb 28, 2016, at 5:13 PM, arjan tijms wrote: >>> >>> What are exactly the rules of making something a sub-spec? >>> >>> There have been various examples of this in the past. Reza mentioned JPA, which started as a sub-spec of EJB, even though it was not directly split off from an existing EJB API (you could say it was conceptually a re-imagined EJB Entity Bean, but JPA entities are different enough to stand on their own). >>> >>> I wonder what the decisions were at the time to go for a sub-spec, instead of either directly putting it in EJB on the one hand, or going right away for a top-level spec on the other hand. >>> >>> Regardless, I think this points out a (practical) weakness in the Java EE umbrella/constituent specs setup. In general we like to split things out into several specs, so that those specs can evolve on their own and are useable by the rest of the platform. E.g. EL is a great example, it's now separate, and can be used everywhere without a dependency on say JSP or JSF. >>> >>> But the fact that top level specs need to be individually "active" and must each have assembled their own EG, is a serious process overhead. This is specifically so because with the current Java EE process not all constituent specs are active/open by default for a given spec cycle. >>> >>> >>>> On Sun, Feb 28, 2016 at 8:25 PM, Reza Rahman wrote: >>>> I am not so sure "everyone stated" this shouldn't be part of CDI. As some of us have already pointed out there might be a case for including it in CDI anyway and this should be part of the discussion equation here and elsewhere. Indeed I suggest putting together a questionnaire on this with the options that "everyone" on this EG indeed does vote on... >>>> >>>>> On Feb 28, 2016, at 2:10 PM, Romain Manni-Bucau wrote: >>>>> >>>>> >>>>> 2016-02-28 20:08 GMT+01:00 Werner Keil : >>>>>> Yes, there's no "incubating" stage for JSRs other than "not Final", so as soon as a JSR or parts of it are final, they become part of an umbrella spec if that spec wants to contain them. >>>>>> >>>>>> Potentially from Java EE 9 on there could be much finer grained activation or deactivation of features and profiles as soon as the whole Jigsaw thing and SE 9 is out, but until then I think we' have to stick to what's available right now. >>>>>> >>>>>> For CDI 2 modularity or running in Java SE are already in scope, but other than e.g. having "ee-concurrency" only in the Java EE profile of CDI, I don't see how CDI should do things the platform will provide later anyway. >>>>>> >>>>> >>>>> Fully agree, means @Lock shouldnt go in CDI as everyone stated so falling back on CDI cause concurrency spec is inactive is a bad choice. Question leaves CDI list then and is: how to make concurrency active? >>>>> >>>>>> Regards, >>>>>> Werner >>>>>> >>>>>>> On Sun, Feb 28, 2016 at 7:59 PM, Reza Rahman wrote: >>>>>>> I am unsure what this means. Firstly I think this functionality is way overdue. Secondly I see little value to having anything that is a pseudo-standard. I'd rather see the effort pursue another path to standardization or remain completely independent while clearly pointing out what the obstacles to standardization are/were. >>>>>>> >>>>>>> On the other hand if this is required to be implemented in Java EE 8 runtimes I don't think it matters what the particular structural gymnastics are. Purely from a JCP standpoint, it is possible to have a sub-specification but only if the eventual goal is to spin it out into a separate specification. Examples of this are JPA, interceptors and others. There is no precedent for an "incubator" specification that is somehow optional. In fact I am pretty sure the current JCP rules would disallow this. >>>>>>> >>>>>>> On Feb 28, 2016, at 1:29 PM, Romain Manni-Bucau wrote: >>>>>>> >>>>>>>> At apache we have subprojects which can become top level project if they behaves well. Would it be possible at EE level? Idea would be to have cdi-concurrency subspec (under CDI umbrella but not part of CDI itself - know there was appendix in bval for instance). Then for EE 9 if the subspec is proven as good it would become its own spec. wdyt? >>>>>>>> >>>>>>>> >>>>>>>> Romain Manni-Bucau >>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>> >>>>>>>> 2016-02-28 19:16 GMT+01:00 Mark Struberg : >>>>>>>>> >>>>>>>>> > Am 26.02.2016 um 17:39 schrieb Werner Keil : >>>>>>>>> > >>>>>>>>> > Reza/all, >>>>>>>>> > >>>>>>>>> > One of the biggest problems with Concurrency Utilities is, that it started in 2003, then went "dormant" (before the term existed) and was revived to be finalized 10 years later after little or no proper alignment with then state of the art Java EE standards and technologies. It duplicates things, especially in EJB or CDI. >>>>>>>>> > >>>>>>>>> >>>>>>>>> +1 that pretty much sums it up. Concurrency utils is pretty much broken and unusable as it is today. :/ >>>>>>>>> >>>>>>>>> Anyway, let?s not fight the past - we need a way forward. >>>>>>>>> >>>>>>>>> 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. >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160229/56474eec/attachment-0001.html