<stuff deleted>
- A common topic for clustering is a common cache and locking. It's
possible with hazelcast. But I was not able use hazelcasts caching
service - lots of class loader issues. I was able to use ehcache (no
locking) and redis for this features. It's a shame that specially
'java caching api' is not possible in OSGi using hazelcast. It's
also not easy with ehcache but I found a workaround.
[Scott] It seems possible to me that remote services could be useful
for creating such a 'java caching api', and ECF has a distribution
provider based upon hazelcast [1]...allowing a nice separation
between 'caching api' (set of interacting osgi services),
implementation (OSGi service impls) and distribution (Hazelcast
and/or other distribution providers).
[Mike] hazelcast implement JSR 107, but it's not possible to use it in
OSGi. I tried it here
https://github.com/mhus/mhus-osgi-dev/blob/master/dev-cache/src/main/java/de/mhus/osgi/dev/cache/CmdDevHazelcast.java but
it's not working because of class loading issues. Using ehcache was
also not easy, I had to copy some classes because classes are not
public - example is in the same repo. But its working with the hack. -
I used the hazelcast coming with cellar.
[Scott] I'm not familiar with JSR 107 so can't comment on it.
But I do know that RS/RSA specifications deal with all
classloading+versioning issues in the spec itself. For impls of these
specs like ECF remote services (with hazelcast distribution provider
[1]), this means that all spec compliant impls have well-specified
classloading and versioning behavior:
i.e.
Remote Services:
https://osgi.org/specification/osgi.cmpn/7.0.0/service.remoteservices.html
Remote Services Admin (where much of the classloading+versioning
behavior is defined):
https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.remoteserviceadmin.html
IMHO having specified behavior for classloading and versioning is one of
the major advantages of remote services/rsa.
Scott
[1] https://github.com/ECF/HazelcastProvider
