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

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.