[JBoss JIRA] (CDI-588) Adding missing annotation Literals
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-588?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-588:
------------------------------------------
Well, {{javax.interceptor.Interceptor.Priority}} is not the annotation but the inner class to {{@Interceptor}} containing constants for priority.
The annotation {{javax.annotation.Priority}} is part of JSR 250 (commons annotations). Some of the annotations of this spec are present in SE put not {{@Priority}}. So yes, we'd have to had this spec as dependency to CDI if we want this literal.
IMO I think it's not worth it for the moment.
> Adding missing annotation Literals
> ----------------------------------
>
> Key: CDI-588
> URL: https://issues.jboss.org/browse/CDI-588
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Antoine Sabot-Durand
> Assignee: Martin Kouba
>
> We forgot literals for {{Inject}} and more questionably literals for:
> * {{Observes}} and {{ObservesAsync}}
> * {{Produces}} and {{Disposes}}
> * {{Specializes}}
> * {{TransientReference}}
> * {{Vetoed}}
> Most of these can be used to help defining a new AnnotatedType to be added to set of discovered types.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (CDI-588) Adding missing annotation Literals
by Antonin Stefanutti (JIRA)
[ https://issues.jboss.org/browse/CDI-588?page=com.atlassian.jira.plugin.sy... ]
Antonin Stefanutti commented on CDI-588:
----------------------------------------
Indeed, my mistake. {{java.interceptor.Interceptor.Priority}} is part of {{java.interceptor-api}}.
So the question, is whether that's acceptable to add a dependency on {{javax.annotation-api}}.
> Adding missing annotation Literals
> ----------------------------------
>
> Key: CDI-588
> URL: https://issues.jboss.org/browse/CDI-588
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Antoine Sabot-Durand
> Assignee: Martin Kouba
>
> We forgot literals for {{Inject}} and more questionably literals for:
> * {{Observes}} and {{ObservesAsync}}
> * {{Produces}} and {{Disposes}}
> * {{Specializes}}
> * {{TransientReference}}
> * {{Vetoed}}
> Most of these can be used to help defining a new AnnotatedType to be added to set of discovered types.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (CDI-588) Adding missing annotation Literals
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-588?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-588:
----------------------------------
Not really, {{javax.annotation.Priority}} is defined in {{javax.annotation-api}}. Some classes from this API are part of the JDK. Some are only part of EE API (Priority, ManagedBean).
> Adding missing annotation Literals
> ----------------------------------
>
> Key: CDI-588
> URL: https://issues.jboss.org/browse/CDI-588
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Antoine Sabot-Durand
> Assignee: Martin Kouba
>
> We forgot literals for {{Inject}} and more questionably literals for:
> * {{Observes}} and {{ObservesAsync}}
> * {{Produces}} and {{Disposes}}
> * {{Specializes}}
> * {{TransientReference}}
> * {{Vetoed}}
> Most of these can be used to help defining a new AnnotatedType to be added to set of discovered types.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (CDI-588) Adding missing annotation Literals
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-588?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-588:
----------------------------------
[~antoinesabot-durand] [~stefanutti] The problem with {{@Priority}} is that it is not part of SE (only EE). And so we would have to add another dependency to CDI API pom.xml.
> Adding missing annotation Literals
> ----------------------------------
>
> Key: CDI-588
> URL: https://issues.jboss.org/browse/CDI-588
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Antoine Sabot-Durand
> Assignee: Martin Kouba
>
> We forgot literals for {{Inject}} and more questionably literals for:
> * {{Observes}} and {{ObservesAsync}}
> * {{Produces}} and {{Disposes}}
> * {{Specializes}}
> * {{TransientReference}}
> * {{Vetoed}}
> Most of these can be used to help defining a new AnnotatedType to be added to set of discovered types.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 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:
-----------------------------------
Would be great if we could just fix 'annotated'.
But my gut feeling is also that we need another mode. It's imo really well defined what 'annotated' does right now. So I'm not sure whether we can change it. Especially if we are allowed to change the case without any beans.xml...
> 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, 9 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-420:
------------------------------------------
you were faster than me [~mkouba] ;). So behavior of type discovery in annotated mode is well defined. The question is: is it better to introduce a new mode (and confusion) or change the behavior of {{annotated}} mode (what would be the real side effect).
> 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, 9 months
[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ]
Matej Novotny commented on CDI-527:
-----------------------------------
+1 for IgnoreFinalMethodProxying
Reasons:
* there is no real proxying going on for final methods, so word like {{ignore}} is better than {{allow}}
* mentions that this annotation relates to final methods, making it clear
* another good fit is {{IgnoreUnproxyableMethod}}, though I deem {{IgnoreFinalMethodProxying}} better because it underlines that you aim to ignore the process of proxy creation (rather than ignoring the method)
> 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)
8 years, 9 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:
----------------------------------
The container discovers each Java class with a bean defining annotation in an implicit bean archive (12.4.1. Type discovery). And an archive which contains a beans.xml file with the bean-discovery-mode of {{annotated}} is an implicit bean archive (12.1. Bean archives).
> 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, 9 months
[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand edited comment on CDI-527 at 3/16/16 4:03 AM:
-------------------------------------------------------------------
List of proposed names for the annotation so far:
* AllowProxying
* Passthrough
* SupressUnproxyAbleResolution
* ForceProxy
* SuppressUnproxyableResolutionException
* AllowFinalMethodProxying
* SkipFinalMethodProxying
* IgnoreFinalMethodProxying
* SkipUnproxyableMethod
* IgnoreUnproxyableMethod
* PassOverUnproxyable
* ByPassUnproxyable
was (Author: antoinesabot-durand):
List of proposed names so far:
* AllowProxying
* Passthrough
* SupressUnproxyAbleResolution
* ForceProxy
* SuppressUnproxyableResolutionException
* AllowFinalMethodProxying
* SkipFinalMethodProxying
* IgnoreFinalMethodProxying
* SkipUnproxyableMethod
* IgnoreUnproxyableMethod
* PassOverUnproxyable
* ByPassUnproxyable
> 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)
8 years, 9 months