On 12/26/13, 1:31 AM, Mark Thomas wrote: > On 24/12/2013 20:37, Phil Steitz wrote: >> The clirr breakage needs to dealt with / explained in the release >> notes. As it stands, the statements about compatibility are not >> correct. > I would argue that there is nothing incorrect about those statements. No > client of Pool should be using any (.*)MXBean class directly since the > sole purpose of such a class is to expose $1 via JMX.
Agreed in principle. The only issue would be if someone decided to implement their own PooledObject implementation, not extending DefaultPooledObject but reusing the management interface. I know this is far-fetched. Technically, since the interface is public, we have broken compatibility, so I would like to either remove the claim of source/binary compat or qualify it in some way. I will fix this. > >> I think the breakage is OK, but would appreciate suggestions on how >> to document in the release notes. > I don't think anything belongs in the release notes about this. The > MXBean naming convention should be familiar to anyone using Pool. If it > is felt that something more needs to be done then I'd suggest adding an > explicit warning to all the MXBean classes that they must not be used > directly by clients or reused by extensions of pool classes > and that they may change in compatible ways between > any release including point releases. Will do. > > Mark > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
