[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:
----------------------------------------
so you bean testing the classloader always? this is broken in OSGi where you often use proxy in create() but not in getBeanClass to allow this to work
> 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)
11 years, 4 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:
-------------------------------------
You can rely on that always. No matter where bean1 and bean2 are packaged you know that bean1 can be injected into bean2 as long as bean2.getBeanClass() can see bean1.getBeanClass().
I agree with you that this is by no means ideal and there are better ways to express this e.g. your getLocation() method.
> 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)
11 years, 4 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:
----------------------------------------
well my point is you can't rely on it generally so its usage shouldn't be this one. Maybe it just means we should have getProxiableType() and getLocation in Bean2<?> (next version)
wdyt?
> 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)
11 years, 4 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} If you use beanclass and that the bean class is not in the app (in upper classloaders) then what do you do?{quote}
That's a different question. If the bean class *is* in the app though then getBeanClass() can tell us whether this bean belongs to war1, war2, war3, shared library or somewhere else which is pretty important information.
> 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)
11 years, 4 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:
----------------------------------------
for wars it is mainly a 'flat' classloader so all beans are "shared" so nothing fancy to do?
for extension yes but honestly not sure that's that important. If you use beanclass and that the bean class is not in the app (in upper classloaders) then what do you do?
> 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)
11 years, 4 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 edited comment on CDI-456 at 9/4/14 9:39 AM:
-------------------------------------------------------------
{quote}You think it is here for modules?{quote}
Not only for modules but yes. It's referenced quite a lot in Section 5.1. Modularity
{quote}Well in a war no big deal{quote}
How?
{quote} in an ear the container does it since it deploys it{quote}
How? You have an extension that registered a custom bean. What information do you use to infer where the bean belongs? The same module as the extension's? Some type from Bean.getTypes()? Or something else?
was (Author: jharting):
{quote}You think it is here for modules?{quote}
Not only for modules but yes. It referenced quite a lot in Section 5.1. Modularity
{quote}Well in a war no big deal{quote}
How?
{quote} in an ear the container does it since it deploys it{quote}
How? You have an extension that registered a custom bean. What information do you use to infer where the bean belongs? The same module as the extension's? Some type from Bean.getTypes()? Or something else?
> 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)
11 years, 4 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}You think it is here for modules?{quote}
Not only for modules but yes. It referenced quite a lot in Section 5.1. Modularity
{quote}Well in a war no big deal{quote}
How?
{quote} in an ear the container does it since it deploys it{quote}
How? You have an extension that registered a custom bean. What information do you use to infer where the bean belongs? The same module as the extension's? Some type from Bean.getTypes()? Or something else?
> 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)
11 years, 4 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:
----------------------------------------
Well in a war no big deal, in an ear the container does it since it deploys it. If you 100% want to do it from the CDI container "alone" you just can't. Then you are right you can use bean class but it doesn't cover 100% of cases (most of them for sure). It doesn't change the main point: getBeanClass is not designed for it IMHO, no? You think it is here for modules?
> 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)
11 years, 4 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:
-------------------------------------
Can you elaborate more on how a CDI implementation should know which module a custom Bean<T> belongs to? I am not able to understand that from your reply.
> 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)
11 years, 4 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:
----------------------------------------
Classloading isolation can be restricted but it doesn't mean you don't inherit from other beans (typically in OSGi you can get proxies to solve it).
In EE that's the same, nothing prevents it if you *custom* beans handle it correctly. In EE that's worse since the deployment is pretty clear (=hierarchic) so no need to test Class to know what should be done.
> 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)
11 years, 4 months