[
https://issues.apache.org/jira/browse/WICKET-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512079
]
Matt Welch commented on WICKET-749:
-----------------------------------
I've checked multiple times to be sure, and yes, I believe that there is only
one copy of the classes that they aren't included in any jars in the
container's classpath.
I'm not sure how to check whether or not there is more than one
ReloadingClassLoader created. I do know that when the ClassCastException
occurs, the conflicting classloaders are ReloadingClassLoader vs
org.mortbay.jetty.webapp.WebappClassLoader and not two different
ReloadingClassLoader's.
> ClassCastException when using ReloadingWicketFilter
> ---------------------------------------------------
>
> Key: WICKET-749
> URL: https://issues.apache.org/jira/browse/WICKET-749
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.3.0-beta2
> Environment: OS: Ubuntu Linux
> JDK: 1.5.0_11
> COntainer: Jetty via Maven (mvn jetty:run)
> Reporter: Matt Welch
> Priority: Minor
> Attachments: reloading.zip
>
>
> Reference Threads:
> http://www.nabble.com/Has-something-changed-in-markup-inheritance--tf3963374.html
> http://www.nabble.com/Classcastexception-and-getSession-tf3979399.html
> In summary, in certain situations, classes that should be loaded by the
> ReloadingClassLoader are being loaded by the container's normal classloader.
> While this happens in several situations, the most obvious and repeatable is
> when using the browser's back button. I will attach a small app that
> demonstrates this issue after submitting this bug.
> The steps needed to recreate this issue int he demo app are actually quite
> odd, so this may seem like a fringe issue, however in our real app, the
> situations comes up much easier and with much more frequency.
> Steps:
> 1) Unzip the attached file.
> 2) Assuming Maven is installed, run "mvn jetty:run" inside the project
> directory.
> 3) Use your browser to go to http://127.0.0.1:8080/app
> 4) Click "Second Link"
> 5) Use your browser back functionality and then click "Second Link" again.
> Everything should work fine.
> 6) You should now be be on a page with the words "Second changed10". If not,
> click "Second Link" to get there. Use the browser to refresh that page.
> 7) Refreshing should have caused a "Page Expired" error. That's ok, that
> isn't the issue. Click the browser back button to go back to the first page.
> 8) Click "Second Link" again. This should generate the ClassCastException.
> If you disable the Reloading filter or if you comment out the include/exclude
> lines in the included FusionReloadingWicketFilters you can go through the
> same steps and not generate a ClassCastError.
> As I mentioned above. This may seem like a very fringe case with all the the
> refreshing and back buttons, but that just because that's the first and most
> reliable way I found to recreate this issue in this tiny demo app. The issue
> occurs under all kinds of situations in my real app including almost always
> after I modify a java file and recompile it which is the primary use case for
> the ReloadingClassloader.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
