I am not following. I always want CompB to use a fixed version of CompA regardless of the calling API code.
Is this possible? The direct dependency between CompC and CompA (newer version) is a real situation. Please advise. On Thu, Apr 15, 2010 at 4:46 PM, Richard S. Hall <[email protected]>wrote: > On 4/15/10 9:17, Yair Ogen wrote: > >> Thank you very much and yes this is exactly what I wanted to achieve, I >> know >> regular Java does not allow this, however I thought that OSGi special >> ClassLoader model resolves this issue. >> >> I think this is a real life scenario. for example, assume based on >> my previously described Component Graph that the logic behind the scenes >> is >> that CompB was tested with CompA a long time ago. Comp C uses Comp B but >> also uses new version of CompA since it is a newer component. >> >> It is a real requirement for me (I think this is common to all?) that the >> system engineers do not allow me to have B use the new CompA since this >> combination was never tested. They do not want to have full regressions >> tests either. >> >> So, the route CompC --> CompA should use newer version, but the route >> CompC >> --> CompB --> CompA should use the older version. >> >> So, I need to tell them this is not possible? >> >> > > To be clear, if CompC somehow gets objects from CompB that are instances > from classes from CompA, then it will not work. This is because CompC is > expecting the CompA instances to be 1.0.1, but the instances that CompB > returns are 1.0.0. A given class can only see one version of a type at a > time. > > However, if CompB only uses class from CompA internally and never exposes > them to CompC, then it is possible for both CompB and CompC to use different > versions of that type. > > There is a slight variation where CompB might expose CompA types, but CompC > doesn't actually ever use those types from CompB. In this case, you could > technically cheat and modify your CompB bundle metadata so it doesn't report > the "uses" constraints. But I wouldn't recommend this since it would be > really fragile and would likely blow up in other situations where you reuse > CompB. > > -> richard > > > Regards, >> >> Yair >> >> On Thu, Apr 15, 2010 at 4:03 PM, Richard S. Hall<[email protected] >> >wrote: >> >> >> >>> On 4/15/10 2:17, Yair Ogen wrote: >>> >>> >>> >>>> Right. this was another problem. >>>> >>>> now A both verrsion and B work ok. >>>> >>>> Problem in C: >>>> >>>> org.osgi.framework.BundleException: The bundle could not be resolved. >>>> Reason: Package uses conflict: Import-Package: com.something.b.main; >>>> version="0.0.0" >>>> >>>> Is this due to conflict between the imported dependency from to Be and >>>> the >>>> one imported directly from C? >>>> >>>> Is this situation supposed to be supported? I mean C using one version >>>> of >>>> and using B that uses another version of A? How can I accomplish this >>>> goal? >>>> >>>> >>>> >>>> >>> As I mentioned in my original response, it is supported assuming B >>> doesn't >>> expose A to C...it sounds like com.something.b.main exposes A v1 to C who >>> is >>> only allowed to see A v1.0.1. >>> >>> For example, assume B has a class like: >>> >>> public interface com.something.b.main.Foo { >>> com.something.classes.Bar getBar(); >>> } >>> >>> Assuming com.something.classes.Bar comes from bundle A, then bundle C >>> will >>> not be allowed to use com.something.b.main, because it would cause it to >>> see >>> a different version of the package than what it is allowed to see. If >>> this >>> is specifically what you are trying to achieve, then you can't do this >>> with >>> Java at all. A given class can only see one version of another class at a >>> time...otherwise you get class cast exceptions. >>> >>> -> richard >>> >>> >>> Any help appreciated. >>> >>> >>>> Thanks, >>>> >>>> Yair >>>> >>>> On Wed, Apr 14, 2010 at 10:38 PM, Richard S. Hall<[email protected] >>>> >>>> >>>>> wrote: >>>>> >>>>> >>>> >>>> >>>> >>>> >>>>> On 4/14/10 14:59, Yair Ogen wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Added the suggested Export-Package as well as Private-Package for the >>>>>> activator. >>>>>> >>>>>> install fails now on: >>>>>> >>>>>> org.codehaus.classworlds.NoSuchRealmException: plexus.core >>>>>> at >>>>>> org.codehaus.classworlds.ClassWorld.getRealm(ClassWorld.java:128) >>>>>> at >>>>>> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:434) >>>>>> at org.codehaus.classworlds.Launcher.main(Launcher.java:375) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> This sounds specific to the scenario you are trying to implement. Not >>>>> sure, >>>>> I have no idea what Class Worlds is... >>>>> >>>>> -> richard >>>>> >>>>> >>>>> Yair >>>>> >>>>> >>>>> >>>>> >>>>>> On Wed, Apr 14, 2010 at 8:42 PM, Richard S. Hall<[email protected] >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> To include packages without exporting them, you should use >>>>>>> Private-Package. >>>>>>> For example, you shouldn't export your activator package. >>>>>>> >>>>>>> Is sounds like you want something like this: >>>>>>> >>>>>>> CompA v1 >>>>>>> Export-Package: com.something.classes; version=1.0.0 >>>>>>> >>>>>>> CompA v1.0.1 >>>>>>> Export-Package: com.something.classes; version=1.0.1 >>>>>>> >>>>>>> CompB >>>>>>> Import-Package: com.something.classes; version="[1.0.0, 1.0.0]" >>>>>>> >>>>>>> Export-Package: com.something.b.main >>>>>>> Private-Package: com.something.activator.b >>>>>>> >>>>>>> CompC >>>>>>> Import-Package: com.something.classes; version="[1.0.1, 1.0.1]", >>>>>>> com.something.b.main >>>>>>> Private-Package: com.something.activator.c >>>>>>> >>>>>>> -> richard >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Yair >>>>>>>> >>>>>>>> On Wed, Apr 14, 2010 at 4:40 PM, Richard S. Hall< >>>>>>>> [email protected] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On 4/14/10 9:19, Christopher Brind wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Hi Richard, >>>>>>>>>> >>>>>>>>>> Would you agree that a good rule of thumb (subject to specific >>>>>>>>>> circumstance >>>>>>>>>> of course) is that bundles should only import packages OR export >>>>>>>>>> packages, >>>>>>>>>> but not both? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Well, as long as you extend that with, ..."and package API >>>>>>>>> separately >>>>>>>>> from >>>>>>>>> the implementation." >>>>>>>>> >>>>>>>>> Then, yes, that'd be a good rule of thumb for the average case, >>>>>>>>> since >>>>>>>>> it >>>>>>>>> would result in the fewest issues overall at the expense of >>>>>>>>> creating >>>>>>>>> more >>>>>>>>> bundles to manage. >>>>>>>>> >>>>>>>>> -> richard >>>>>>>>> >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Chris >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 14 April 2010 14:13, Richard S. Hall<[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Technically, what you want to do is possible assuming that CompB >>>>>>>>>>> doesn't >>>>>>>>>>> expose CompA v1 to CompC. From the sounds of it, you've packaged >>>>>>>>>>> your >>>>>>>>>>> bundles incorrectly. Don't embed the Person package into your >>>>>>>>>>> bundles, >>>>>>>>>>> package them as separate bundles and them use Import-Package in >>>>>>>>>>> the >>>>>>>>>>> client >>>>>>>>>>> bundles to access them. You might want to start with some >>>>>>>>>>> introductory >>>>>>>>>>> OSGi >>>>>>>>>>> tutorials to understand the basics. >>>>>>>>>>> >>>>>>>>>>> -> richard >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 4/14/10 6:53, Yair Ogen wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I am a newbie. I've created dummy projects to test this out. >>>>>>>>>>>> >>>>>>>>>>>> What I am trying to achieve is as follows: >>>>>>>>>>>> >>>>>>>>>>>> CompA version 1.0.0 defines class Person that has 2 properties: >>>>>>>>>>>> name, >>>>>>>>>>>> lastName >>>>>>>>>>>> CompA version 1.0.1 defines class Person that has 2 properties: >>>>>>>>>>>> name, >>>>>>>>>>>> myLastName >>>>>>>>>>>> CompB version 1.0.0 calls API on person compiled with CompA >>>>>>>>>>>> version >>>>>>>>>>>> 1.0.0. >>>>>>>>>>>> CompC version 1.0.0 calls API on person compiled with CompA >>>>>>>>>>>> version >>>>>>>>>>>> 1.0.1. >>>>>>>>>>>> Additionally calls API on CompB. >>>>>>>>>>>> >>>>>>>>>>>> So, CompA, both versions, are not dependent on anything. >>>>>>>>>>>> CompB is dependant on CompA version *1.0.0*. >>>>>>>>>>>> CompC is dependant on CompB version 1.0.0 and CompA version >>>>>>>>>>>> *1.0.1*. >>>>>>>>>>>> >>>>>>>>>>>> When I read about OSGi I thought that I should be able to see >>>>>>>>>>>> that >>>>>>>>>>>> the >>>>>>>>>>>> API >>>>>>>>>>>> used directly between C and A will activate Person from A >>>>>>>>>>>> version >>>>>>>>>>>> 1.0.1, >>>>>>>>>>>> but >>>>>>>>>>>> the API called from C to B to A will activate the person from A >>>>>>>>>>>> version >>>>>>>>>>>> 1.0.0. >>>>>>>>>>>> >>>>>>>>>>>> This is not the case. Pure B API activate the "right" person. >>>>>>>>>>>> >>>>>>>>>>>> Person used from C (regardless of the origin - API in C or API >>>>>>>>>>>> in >>>>>>>>>>>> B) >>>>>>>>>>>> activates the same Person - 1.0.1. >>>>>>>>>>>> >>>>>>>>>>>> When investigating I saw that the person class was embedded in B >>>>>>>>>>>> and >>>>>>>>>>>> in >>>>>>>>>>>> C, >>>>>>>>>>>> so of course they can only work with one class at a time. >>>>>>>>>>>> >>>>>>>>>>>> My question is - isn't there a non embedded approach, where >>>>>>>>>>>> both >>>>>>>>>>>> A >>>>>>>>>>>> versions >>>>>>>>>>>> jars are in the classpath and the container will pick up the >>>>>>>>>>>> correct >>>>>>>>>>>> dependency on the fly? >>>>>>>>>>>> >>>>>>>>>>>> This must work for me, because this is the heart of what I need >>>>>>>>>>>> from >>>>>>>>>>>> OSGi >>>>>>>>>>>> - >>>>>>>>>>>> Manage multiple version of the same artifacts in a single jvm... >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> >>>>>>>>>>>> Yair >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >>> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
