[seam-dev] XML Configuration of producer fields

[Pete Muir]

Makes sense - especially in the case of generic beans, and exposing "primitives" to the app from XML.

On 25 Aug 2010, at 11:35, Stuart Douglas wrote:

> 
> No, it seems silly to force the user to create a class with a field solely so they can then configure it via XML. It will be applied to an existing field internally, but on a class that is part of the seam xml implementation.
> 
> Stuart 
> 
> On 25/08/2010, at 8:33 PM, Pete Muir wrote:
> 
>> 
>> On 25 Aug 2010, at 11:01, Stuart Douglas wrote:
>> 
>>> 
>>> On 24/08/2010, at 9:16 PM, Pete Muir wrote:
>>> 
>>>> Agreed, this would be very useful. 
>>>> 
>>>> The only (practical) issue I see is that Weld currently doesn't expect AnnotatedTtypes to be respected for EE-style injection (in some/all cases). I suspect that it should (nb. this is large a change in the container integration contract).
>>>> 
>>>> On 24 Aug 2010, at 09:39, Stuart Douglas wrote:
>>>> 
>>>>> I think that seam-xml needs to ability to programatically add resource (and other) producer fields.  My proposed syntax is:
>>>>> 
>>>>> <s:EntityManager>
>>>>> <s:producerField/>
>>>>> <s:PersistenceContext unitName="customer" />
>>>>> <my:CustomerDatasource/>
>>>>> </s:EntityManager>
>>>>> 
>>>>> which would be equivalent to:
>>>>> 
>>>>> @Produces
>>>>> @PersistenceContext(unitName="main")
>>>>> @CustomerDatasource
>>>>> EntityManager entityManager;
>>>>> 
>>>>> This will also support other types of producer fields, such as weld extension generic bean producer fields and primitives:
>>>>> 
>>>>> 
>>>>> <s:String>
>>>>> <s:producerField/>
>>>>> <my:ApplicationVersion />
>>>>> <s:value>3.0.0.GA</s:value>
>>>>> </s:String>
>>>> 
>>>> I think it should be:
>>>> 
>>>> <ee:EntityManager>
>>>> <ee:Produces />
>>>> <ee:PersistenceContext unitName="customer" />
>>>> <my:CustomerDatasource/>
>>>> </ee:EntityManager>
>>>> 
>>>> What was the reason for introducing the special producerField keyword?
>>> 
>>> It was to distinguish these from normal bean declarations, however @Produces will never be applied directly to a bean class, so that should be enough.
>> 
>> Ah, so you aren't applying this to an existing field?
>