[JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to producer methods
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.sy... ]
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)
8 years, 2 months
[JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to producer methods
by Mark Struberg (JIRA)
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)
8 years, 2 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
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)
8 years, 2 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
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)
8 years, 2 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
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)
8 years, 2 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
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)
8 years, 2 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Emily Jiang (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
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)
8 years, 2 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
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)
8 years, 2 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
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 {{(a)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)
8 years, 2 months
[JBoss JIRA] (CDI-579) Extension disqualifies a jar as 'implicit bean archive'?
by Arjan t (JIRA)
[ https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.sy... ]
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)
8 years, 2 months