[jira] Resolved: (WICKET-1681) MarkupResourceStream unexpectedly loads markup class

["Igor Vaynberg (JIRA)" <ji...@apache.org>]

     [ 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.