Get the {@link Properties} that were used to create this {@link CacheManager}.
If properties are completely implementation specific, then no behavior should be asserted by the TCK on CacheManagers created with properties. This means that it is not possible to assert the pass-through behavior suggested by CacheManager.getProperties().
Amend javadoc of CachingProvider.getCacheManager(URI uri, ClassLoader classLoader, Properties properties) as follows:
Properties names follow the same scheme as package names.
The prefixes {@code java} and {@code javax} are reserved.
Properties are passed through and can be retrieved via {@link CacheManager#getProperties()}.
Properties within the package scope of a caching implementation may be used for
additional configuration.
Javadoc of
CachingProvider getCacheManager(URI uri, ClassLoader classLoader, Properties properties)states:Javadoc of
CacheManager.getProperties()states:If properties are completely implementation specific, then no behavior should be asserted by the TCK on
CacheManagers created with properties. This means that it is not possible to assert the pass-through behavior suggested byCacheManager.getProperties().Proposed solution (as per https://github.com/jsr107/jsr107tck/issues/102#issuecomment-334931087) is to scope properties and assert the pass-through behavior in the TCK.
CachingProvider.getCacheManager(URI uri, ClassLoader classLoader, Properties properties)as follows:getCacheManager_nonNullPropertiestest to assert the pass-through behavior with test properties in reserved scope.