[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}Enough to define it well next tim, no?{quote}
We cannot just redefine the method's behavior (as otherwise we break other things).
We can:
1) define a new better mechanism for this, or
2) redefine the method behavior and the related parts of the spec while retaining backward compatibility (hard or perhaps not possible at all), or
3) leave it as it is
> 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)
9 years, 9 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:
--------------------------------
[~agoncal] Hm, so it woudn't work for Java 8 SE without some dependency tuning, right? I'm just pointing out there is a little complication...
> 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)
9 years, 9 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:
----------------------------------------
Not sure I get
{quote}
* cannot be redefined to simply return the bean type - besides breaking backward compatibility this would also break how other parts of CDI work
{quote}
Enough to define it well next tim, no?
> 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)
9 years, 9 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:
-------------------------------------
Anatole, you are completely right. But why does it work this way?
The behavior is driven by the following statement in the specification:
{quote}A bean is available for injection in a certain module if the *bean class* is required to be *accessible to classes in the module*, according to the class
accessibility requirements of the module architecture.{quote}
Let's expand your example a bit to demonstrate this. Let's say that your producers are called {{MyProducer1}}, {{MyProducer2}}, {{MyProducer3}} and are packaged in war1, war2 and war3, respectively.
Now, let's inject {{MyBean}} in war1. {{MyProducer1.create()}} is the first candidate. Since the bean class of {{MyProducer1.create()}} is {{MyProducer1}} and since this class is accessible within war1, we can use {{MyProducer1.create()}} to create a {{MyBean}} instance. For {{MyProducer2}} and {{MyProducer3}} this is not the case as we assume wars are isolated. This is expected and in line with your conclusion.
Notice that although {{MyProducer1.create()}} produces {{MyBean}} instances, {{MyProducer1}} is its bean class. If we made {{MyBean}} the bean class of {{MyProducer1}}, {{MyProducer2}} and {{MyProducer3}} (*as this ticket proposes*), all three producer methods would be available for injection in any of the wars, which is obviously not desired! The aforementioned CDI accessibility rule determines the accessibility of the bean by its bean class and therefore we cannot pronounce the return type of a producer method as its bean class.
\\
----
\\
Custom Bean<T> implementations are very similar. Image now that instead of using {{MyProducer}} classes, our example uses {{MyBeanProvider}} classes defined as:
{code:JAVA}
public class MyBeanProvider implements Bean<MyBean> {
public T create(CreationalContext<T> creationalContext) {
return new MyBean();
}
...
}
{code}
Again, we have {{MyBeanProvider1}}, {{MyBeanProvider2}}, {{MyBeanProvider3}} in war1, war2, war3, respectively. Each bean provider is registered by an extension.
What should {{MyBeanProvider1.getBeanClass()}} return? Let's assume it returns {{MyBeanProvider1.class}}. Once we apply the accessibility rule of CDI we can see that each war again gets its respective bean producing MyBean instances and that the bean isolation follows classloader isolation. This is again the expected behavior, matching Anatole's example.
If we however follow the "simplification proposed by this ticket" and return {{MyBean.class}} from {{MyBeanProvider1.getBeanClass()}} then, not unlike with producers, {{MyBeanProvider1}} will be visible from all the three wars, which is not desired. This would be because {{MyBean.class}} is accessible from all the three wars. The CDI accessibility rule determines the accessibility of the bean by its bean class and therefore we cannot just blindly return a bean type from {{Bean.getBeanClass()}}.
Hope this makes it clearer that {{Bean.getBeanClass()}}
* exists for a reason
* it is not a shortcut to bean types and there is often absolutely no relation between Bean<T>.getTypes() and Bean<T>.getBeanClass()
* although probably not the ideal way of addressing modularity and isolation (and subject to improvement in CDI 2.0), it works
* cannot be redefined to simply return the bean type - besides breaking backward compatibility this would also break how other parts of CDI 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)
9 years, 9 months
[JBoss JIRA] (CDI-457) Add a disposable interface
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-457?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-457:
-----------------------------------
Please let me ask one question: why should the container know about dependent scoped beans which are _not_ injected into some normalscoped bean? We do not spare any resources for them (at least in OWB). Even if they have interceptors or decorators applied.
Btw, there is kind off such a mechanism already. All you need to do is to keep the Bean<T> and the CreationalContext you used to create the contextual instance. Then just use Bean.destroy(T, cc);
> Add a disposable interface
> --------------------------
>
> Key: CDI-457
> URL: https://issues.jboss.org/browse/CDI-457
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts
> Reporter: John Ament
> Assignee: John Ament
>
> Currently for Dependent scoped beans, there's no way for the container to be aware when it's no longer needed.
> I suggest that we somehow wrap dependent beans in a Disposable wrapper to be notified when it's not needed any longer.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (CDI-457) Add a disposable interface
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-457?page=com.atlassian.jira.plugin.sy... ]
John Ament commented on CDI-457:
--------------------------------
BTW, @TransientReference would work in the producer method solution, if it were allowed on methods/fields, rather than params only.
WDYT about allowing @TransientReference on producer methods? Allowing the producer to control the behavior of the injected reference, rather than the injection point controlling it?
> Add a disposable interface
> --------------------------
>
> Key: CDI-457
> URL: https://issues.jboss.org/browse/CDI-457
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts
> Reporter: John Ament
> Assignee: John Ament
>
> Currently for Dependent scoped beans, there's no way for the container to be aware when it's no longer needed.
> I suggest that we somehow wrap dependent beans in a Disposable wrapper to be notified when it's not needed any longer.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (CDI-457) Add a disposable interface
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-457?page=com.atlassian.jira.plugin.sy... ]
John Ament commented on CDI-457:
--------------------------------
{code}Instance.destroy(){code} is probably the closest to what I'm looking for, but less error prone. There were a few ways I was thinking to solve this, first is
{code}
@Produces
@UnManaged
public SomeClass produceSomeClass() {...
{code}
@UnManaged would be a new annotation indicating that the returned object is not contextual (and hence, implicitly dependent). Another way, using the Instance<> approach would be:
{code}
Disposable<SomeClass> dsc = CDI.current().select(SomeClass.class).getDisposable();
try(SomeClass sc = dsc.get()) {
// do something with some class
}
{code}
so that when the Disposable object goes out of scope, it gets cleaned up.
> Add a disposable interface
> --------------------------
>
> Key: CDI-457
> URL: https://issues.jboss.org/browse/CDI-457
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts
> Reporter: John Ament
> Assignee: John Ament
>
> Currently for Dependent scoped beans, there's no way for the container to be aware when it's no longer needed.
> I suggest that we somehow wrap dependent beans in a Disposable wrapper to be notified when it's not needed any longer.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition
by Anatole Tresch (JIRA)
[ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.sy... ]
Anatole Tresch commented on CDI-456:
------------------------------------
Jozef, imagine the following
{noformat}
public class MyProducer{
@Produces @ApplicationScoped
public MyBean create(){ return new MyBean(); }
}
{noformat}
The {{MyBean}} class is declared in the *ear*, as follows:
{noformat}
public final class MyBean{
public final String CONTEXT = Thread.currentThread().getContextClassLoader().toString();
}
{noformat}
Now you have 3 wars, the class instance for {{MyBean}} will be the same for all three wars, since it is loaded from the *ear classloader* (but also visible to the war classloader).
Nevertheless, since the {{MyProducer}} producer class is defined on *war level*, you get three different instances, each with a different {{CONTEXT}}...
> 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)
9 years, 9 months
Tools : Google Drive vs Asciidoc and Github
by Antoine Sabot-Durand
Hi all,
To pursue the discussion we had during last meeting, I really think we should use both tools for the workshop. that’s how I see things :
In early stage in the workshop the working doc is changing fast and could probably content ideas that will disappear in future version (impossible or breaking backward compatibility).
This phase needs fast collaboration between people knowing that the doc content is volatile and more in “brain storm” than in “part of the final spec” mode. For these reason I think we should set this working phase in Google Drive. It will be easier to collaborate synchronously on the doc and separate the very early draft to more advance phase.
When an agreement (we have to define that yet) will be reached on this doc, it will be converted in Asciidoc (the plugin works nicely) and integrated to the spec website. The change will course continue but if we didn’t missed big mistake there will be less of them and they could be done thru PR.
WDYT ?
Antoine
9 years, 9 months