ehcache / ehcache3 Goto Github PK

See #52, but there are quite some places where this still needs to be wired

i.e. everything around config parsing from XML, creating Builders and building actual Cache and CacheManager instances. But also wiring the RuntimeConfiguration of some kind, that let someone read the configuration currently in use by a given Cache or CacheManager, also enabling mutating the bits that are mutable

Requires having Expiry implemented in Ehcache but NOT the bridge to 107... Only an implementation that's bridgeable.

Requires LocalTransactionManager API

Travis CI is lacking at least the test result publishing feature.
Given this, we are considering http://www.cloudbees.com/resources/foss

This issue is to track required changes to project setup in case it is needed.

I introduced it as it was required in the API module.
It's all in core now... Do we want to keep this indirection at all ?

i.e. Merge Cache & AtomicCache and have them be "close" to javax.cache.Cache (certainly keep Exceptions)

Currently Store.put takes (K, ValueHolder<V>) - it's probably better to never ever accept ValueHolder instances. The metadata shouldn't be provided by anything other than the Store anyway...

See issue #45

Consists of adding the putIfAbsent, replace et al on the Cache interface.
This is an API issue, it doesn't require implementing any further than to please javac. (i.e. throw UnsupportedOperationException is just fine)

That's both the Configuration as well as the other APIs (if any)

Using the CacheLoader API and hooking into the life cycle listeners

See issue #45
This includes handling CacheAccessException in a resilient manner (see #52)

Which basically means:

• Implement in Ehcache
• Define matching SPI on the Store interface
• Implement in the on-heap store impl. OnHeapStore (our CHMv8 back port?)

We probably need some "framework" for that. We thought about having a dedicated qualified artifact for the module contain the SPIs, which would contain a Tester to each interface.

Where the OnHeapStore is the first thing to be tested. Given what it does now, it probably doesn't require any actual unit testing on its own. But consider it part of this task to make sure that's actually true.

Ideally this would support all existing algorithms including Clock?
This is an API issue, it doesn't require implementing any further than to please javac. (i.e. throw UnsupportedOperationException is just fine)

Consists of adding the API to put/get/remove from the Cache.
This is an API issue, it doesn't require implementing any further than to please javac. (i.e. throw UnsupportedOperationException is just fine).

Currently these are pretty simple, e.g.: Cache.get(K): V but should we keep them as such? add checked exceptions? ... more?

both write through, as well as write behind

We want JavaDoc on all API types... So this task also encompasses adding Javadoc where some is missing!

Add :

• Checkstyle (eol & no tab rules only)
• findbugs (reports, no threshold to break the build)
• test coverage (reports, no threshold to break the build)

Add the putAll, getAll et al methods to the Cache interface.
This is an API issue, it doesn't require implementing any further than to please javac. (i.e. throw UnsupportedOperationException is just fine)

Just enough so we can support the 107 MBean stuff

As part of the first milestone and once CI choice/setup has been finalised, we need to add the possibility of pushing SNAPSHOT and later releases to Sonatype/Maven Central.

We don't really need Configs to configure stuff... We can build CacheManager and Cache instances right away. We'll need Configurations for Runtime stuff though, with getters to read-only attributes and getters as well as setters for read-write ones.

Given we have 2k minutes on cloud bees, the current tests consume quite some CPU (and wall clock time)... Probably want to make these quicker/lighter. May mean move the "full" ones to some other test phase (we only have unit tests for now though)

That delegates to the "real" Ehcache 3 API (that's in the 107 spirit still).
Avoids potential issues w/ packaging the 107 api as part of Ehcache if 107 becomes part of the EE spec.

Figure out and implement the default ResilienceStrategy

Need to :

• find where to best source it from... JDK8? Existing port? and have that base import as a dedicated commit in the repo! Any subsequent change needs to be in other commits.
• remove the unnecessary (e.g. stream API).
• Unsafe usage may remain for now... will address that separately again, if ever.
• Finally replace the DeprecatedOnHeapStore

See #52 for work already done in Ehcache, but CacheWriter and CacheWriterFactory is still to be wired into it all (à la CacheLoader see #75)

How does one configure Cache upfront to be managed by a CacheManager ? This has to match 107 enough to not confuse everyone...