6 Replies Latest reply on Apr 20, 2007 8:29 AM by adrian.brock

    anonymous beans

    bill.burke
    bill.burke Apr 18, 2007 6:43 PM

      I finding that I don't always need to specify a bean name attribute. In fact, in these scenarios, its quite annoying. It would be cool if the name attribute was optional.

      How hard would it be to add this? Just generate a random name in the default initialization of BeanMetaData and let the container override it if somebody has specified it? And change the schema too?

      thanks

      • 3770 Views
      • Tags:
        • 1. Re: anonymous beans
          starksm64
          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.

            • Actions
          • 2. Re: anonymous beans
            alesj
            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.

              • Actions
            • 3. Re: anonymous beans
              bill.burke
              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.

                • Actions
              • 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"/>


                  • Actions
                • 5. Re: anonymous beans
                  bill.burke
                  bill.burke Apr 20, 2007 8:13 AM (in response to bill.burke)

                  don't see the reason for the extra complication

                    • Actions
                  • 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 do 
                    uninstall bean1
// Bean is unusable for a "long time"
install bean1


                    you do 

                    prepare 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.

                      • Actions