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? 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] > >
