(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/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 >