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.schoen...@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
