[
https://issues.apache.org/jira/browse/WICKET-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512136
]
Jean-Baptiste Quenot edited comment on WICKET-749 at 7/12/07 8:50 AM:
----------------------------------------------------------------------
The first observation of my debug session is that there was a recent change in
how the reference to classes are kept. Previouly, eg in
BookmarkablePageRequestTarget, we were holding a Class directly, whereas now we
keep a WeakReference to the Class, since revision 548314. But after changing
BookmarkablePageRequestTarget to keep a Class directly, I can still reproduce
the problem, however the page expired goes away.
If I set Objects.setObjectStreamFactory(new WicketObjectStreamFactory()); in
FusionWebApplication.init() however I cannot reproduce the problem anymore.
was:
The first observation of my debug session is that there was a recent change in
how the reference to classes are kept. Previouly, eg in
BookmarkablePageRequestTarget, we were holding a Class directly, whereas now we
keep a WeakReference to the Class, since revision 548314. But after changing
BookmarkablePageRequestTarget to keep a Class directly, I can still reproduce
the problem.
> 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.
