I think the exception is the correct behavior. The bundle resolves because you configured the system bundle to export the junit package, however when the class is loaded, it's not found, which is to be expected if you haven't configured the system classpath correctly. The results can also be affected by an osgi property used to configure what classloader is actaully used by the system bundle to load classes (it can use the boot classloader which contains only the jre).
2010/11/19 Jean-Baptiste Reich <[email protected]>: > I did another experiment but this time with the normal JRE 1.6 > I have created a bundle that uses junit.framework package (just for the > purpose of this example) and I have started felix with that bundle and with > the default configuration: > java -cp bin/junit-3.8.1.jar -jar bin/felix.jar > > And I get this error: > org.osgi.framework.BundleException: Unresolved constraint in bundle > extends-jre [117]: Unable to resolve 117.0: missing requirement [117.0] > package; (package=junit.framework) > at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3407) > at org.apache.felix.framework.Felix.startBundle(Felix.java:1714) > at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1143) > at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264) > at java.lang.Thread.run(Thread.java:662) > > This is the normal behaviour. > After that I have changed the felix configuration by adding this: > org.osgi.framework.system.packages.extra=junit.framework > > But I still have an error: > java.lang.NoClassDefFoundError: junit/framework/TestCase > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632) > at java.lang.ClassLoader.defineClass(ClassLoader.java:616) > at > org.apache.felix.framework.ModuleImpl$ModuleClassLoader.findClass(ModuleImpl.java:1904) > at > org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:728) > at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:72) > at > org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1765) > at java.lang.ClassLoader.loadClass(ClassLoader.java:248) > at > org.apache.felix.framework.ModuleImpl.getClassByDelegation(ModuleImpl.java:646) > at org.apache.felix.framework.Felix.createBundleActivator(Felix.java:3651) > at org.apache.felix.framework.Felix.activateBundle(Felix.java:1817) > at org.apache.felix.framework.Felix.startBundle(Felix.java:1739) > at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1143) > at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264) > at java.lang.Thread.run(Thread.java:662) > > This is the same problem I described before. So this is not related to the > CDC architecture. > > So, is this a bug ? > Is there something special to do in the configuration to resolve this case ? > > Thanks > > 2010/11/19 Jean-Baptiste Reich <[email protected]> > >> Yes, I did'nt mentioned it but I tried to use boot, app, ext and framework >> and nothing work >> >> 2010/11/19 Karl Pauls <[email protected]> >> >> Did you try to set: >>> >>> org.osgi.framework.bundle.parent="framework" >>> >>> regards, >>> >>> Karl >>> >>> 2010/11/19 Jean-Baptiste Reich <[email protected]>: >>> > First, this is my MANIFEST: >>> > Manifest-Version: 1.0 >>> > Export-Package: com.sandbox.jsse.server;uses:="javax.net,javax.net.ss >>> > l,com.sun.net.ssl,org.osgi.framework" >>> > Built-By: jb >>> > Tool: Bnd-0.0.357 >>> > Bundle-Name: jsse-server >>> > Created-By: Apache Maven Bundle Plugin >>> > Bundle-Version: 0.0.1.SNAPSHOT >>> > Build-Jdk: 1.6.0_20 >>> > Bnd-LastModified: 1290149610828 >>> > Bundle-ManifestVersion: 2 >>> > Bundle-Activator: com.sandbox.jsse.server.JSSEActivator >>> > Import-Package: com.sandbox.jsse.server,com.sun.net.ssl,javax.net,jav >>> > ax.net.ssl,org.osgi.framework;version="1.3" >>> > Bundle-SymbolicName: jsse-server >>> > For my tests, I use the felix framework 3.0.5. My basic configuration is >>> > attached to this mail >>> > These are the felix debug logs: >>> > DEBUG: WIRE: [62.0] package; >>> (&(package=org.osgi.framework)(version>=1.3.0)) >>> > -> [0] >>> > DEBUG: WIRE: [99.0] package; >>> (&(package=org.osgi.framework)(version>=1.4.0)) >>> > -> [0] >>> > DEBUG: WIRE: [99.0] package; >>> > (&(package=org.osgi.service.packageadmin)(version>=1.2.0)) -> [0] >>> > DEBUG: WIRE: [99.0] package; >>> > (&(package=org.osgi.service.startlevel)(version>=1.1.0)) -> [0] >>> > DEBUG: WIRE: [2.0] package; >>> > (&(package=org.osgi.framework)(version>=1.4.0)(!(version>=2.0.0))) -> >>> [0] >>> > DEBUG: WIRE: [2.0] package; >>> > (&(package=org.osgi.service.cm)(version>=1.2.0)(!(version>=2.0.0))) -> >>> > [62.0] >>> > DEBUG: WIRE: [2.0] package; >>> > (&(package=org.osgi.service.log)(version>=1.3.0)(!(version>=2.0.0))) -> >>> > [99.0] >>> > DEBUG: WIRE: [2.0] package; >>> > >>> (&(package=org.osgi.service.packageadmin)(version>=1.2.0)(!(version>=2.0.0))) >>> > -> [0] >>> > DEBUG: WIRE: [2.0] package; >>> > >>> (&(package=org.osgi.service.startlevel)(version>=1.1.0)(!(version>=2.0.0))) >>> > -> [0] >>> > DEBUG: WIRE: [2.0] package; >>> > (&(package=org.osgi.service.url)(version>=1.0.0)(!(version>=2.0.0))) -> >>> [0] >>> > DEBUG: WIRE: [2.0] package; >>> > (&(package=org.osgi.util.tracker)(version>=1.3.0)(!(version>=2.0.0))) -> >>> [0] >>> > DEBUG: WIRE: [7.0] package; >>> (&(package=org.osgi.framework)(version>=1.3.0)) >>> > -> [0] >>> > DEBUG: WIRE: [7.0] package; >>> > (&(package=org.osgi.util.tracker)(version>=1.3.0)) -> [0] >>> > DEBUG: WIRE: [8.0] package; >>> > (&(package=org.apache.felix.shell)(version>=1.0.0)) -> [99.0] >>> > DEBUG: WIRE: [8.0] package; >>> (&(package=org.osgi.framework)(version>=1.3.0)) >>> > -> [0] >>> > -> DEBUG: WIRE: [21.0] package; (package=com.sun.net.ssl) -> [0] >>> > DEBUG: WIRE: [21.0] package; (package=javax.net) -> [0] >>> > DEBUG: WIRE: [21.0] package; (package=javax.net.ssl) -> [0] >>> > DEBUG: WIRE: [21.0] package; >>> (&(package=org.osgi.framework)(version>=1.3.0)) >>> > -> [0] >>> > ERROR: Error starting >>> > >>> file:/home/jb/projects/felix-framework-3.0.5/deploy/jsse-server-0.0.1-SNAPSHOT.jar >>> > (org.osgi.framework.BundleException: Activator start error in bundle >>> > jsse-server [21].) >>> > java.lang.NoClassDefFoundError: javax.net.ServerSocketFactory >>> > at java.lang.Class.getConstructor0(Native Method) >>> > at >>> org.apache.felix.framework.Felix.createBundleActivator(Felix.java:3657) >>> > at org.apache.felix.framework.Felix.activateBundle(Felix.java:1817) >>> > at org.apache.felix.framework.Felix.startBundle(Felix.java:1739) >>> > at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1143) >>> > at >>> org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264) >>> > at java.lang.Thread.run(Thread.java:712) >>> > at java.lang.Thread.startup(Thread.java:782) >>> > DEBUG: DYNAMIC WIRE: [7.0] package; (package=org.apache.felix.shell) -> >>> > [99.0] >>> > I tried to use these different configurations: >>> > 1: >>> > org.osgi.framework.system.packages.extra=com.sun.net.ssl; \ >>> > com.sun.net.ssl.internal.ssl; \ >>> > com.sun.net.ssl.internal.www.protocol.https; \ >>> > com.sun.security.cert.internal.x509; \ >>> > javax.net; \ >>> > javax.net.ssl; \ >>> > javax.security.auth.x509; \ >>> > javax.security.cert;version=1.4.0 >>> > #org.osgi.framework.bootdelegation=sun.*,com.sun.* >>> > 2: >>> > org.osgi.framework.system.packages.extra=com.sun.net.ssl; \ >>> > com.sun.net.ssl.internal.ssl; \ >>> > com.sun.net.ssl.internal.www.protocol.https; \ >>> > com.sun.security.cert.internal.x509; \ >>> > javax.net; \ >>> > javax.net.ssl; \ >>> > javax.security.auth.x509; \ >>> > javax.security.cert;version=1.4.0 >>> > org.osgi.framework.bootdelegation=sun.*,com.sun.*,javax.* >>> > 3: >>> > org.osgi.framework.system.packages.extra=com.sun.net.ssl; \ >>> > com.sun.net.ssl.internal.ssl; \ >>> > com.sun.net.ssl.internal.www.protocol.https; \ >>> > com.sun.security.cert.internal.x509; \ >>> > javax.net; \ >>> > javax.net.ssl; \ >>> > javax.security.auth.x509; \ >>> > javax.security.cert;version=1.4.0 >>> > org.osgi.framework.bootdelegation=* >>> > 4 (in this case I changed the imported packages to optional in the >>> > MANIFEST): >>> > #org.osgi.framework.system.packages.extra= >>> > org.osgi.framework.bootdelegation=sun.*,com.sun.*,javax.* >>> > 5 (in this case I changed the imported packages to optional in the >>> > MANIFEST): >>> > #org.osgi.framework.system.packages.extra= >>> > org.osgi.framework.bootdelegation=* >>> > >>> > >>> > None of them works... >>> > 2010/11/19 Marcel Offermans <[email protected]> >>> >> >>> >> You can, but it's *not* the preferred solution. Boot delegation should >>> >> only be used if all else fails. Just exporting the packages through the >>> >> system bundle is more explicit (you actually import what you need, >>> which >>> >> makes it very visible and debuggable). >>> >> >>> >> Greetings, Marcel >>> >> >>> >> On 19 Nov 2010, at 10:14 , Ke Yao wrote: >>> >> >>> >> > You can add the sentence which is >>> >> > "org.osgi.framework.bootdelegation=javax.* "in the felix's cfg file >>> .Due to >>> >> > when felix load the JDK, it only load the java package, the javax and >>> org >>> >> > packages aren't been loaded, so you need cfg the bootdelegation. >>> >> > >>> >> > >>> >> > The most powerful enemy is yourself,beat your own,win the world! >>> >> > >>> >> > >>> _________________________________________________________________________________________ >>> >> > >>> >> > 姚柯（Ivan Yao） >>> >> > 浙江网新恒天软件有限公司 >>> >> > Insigma Hengtian Software Ltd. >>> >> > Address: Building J1, Insigma Software Park, 1 Xiyuan8 Road, San Dun, >>> >> > West Lake District >>> >> > Zip Code: 310007 >>> >> > Tel:13735434226 >>> >> > MSN:[email protected] <msn%[email protected]> >>> >> > >>> >> > -----Original Message----- >>> >> > From: Marcel Offermans [mailto:[email protected]] >>> >> > Sent: 2010年11月19日 17:10 >>> >> > To: [email protected] >>> >> > Subject: Re: Class loading problem >>> >> > >>> >> > @Jean-Baptiste: Perhaps a stupid question, but since it's a javax.* >>> >> > class that cannot be found, are you actually exporting these packages >>> >> > through the system bundle? >>> >> > >>> >> > On 19 Nov 2010, at 10:01 , Karl Pauls wrote: >>> >> > >>> >> >> Can you share the manifest of your bundle with us? Additionally, can >>> >> >> you set the debug level to 4 and give the output as well? >>> >> >> >>> >> >> regards, >>> >> >> >>> >> >> Karl >>> >> >> >>> >> >> On Fri, Nov 19, 2010 at 8:21 AM, Jean-Baptiste Reich >>> >> >> <[email protected]> wrote: >>> >> >>> Hello, >>> >> >>> >>> >> >>> I tried to run felix on a CDC architecture and with jsse enabled >>> >> >>> (which is >>> >> >>> optional). For that, I add the jsse jars to the classpath on the >>> >> >>> command >>> >> >>> line when starting felix with my VM (cvm). >>> >> >>> Then in my bundle I try to load the class >>> >> >>> javax.net.ServerSocketFactory but >>> >> >>> I receive a NoClassDefFoundError. >>> >> >>> When I launch my project as a normal JAR (not a bundle) with >>> exactly >>> >> >>> the >>> >> >>> same command line, it works (in that case the server is not >>> embedded >>> >> >>> in >>> >> >>> felix). So, I assume there is a class loading problem but I don't >>> >> >>> understand >>> >> >>> it. >>> >> >>> >>> >> >>> Did I miss something ? Is there a special way to handle this? (I >>> have >>> >> >>> already tried to change the bootdelegation and the bundle parent >>> but >>> >> >>> it does >>> >> >>> not work) >>> >> >>> >>> >> >>> Thanks >>> >> >>> >>> >> >> >>> >> >> >>> >> >> >>> >> >> -- >>> >> >> 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] >>> >> > >>> >> > >>> >> >>> >> >>> >> --------------------------------------------------------------------- >>> >> 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] >>> >>> >> > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
