Why is the thread context classloader used in DefaultClassResolver?

[Thorsten Schöning <ts...@am-soft.de>]

Hi all,

I'm using Wicket as render engine for HTML-reports and am therefore
integrating it into various different apps running under different
circumstances. One of those is a web service implemented pretty old
school using Axis2 running in a Tomcat.

Rendering fails in that context because Wicket can't properly resolve
markup. Root cause is that "DefaultClassResolver" uses the thread
context classloader by default, which seems to be the one of the
Tomcat, which itself only knows about Axis2, but not the classes Axis2
has loaded as part if its own services with its own classloader. So in
the end, resolving some class in Wicket simply fails.

This can be worked around successfully by implementing
"AbstractClassResolver" and simply not using the TCCL anymore, but the
loader which actually loaded my Wicket-app instead.

https://ci.apache.org/projects/wicket/apidocs/8.x/org/apache/wicket/settings/ApplicationSettings.html#setClassResolver-org.apache.wicket.application.IClassResolver-

Why is the TCCL the default anyway? Shouldn't the best default always
be using the loader associated with the app? Shouldn't if anyone else
needs something else that be the reason for a custom implementation?

Using the TCCL has been introduced in the following commit:

https://github.com/apache/wicket/commit/5df9b6e1c37496b39196ce5fc76ea67a32e9633b#diff-79cf4f749b2b3d37ff0c363a63aa2c13R57

The simply seems to pre-date the possibility to use a custom
classloader as easily as currently.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning       E-Mail: Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/

Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow