thats not for classes. Wicket doesnt have by default (there are some
solutions) a class reloader
What you see is for for the markup files (and we also do that for other
resources)

johan


On Thu, Jul 17, 2008 at 10:05 AM, <[EMAIL PROTECTED]> wrote:

> As always, excellent feedback- a HUGE thank you for your quick and
> insightful reply - much appreciated :-)
>
> Do you think the ability to switch off jar file watching would be useful?
>  I personally would only expect the classes in my project to be reloaded,
> and will probably have to implement this change for our WAS environment
> anyway.
>
> Thanks
> Mike
>
> Johan Compagner wrote:
> >
> > wicket has special support for that:
> >
> >     if (urlConnection instanceof JarURLConnection)
> >                 {
> >                     JarURLConnection jarUrlConnection =
> > (JarURLConnection)urlConnection;
> >                     URL jarFileUrl = jarUrlConnection.getJarFileURL();
> >                     URLConnection jarFileConnection =
> > jarFileUrl.openConnection();
> >                     try
> >                     {
> >                         lastModified =
> > jarFileConnection.getLastModified();
> >                     }
> >                     finally
> >                     {
> >                         jarFileConnection.getInputStream().close();
> >                     }
> >                 }
> >                 else
> >                 {
> >                     close = true;
> >                     lastModified = urlConnection.getLastModified();
> >                 }
> >
> > and then in the finally:
> >
> > if (urlConnection != null)
> >                 {
> >                     if (urlConnection instanceof HttpURLConnection)
> >                     {
> >                         ((HttpURLConnection)urlConnection).disconnect();
> >                     }
> >                     else if (close)
> >                     {
> >                         try
> >                         {
> >                             urlConnection.getInputStream().close(); <<
> 293
> >                         }
> >                         catch (Exception ex)
> >                         {
> >                             // ignore
> >                         }
> >                     }
> >                 }
> >
> >
> > thats inside
> > UrlResourceStream.lastModifiedTime(UrlResourceStream.java:293)
> >
> > So it seems that websphere has its own jar/zip handler thats not a
> > JarURLConnection
> >
> > and if that is the case we ask really for the entry the last modified
> > instead of just of the jar file..
> > That means that it constantly must open it and so on. And now we are
> > encountering a problem  with all those URLConnections
> > there is not good way to close one... So we try to do it with
> > getInputStream().close()
> >
> > johan
> >
> >
> >
> >
> > On Wed, Jul 16, 2008 at 2:34 PM, RUMikeP <[EMAIL PROTECTED]> wrote:
> >
> >>
> >> Hi
> >>
> >> After starting my local Webpshere Application Server (6.1.0.15),
> running
> >> my
> >> wicket application (1.3.4) in development mode, the ModificationWatcher
> >> appears to devour memory, until eventually I get out of memory
> exceptions
> >> (when my latest exception occured, my wicket instance was using 1.7GB
> >> (less
> >> than 10 pages visited).
> >>
> >> If I run in deployment mode, the memory use is stable as it does not
> >> invoke
> >> the ModificationWatcher.
> >>
> >> Anyone else seeing this behaviour on Websphere or have any guesses?
>  Will
> >> have a closer look myself as soon as I get a chance, but hoping that
> >> someone
> >> else has seen this before ...
> >>
> >> [7/16/08 12:33:33:465 CAT] 00000046 Task          E
> >> org.apache.wicket.util.thread.Task$1 run Task ModificationWatcher
> >> terminated
> >>                                 java.lang.OutOfMemoryError:
> >> ZIP004:OutOfMemoryError, MEM_ERROR in inflateInit2
> >>        at java.util.zip.Inflater.init(Native Method)
> >>        at java.util.zip.Inflater.<init>(Inflater.java:105)
> >>        at java.util.zip.ZipFile.getInflater(ZipFile.java:416)
> >>        at java.util.zip.ZipFile.getInputStream(ZipFile.java:359)
> >>        at java.util.zip.ZipFile.getInputStream(ZipFile.java:324)
> >>        at
> >>
> >>
> com.ibm.ws.classloader.Handler$ClassLoaderURLConnection.getInputStream(Handler.java:288)
> >>        at
> >>
> >>
> org.apache.wicket.util.resource.UrlResourceStream.lastModifiedTime(UrlResourceStream.java:293)
> >>        at
> >>
> >>
> org.apache.wicket.markup.MarkupResourceStream.lastModifiedTime(MarkupResourceStream.java:144)
> >>        at
> >>
> >>
> org.apache.wicket.util.watch.ModificationWatcher$1.run(ModificationWatcher.java:176)
> >>        at org.apache.wicket.util.thread.Task$1.run(Task.java:115)
> >>        at java.lang.Thread.run(Thread.java:810)
> >>
> >> Notes: 1.  the only zips/jars are the wicket-related jars in the
> >> web-inf/lib
> >> dir
> >>          2.  it is not possible to deploy my app on Tomcat, but the
> >> wicket-examples deployed on tomcat in development mode does not create
> >> the
> >> same issue.
> >>
> >> Thanks
> >> Mike
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/WEBSPHERE-%3A-ModificationWatcher-OutOfMemory-errors-tp18486458p18486458.html
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> >
> Quoted from:
>
> http://www.nabble.com/WEBSPHERE-%3A-ModificationWatcher-OutOfMemory-errors-tp18486458p18489140.html
>
>

Reply via email to