JDK-4997033 : RequiredModelMBean.setAttribute should throw exception if no setMethod and no currencyTimeLimit
  • Type: Bug
  • Component: core-svc
  • Sub-Component: javax.management
  • Affected Version: 6
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2004-02-19
  • Updated: 2017-05-16
  • Resolved: 2005-12-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b63Fixed
Description
The DescriptorSupport only defines "getMyAttribute", so when calling
RequiredModelMBean.setAttribute, a ServiceNotFoundException is expected.
Instead, the setAttribute odes not throw any exception as if it succeeded.

See test modelmbeans_checksetAttribute.

###@###.### 2004-02-19
Comments
EVALUATION The @throws clause of RequiredModelMBean.setAttribute should be changed to say: "A ServiceNotFoundException if either no setMethod field is defined in the descriptor for the attribute and caching is not enabled for the attribute; or the managed resource is null."
12-10-2005
EVALUATION The PDF spec says: "If no setMethod operation is defined then only the value field of the attribute's descriptor will be set. [...] If caching is supported by the model MBean, the new attribute value will be cached in the value field of the descriptor if the currencyTimeLimit field of the descriptor is not -1." This implies that we must not throw an exception if setMethod is not set, unless caching is not supported. There appears to be a contradiction between the PDF spec and the Javadoc spec here. The safest thing to do would appear to be to keep the existing behaviour, i.e. do not throw an exception, at least unless we can determine that the value would not be cached.
12-10-2005
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang
01-09-2004
PUBLIC COMMENTS .
01-09-2004
EVALUATION This is not strictly speaking a spec violation. The spec is a little unclear on the question, but it appears that an implementation would be justified in making the following interpretation. When an attribute's descriptor defines a getMethod but not a setMethod, then calling setAttribute causes the set value to be stored in the descriptor itself. This makes a small amount of sense when the descriptor defines an explicit currencyTimeLimit that is not -1. Then the setAttribute value is the cached value for the number of milliseconds defined by currencyTimeLimit. A getAttribute that arrives within that period will retrieve the cached value. On the other hand, if there is no currencyTimeLimit, or if it is -1, then the cached value is always stale. In this case, if there is a getMethod but no setMethod, the value set by a setAttribute will never be seen by a subsequent getAttribute. It would make sense to throw an exception here. ###@###.### 2004-02-19
19-02-2004