[
https://issues.apache.org/jira/browse/WICKET-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512162
]
Matt Welch commented on WICKET-749:
-----------------------------------
>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.
Thank for looking into this. I see the same thing you do. Putting
Objects.setObjectStreamFactory(new WicketObjectStreamFactory()); int he
WebApplication's init() method does prevent the ClassCastException from
appearing in the steps I put forth earlier, however, unfortunately this causes
the second problem I mentioned previously to rear it's head: one can no longer
reload the page or application classes correctly after making a changes to
them. Try these steps with the Objects.setObjectStreamFactory(new
WicketObjectStreamFactory()); in place:
1) Start the webapp with "mvn jetty:run".
2) Navigate to http://127.0.0.1:8080/app
3) You should see the "hello" page. Refresh it once or twice to confirm that
refreshing works as expected. It should.
4) Make a trivial change Hello.java such as adding a new empty line and
recompile.
5) Refresh the page once again; perhaps twice. You should see the same
ClassCastException exception. However, this time it appears to be caused by a
conflict between two different instances of ReloadingClassLoader instead of a
conflict between a ReloadingClassLoader and the Jetty classloader as was the
case previously.
> 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
> Assignee: Jean-Baptiste Quenot
> Priority: Minor
> Fix For: 1.3.0-beta3
>
> 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.
