From jharting at redhat.com  Mon Mar  9 02:25:36 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Mon, 09 Mar 2015 07:25:36 +0100
Subject: [weld-dev] How to skip CDI injection if a property is not
 configured in batch application?
In-Reply-To: <54FB2D34.5090005@redhat.com>
References: <54FB2D34.5090005@redhat.com>
Message-ID: <54FD3CE0.1070706@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/org/jberet/creation/BatchCDIExtension.java
>
> [2] 
> https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/creation/BatchBeanProducer.java
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150309/f28bb04d/attachment.html 

From jharting at redhat.com  Mon Mar  9 02:39:47 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Mon, 09 Mar 2015 07:39:47 +0100
Subject: [weld-dev] How to skip CDI injection if a property is not
 configured in batch application?
In-Reply-To: <54FD3CE0.1070706@redhat.com>
References: <54FB2D34.5090005@redhat.com> <54FD3CE0.1070706@redhat.com>
Message-ID: <54FD4033.2030706@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/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
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150309/11822cd5/attachment-0001.html 

From jharting at redhat.com  Mon Mar  9 05:48:39 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Mon, 09 Mar 2015 10:48:39 +0100
Subject: [weld-dev] [cdi-dev] How to skip CDI injection if a property is
 not configured in batch application?
In-Reply-To: <54FD68C0.5060003@redhat.com>
References: <54FB2D34.5090005@redhat.com>
	<54FD3CE0.1070706@redhat.com>	<105DD0AB-949B-42D0-AD7C-9A71DB832432@yahoo.de>
	<54FD68C0.5060003@redhat.com>
Message-ID: <54FD6C77.7080705@redhat.com>

Moving the thread back to weld-dev

On 03/09/2015 10:32 AM, Jozef Hartinger wrote:
> How do you obtain the current value of a field from an InjectionPoint?
> Do you use proprietary APIs for that?
>
> Jozef
>
> On 03/09/2015 09:52 AM, Mark Struberg wrote:
>> 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 at 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/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
>>> weld-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


From jharting at redhat.com  Mon Mar 16 04:23:47 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Mon, 16 Mar 2015 09:23:47 +0100
Subject: [weld-dev] How to skip CDI injection if a property is not
 configured in batch application?
In-Reply-To: <54FDB182.9010809@redhat.com>
References: <54FB2D34.5090005@redhat.com> <54FD3CE0.1070706@redhat.com>
	<54FD4033.2030706@redhat.com> <54FDB182.9010809@redhat.com>
Message-ID: <55069313.5090000@redhat.com>

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
>>> weld-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150316/2a7b486c/attachment.html 

From jharting at redhat.com  Thu Mar 26 09:33:03 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Thu, 26 Mar 2015 14:33:03 +0100
Subject: [weld-dev] Weld 2.2.10.Final
Message-ID: <55140A8F.3030307@redhat.com>

Weld 2.2.10.Final is now released. Again, this is a bug-fixing release 
with minor performance improvements in the area of disposer methods.

In addition, a new unified way of configuring Weld was added (expect 
blog post on the topic soon). See the docs for details: 
http://docs.jboss.org/weld/reference/2.2.10.Final/en-US/html/configure.html

Release notes: 
https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310891&version=12326325
Download: http://weld.cdi-spec.org/download/