Hi, I'm working on a project that uses Wicket and OSGi and have come across some of the same classloading issues. We don't use Spring, so I can't comment on that side of things. Some brief comments follow below:
2008/7/3 Daniel Stoch <[EMAIL PROTECTED]>: > > Proposal 1 (change actual method behavior): > Modify resolveClass() method in DefaultClassResolver as I wrote above Using the classloader that loaded the DefaultClassLoader class, and enabling dynamic imports in this bundle doesn't sound ideal to me. We have created our own Wicket bundle and we don't use dynamic imports on it. > Proposal 2 (do not change actual method behavior): > Make DefaultClassResolver extensible (remove final modifier in class > declaration) and define a new method (invent a better name for it ;)): We have implemented our own IClassResolver which delegates to Wicket's DefaultClassResolver, then performs its own steps where this doesn't succeed in loading a class. So we don't actually need the DefaultClassResolver to be extensible, nor have we needed to copy any code or patch Wicket classes. I don't mind if DefaultClassResolver is made extensible of course, but I'm not sure how much value this adds. Regarding resolution of classes for components provided by other bundles, we have implemented a simple service-based lookup of classes. This sounds a lot like the IClassResolver services in Pax Wicket that Edward describe. Some common solution for how to best do this sounds potentially very useful (a WicketOsgi subproject that provides the necessary code maybe?) And, I'm obviously strongly in favour of fixing any bits of code in Wicket that uses Class.forName() instead of using the IClassResolver mechanism! Regards, Jan
