WELD-862 and Seam Cron
by Peter Royle
Hi,
I'm aiming to make a release of Seam Cron available within the next two weeks. Currently there is an outstanding issue (https://issues.jboss.org/browse/WELD-862) which prevents Cron from running properly with Weld. I have been able to carry on developing Cron by testing it against OpenWebBeans, but obviously if we are to release a Seam module it should work against Weld.
It would be nice if WELD-862 could be fixed as soon a possible so that all future versions will work well with Cron.
But more importantly I also probably need to do something special in Cron so that it will work with the version of Weld already deployed in JBoss AS and Glassfish, which will contain the bug. The workaround mentioned in the bug report is to deep copy the InvocationContext. I attempted to do this by serialising and unserialising the InvocationContext but couldn't due to UnserializableExceptions. Does anyone have any advice for me about how I might be able to work around this bug to support existing versions of Weld?
Cheers,
Pete R
2 months, 2 weeks
Re: [weld-dev] How to skip CDI injection if a property is not configured in batch application?
by Jozef Hartinger
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/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
>>
>
11 years
Re: [weld-dev] [cdi-dev] How to skip CDI injection if a property is not configured in batch application?
by Jozef Hartinger
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(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
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)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(a)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.
11 years
Re: [weld-dev] How to skip CDI injection if a property is not configured in batch application?
by Jozef Hartinger
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...
>
>
11 years
