You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Peter Thomas <pt...@gmail.com> on 2007/09/24 13:53:06 UTC
Experiences with ReloadingWicketFilter
Hi,
I have minor issues with ReloadingWicketFilter and have reopened this JIRA
issue I raised some time back, with a quickstart attached:
https://issues.apache.org/jira/browse/WICKET-685
Just curious to know if others have problems with the ReloadingWicketFilter
when you make minor changes to a page with markup inheritance, you may want
to look at the issue history. ReloadingWicketFilter is a huge time saver
(thanks JBQ :) but would love to see this improved, let me know if you need
more info on the JIRA.
Thanks,
Peter.
Re: Experiences with ReloadingWicketFilter
Posted by Carlos Pita <ca...@gmail.com>.
A time ago I filed a bug relating markup inheritance with the reloading
servlet (although inline frames are involved too in my somewhat contrived
example). Enjoy the cocktail here
https://issues.apache.org/jira/browse/WICKET-965.<https://issues.apache.org/jira/browse/WICKET-965>
Regards,
Carlos
On 9/25/07, Peter Thomas <pt...@gmail.com> wrote:
>
> On 9/25/07, Jean-Baptiste Quenot <jb...@apache.org> wrote:
> >
> > * Peter Thomas:
> >
> > > So to confirm my understanding, when using the
> > > ReloadingWicketFilter, when you make a change to a Page you have
> > > to re-trace navigation to a point prior to where the Page is
> > > loaded. Is that correct?
> >
> > You have to make sure you're not using an instance of a page
> > loaded in a previous classloader, ie make sure not to keep an
> > instance of a page across reloads.
> >
> > > I'm just hoping that something can be done (or
> > > un-done) to improve the developer experience when using
> > > ReloadingWicketFilter.
> >
> > To be honest ReloadingWicketFilter is a hack to work around how
> > the JVM loads classes, and it is bootstrapped during the Wicket
> > application initialization.
> >
> > If ReloadingWicketFilter is causing more problems than it is meant
> > to solve, we might simply want to remove it from Wicket,
> > especially if it proves to be unreliable in complex setups.
> > Unless you're willing to turn your hope into contribution?
>
>
> That's a little harsh. Have a look in the JIRA and I've repeatedly said
> how
> much I appreciate the RWF and even the way it works now (even citing it as
> the reason for not moving to groovy!). Thanks for the gentle reminder
> that
> I should quit whining about this. I'm not a master of classloading and it
> is unlikely I contribute anything in this area.
>
> Have you seen my suggestion to clear your session cookie before
> > reloading the page BTW? All this is very complicated I realize,
> > but there's not much we can do to simplify reloading.
> > --
>
>
> I saw your suggestion on clearing cookies, thanks.
>
> I'll say this one last time and then shut up - I completely understand
> that
> this is a hack and all - but it used to work the way I expected and at
> least
> one other user felt the same. I was just pushing my luck (at the risk of
> losing mailing-list karma) because as the other user said, once you have
> experienced "page refresh" reload of classes it is very hard to go back.
>
> But you are saying nothing more can be done, and I respect the opinion of
> the Wicket committers on this and I can live with how it is now. I
> completely appreciate the work that you and other Wicket committers have
> put
> into RWF and it is a huge time saver in its current form.
>
> Thanks,
>
> Peter.
>
Re: Experiences with ReloadingWicketFilter
Posted by Peter Thomas <pt...@gmail.com>.
On 9/25/07, Jean-Baptiste Quenot <jb...@apache.org> wrote:
>
> * Peter Thomas:
>
> > So to confirm my understanding, when using the
> > ReloadingWicketFilter, when you make a change to a Page you have
> > to re-trace navigation to a point prior to where the Page is
> > loaded. Is that correct?
>
> You have to make sure you're not using an instance of a page
> loaded in a previous classloader, ie make sure not to keep an
> instance of a page across reloads.
>
> > I'm just hoping that something can be done (or
> > un-done) to improve the developer experience when using
> > ReloadingWicketFilter.
>
> To be honest ReloadingWicketFilter is a hack to work around how
> the JVM loads classes, and it is bootstrapped during the Wicket
> application initialization.
>
> If ReloadingWicketFilter is causing more problems than it is meant
> to solve, we might simply want to remove it from Wicket,
> especially if it proves to be unreliable in complex setups.
> Unless you're willing to turn your hope into contribution?
That's a little harsh. Have a look in the JIRA and I've repeatedly said how
much I appreciate the RWF and even the way it works now (even citing it as
the reason for not moving to groovy!). Thanks for the gentle reminder that
I should quit whining about this. I'm not a master of classloading and it
is unlikely I contribute anything in this area.
Have you seen my suggestion to clear your session cookie before
> reloading the page BTW? All this is very complicated I realize,
> but there's not much we can do to simplify reloading.
> --
I saw your suggestion on clearing cookies, thanks.
I'll say this one last time and then shut up - I completely understand that
this is a hack and all - but it used to work the way I expected and at least
one other user felt the same. I was just pushing my luck (at the risk of
losing mailing-list karma) because as the other user said, once you have
experienced "page refresh" reload of classes it is very hard to go back.
But you are saying nothing more can be done, and I respect the opinion of
the Wicket committers on this and I can live with how it is now. I
completely appreciate the work that you and other Wicket committers have put
into RWF and it is a huge time saver in its current form.
Thanks,
Peter.
Re: Experiences with ReloadingWicketFilter
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* Peter Thomas:
> So to confirm my understanding, when using the
> ReloadingWicketFilter, when you make a change to a Page you have
> to re-trace navigation to a point prior to where the Page is
> loaded. Is that correct?
You have to make sure you're not using an instance of a page
loaded in a previous classloader, ie make sure not to keep an
instance of a page across reloads.
> I'm just hoping that something can be done (or
> un-done) to improve the developer experience when using
> ReloadingWicketFilter.
To be honest ReloadingWicketFilter is a hack to work around how
the JVM loads classes, and it is bootstrapped during the Wicket
application initialization.
If ReloadingWicketFilter is causing more problems than it is meant
to solve, we might simply want to remove it from Wicket,
especially if it proves to be unreliable in complex setups.
Unless you're willing to turn your hope into contribution?
Have you seen my suggestion to clear your session cookie before
reloading the page BTW? All this is very complicated I realize,
but there's not much we can do to simplify reloading.
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Experiences with ReloadingWicketFilter
Posted by Peter Thomas <pt...@gmail.com>.
On 9/25/07, Jean-Baptiste Quenot <jb...@apache.org> wrote:
>
> * Peter Thomas:
>
> > Just curious to know if others have problems with the
> > ReloadingWicketFilter when you make minor changes to a page with
> > markup inheritance, you may want to look at the issue history.
>
> FYI the problem described in the JIRA issue is not related
> to markup inheritance. The exception is thrown because the
> class TestPage is loaded from two different classloaders, thus
> TestPage(classloader1) != TestPage(classloader2).
> --
Thanks JBQ. It would be nice to have a better error / stack trace for the
above case. Currently it is like "Markup of type 'html' for component '
test.TestPage' not found." The stack trace also gives the impression that
markup inheritance has something to do with the error, e.g. "
markup.loader.InheritedMarkupMarkupLoader" etc.
So to confirm my understanding, when using the ReloadingWicketFilter, when
you make a change to a Page you have to re-trace navigation to a point prior
to where the Page is loaded. Is that correct?
I'm pretty sure that earlier in the SNAPSHOT days refreshing the page "just
worked", and this is backed up by another user here:
http://www.nabble.com/Has-something-changed-in-markup-inheritance--t3963374.html#a11532314
I'm just hoping that something can be done (or un-done) to improve the
developer experience when using ReloadingWicketFilter.
Thanks,
Peter.
Re: Experiences with ReloadingWicketFilter
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* Peter Thomas:
> Just curious to know if others have problems with the
> ReloadingWicketFilter when you make minor changes to a page with
> markup inheritance, you may want to look at the issue history.
FYI the problem described in the JIRA issue is not related
to markup inheritance. The exception is thrown because the
class TestPage is loaded from two different classloaders, thus
TestPage(classloader1) != TestPage(classloader2).
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org