[
https://issues.apache.org/jira/browse/WICKET-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512142
]
Matt Welch commented on WICKET-749:
-----------------------------------
>how can the jetty classloader then load the classes that aren't in his path??
>somehow you have to have it in your path.
Johan, thank you for taking the time to think about this issue and comment. I
really appreciate it.
I'm not sure how to answer your question, however, but I'll be the first to
admit that I don't have a terribly deep understanding of the low level
intricacies of classloaders.
When "mvn jetty:run" is executed, either maven or jetty (I'm not sure which)
prints out a classpath. Here is that classpath for the attached tiny app
(obviously localized for my own environment):
file:/home/mwelch/projects/temp/sandbox/target/classes/,
file:/home/mwelch/.m2/repository/commons-logging/commons-logging/1.1/commons-logging-1.1.jar,
file:/home/mwelch/.m2/repository/org/springframework/spring/2.0/spring-2.0.jar,
file:/home/mwelch/.m2/repository/cglib/cglib-nodep/2.1_3/cglib-nodep-2.1_3.jar,
file:/home/mwelch/.m2/repository/org/apache/wicket/wicket/1.3.0-beta2/wicket-1.3.0-beta2.jar,
file:/home/mwelch/.m2/repository/logkit/logkit/1.0.1/logkit-1.0.1.jar,
file:/home/mwelch/.m2/repository/log4j/log4j/1.2.13/log4j-1.2.13.jar,
file:/home/mwelch/.m2/repository/asm/asm/1.5.3/asm-1.5.3.jar,
file:/home/mwelch/.m2/repository/avalon-framework/avalon-framework/4.1.3/avalon-framework-4.1.3.jar,
file:/home/mwelch/.m2/repository/org/slf4j/slf4j-api/1.3.1/slf4j-api-1.3.1.jar,
file:/home/mwelch/.m2/repository/commons-collections/commons-collections/3.2/commons-collections-3.2.jar,
file:/home/mwelch/.m2/repository/org/apache/wicket/wicket-extensions/1.3.0-beta2/wicket-extensions-1.3.0-beta2.jar,
file:/home/mwelch/.m2/repository/org/apache/wicket/wicket-spring/1.3.0-beta2/wicket-spring-1.3.0-beta2.jar,
file:/home/mwelch/.m2/repository/org/apache/wicket/wicket-ioc/1.3.0-beta2/wicket-ioc-1.3.0-beta2.jar,
file:/home/mwelch/.m2/repository/org/apache/wicket/wicket-spring-annot/1.3.0-beta2/wicket-spring-annot-1.3.0-beta2.jar,
file:/home/mwelch/.m2/repository/org/slf4j/slf4j-log4j12/1.4.0/slf4j-log4j12-1.4.0.jar
The first item in the classpath points to the location of my compiled classes.
A few lines above that int the ouput I see:
[INFO] Webapp directory = /home/mwelch/projects/temp/sandbox/src/main/webapp
When I look into that webapp directory, the only thing I find is a "WEB-INF"
directory and in there only a web.xml. There is no "classes" or "lib" directory
there that might provide a second place Jetty would load things from.
The attached app is barely more than a Hello World implementation so there
isn't a lot of configuration that has been done so I'm not sure where I might
have misconfigured things. Nevertheless, I have suspected from the beginning
that an error in my setup was to blame so I'm more than willing to continue to
explore that possibility.
> 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.
