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]
