> 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]
