Uh, ok... I just deleted a chunk off this email then...
Anyways, take a look at the Spring OSGi project (I know I know... it was renamed... but you get it...) It has excellent features for OSGi. Regards, Rodrigo On Fri, Feb 22, 2008 at 3:17 AM, Mike Smoot <[EMAIL PROTECTED]> wrote: > Argh! I just got it working. The list of urls going into the > URLClassLoader was incorrect... > > Thanks for your patience! > > Mike > > On Thu, Feb 21, 2008 at 7:11 PM, Mike Smoot <[EMAIL PROTECTED]> wrote: > > > > > > > On Thu, Feb 21, 2008 at 7:01 PM, Rodrigo Madera < > [EMAIL PROTECTED]> > > wrote: > > > > > Classpaths and OSGi spell tricky when on the same sentence. > > > > > > > Indeed! :) > > > > > > > > > > How do you *search *for classes in your class loading mechanism? > > > > > > Using a list of urls pointing to the plugin jars, we create a > > URLClassLoader. As I understand things, this adds all classes in the > jars to > > the search path for that ClassLoader. Once we've got the > URLClassLoader, we > > open each jar, read the manifest which tells us which class we should be > > looking for, and call loadClass on that class name. > > > > > > thanks, > > Mike > > > > > > > > > > > > > > > > > Rodrigo > > > > > > On Fri, Feb 22, 2008 at 2:58 AM, Mike Smoot <[EMAIL PROTECTED]> wrote: > > > > > > > I'm not sure I understand the question, but once we get a Class > object > > > > from > > > > the ClassLoader given a name, we call newInstance() on it. Then > it's > > > up > > > > to > > > > the plugin to do it's thing. > > > > > > > > Or are you asking how we get the ClassLoader in the first place? We > > > do > > > > that > > > > by creating a URLClassLoader with a list of urls that point to the > > > plugin > > > > jar files. > > > > > > > > Or are you asking something else? > > > > > > > > thanks, > > > > Mike > > > > > > > > On Thu, Feb 21, 2008 at 6:45 PM, Rodrigo Madera < > > > [EMAIL PROTECTED]> > > > > wrote: > > > > > > > > > What algorithm does your class loading use? > > > > > > > > > > Regards, > > > > > Rodrigo > > > > > > > > > > On Fri, Feb 22, 2008 at 2:40 AM, Mike Smoot <[EMAIL PROTECTED]> > > > > wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > I'm working on migrating an existing swing application ( > > > > > > http://cytoscape.org) > > > > > > to OSGi using Felix. With the help of bnd, I've gotten > everything > > > > > running > > > > > > about how it should, with the exception of our legacy plugin > > > > mechanism. > > > > > > The > > > > > > way the old plugin mechanism works is that a plugin jar file > (but > > > not > > > > a > > > > > > bundle) is read and we then call ClassLoader.loadClass() on a > > > class > > > > > found > > > > > > in > > > > > > the jar file. The problem is that with Felix I get a > > > > > NoClassDefFoundError > > > > > > when I try to load the class. I'm assuming this is because > none > > > of > > > > the > > > > > > packages defined in the plugin jar are found by Felix since the > > > plugin > > > > > > jars > > > > > > aren't bundles or loaded as such. > > > > > > > > > > > > Now, I've managed to work around this problem in two cases. > First > > > is > > > > > > using > > > > > > Equinox, which I'm not terribly keen on using. Second is by > > > running > > > > bnd > > > > > > on > > > > > > each plugin jar, loading them as bundles, jumping through a few > > > hoops > > > > to > > > > > > get > > > > > > the correct ClassLoader, and then loading the class. The > problem > > > with > > > > > the > > > > > > second approach is that I have to wrap all plugins before > anything > > > > will > > > > > > work. I'd very much like to avoid this requirement (for now) > > > because > > > > > this > > > > > > will only work with plugins that I have and not those developed > by > > > > > users. > > > > > > > > > > > > Can anyone provide any guidance on loading classes that aren't > > > part of > > > > > > bundles? Is this possible with Felix? I apologize if this is a > > > bit > > > > > > vague, > > > > > > but I'm still very new to OSGi. > > > > > > > > > > > > thanks, > > > > > > Mike > > > > > > > > > > > > -- > > > > > > ____________________________________________________________ > > > > > > Michael Smoot, Ph.D. Bioengineering Department > > > > > > tel: 858-822-4756 University of California San Diego > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > ____________________________________________________________ > > > > Michael Smoot, Ph.D. Bioengineering Department > > > > tel: 858-822-4756 University of California San Diego > > > > > > > > > > > > > > > -- > > ____________________________________________________________ > > Michael Smoot, Ph.D. Bioengineering Department > > tel: 858-822-4756 University of California San Diego > > > > > > -- > ____________________________________________________________ > Michael Smoot, Ph.D. Bioengineering Department > tel: 858-822-4756 University of California San Diego >
