-
Notifications
You must be signed in to change notification settings - Fork 579
Home
This wiki contains all design documents and other related material to doing development on Ehcache, not using Ehcache! If you are a developer that wants to get involved in developing new features, fixing bugs, extend the existing or implement a new module based on the Ehcache3 SPIs, this is the place you’ve been looking for. Be welcome!
On paper (or on this screen), it’s pretty straight forward:
-
Join the developer mailing list and say hello! Or join us on irc #ehcache on freenode
-
Check the issues and verify what you want isn’t yet planned or could even already being worked on by someone; We’re also using a board on waffle.io, where work for the current milestone is prioritized;
-
If the task exists already and isn’t assigned: drop us an email on the developer mailing list about it and we’ll make sure we help you getting started and we’ll assign the task/issue to you;
-
If nothing matches in the existing issue list, create a bug as such; or, if we’re talking about a larger task or feature, drop us a message first, and we’ll see how to tackle it;
-
Fork the project to your own repository and get started (you probably want to work on a dedicated branch);
-
Rebase your fork and do a pull request. We’ll use that to code review it (see git usage page as well as the developer guidelines)
-
Be rich and famous!
Now, the doing the work part might be a little more challenging, and we don’t provide any guarantees as to becoming rich… but you’ll be famous to us!
In order to accept any contribution, we will need you to fill out and mail the Individual Contributor Agreement at [email protected].
The code core of Ehcache is split in three core modules:
-
the API module, which contains mainly interfaces. They are the core API to Ehcache (e.g. Cache, CacheManager) that users depend on. It also contains the entry points in terms of SPI (e.g. Service, Store, AuthoritativeTier & CachingTier), that are used by other modules that in turn provide their implementations;
-
the Core module, that is composed of the plumbery that wires the API used by users with the SPI implementations present in packaged modules; and
-
the Implementation module, containing the default implementation of Cache and CacheManager, as well as implementations of core SPIs, such as HeapResource that lets you create on-heap Cache and CachingTier instances.
A CacheManager manages Cache instances, but also Service instances that can be used by either Cache or other Service instances. An example of Service being the org.ehcache.spi.cache.Store.Provider, it’s the Service the CacheManager will use to create the Store instance underlying your Cache.
Service are created by using the Java’s java.util.ServiceLoader service-provider loading facility. It is used to locate all org.ehcache.spi.service.ServiceFactory implementations on the classpath. These are in turn used to create Service instances. Each CacheManager uses its own org.ehcache.spi.ServiceLocator facility to locate Service instances, which it then in turn life cycles.
Service instances are configured by their own respective ServiceConfiguration at Service.start() invocation time. CacheManager and its Service instances can then use these services. In the case of the org.ehcache.spi.cache.Store.Provider instance, it is being used by the CacheManager to create a Store to back a Cache. Being a direct dependency of Ehcache, that Service interface is part of the core SPI. It defines a createStore() method that will be invoked by the CacheManager at Cache creation time. The Store.Provider implementation can introspect not only the Store.Configuration passed, but also all ServiceConfiguration instances associated with the Cache being created in order to decide what Store should be created (note: currently it only creates OnHeapStore, as this is the only topology supported… more to come).
org.ehcache.config.CacheConfiguration, org.ehcache.spi.service.ServiceConfiguration, org.ehcache.config.xml.XmlConfigurationParser
|
Note
|
For more information on how the configuration is parsed, resolved and services are then bootstrapped, please read the Bootstrapping design doc. |