wicket-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Ertl <pe...@gmx.org>
Subject Re: JRebel and wicket
Date Thu, 18 Nov 2010 15:14:01 GMT
Last time I tried to give JRebel some love this issue made me drop it again (If I remember
the situation correctly):

Imagine you are developing a new page "HomePage" which has a single component

public HomePage()
   add(new Label("foo", ...) {   });

later on add another component

public HomePage()
   add(new TextField("bar", ...) {   });
   add(new Label("foo", ...) {   });

--> JRebel throws a "SuperClassChangedError" when trying to replace HomePage$1

This also happens when you change a component type (e.g. Link --> BookmarkableLink) or
in similar situations.

It's a known limitation (and no change in sight)



Am 18.11.2010 um 15:19 schrieb Carl-Eric Menzel:

> On Thu, 18 Nov 2010 14:25:40 +0100
> Martijn Dashorst <martijn.dashorst@gmail.com> wrote:
>> Relaxing the add() method has been proposed before (by Eelco). It is
>> not something new, and if it helps people using jrebel to improve
>> their productivity, that would be a great side effect.
> I agree it would be a good side effect, but not a change worth doing
> just for the benefit of JRebel :) - only if the change adds something
> worthwhile on its own.
> I just googled for Eelco's original proposal to give add() the
> semantics of addOrReplace(), since I didn't even know about that
> proposal.
> I agree with what you say about "final" and the clear semantics of
> add() and addOrReplace(). I like the fact that with the current
> semantics I can choose whether I want to definitely add (and get an
> exception in case of a bug) or whether I want to, well, add or
> replace :-)
> Usually I prefer a slight bit of additional typing over an
> ambiguous/unclear API.
> Maybe someone who uses JRebel (I don't) can ask the JRebel guys about
> better support for this.
> Carl-Eric
> www.wicketbuch.de

View raw message