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]
