You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Reinhard Pötz <re...@apache.org> on 2011/09/15 16:56:08 UTC
JRebel Wicket-Integration
Yesterday I started with a new Wicket 1.5 project and since the
ReloadingClassLoader didn't work for me I gave JRebel a try. AFAICT
JRebel worked great when you change existing classes. But then I run
into a problem when I added a mount to the Wicket application.
I contacted the JRebel support and they answered promptly. You can find
our conversation below.
The mentioned code sample can be found at
https://github.com/reinhard/wicket-jrebel
In short, they are asking whether it is ok to call the init() method of
the WebApplication object again when the class file was changed.
Unfortunately I'm not an expert in how Wicket works internally and
whether it is save what they propose.
It would be great if somebody else with a better understanding of
possible implications of this call could share his thoughts with us.
Please keep the ZeroTurnaround Support Team in the loop by CCing them.
-- Reinhard
On 09/15/2011 01:07 PM, ZeroTurnaround Support Team wrote:
> Hello,
>
> Thank you very much for the demo application.
>
> As the page is mounted in the init() method the only solution for
> this problem would be to call this method when a class extending
> org.apache.wicket.Application is changed. Can you predict what
> problems may arise if we do this? It seems that if multiple pages are
> mounted to same path the last one is used, so there should be no
> problems with remounting pages. What else can be done in the init()
> method except mounting pages?
>
> -- Aleksei Sosnovski support@zeroturnaround.com
>
>
> -----Original Message----- From: "Reinhard
> Pötz"<re...@apache.org> Reply-To: "Reinhard
> Pötz"<re...@apache.org> Date: Wed, 14 Sep 2011 22:58:17 +0200 To:
> "ZeroTurnaround Support Team"<su...@zeroturnaround.com> Subject:
> Re: (Case 16581) JRebel Wicket-Integration
>
>> Hello Anton!
>>
>> Thanks for your really fast answer! I've created a small
>> test-project based on the Wicket Quickstart archetype, which is
>> attached to this mail.
>>
>> Run 'mvn package eclipse:eclipse' in order to get a working
>> project configuration for Eclipse and JRebel. Then run the main
>> method of the class com.example.Start with JRebel being activated.
>> The reload of existing pages works fine AFAICS (at least some
>> simple experiments worked well for me).
>>
>> Then go to the class com.example.WicketApplication and uncomment
>> the commented line that mounts a page. As I explained in my mail
>> before, the new page isn't found although the log and the console
>> output confirm that the WicketApplication class has been reloaded
>> before.
>>
>> If you have any further questions, don't hesitate to contact me!
>>
>> Best regards, Reinhard Pötz
>>
>> On 09/14/2011 06:18 PM, ZeroTurnaround Support Team wrote:
>>> Hello!
>>>
>>> It might be the case that this particular functionality is not
>>> covered with our integration. JRebel picks up the new version of
>>> the class but probably it is required to reinitialize some of the
>>> Wicket internals.
>>>
>>> Can you provide me the sample test case for this issue?
>>>
>>> -- Anton Arhipov support@zeroturnaround.com
--
Reinhard Pötz Founder & Managing Director, Indoqa and Deepsearch
http://www.indoqa.com/people/reinhard-poetz.html
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________
Furthermore, I think Oracle has to honor the JSPA agreement.
http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: (Case 16622) Re: JRebel Wicket-Integration
Posted by ZeroTurnaround Support Team <su...@zeroturnaround.com>.
Hey,
please don't CC support@zeroturnaround.com from the list, currently each mail will open up a new support case in our bug-tracker for some reason. We'll be following the list directly.. thank you!
--
Sander Sõnajalg
support@zeroturnaround.com
-----Original Message-----
From: "Martin Grigorov" <mg...@apache.org>
Reply-To: "Martin Grigorov" <mg...@apache.org>
Date: Thu, 15 Sep 2011 18:08:03 +0300
To: "dev@wicket.apache.org" <de...@wicket.apache.org>
Cc: "ZeroTurnaround Support Team" <su...@zeroturnaround.com>
Subject: Re: JRebel Wicket-Integration
>Hi,
>
Re: JRebel Wicket-Integration
Posted by Martin Grigorov <mg...@apache.org>.
On Thu, Sep 15, 2011 at 10:58 PM, Reinhard Pötz <re...@apache.org> wrote:
> On 09/15/2011 08:40 PM, Sander Sõnajalg wrote:
>>
>> On Thu, Sep 15, 2011 at 8:51 PM, Martin
>> Grigorov<mg...@apache.org>wrote:
>>
>>> Sorry, I went a bit far.
>>> You need to re-call just #init() without #internalInit(), so
>>> #internalDestroy() is not really needed.
>>>
>>> Usually #init() mounts the pages and configures different IXyzSettings
>>> but it can contain any user specific code so I think it is not that
>>> safe to be re-called.
>>>
>>> Even with @Mount someone have to re-run the scanner and if the impl is
>>> the same as it is now the registry with mappers will be doubled.
>>>
>>> I see no way to archive what you need at the moment.
>>>
>>
>>
>> Thanks a lot for your answers! : )
>>
>> Trying to support @Mount is probably our way to go here, if we want to
>> enhance our wicket support. Re-calling init() sounds very unsafe and this
>> is
>> probably unacceptable, but patching various resource scanners is something
>> we have done for numerous frameworks already, this should be feasible if
>> the
>> need for this functionality seems to be high enough. Thanks!
>
> IIUC this means Wicket's o.a.w.request.mapper.ICompoundRequestMapper
> interface would have to provide a #clear() method.
This is not so simple too because it will remove the system mappers too.
But even if it cleans just the user defined mappers then what about
your custom application specific logic in #init(). How to revert and
re-apply it safely ?
I think it is not worth the troubles.
Application#init() is modified rarely. Only in the early development
phase a man needs to add something there. With the time you'll edit
more components and more rarely the configuration.
Here is a workaround that you can use to mount a newly created page:
in code which you know will execute for sure (e.g. another page's
#onBeforeRender()) you can add
WebApplication.get().mountPage("some/path", TheNewPage.class) then
fire a request once and then remove that line.
>
> Then the JRebel Wicket plugin could call it so that there are no double
> mounts.
>
> However, after looking at the mentioned AnnotatedMountScanner
> (http://goo.gl/AY6Ap) I'm not sure how the JRebel Wicket plugin would know
> how to re-run the scanner which is usually called by
>
> new AnnotatedMountScanner().scanPackage("com.example.*").mount(this);
>
> Any ideas?
>
> --
> Reinhard Pötz Founder & Managing Director, Indoqa and Deepsearch
> http://www.indoqa.com/people/reinhard-poetz.html
>
> Member of the Apache Software Foundation
> Apache Cocoon Committer, PMC member reinhard@apache.org
> ________________________________________________________________________
>
> Furthermore, I think Oracle has to honor the JSPA agreement.
> http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
Re: JRebel Wicket-Integration
Posted by Reinhard Pötz <re...@apache.org>.
On 09/15/2011 08:40 PM, Sander Sõnajalg wrote:
> On Thu, Sep 15, 2011 at 8:51 PM, Martin Grigorov<mg...@apache.org>wrote:
>
>> Sorry, I went a bit far.
>> You need to re-call just #init() without #internalInit(), so
>> #internalDestroy() is not really needed.
>>
>> Usually #init() mounts the pages and configures different IXyzSettings
>> but it can contain any user specific code so I think it is not that
>> safe to be re-called.
>>
>> Even with @Mount someone have to re-run the scanner and if the impl is
>> the same as it is now the registry with mappers will be doubled.
>>
>> I see no way to archive what you need at the moment.
>>
>
>
> Thanks a lot for your answers! : )
>
> Trying to support @Mount is probably our way to go here, if we want to
> enhance our wicket support. Re-calling init() sounds very unsafe and this is
> probably unacceptable, but patching various resource scanners is something
> we have done for numerous frameworks already, this should be feasible if the
> need for this functionality seems to be high enough. Thanks!
IIUC this means Wicket's o.a.w.request.mapper.ICompoundRequestMapper
interface would have to provide a #clear() method.
Then the JRebel Wicket plugin could call it so that there are no double
mounts.
However, after looking at the mentioned AnnotatedMountScanner
(http://goo.gl/AY6Ap) I'm not sure how the JRebel Wicket plugin would
know how to re-run the scanner which is usually called by
new AnnotatedMountScanner().scanPackage("com.example.*").mount(this);
Any ideas?
--
Reinhard Pötz Founder & Managing Director, Indoqa and Deepsearch
http://www.indoqa.com/people/reinhard-poetz.html
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________
Furthermore, I think Oracle has to honor the JSPA agreement.
http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: JRebel Wicket-Integration
Posted by Reinhard Pötz <re...@apache.org>.
On 09/15/2011 08:40 PM, Sander Sõnajalg wrote:
> On Thu, Sep 15, 2011 at 8:51 PM, Martin Grigorov<mg...@apache.org>wrote:
>
>> Sorry, I went a bit far.
>> You need to re-call just #init() without #internalInit(), so
>> #internalDestroy() is not really needed.
>>
>> Usually #init() mounts the pages and configures different IXyzSettings
>> but it can contain any user specific code so I think it is not that
>> safe to be re-called.
>>
>> Even with @Mount someone have to re-run the scanner and if the impl is
>> the same as it is now the registry with mappers will be doubled.
>>
>> I see no way to archive what you need at the moment.
>>
>
>
> Thanks a lot for your answers! : )
>
> Trying to support @Mount is probably our way to go here, if we want to
> enhance our wicket support. Re-calling init() sounds very unsafe
<snip/>
Another thought: Is there any chance to make the call of init()
configurable for JRebel user? E.g. via a system property.
--
Reinhard Pötz Founder & Managing Director, Indoqa and Deepsearch
http://www.indoqa.com/people/reinhard-poetz.html
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________
Furthermore, I think Oracle has to honor the JSPA agreement.
http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: JRebel Wicket-Integration
Posted by Sander Sõnajalg <sa...@zeroturnaround.com>.
On Thu, Sep 15, 2011 at 8:51 PM, Martin Grigorov <mg...@apache.org>wrote:
> Sorry, I went a bit far.
> You need to re-call just #init() without #internalInit(), so
> #internalDestroy() is not really needed.
>
> Usually #init() mounts the pages and configures different IXyzSettings
> but it can contain any user specific code so I think it is not that
> safe to be re-called.
>
> Even with @Mount someone have to re-run the scanner and if the impl is
> the same as it is now the registry with mappers will be doubled.
>
> I see no way to archive what you need at the moment.
>
Thanks a lot for your answers! : )
Trying to support @Mount is probably our way to go here, if we want to
enhance our wicket support. Re-calling init() sounds very unsafe and this is
probably unacceptable, but patching various resource scanners is something
we have done for numerous frameworks already, this should be feasible if the
need for this functionality seems to be high enough. Thanks!
--
Sander Sõnajalg
Re: JRebel Wicket-Integration
Posted by Martin Grigorov <mg...@apache.org>.
Sorry, I went a bit far.
You need to re-call just #init() without #internalInit(), so
#internalDestroy() is not really needed.
Usually #init() mounts the pages and configures different IXyzSettings
but it can contain any user specific code so I think it is not that
safe to be re-called.
Even with @Mount someone have to re-run the scanner and if the impl is
the same as it is now the registry with mappers will be doubled.
I see no way to archive what you need at the moment.
2011/9/15 Sander Sõnajalg <sa...@zeroturnaround.com>:
> Hi!
>
> I think this discussion was started by our support being asked whether it
> would be possible to reload the statements that mount the bookmarkable
> pages, typically placed in a method overriding Application#init(). Let's
> even leave garbage collection aside for a moment.. JRebel is a
> developer-oriented product and the developer will probably be running his
> instance of wicket in an isolated web server where he is the only user and
> he'll be restarting he server at least once a day anyway... memory is
> usually not a problem. I mean.. re-calling Application#init() is something
> that user can override to do whatever custom application initialization
> logics he wants, right? And quite probably some guys will use it to
> initialize some singleton services or other stuff they really expect to only
> get called once? I'm afraid there is no way we could assume that re-calling
> Application#init is safe, even if there is no wicket-interals-specific
> reason that disallows recalling it (is there?). Situation would have been
> better if mounting those bookmarkable pages would have been implemented by
> some sort of @Mount annotations on top of the Page classes (I haven't
> followed recent developments of wicket.. i don't know whether you have this
> option or not). But currently, i think this kind of reloading is not safely
> doable, or what you guys think..?
>
> Sander Sõnajalg
> (JRebel development team)
>
>
> On Thu, Sep 15, 2011 at 6:51 PM, Reinhard Pötz <re...@apache.org> wrote:
>
>>
>> Do I understand your comment correctly that you are worried about wasting
>> resources, i.e. mounted mappers that don't get garbage collected?
>>
>> Or do you also expect that after #internalDestroy() #init() the application
>> doesn't work as expected anymore?
>>
>> -- Reinhard
>>
>> On 09/15/2011 05:08 PM, Martin Grigorov wrote:
>>
>>> Hi,
>>>
>>> I've heart about problems with Wicket page reload and component tree
>>> before but this question about reloading the configuration
>>> (Application class) is new for me.
>>>
>>> I haven't tried it but before calling #init() I would call
>>> #internalDestroy(). But even with this I think it wont work because
>>> destroy method calls different destroy callbacks for the configurable
>>> parts of Wicket but it doesn't clean data structures like the list of
>>> mounted mappers. We leave this to the garbage collector.
>>> The mount problem can be solved with #umount(String) but only if you
>>> know the mount path, so again it is not enough...
>>>
>>> On Thu, Sep 15, 2011 at 5:56 PM, Reinhard Pötz<re...@apache.org>
>>> wrote:
>>>
>>>>
>>>> Yesterday I started with a new Wicket 1.5 project and since the
>>>> ReloadingClassLoader didn't work for me I gave JRebel a try. AFAICT
>>>> JRebel
>>>> worked great when you change existing classes. But then I run into a
>>>> problem
>>>> when I added a mount to the Wicket application.
>>>>
>>>> I contacted the JRebel support and they answered promptly. You can find
>>>> our
>>>> conversation below.
>>>> The mentioned code sample can be found at
>>>> https://github.com/reinhard/**wicket-jrebel<https://github.com/reinhard/wicket-jrebel>
>>>>
>>>> In short, they are asking whether it is ok to call the init() method of
>>>> the
>>>> WebApplication object again when the class file was changed.
>>>>
>>>> Unfortunately I'm not an expert in how Wicket works internally and
>>>> whether
>>>> it is save what they propose.
>>>>
>>>> It would be great if somebody else with a better understanding of
>>>> possible
>>>> implications of this call could share his thoughts with us.
>>>> Please keep the ZeroTurnaround Support Team in the loop by CCing them.
>>>>
>>>> -- Reinhard
>>>>
>>>> On 09/15/2011 01:07 PM, ZeroTurnaround Support Team wrote:
>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>> Thank you very much for the demo application.
>>>>>
>>>>> As the page is mounted in the init() method the only solution for
>>>>> this problem would be to call this method when a class extending
>>>>> org.apache.wicket.Application is changed. Can you predict what
>>>>> problems may arise if we do this? It seems that if multiple pages are
>>>>> mounted to same path the last one is used, so there should be no
>>>>> problems with remounting pages. What else can be done in the init()
>>>>> method except mounting pages?
>>>>>
>>>>> -- Aleksei Sosnovski support@zeroturnaround.com
>>>>>
>>>>>
>>>>> -----Original Message----- From: "Reinhard
>>>>> Pötz"<re...@apache.org> Reply-To: "Reinhard
>>>>> Pötz"<re...@apache.org> Date: Wed, 14 Sep 2011 22:58:17 +0200 To:
>>>>> "ZeroTurnaround Support Team"<su...@zeroturnaround.com>>
>>>>> Subject:
>>>>> Re: (Case 16581) JRebel Wicket-Integration
>>>>>
>>>>> Hello Anton!
>>>>>>
>>>>>> Thanks for your really fast answer! I've created a small
>>>>>> test-project based on the Wicket Quickstart archetype, which is
>>>>>> attached to this mail.
>>>>>>
>>>>>> Run 'mvn package eclipse:eclipse' in order to get a working
>>>>>> project configuration for Eclipse and JRebel. Then run the main
>>>>>> method of the class com.example.Start with JRebel being activated.
>>>>>> The reload of existing pages works fine AFAICS (at least some
>>>>>> simple experiments worked well for me).
>>>>>>
>>>>>> Then go to the class com.example.WicketApplication and uncomment
>>>>>> the commented line that mounts a page. As I explained in my mail
>>>>>> before, the new page isn't found although the log and the console
>>>>>> output confirm that the WicketApplication class has been reloaded
>>>>>> before.
>>>>>>
>>>>>> If you have any further questions, don't hesitate to contact me!
>>>>>>
>>>>>> Best regards, Reinhard Pötz
>>>>>>
>>>>>> On 09/14/2011 06:18 PM, ZeroTurnaround Support Team wrote:
>>>>>>
>>>>>>>
>>>>>>> Hello!
>>>>>>>
>>>>>>> It might be the case that this particular functionality is not
>>>>>>> covered with our integration. JRebel picks up the new version of
>>>>>>> the class but probably it is required to reinitialize some of the
>>>>>>> Wicket internals.
>>>>>>>
>>>>>>> Can you provide me the sample test case for this issue?
>>>>>>>
>>>>>>> -- Anton Arhipov support@zeroturnaround.com
>>>>>>>
>>>>>>
>>>> --
>>>> Reinhard Pötz Founder& Managing Director, Indoqa and Deepsearch
>>>> http://www.indoqa.com/people/**
>>>> reinhard-poetz.html <http://www.indoqa.com/people/reinhard-poetz.html>
>>>>
>>>> Member of the Apache Software Foundation
>>>> Apache Cocoon Committer, PMC member reinhard@apache.org
>>>> ______________________________**______________________________**
>>>> ____________
>>>>
>>>> Furthermore, I think Oracle has to honor the JSPA agreement.
>>>> http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
>>>>
>>>>
>>>
>>>
>>>
>>
>> --
>> Reinhard Pötz Founder & Managing Director, Indoqa and Deepsearch
>> http://www.indoqa.com/people/**reinhard-poetz.html<http://www.indoqa.com/people/reinhard-poetz.html>
>>
>> Member of the Apache Software Foundation
>> Apache Cocoon Committer, PMC member reinhard@apache.org
>> ______________________________**______________________________**
>> ____________
>>
>> Furthermore, I think Oracle has to honor the JSPA agreement.
>> http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
>>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
Re: JRebel Wicket-Integration
Posted by Igor Vaynberg <ig...@gmail.com>.
client code should not be calling application#init(), it is called
once by the framework.
there is an option to use @Mount, there is a project in wicket-stuff
that allows this but we do not support it as part of core.
-igor
2011/9/15 Sander Sõnajalg <sa...@zeroturnaround.com>:
> Hi!
>
> I think this discussion was started by our support being asked whether it
> would be possible to reload the statements that mount the bookmarkable
> pages, typically placed in a method overriding Application#init(). Let's
> even leave garbage collection aside for a moment.. JRebel is a
> developer-oriented product and the developer will probably be running his
> instance of wicket in an isolated web server where he is the only user and
> he'll be restarting he server at least once a day anyway... memory is
> usually not a problem. I mean.. re-calling Application#init() is something
> that user can override to do whatever custom application initialization
> logics he wants, right? And quite probably some guys will use it to
> initialize some singleton services or other stuff they really expect to only
> get called once? I'm afraid there is no way we could assume that re-calling
> Application#init is safe, even if there is no wicket-interals-specific
> reason that disallows recalling it (is there?). Situation would have been
> better if mounting those bookmarkable pages would have been implemented by
> some sort of @Mount annotations on top of the Page classes (I haven't
> followed recent developments of wicket.. i don't know whether you have this
> option or not). But currently, i think this kind of reloading is not safely
> doable, or what you guys think..?
>
> Sander Sõnajalg
> (JRebel development team)
>
>
> On Thu, Sep 15, 2011 at 6:51 PM, Reinhard Pötz <re...@apache.org> wrote:
>
>>
>> Do I understand your comment correctly that you are worried about wasting
>> resources, i.e. mounted mappers that don't get garbage collected?
>>
>> Or do you also expect that after #internalDestroy() #init() the application
>> doesn't work as expected anymore?
>>
>> -- Reinhard
>>
>> On 09/15/2011 05:08 PM, Martin Grigorov wrote:
>>
>>> Hi,
>>>
>>> I've heart about problems with Wicket page reload and component tree
>>> before but this question about reloading the configuration
>>> (Application class) is new for me.
>>>
>>> I haven't tried it but before calling #init() I would call
>>> #internalDestroy(). But even with this I think it wont work because
>>> destroy method calls different destroy callbacks for the configurable
>>> parts of Wicket but it doesn't clean data structures like the list of
>>> mounted mappers. We leave this to the garbage collector.
>>> The mount problem can be solved with #umount(String) but only if you
>>> know the mount path, so again it is not enough...
>>>
>>> On Thu, Sep 15, 2011 at 5:56 PM, Reinhard Pötz<re...@apache.org>
>>> wrote:
>>>
>>>>
>>>> Yesterday I started with a new Wicket 1.5 project and since the
>>>> ReloadingClassLoader didn't work for me I gave JRebel a try. AFAICT
>>>> JRebel
>>>> worked great when you change existing classes. But then I run into a
>>>> problem
>>>> when I added a mount to the Wicket application.
>>>>
>>>> I contacted the JRebel support and they answered promptly. You can find
>>>> our
>>>> conversation below.
>>>> The mentioned code sample can be found at
>>>> https://github.com/reinhard/**wicket-jrebel<https://github.com/reinhard/wicket-jrebel>
>>>>
>>>> In short, they are asking whether it is ok to call the init() method of
>>>> the
>>>> WebApplication object again when the class file was changed.
>>>>
>>>> Unfortunately I'm not an expert in how Wicket works internally and
>>>> whether
>>>> it is save what they propose.
>>>>
>>>> It would be great if somebody else with a better understanding of
>>>> possible
>>>> implications of this call could share his thoughts with us.
>>>> Please keep the ZeroTurnaround Support Team in the loop by CCing them.
>>>>
>>>> -- Reinhard
>>>>
>>>> On 09/15/2011 01:07 PM, ZeroTurnaround Support Team wrote:
>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>> Thank you very much for the demo application.
>>>>>
>>>>> As the page is mounted in the init() method the only solution for
>>>>> this problem would be to call this method when a class extending
>>>>> org.apache.wicket.Application is changed. Can you predict what
>>>>> problems may arise if we do this? It seems that if multiple pages are
>>>>> mounted to same path the last one is used, so there should be no
>>>>> problems with remounting pages. What else can be done in the init()
>>>>> method except mounting pages?
>>>>>
>>>>> -- Aleksei Sosnovski support@zeroturnaround.com
>>>>>
>>>>>
>>>>> -----Original Message----- From: "Reinhard
>>>>> Pötz"<re...@apache.org> Reply-To: "Reinhard
>>>>> Pötz"<re...@apache.org> Date: Wed, 14 Sep 2011 22:58:17 +0200 To:
>>>>> "ZeroTurnaround Support Team"<su...@zeroturnaround.com>>
>>>>> Subject:
>>>>> Re: (Case 16581) JRebel Wicket-Integration
>>>>>
>>>>> Hello Anton!
>>>>>>
>>>>>> Thanks for your really fast answer! I've created a small
>>>>>> test-project based on the Wicket Quickstart archetype, which is
>>>>>> attached to this mail.
>>>>>>
>>>>>> Run 'mvn package eclipse:eclipse' in order to get a working
>>>>>> project configuration for Eclipse and JRebel. Then run the main
>>>>>> method of the class com.example.Start with JRebel being activated.
>>>>>> The reload of existing pages works fine AFAICS (at least some
>>>>>> simple experiments worked well for me).
>>>>>>
>>>>>> Then go to the class com.example.WicketApplication and uncomment
>>>>>> the commented line that mounts a page. As I explained in my mail
>>>>>> before, the new page isn't found although the log and the console
>>>>>> output confirm that the WicketApplication class has been reloaded
>>>>>> before.
>>>>>>
>>>>>> If you have any further questions, don't hesitate to contact me!
>>>>>>
>>>>>> Best regards, Reinhard Pötz
>>>>>>
>>>>>> On 09/14/2011 06:18 PM, ZeroTurnaround Support Team wrote:
>>>>>>
>>>>>>>
>>>>>>> Hello!
>>>>>>>
>>>>>>> It might be the case that this particular functionality is not
>>>>>>> covered with our integration. JRebel picks up the new version of
>>>>>>> the class but probably it is required to reinitialize some of the
>>>>>>> Wicket internals.
>>>>>>>
>>>>>>> Can you provide me the sample test case for this issue?
>>>>>>>
>>>>>>> -- Anton Arhipov support@zeroturnaround.com
>>>>>>>
>>>>>>
>>>> --
>>>> Reinhard Pötz Founder& Managing Director, Indoqa and Deepsearch
>>>> http://www.indoqa.com/people/**
>>>> reinhard-poetz.html <http://www.indoqa.com/people/reinhard-poetz.html>
>>>>
>>>> Member of the Apache Software Foundation
>>>> Apache Cocoon Committer, PMC member reinhard@apache.org
>>>> ______________________________**______________________________**
>>>> ____________
>>>>
>>>> Furthermore, I think Oracle has to honor the JSPA agreement.
>>>> http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
>>>>
>>>>
>>>
>>>
>>>
>>
>> --
>> Reinhard Pötz Founder & Managing Director, Indoqa and Deepsearch
>> http://www.indoqa.com/people/**reinhard-poetz.html<http://www.indoqa.com/people/reinhard-poetz.html>
>>
>> Member of the Apache Software Foundation
>> Apache Cocoon Committer, PMC member reinhard@apache.org
>> ______________________________**______________________________**
>> ____________
>>
>> Furthermore, I think Oracle has to honor the JSPA agreement.
>> http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
>>
>
Re: JRebel Wicket-Integration
Posted by Sander Sõnajalg <sa...@zeroturnaround.com>.
Hi!
I think this discussion was started by our support being asked whether it
would be possible to reload the statements that mount the bookmarkable
pages, typically placed in a method overriding Application#init(). Let's
even leave garbage collection aside for a moment.. JRebel is a
developer-oriented product and the developer will probably be running his
instance of wicket in an isolated web server where he is the only user and
he'll be restarting he server at least once a day anyway... memory is
usually not a problem. I mean.. re-calling Application#init() is something
that user can override to do whatever custom application initialization
logics he wants, right? And quite probably some guys will use it to
initialize some singleton services or other stuff they really expect to only
get called once? I'm afraid there is no way we could assume that re-calling
Application#init is safe, even if there is no wicket-interals-specific
reason that disallows recalling it (is there?). Situation would have been
better if mounting those bookmarkable pages would have been implemented by
some sort of @Mount annotations on top of the Page classes (I haven't
followed recent developments of wicket.. i don't know whether you have this
option or not). But currently, i think this kind of reloading is not safely
doable, or what you guys think..?
Sander Sõnajalg
(JRebel development team)
On Thu, Sep 15, 2011 at 6:51 PM, Reinhard Pötz <re...@apache.org> wrote:
>
> Do I understand your comment correctly that you are worried about wasting
> resources, i.e. mounted mappers that don't get garbage collected?
>
> Or do you also expect that after #internalDestroy() #init() the application
> doesn't work as expected anymore?
>
> -- Reinhard
>
> On 09/15/2011 05:08 PM, Martin Grigorov wrote:
>
>> Hi,
>>
>> I've heart about problems with Wicket page reload and component tree
>> before but this question about reloading the configuration
>> (Application class) is new for me.
>>
>> I haven't tried it but before calling #init() I would call
>> #internalDestroy(). But even with this I think it wont work because
>> destroy method calls different destroy callbacks for the configurable
>> parts of Wicket but it doesn't clean data structures like the list of
>> mounted mappers. We leave this to the garbage collector.
>> The mount problem can be solved with #umount(String) but only if you
>> know the mount path, so again it is not enough...
>>
>> On Thu, Sep 15, 2011 at 5:56 PM, Reinhard Pötz<re...@apache.org>
>> wrote:
>>
>>>
>>> Yesterday I started with a new Wicket 1.5 project and since the
>>> ReloadingClassLoader didn't work for me I gave JRebel a try. AFAICT
>>> JRebel
>>> worked great when you change existing classes. But then I run into a
>>> problem
>>> when I added a mount to the Wicket application.
>>>
>>> I contacted the JRebel support and they answered promptly. You can find
>>> our
>>> conversation below.
>>> The mentioned code sample can be found at
>>> https://github.com/reinhard/**wicket-jrebel<https://github.com/reinhard/wicket-jrebel>
>>>
>>> In short, they are asking whether it is ok to call the init() method of
>>> the
>>> WebApplication object again when the class file was changed.
>>>
>>> Unfortunately I'm not an expert in how Wicket works internally and
>>> whether
>>> it is save what they propose.
>>>
>>> It would be great if somebody else with a better understanding of
>>> possible
>>> implications of this call could share his thoughts with us.
>>> Please keep the ZeroTurnaround Support Team in the loop by CCing them.
>>>
>>> -- Reinhard
>>>
>>> On 09/15/2011 01:07 PM, ZeroTurnaround Support Team wrote:
>>>
>>>>
>>>> Hello,
>>>>
>>>> Thank you very much for the demo application.
>>>>
>>>> As the page is mounted in the init() method the only solution for
>>>> this problem would be to call this method when a class extending
>>>> org.apache.wicket.Application is changed. Can you predict what
>>>> problems may arise if we do this? It seems that if multiple pages are
>>>> mounted to same path the last one is used, so there should be no
>>>> problems with remounting pages. What else can be done in the init()
>>>> method except mounting pages?
>>>>
>>>> -- Aleksei Sosnovski support@zeroturnaround.com
>>>>
>>>>
>>>> -----Original Message----- From: "Reinhard
>>>> Pötz"<re...@apache.org> Reply-To: "Reinhard
>>>> Pötz"<re...@apache.org> Date: Wed, 14 Sep 2011 22:58:17 +0200 To:
>>>> "ZeroTurnaround Support Team"<su...@zeroturnaround.com>>
>>>> Subject:
>>>> Re: (Case 16581) JRebel Wicket-Integration
>>>>
>>>> Hello Anton!
>>>>>
>>>>> Thanks for your really fast answer! I've created a small
>>>>> test-project based on the Wicket Quickstart archetype, which is
>>>>> attached to this mail.
>>>>>
>>>>> Run 'mvn package eclipse:eclipse' in order to get a working
>>>>> project configuration for Eclipse and JRebel. Then run the main
>>>>> method of the class com.example.Start with JRebel being activated.
>>>>> The reload of existing pages works fine AFAICS (at least some
>>>>> simple experiments worked well for me).
>>>>>
>>>>> Then go to the class com.example.WicketApplication and uncomment
>>>>> the commented line that mounts a page. As I explained in my mail
>>>>> before, the new page isn't found although the log and the console
>>>>> output confirm that the WicketApplication class has been reloaded
>>>>> before.
>>>>>
>>>>> If you have any further questions, don't hesitate to contact me!
>>>>>
>>>>> Best regards, Reinhard Pötz
>>>>>
>>>>> On 09/14/2011 06:18 PM, ZeroTurnaround Support Team wrote:
>>>>>
>>>>>>
>>>>>> Hello!
>>>>>>
>>>>>> It might be the case that this particular functionality is not
>>>>>> covered with our integration. JRebel picks up the new version of
>>>>>> the class but probably it is required to reinitialize some of the
>>>>>> Wicket internals.
>>>>>>
>>>>>> Can you provide me the sample test case for this issue?
>>>>>>
>>>>>> -- Anton Arhipov support@zeroturnaround.com
>>>>>>
>>>>>
>>> --
>>> Reinhard Pötz Founder& Managing Director, Indoqa and Deepsearch
>>> http://www.indoqa.com/people/**
>>> reinhard-poetz.html <http://www.indoqa.com/people/reinhard-poetz.html>
>>>
>>> Member of the Apache Software Foundation
>>> Apache Cocoon Committer, PMC member reinhard@apache.org
>>> ______________________________**______________________________**
>>> ____________
>>>
>>> Furthermore, I think Oracle has to honor the JSPA agreement.
>>> http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
>>>
>>>
>>
>>
>>
>
> --
> Reinhard Pötz Founder & Managing Director, Indoqa and Deepsearch
> http://www.indoqa.com/people/**reinhard-poetz.html<http://www.indoqa.com/people/reinhard-poetz.html>
>
> Member of the Apache Software Foundation
> Apache Cocoon Committer, PMC member reinhard@apache.org
> ______________________________**______________________________**
> ____________
>
> Furthermore, I think Oracle has to honor the JSPA agreement.
> http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
>
Re: JRebel Wicket-Integration
Posted by Reinhard Pötz <re...@apache.org>.
Do I understand your comment correctly that you are worried about
wasting resources, i.e. mounted mappers that don't get garbage collected?
Or do you also expect that after #internalDestroy() #init() the
application doesn't work as expected anymore?
-- Reinhard
On 09/15/2011 05:08 PM, Martin Grigorov wrote:
> Hi,
>
> I've heart about problems with Wicket page reload and component tree
> before but this question about reloading the configuration
> (Application class) is new for me.
>
> I haven't tried it but before calling #init() I would call
> #internalDestroy(). But even with this I think it wont work because
> destroy method calls different destroy callbacks for the configurable
> parts of Wicket but it doesn't clean data structures like the list of
> mounted mappers. We leave this to the garbage collector.
> The mount problem can be solved with #umount(String) but only if you
> know the mount path, so again it is not enough...
>
> On Thu, Sep 15, 2011 at 5:56 PM, Reinhard Pötz<re...@apache.org> wrote:
>>
>> Yesterday I started with a new Wicket 1.5 project and since the
>> ReloadingClassLoader didn't work for me I gave JRebel a try. AFAICT JRebel
>> worked great when you change existing classes. But then I run into a problem
>> when I added a mount to the Wicket application.
>>
>> I contacted the JRebel support and they answered promptly. You can find our
>> conversation below.
>> The mentioned code sample can be found at
>> https://github.com/reinhard/wicket-jrebel
>>
>> In short, they are asking whether it is ok to call the init() method of the
>> WebApplication object again when the class file was changed.
>>
>> Unfortunately I'm not an expert in how Wicket works internally and whether
>> it is save what they propose.
>>
>> It would be great if somebody else with a better understanding of possible
>> implications of this call could share his thoughts with us.
>> Please keep the ZeroTurnaround Support Team in the loop by CCing them.
>>
>> -- Reinhard
>>
>> On 09/15/2011 01:07 PM, ZeroTurnaround Support Team wrote:
>>>
>>> Hello,
>>>
>>> Thank you very much for the demo application.
>>>
>>> As the page is mounted in the init() method the only solution for
>>> this problem would be to call this method when a class extending
>>> org.apache.wicket.Application is changed. Can you predict what
>>> problems may arise if we do this? It seems that if multiple pages are
>>> mounted to same path the last one is used, so there should be no
>>> problems with remounting pages. What else can be done in the init()
>>> method except mounting pages?
>>>
>>> -- Aleksei Sosnovski support@zeroturnaround.com
>>>
>>>
>>> -----Original Message----- From: "Reinhard
>>> Pötz"<re...@apache.org> Reply-To: "Reinhard
>>> Pötz"<re...@apache.org> Date: Wed, 14 Sep 2011 22:58:17 +0200 To:
>>> "ZeroTurnaround Support Team"<su...@zeroturnaround.com> Subject:
>>> Re: (Case 16581) JRebel Wicket-Integration
>>>
>>>> Hello Anton!
>>>>
>>>> Thanks for your really fast answer! I've created a small
>>>> test-project based on the Wicket Quickstart archetype, which is
>>>> attached to this mail.
>>>>
>>>> Run 'mvn package eclipse:eclipse' in order to get a working
>>>> project configuration for Eclipse and JRebel. Then run the main
>>>> method of the class com.example.Start with JRebel being activated.
>>>> The reload of existing pages works fine AFAICS (at least some
>>>> simple experiments worked well for me).
>>>>
>>>> Then go to the class com.example.WicketApplication and uncomment
>>>> the commented line that mounts a page. As I explained in my mail
>>>> before, the new page isn't found although the log and the console
>>>> output confirm that the WicketApplication class has been reloaded
>>>> before.
>>>>
>>>> If you have any further questions, don't hesitate to contact me!
>>>>
>>>> Best regards, Reinhard Pötz
>>>>
>>>> On 09/14/2011 06:18 PM, ZeroTurnaround Support Team wrote:
>>>>>
>>>>> Hello!
>>>>>
>>>>> It might be the case that this particular functionality is not
>>>>> covered with our integration. JRebel picks up the new version of
>>>>> the class but probably it is required to reinitialize some of the
>>>>> Wicket internals.
>>>>>
>>>>> Can you provide me the sample test case for this issue?
>>>>>
>>>>> -- Anton Arhipov support@zeroturnaround.com
>>
>> --
>> Reinhard Pötz Founder& Managing Director, Indoqa and Deepsearch
>> http://www.indoqa.com/people/reinhard-poetz.html
>>
>> Member of the Apache Software Foundation
>> Apache Cocoon Committer, PMC member reinhard@apache.org
>> ________________________________________________________________________
>>
>> Furthermore, I think Oracle has to honor the JSPA agreement.
>> http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
>>
>
>
>
--
Reinhard Pötz Founder & Managing Director, Indoqa and Deepsearch
http://www.indoqa.com/people/reinhard-poetz.html
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________
Furthermore, I think Oracle has to honor the JSPA agreement.
http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: JRebel Wicket-Integration
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
I've heart about problems with Wicket page reload and component tree
before but this question about reloading the configuration
(Application class) is new for me.
I haven't tried it but before calling #init() I would call
#internalDestroy(). But even with this I think it wont work because
destroy method calls different destroy callbacks for the configurable
parts of Wicket but it doesn't clean data structures like the list of
mounted mappers. We leave this to the garbage collector.
The mount problem can be solved with #umount(String) but only if you
know the mount path, so again it is not enough...
On Thu, Sep 15, 2011 at 5:56 PM, Reinhard Pötz <re...@apache.org> wrote:
>
> Yesterday I started with a new Wicket 1.5 project and since the
> ReloadingClassLoader didn't work for me I gave JRebel a try. AFAICT JRebel
> worked great when you change existing classes. But then I run into a problem
> when I added a mount to the Wicket application.
>
> I contacted the JRebel support and they answered promptly. You can find our
> conversation below.
> The mentioned code sample can be found at
> https://github.com/reinhard/wicket-jrebel
>
> In short, they are asking whether it is ok to call the init() method of the
> WebApplication object again when the class file was changed.
>
> Unfortunately I'm not an expert in how Wicket works internally and whether
> it is save what they propose.
>
> It would be great if somebody else with a better understanding of possible
> implications of this call could share his thoughts with us.
> Please keep the ZeroTurnaround Support Team in the loop by CCing them.
>
> -- Reinhard
>
> On 09/15/2011 01:07 PM, ZeroTurnaround Support Team wrote:
>>
>> Hello,
>>
>> Thank you very much for the demo application.
>>
>> As the page is mounted in the init() method the only solution for
>> this problem would be to call this method when a class extending
>> org.apache.wicket.Application is changed. Can you predict what
>> problems may arise if we do this? It seems that if multiple pages are
>> mounted to same path the last one is used, so there should be no
>> problems with remounting pages. What else can be done in the init()
>> method except mounting pages?
>>
>> -- Aleksei Sosnovski support@zeroturnaround.com
>>
>>
>> -----Original Message----- From: "Reinhard
>> Pötz"<re...@apache.org> Reply-To: "Reinhard
>> Pötz"<re...@apache.org> Date: Wed, 14 Sep 2011 22:58:17 +0200 To:
>> "ZeroTurnaround Support Team"<su...@zeroturnaround.com> Subject:
>> Re: (Case 16581) JRebel Wicket-Integration
>>
>>> Hello Anton!
>>>
>>> Thanks for your really fast answer! I've created a small
>>> test-project based on the Wicket Quickstart archetype, which is
>>> attached to this mail.
>>>
>>> Run 'mvn package eclipse:eclipse' in order to get a working
>>> project configuration for Eclipse and JRebel. Then run the main
>>> method of the class com.example.Start with JRebel being activated.
>>> The reload of existing pages works fine AFAICS (at least some
>>> simple experiments worked well for me).
>>>
>>> Then go to the class com.example.WicketApplication and uncomment
>>> the commented line that mounts a page. As I explained in my mail
>>> before, the new page isn't found although the log and the console
>>> output confirm that the WicketApplication class has been reloaded
>>> before.
>>>
>>> If you have any further questions, don't hesitate to contact me!
>>>
>>> Best regards, Reinhard Pötz
>>>
>>> On 09/14/2011 06:18 PM, ZeroTurnaround Support Team wrote:
>>>>
>>>> Hello!
>>>>
>>>> It might be the case that this particular functionality is not
>>>> covered with our integration. JRebel picks up the new version of
>>>> the class but probably it is required to reinitialize some of the
>>>> Wicket internals.
>>>>
>>>> Can you provide me the sample test case for this issue?
>>>>
>>>> -- Anton Arhipov support@zeroturnaround.com
>
> --
> Reinhard Pötz Founder & Managing Director, Indoqa and Deepsearch
> http://www.indoqa.com/people/reinhard-poetz.html
>
> Member of the Apache Software Foundation
> Apache Cocoon Committer, PMC member reinhard@apache.org
> ________________________________________________________________________
>
> Furthermore, I think Oracle has to honor the JSPA agreement.
> http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com