[webbeans-dev] Re: XML configuration format

[Scott Ferguson]

On Dec 21, 2008, at 11:59 AM, Gavin King wrote:

>> i.e. removing the old 3rd rule because it was making things more  
>> confusing.
>> The slight extra verbosity by requiring <Current/> for an injected  
>> type is
>> outweighed by the simplification, and consistency with 9.2.6.
>
> This change would amount to *always* having to specify <Current/> in
> the common case where an injection point is not an inline Web Bean
> definition. I'm really not keen on that.

The inline bean is an important case for us because we essentially use  
inline beans to configure all our JavaEE specs: servlet web.xml,  
jsp .tld, JSF xml, EAR application.xml, etc.  For us, the servlet <web- 
app> is just a bean and all the configuration tags in the web.xml are  
inline beans.  It's very flexible and powerful.

Bah.  Nevermind.  I just checked the draft and you'd need to make more  
changes to give WebBeans that power.  Our case needs the ability to  
rewrite the example in 9.6 as

<myapp:Admin>
   <ApplicationScoped/>

   <myapp:username>gavin</myapp:username>

   <myapp:name>
     <myapp:first-name>Gavin</myapp:first-name>
     <myapp:last-name>King</myapp:last-name>
   </myapp:name>
</myapp:Admin>

Assuming Admin.setName(Name name) exists and Name is a concrete class.

If WebBeans allowed that, it could configure every JavaEE spec.

>
> I'm inclined in this direction for another reason: I want to be able  
> to say
> (at some point in the future) that @PersistentContext, @Resource, etc,
> are just Web Beans binding types. That's possible if we have setter
> injection, but it's not possible today.

Good!  I was afraid of a philosophical objection to setter injection.

> However, it raises the issue of how we would distinguish setter  
> injection
> from field injection in the XML. Does:
>
>    <my:foo>...</my:foo>
>
> represent the field "foo" or the setter "setFoo()"? Or should property
> injection look like:
>
>    <my:setFoo>...</my:setFoo>
>
> which works, but is not really "historic".

It should follow the standard bean format.  There really shouldn't be  
any need to distinguish between the two.  If a setter exists, it would  
take priority over the field because it's more powerful.

>
>> 4) Annotation declaration is great.  I would like the ability to add
>> non-webbeans annotations (for service declarations/introspection),  
>> but that
>> non-critical and could certainly be put off until a later spec.
>
> Yes, I would also like this facility, but also kinda useless without  
> a full
> metamodel API, which I think is something we're going to run out of
> time to do, I'm afraid.

Right.  I wasn't really expecting it in this draft.

For my use, adding a Bean.getDeclaredAnnotations() would do the  
trick.  My main purpose is to deploy beans as services at startup  
time, similar to EJB message driven beans or servlets.  All I need is  
the configured, merged annotations on the bean to make that happen.  I  
don't need any special restrictions on the annotations, since the  
startup code knows its own annotations.

-- Scot

>
>
>
> -- 
> Gavin King
> gavin.king at gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
>
>