dev.meetings

Meet up notes

Sep 11, 2014 - Hangout on Air

Next public meeting on G+ Hangout on Air at 11:30pm IST / 8pm CET / 2pm EST / 11am PST

Agenda

1. CRUD operations & 107

2. Resilient Cache ?

3. CIaaS: travis-ci

4. Eclipse & Gradle

Use the Q&A app on the Hangout on Air for additional ideas or thoughts…​

Sep 4, 2014 - Hangout on Air

Recording available here on YouTube

Review some proposal on CacheManager and Cache subtyping & their matching Builder

We want CacheBuilder to create instances of types:

1. Unmanaged(ShortLived)Cache

2. UnmanagedLongLivedCache

While CacheManagerBuilder create:

1. (ShortLived)CacheManager

2. LongLivedCacheManager

which manages Cache, i.e. not Unmanaged ones. LongLived exposes the methods to delete 'persistent' data (i.e. that outlives the life of the JVM). A Cache is closed or destroyed through the CacheManager.

Initial API issue break down

Issues are now ordered on waffle.io:

1. 'API' labeled issues for public API require

   1. JavaDoc

2. 'API' labeled issues that are about SPI, require

   1. JavaDoc

   2. Tester of some kind, that

3. 'Enhancement' labeled issues require

   1. JavaDoc, as required

   2. Unit tests

   3. If ported from the 2.x line, best is to have decent coverage on the responsibilities the class will keep, prior to refactoring it; then refactor and add/tweak tests as required

CIaaS

1. drone.io 'failed'

2. codeship.io 'failed'

3. travis-ci.org 'testing…​'

4. cloudbees.com 'todo'

Aug 28, 2014 - Hangout on Air

Recording available here on YouTube

CacheManagerBuilder and CacheBuilder

Let’s try to introduce a type hierarchy for both Cache and CacheManager that the builder would actually build, narrowing the type down à la Quartz 2.0 builders.

PersistentCache cache = newCacheBuilder() // (1)
  .diskPersistent(
    cfg // (3)
  ) // (2)
  .build(); // (4)

1. static method that creates a builder: Builder<Cache>

2. narrows to the builder’s type down to Builder<PersistentCache>

3. cfg actually defines the mode to use for persistence, eg: expect data on disk; expect none; use data if there; wipe data if there; wipe data on Cache.close()

4. actually builds the PersistentCache

Alex to make an actual proposal by next week.

CacheManager-less Cache instances

• Keep these, where the user is actually responsible to provide services

• Only these Cache's type would expose .close()

• CacheManager managed Cache instances would be 'closed' through the CacheManager

• To further lifecycle PersistentCache instance, managed by a CacheManager, the latter could expose some method to retrieve DiskPersisted (interface with minimal lifecycle methods) instances; e.g.

Iterable<Map.Entry<String, DiskPersisted>> it = cacheManager.getManaged(DiskPersisted.class);
it.next().value() // (1)
 .deleteOnDiskFiles(); // (2)

1. DiskPersisted could expose methods around lifecycling the data on disk only. No Cache methods

2. Implies Cache.close(), i.e. clear all 'VM transient' data and delete data from disk.

Aug 21, 2014 - Hangout on Air

Recording available here on YouTube

org.ehcache.Cache vs. org.ehcache.spi.cache.Store

Cache<K, V> backed by a Store<K, Element<V>>

1. Rename Element

2. Try Store<K, Element<V>> for now

Roles

How much can be solved by having the Cache call into some Store.process(K, EntryProcessor<K, V, T>): T equivalent?

1. Cache Roles

   1. Expiry

   2. Public EntryListeners

   3. Cache lifecycle

   4. CacheLoaders

   5. CacheWriters

2. Store Roles

   1. Store by Value vs. Ref.

   2. Eviction & (private) EvictionListeners

Other items

Integrate 107 TCK

Created issue #21

What’s with the sizeof modules ?

1. Hibernate to be integrated within the h2lc module there

2. Groovy, either:

   1. @candrews takes ownership, or

   2. we find someone within TC/SAG to do so (unidentified yet though)