RE: Rendering a component into a String
Just a quick update for those with the same problem: Option 1 did not work as the page is not bookmarkable. I used option 2 and override isBookmarkable() method in RenderPage to return true. Page is set to stateless on its own. It's not too clean but in my case should be enough. Martin, please let me know if you see any danger in such solution. Mateusz -Original Message- From: Martin Grigorov [mailto:mgrigo...@apache.org] Sent: Thursday, November 21, 2013 10:56 AM To: users@wicket.apache.org Subject: Re: Rendering a component into a String Option 1) Override your component's onInitialize/onConfigure and call page.setStatelessHint(true) Option 2) Copy/paste ComponentRenderer.java locally and do something similar directly in RenderPage On Thu, Nov 21, 2013 at 11:29 AM, Mateusz Mieszkowski < mmieszkow...@objectivity.co.uk> wrote: > Martin, > > Ticket created: https://issues.apache.org/jira/browse/WICKET-5422 > Can you advise a workaround for now? > > Cheers, > Mateusz > > > -Original Message- > From: Martin Grigorov [mailto:mgrigo...@apache.org] > Sent: Thursday, November 21, 2013 9:49 AM > To: users@wicket.apache.org > Cc: Martin Dietze > Subject: Re: Rendering a component into a String > > Please create a ticket. > The page should be marked as stateless to avoid storing it. > > > On Thu, Nov 21, 2013 at 10:40 AM, Mateusz Mieszkowski < > mmieszkow...@objectivity.co.uk> wrote: > > > Hi guys, > > > > I noticed a problem with ComponentRenderer.renderComponent(). It is > > possible that I'm missing something but this is what I get for now: > > I'm using ComponenetRenderer withing CustomTooltipBehavior > > (wicket-jquery-ui) to generate tooltip content. I add this to about > > 50 rows in my table so I run renderComponent() method as many times. > > All worked fine but there was a problem with performance when I used > > Fragment component with markup attached to the WebPage. I did some > > digging and finally checked > > http://localhost:8080/context/wicket/internal/debug/diskDataStore > > and it appeared that for one request, Wicket stores 51 pages in it. > > All of the size of the whole page (about 300kB) and all of them > > named org.apache.wicket.core.util.string.ComponentRenderer$RenderPage. > > > > I changed implementation from Fragment to Panel componenet and the > > size was reduced to (1kB) but still all of these items were stored > > in the DataStore. > > > > It seems that this method is creating a dummy page in order to > > create the markup, but how can I avoid storing these pages? > > > > Best regards, > > Mateusz > > > > -Original Message- > > From: Martin Grigorov [mailto:mgrigo...@apache.org] > > Sent: Wednesday, November 13, 2013 2:09 PM > > To: users@wicket.apache.org; Martin Dietze > > Subject: Re: Rendering a component into a String > > > > Hi, > > > > See the source of > > http://www.wicket-library.com/wicket-examples-6.0.x/mailtemplate/?2e > > xa > > mple > > > > > > On Wed, Nov 13, 2013 at 3:04 PM, Martin Dietze wrote: > > > > > In a legacy project I've inherited I've got a piece of code that > > > no longer works since the project was upgraded from Wicket 1.4 to > > > Wicket 6. > > > > > > It's about rendering a component (a Wicket panel) into a string in > > > order to return it wrapped into a webservice reply. > > > > > > The webservice is based on Wicket, too. The webservice is based on > > > a Javascript handshake - the client calls the service using a > > > token connecting the user to his current session he has on the > > > application, the service replies are rendered into an iframe and > > > deliver their data through postMessage. > > > > > > Thus, when rendering a reply, I am basically rendering a Wicket > > > page within the context of my session. > > > > > > Now one of my API's calls requires me to render a Wicket panel > > > into a String, which is then wrapped into JSON as part of the > > > respective call's reply. > > > > > > The legacy code used to do this roughly like this (changes for > > > using the Wicket 6 API were applied, but this nevertheless never > > > worked): > > > > > > - create a mock RequestCycle by creating a MockHttpSession, a > > > MockHttpServletRequest and a MockHttpServletResponse, glue > > > this all together to obtain a ServletWebRequest and a > > &g
RE: Rendering a component into a String
Martin,
Ticket created: https://issues.apache.org/jira/browse/WICKET-5422
Can you advise a workaround for now?
Cheers,
Mateusz
-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org]
Sent: Thursday, November 21, 2013 9:49 AM
To: users@wicket.apache.org
Cc: Martin Dietze
Subject: Re: Rendering a component into a String
Please create a ticket.
The page should be marked as stateless to avoid storing it.
On Thu, Nov 21, 2013 at 10:40 AM, Mateusz Mieszkowski <
mmieszkow...@objectivity.co.uk> wrote:
> Hi guys,
>
> I noticed a problem with ComponentRenderer.renderComponent(). It is
> possible that I'm missing something but this is what I get for now:
> I'm using ComponenetRenderer withing CustomTooltipBehavior
> (wicket-jquery-ui) to generate tooltip content. I add this to about 50
> rows in my table so I run renderComponent() method as many times.
> All worked fine but there was a problem with performance when I used
> Fragment component with markup attached to the WebPage. I did some
> digging and finally checked
> http://localhost:8080/context/wicket/internal/debug/diskDataStore and
> it appeared that for one request, Wicket stores 51 pages in it. All of
> the size of the whole page (about 300kB) and all of them named
> org.apache.wicket.core.util.string.ComponentRenderer$RenderPage.
>
> I changed implementation from Fragment to Panel componenet and the
> size was reduced to (1kB) but still all of these items were stored in
> the DataStore.
>
> It seems that this method is creating a dummy page in order to create
> the markup, but how can I avoid storing these pages?
>
> Best regards,
> Mateusz
>
> -Original Message-
> From: Martin Grigorov [mailto:mgrigo...@apache.org]
> Sent: Wednesday, November 13, 2013 2:09 PM
> To: users@wicket.apache.org; Martin Dietze
> Subject: Re: Rendering a component into a String
>
> Hi,
>
> See the source of
> http://www.wicket-library.com/wicket-examples-6.0.x/mailtemplate/?2exa
> mple
>
>
> On Wed, Nov 13, 2013 at 3:04 PM, Martin Dietze wrote:
>
> > In a legacy project I've inherited I've got a piece of code that no
> > longer works since the project was upgraded from Wicket 1.4 to
> > Wicket 6.
> >
> > It's about rendering a component (a Wicket panel) into a string in
> > order to return it wrapped into a webservice reply.
> >
> > The webservice is based on Wicket, too. The webservice is based on a
> > Javascript handshake - the client calls the service using a token
> > connecting the user to his current session he has on the
> > application, the service replies are rendered into an iframe and
> > deliver their data through postMessage.
> >
> > Thus, when rendering a reply, I am basically rendering a Wicket page
> > within the context of my session.
> >
> > Now one of my API's calls requires me to render a Wicket panel into
> > a String, which is then wrapped into JSON as part of the respective
> > call's reply.
> >
> > The legacy code used to do this roughly like this (changes for using
> > the Wicket 6 API were applied, but this nevertheless never
> > worked):
> >
> > - create a mock RequestCycle by creating a MockHttpSession, a
> > MockHttpServletRequest and a MockHttpServletResponse, glue
> > this all together to obtain a ServletWebRequest and a
> > BufferedWebResponse and finaly use use Application.createRequestCycle()
> > to create the RequestCycle object
> >
> > - the component wrapped into a ComponentRenderingRequestHandler
> >
> > - then this code is executed:
> >
> > |try {
> > |requestCycle.scheduleRequestHandlerAfterCurrent(requestHandler);
> > |try {
> > |if ( !requestCycle.processRequestAndDetach() ) {
> > |requestCycle.scheduleRequestHandlerAfterCurrent(new
> > ErrorCodeRequestHandler((HttpServletResponse.SC_NOT_FOUND));
> > | }
> > |} finally {
> > |requestCycle.getResponse().close();
> > |}
> > |return requestCycle.getResponse().toString();
> > |} finally {
> > |requestCycle.detach();
> > |}
> >
> > I must admit I could not have written this myself :)
> >
> > Now when running this code, I run into two different
> > exceptions:
> >
> > org.apache.wicket.WicketRuntimeException: Exception in rendering
> > component: [Profile [Component id = profile]]
> > at
> > org.apache.wicket.Component.internalRenderComponent(Component.java:2
> > 57
> > 6)
> > [wi
RE: Rendering a component into a String
Hi guys,
I noticed a problem with ComponentRenderer.renderComponent(). It is possible
that I'm missing something but this is what I get for now:
I'm using ComponenetRenderer withing CustomTooltipBehavior (wicket-jquery-ui)
to generate tooltip content. I add this to about 50 rows in my table so I run
renderComponent() method as many times.
All worked fine but there was a problem with performance when I used Fragment
component with markup attached to the WebPage. I did some digging and finally
checked http://localhost:8080/context/wicket/internal/debug/diskDataStore and
it appeared that for one request, Wicket stores 51 pages in it. All of the size
of the whole page (about 300kB) and all of them named
org.apache.wicket.core.util.string.ComponentRenderer$RenderPage.
I changed implementation from Fragment to Panel componenet and the size was
reduced to (1kB) but still all of these items were stored in the DataStore.
It seems that this method is creating a dummy page in order to create the
markup, but how can I avoid storing these pages?
Best regards,
Mateusz
-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org]
Sent: Wednesday, November 13, 2013 2:09 PM
To: users@wicket.apache.org; Martin Dietze
Subject: Re: Rendering a component into a String
Hi,
See the source of
http://www.wicket-library.com/wicket-examples-6.0.x/mailtemplate/?2 example
On Wed, Nov 13, 2013 at 3:04 PM, Martin Dietze wrote:
> In a legacy project I've inherited I've got a piece of code that no
> longer works since the project was upgraded from Wicket 1.4 to Wicket
> 6.
>
> It's about rendering a component (a Wicket panel) into a string in
> order to return it wrapped into a webservice reply.
>
> The webservice is based on Wicket, too. The webservice is based on a
> Javascript handshake - the client calls the service using a token
> connecting the user to his current session he has on the application,
> the service replies are rendered into an iframe and deliver their data
> through postMessage.
>
> Thus, when rendering a reply, I am basically rendering a Wicket page
> within the context of my session.
>
> Now one of my API's calls requires me to render a Wicket panel into a
> String, which is then wrapped into JSON as part of the respective
> call's reply.
>
> The legacy code used to do this roughly like this (changes for using
> the Wicket 6 API were applied, but this nevertheless never
> worked):
>
> - create a mock RequestCycle by creating a MockHttpSession, a
> MockHttpServletRequest and a MockHttpServletResponse, glue
> this all together to obtain a ServletWebRequest and a
> BufferedWebResponse and finaly use use Application.createRequestCycle()
> to create the RequestCycle object
>
> - the component wrapped into a ComponentRenderingRequestHandler
>
> - then this code is executed:
>
> |try {
> |requestCycle.scheduleRequestHandlerAfterCurrent(requestHandler);
> |try {
> |if ( !requestCycle.processRequestAndDetach() ) {
> |requestCycle.scheduleRequestHandlerAfterCurrent(new
> ErrorCodeRequestHandler((HttpServletResponse.SC_NOT_FOUND));
> | }
> |} finally {
> |requestCycle.getResponse().close();
> |}
> |return requestCycle.getResponse().toString();
> |} finally {
> |requestCycle.detach();
> |}
>
> I must admit I could not have written this myself :)
>
> Now when running this code, I run into two different
> exceptions:
>
> org.apache.wicket.WicketRuntimeException: Exception in rendering
> component: [Profile [Component id = profile]]
> at
> org.apache.wicket.Component.internalRenderComponent(Component.java:257
> 6)
> [wicket-core-6.9.1.jar:6.9.1]
> at
> org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1493)
> ~[wicket-core-6.9.1.jar:6.9.1]
> at
> org.apache.wicket.Component.internalRender(Component.java:2379)
> [wicket-core-6.9.1.jar:6.9.1]
> at org.apache.wicket.Component.render(Component.java:2307)
> [wicket-core-6.9.1.jar:6.9.1]
> [...]
> Caused by: java.lang.NullPointerException: null
> at
> org.apache.wicket.markup.html.internal.Enclosure.isVisible(Enclosure.j
> ava:143)
> ~[wicket-core-6.9.1.jar:6.9.1]
> at
> org.apache.wicket.Component.determineVisibility(Component.java:4363)
> [wicket-core-6.9.1.jar:6.9.1]
> at
> org.apache.wicket.Component.internalBeforeRender(Component.java:916)
> [wicket-core-6.9.1.jar:6.9.1]
> at
> org.apache.wicket.Component.beforeRender(Component.java:991)
> [wicket-core-6.9.1.jar:6.9.1]
> at
> org.apache.wicket.Component.internalPrepareForRender(Component.java:22
> 14)
> [wicket-core-6.9.1.jar:6.9.1]
> at org.apache.wicket.Component.render(Component.java:2303)
> [wicket-core-6.9.1.jar:6.9.1]
> at
> org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1390
> )
> ~[wicket-core-6.9.1.jar:6.9.1]
> at
> org.apache.w
RE: ajaxlink in ListItem not working
Hi,
I have similar problem. What's more, my code worked fine before migration to
6.10.0 (worked on 5.10.0).
Now, when I click the link, nothing happens.
I haven't got time to investigate this in more detail but just letting you know
that this may not be something obvious.
Cheers,
Mateusz
-Original Message-
From: ha...@dds.nl [mailto:ha...@dds.nl]
Sent: Monday, August 26, 2013 2:05 PM
To: users@wicket.apache.org
Subject: Re: ajaxlink in ListItem not working
Sven,
No, I forgot to change the names in the code. The names in the markup and java
code are the same.
Sven Meier schreef:
>>
>> Wicket users,
>>
>> I got an AjaxLink in a ListItem, but there is no response when
>> clicking. This is the markup code
>>
>>
>>
>>> wicket:id="color">#ff
>>
>>
>>
>> Java code
>>
>> ListView colorView = new ListView("kleuren",
>> getKleuren()) {
>>
>> @Override
>> protected void populateItem(ListItem item) {
>> String color = (String) item.getModelObject();
>>AjaxLink selectColor = new AjaxLink("selectLink",
>> Model.of(Color)) {
>>@Override
>>public void onClick(AjaxRequestTarget target) {
>>logger.debug("click color");
>>}
>>};
>>
>>Label kleurLabel = new Label("kleur", kleur);
>>selectKleur.add(kleurLabel);
>>item.add(selectKleur);
>>
>>}
>>};
>>
>>add(colorView);
>>
>> I can see javascript generated for the links in the items, but
>> somehow this is not triggered.
>>
>> javascript code:
>>
>> ...
>> (function(){Wicket.Ajax.ajax({"u":"./customizer?1-1.IBehaviorListener
>> .0-customizerForm-stijlPanel-colorSelectiePanel-colorSelectie-submitColor","e":"click","c":"submitColor25"});})();.
>> Anybody has an idea or experience with ajaxlinks in listitems? How to debug
>> this?
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Multiple F5 refreshes create multiple threads
Hi, I'm having a problem with quite old version of Wicket (1.3.6) and I'm wondering if this still exists in the latest version as we're getting ready for upgrading. The thing is that if the page opened in browser uses SortableDataProvider, iterator method is executed. So far so good... But each time user do F5, page refresh creates new http thread and every one of them is trying to process iterator method. Since this is the same user/session, I think it is safe to say that only one thread(that is doing the refresh) is necessary and more refreshes should kill http threads that are working to get the same info. The problem in my system was, that one user's F5 blocked and it caused hundreds of refresh and started hundreds of http thread. I imagine that in worse case scenario it could use up whole thread pool and system would be useless for some time. I've checked changelogs and jira issues but haven't found anything similar. Could you please let me know if there is a way to avoid such situation? Kind regards, Mateusz Mieszkowski
