Other than this I am not aware of any other way of suppressing CDI/Weld
injection. Since you have control over the producer methods you could
perhaps implement this on the JBeret side using thread locals to pass
the injected instance/default values around?
On 03/09/2015 03:43 PM, Cheng Fang wrote:
(I just subscribed to cdi-dev, and tried to post to it several times,
but bounced back, so send to you)
Thanks, Jozef.
I'm mostly concerned with user-supplied default field values. For JVM
default field values, we currently just let CDI inject null, or
primitive defaults to it.
I just tried your suggestion, adding the following method to
BatchCDIExtension class:
public<T>voidprocessAnnotatedType(@ObservesProcessAnnotatedType<T> pat,
BeanManager beanManager) {...}
and found batch properties are not yet available when it is called. This
method seems to be called during scanning, which is
pretty early stage.
Cheng
On 3/9/15 2:39 AM, Jozef Hartinger wrote:
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/org/jberet/creation/BatchCDIExtension.java
[2]
https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/creation/BatchBeanProducer.java
_______________________________________________
weld-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/weld-dev
_______________________________________________
weld-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/weld-dev
