I actually think it is quite good to habe a DTO bundlenused by A B and The Cache. Especially if it is a Shared Cache. Having the Pojos versioned independently and server from ist own bundle is an Option for a Heavy weight persistence and Cache thing.
Gruß Bernd > Am 20.11.2014 um 17:43 schrieb Balázs Zsoldos <[email protected]>: > > 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 >> [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] >> >> 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 3:12 PM, BJ Hargrave <[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 >> [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 08:52 >> Subject: Re: [osgi-dev] How to pass Classloader for a Cache component >> Sent by: [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]> 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 >> [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 08:07 >> Subject: Re: [osgi-dev] How to pass Classloader for a Cache component >> Sent by: [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]> 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 >> [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 06:07 >> Subject: [osgi-dev] How to pass Classloader for a Cache component >> Sent by: [email protected] >> >> >> >> >> >> 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 >> [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 >> >> >> _______________________________________________ >> 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 >> _______________________________________________ >> 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
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
