[JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-456:
-----------------------------------
jozef, how should that work? The 3 beans are different but have the same beanClass(). So how should this get implemented?
let's look at what you quoted.
{quote}
5.1.4
For a custom implementation of the Bean interface defined in Section 11.1, “The Bean interface”, the container calls getBeanClass() to determine the bean class of the bean
{quote}
So what? Where in this sentence does it state that the 'bean class of the bean' cannot be null? It neither does define what the 'bean class of the bean' is used for by the container.
{quote}
5.1.1.2
For a custom implementation of the Bean interface defined in Section 11.1, “The Bean interface”, the container calls .. getBeanClass() and getStereotypes() to determine whether an alternative is selected in a certain bean archive.
{quote}
oh fine, but this is not about Alternatives!
Show me one single line where you read that getBeanClass() must not be null for any custom bean.
This is just missing from the spec and we should clarify what should happen in this case.
> fix Bean#getBeanClass() definition
> ----------------------------------
>
> Key: CDI-456
> URL: https://issues.jboss.org/browse/CDI-456
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Reporter: Mark Struberg
>
> currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field.
> Imo this only causes troubles and doesn't add any benefit.
> * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created.
> * At the time we create interceptors we ONLY need the type which is to be created;
> * At the time we create the normalscoping proxies we ONLY need the type which is to be created;
> In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class!
> In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 3 months
[JBoss JIRA] (CDI-459) Clarify whether CDI should validate beans that are not enabled
by Jozef Hartinger (JIRA)
Jozef Hartinger created CDI-459:
-----------------------------------
Summary: Clarify whether CDI should validate beans that are not enabled
Key: CDI-459
URL: https://issues.jboss.org/browse/CDI-459
Project: CDI Specification Issues
Issue Type: Clarification
Components: Beans
Affects Versions: 1.2.Final
Reporter: Jozef Hartinger
CDITCK-438 opens up an interesting question. Should CDI validate beans that are not enabled?
First, we need to make a distinction between a *definition error* (e.g. a field that is annotated with both {{@Inject}} and {{@Producer}} ) and a *deployment problem* (e.g. an unsatisfied dependency).
The spec currently explicitly requires deployment problems to be detected on enabled beans only:
{quote}The container must validate all injection points of all *enabled beans*, all observer methods, all disposer methods and all other Java EE component classes supporting injection when the application is initialized to ensure that there are no unsatisfied or unresolvable ambiguous dependencies. {quote}
However, It is not explicitly defined for definition errors, e.g:
{quote}
If a Bean instance with qualifier @Intercepted is injected into a bean instance other than an interceptor instance, the container automatically detects the problem and treats it as a definition error.
{quote}
does not say anything about enablement of the bean.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 3 months
[JBoss JIRA] (CDI-4) Need a way to provide ordering for Event observers
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Martin Kouba edited comment on CDI-4 at 9/8/14 7:35 AM:
--------------------------------------------------------
Actually, {{javax.annotation.Priority}} is not a part of the Java SE (only EE 7+), so it shouldn't be a big problem.
was (Author: mkouba):
Actually, +javax.annotation.Priority+ is not part of the Java SE (only EE 7+), so it shouldn't be a big problem.
> Need a way to provide ordering for Event observers
> --------------------------------------------------
>
> Key: CDI-4
> URL: https://issues.jboss.org/browse/CDI-4
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events, Portable Extensions
> Affects Versions: 1.0
> Environment: All
> Reporter: Lincoln Baxter III
> Assignee: Pete Muir
> Fix For: 2.0 (discussion)
>
>
> There needs to be a way to specify some kind of ordering for Event observers.
> Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 3 months
[JBoss JIRA] (CDI-4) Need a way to provide ordering for Event observers
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Martin Kouba commented on CDI-4:
--------------------------------
Actually, +javax.annotation.Priority+ is not part of the Java SE (only EE 7+), so it shouldn't be a big problem.
> Need a way to provide ordering for Event observers
> --------------------------------------------------
>
> Key: CDI-4
> URL: https://issues.jboss.org/browse/CDI-4
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events, Portable Extensions
> Affects Versions: 1.0
> Environment: All
> Reporter: Lincoln Baxter III
> Assignee: Pete Muir
> Fix For: 2.0 (discussion)
>
>
> There needs to be a way to specify some kind of ordering for Event observers.
> Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 3 months
[JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-456:
----------------------------------------
I think main issue today regarding it is the javadoc doesn't state what you get when. So basically you don't know what you get. IMHO this thing should be well defined and not rely on a "hack"
getBeanClass still makes sense for proxying IMHO
> fix Bean#getBeanClass() definition
> ----------------------------------
>
> Key: CDI-456
> URL: https://issues.jboss.org/browse/CDI-456
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Reporter: Mark Struberg
>
> currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field.
> Imo this only causes troubles and doesn't add any benefit.
> * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created.
> * At the time we create interceptors we ONLY need the type which is to be created;
> * At the time we create the normalscoping proxies we ONLY need the type which is to be created;
> In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class!
> In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 3 months
[JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-456:
-------------------------------------
{quote}The whole modularity in EAR otoh requires that JavaEE FINALLY properly defines the default isolation (EAR as 1 classloader + each WAR as child ClassLoader, etc) as standard. If the EE platform doesn't have a proper modularity specification we have a floating target and cannot define how CDI should handle it neither.{quote}
Let's suppose for a moment that Java EE finally properly defined its module architecture. Now, how should we define CDI modularity? Should it follow the underlying module architecture or go against it? I think we can agree that we should not define a different architecture but rather follow the underlying one. But wait... that's what CDI already does by using class accessibility to infer bean accessibility ;-)
> fix Bean#getBeanClass() definition
> ----------------------------------
>
> Key: CDI-456
> URL: https://issues.jboss.org/browse/CDI-456
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Reporter: Mark Struberg
>
> currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field.
> Imo this only causes troubles and doesn't add any benefit.
> * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created.
> * At the time we create interceptors we ONLY need the type which is to be created;
> * At the time we create the normalscoping proxies we ONLY need the type which is to be created;
> In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class!
> In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 3 months
[JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-456:
-------------------------------------
{quote}Bean#getBeanClass() is only defined for 'Managed Beans' at the moment. That means it is only defined for classes which get scanned at boot time. It is not defined for anything you do via Extensions.{quote}
The Javadoc defines {{Bean#getBeanClass()}} for *managed beans, session beans, producer methods and producer fields*. Not just managed beans. In addition, although {{Bean#getBeanClass()}} is not explicitly defined for custom beans, the expected behavior can be implied from sections 5.1, 5.1.1.2 and 5.1.4. The behavior for custom beans should be defined more explicitly as currently it needs to be implied and is not immediately obvious.
{quote} it wont work for 3 custom Bean<T> which are differently configured for each of the 3 WARs{quote}
See my example above. It works there.
{quote}Especially since getBeanClass() might return null if you strictly follow the spec wording.{quote}
{quote}For a custom implementation of the Bean interface defined in Section 11.1, “The Bean interface”, the container calls getBeanClass() to determine the bean class of the bean{quote}
Since 'bean class' is used in 5.1.4. to determine if the bean is available for injection then returning null from {{getBeanClass}} is arguably a definition error.
> fix Bean#getBeanClass() definition
> ----------------------------------
>
> Key: CDI-456
> URL: https://issues.jboss.org/browse/CDI-456
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Reporter: Mark Struberg
>
> currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field.
> Imo this only causes troubles and doesn't add any benefit.
> * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created.
> * At the time we create interceptors we ONLY need the type which is to be created;
> * At the time we create the normalscoping proxies we ONLY need the type which is to be created;
> In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class!
> In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 3 months
[JBoss JIRA] (CDI-4) Need a way to provide ordering for Event observers
by Antonio Goncalves (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Antonio Goncalves commented on CDI-4:
-------------------------------------
Yes, that reminds me of {{javax.annotation.Resource}}. It got updated in Java EE 6 (it introduced the {{lookup()}} method) and we had to endorse the library for Java SE 6. So yes, there is a bit of tuning when you touch common code like [Commons Annotation|https://jcp.org/en/jsr/detail?id=250].
> Need a way to provide ordering for Event observers
> --------------------------------------------------
>
> Key: CDI-4
> URL: https://issues.jboss.org/browse/CDI-4
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events, Portable Extensions
> Affects Versions: 1.0
> Environment: All
> Reporter: Lincoln Baxter III
> Assignee: Pete Muir
> Fix For: 2.0 (discussion)
>
>
> There needs to be a way to specify some kind of ordering for Event observers.
> Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 3 months
[JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-456:
-----------------------------------
to also add what we discussed on IRC on friday:
Bean#getBeanClass() is _only_ defined for 'Managed Beans' at the moment. That means it is only defined for classes which get scanned at boot time. It is *not* defined for anything you do via Extensions.
regarding the modularity discussion: yes, using getBeanClass() for that would work for ManagedBeans which get scanned by the container, but again: it wont work for 3 custom Bean<T> which are differently configured for each of the 3 WARs. Especially since getBeanClass() might return null if you strictly follow the spec wording.
So I think we need to
a.) clarify what getBeanClass() shall return for Bean<T> added via Extensions
b.) how modularity works for synthetic beans.
The whole modularity in EAR otoh requires that JavaEE FINALLY properly defines the default isolation (EAR as 1 classloader + each WAR as child ClassLoader, etc) as standard. If the EE platform doesn't have a proper modularity specification we have a floating target and cannot define how CDI should handle it neither.
> fix Bean#getBeanClass() definition
> ----------------------------------
>
> Key: CDI-456
> URL: https://issues.jboss.org/browse/CDI-456
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Reporter: Mark Struberg
>
> currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field.
> Imo this only causes troubles and doesn't add any benefit.
> * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created.
> * At the time we create interceptors we ONLY need the type which is to be created;
> * At the time we create the normalscoping proxies we ONLY need the type which is to be created;
> In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class!
> In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 3 months
