7 Replies Latest reply on Jan 31, 2005 2:27 PM by Dimitris Andreadis

    mbeans read-only attributes

    Eitan Gur Newbie


      I want to add to an mbean, a boolean attribute which is read-only to the user (i.e. - the user only sees true/false), but that the code from the class could change it.

      I tried to use the following:

      <attribute access="read-only" getMethod="getIsEmulatorRunning"

      but I got an exception:

      16:56:05,412 INFO [ServiceConfigurator] Problem configuring service MessagingAS:service=MMSCProperties
      org.jboss.deployment.DeploymentException: Exception setting attribute javax.management.Attribute: name=IsEmulatorRunning
      value=false on mbean MessagingAS:service=MMSCProperties; - nested throwable: (javax.management.AttributeNotFoundExcepti
      on: Attribute 'IsEmulatorRunning' is not writable)

      Is there a way to create such an attribute?


        • 1. Re: mbeans read-only attributes
          Dimitris Andreadis Master

          I presume the xml snippet is from the xmbean descriptor. Declaring something there (e.g. an attribute) doesn't mean a method is created in your class.

          An XMBean defines a JMX wrapper (Model MBean) on top of an ordinary POJO class. In the xmbean descriptor you define the management interface that you want to expose and how this interface maps onto your POJO methods.

          • 2. Re: mbeans read-only attributes
            Eitan Gur Newbie


            Let me elaborate more:
            I want this varibale to be displayed to the user, and to have a default value when I load the AS. If I create the getter and setter, declare about them in the xmbean descriptor, and declare the access to be "read-write" - there's no problem, only the user can change this variable (and this I don't want).

            If I decalre this variable to be "read-only" - I get an exception when I try to edit it from the code (and I need to).

            I can workaround it by decalring it as read-write, and degenerate it by not adding code to the setter (so the user will have no affect on this variable) - but this is not good-practice programming.

            Is there any way to expose an attribute to the user, but allow it to be changed from within the code?

            • 3. Re: mbeans read-only attributes
              Dimitris Andreadis Master

              I guess you need to expose this as read-only on the MBean and alter the value of this inside your MBean code.

              I don't understand the exception you get. Isn't the MBean itself holding the value of this variable? Show the MBean code.

              The thing is, as soon as you declare something read-write it should be possible to write it. If you aim is to allow overriding through the -service.xml descriptor but dissallow editing through the console, this will not work, because both use the same way to access the variable.

              • 4. Re: mbeans read-only attributes
                Eitan Gur Newbie

                This answers my question.
                I did want to override through the -service.xml and not through the console.

                Too bad it can't be done, but thanks anyway :-)

                • 5. Re: mbeans read-only attributes
                  mazz Master

                  I had the same question, sort of. I think I want the same thing you do. I want a "read-only" attribute (I don't want any user code modifying it - either through a JMX console, a remote JMX API call, etc.). However, i want the deployer to be able to set it in via its [mbean>[attribute> setting in my jboss-service.xml.

                  The only way I can this as being possible is to have my MBean define a read-write attribute, but have it act as a "read-but-write-only-once". My setter will have to maintain an internal member variable "wasSet" whose default is false. When the setter is called, if "wasSet" is false, it sets the attribute but then sets wasSet to true, disabling any future calls to the setter.

                  This would allow, at deployment time, the [mbean>[attribute> setting to work, but thereafter, the MBean attribute is considered read-only.

                  The use-case for this feature is a security setting that I have. I have a setting that, for security purposes, should not be allowed to be set by anyone during the time the MBean is registered in the MBeanServer. But I want the deployer of the MBean to have the option to configure this security feature (enable it or disable it). Hence why I need the capability to set the attribute for the first time. This way, the deploy can set the [mbean>[attribute> to whatever they want and not be afraid that some other code will come later and revert the setting.

                  Am I missing some JBossAS feature or is this the only way to do it?

                  • 6. Re: mbeans read-only attributes
                    Scott Stark Master

                    This can be achieved by running with a security manager and assigning the core service layer jars the approriate permission while not allowing write access from the jmx-console.war or jmx-invoker-service.xml. You can partition out the untrusted access paths into a seperate deploy directory that is not assigned any write permissions.

                    More generically you would have configure the mbean as an xmbean with a security interceptor that imposed the can access semantics you are looking for. This would require a run-as security interceptor on the SARDeployer in order for it to be seen as a trusted component.

                    • 7. Re: mbeans read-only attributes
                      Dimitris Andreadis Master

                      If you use XMBeans you have the option of declaring attributes, that don't correspond to actual POJO attributes (i.e. no getter/setter) and for which a default value may be specified, e.g

                       <attribute access="read-only">
                       <default value="Initial value"/>

                      A problem with this is your POJO code will have to go through the MBeanServer to read the atttribute, if needed.

                      But as Scott pointed out, this seems to be mostly an access control issue.