Hello Karl, Thank you for your answer and help. I have opened a bug report for Equinox
https://bugs.eclipse.org/bugs/show_bug.cgi?id=224833 Regards, Michael -----Ursprüngliche Nachricht----- Von: Karl Pauls [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 28. März 2008 13:34 An: [email protected] Betreff: Re: AW: obr resolving and system packages Well, the idea is that the system bundle should list all the packages it exports in its Export-Package header. That is what the spec indicates and what is the case for all other bundles. A resolved bundle exports the packages in its Export-Package header which one can get from a call to getHeaders(). In case you create a bug report feel free to post a reference here as well, then we can comment on the bug as well :-) regards, Karl On Fri, Mar 28, 2008 at 9:47 AM, Hampel, Michael <[EMAIL PROTECTED]> wrote: > > Thank you for your answers. > I tried now with Felix and Karl is right - it works. If I print the headers > of the system bundle in the > Felix case there is an Export-Package header with all javax and so forth > packages included. > In the equinox case the Export-Package header does not contain these > packages but they are exported by the system package > Anyway. > In both cases the original Manifest file in the jar is not containing these > packages in the Export-Package header. > So felix must add them at runtime - can you please give me a hint what I > should ask the equinox people > To change? > > Thanx again in advance for your help, > > > Michael > > > > -----Ursprüngliche Nachricht----- > Von: Richard S. Hall [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 27. März 2008 20:06 > > An: [email protected] > Betreff: Re: AW: obr resolving and system packages > > > > Yeah, now that Karl reminds me, I think he is correct. We don't re-parse > the manifest, we do getHeaders() and parse the results of that. On > Felix, this should return the correct value. > > -> richard > > Karl Pauls wrote: > > I disagree. The system package should make javax packages available in > > its manifest if they are exported by the system bundle (and Felix will > > do so in case it is configured correctly). Why would the system bundle > > export packages that are not in it's manifest? Now, equinox doesn't do > > so but that doesn't imply that we have to change anything - maybe a > > bug report against equinox is more in order? > > > > The spec says the system bundle's getHeaders should contain an > > Export-Package header that contains a list of packages that are to be > > exported by the framework -- hence, I'd say its a bug in equinox. > > > > regards, > > > > Karl > > > > > >> Yes, you are probably correct...at least it sounds reasonable. > >> > >> What we probably need to do is modify LocalRepositoryImpl to special > >> case the system bundle to calculate its exported packages differently... > >> > >> Please feel free to look into this issue and/or create a JIRA issue > >> against OBR. > >> > >> Thanks for follow up. > >> > >> > >> > >> -> richard > >> > >> Hampel, Michael wrote: > >> > > >> > Hello, > >> > > >> > After debugging the felix bundlerepository I think I found the problem > why the packages are not > >> > Found. > >> > When looking at the code of LocalRepositoryImpl the > initialization(initialize()) of a LocalResourceImpl instance > >> > Determines the exported packages of a local resource by examining its > manifest entries. > >> > Now, the system bundle (in my case equinox but I also think Felix) is > not exporting javax packages in its > >> > Manifest file - this is triggered via the > org.osgi.framework.system.packages property (I think). > >> > Therefore the OBR Resolver does not find these packages from the > system bundle. > >> > If I use the PackageAdmin to list the packages exported by the > SystemBundle then the framework system packages > >> > Are included (I think this is also how the Felix GUI gets the exported > packages for a bundle to display). > >> > Another solution was to read the FRAMEWORK_SYSTEMPACKAGES property > from the BundleContext to get the exported > >> > System packages. > >> > One of these solutions could be used to add the exported system > packages to the capabilities of the SystemBundle. > >> > > >> > Please let me know if I am on the right track and if so which solution > you would prefer and if the > >> > LocalRepositoryImpl could be changed. > >> > > >> > Thanx in advance for any help, > >> > > >> > Michael > >> > > >> > > >> > > >> > > >> > -----Ursprüngliche Nachricht----- > >> > Von: Hampel, Michael > >> > Gesendet: Donnerstag, 20. März 2008 13:21 > >> > An: [email protected] > >> > Betreff: AW: obr resolving and system packages > >> > > >> > Hello again, > >> > > >> > I have now listed the exported packages of my system bundle and it > contains all javax and org.xml packages > >> > The OBR resolver is not able to find. > >> > Also the runtime is able to resolve and start the bundle with these > package dependencies. > >> > Could you please explain how the OBR resolver would find these > packages? > >> > > >> > Thanx in advance, > >> > > >> > Michael > >> > > >> > > >> > > >> > > >> > -----Ursprüngliche Nachricht----- > >> > Von: Hampel, Michael > >> > Gesendet: Donnerstag, 20. März 2008 12:13 > >> > An: [email protected] > >> > Betreff: AW: obr resolving and system packages > >> > > >> > Hello Richard, > >> > > >> > Thank you for your answer. > >> > I actually tried it. > >> > I have a directory where I put all my bundles in and which I use as > the repository. > >> > I then start the OSGi runtime (in my case equinox) plus the necessary > bundles for OBR handling > >> > within eclipse with the help of a run configuration. > >> > > >> > By saying > >> > "If your local system bundle exports javax.swing" > >> > do you mean that if I would start felix with a configuration file that > includes > >> > org.osgi.framework.system.packages= > >> > ${jre-${java.specification.version}} > >> > plus all java platform package export properties like > >> > jre-1.3=, \ > >> > javax.accessibility; \ > >> > javax.accessibility.resources; \ > >> > javax.naming; \ > >> > ..... > >> > > >> > Then the OBR Resolver should find it from the system bundle? > >> > > >> > Thank you again for your help, > >> > > >> > Michael > >> > > >> > > >> > > >> > > >> > -----Ursprüngliche Nachricht----- > >> > Von: Richard S. Hall [mailto:[EMAIL PROTECTED] > >> > Gesendet: Donnerstag, 20. März 2008 11:08 > >> > An: [email protected] > >> > Betreff: Re: obr resolving and system packages > >> > > >> > Did you actually try this or are you just making an assumption? > >> > > >> > OBR treats the locally installed bundles as a repository too. So, if > >> > your local system bundle exports javax.swing, then it should resolve > the > >> > package correctly...at least that is how it is supposed to work. > >> > > >> > -> richard > >> > > >> > Hampel, Michael wrote: > >> > > >> >> Hello, > >> >> > >> >> how do I deal with system package dependencies like javax.swing - > that > >> >> an OSGi runtime would be able to resolve from the system classpath - > >> >> in the OBR resolving process. > >> >> If a resource in my repository.xml has a require element for > javax.swing > >> >> the Resolver tries to find the dependency in one of my specified > >> >> repositories > >> >> but will not find it - so the OBR resolving for this resource will > fail > >> >> although it would resolve in the runtime. > >> >> Is there a way to add system packages to the OBR resolving process or > do > >> >> I have to specify all aof these packages as optional or do I see > >> >> this completely wrong? > >> >> > >> >> Thanx in advance for any help, > >> >> > >> >> Michael > >> >> > >> >> > >> >> > >> >> > >> > > >> > --------------------------------------------------------------------- > >> > 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] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Karl Pauls [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]
