You are right I guess. I think I will go with the most simple ServiceFactory and a new instance for each bundle who requests the cache. Programmers must know than that two bundles should not use the same cache directly.
Thanks for the discussion! *Zsoldos Balázs* Rendszertervező | Software architect +36 70 594 9234 | [email protected] *EverIT Kft.* 1137 Budapest, Katona József utca 17. III. em. 2. http://www.everit.biz I [email protected] Ezen üzenet és annak bármely csatolt anyaga bizalmas, jogi védelem alatt áll, a nyilvános közléstől védett. Az üzenetet kizárólag a címzett, illetve az általa meghatalmazottak használhatják fel. Ha Ön nem az üzenet címzettje, úgy kérjük, hogy telefonon, vagy e-mail-ben értesítse erről az üzenet küldőjét és törölje az üzenetet, valamint annak összes csatolt mellékletét a rendszeréből. Ha Ön nem az üzenet címzettje, abban az esetben tilos az üzenetet vagy annak bármely csatolt mellékletét lemásolnia, elmentenie, az üzenet tartalmát bárkivel közölnie vagy azzal visszaélnie. This message and any attachment are confidential and are legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorised to receive it. If you are not the intended recipient, please telephone or email the sender and delete this message and any attachment from your system. Please note that any dissemination, distribution, copying or use of or reliance upon the information contained in and transmitted with this e-mail by or to anyone other than the recipient designated above by the sender is unauthorised and strictly prohibited. On Thu, Nov 20, 2014 at 5:33 PM, BJ Hargrave <[email protected]> wrote: > Yes, but that is a specific limited case. You know that A and B import > from DTO and limit their cache contributions to that type. It is not a > general case. > -- > > *BJ Hargrave* > Senior Technical Staff Member, IBM > OSGi Fellow and CTO of the *OSGi Alliance* <http://www.osgi.org/> > *[email protected]* <[email protected]> > > office: +1 386 848 1781 > mobile: +1 386 848 3788 > > > > > > From: Balázs Zsoldos <[email protected]> > To: OSGi Developer Mail List <[email protected]> > Date: 2014/11/20 09:47 > Subject: Re: [osgi-dev] How to pass Classloader for a Cache > component > Sent by: [email protected] > ------------------------------ > > > > "I don't see how you can use it in an environment with many classloaders" > > Imagine there are four Bundles: A, B, DTO. > Bundle A and Bundle B wires to the packages of DTO, so their both of their > classloader see the DTO classes -> Theoretically Bundle A and Bundle B > could use the same cache instance. Question is if this should be supported > at all. If not, than either bundle A or bundle B should use the cache but > not both at the same time. > > *Zsoldos Balázs* > Rendszertervező | Software architect > > > > +36 70 594 9234 | *[email protected]* <[email protected]> > > *EverIT Kft.* > 1137 Budapest, Katona József utca 17. III. em. 2. > *http://www.everit.biz* <http://www.everit.biz/> I *[email protected]* > <[email protected]> > > Ezen üzenet és annak bármely csatolt anyaga bizalmas, jogi védelem alatt > áll, a nyilvános közléstől védett. Az üzenetet kizárólag a címzett, illetve > az általa meghatalmazottak használhatják fel. Ha Ön nem az üzenet > címzettje, úgy kérjük, hogy telefonon, vagy e-mail-ben értesítse erről az > üzenet küldőjét és törölje az üzenetet, valamint annak összes csatolt > mellékletét a rendszeréből. Ha Ön nem az üzenet címzettje, abban az esetben > tilos az üzenetet vagy annak bármely csatolt mellékletét lemásolnia, > elmentenie, az üzenet tartalmát bárkivel közölnie vagy azzal visszaélnie. > > > This message and any attachment are confidential and are legally > privileged. It is intended solely for the use of the individual or entity > to whom it is addressed and others authorised to receive it. If you are not > the intended recipient, please telephone or email the sender and delete > this message and any attachment from your system. Please note that any > dissemination, distribution, copying or use of or reliance upon the > information contained in and transmitted with this e-mail by or to anyone > other than the recipient designated above by the sender is unauthorised and > strictly prohibited. > > > On Thu, Nov 20, 2014 at 3:12 PM, BJ Hargrave <*[email protected]* > <[email protected]>> wrote: > Then I did misunderstand your question. If the cache can only be > associated with a single class loader, then I don't see how you can use it > in an environment with many classloaders. So you will need a different > cache for each user with a different classloader. > -- > > *BJ Hargrave* > Senior Technical Staff Member, IBM > OSGi Fellow and CTO of the *OSGi Alliance* <http://www.osgi.org/> > *[email protected]* <[email protected]> > > office: *+1 386 848 1781* <%2B1%20386%20848%201781> > mobile: *+1 386 848 3788* <%2B1%20386%20848%203788> > > > > > > From: Balázs Zsoldos <*[email protected]* > <[email protected]>> > To: OSGi Developer Mail List <*[email protected]* > <[email protected]>> > Date: 2014/11/20 08:52 > Subject: Re: [osgi-dev] How to pass Classloader for a Cache > component > Sent by: *[email protected]* > <[email protected]> > ------------------------------ > > > > I am not sure I understand it :). I will try to play with the logic > though. > > Imagine there are three bundles: A, B, C. Bundle C contains the cache > component and registers the Cache instances as OSGi services based on > configuration. Bundle A and Bundle B requests that OSGi service. > > When a bundle interacts with the central cache, I cannot define the > ClassLoader. I can only define it only during the initialization of the > cache. If the classloader is not defined during the initialization and the > cache is distributed, it might happen that the cache receives entries from > the network and it cannot deserialize them as the bundle that contains the > classes is not started yet or it has not requested the Cache OSGi service, > the cache will not see the class types. > > It would be also a problem if: > > - The key of the cache is a String, while the value type is a specific > DTO > - The bundle that contains the DTO type is uninstalled / updated. > > The cache would hold the values based on the Strings and others could > request it although they would wire to the updated DTO bundle. > > > On Thu, Nov 20, 2014 at 2:38 PM, BJ Hargrave <*[email protected]* > <[email protected]>> wrote: > You can return a unique facade to a central cache to each bundle. You can > use the facade to collect the bundle's class loader when a key is added to > the cache. You use the facade just to know which bundle is interacting with > the central cache. > -- > > *BJ Hargrave* > Senior Technical Staff Member, IBM > OSGi Fellow and CTO of the *OSGi Alliance* <http://www.osgi.org/> > *[email protected]* <[email protected]> > > office: *+1 386 848 1781* <%2B1%20386%20848%201781> > mobile: *+1 386 848 3788* <%2B1%20386%20848%203788> > > > > > > From: Balázs Zsoldos <*[email protected]* > <[email protected]>> > To: OSGi Developer Mail List <*[email protected]* > <[email protected]>> > Date: 2014/11/20 08:07 > Subject: Re: [osgi-dev] How to pass Classloader for a Cache > component > Sent by: *[email protected]* > <[email protected]> > > ------------------------------ > > > > I have been thinking of this solution but I had the following issue with > it: If multiple bundles request the OSGi service, they might think that > they see the same cache while they always get a new instance. Also, if I > configure a cache with 10.000 maxEntries, this cache will be populated as > many times as the service is requested. > > The issue is that many of the cache implementations support custom > ClassLoaders to be passed only during the initialization of the cache (and > not when the get(key) function is called). > > Do you think cache / bundle is a better choice than defining the > classloader bundle in configuration? I could not decide for sure. I feel > hat classloader-bundle-configuration is less KISS but more deterministic. > > > On Thu, Nov 20, 2014 at 1:56 PM, BJ Hargrave <*[email protected]* > <[email protected]>> wrote: > 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* <http://www.osgi.org/> > *[email protected]* <[email protected]> > > office: *+1 386 848 1781* <%2B1%20386%20848%201781> > mobile: *+1 386 848 3788* <%2B1%20386%20848%203788> > > > > > > From: Balázs Zsoldos <*[email protected]* > <[email protected]>> > To: OSGi Developer Mail List <*[email protected]* > <[email protected]>> > Date: 2014/11/20 06:07 > Subject: [osgi-dev] How to pass Classloader for a Cache component > Sent by: *[email protected]* > <[email protected]> > > ------------------------------ > > > > > Hi, > > we have several cache components that can store key-value pairs. The > different implementations are: > > - *Noop* <https://github.com/everit-org/cache-noop> (No operation, the > cache always says that it does not have the data, implements ConcurrentMap) > - ConcurrentHashMap (for development and tests) > - *Infinispan * > <https://github.com/everit-org/cache-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* <https://github.com/everit-org/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* <http://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 > *[email protected]* <[email protected]> > *https://mail.osgi.org/mailman/listinfo/osgi-dev* > <https://mail.osgi.org/mailman/listinfo/osgi-dev> > > > _______________________________________________ > OSGi Developer Mail List > *[email protected]* <[email protected]> > *https://mail.osgi.org/mailman/listinfo/osgi-dev* > <https://mail.osgi.org/mailman/listinfo/osgi-dev> > _______________________________________________ > OSGi Developer Mail List > *[email protected]* <[email protected]> > *https://mail.osgi.org/mailman/listinfo/osgi-dev* > <https://mail.osgi.org/mailman/listinfo/osgi-dev> > > > _______________________________________________ > OSGi Developer Mail List > *[email protected]* <[email protected]> > *https://mail.osgi.org/mailman/listinfo/osgi-dev* > <https://mail.osgi.org/mailman/listinfo/osgi-dev> > _______________________________________________ > OSGi Developer Mail List > *[email protected]* <[email protected]> > *https://mail.osgi.org/mailman/listinfo/osgi-dev* > <https://mail.osgi.org/mailman/listinfo/osgi-dev> > > > _______________________________________________ > OSGi Developer Mail List > *[email protected]* <[email protected]> > *https://mail.osgi.org/mailman/listinfo/osgi-dev* > <https://mail.osgi.org/mailman/listinfo/osgi-dev> > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev >
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
