Author: jbq
Date: Fri Jul 13 14:20:28 2007
New Revision: 556150
URL: http://svn.apache.org/viewvc?view=rev&rev=556150
Log:
WICKET-749 ClassCastException when using ReloadingWicketFilter
Session must be excluded from the reloading filter
Modified:
incubator/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/application/ReloadingClassLoader.java
incubator/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/ReloadingWicketFilter.java
Modified:
incubator/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/application/ReloadingClassLoader.java
URL:
http://svn.apache.org/viewvc/incubator/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/application/ReloadingClassLoader.java?view=diff&rev=556150&r1=556149&r2=556150
==============================================================================
---
incubator/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/application/ReloadingClassLoader.java
(original)
+++
incubator/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/application/ReloadingClassLoader.java
Fri Jul 13 14:20:28 2007
@@ -321,8 +321,9 @@
{
listener.onChange();
}
- finally
+ catch (Exception e)
{
+ log.error("Could not
notify listener", e);
// If an error occurs
when the listener is notified,
// remove the watched
object to avoid rethrowing the
// exception at next
check
Modified:
incubator/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/ReloadingWicketFilter.java
URL:
http://svn.apache.org/viewvc/incubator/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/ReloadingWicketFilter.java?view=diff&rev=556150&r1=556149&r2=556150
==============================================================================
---
incubator/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/ReloadingWicketFilter.java
(original)
+++
incubator/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/ReloadingWicketFilter.java
Fri Jul 13 14:20:28 2007
@@ -16,18 +16,22 @@
*/
package org.apache.wicket.protocol.http;
+import java.net.URL;
+
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
+import org.apache.wicket.Session;
import org.apache.wicket.application.ReloadingClassLoader;
import org.apache.wicket.util.listener.IChangeListener;
/**
- * Custom WicketFilter that reloads the web applications when classes are
- * modified. In order to reload your own classes, use include and exclude
- * patterns using wildcards. And in web.xml, point to your custom reloading
- * wicket filter instead of the original wicket filter.
+ * Custom [EMAIL PROTECTED] WicketFilter} that reloads the web applications
when classes
+ * are modified. In order to monitor changes to your own classes, subclass
+ * [EMAIL PROTECTED] ReloadingWicketFilter} and use include and exclude
patterns using
+ * wildcards. And in web.xml, point to your custom [EMAIL PROTECTED]
ReloadingWicketFilter}
+ * instead of the original [EMAIL PROTECTED] WicketFilter}.
*
* <p>
* The built-in patterns are:
@@ -55,19 +59,44 @@
* </pre>
*
* <p>
- * <b>Note. </b> The order of including and excluding patterns is significant.
- * </p>
+ * It is also possible to add an extra URL to watch for changes using
+ * <tt>ReloadingClassLoader.addLocation()</tt> . By default, all the URLs
+ * returned by the parent class loader (ie all [EMAIL PROTECTED] URL} returned
by
+ * [EMAIL PROTECTED] ClassLoader#getResources(String)} with empty [EMAIL
PROTECTED] String}) are
+ * registered.
+ * </p>
+ * <hr>
+ * <p>
+ * <b>Important. </b> It can be quite tricky to setup the reloading mechanism
+ * correctly. Here are the general guidelines:
+ * </p>
+ * <ul>
+ * <li>The order of include and exclude patterns is significant, the patterns
+ * are processed sequentially in the order they are defined</li>
+ * <li>Don't forget that inner classes are named after YourClass$1, so take
+ * that into account when setting up the patterns, eg include
+ * <tt>YourClass*</tt>, not just <tt>YourClass</tt></li>
+ * <li>To enable back-button support for the reloading mechanism, be sure to
+ * put <tt>Objects.setObjectStreamFactory(new
WicketObjectStreamFactory());</tt>
+ * in your application's [EMAIL PROTECTED] WebApplication#init()} method.
<b>Native JDK
+ * object serialization will break the reloading mechanism when navigating in
+ * the browser's history.</b></li>
+ * <li>It is advisable to <b>exclude</b> subclasses of [EMAIL PROTECTED]
Session} from
+ * the the reloading classloader, because this is the only object that remains
+ * across application restarts</li>
+ * </ul>
*
* <p>
- * Be sure to carefully read the following information if you also use Spring:
+ * <b>Be sure to carefully read the following information if you also use
+ * Spring:</b>
* </p>
*
* <p>
* When using Spring, the application must not be a Spring bean itself,
* otherwise the reloading mechanism won't be able to reload the application.
In
* particular, make sure <b>not</b> to use
- * org.apache.wicket.spring.SpringWebApplicationFactory in web.xml. To inject
- * dependencies in your application, use SpringComponentInjector or
+ * org.apache.wicket.spring.SpringWebApplicationFactory in web.xml. If you
+ * really need to inject dependencies in your application, use
* DefaultListableBeanFactory.autowireBeanProperties() in the init() method.
* </p>
*
@@ -76,9 +105,9 @@
* managers, you will get <tt>ClassCastException</tt> if a given class is
* loaded two times, one time by the normal classloader, and another time by
the
* reloading classloader. You need to ensure that your Spring beans are
properly
- * excluded from the reloading class loader and only keep the Wicket components
- * included. When getting a cryptic error with regard to class loading, class
- * instantiation or class comparison, first <b>disable the reloading class
+ * excluded from the reloading class loader and that only the Wicket components
+ * are included. When getting a cryptic error with regard to class loading,
+ * class instantiation or class comparison, first <b>disable the reloading
class
* loader</b> to rule out the possibility of a classloader conflict. Please
* keep in mind that two classes are equal if and only if they have the same
* name <b>and are loaded in the same classloader</b>. Same goes for errors
@@ -86,22 +115,6 @@
* better be safe and disable the reloading feature.
* </p>
*
- *
- * <p>
- * It is also possible to add an extra URL to watch for changes using
- * <tt>ReloadingClassLoader.addLocation()</tt> . By default, all the URL
- * returned by the provided class loader are registered.
- * </p>
- *
- * <p>
- * <b>Important. </b> To enable back-button support for the reloading
mechanism,
- * be sure to put
- * <tt>Objects.setObjectStreamFactory(new WicketObjectStreamFactory());</tt>
- * in your application's [EMAIL PROTECTED] WebApplication#init()} method.
<b>Native JDK
- * object serialization will break the reloading mechanism when navigating in
- * the browser's history.</b>
- * </p>
- *
* @see WicketFilter
*
* @author <a href="mailto:[EMAIL PROTECTED]">Jean-Baptiste Quenot</a>
@@ -136,6 +149,12 @@
{
public void onChange()
{
+ /*
+ * Create a new classloader, as there is no way
to clear a
+ * ClassLoader's cache. This supposes that we
don't share
+ * objects across application instances, this
is almost true,
+ * except for Wicket's Session object.
+ */
reloadingClassLoader = new
ReloadingClassLoader(getClass().getClassLoader());
try
{
