9 Replies Latest reply on Aug 4, 2002 9:05 AM by davidjencks

    xmbean versions

    davidjencks

      I need to get xmbeans working now. What's the story with the multiple versions? Only the JBossXMBean10.java has any content. I don't really want to spend the time to rewrite it for the 1.2, but will if necessary. Are modifications to the 1.0 or 1.2 dtd OK?

      The changes I want to make amount to:

      1. remove name from constructor element. I think the name of a constructor is pretty well determined.

      2. Add default values for attributes. Then an mbean can be deployed completely configured just from its descriptor. This is handy if you are generating the descriptor dynamically.

      It might be nice to add default constructor arguments, but I don't need them right now and don't know how you'd specify which constructor to use anyway.

      Thanks
      david jencks

        • 1. Re: xmbean versions

          Juha is in Majorca.

          He said he wanted to convert the XMBean to XML schema,
          but he had stopped working on it for now.
          This is 1.2 I think?

          He has a branch called juhasstuff, but it doesn't look
          to contain any XMBean changes.

          Regards,
          Adrian

          • 2. Re: xmbean versions

            yeah I want to convert to XSD for 1.2. Nothing prevents you adding your own DTD's even to that version if you want to (meaning we don't need to restrict the xml metadata based builder to a single document schema -- and in fact we don't do that even today).

            Default values (the spec 'default' field) should be part of the attribute interceptor, and the 'value' descriptor field initialized with 'default' at ModelMBeanXXXInfo creation.

            Makes sense?

            -- Juha

            • 3. Re: xmbean versions
              davidjencks

              My original question didn't get answered clearly;-) Can I change the 1.0 implementation or should I implement the 1.2 stuff?

              With regards to the default values, I can think of a couple of ways to get them into the target object:

              1. Rearrange the order of interceptor creation so that the attribute interceptor can set the target object values in its constructor

              2. Introduce lifecycle events in the mbean interceptors like those in the ejb interceptors.

              I think (2) is more compatible with the proposed stateless interceptors. Any comments?

              • 4. Re: xmbean versions

                Hi David,

                I can't answer your first question.

                For the second part, defaultValue is only for the
                getAttribute() method where the descriptor has no value
                or getter.

                I think what you are talking about is an initial value
                which could potentially invoke the setter.
                The setAttribute really needs to go through the
                whole stack after it is constructed. You never know
                what else might be in there looking for it,
                e.g. Persistence.

                Regards,
                Adrian

                • 5. Re: xmbean versions

                  No you can't change the 1.0 version, that just forces everyone to change their XML files for no good reason.

                  You can extend the builder implementation for your own additional tags if you want, and introduce it under another schema name.

                  -- Juha

                  • 6. Re: xmbean versions

                    Adrian is correct on the default field value for descriptors, it is set on the metadata on creation and then returned by the interceptor when needed.

                    I don't understand the case where you need default values beyond this behavior.

                    Lifecycle: do you mean method callbacks or actual events (notifications) sent by the interceptor? The shared interceptor is an MBean and implements the MBeanRegistration interface (I can't remember if it actually does, but it should). I don't think adding additional method callbacks beyond this is needed. Notifications from the registration callback methods we should do if they're required.

                    -- Juha

                    • 7. Re: xmbean versions
                      davidjencks

                      --default or initial values.
                      OK, I just looked at the book;-) and think I should be using "default" rather than "value". What I want to do is use the default descriptor for an attribute to set an initial value for the attribute, in the managed object itself (if it has a setter method). I don't know exactly how this fits in the philosophy of jmx, but it would be extremely handy. The reason is that the xml description for the mbean can then include its entire initial state. I plan to modify ServiceConfigurator so it can make an xmbean based on xml being right there in the *-service.xml file, rather than in a separate file referenced by a url. This will enable one-stop mbeanification of any object just by including the appropriate xml in a *-service.xml file. I plan to use this first to make ConnectionFactoryLoaders directly into mbeans, with the attribute values set directly from the xmbean xml (embedded in a dynamically created service-xml format document). This xml will be generated from the ra.xml from the resource adapter and configuration info for the attribute values.

                      It looks like I can get the (default) attribute values sent to the managed object when the interceptor stack instance is being set up, if I reorder the setup a bit. They will not go through the persistence interceptor, since that won't be in the stack yet. For my purposes at the moment that doesn't matter.

                      I don't think this usage conflicts with the description of "default" as the value "returned if the value field has not been set and the attribute as not been associated with an operation that would retrieve the value from the managed resource". If the attribute does have a getter, we could still use the default to set the initial value.

                      I think that when we make the ejb container interceptors into mbean interceptors we will need lifecycle events, just as the ejb interceptors have now. Sending the initial value to the managed object would certainly be more appropriate in an init or start method, but I can wait.

                      --xmbean dtd
                      The xmbean dtd modification I would like to make is completely backward compatible, namely to allow and optional default-value descriptor element with the other descriptors. I think including a constructor name is a bit silly, but don't need to change it. So I would like to change the dtd in this minor way, and later work on getting the 1.2 dtd to be a schema and better structured.

                      Any thoughts?

                      Thanks

                      • 8. Re: xmbean versions


                        > It looks like I can get the (default) attribute
                        > values sent to the managed object when the
                        > interceptor stack instance is being set up, if I
                        > reorder the setup a bit. They will not go through
                        > the persistence interceptor, since that won't be in
                        > the stack yet. For my purposes at the moment that
                        > doesn't matter.

                        Ok I see what you mean. You should really work this on the dev branch that reimplements the interceptors but it is in such a state that it's not really doable and I can't finish it for at least another 4 weeks due to trainings.

                        So go ahead, though be aware it may break and you might need to rework it later (or build good test cases for it so it will be easy to merge with the upcoming changes).

                        > I think that when we make the ejb container
                        > interceptors into mbean interceptors we will need
                        > lifecycle events, just as the ejb interceptors have
                        > now. Sending the initial value to the managed object
                        > would certainly be more appropriate in an init or
                        > start method, but I can wait.

                        yeah that will be in the dev branch.


                        > --xmbean dtd
                        > The xmbean dtd modification I would like to make is
                        > completely backward compatible, namely to allow and
                        > optional default-value descriptor element with the
                        > other descriptors. I think including a constructor
                        > name is a bit silly, but don't need to change it. So
                        > I would like to change the dtd in this minor way, and
                        > later work on getting the 1.2 dtd to be a schema and
                        > better structured.

                        adding new optional tags to the existing schema is ok

                        -- Juha


                        • 9. Re: xmbean versions
                          davidjencks

                          OK, thanks.

                          I've been working with cvs head. The attribute interceptor change is all in an override to insertLast, so merging should be easy, and it will need to be rewritten to use lifecycle events anyway.