This content has been marked as final.
Show 6 replies
-
1. Re: anonymous beans
starksm64 Apr 18, 2007 9:45 PM (in response to bill.burke)I would make the name anon#n, but yes, that seems about all that is required to add this.
-
2. Re: anonymous beans
alesj Apr 19, 2007 2:36 AM (in response to bill.burke)This one is an oldie:
- http://jira.jboss.com/jira/browse/JBMICROCONT-28
- http://www.jboss.org/index.html?module=bb&op=viewtopic&t=101320&start=20
- http://www.jboss.org/index.html?module=bb&op=viewtopic&t=89581
- http://www.jboss.org/index.html?module=bb&op=viewtopic&t=105759
I can 'change' its priority if it really annoys you.
But I would like to leave it after J1 - trying to push our OSGi till then as much as I can. -
3. Re: anonymous beans
bill.burke Apr 19, 2007 10:06 AM (in response to bill.burke)just tell me how to do it and i can do it. is my approach valid, etc.
-
4. Re: anonymous beans
adrian.brock Apr 20, 2007 8:06 AM (in response to bill.burke)"bill.burke@jboss.com" wrote:
just tell me how to do it and i can do it. is my approach valid, etc.
Repeating at least three other discussions... :-(
The real solution is to always use an internal id (a GUID) then you don't need a name
unless you are doing injections.
The controller would use the GUID internally and map external calls
name -> GUID and vice versa.
For the Bean as a value<bean > <attribute name="blah><bean/></attribute> </bean>
the GUID needs to be linked since this is really an injection.<bean> <attribute name="blah><inject bean="Anon#1"/></attribute> <bean> <bean name="Anon#1"/>
-
5. Re: anonymous beans
bill.burke Apr 20, 2007 8:13 AM (in response to bill.burke)don't see the reason for the extra complication
-
6. Re: anonymous beans
adrian.brock Apr 20, 2007 8:29 AM (in response to bill.burke)"bill.burke@jboss.com" wrote:
don't see the reason for the extra complication
Read the other threads! Why do we need to repeat everything already discussed
every time you post?
e.g. One advantage is being able to summarize duplicate names of beans in
different deployments in the IncompleteDeploymentException.
Currently you get an exception but it is not included in the summary because
you can't install two beans with the same name. So all knowledge of the
duplicate context is lost.
Another is that is not more complicated, it is less.
The MC deals with a single id (guaranteed unique) rather leaving it to the different
contexts (and the user) to control.
Finally, it is required for when we eventually get around to transactional deployment,
where you don't douninstall bean1 // Bean is unusable for a "long time" install bean1
you doprepare to install GUID2 (name=Bean1) prepare to uninstall GUID1 (name=Bean1) vote handoff state GUID1 -> GUID2 (e.g. socket/jndi front ends and other injections) uninstall GUID1 // Almost nothing since the handoff already changed which is the active one install GUID2
i..e. There are two beans being managed with the same name, but only one is the
"active" one.