[JBoss JIRA] (CDI-320) Clarify whether ProcessAnnotatedType should be fired for annotations
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-320?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-320:
-------------------------------------
Labels: CDI_spec_chge Ready_to_fix (was: )
> Clarify whether ProcessAnnotatedType should be fired for annotations
> --------------------------------------------------------------------
>
> Key: CDI-320
> URL: https://issues.jboss.org/browse/CDI-320
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions
> Reporter: Ron Šmeral
> Labels: CDI_spec_chge, Ready_to_fix
> Fix For: 1.2 Proposed
>
>
> It should be stated clearly whether {{ProcessAnnotatedType}} should be fired for annotations.
> Currently, *11.5.6 ProcessAnnotatedType event* says:
> {quote}
> The container must fire an event, before it processes a type, for each:
> * Java class, interface or enum in a bean archive,
> {quote}
> The word "annotation" has been introduced into the above line and later reverted.
> {quote}
> * Annotated type added by {{BeforeBeanDiscovery.addAnnotatedType()}},
> {quote}
> The wording used here, however, doesn't exclude the option of the annotated type being an Annotation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (CDI-372) clarify behaviour of implicit bean archive
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-372?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-372:
------------------------------------------
The notion of Bean Archive is introduce in Chapter 12, we should do an introduction before.In section 2.5 we introduce the notion of bean defining annotation, we should more clearly explain what is the purpose of this concept. Now we only have a link to section 12.1.
> clarify behaviour of implicit bean archive
> ------------------------------------------
>
> Key: CDI-372
> URL: https://issues.jboss.org/browse/CDI-372
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Packaging and Deployment
> Affects Versions: 1.1.PFD
> Reporter: David Konecny
> Priority: Minor
> Labels: CDI_spec_chge
> Fix For: 1.2 Proposed
>
>
> I read chapter "12.1 Bean archives" which defines 'explicit bean archive' and 'implicit bean archive' and following that I removed beans.xml from my existing application only to find out that deployment of my app now fails because of unsatisfied dependencies. It took me a while to figure out the problem: there is behavioural difference between explicit and implicit bean archive which is mentioned later in the middle of chapter "12.4 Bean discovery":
> The container discovers:
> • each Java class, interface or enum deployed in an explicit bean archive, and
> • each Java class interface, or enum with a bean defining annotation in an implicit bean archive.
> The fact that implicit bean archive provides only beans with defining annotations is very important piece of information and I would like to suggest to mention that early in chapter 12.1 when the bean archive concepts are defined. Thanks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (CDI-372) clarify behaviour of implicit bean archive
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-372?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-372:
-------------------------------------
Labels: CDI_spec_chge (was: )
> clarify behaviour of implicit bean archive
> ------------------------------------------
>
> Key: CDI-372
> URL: https://issues.jboss.org/browse/CDI-372
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Packaging and Deployment
> Affects Versions: 1.1.PFD
> Reporter: David Konecny
> Priority: Minor
> Labels: CDI_spec_chge
> Fix For: 1.2 Proposed
>
>
> I read chapter "12.1 Bean archives" which defines 'explicit bean archive' and 'implicit bean archive' and following that I removed beans.xml from my existing application only to find out that deployment of my app now fails because of unsatisfied dependencies. It took me a while to figure out the problem: there is behavioural difference between explicit and implicit bean archive which is mentioned later in the middle of chapter "12.4 Bean discovery":
> The container discovers:
> • each Java class, interface or enum deployed in an explicit bean archive, and
> • each Java class interface, or enum with a bean defining annotation in an implicit bean archive.
> The fact that implicit bean archive provides only beans with defining annotations is very important piece of information and I would like to suggest to mention that early in chapter 12.1 when the bean archive concepts are defined. Thanks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (CDI-376) BeanManager#getProducerFactory return type differs between API and spec
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-376?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-376:
-------------------------------------
Labels: CDI_api_chge CDI_spec_chge Ready_to_fix (was: CDI_api_chge CDI_spec_chge)
> BeanManager#getProducerFactory return type differs between API and spec
> -----------------------------------------------------------------------
>
> Key: CDI-376
> URL: https://issues.jboss.org/browse/CDI-376
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Javadoc and API
> Affects Versions: 1.1.PFD
> Reporter: Mark Struberg
> Priority: Critical
> Labels: CDI_api_chge, CDI_spec_chge, Ready_to_fix
> Fix For: 1.2 Proposed
>
>
> return type differs between API and spec wording for both BeanManager#getProducerFactory methods.
> In API we have
> {{public <X> ProducerFactory<X> getProducerFactory(AnnotatedMethod<? super X> method, Bean<X> declaringBean);}}
> While in spec (section 11.3.22 )we have
> {{public <X> ProducerFactory<? super X> getProducerFactory(AnnotatedMethod<? super X> method, Bean<X> declaringBean);}}
> They differ in the return type:
> {{ProducerFactory<X>}} vs {{ProducerFactory<? super X>}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (CDI-376) BeanManager#getProducerFactory return type differs between API and spec
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-376?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-376:
------------------------------------------
I propose to correct the Spec to conform API. It should have less impact.
> BeanManager#getProducerFactory return type differs between API and spec
> -----------------------------------------------------------------------
>
> Key: CDI-376
> URL: https://issues.jboss.org/browse/CDI-376
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Javadoc and API
> Affects Versions: 1.1.PFD
> Reporter: Mark Struberg
> Priority: Critical
> Labels: CDI_api_chge, CDI_spec_chge
> Fix For: 1.2 Proposed
>
>
> return type differs between API and spec wording for both BeanManager#getProducerFactory methods.
> In API we have
> {{public <X> ProducerFactory<X> getProducerFactory(AnnotatedMethod<? super X> method, Bean<X> declaringBean);}}
> While in spec (section 11.3.22 )we have
> {{public <X> ProducerFactory<? super X> getProducerFactory(AnnotatedMethod<? super X> method, Bean<X> declaringBean);}}
> They differ in the return type:
> {{ProducerFactory<X>}} vs {{ProducerFactory<? super X>}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (CDI-376) BeanManager#getProducerFactory return type differs between API and spec
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-376?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-376:
-------------------------------------
Description:
return type differs between API and spec wording for both BeanManager#getProducerFactory methods.
In API we have
{{public <X> ProducerFactory<X> getProducerFactory(AnnotatedMethod<? super X> method, Bean<X> declaringBean);}}
While in spec (section 11.3.22 )we have
{{public <X> ProducerFactory<? super X> getProducerFactory(AnnotatedMethod<? super X> method, Bean<X> declaringBean);}}
They differ in the return type:
{{ProducerFactory<X>}} vs {{ProducerFactory<? super X>}}
was:
return type differs between API and spec wording for both BeanManager#getProducerFactory methods.
1st is API git, 2nd is spec version:
public <X> ProducerFactory<X> getProducerFactory(AnnotatedMethod<? super X> method, Bean<X> declaringBean);
public <X> ProducerFactory<? super X> getProducerFactory(AnnotatedMethod<? super X> method, Bean<X> declaringBean);
They differ in the return type:
ProducerFactory<X> vs
ProducerFactory<? super X>
> BeanManager#getProducerFactory return type differs between API and spec
> -----------------------------------------------------------------------
>
> Key: CDI-376
> URL: https://issues.jboss.org/browse/CDI-376
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Javadoc and API
> Affects Versions: 1.1.PFD
> Reporter: Mark Struberg
> Priority: Critical
> Labels: CDI_api_chge, CDI_spec_chge
> Fix For: 1.2 Proposed
>
>
> return type differs between API and spec wording for both BeanManager#getProducerFactory methods.
> In API we have
> {{public <X> ProducerFactory<X> getProducerFactory(AnnotatedMethod<? super X> method, Bean<X> declaringBean);}}
> While in spec (section 11.3.22 )we have
> {{public <X> ProducerFactory<? super X> getProducerFactory(AnnotatedMethod<? super X> method, Bean<X> declaringBean);}}
> They differ in the return type:
> {{ProducerFactory<X>}} vs {{ProducerFactory<? super X>}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (CDI-376) BeanManager#getProducerFactory return type differs between API and spec
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-376?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-376:
-------------------------------------
Labels: CDI_api_chge CDI_spec_chge (was: )
> BeanManager#getProducerFactory return type differs between API and spec
> -----------------------------------------------------------------------
>
> Key: CDI-376
> URL: https://issues.jboss.org/browse/CDI-376
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Javadoc and API
> Affects Versions: 1.1.PFD
> Reporter: Mark Struberg
> Priority: Critical
> Labels: CDI_api_chge, CDI_spec_chge
> Fix For: 1.2 Proposed
>
>
> return type differs between API and spec wording for both BeanManager#getProducerFactory methods.
> 1st is API git, 2nd is spec version:
> public <X> ProducerFactory<X> getProducerFactory(AnnotatedMethod<? super X> method, Bean<X> declaringBean);
> public <X> ProducerFactory<? super X> getProducerFactory(AnnotatedMethod<? super X> method, Bean<X> declaringBean);
> They differ in the return type:
> ProducerFactory<X> vs
> ProducerFactory<? super X>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (CDI-380) Clarify SessionScoped
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-380?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-380:
-------------------------------------
Labels: CDI_api_chge CDI_spec_chge Ready_to_fix (was: )
> Clarify SessionScoped
> ---------------------
>
> Key: CDI-380
> URL: https://issues.jboss.org/browse/CDI-380
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Joseph Snyder
> Priority: Minor
> Labels: CDI_api_chge, CDI_spec_chge, Ready_to_fix
> Fix For: 1.2 Proposed
>
>
> The javadocs say:
> The request context is destroyed:
> - at the end of the servlet request, after the service() method, all
> doFilter() methods, and all requestDestroyed() and onComplete()
> notifications return,
> ...
> The session context is destroyed when the HTTPSession times out, after all
> HttpSessionListeners have been called, and at the very end of any request in
> which invalidate() was called, after all filters and ServletRequestListeners
> have been called.
> Those definitions are different.
> The session context rule seems to be a combination of "or" items that
> include some "and" items. It's difficult to parse. It would be clearer
> if it was written as a list. And, like request scoped, it would be clearer
> if it described when the session scope/context is created.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (CDI-381) Additional implementations of Request Context
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-381?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-381:
-------------------------------------
Labels: CDI_api_chge Ready_to_fix (was: )
> Additional implementations of Request Context
> ---------------------------------------------
>
> Key: CDI-381
> URL: https://issues.jboss.org/browse/CDI-381
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Joseph Snyder
> Priority: Minor
> Labels: CDI_api_chge, Ready_to_fix
> Fix For: 1.2 Proposed
>
>
> Suppose another spec wanted to define when @RequestScoped applied to its
> operations, how would it do that? The javadocs for @RequestScoped seem to
> be an exhaustive list, not allowing the scope to be used in other contexts.
> The javadocs need to indicate that the scope can be active at other
> times beyond what the spec describes. It can be tricky to do that in a
> way that doesn't allow people to implement the currently defined scopes
> incorrectly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months