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?