2 Replies Latest reply on Jan 13, 2006 11:18 AM by Peter Johnson

    Making write-only attributes read-writable?

    chi lin Newbie

      I'm working on the JBoss Admin Console project in the area of JBossMQ and Destination management and we're having problem handling the write-only attributes.

      When the user press the submit button to update the attributes, the Admin Console invokes DeploymentService.updateMBean() for each MBean, passing all the attributes of that MBean (whether the attribute has been modified or not). This works fine except for the write-only attribute, since we couldn't get its value from the MBean, if the user doesn't explicitly set/change it, we don't know what to set it to!!!

      So far we've encountered three write-only attributes: the 'HasSecurityManager' attribute in the StateManager, and the 'SecurityManager' and 'SecurityConf' attributes in the Destination Queue/Topic.

      In order for the Admin Console to properly manage the attributes, we propose to make the write-only attributes read-writable. Does any one have any comment/concern/objection to it?

        • 1. Re: Making write-only attributes read-writable?
          Scott Stark Master

          Yes, if its marked as not readable, it should not be readable. Such attributes should not be submitted for update.

          • 2. Re: Making write-only attributes read-writable?
            Peter Johnson Master

            One of the requirements for the Admin Console is that any changes made through the Admin Console be persisted. This way, an administrator can make a change to something, reboot the app server, and be confident that the changed setting is still in effect when the app server comes back up. Because of this requirement, the Admin Console cannot simply make setter calls on the MBeans in question because there is no persistence mechanism built into MBeans. As an example, any MBean changes made via the jmx-console are lost after a reboot.

            The Admin Console uses the Deployment Service (as released in ./docs/examples/varia/deployment-service) as the persistence mechanism. The Deployment Service uses a template scheme, whereby a caller, such as the Admin Console, provides all of the attribute values for one or more MBeans, and then the Deployment Service creates and deploys the configuration XML file for those MBeans.

            As an example, consider that the administrator wants to create a new JMS destination, such as a topic. Using the Admin Console, the administrator would supply all of the attribute values for the new topic, and then save that topic. The Admin Console hands the attribute values off to the Deployment Service, which creates the configuration XML file and deploys it. Some time later, the administrator determines that the DurableMessageCount attribute needs to be changed. So she uses the Admin Console to make that change. The Admin Console obtains the current settings for that topic?s attributes, displays then to the administrator, and she then changes the DurableMessageCount attribute and clicks on save. But now the Admin Console has a problem. Two of the attributes on a topic are write only: SecurityManager and SecurityConf. If the Admin Console does not supply values for those two attributes, then the resulting configuration XML file created by the Deployment Service will not contain those attributes. If the administrator, when creating the topic, had set those attribute values, then those attribute values will be lost as a result of changing another attribute value. Not what the administrator had expected. Likewise, the Admin Console cannot assume a default value for those attributes because the administrator could have changed those attributes to a value other than the default.

            There are several solutions to this problem. One is to make MBeans persistable. Another is to enhance the Deployment Service such that it merges the attribute values given to it with the existing attribute values for the MBean(s) being updated. I think that both of those changes are non-trivial. A third option is to make writeable attributes also readable. That would seem the easier of the options. (A fourth option is to have the Admin Console read the configuration file to extract the current setting of the write-only attribute, but that is not practical since that restricts the Admin Console to working only with the app server on which it is deployed, and it is not elegant because the Admin Console would be bypassing various APIs to get information.)

            I am open to other options.