If you register the cache as a service using ServiceFactory, then you will know the bundle that gets the service. You can then use that bundle's class loader. This would seem sufficient, or did I not fully understand the problem? --
BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance hargr...@us.ibm.com office: +1 386 848 1781 mobile: +1 386 848 3788 From: Balázs Zsoldos <balazs.zsol...@everit.biz> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> Date: 2014/11/20 06:07 Subject: [osgi-dev] How to pass Classloader for a Cache component Sent by: osgi-dev-boun...@mail.osgi.org Hi, we have several cache components that can store key-value pairs. The different implementations are: Noop (No operation, the cache always says that it does not have the data, implements ConcurrentMap) ConcurrentHashMap (for development and tests) Infinispan (transactional and distributed ConcurrentMap) When it comes to the point of distribution or hard drive storage, the following question is raised: How to pass the Classloader that can deserialize the key and value classes to the cache? Current solution There is a cache-api that contains a factory interface. The classloader is passed to the createCacheHolder function. The cacheHolder can be closed when we do not want to use the cache anymore and it has a function that gives us back a concurrentMap. The issue with this solution is that we have to keep three member variables in our component and initialize the cache in the activate method. The code looks a bit ugly. Other possible solution The cache component registers an OSGi service based on the Map, ConcurrentMap, CacheSpecificInterface interfaces. The one who want to use the created cache instance can use one of the interfaces that is available. E.g: In case of Infinispan, the cache registers an OSGi service with three interfaces: Map, ConcurrentMap, InfinispanCache. The code on the consumer side looks cool, we need only one reference with type Map, ConcurrentMap or whatever. The API is much more flexible and simple. However, the classloader is not passed in this case. I was thinking a lot and I came out with a weird idea: In case the cache needs a ClassLoader, one of the configuration attributes is a filter expression for a bundle. The cache OSGi service is registered when that bundle is available and it uses the ClassLoader of the bundle. E.g: We have the following cache configuration: classLoaderBundle: (&(bundle.name=xy)(bundle.version>1.0.0)...) Question Do you think this solution is too weird to use? Do you know any other options to solve this issue? I am planning to create a new major release soon and it would be really helpful to find the best API / Configuration for this issue. Regards, Balázs Zsoldos _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
