[JBoss JIRA] (CDI-517) assignability to parameterized required type
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-517?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-517:
-----------------------------------
wrote a small sample app to demonstrate the difference in behaviour with old and new containers.
https://github.com/struberg/cdispec-517
> assignability to parameterized required type
> --------------------------------------------
>
> Key: CDI-517
> URL: https://issues.jboss.org/browse/CDI-517
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Resolution
> Affects Versions: 1.1.PFD, 1.2.Final
> Reporter: Mark Struberg
>
> 2 days before the CDI-1.1 spec went PDF the following backward-incomatible change was made:
> {quote}
> -A raw bean type is considered assignable to a parameterized required type if the raw types are identical.
> + A raw bean type is considered assignable to a parameterized required type if the raw types are identical and all type parameters of the bean type are either unbounded type variables or java.lang.Object.
> {quote}
> This breaks a lot of projects and also is also not compatible with the JavaEE6 RI and the CDI-1.0 RI where this was explicitly allowed.
> This is a follow up to CDI-304.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month
[JBoss JIRA] (CDI-517) assignability to parameterized required type
by Mark Struberg (JIRA)
Mark Struberg created CDI-517:
---------------------------------
Summary: assignability to parameterized required type
Key: CDI-517
URL: https://issues.jboss.org/browse/CDI-517
Project: CDI Specification Issues
Issue Type: Bug
Components: Resolution
Affects Versions: 1.2.Final, 1.1.PFD
Reporter: Mark Struberg
2 days before the CDI-1.1 spec went PDF the following backward-incomatible change was made:
{quote}
-A raw bean type is considered assignable to a parameterized required type if the raw types are identical.
+ A raw bean type is considered assignable to a parameterized required type if the raw types are identical and all type parameters of the bean type are either unbounded type variables or java.lang.Object.
{quote}
This breaks a lot of projects and also is also not compatible with the JavaEE6 RI and the CDI-1.0 RI where this was explicitly allowed.
This is a follow up to CDI-304.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month
Changing our meeting time slot?
by Antoine Sabot-Durand
Hi all,
Following last week discussion, you’ll find a Doodle link below to choose your the best time slot for our meeting. I propose time slot on several days for 6-7pm CET or 8-9pm CET (I’m usually not available between 7-8pm). I took into consideration USA and Europe (majority of us) TZ.
Please fill the doodle so we could change our meeting slot and have more people able to join.
http://doodle.com/izh845adznk37vww <http://doodle.com/izh845adznk37vww>
thanks
Antoine
9 years, 1 month
Re: [cdi-dev] [weld-dev] How to skip CDI injection if a property is not configured in batch application?
by Mark Struberg
There is an easy trick though which we do at BatchEE:
The producer is @Dependent. So you can simply inject the InjectionPoint and inspect the current value in case it is not yet set.
LieGrue,
strub
> Am 09.03.2015 um 07:25 schrieb Jozef Hartinger <jharting(a)redhat.com>:
>
> Adding weld-dev.
>
> Hi Cheng,
>
> by defining a producer method you are basically saying "I am able to supply an object for this given type/qualifier combination". There is not way to opt out of it at runtime. Are you concerned about the JVM default values or the default values a user has provided?
>
> Jozef
>
> On 03/07/2015 05:54 PM, Cheng Fang wrote:
>> Hi Jozef,
>>
>> I'm having a question in using CDI injection in project JBeret (batch impl project), and would appreciate any help from you.
>>
>> A batch application (in Java SE or EE) can inject configured batch properties into batch artifact classes:
>>
>> @Inject
>> @javax.batch.api.BatchProperty(name = "batchPropName")
>> String batchPropName = "default name";
>>
>> The property value comes from job.xml, which is the batch job definition descriptor file:
>>
>> <batchlet ref="batchlet1">
>> <properties>
>> <property name="batchPropName" value="configured name"/>
>> </properties>
>> ...
>>
>> When "batchPropName" property is not configured in job.xml, the injection should not happen, and whatever java default field value should be preserved for batchPropName field.
>>
>> With our current batch CDI extension [1] and producer bean [2], it injects a null value into this field, overwriting the java default value, when the target batch property is not present.
>>
>> How to signal to Weld to skip performing the injection for those injection targets? Ideally, I hope it can be done from within producer methods, which is the place we retrieve batch properties and know whether they exist or not.
>>
>> I think this is also how Java EE field injection works. How do we handle it in EE, and is it something I can mirror?
>>
>> Thanks,
>> Cheng
>>
>> [1] https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/or...
>>
>> [2] https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/or...
>>
>>
>
> _______________________________________________
> weld-dev mailing list
> weld-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
9 years, 1 month
Re: [cdi-dev] [weld-dev] How to skip CDI injection if a property is not configured in batch application?
by Mark Struberg
Not possible. The jobs can also only get added at runtime. So you don not have this information during bootstrap.
LieGrue,
strub
> Am 09.03.2015 um 07:39 schrieb Jozef Hartinger <jharting(a)redhat.com>:
>
> You can actually work around by listening to ProcessAnnotatedType and removing the @Inject annotation from injection points for which there is no value to inject. Is the set of defined key-value pairs known at the time when the CDI extension is called?
>
> Jozef
>
> On 03/09/2015 07:25 AM, Jozef Hartinger wrote:
>> Adding weld-dev.
>>
>> Hi Cheng,
>>
>> by defining a producer method you are basically saying "I am able to supply an object for this given type/qualifier combination". There is not way to opt out of it at runtime. Are you concerned about the JVM default values or the default values a user has provided?
>>
>> Jozef
>>
>> On 03/07/2015 05:54 PM, Cheng Fang wrote:
>>> Hi Jozef,
>>>
>>> I'm having a question in using CDI injection in project JBeret (batch impl project), and would appreciate any help from you.
>>>
>>> A batch application (in Java SE or EE) can inject configured batch properties into batch artifact classes:
>>>
>>> @Inject
>>> @javax.batch.api.BatchProperty(name = "batchPropName")
>>> String batchPropName = "default name";
>>>
>>> The property value comes from job.xml, which is the batch job definition descriptor file:
>>>
>>> <batchlet ref="batchlet1">
>>> <properties>
>>> <property name="batchPropName" value="configured name"/>
>>> </properties>
>>> ...
>>>
>>> When "batchPropName" property is not configured in job.xml, the injection should not happen, and whatever java default field value should be preserved for batchPropName field.
>>>
>>> With our current batch CDI extension [1] and producer bean [2], it injects a null value into this field, overwriting the java default value, when the target batch property is not present.
>>>
>>> How to signal to Weld to skip performing the injection for those injection targets? Ideally, I hope it can be done from within producer methods, which is the place we retrieve batch properties and know whether they exist or not.
>>>
>>> I think this is also how Java EE field injection works. How do we handle it in EE, and is it something I can mirror?
>>>
>>> Thanks,
>>> Cheng
>>>
>>> [1] https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/or...
>>>
>>> [2] https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/or...
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> weld-dev mailing list
>>
>> weld-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
>
> _______________________________________________
> weld-dev mailing list
> weld-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
9 years, 1 month
[JBoss JIRA] (CDI-516) Firing events with dynamic parameterized types
by Sven Linstaedt (JIRA)
[ https://issues.jboss.org/browse/CDI-516?page=com.atlassian.jira.plugin.sy... ]
Sven Linstaedt commented on CDI-516:
------------------------------------
Opting for the second solution, as application code should not have to deal with java.lang.reflect.* and framework code (that needs to handle generic types) should not have to mess around with convenience oriented Instance- or Event-related code.
> Firing events with dynamic parameterized types
> ----------------------------------------------
>
> Key: CDI-516
> URL: https://issues.jboss.org/browse/CDI-516
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Reporter: Antonin Stefanutti
>
> For the time being, either by using {{Event.select(...)}}, respectively {{BeanManager.fireEvent(...)}}, it is not possible to fire an event whose runtime type is a dynamic parameterized type, as specified in [The {{Event}} interface|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#event]:
> {quote}
> If the container is unable to resolve the parameterized type of the event object, it uses the specified type to infer the parameterized type of the event types.
> If the runtime type of the event object contains an unresolvable type variable, an {{IllegalArgumentException}} is thrown.
> {quote}
> Respectively in [Firing an event|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bm_fire_event]:
> {quote}
> If the runtime type of the event object contains a type variable, an {{IllegalArgumentException}} is thrown.
> {quote}
> While, it is possible to pass a {{TypeLiteral}} to the {{Event.select(...)}} method, e.g.:
> {code}
> @Inject
> Event<Object> event;
> event.select(new TypeLiteral<String>() {});
> {code}
> It is not possible to pass a type variable known at runtime as the {{TypeLiteral}} class relies on the declared type variable and does not permit to override that behavior as the {{TypeLiteral.getType()}} method is declared {{final}}.
> Yet, there are use cases where that need is valid, for example:
> {code}
> <T> CdiEventEndpoint<T> cdiEventEndpoint(InjectionPoint ip, CamelContext context, @Any Event<Object> event) throws Exception {
> // Represents the runtime type for T
> Type type = ((ParameterizedType) ip.getType()).getActualTypeArguments()[0];
> String uri = endpointUri(type, ip.getQualifiers());
> if (context.hasEndpoint(uri) == null) {
> // Work around to pass the dynamic type
> TypeLiteral<T> literal = new TypeLiteral<T>() {};
> for (Field field : TypeLiteral.class.getDeclaredFields()) {
> if (field.getType().equals(Type.class)) {
> field.setAccessible(true);
> field.set(literal, type);
> break;
> }
> }
> // Here we used the dynamic type
> Event<T> typedEvent = event.select(literal, ip.getQualifiers().toArray(new Annotation[ip.getQualifiers().size()]));
> context.addEndpoint(uri, new CdiEventEndpoint<>(typedEvent, uri, context));
> }
> return CamelContextHelper.getMandatoryEndpoint(context, uri, CdiEventEndpoint.class);
> }
> {code}
> In the example above, the {{TypeLiteral}} class could have a constructor taking the dynamic type as argument.
> Another alternative would be to enrich the {{BeanManager}} SPI with the following method:
> {code}
> public void fireEvent(Object event, Type type, Annotation... qualifiers);
> {code}
> That use case is taken from the [CDI event Camel endpoint|https://github.com/astefanutti/camel-cdi/blob/84426570bcd7815eb9...] in the [Camel CDI extension|https://github.com/astefanutti/camel-cdi].
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month
[JBoss JIRA] (CDI-516) Firing events with dynamic parameterized types
by Antonin Stefanutti (JIRA)
[ https://issues.jboss.org/browse/CDI-516?page=com.atlassian.jira.plugin.sy... ]
Antonin Stefanutti updated CDI-516:
-----------------------------------
Description:
For the time being, either by using {{Event.select(...)}}, respectively {{BeanManager.fireEvent(...)}}, it is not possible to fire an event whose runtime type is a dynamic parameterized type, as specified in [The {{Event}} interface|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#event]:
{quote}
If the container is unable to resolve the parameterized type of the event object, it uses the specified type to infer the parameterized type of the event types.
If the runtime type of the event object contains an unresolvable type variable, an {{IllegalArgumentException}} is thrown.
{quote}
Respectively in [Firing an event|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bm_fire_event]:
{quote}
If the runtime type of the event object contains a type variable, an {{IllegalArgumentException}} is thrown.
{quote}
While, it is possible to pass a {{TypeLiteral}} to the {{Event.select(...)}} method, e.g.:
{code}
@Inject
Event<Object> event;
event.select(new TypeLiteral<String>() {});
{code}
It is not possible to pass a type variable known at runtime as the {{TypeLiteral}} class relies on the declared type variable and does not permit to override that behavior as the {{TypeLiteral.getType()}} method is declared {{final}}.
Yet, there are use cases where that need is valid, for example:
{code}
<T> CdiEventEndpoint<T> cdiEventEndpoint(InjectionPoint ip, CamelContext context, @Any Event<Object> event) throws Exception {
// Represents the runtime type for T
Type type = ((ParameterizedType) ip.getType()).getActualTypeArguments()[0];
String uri = endpointUri(type, ip.getQualifiers());
if (context.hasEndpoint(uri) == null) {
// Work around to pass the dynamic type
TypeLiteral<T> literal = new TypeLiteral<T>() {};
for (Field field : TypeLiteral.class.getDeclaredFields()) {
if (field.getType().equals(Type.class)) {
field.setAccessible(true);
field.set(literal, type);
break;
}
}
// Here we used the dynamic type
Event<T> typedEvent = event.select(literal, ip.getQualifiers().toArray(new Annotation[ip.getQualifiers().size()]));
context.addEndpoint(uri, new CdiEventEndpoint<>(typedEvent, uri, context));
}
return CamelContextHelper.getMandatoryEndpoint(context, uri, CdiEventEndpoint.class);
}
{code}
In the example above, the {{TypeLiteral}} class could have a constructor taking the dynamic type as argument.
Another alternative would be to enrich the {{BeanManager}} SPI with the following method:
{code}
public void fireEvent(Object event, Type type, Annotation... qualifiers);
{code}
That use case is taken from the [CDI event Camel endpoint|https://github.com/astefanutti/camel-cdi/blob/84426570bcd7815eb9...] in the [Camel CDI extension|https://github.com/astefanutti/camel-cdi].
was:
For the time being, either by using {{Event.select(...)}}, respectively {{BeanManager.fireEvent(...)}}, it is not possible to fire an event whose runtime type is a dynamic parameterized type, as specified in [The {{Event}} interface|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#event]:
{quote}
If the container is unable to resolve the parameterized type of the event object, it uses the specified type to infer the parameterized type of the event types.
If the runtime type of the event object contains an unresolvable type variable, an {{IllegalArgumentException}} is thrown.
{quote}
Respectively in [Firing an event|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bm_fire_event]:
{quote}
If the runtime type of the event object contains a type variable, an {{IllegalArgumentException}} is thrown.
{quote}
While, it is possible to pass a {{TypeLiteral}} to the {{Event.select(...)}} method, e.g.:
{code}
@Inject
Event<Object> event;
event.select(new TypeLiteral<String>() {});
{code}
It is not possible to pass a type variable known at runtime as the {{TypeLiteral}} class relies on the declared type variable and does not permit to override that behavior as the {{TypeLiteral.getType()}} method is declared {{final}}.
Yet, there are use cases where that need is valid, for example:
{code}
<T> CdiEventEndpoint<T> cdiEventEndpoint(InjectionPoint ip, CamelContext context, @Any Event<Object> event) throws Exception {
// Represents the runtime type for T
Type type = ((ParameterizedType) ip.getType()).getActualTypeArguments()[0];
String uri = endpointUri(type, ip.getQualifiers());
if (context.hasEndpoint(uri) == null) {
// Work around to pass the dynamic type
TypeLiteral<T> literal = new TypeLiteral<T>() {};
for (Field field : TypeLiteral.class.getDeclaredFields()) {
if (field.getType().equals(Type.class)) {
field.setAccessible(true);
field.set(literal, type);
break;
}
}
// Here we used the dynamic type
Event<T> typedEvent = event.select(literal, ip.getQualifiers().toArray(new Annotation[ip.getQualifiers().size()]));
context.addEndpoint(uri, new CdiEventEndpoint<>(typedEvent, uri, context));
}
return CamelContextHelper.getMandatoryEndpoint(context, uri, CdiEventEndpoint.class);
}
{code}
In the example above, the {{TypeLiteral}} class could have a constructor taking the dynamic type as argument.
Another alternative would be to enrich the {{BeanManager}} SPI with the following method:
{code}
public void fireEvent(Object event, Type type, Annotation... qualifiers);
{code}
> Firing events with dynamic parameterized types
> ----------------------------------------------
>
> Key: CDI-516
> URL: https://issues.jboss.org/browse/CDI-516
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Reporter: Antonin Stefanutti
>
> For the time being, either by using {{Event.select(...)}}, respectively {{BeanManager.fireEvent(...)}}, it is not possible to fire an event whose runtime type is a dynamic parameterized type, as specified in [The {{Event}} interface|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#event]:
> {quote}
> If the container is unable to resolve the parameterized type of the event object, it uses the specified type to infer the parameterized type of the event types.
> If the runtime type of the event object contains an unresolvable type variable, an {{IllegalArgumentException}} is thrown.
> {quote}
> Respectively in [Firing an event|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bm_fire_event]:
> {quote}
> If the runtime type of the event object contains a type variable, an {{IllegalArgumentException}} is thrown.
> {quote}
> While, it is possible to pass a {{TypeLiteral}} to the {{Event.select(...)}} method, e.g.:
> {code}
> @Inject
> Event<Object> event;
> event.select(new TypeLiteral<String>() {});
> {code}
> It is not possible to pass a type variable known at runtime as the {{TypeLiteral}} class relies on the declared type variable and does not permit to override that behavior as the {{TypeLiteral.getType()}} method is declared {{final}}.
> Yet, there are use cases where that need is valid, for example:
> {code}
> <T> CdiEventEndpoint<T> cdiEventEndpoint(InjectionPoint ip, CamelContext context, @Any Event<Object> event) throws Exception {
> // Represents the runtime type for T
> Type type = ((ParameterizedType) ip.getType()).getActualTypeArguments()[0];
> String uri = endpointUri(type, ip.getQualifiers());
> if (context.hasEndpoint(uri) == null) {
> // Work around to pass the dynamic type
> TypeLiteral<T> literal = new TypeLiteral<T>() {};
> for (Field field : TypeLiteral.class.getDeclaredFields()) {
> if (field.getType().equals(Type.class)) {
> field.setAccessible(true);
> field.set(literal, type);
> break;
> }
> }
> // Here we used the dynamic type
> Event<T> typedEvent = event.select(literal, ip.getQualifiers().toArray(new Annotation[ip.getQualifiers().size()]));
> context.addEndpoint(uri, new CdiEventEndpoint<>(typedEvent, uri, context));
> }
> return CamelContextHelper.getMandatoryEndpoint(context, uri, CdiEventEndpoint.class);
> }
> {code}
> In the example above, the {{TypeLiteral}} class could have a constructor taking the dynamic type as argument.
> Another alternative would be to enrich the {{BeanManager}} SPI with the following method:
> {code}
> public void fireEvent(Object event, Type type, Annotation... qualifiers);
> {code}
> That use case is taken from the [CDI event Camel endpoint|https://github.com/astefanutti/camel-cdi/blob/84426570bcd7815eb9...] in the [Camel CDI extension|https://github.com/astefanutti/camel-cdi].
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month
[JBoss JIRA] (CDI-516) Firing events with dynamic parameterized types
by Antonin Stefanutti (JIRA)
Antonin Stefanutti created CDI-516:
--------------------------------------
Summary: Firing events with dynamic parameterized types
Key: CDI-516
URL: https://issues.jboss.org/browse/CDI-516
Project: CDI Specification Issues
Issue Type: Feature Request
Components: Events
Reporter: Antonin Stefanutti
For the time being, either by using {{Event.select(...)}}, respectively {{BeanManager.fireEvent(...)}}, it is not possible to fire an event whose runtime type is a dynamic parameterized type, as specified in [The {{Event}} interface|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#event]:
{quote}
If the container is unable to resolve the parameterized type of the event object, it uses the specified type to infer the parameterized type of the event types.
If the runtime type of the event object contains an unresolvable type variable, an {{IllegalArgumentException}} is thrown.
{quote}
Respectively in [Firing an event|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bm_fire_event]:
{quote}
If the runtime type of the event object contains a type variable, an {{IllegalArgumentException}} is thrown.
{quote}
While, it is possible to pass a {{TypeLiteral}} to the {{Event.select(...)}} method, e.g.:
{code}
@Inject
Event<Object> event;
event.select(new TypeLiteral<String>() {});
{code}
It is not possible to pass a type variable known at runtime as the {{TypeLiteral}} class relies on the declared type variable and does not permit to override that behavior as the {{TypeLiteral.getType()}} method is declared {{final}}.
Yet, there are use cases where that need is valid, for example:
{code}
<T> CdiEventEndpoint<T> cdiEventEndpoint(InjectionPoint ip, CamelContext context, @Any Event<Object> event) throws Exception {
// Represents the runtime type for T
Type type = ((ParameterizedType) ip.getType()).getActualTypeArguments()[0];
String uri = endpointUri(type, ip.getQualifiers());
if (context.hasEndpoint(uri) == null) {
// Work around to pass the dynamic type
TypeLiteral<T> literal = new TypeLiteral<T>() {};
for (Field field : TypeLiteral.class.getDeclaredFields()) {
if (field.getType().equals(Type.class)) {
field.setAccessible(true);
field.set(literal, type);
break;
}
}
// Here we used the dynamic type
Event<T> typedEvent = event.select(literal, ip.getQualifiers().toArray(new Annotation[ip.getQualifiers().size()]));
context.addEndpoint(uri, new CdiEventEndpoint<>(typedEvent, uri, context));
}
return CamelContextHelper.getMandatoryEndpoint(context, uri, CdiEventEndpoint.class);
}
{code}
In the example above, the {{TypeLiteral}} class could have a constructor taking the dynamic type as argument.
Another alternative would be to enrich the {{BeanManager}} SPI with the following method:
{code}
public void fireEvent(Object event, Type type, Annotation... qualifiers);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month
explicit bean archives discovery-mode 'annotated'
by Mark Struberg
Hi!
I think I’ve implemented the behavour the spec defines - but it does not make much sense.
First let’s look at the spec:
11.5.6. ProcessAnnotatedType event
The container must fire an event, before it processes a type, for every Java class, interface
(excluding the special kind of interface declaration annotation type) or enum DISCOVERED
as defined in Section 12.4.1, “Type discovery”
12.4.1 defines…
First the container must discover types. The container discovers:
• each Java class with a bean defining annotation in an implicit bean archive.
And in 2.5 we can read
"f the bean discovery mode is annotated then:
• bean classes that don’t have bean defining annotation (as defined in Section 2.5.1, “Bean defining annotations”) and are not bean classes of sessions beans, are NOT DISCOVERED“
Which to me means that for a BDA with discovery-mode = „annotated“ we ONLY must fire ProcessAnnotatedType for classes with bean defining annotations, and NOT for interfaces or enums.
If this is true, then it is a huge mess for lots of CDI Extensions. It basically renders the ‚annotated‘ mode pretty much useless.
What we really need instead is a mode which will not automatically make a @Dependent bean out of every class later. But I really would ‚discover‘ all classes in a BDA and pass them to ProcessAnnotatedType.
Some way to fix this or do we have to wait for CDI-2.0 to repair CDI-1.1?
LieGrue,
strub
9 years, 1 month
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'detected'
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-420:
-------------------------------------
This interface/enum discovery use-case very often uses a marker annotation (e.g. @MessageBundle). Such extension can work around this limitation by making the marker annotation a @Stereotype.
> add a bean-discovery-mode 'detected'
> ------------------------------------
>
> Key: CDI-420
> URL: https://issues.jboss.org/browse/CDI-420
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Packaging and Deployment
> Affects Versions: TBD
> Reporter: Mark Struberg
>
> This is for some future CDI release.
> We currently only have 3 bean-discovery-modes
> * none
> * all
> * annotated
> The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for
> • each Java class, interface or enum deployed in an explicit bean archive, and
> • each Java class with a bean defining annotation in an implicit bean archive.
> • each session bean
> Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation.
> It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing.
> I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea...
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month
