Hi, Not that I'm doing anything other than slightly venting myself, with no intentional bashing of any kind (other than maybe the whole class loading invention in java, more or less)...
Those Class.forName() constructs seem to be a constant source of frustration, especially when coupled to things like OSGi (not the fault of OSGi in the least, IMO); I just ran into an issue with Class.forName() when it came to loading MySql drivers... I ended up added the MySql driver package(s) to the bootdelegation property in the Felix config.properties file and problem solved (ok, maybe it's not esoteric optimalism, admittedly; And, that thwarts a dynamic upgrade of the drivers, but still...); With OSGi, it's such a mind set change from "legacy container business as usual" and all these Class.forName() games of the past -- to service injection, really... I'd rather play the "service injection" game myself, frankly... Well, glad to see some closure on this one... Have a good day, happy trails, Craig Phillips, Praxis -----Original Message----- From: Jackson, Bruce [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2008 10:08 AM To: [email protected] Subject: Re: Classloading across bundles Thanks for that, I've got to the bottom of the problem. Its quite obscure: obviously, my handler does many other things and contains a helper which in the constructor stores a copy of the class name. In the invoke, the stored class name is used in a Class.forName() call, and that is what causes the exception. Thanks for your help, much appreciated On 04/08/2008 11:38, "Stuart McCulloch" <[EMAIL PROTECTED]> wrote: 2008/8/4 Jackson, Bruce <[EMAIL PROTECTED]> > Hi Stuart > > Well, that's interesting. To use your description of my problem (which is > correct) the interface ObjectManagement declared in bundle A is indeed > public, and it is also imported by B. B provides its own interface (in the > code fragment, its passed as the argument clazz) which it passes to the > service method in A. > I've just hacked up an extremely simple project that does exactly this: the client (B) passes a class to the proxy service (A), which creates a proxy based on the given class and another interface from A that is both public and exported from A. The project deploys and runs without any exceptions - also note the proxy bundle (A) doesn't need to import anything from the client (B). So I think there must be something else in your particular setup that is causing the visibility issue - I see from the stack trace that you're also using some sort of remoting, which does a "Class.forName(...)" I think this is the actual problem, to confirm this you could comment out the remoting call and see if the same exception occurs. To diagnose further we'd need access to some sort of public testcase (unless your project is already open-source) that recreates the issue, because the solution depends a lot on what the remoting code needs. I'll email you my example proxy project separately, as attachments often get removed from the mailing list - to build and deploy it use: "mvn clean install pax:provision" HTH So, according to your scenario, A should be able to create a proxy object > with interfaces ObjectManagement (from A) and clazz (from B). > Running the code, it does actually appear that this works: I do get an > object returned from the call to the factory in B (I can see it in Eclipse's > debugger, including an InvocationHandler instance that looks ok): > > Song s = (Song) ObjectFactory.getObject(Song.class, true); > > However, as soon as I try to invoke methods on the object s, I get > exceptions, for example: > > Song s = (Song) ObjectFactory.getObject(Song.class, true); if(s == null) { > > System.err.println("!!! NULL"); > > } System.out.println("s: " + s.toString()); > > ...the code creates the object s, it DOESN'T print "!!!NULL" but as soon as > it gets to s.toString() (and I've tried this with other methods declared in > Song too) I get: > > java.lang.reflect.UndeclaredThrowableException at > $Proxy5.toString(Unknown Source) at > com.qualcomm.zoom.itunes.LibraryHandler.endElement(LibraryHandler.java:7 7) > Caused by: java.lang.ClassNotFoundException: com.qualcomm.zoom.itunes.Song > at java.lang.ClassLoader.findClass(ClassLoader.java:413) at > java.lang.ClassLoader.loadClass(ClassLoader.java:316) at > java.lang.ClassLoader.loadClass(ClassLoader.java:251) at > org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal( BundleLoader.java:429) > at > org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLo ader.java:369) > at > org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLo ader.java:357) > at > org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(Defau ltClassLoader.java:83) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at > java.lang.ClassLoader.loadClassInternal(ClassLoader.java:374) at > java.lang.Class.forName0(Native Method) at > java.lang.Class.forName(Class.java:164) at > com.qualcomm.pf.p2.remoting.Invoker.invoke(Invoker.java:145) > > This looks like its the InvocationHandler that can't see the class > declaration but that's also in the package exported by A, so I'm confused?! > -- Cheers, Stuart
