Re: [webbeans-dev] Re: XML configuration format
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(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org