[JBoss JIRA] (CDI-633) Introduce BeanManager.event()
by Sven Linstaedt (JIRA)
[ https://issues.jboss.org/browse/CDI-633?page=com.atlassian.jira.plugin.sy... ]
Sven Linstaedt commented on CDI-633:
------------------------------------
Some enhancement like that, yeah. A similar solution was already stated in CDI-493 and CDI-516. This new API enhancement should accept any {{java.lang.reflect.Type}}, that does not contain a TypeVariable, but will throw an {{IllegalArgumentException}} otherwise. Of course only the raw type of the event object could only be checked against the type parameter for consistency, so we loose a good amount of type safety here. But as these API is primary meant to be used by extensions like the majority of {{BeanManager}} methods, at least I am fine with it.
In addition the original methods ({{fireEvent(event, qualifiers)}} and {{resolveObserverMethods(event, qualifiers)}}) must be kept for backward compability and probably will keep the use the event object's class for resolution, which implies the event class must not have any type variable as this will cause the documented {{IllegalArgumentException}}.
> Introduce BeanManager.event()
> -----------------------------
>
> Key: CDI-633
> URL: https://issues.jboss.org/browse/CDI-633
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Martin Kouba
> Fix For: 2.0 .Final
>
>
> * this would allow to define the _specified type_ - the container may use the specified type to infer the parameterized type of the event types
> * the method should return {{javax.enterprise.event.Event<Object>}} with no qualifiers
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (CDI-633) Intoroduce BeanManager.event()
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/CDI-633?page=com.atlassian.jira.plugin.sy... ]
Matej Novotny commented on CDI-633:
-----------------------------------
I see, you cannot do anything with {{Event}} before deployment validation phase, so it won't help.
Since you only have BM at that point, the solution would be to add another BM method, which would allow to explicitly state the type as well, is that correct?
Something along these lines:
{code}
BeanManager#fire(type, event, qualifiers)
{code}
> Intoroduce BeanManager.event()
> ------------------------------
>
> Key: CDI-633
> URL: https://issues.jboss.org/browse/CDI-633
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Martin Kouba
> Fix For: 2.0 .Final
>
>
> * this would allow to define the _specified type_ - the container may use the specified type to infer the parameterized type of the event types
> * the method should return {{javax.enterprise.event.Event<Object>}} with no qualifiers
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (CDI-633) Intoroduce BeanManager.event()
by Sven Linstaedt (JIRA)
[ https://issues.jboss.org/browse/CDI-633?page=com.atlassian.jira.plugin.sy... ]
Sven Linstaedt commented on CDI-633:
------------------------------------
To be a more concrete: I tried to write a meta-extension allowing "binding" of beans by (e.g. like in "interceptor binding") firing custom events during container initialization, similar to {{ProcessAnnotatedType<T>}}, that may be handled by other extensions. The type parameter {{T}} is not known statically, but rather reflectively as {{java.lang.reflect.Type}}. So even being able to retrieve an {{Event<T>}} before {{AfterDeploymentValidation }} does not help in this case, as {{Event<T>}} was meant for use with a concrete type parameter {{T}} either via {{Class}} or {{TypeLiteral}}.
This proposal does not supersedes it's linked duplicates imho.
> Intoroduce BeanManager.event()
> ------------------------------
>
> Key: CDI-633
> URL: https://issues.jboss.org/browse/CDI-633
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Martin Kouba
> Fix For: 2.0 .Final
>
>
> * this would allow to define the _specified type_ - the container may use the specified type to infer the parameterized type of the event types
> * the method should return {{javax.enterprise.event.Event<Object>}} with no qualifiers
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (CDI-455) Allow building of TypeLiteral's with dynamic types
by Sven Linstaedt (JIRA)
[ https://issues.jboss.org/browse/CDI-455?page=com.atlassian.jira.plugin.sy... ]
Sven Linstaedt commented on CDI-455:
------------------------------------
At first I thought of {{TypeLiteral}} being a workaround for java's type erasure. Extending it by being able to create one from an unknown {{java.lang.Class}} with given type parameters or even {{java.lang.reflect.Type}} just to be able to "reuse" all existing APIs that accept a {{TypeLiteral}} smells like a dirty trick, as the benefit of type safety as mentioned before is lost.
Secondly we have a bunch of existing APIs, that are meant to be used with "dynamic types". Most of them reside in {{javax.enterprise.inject.spi.BeanManager}} like {{BeanManager#getBeans}} or {{BeanManager#getReference}}. If there is a need to extend something, it may be more suitable to extend these APIs.
> Allow building of TypeLiteral's with dynamic types
> --------------------------------------------------
>
> Key: CDI-455
> URL: https://issues.jboss.org/browse/CDI-455
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Lucas Ventura Carro
>
> It could be useful the building of {{TypeLiteral}}'s, but using dynamic types. This way, the types can be indicated at runtime and not in compile. This functionality is "doable" as it is done at [Guice|https://github.com/google/guice], a similar injection framework, and as [this post shows|http://luisfsgoncalves.wordpress.com/2010/09/08/generic-bindings-wi...].
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (CDI-633) Intoroduce BeanManager.event()
by Sven Linstaedt (JIRA)
[ https://issues.jboss.org/browse/CDI-633?page=com.atlassian.jira.plugin.sy... ]
Sven Linstaedt edited comment on CDI-633 at 10/10/16 4:38 AM:
--------------------------------------------------------------
[~manovotn] Not completely: {{javax.enterprise.event.Event<T>}} is meant for application driven event triggering. In order to narrow down the event type, you can either specify a {{java.lang.Class<T>}} or a for generics a {{javax.enterprise.util.TypeLiteral<U>}}.
As an extension developer, {{Event<T>}} is not sufficient as you can neither
# resolve {{Event<T>}} before {{AfterDeploymentValidation}} nor
# narrow down the event type by an extension-resolved {{java.lang.reflect.Type}}, which can not be hardcoded using {{TypeLiteral<U>}} as the static type is not known to the extension and TypeLiteral was not meant for being created out of some unknown {{Type}}.
So there is still a need for extending the existing method {{BeanManager#fire}} and of course keeping it backwards compatible as mentioned in CDI-493.
was (Author: tzwoenn):
[~manovotn] Not completely: {{javax.enterprise.event.Event<T>}} is meant for application driven event triggering. In order to narrow down the event type, you can either specify a {{java.lang.Class<T>}} or a for generics a {{javax.enterprise.util.TypeLiteral<U>}}.
As an extension developer, {{Event<T>}} is not sufficient as you can neither
# resolve {{Event<T>}} before{{AfterDeploymentValidation}} nor
# narrow down the event type by an extension-resolved {{java.lang.reflect.Type}}, which can not be hardcoded using {{TypeLiteral<U>}} as the static type is not known to the extension and TypeLiteral was not meant for being created out of some unknown {{Type}}.
So there is still a need for extending the existing method {{BeanManager#fire}} and of course keeping it backwards compatible as mentioned in CDI-493.
> Intoroduce BeanManager.event()
> ------------------------------
>
> Key: CDI-633
> URL: https://issues.jboss.org/browse/CDI-633
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Martin Kouba
> Fix For: 2.0 .Final
>
>
> * this would allow to define the _specified type_ - the container may use the specified type to infer the parameterized type of the event types
> * the method should return {{javax.enterprise.event.Event<Object>}} with no qualifiers
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (CDI-103) Support client controlled contexts
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-103?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-103:
-------------------------------------
Fix Version/s: 2.1 (Discussion)
(was: 2.0 (discussion))
> Support client controlled contexts
> ----------------------------------
>
> Key: CDI-103
> URL: https://issues.jboss.org/browse/CDI-103
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts
> Reporter: Pete Muir
> Fix For: 2.1 (Discussion)
>
>
> In a client controlled context, the client controls via some identifier (probably an identifier, but we should allow the context to inspect the injection point) which contextual instances it sees for a particular bean type. For example given:
> {code}
> @MyScope
> class Foo {
> String name;
> }
> {code}
> and a context which uses annotations to differentiate between contextual instance, these two injection points would see different instances:
> {code}
> @Inject @Bar Foo barFoo;
> @Inject @Baz Foo bazFoo;
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (CDI-110) Provide support for binding an invocation handler to an interface or abstract class
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-110?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-110:
-------------------------------------
Fix Version/s: 2.1 (Discussion)
(was: 2.0 (discussion))
> Provide support for binding an invocation handler to an interface or abstract class
> -----------------------------------------------------------------------------------
>
> Key: CDI-110
> URL: https://issues.jboss.org/browse/CDI-110
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Inheritance and Specialization
> Affects Versions: 1.0
> Reporter: George Gastaldi
> Labels: cdi
> Fix For: 2.1 (Discussion)
>
>
> The purpose of this feature is to allow interfaces and abstract classes to be automatically implemented by an invocation handler to which all abstract method invocations are delegated. The invocation handler would get "bound" to the type using the same strategy as is used for interceptor binding.
> Binding type:
> {code:java}
> @Target({ METHOD, TYPE })
> @Retention(RetentionPolicy.RUNTIME)
> @ServiceHandlerBindingType
> public @interface EchoService {}
> {code}
> Invocation handler:
> {code:java}
> @ServiceHandler
> @EchoService
> public class EchoServiceHandler {
> @AroundInvoke
> public Object invoke(InvocationContext ctx) {
> return ctx.getMethod().getName().toString();
> }
> }
> {code}
> Usage:
> {code:java}
> @EchoService
> public interface HelloWorld {
> String helloWorld();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (CDI-128) Ability to access CDI enhanced metadata from the InvocationContext.getMethod()
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-128?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-128:
-------------------------------------
Fix Version/s: 2.1 (Discussion)
(was: 2.0 (discussion))
> Ability to access CDI enhanced metadata from the InvocationContext.getMethod()
> ------------------------------------------------------------------------------
>
> Key: CDI-128
> URL: https://issues.jboss.org/browse/CDI-128
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Interceptors
> Affects Versions: 1.0
> Reporter: Richard Hightower
> Fix For: 2.1 (Discussion)
>
>
> The issues with InvocationContext is it was designed before CDI as part of EJB 3. In CDI, the meta-data will likely exist in an annotation, but it could exist in an XML file (Candi, and Seam XML Extension for CDI).
> For example, I am working on creating a standard interceptor for JCache 107. I can read the annotation from the getMethod of the InvocationContext, but if someone added the interception meta-data in an XML file, then it will not be available to InvocationContext.getMethod().getAnnotation(Cacheable.class).
> I propose we have an extension interface that extends InvocationContext called CDIInvocationContext that has a getAnnotated. This way if someone annotates in an XML file, then it is available to implementors for interceptors.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months