-
Notifications
You must be signed in to change notification settings - Fork 25
Support for platform MBeanServer #83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
The needed change is trivial. The method public static MBeanServer resolveMBeanServer() {
if (System.getProperty("javax.management.builder.initial") == null) {
throw new RuntimeException("You must set the 'javax.management.builder" +
".initial' property so that the TCK can find your MBeanServer'");
}
if (System.getProperty("org.jsr107.tck.management.agentId") == null) {
throw new RuntimeException("You must set the 'org.jsr107.tck.management.agentId'" +
"system property so that the TCK can find your MBeanServer agent by " +
"its ID.'");
}
String agentId = System.getProperty("org.jsr107.tck.management.agentId");
ArrayList<MBeanServer> mBeanServers = MBeanServerFactory.findMBeanServer(agentId);
if (mBeanServers.size() < 1) {
throw new CacheException("The specification requires registration of " +
"MBeans in an implementation specific MBeanServer. A search for an " +
"MBeanServer did not find any.");
}
return mBeanServers.get(0);
} It can be changed to: public static MBeanServer resolveMBeanServer() {
String agentId = System.getProperty("org.jsr107.tck.management.agentId");
ArrayList<MBeanServer> mBeanServers = MBeanServerFactory.findMBeanServer(agentId);
if (mBeanServers.size() < 1) {
throw new CacheException("The specification requires registration of " +
"MBeans in an implementation specific MBeanServer. A search for an " +
"MBeanServer did not find any.");
}
return mBeanServers.get(0);
} If I can check this thoroughly this and make a pull request. Any comments? |
@cruftex Ehcache 3 also takes the approach of registering MBeans with the platform I agree it would be nice if the TCK was testing the real runtime behaviour and not a fabricated one. |
Preparing an PR. Cache implementations need to change behavior and register with the platform MBean server. The TCK guide needs an update. The properties Cache implementations that want to make the transition before TCK 1.1 is released, can use some glue code that makes the platform MBean server available to the TCK under a specified ID. See, for example: https://github.com/cache2k/cache2k/blob/master/cache2k-jcache/src/main/java/org/cache2k/jcache/provider/tckGlue/TckMBeanServerBuilder.java |
PRs for RI and TCK are ready. |
Fixed by #119 & jsr107/RI#56 |
The two properties were not removed from the surefire plugin. |
The spec says on page 129:
However, the spec indirectly enforces that a separate MBeanServer is registered, because it wants to retrieve it by the id stored in the property
org.jsr107.tck.management.agentId
.The Oracle Coherence does register its beans always with the platform MBeanServer. They sneaked around the TCK shortcoming by providing a server wrapper which constantly produces the id
Coherence WrapperMBeanServer
for the platform MBeanServer.All other existing implementations did copy the approach of the RI and provided a custom implementation of MBeanServerBuilder to produce a separate MBeanServer which the TCK can pick up.
The TCK should support the simple approach, registering the bean with the platform MBeanServer, straight forward. All implementations except Oracle produced extra code to register a separate MBeanServer to comply with the TCK, however, the spec does not require that.
At other places the Spec clearly says, that implementation must register with the platform mbean server. See JavaDoc of
CacheManager.enableManagement()
.The Spec should be clear whether this is mandatory or not at all places.
The text was updated successfully, but these errors were encountered: