Providing bean name aware feature| JBoss.org Content Archive (Read Only)

15. Re: Providing bean name aware feature

adrian.brock Jul 17, 2007 7:23 AM (in response to alesj)

I'm not overly keen on this syntax

<inject fromContext="name"/>

since the injection form with an explicit "bean"

<inject/>

is used for injection by type.

16. Re: Providing bean name aware feature

alesj Jul 17, 2007 8:27 AM (in response to alesj)

"adrian@jboss.org" wrote:
I thought I said not to add that xml config?
You're not listening to any of my objections on this which has just led to all
sorts of hacks and stupid configurations.

Yup.
I did respond I'll do them both though. :-(

The thing is people - like ThomasD - want to write as little code as possible to get name injected.

If he needs to write the whole

<property name="name"><inject fromContext="name"/></property>

it's almost the same if he writes

<property name="name">MyBeanName</property>

Even less chars on short names. :-)

But I agree auto-injection has its advantages. :-)

"adrian@jboss.org" wrote:

1) The name injection should be configured on a property
e.g. something like
<property name="name"><inject fromContext="name"/></property>
You should be able to inject the bean name anywhere, e.g.
on a parameter to the constructor
<constructor>
<parameter><inject fromContext="name"/></parameter>
</constructor>
and even potentially use it to resolve an alias to the real name
<inject bean="SomeAlias" fromContext="name"/>
2) This just matches what should be doable and should be done via an annotation
@inject(fromContext="name")
public void setName(String name);

Yup, I agree totally.
The parameter configuration should be there.
And I'm also not keen on

<inject fromContext="name"/>

So that I don't screw it up for the Nth time, what should we use then? :-)

And I don't understand what you meant with alias usage?

"adrian@jboss.org" wrote:

3) The idea of hardwiring "setName" into the microcontainer code
as some kind of default is just stupid.
e.g. What if the bean already uses the "name" property for something else?

You should be aware that setName is not used for bean name, and you actually set name-method attribute.

17. Re: Providing bean name aware feature

adrian.brock Jul 17, 2007 8:56 AM (in response to alesj)

"alesj" wrote:
"adrian@jboss.org" wrote:
I thought I said not to add that xml config?
You're not listening to any of my objections on this which has just led to all
sorts of hacks and stupid configurations.

Yup.
I did respond I'll do them both though. :-(

I said don't do it, to which you responded "I'll do it anyway. ;-)

The thing is people - like ThomasD - want to write as little code as possible to get name injected.

Yes that is the annotation.

So that I don't screw it up for the Nth time, what should we use then? :-)

We just need a way to say I want to inject some metadata from the context.
There could be other things in future like:

@Inject(fromContext="metadata")
void setMetaData(MetaData md);

@Inject(fromContext="scope")
void setScope(Scope scope);

Though I doubt they will get used that often.
More likely would be the GUID when it has been implemented.

Injecting the name is probably not what people want anyway
if the name exists in multiple scopes/deployments.

@Inject(fromContext="id")
void setID(Object id);

"adrian@jboss.org" wrote:

3) The idea of hardwiring "setName" into the microcontainer code
as some kind of default is just stupid.
e.g. What if the bean already uses the "name" property for something else?

You should be aware that setName is not used for bean name, and you actually set name-method attribute.

Yes, but this is not what we want the annotation to look like.
The XML should reasonably match the annotation in structure and features.

If you're talking about ease of use then you can always have an
alternative annotation/xml element that means the same thing as the long winded
injection. e.g.

@BeanName // == @Inject(fromContext="name")
public void setName(String name);

<property name="name"><bean-name/></property>
or even
<bean-name property="name"/>

Both of the xml examples above could be parsed to the real PropertyMetaData

<property name="name"><inject fromContext="name"/></property>

The point is that the internal MetaData model remains clean.

The only thing you are changing internally is the "inject metadata" to allow
it to get things from the context instead of another bean.

You can do whatever tricks you like with the xml and annotations to remove
any boiler plate as long it produces the same metadata underneath.

There's a number of other areas where such a "shorthand" would be useful.

18. Re: Providing bean name aware feature

alesj Jul 17, 2007 11:02 AM (in response to alesj)

"adrian@jboss.org" wrote:

I said don't do it, to which you responded "I'll do it anyway. ;-)

I can deny it and delete/edit the post. :-)
But the 'mea culpa' would stay and haunt me ...

The point is that the internal MetaData model remains clean.

The only thing you are changing internally is the "inject metadata" to allow
it to get things from the context instead of another bean.

You can do whatever tricks you like with the xml and annotations to remove
any boiler plate as long it produces the same metadata underneath.

There's a number of other areas where such a "shorthand" would be useful.

Yup.
This is what it should have been done in the first place. :-(
I'll ditch my crap and rewrite this to the upper features.

If there is a bean attribute on the element as well, should I do the actual bean context lookup and perform the fromContext on that context?

And for all the other cases - e.g. type and fromContext - throw exception?

19. Re: Providing bean name aware feature

alesj Jul 17, 2007 3:21 PM (in response to alesj)

"alesj" wrote:

I'll ditch my crap and rewrite this to the upper features.

I've added FromContext to AbstractInjectionValueMetaData to handle injection form (Kernel|XYZ)ControllerContext.

 <bean name="set_name_bean" class="org.jboss.test.kernel.deployment.support.NameAwareBean">
 <property name="name"><inject fromContext="name"/></property>
 </bean>

 <beanfactory name="set_name_factory" class="org.jboss.test.kernel.deployment.support.NameAwareBean">
 <property name="name"><inject fromContext="name"/></property>
 </beanfactory>

 <bean name="metadata" class="org.jboss.test.kernel.deployment.support.NameAwareBean">
 <property name="metadata"><inject fromContext="metadata"/></property>
 </bean>

 <bean name="scopekey" class="org.jboss.test.kernel.deployment.support.NameAwareBean">
 <property name="scopeKey"><inject fromContext="scope"/></property>
 </bean>

 <bean name="dynamic" class="org.jboss.test.kernel.deployment.support.NameAwareBean">
 <property name="dynamic"><inject fromContext="getBeanMetaData"/></property>
 </bean>

 <bean name="other" class="org.jboss.test.kernel.deployment.support.NameAwareBean">
 <property name="name"><inject bean="set_name_bean" fromContext="name"/></property>
 </bean>

Currently there are these lookups / injections defined:
- name
- metadata
- scope
- id
- dynamic

If none of the first 4 is recognised, dynamic is used.
Dynamic tries to execute the getter method gained from the actual string value of fromContext attribute on the underlying context.

 public Object executeLookup(ControllerContext context) throws Throwable
 {
 Method method = findMethod(context.getClass());
 if (method == null)
 throw new IllegalArgumentException("No such getter on context class: " + getFromString());
 return ReflectionUtils.invoke(method, context, new Object[]{});

Is this dynamic OK to stay?
I added it to cover some exotic cases on-the-fly, but I can easily remove it. :-)

20. Re: Providing bean name aware feature

alesj Jul 18, 2007 2:18 AM (in response to alesj)

I've added two more FromContext impls:
- alias
- beaninfo

Should we return a proxy in the case of beaninfo and dynamic, to make them immutable / unmodifiable?

21. Re: Providing bean name aware feature

adrian.brock Jul 18, 2007 11:40 AM (in response to alesj)

"alesj" wrote:

If there is a bean attribute on the element as well, should I do the actual bean context lookup and perform the fromContext on that context?

Yes, that's what I said about resolving aliases.
Another one might "give me the scope of another bean"

<property name="scopeOfX"><inject bean"X" fromContext="scope"/>

P.S. I'm not suggesting you implement anything other than "name" for now,
but make it easy to add new ones as they are demanded make sense.

22. Re: Providing bean name aware feature

adrian.brock Jul 18, 2007 11:42 AM (in response to alesj)

"alesj" wrote:
I've added two more FromContext impls:
- alias

That doesn't make sense, since you have multiple aliases.

- beaninfo

Should we return a proxy in the case of beaninfo and dynamic, to make them immutable / unmodifiable?

Good idea. :-)
Although I think you only need a wrapper/delegate (no reflection)
rather than a full proxy.

23. Re: Providing bean name aware feature

alesj Jul 18, 2007 11:48 AM (in response to alesj)

"adrian@jboss.org" wrote:

Yes, that's what I said about resolving aliases.

Done.

"adrian@jboss.org" wrote:

Another one might "give me the scope of another bean"
<property name="scopeOfX"><inject bean"X" fromContext="scope"/>

Also done. ;-)

"adrian@jboss.org" wrote:

P.S. I'm not suggesting you implement anything other than "name" for now, but make it easy to add new ones as they are demanded make sense.

Even if it's already done? ;-)

24. Re: Providing bean name aware feature

alesj Jul 18, 2007 11:50 AM (in response to alesj)

"adrian@jboss.org" wrote:

That doesn't make sense, since you have multiple aliases.

Just changed it to 'aliases'.

"adrian@jboss.org" wrote:

Good idea. :-)
Although I think you only need a wrapper/delegate (no reflection)
rather than a full proxy.

Finally no objection. :-)
Wrapper it is!

25. Re: Providing bean name aware feature

alesj Jul 19, 2007 5:18 AM (in response to alesj)

"alesj" wrote:

Wrapper it is!

Can / should I add unmodifiable wrappers to SPI?

26. Re: Providing bean name aware feature

adrian.brock Jul 19, 2007 6:45 AM (in response to alesj)

I don't see why not. Put them in a "helpers" subpackage of the relevant spi.