-
1. Re: Providing bean name aware feature
alesj Jul 13, 2007 5:06 AM (in response to alesj)This is done.
Comment from JIRA task:
Support for injecting bean name is added both to plain bean and to beanfactory as well:<bean name="MyPlainBeanName" class="org.jboss.test.kernel.deployment.support.NameAwareBean" name-method="applyName" /> <beanfactory name="MyNameAsFactory" class="org.jboss.test.kernel.deployment.support.NameAwareBean" name-method="applyName" />
You have to specify name of the method that will handle bean name injection - in this case it is applyName method on NameAwareBean class.
It's a method support, not a property support, so setters should be fully written. -
2. Re: Providing bean name aware feature
adrian.brock Jul 13, 2007 5:14 AM (in response to alesj)Why the name of the method? It should be a property name.
Is this a spring thing again? :-)
And do you support something like?@InjectContextName public void setName(Stinrg name) {} or @Inject(fromContext="name") public void setName(String name) {}
-
3. Re: Providing bean name aware feature
alesj Jul 13, 2007 5:21 AM (in response to alesj)"adrian@jboss.org" wrote:
Why the name of the method? It should be a property name.
Is this a spring thing again? :-)
Not that I would know.
I think they have a interface you need to implement to get your name injected - BeanNameAware.
I thought it is more flexible to have a method, not just setter - three more chars to write. ;-)
And I always liked applyName. :-)"adrian@jboss.org" wrote:
And do you support something like?@InjectContextName public void setName(Stinrg name) {} or @Inject(fromContext="name") public void setName(String name) {}
Support it in what way?
This should be a part of our annotation support if that's what you mean. -
4. Re: Providing bean name aware feature
adrian.brock Jul 13, 2007 5:24 AM (in response to alesj)Ales, you really need to discuss things in the forums before you do stuff.
That way you can get input on whether:
* it is a good idea
* your proposed solution should be done a different way
* it is a part of something more generic, e.g. Bill's name<->ObjectName
feature request was really done by implementing aliases
e.g. This is where I described what I proposed to do to the deployers in April
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=106213
here is where I warned that I was going to commit those changes
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=112071
and this is where I described what I had done when I had committed
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=112181
with a number of other discussions in between. :-)
I'm not saying you'll get answers (if you do it will most likely be after you
commit anyway ;-) but at least you gives others the option to comment
and review.
This is most important so you don't have to unpick everything and redo it
like you had to do with the ClassInfo serialization. -
5. Re: Providing bean name aware feature
alesj Jul 13, 2007 5:29 AM (in response to alesj)"adrian@jboss.org" wrote:
I'm not saying you'll get answers (if you do it will most likely be after you
commit anyway ;-) but at least you gives others the option to comment
and review.
I agree.
That's why I posted the initial forum post yesterday around noon.
And created JIRA issue. And linked starting Thomas's post will all new posts.
Since this is not really a huge feature, and _nobody_ commented on either posts, I went ahead and did it.
Silence means approval? :-) -
6. Re: Providing bean name aware feature
alesj Jul 13, 2007 5:33 AM (in response to alesj)"adrian@jboss.org" wrote:
This is most important so you don't have to unpick everything and redo it
like you had to do with the ClassInfo serialization.
:-(
That's was me getting my feet wet with whole container java.lang abstraction and its serialization. An educational feedback.
And I still don't understand why it works by only adding deserialization detail on ReflectClassInfoImpl. But this is not the post to discuss that. ;-) -
7. Re: Providing bean name aware feature
adrian.brock Jul 13, 2007 5:51 AM (in response to alesj)"alesj wrote:
Silence means approval? :-)
Only when you've given people chance to respond. :-)
Anyway, like you say, this is a trivial feature, its the serialization and alias stuff
that I was more referring to. -
8. Re: Providing bean name aware feature
alesj Jul 13, 2007 6:08 AM (in response to alesj)"adrian@jboss.org" wrote:
Anyway, like you say, this is a trivial feature, its the serialization and alias stuff that I was more referring to.
The alias feature was there long ago, even introduced at R&D presentation. ;-)
But it was done wrong.
The idea stayed the same. Only the impl improved.
It improved on your comment of being a full dependency. :-)
The current impl is good - it does exactly what we want.
I think it will be useful, once people have a lot of beans to handle. -
9. Re: Providing bean name aware feature
alesj Jul 16, 2007 9:16 AM (in response to alesj)Since JBMICROCONT-192 was reopened.
"thomas.diesler@jboss.org" wrote:
Does it really have to be that complicated?
How about
@BeanName
void setName(String name)
{
log.info(name + ": " + this)
}
I propose the next addition:<bean name="somename" class="..." name-aware="true">
I still think me should explicitly mark that we want to have name injected.
Since we don't provide the name method, it will invoke by default to setName.
Less complicated. :-)
OK? -
10. Re: Providing bean name aware feature
adrian.brock Jul 16, 2007 9:44 AM (in response to alesj)Just add support for an annotation.
There's no reason to force people to program in xml.
All of the stuff that can be done with XML, should be doable with annotations.
In principle, all that should be in the xml is a list of beans
with the xml just used to override the annotations or when the bean is not annotated. -
11. Re: Providing bean name aware feature
alesj Jul 16, 2007 10:09 AM (in response to alesj)"adrian@jboss.org" wrote:
Just add support for an annotation.
There's no reason to force people to program in xml.
I'll add them both - xml is OOTB.
The annotation will be part of whole annotation handling impl."adrian@jboss.org" wrote:
All of the stuff that can be done with XML, should be doable with annotations.
In principle, all that should be in the xml is a list of beans
with the xml just used to override the annotations or when the bean is not annotated.
I agree.
Did we ever considered similar scanning for 'MC beans' as it exists for EJB3 and Seam? -
12. Re: Providing bean name aware feature
adrian.brock Jul 16, 2007 10:15 AM (in response to alesj)"alesj" wrote:
Did we ever considered similar scanning for 'MC beans' as it exists for EJB3 and Seam?
That can be done when Bill adds his generic scanner to the deployers.
i.e. have a deployer that instead of using a -beans.xml creates mc deployment
components (BeanMetaData) from what the scanner found. -
13. Re: Providing bean name aware feature
alesj Jul 17, 2007 5:30 AM (in response to alesj)"alesj" wrote:
I'll add them both - xml is OOTB.
This part is commited.
Use this until the MC beans annotation handling.
I'll add a comment here and to the JBMICROCONT-192 once that is done. -
14. Re: Providing bean name aware feature
adrian.brock Jul 17, 2007 7:20 AM (in response to alesj)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.
The way you've done is also crippled, see below.
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);
THERE SHOULD BE A CORRESPONDANCE BETWEEN THE
XML AND THE ANNOTATION FEATURES.
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?