[
https://issues.apache.org/jira/browse/WICKET-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Vaynberg resolved WICKET-1681.
-----------------------------------
Resolution: Won't Fix
Assignee: Igor Vaynberg
we prefer not to hold on to the actual Class instance anywhere in the code. The
reason for this is that it causes web application reloading issues with
classloaders since there is a hard reference to Class.
what we do all over our internal code is to either keep a WeakReference<Class>
or just the class name
we do understand that class resolution can be a problem in environments like
OSGi, and for that we have a special class resolver facility. we try not to
resolve the class by simply doing Class.forName(name), instead if you take a
look at markupresourcestream.getMarkupClass() you will see that it delegates
class loading to Classes.resolveClass() which in turn delegates it to
IClassResolver implmenetation installed in application settings.
the default implementation of IClassResolver uses thread's context class loader
to load the class, which obviously will not work in OSGi. so, what this means
for you is that you will most likely have to implement and install your own
IClassResolver that can load classes using OSGi's class loader.
if there are any further questions, or if for some reason this is not going to
work for you please open a discussion on the mailing list.
> MarkupResourceStream unexpectedly loads markup class
> ----------------------------------------------------
>
> Key: WICKET-1681
> URL: https://issues.apache.org/jira/browse/WICKET-1681
> Project: Wicket
> Issue Type: Bug
> Affects Versions: 1.3.3
> Environment: OSGi / Eclipse 3.3.0 / Java 1.6.0
> Reporter: Nick Giles
> Assignee: Igor Vaynberg
>
> The getMarkupClass method in MarkupResourceStream tries to load the markup
> class from its name. In some classloading environments, notably OSGi in our
> case, the base class may not be accessible, only the relevant interfaces or
> superclass. This was actually discovered because InheritedMarkupMarkupLoader
> was throwing a null pointer from the checkForMarkupInheritance method when
> looking for the base markup, so tracing the issue wasn't straightforward
> either.
> Since the actual Class object is passed in to the constructor of the stream,
> a reference to that could be stored, and then classloading could be avoided
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
