RE: MarkupResourceStream and classloading
nick, have you tried asking on pax wicket mailing list? those guys use wicket with osgi all the time. perhaps they have a clean solution. We have had numerous issues with this. We have a working solution, but IMO not a clean one. Actually, opinion is probably too strong a word, since I have not yet been able to fully investigate the issue. However, my feeling is that it will be impossible to find a clean or ideal solution in the OSGi world given the way Wicket classloading works, as you described in your original post. It would be nice if somebody from the OSGi world could sit down and redesign the serialization stuff with the Wicket team, but I doubt that will happen, since OSGi is only used by a small number of Wicket users. Alternatively, may take a look at OsgiClassResolver.java in the welo project which is hosted at google code. OsgiClassResolver.java is an implementation (improvement needed) of IClassResolver to resolve classes that are stored in osgi bundles. I tried googling this, but did not fine a welo project. Can you provide us with a link? Cheers, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MarkupResourceStream and classloading
welo.googlecode.com should do it i believe -igor On Tue, Jun 24, 2008 at 3:48 PM, David Leangen [EMAIL PROTECTED] wrote: nick, have you tried asking on pax wicket mailing list? those guys use wicket with osgi all the time. perhaps they have a clean solution. We have had numerous issues with this. We have a working solution, but IMO not a clean one. Actually, opinion is probably too strong a word, since I have not yet been able to fully investigate the issue. However, my feeling is that it will be impossible to find a clean or ideal solution in the OSGi world given the way Wicket classloading works, as you described in your original post. It would be nice if somebody from the OSGi world could sit down and redesign the serialization stuff with the Wicket team, but I doubt that will happen, since OSGi is only used by a small number of Wicket users. Alternatively, may take a look at OsgiClassResolver.java in the welo project which is hosted at google code. OsgiClassResolver.java is an implementation (improvement needed) of IClassResolver to resolve classes that are stored in osgi bundles. I tried googling this, but did not fine a welo project. Can you provide us with a link? Cheers, David - 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: MarkupResourceStream and classloading
My take is to implement your own version of IClassResolver. Wicket shouldn't have dependency on osgi. -- View this message in context: http://www.nabble.com/MarkupResourceStream-and-classloading-tp18029801p18045590.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MarkupResourceStream and classloading
we shouldnt have a dependency, but if there is something we can improve to make this easier we would be all for it. -igor On Sat, Jun 21, 2008 at 8:34 AM, james yong [EMAIL PROTECTED] wrote: My take is to implement your own version of IClassResolver. Wicket shouldn't have dependency on osgi. -- View this message in context: http://www.nabble.com/MarkupResourceStream-and-classloading-tp18029801p18045590.html Sent from the Wicket - User mailing list archive at Nabble.com. - 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: MarkupResourceStream and classloading
nick, have you tried asking on pax wicket mailing list? those guys use wicket with osgi all the time. perhaps they have a clean solution. -igor On Fri, Jun 20, 2008 at 6:38 AM, Nick Giles [EMAIL PROTECTED] wrote: We're using Wicket within an OSGi evironment (Equinox 3.3.0), and have run into an issue with MarkupResourceStream. It is given a class the markup is associated with, but it stores that class using only its name. When accessed, it then tries to instantiate that class through Classes.resolveClass. Unfortunately, despite having our own IClassResolver, without giving in to some bad OSGi practice, it is not permissible for the required class to be visible, only the interfaces. This occurs because of the (helpful) classpath segregation that OSGi encourages, such that a bundle only imports the packages it actually needs, and is not allowed access to anything else. I have logged this as a bug (https://issues.apache.org/jira/browse/WICKET-1681), but the conclusion there was that there should be a workaround. Without either importing specific implementation packages into the affected bundle (fragile, poor practice) or allowing dynamic imports (evil hack to get around not knowing what classes you'll load, effectively drops the benefits of OSGi's classloader separation), I can't see a solution. Does anyone have any suggested solutions, or opinions on whether this should be handled by Wicket or our client code? Thanks, Nick - 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: MarkupResourceStream and classloading
Alternatively, may take a look at OsgiClassResolver.java in the welo project which is hosted at google code. OsgiClassResolver.java is an implementation (improvement needed) of IClassResolver to resolve classes that are stored in osgi bundles. igor.vaynberg wrote: nick, have you tried asking on pax wicket mailing list? those guys use wicket with osgi all the time. perhaps they have a clean solution. -igor -- View this message in context: http://www.nabble.com/MarkupResourceStream-and-classloading-tp18029801p18046534.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
