Re: OSGi and class loading issues solution proposal
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
Re: OSGi and class loading issues solution proposal
On Thu, Jul 3, 2008 at 8:24 PM, Daniel Stoch [EMAIL PROTECTED] wrote: But there is a one assumption, that bundle with Wicket classes (you probably have a Wicket bundled somehow in your app, don't you? :)), should have a dynamic import for all classes which can be located in many different bundles: DynamicImport-Package: * I don't think you should use DynamicImport-Package. In pax wicket, we creates a delegating class resolver that tracks IClassResolver services. Proposal 1 (change actual method behavior): Modify resolveClass() method in DefaultClassResolver as I wrote above -1. This can be easily work around by setting the class resolver. 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 ;)): +1 2. LazyInitProxyFactory - Spring integration The first minor thing is a call Class.forName(type); in ProxyReplacement. Why not use IClassResolver here (and maybe in other places in Wicket)? +1 Proposal 2 (do not change actual method behavior): Make LazyInitProxyFactory customizable to allows using a different method to create proxy inside OSGi. +1 Regards, Edward Yakop - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OSGi and class loading issues solution proposal
On Thu, Jul 3, 2008 at 2:53 PM, Edward Yakop [EMAIL PROTECTED] wrote: On Thu, Jul 3, 2008 at 8:24 PM, Daniel Stoch [EMAIL PROTECTED] wrote: But there is a one assumption, that bundle with Wicket classes (you probably have a Wicket bundled somehow in your app, don't you? :)), should have a dynamic import for all classes which can be located in many different bundles: DynamicImport-Package: * I don't think you should use DynamicImport-Package. I know it is not a very good practise, but Wicket jars/bundles already have DynamicImport-Package: * ;). And sometimes is hard to avoid this. In pax wicket, we creates a delegating class resolver that tracks IClassResolver services. So each bundle must export its IClassResolver service? What about bundles independent from Wicket? -- Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OSGi and class loading issues solution proposal
On Thu, Jul 3, 2008 at 9:27 PM, Daniel Stoch [EMAIL PROTECTED] wrote: On Thu, Jul 3, 2008 at 2:53 PM, Edward Yakop [EMAIL PROTECTED] wrote: On Thu, Jul 3, 2008 at 8:24 PM, Daniel Stoch [EMAIL PROTECTED] wrote: But there is a one assumption, that bundle with Wicket classes (you probably have a Wicket bundled somehow in your app, don't you? :)), should have a dynamic import for all classes which can be located in many different bundles: DynamicImport-Package: * I don't think you should use DynamicImport-Package. I know it is not a very good practise, but Wicket jars/bundles already have DynamicImport-Package: * ;). And sometimes is hard to avoid this. Isn't this in general depends on the IClassResolver of wicket application? If IClassResolver is set and the rest of wicket bundles uses Application class resolver, it would be irrelevant whether the other wicket jars/bundles has DynamicImport-Package declaration. So each bundle must export its IClassResolver service? What about bundles independent from Wicket? It doesn't have to be for each bundle. As long as you have a bundle / many bundles that have sufficient ImportPackage and there's no private packages caught in the page serialization. We would be able to minimize this requirement to application wicket components and business layer bundles. Regards, Edward Yakop - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OSGi and class loading issues solution proposal
On Thu, Jul 3, 2008 at 3:35 PM, Edward Yakop [EMAIL PROTECTED] wrote: On Thu, Jul 3, 2008 at 9:27 PM, Daniel Stoch [EMAIL PROTECTED] wrote: On Thu, Jul 3, 2008 at 2:53 PM, Edward Yakop [EMAIL PROTECTED] wrote: On Thu, Jul 3, 2008 at 8:24 PM, Daniel Stoch [EMAIL PROTECTED] wrote: But there is a one assumption, that bundle with Wicket classes (you probably have a Wicket bundled somehow in your app, don't you? :)), should have a dynamic import for all classes which can be located in many different bundles: DynamicImport-Package: * I don't think you should use DynamicImport-Package. I know it is not a very good practise, but Wicket jars/bundles already have DynamicImport-Package: * ;). And sometimes is hard to avoid this. Isn't this in general depends on the IClassResolver of wicket application? If IClassResolver is set and the rest of wicket bundles uses Application class resolver, it would be irrelevant whether the other wicket jars/bundles has DynamicImport-Package declaration. Ok, but what about other (non-wicket) mechanisms, which do not use IClassResolver (eg. creating proxy by Proxy.newProxyInstance(...) - it uses classloader directly)? -- Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OSGi and class loading issues solution proposal
On Thu, Jul 3, 2008 at 9:55 PM, Daniel Stoch [EMAIL PROTECTED] wrote: On Thu, Jul 3, 2008 at 3:35 PM, Edward Yakop [EMAIL PROTECTED] wrote: On Thu, Jul 3, 2008 at 9:27 PM, Daniel Stoch [EMAIL PROTECTED] wrote: On Thu, Jul 3, 2008 at 2:53 PM, Edward Yakop [EMAIL PROTECTED] wrote: On Thu, Jul 3, 2008 at 8:24 PM, Daniel Stoch [EMAIL PROTECTED] wrote: Ok, but what about other (non-wicket) mechanisms, which do not use IClassResolver (eg. creating proxy by Proxy.newProxyInstance(...) - it uses classloader directly)? I'm not too sure about this. But as last resort, I would probably passed my own implementation of ClassLoader. Regards, Edward Yakop - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OSGi and class loading issues solution proposal
why dont you guys hash all this out. since no one uses osgi from the core team we are mostly unaware of these issues but do want to support the platform. once you settle down on the changes you want to see create jira issues and we will take it from there. -igor On Thu, Jul 3, 2008 at 5:53 AM, Edward Yakop [EMAIL PROTECTED] wrote: On Thu, Jul 3, 2008 at 8:24 PM, Daniel Stoch [EMAIL PROTECTED] wrote: But there is a one assumption, that bundle with Wicket classes (you probably have a Wicket bundled somehow in your app, don't you? :)), should have a dynamic import for all classes which can be located in many different bundles: DynamicImport-Package: * I don't think you should use DynamicImport-Package. In pax wicket, we creates a delegating class resolver that tracks IClassResolver services. Proposal 1 (change actual method behavior): Modify resolveClass() method in DefaultClassResolver as I wrote above -1. This can be easily work around by setting the class resolver. 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 ;)): +1 2. LazyInitProxyFactory - Spring integration The first minor thing is a call Class.forName(type); in ProxyReplacement. Why not use IClassResolver here (and maybe in other places in Wicket)? +1 Proposal 2 (do not change actual method behavior): Make LazyInitProxyFactory customizable to allows using a different method to create proxy inside OSGi. +1 Regards, Edward Yakop - 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]
Re: OSGi and class loading issues solution proposal
On Thu, Jul 3, 2008 at 4:28 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: why dont you guys hash all this out. since no one uses osgi from the core team we are mostly unaware of these issues but do want to support the platform. once you settle down on the changes you want to see create jira issues and we will take it from there. Ok, we'll do :). Before I'll create any JIRA issue, first I want to ask other osgi-guys what are they thinking about proposed changes. Maybe someone will have a better/other concepts (or vote for these, like Edward did). -- Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: OSGi and class loading issues solution proposal
Before I'll create any JIRA issue, first I want to ask other osgi-guys what are they thinking about proposed changes. Well, I use the OSGi/Wicket combination extensively in the form of pax-wicket. Edward is the lead developer, but we often collaborate. Personally, I think this is a great initiative. I would really like to see more OSGi compatibility in Wicket, since I always have to use my own patched versions to get things working right. As I reply to your original questions, I'll just voice a few concerns here in context that I have probably already mentioned before. Proposal 1 (change actual method behavior): Modify resolveClass() method in DefaultClassResolver as I wrote above -1 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 ;)): +1 2. LazyInitProxyFactory - Spring integration Don't use Spring, so I'll abstain from this vote. Now, I have two concerns. My assumption is that the bundle providing the components is to be used as a kind of library bundle, and that it should not need to know in advance where it will be used. If this is not your use case, then the rest of this discussion may not be relevant to you. First: classes that derive from private packages. Ideally, the importing bundle should declare the IClassResolver, since the library bundle should not need to know where it needs to be used. If you create the IClassResolver outside of the library bundle, then you will not have access to the bundle's private classes, and deserialization will fail, so I don't see any way to make that ideal way work. So, probably because of these private packages the only way to do this is to create an IClassResolver service from within the library bundle and have this service consumed by bundles that need to use the library. Consuming bundles can either just grab all implementations of the IClassResolver service, or can pick and choose them by ID. Edward has recently made an implementation of this approach in pax-wicket. So far, it seems to work very well. In this respect, this is no longer a problem per se, but I think we need to validate and document this approach, and maybe suggest it as a best practice, or pattern or whatever. The second issue is a little trickier. Since I've never actually encountered this potential problem myself, I'm only really guessing at this point. Since a given class can be provided by more than one bundle, and on top of that there can be more than one version of the given class, we need to be very careful about how we choose the source of that class. It's not enough to simply search by classname, since this may provide us with the wrong version of that class, and again deserialization will fail. Probably, we'll need to provide some kind of marker for that class in order to be able to associate it with it's source bundle. Actually, I think that Edward has already addressed this issue with his recent commits to the pax-wicket codebase, but I have not yet had a chance to review it. The only other issue, then, it what to do if the source bundle goes away between serialization and deserialization. I have no ideas here other than to make deserialization fail somehow gracefully. Regards, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
