You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Tom Eugelink <tb...@tbee.org> on 2012/04/06 16:48:11 UTC

reloading of HTML and classes

I've been fighting this for the past two days, but I'm not succeeding. I'm using Wicket 1.5.5 on GlassFish 3.1.2 and that runs without a problem. I have configured

<filter-class>org.apache.wicket.protocol.http.ReloadingWicketFilter</filter-class>

to reload the classes, but that is not working. The only way to reload the class file is by using JRebel.

Also Wicket reports that it runs in DEVELOPMENT mode, but it is not reloading the HTML files. In an attempting to resolve that I explicitely configured

     getResourceSettings().setDefaultCacheDuration(Duration.ONE_SECOND);

but that does not make a difference. The only way I can get it to work somewhat, is to add my own ResourceFinder directly on the src folder:

         getResourceSettings().setResourceFinder(new IResourceFinder()
         {
             @Override
             public IResourceStream find(Class<?> clazz, String pathname)
             {
                 File f = new File("C:/Documents and Settings/User/My Documents/s2m/sources/components/service/src/main/java/" + pathname);
                 if (f.exists())
                 {
                     return new FileResourceStream( f );
                 }
                 return null;
             }
         });
         getResourceSettings().setUseDefaultOnMissingResource(true);

But still the source are not reloaded reliably. I figure if the cache expires, a new call to the resource finder should be done, correct?

Is there any debugging of these autoreload features, so I can see what Wicket is doing?

Tom





---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: reloading of HTML and classes

Posted by Tom Eugelink <tb...@tbee.org>.
Eclipse in debug mode indeed allows for some limited reloading of classes, but JRebel does a good job and my explicit HTML code seems to work as well. I still need to test it thoroughly. But none of Wicket's regular tools seem to work and that amazes me.

Tom



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: reloading of HTML and classes

Posted by armhold <ar...@gmail.com>.
I don't use ReloadingWicketFilter, but have pretty good luck reloading
changed HTML and classes by simply running in debug mode in my
IDE. With -Dwicket.configuration=development and running under the
debugger, I can redeploy changes with "reload changed classes"
(command+F9 in Intellij on OSX; I assume there's something similar for
Eclipse.)

It doesn't work if you've changed something deep in the app's startup
(like say WicketApplication), but covers about 90% of my needs.

--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/reloading-of-HTML-and-classes-tp4537542p4539448.html
Sent from the Users forum mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: reloading of HTML and classes

Posted by Tom Eugelink <tb...@tbee.org>.
Aha! This is very interesting. I have the same problems and wrote my own resource finder, which works ok now. But this would explain what the original problem is! Should be a fairly easy problem to fix, though.

Tom


On 2012-04-20 18:24, Andrew Geery wrote:
> An issue I ran into with having Wicket reload the html files in development
> mode is that it doesn't seem to work if the path to the html files has
> spaces in it.  For example, running under Eclipse with the workspace in
> c:\Documents and Settings\... html reloading did not work.  Taking the
> exact same configuration but putting the workspace directly on the c:\
> drive (e.g., c:\workspace), the htm reloading works perfectly.
>
> Hope that helps.
> Andrew
>



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: reloading of HTML and classes

Posted by Christoph Leiter <ma...@christophleiter.com>.
You are right, I was able to reproduce it:
https://issues.apache.org/jira/browse/WICKET-4509


Christoph

On 20.04.2012 18:24, Andrew Geery wrote:
> An issue I ran into with having Wicket reload the html files in development
> mode is that it doesn't seem to work if the path to the html files has
> spaces in it.  For example, running under Eclipse with the workspace in
> c:\Documents and Settings\... html reloading did not work.  Taking the
> exact same configuration but putting the workspace directly on the c:\
> drive (e.g., c:\workspace), the htm reloading works perfectly.
>
> Hope that helps.
> Andrew
>
> On Tue, Apr 10, 2012 at 2:45 AM, Martin Grigorov<mg...@apache.org>wrote:
>
>> On Sun, Apr 8, 2012 at 5:38 AM, Bernard<bh...@gmail.com>  wrote:
>>> Hi,
>>>
>>> The HTML part is covered if your IDE copies HTML files to the
>>> deployment directory when you save them. Wicket will then pick up this
>>> change and reload the corresponding pages. This works for existing
>>> markup but not for new markup that was missing.
>>
>>
>> https://github.com/wicketstuff/core/tree/master/jdk-1.7-parent/wicketstuff-wicket7
>> provides an extension of Wicket's default
>> ModificationWatcher that uses JDK7 NIO2 WatchService. This should help
>> for this problem.
>>
>>>
>>> The Java classes part can only be handled with debugging, JRebel or a
>>> complete re-deployment. There is no hot-deployment of individual
>>> classes in GlassFish (I don't know whether any other server supports
>>> this). However GlassFish has session preservation so the re-deploy
>>> process is seamless. To further speed up the deployment, one can copy
>>> most libraries (including Wicket) into the GlassFish domain's lib dir
>>> instead of copying them on every deployment.
>>>
>>> The "Deploy on Save" feature is only useful for mini applications - it
>>> is too slow.
>>>
>>> Bernard
>>>
>>>
>>> On Fri, 06 Apr 2012 16:48:11 +0200, you wrote:
>>>
>>>>
>>>> I've been fighting this for the past two days, but I'm not succeeding.
>> I'm using Wicket 1.5.5 on GlassFish 3.1.2 and that runs without a problem.
>> I have configured
>>>>
>>
>>>> <filter-class>org.apache.wicket.protocol.http.ReloadingWicketFilter</filter-class>
>>>>
>>>> to reload the classes, but that is not working. The only way to reload
>> the class file is by using JRebel.
>>>>
>>>> Also Wicket reports that it runs in DEVELOPMENT mode, but it is not
>> reloading the HTML files. In an attempting to resolve that I explicitely
>> configured
>>>>
>>>>      getResourceSettings().setDefaultCacheDuration(Duration.ONE_SECOND);
>>>>
>>>> but that does not make a difference. The only way I can get it to work
>> somewhat, is to add my own ResourceFinder directly on the src folder:
>>>>
>>>>          getResourceSettings().setResourceFinder(new IResourceFinder()
>>>>          {
>>>>              @Override
>>>>              public IResourceStream find(Class<?>  clazz, String pathname)
>>>>              {
>>>>                  File f = new File("C:/Documents and Settings/User/My
>> Documents/s2m/sources/components/service/src/main/java/" + pathname);
>>>>                  if (f.exists())
>>>>                  {
>>>>                      return new FileResourceStream( f );
>>>>                  }
>>>>                  return null;
>>>>              }
>>>>          });
>>>>          getResourceSettings().setUseDefaultOnMissingResource(true);
>>>>
>>>> But still the source are not reloaded reliably. I figure if the cache
>> expires, a new call to the resource finder should be done, correct?
>>>>
>>>> Is there any debugging of these autoreload features, so I can see what
>> Wicket is doing?
>>>>
>>>> Tom
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: reloading of HTML and classes

Posted by Andrew Geery <an...@gmail.com>.
An issue I ran into with having Wicket reload the html files in development
mode is that it doesn't seem to work if the path to the html files has
spaces in it.  For example, running under Eclipse with the workspace in
c:\Documents and Settings\... html reloading did not work.  Taking the
exact same configuration but putting the workspace directly on the c:\
drive (e.g., c:\workspace), the htm reloading works perfectly.

Hope that helps.
Andrew

On Tue, Apr 10, 2012 at 2:45 AM, Martin Grigorov <mg...@apache.org>wrote:

> On Sun, Apr 8, 2012 at 5:38 AM, Bernard <bh...@gmail.com> wrote:
> > Hi,
> >
> > The HTML part is covered if your IDE copies HTML files to the
> > deployment directory when you save them. Wicket will then pick up this
> > change and reload the corresponding pages. This works for existing
> > markup but not for new markup that was missing.
>
>
> https://github.com/wicketstuff/core/tree/master/jdk-1.7-parent/wicketstuff-wicket7
> provides an extension of Wicket's default
> ModificationWatcher that uses JDK7 NIO2 WatchService. This should help
> for this problem.
>
> >
> > The Java classes part can only be handled with debugging, JRebel or a
> > complete re-deployment. There is no hot-deployment of individual
> > classes in GlassFish (I don't know whether any other server supports
> > this). However GlassFish has session preservation so the re-deploy
> > process is seamless. To further speed up the deployment, one can copy
> > most libraries (including Wicket) into the GlassFish domain's lib dir
> > instead of copying them on every deployment.
> >
> > The "Deploy on Save" feature is only useful for mini applications - it
> > is too slow.
> >
> > Bernard
> >
> >
> > On Fri, 06 Apr 2012 16:48:11 +0200, you wrote:
> >
> >>
> >>I've been fighting this for the past two days, but I'm not succeeding.
> I'm using Wicket 1.5.5 on GlassFish 3.1.2 and that runs without a problem.
> I have configured
> >>
>
> >><filter-class>org.apache.wicket.protocol.http.ReloadingWicketFilter</filter-class>
> >>
> >>to reload the classes, but that is not working. The only way to reload
> the class file is by using JRebel.
> >>
> >>Also Wicket reports that it runs in DEVELOPMENT mode, but it is not
> reloading the HTML files. In an attempting to resolve that I explicitely
> configured
> >>
> >>     getResourceSettings().setDefaultCacheDuration(Duration.ONE_SECOND);
> >>
> >>but that does not make a difference. The only way I can get it to work
> somewhat, is to add my own ResourceFinder directly on the src folder:
> >>
> >>         getResourceSettings().setResourceFinder(new IResourceFinder()
> >>         {
> >>             @Override
> >>             public IResourceStream find(Class<?> clazz, String pathname)
> >>             {
> >>                 File f = new File("C:/Documents and Settings/User/My
> Documents/s2m/sources/components/service/src/main/java/" + pathname);
> >>                 if (f.exists())
> >>                 {
> >>                     return new FileResourceStream( f );
> >>                 }
> >>                 return null;
> >>             }
> >>         });
> >>         getResourceSettings().setUseDefaultOnMissingResource(true);
> >>
> >>But still the source are not reloaded reliably. I figure if the cache
> expires, a new call to the resource finder should be done, correct?
> >>
> >>Is there any debugging of these autoreload features, so I can see what
> Wicket is doing?
> >>
> >>Tom
> >>
> >>
> >>
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: reloading of HTML and classes

Posted by Martin Grigorov <mg...@apache.org>.
On Sun, Apr 8, 2012 at 5:38 AM, Bernard <bh...@gmail.com> wrote:
> Hi,
>
> The HTML part is covered if your IDE copies HTML files to the
> deployment directory when you save them. Wicket will then pick up this
> change and reload the corresponding pages. This works for existing
> markup but not for new markup that was missing.

https://github.com/wicketstuff/core/tree/master/jdk-1.7-parent/wicketstuff-wicket7
provides an extension of Wicket's default
ModificationWatcher that uses JDK7 NIO2 WatchService. This should help
for this problem.

>
> The Java classes part can only be handled with debugging, JRebel or a
> complete re-deployment. There is no hot-deployment of individual
> classes in GlassFish (I don't know whether any other server supports
> this). However GlassFish has session preservation so the re-deploy
> process is seamless. To further speed up the deployment, one can copy
> most libraries (including Wicket) into the GlassFish domain's lib dir
> instead of copying them on every deployment.
>
> The "Deploy on Save" feature is only useful for mini applications - it
> is too slow.
>
> Bernard
>
>
> On Fri, 06 Apr 2012 16:48:11 +0200, you wrote:
>
>>
>>I've been fighting this for the past two days, but I'm not succeeding. I'm using Wicket 1.5.5 on GlassFish 3.1.2 and that runs without a problem. I have configured
>>
>><filter-class>org.apache.wicket.protocol.http.ReloadingWicketFilter</filter-class>
>>
>>to reload the classes, but that is not working. The only way to reload the class file is by using JRebel.
>>
>>Also Wicket reports that it runs in DEVELOPMENT mode, but it is not reloading the HTML files. In an attempting to resolve that I explicitely configured
>>
>>     getResourceSettings().setDefaultCacheDuration(Duration.ONE_SECOND);
>>
>>but that does not make a difference. The only way I can get it to work somewhat, is to add my own ResourceFinder directly on the src folder:
>>
>>         getResourceSettings().setResourceFinder(new IResourceFinder()
>>         {
>>             @Override
>>             public IResourceStream find(Class<?> clazz, String pathname)
>>             {
>>                 File f = new File("C:/Documents and Settings/User/My Documents/s2m/sources/components/service/src/main/java/" + pathname);
>>                 if (f.exists())
>>                 {
>>                     return new FileResourceStream( f );
>>                 }
>>                 return null;
>>             }
>>         });
>>         getResourceSettings().setUseDefaultOnMissingResource(true);
>>
>>But still the source are not reloaded reliably. I figure if the cache expires, a new call to the resource finder should be done, correct?
>>
>>Is there any debugging of these autoreload features, so I can see what Wicket is doing?
>>
>>Tom
>>
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>For additional commands, e-mail: users-help@wicket.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: reloading of HTML and classes

Posted by Bernard <bh...@gmail.com>.
Hi,

The HTML part is covered if your IDE copies HTML files to the
deployment directory when you save them. Wicket will then pick up this
change and reload the corresponding pages. This works for existing
markup but not for new markup that was missing.

The Java classes part can only be handled with debugging, JRebel or a
complete re-deployment. There is no hot-deployment of individual
classes in GlassFish (I don't know whether any other server supports
this). However GlassFish has session preservation so the re-deploy
process is seamless. To further speed up the deployment, one can copy
most libraries (including Wicket) into the GlassFish domain's lib dir
instead of copying them on every deployment.

The "Deploy on Save" feature is only useful for mini applications - it
is too slow.

Bernard


On Fri, 06 Apr 2012 16:48:11 +0200, you wrote:

>
>I've been fighting this for the past two days, but I'm not succeeding. I'm using Wicket 1.5.5 on GlassFish 3.1.2 and that runs without a problem. I have configured
>
><filter-class>org.apache.wicket.protocol.http.ReloadingWicketFilter</filter-class>
>
>to reload the classes, but that is not working. The only way to reload the class file is by using JRebel.
>
>Also Wicket reports that it runs in DEVELOPMENT mode, but it is not reloading the HTML files. In an attempting to resolve that I explicitely configured
>
>     getResourceSettings().setDefaultCacheDuration(Duration.ONE_SECOND);
>
>but that does not make a difference. The only way I can get it to work somewhat, is to add my own ResourceFinder directly on the src folder:
>
>         getResourceSettings().setResourceFinder(new IResourceFinder()
>         {
>             @Override
>             public IResourceStream find(Class<?> clazz, String pathname)
>             {
>                 File f = new File("C:/Documents and Settings/User/My Documents/s2m/sources/components/service/src/main/java/" + pathname);
>                 if (f.exists())
>                 {
>                     return new FileResourceStream( f );
>                 }
>                 return null;
>             }
>         });
>         getResourceSettings().setUseDefaultOnMissingResource(true);
>
>But still the source are not reloaded reliably. I figure if the cache expires, a new call to the resource finder should be done, correct?
>
>Is there any debugging of these autoreload features, so I can see what Wicket is doing?
>
>Tom
>
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>For additional commands, e-mail: users-help@wicket.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org