Re: two bundles with same package problem
Thanks a lot. This is really what I need. Actually I am just integrating legacy code to osgi environment and that is why I need this "hack". 2008/4/11, Stuart McCulloch <[EMAIL PROTECTED]>: > this is a classic "split-package" problem, where you have > two bundles exporting the same package but with different > content (which is usually a bad idea) > > in OSGi only one bundle will be chosen as the "exporter" > of a given version of a package, so you will see missing > class problems like you mention with split-packages. > > see section 3.13 of the OSGi spec for more discussion of > split-packages, and a solution (Require-Bundle). However, > note that there are side-effects of using Require-Bundle > that mean it should be used very sparingly, usually when > integrating legacy code with OSGi where you don't have > control over the package content > > for new projects where you can refactor your code, it's > advisable to ensure that there's only one set of content > for a given package, as this is much more maintainable > and you get the most out of OSGi wrt. dynamic upgrades > > I often suggest also putting the API/SPI package(s) into > a separate bundle than the implementation, as this makes > it much easier to swap implementations at runtime. > > HTH >
Re: two bundles with same package problem
On 11/04/2008, Sergey Parilin <[EMAIL PROTECTED]> wrote: > > Ops, sorry. It was a mistake in the example. It was because > maven-bundle-plugin don't add not exporting package in to the bundle > archive. You must delete Export-Package directive from > bundle2/osgi.bnd and rebuild and rerun it. Or there is a fixed version > in attachment. For now classes in second bundle in org.foo are > present, but bundle2 still can't find org.foo.ExampleService2 and I > have this response: > java.lang.NoClassDefFoundError: *** Package 'org.foo' is imported by > bundle 2 from bundle 1, but the exported package from bundle 1 does > not contain the requested class 'org.foo.ExampleService2'. Please > verify that the class name is correct in the importing bundle 2 and/or > that the exported package is correctly bundled in 1. *** > But class org.foo.ExampleService2 presented in bundle2 this is a classic "split-package" problem, where you have two bundles exporting the same package but with different content (which is usually a bad idea) in OSGi only one bundle will be chosen as the "exporter" of a given version of a package, so you will see missing class problems like you mention with split-packages. see section 3.13 of the OSGi spec for more discussion of split-packages, and a solution (Require-Bundle). However, note that there are side-effects of using Require-Bundle that mean it should be used very sparingly, usually when integrating legacy code with OSGi where you don't have control over the package content for new projects where you can refactor your code, it's advisable to ensure that there's only one set of content for a given package, as this is much more maintainable and you get the most out of OSGi wrt. dynamic upgrades I often suggest also putting the API/SPI package(s) into a separate bundle than the implementation, as this makes it much easier to swap implementations at runtime. HTH 2008/4/11, Karl Pauls <[EMAIL PROTECTED]>: > > > You don't include the org.foo package inside your second bundle (i.e., > > there are no classes in the org/foo dir). That is why you can't find > > the classes. > > > > Felix and Kf's behaviour is the correct one. Since the bundle that > > exports the package actually doesn't have anything to export the > > classes can not be found. It probably only works on Equinox because > > they do bootdelegate to the classpath by default (which is bad). Just > > make sure your bundle contains the org.foo package and it should work. > > > > regards, > > > > Karl > > > > > > On Fri, Apr 11, 2008 at 2:55 PM, Sergey Parilin <[EMAIL PROTECTED]> > wrote: > > > Thanks for the quick answer. > > > > > > Here they are. > > > > > > This is the first: > > > > > > Manifest-Version: 1.0 > > > Export-Package: org.foo;version="1.0.0.SNAPSHOT" > > > Private-Package: org.foo.internal > > > Ignore-Package: org.foo.internal > > > Built-By: sap > > > Tool: Bnd-0.0.227 > > > Bundle-Name: org.foo.test-osgi.bundle1 [org.foo] > > > Created-By: Apache Maven Bundle Plugin > > > Build-Jdk: 1.6.0_03 > > > Bundle-Version: 1.0.0.SNAPSHOT > > > Bnd-LastModified: 1207917736196 > > > Bundle-ManifestVersion: 2 > > > Bundle-Activator: org.foo.internal.ExampleActivator1 > > > Bundle-Description: Generated using Pax-Construct v2 > > > Import-Package: org.foo;version="1.0.0.SNAPSHOT",org.osgi.framework > > > Bundle-SymbolicName: org.foo.test-osgi.bundle1 > > > > > > This is the second: > > > > > > Manifest-Version: 1.0 > > > Private-Package: org.foo.internal > > > Ignore-Package: org.foo.internal > > > Built-By: sap > > > Tool: Bnd-0.0.227 > > > Bundle-Name: org.foo.test-osgi.bundle2 [org.foo] > > > Created-By: Apache Maven Bundle Plugin > > > Build-Jdk: 1.6.0_03 > > > Bundle-Version: 1.0.0.SNAPSHOT > > > Bnd-LastModified: 1207917736734 > > > Bundle-ManifestVersion: 2 > > > Bundle-Activator: org.foo.internal.ExampleActivator2 > > > Bundle-Description: Generated using Pax-Construct v2 > > > Import-Package: org.foo;version="1.0.0.SNAPSHOT",org.osgi.framework > > > Bundle-SymbolicName: org.foo.test-osgi.bundle2 > > > > > > Also, I have attached my example as an archive. > > > You can extract it. Build and execute with maven2. > > > mvn clean install > > > mvn -Dframework=felix pax:provision > > > or > > > mvn -Dframework=equinox pax:provision > > > > > > to feel a difference. > > > > > > 2008/4/11, Marcel Offermans <[EMAIL PROTECTED]>: > > > > > > > > > > On Apr 11, 2008, at 13:13 , Sergey Parilin wrote: > > > > > > > > > > > > > I have two bundles (A and B). Bundle A have package org.foo and > > > > > imports it. > > > > > > > > > > > > > Could you please show us both manifests, because I'm not sure I > completely > > > > understand your story. > > > > > > > > Greetings, Marcel > > > > > > > > > > > > > > > > > > > > > -- > > Karl Pauls > > [EMAIL PROTECTED] > > > > -- Cheers, Stuart
Re: two bundles with same package problem
Ops, sorry. It was a mistake in the example. It was because maven-bundle-plugin don't add not exporting package in to the bundle archive. You must delete Export-Package directive from bundle2/osgi.bnd and rebuild and rerun it. Or there is a fixed version in attachment. For now classes in second bundle in org.foo are present, but bundle2 still can't find org.foo.ExampleService2 and I have this response: java.lang.NoClassDefFoundError: *** Package 'org.foo' is imported by bundle 2 from bundle 1, but the exported package from bundle 1 does not contain the requested class 'org.foo.ExampleService2'. Please verify that the class name is correct in the importing bundle 2 and/or that the exported package is correctly bundled in 1. *** But class org.foo.ExampleService2 presented in bundle2 2008/4/11, Karl Pauls <[EMAIL PROTECTED]>: > You don't include the org.foo package inside your second bundle (i.e., > there are no classes in the org/foo dir). That is why you can't find > the classes. > > Felix and Kf's behaviour is the correct one. Since the bundle that > exports the package actually doesn't have anything to export the > classes can not be found. It probably only works on Equinox because > they do bootdelegate to the classpath by default (which is bad). Just > make sure your bundle contains the org.foo package and it should work. > > regards, > > Karl > > > On Fri, Apr 11, 2008 at 2:55 PM, Sergey Parilin <[EMAIL PROTECTED]> wrote: > > Thanks for the quick answer. > > > > Here they are. > > > > This is the first: > > > > Manifest-Version: 1.0 > > Export-Package: org.foo;version="1.0.0.SNAPSHOT" > > Private-Package: org.foo.internal > > Ignore-Package: org.foo.internal > > Built-By: sap > > Tool: Bnd-0.0.227 > > Bundle-Name: org.foo.test-osgi.bundle1 [org.foo] > > Created-By: Apache Maven Bundle Plugin > > Build-Jdk: 1.6.0_03 > > Bundle-Version: 1.0.0.SNAPSHOT > > Bnd-LastModified: 1207917736196 > > Bundle-ManifestVersion: 2 > > Bundle-Activator: org.foo.internal.ExampleActivator1 > > Bundle-Description: Generated using Pax-Construct v2 > > Import-Package: org.foo;version="1.0.0.SNAPSHOT",org.osgi.framework > > Bundle-SymbolicName: org.foo.test-osgi.bundle1 > > > > This is the second: > > > > Manifest-Version: 1.0 > > Private-Package: org.foo.internal > > Ignore-Package: org.foo.internal > > Built-By: sap > > Tool: Bnd-0.0.227 > > Bundle-Name: org.foo.test-osgi.bundle2 [org.foo] > > Created-By: Apache Maven Bundle Plugin > > Build-Jdk: 1.6.0_03 > > Bundle-Version: 1.0.0.SNAPSHOT > > Bnd-LastModified: 1207917736734 > > Bundle-ManifestVersion: 2 > > Bundle-Activator: org.foo.internal.ExampleActivator2 > > Bundle-Description: Generated using Pax-Construct v2 > > Import-Package: org.foo;version="1.0.0.SNAPSHOT",org.osgi.framework > > Bundle-SymbolicName: org.foo.test-osgi.bundle2 > > > > Also, I have attached my example as an archive. > > You can extract it. Build and execute with maven2. > > mvn clean install > > mvn -Dframework=felix pax:provision > > or > > mvn -Dframework=equinox pax:provision > > > > to feel a difference. > > > > 2008/4/11, Marcel Offermans <[EMAIL PROTECTED]>: > > > > > > > On Apr 11, 2008, at 13:13 , Sergey Parilin wrote: > > > > > > > > > > I have two bundles (A and B). Bundle A have package org.foo and > > > > imports it. > > > > > > > > > > Could you please show us both manifests, because I'm not sure I > completely > > > understand your story. > > > > > > Greetings, Marcel > > > > > > > > > > > > > -- > Karl Pauls > [EMAIL PROTECTED] > test-osgi.tar.gz Description: GNU Zip compressed data
Re: two bundles with same package problem
You don't include the org.foo package inside your second bundle (i.e., there are no classes in the org/foo dir). That is why you can't find the classes. Felix and Kf's behaviour is the correct one. Since the bundle that exports the package actually doesn't have anything to export the classes can not be found. It probably only works on Equinox because they do bootdelegate to the classpath by default (which is bad). Just make sure your bundle contains the org.foo package and it should work. regards, Karl On Fri, Apr 11, 2008 at 2:55 PM, Sergey Parilin <[EMAIL PROTECTED]> wrote: > Thanks for the quick answer. > > Here they are. > > This is the first: > > Manifest-Version: 1.0 > Export-Package: org.foo;version="1.0.0.SNAPSHOT" > Private-Package: org.foo.internal > Ignore-Package: org.foo.internal > Built-By: sap > Tool: Bnd-0.0.227 > Bundle-Name: org.foo.test-osgi.bundle1 [org.foo] > Created-By: Apache Maven Bundle Plugin > Build-Jdk: 1.6.0_03 > Bundle-Version: 1.0.0.SNAPSHOT > Bnd-LastModified: 1207917736196 > Bundle-ManifestVersion: 2 > Bundle-Activator: org.foo.internal.ExampleActivator1 > Bundle-Description: Generated using Pax-Construct v2 > Import-Package: org.foo;version="1.0.0.SNAPSHOT",org.osgi.framework > Bundle-SymbolicName: org.foo.test-osgi.bundle1 > > This is the second: > > Manifest-Version: 1.0 > Private-Package: org.foo.internal > Ignore-Package: org.foo.internal > Built-By: sap > Tool: Bnd-0.0.227 > Bundle-Name: org.foo.test-osgi.bundle2 [org.foo] > Created-By: Apache Maven Bundle Plugin > Build-Jdk: 1.6.0_03 > Bundle-Version: 1.0.0.SNAPSHOT > Bnd-LastModified: 1207917736734 > Bundle-ManifestVersion: 2 > Bundle-Activator: org.foo.internal.ExampleActivator2 > Bundle-Description: Generated using Pax-Construct v2 > Import-Package: org.foo;version="1.0.0.SNAPSHOT",org.osgi.framework > Bundle-SymbolicName: org.foo.test-osgi.bundle2 > > Also, I have attached my example as an archive. > You can extract it. Build and execute with maven2. > mvn clean install > mvn -Dframework=felix pax:provision > or > mvn -Dframework=equinox pax:provision > > to feel a difference. > > 2008/4/11, Marcel Offermans <[EMAIL PROTECTED]>: > > > > On Apr 11, 2008, at 13:13 , Sergey Parilin wrote: > > > > > > > I have two bundles (A and B). Bundle A have package org.foo and > > > imports it. > > > > > > > Could you please show us both manifests, because I'm not sure I completely > > understand your story. > > > > Greetings, Marcel > > > > > -- Karl Pauls [EMAIL PROTECTED]
Re: two bundles with same package problem
Thanks for the quick answer. Here they are. This is the first: Manifest-Version: 1.0 Export-Package: org.foo;version="1.0.0.SNAPSHOT" Private-Package: org.foo.internal Ignore-Package: org.foo.internal Built-By: sap Tool: Bnd-0.0.227 Bundle-Name: org.foo.test-osgi.bundle1 [org.foo] Created-By: Apache Maven Bundle Plugin Build-Jdk: 1.6.0_03 Bundle-Version: 1.0.0.SNAPSHOT Bnd-LastModified: 1207917736196 Bundle-ManifestVersion: 2 Bundle-Activator: org.foo.internal.ExampleActivator1 Bundle-Description: Generated using Pax-Construct v2 Import-Package: org.foo;version="1.0.0.SNAPSHOT",org.osgi.framework Bundle-SymbolicName: org.foo.test-osgi.bundle1 This is the second: Manifest-Version: 1.0 Private-Package: org.foo.internal Ignore-Package: org.foo.internal Built-By: sap Tool: Bnd-0.0.227 Bundle-Name: org.foo.test-osgi.bundle2 [org.foo] Created-By: Apache Maven Bundle Plugin Build-Jdk: 1.6.0_03 Bundle-Version: 1.0.0.SNAPSHOT Bnd-LastModified: 1207917736734 Bundle-ManifestVersion: 2 Bundle-Activator: org.foo.internal.ExampleActivator2 Bundle-Description: Generated using Pax-Construct v2 Import-Package: org.foo;version="1.0.0.SNAPSHOT",org.osgi.framework Bundle-SymbolicName: org.foo.test-osgi.bundle2 Also, I have attached my example as an archive. You can extract it. Build and execute with maven2. mvn clean install mvn -Dframework=felix pax:provision or mvn -Dframework=equinox pax:provision to feel a difference. 2008/4/11, Marcel Offermans <[EMAIL PROTECTED]>: > On Apr 11, 2008, at 13:13 , Sergey Parilin wrote: > > > > I have two bundles (A and B). Bundle A have package org.foo and > > imports it. > > > > Could you please show us both manifests, because I'm not sure I completely > understand your story. > > Greetings, Marcel > > test-osgi.tar.gz Description: GNU Zip compressed data
Re: two bundles with same package problem
On Apr 11, 2008, at 13:13 , Sergey Parilin wrote: I have two bundles (A and B). Bundle A have package org.foo and imports it. Could you please show us both manifests, because I'm not sure I completely understand your story. Greetings, Marcel
two bundles with same package problem
Hi, I have one problem and hope you will help me. First of all, example which I mentioning below is a simple representation of more complex problem with third party libraries. This means that I can't change any packages at all. I have two bundles (A and B). Bundle A have package org.foo and imports it. Package B exports package org.foo from bundle A, but bundle B have it's own package org.foo with classes which are differ from classes in bundle A. And this is a problem: when bundle B exports the package org.foo it can't find any of it's own classes from that package if it doesn't export this package then it can't find classes from bundle A. The main confusing thing in this story that I had tried run this example on other osgi framework implementations using a pax:provision and results are not the same. Felix and Knopperfish had thrown a NoClassDefFoundError but Equinox and Concierge had executed this example normally. Which implementation is right in this situation? Or may be felix must be configured to support this behaviour? Thanks in advance.
Re: Moving the Sling Management Console to Apache Felix
On Fri, Apr 11, 2008 at 9:47 AM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > ... Point is, if we can show to the IPMC that both communities are > interested in this move - shown by a vote in both places - this should > not be a problem to the IPMC Ok, let's have those votes then. I'm also on the IPMC, so I'll support our case there if needed. -Bertrand
Re: Moving the Sling Management Console to Apache Felix
Hi all, Am Freitag, den 11.04.2008, 09:35 +0200 schrieb Bertrand Delacretaz: > On Fri, Apr 11, 2008 at 8:10 AM, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > > ... so I guess the final thing we have to do is to vote in both projects if > > each project agrees to moving the stuff > > ok > > > ... Not sure, but as Sling is in the > > Incubator we might need a vote from the Incubator PMC - otherwise we would > > bypass the incubator process :)... > > You're probably right - I would indicate in the vote request that most > of the console code has been contributed by Felix Meschberger, and > some of it by you and me, mentioning that we're all experienced > committers. > > That should make it easier for people to accept the move, even though > in theory you're right that this bypasses the incubator process. I quickly talked to Aaron about this issue. He said, that it should probably not be an issue to move this code but he would confirm with Noel of the IPMC and come back to me. Point is, if we can show to the IPMC that both communities are interested in this move - shown by a vote in both places - this should not be a problem to the IPMC. Regards Felix
Re: Moving the Sling Management Console to Apache Felix
On Fri, Apr 11, 2008 at 8:10 AM, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > ... so I guess the final thing we have to do is to vote in both projects if > each project agrees to moving the stuff ok > ... Not sure, but as Sling is in the > Incubator we might need a vote from the Incubator PMC - otherwise we would > bypass the incubator process :)... You're probably right - I would indicate in the vote request that most of the console code has been contributed by Felix Meschberger, and some of it by you and me, mentioning that we're all experienced committers. That should make it easier for people to accept the move, even though in theory you're right that this bypasses the incubator process. -Bertrand
