Custom ISerializer being used during serialization but _not_ during deserialization
Hi all,
in my application I register a custom ISerializer implementation in the
WebApplication.init() method as follows:
@Override
protected void init() {
super.init();
getFrameworkSettings().setSerializer(new
MySerializer(getApplicationKey()));
...
This works as expected during page serialization (that is, my custom
ISerializer.serialize() implementation gets called).
However, it seems as though my ISerializer is _not_ being used during page
deserialization, as can be seen in the error trace below.
As can be seen in the stack trace, the default
*org.apache.wicket.serialize.java.JavaSerializer.deserialize()
method is being called.
Am I doing anything wrong when setting up my custom ISerializer or is
Wicket failing to honor my framework settings?
best regards, Peter
*
java.lang.RuntimeException: Could not deserialize object using: class
org.apache.wicket.serialize.java.JavaSerializer$ClassResolverObjectInputStream
* at
org.apache.wicket.serialize.java.JavaSerializer.deserialize(JavaSerializer.java:137)
*
at
org.apache.wicket.pageStore.DefaultPageStore.deserializePage(DefaultPageStore.java:388)
at
org.apache.wicket.pageStore.DefaultPageStore.getPage(DefaultPageStore.java:127)
at
org.apache.wicket.page.PageStoreManager$SessionEntry.getPage(PageStoreManager.java:192)
at
org.apache.wicket.page.PageStoreManager$PersistentRequestAdapter.getPage(PageStoreManager.java:327)
at
org.apache.wicket.page.AbstractPageManager.getPage(AbstractPageManager.java:102)
at
org.apache.wicket.page.PageManagerDecorator.getPage(PageManagerDecorator.java:50)
at
org.apache.wicket.page.PageAccessSynchronizer$2.getPage(PageAccessSynchronizer.java:232)
at
org.apache.wicket.DefaultMapperContext.getPageInstance(DefaultMapperContext.java:117)
at
org.apache.wicket.request.handler.PageProvider.getStoredPage(PageProvider.java:292)
at
org.apache.wicket.request.handler.PageProvider.isNewPageInstance(PageProvider.java:205)
at
org.apache.wicket.request.mapper.AbstractBookmarkableMapper.mapHandler(AbstractBookmarkableMapper.java:339)
at
org.apache.wicket.request.mapper.CompoundRequestMapper.mapHandler(CompoundRequestMapper.java:156)
at
org.apache.wicket.protocol.https.HttpsMapper.mapHandler(HttpsMapper.java:125)
at
org.apache.wicket.request.cycle.RequestCycle.mapUrlFor(RequestCycle.java:401)
at
org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:146)
at
org.apache.wicket.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:167)
at
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:750)
at
org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
at
org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:252)
at
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:209)
at
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:280)
at
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162)
Re: wicket-ajax and IE performance problems for pages with many links
Sure,
here goes. I have added both the java and the js file to the same Java package:
WicketAjaxJsPatch.java
==
/**
* {...@link IBehavior} that should be added to {...@link Page}s that need to
prevent
* the page load performance penalty incurred when wicket-ajax.js traverses all
* <a> tags in the page markup.
*
*
* For background information, see http://www.nabble.com/wicket-ajax-and-IE-performance-problems-for-pages-with-many-links-td23078336.html";
* >this mailing list thread
*
* This behavior simply makes sure that our patch gets applied to wicket-ajax.js
* (by forcing wicket-ajax.js to be added to the page head prior to
* wicket-ajax-patch.js).
*
*/
public class WicketAjaxJsPatch extends AbstractDefaultAjaxBehavior {
@Override
public void renderHead(IHeaderResponse response) {
super.renderHead(response);
response.renderJavascriptReference(new ResourceReference(
WicketAjaxJsPatch.class, "wicket-ajax-patch.js"));
}
@Override
protected void respond(AjaxRequestTarget target) {
// Does nothing. The fact that we are extending
// AbstractDefaultAjaxBehavior means that we will pull in
// wicket-event.js and wicket-ajax.js. The job of this behavior is to
// make sure that our wicket-ajax-patch.js script gets added to the page
// head after those scripts.
}
}
wicket-ajax-patch.js
===
/**
* Overrides the attachFocusEvent function registered by wicket-ajax.js.
* The original version traverses all anchor and button tags on the page
* which incurs a major performance penalty on pages with many links.
* This version skips these elements in the scanning.
*/
if (typeof(Wicket) != "undefined") {
if (typeof(Wicket.Focus) != "undefined") {
// Deregister old attachFocusEvent function
handlers = Wicket.Event.domReadyHandlers;
filteredHandlers = new Array();
for(i = 0; i < handlers.length; i++) {
if (handlers[i] != Wicket.Focus.attachFocusEvent) {
filteredHandlers.push(handlers[i]);
}
}
Wicket.Event.domReadyHandlers = filteredHandlers;
// Redefine and re-register attachFocusEvent
Wicket.Focus.attachFocusEvent=function() {
Wicket.Focus.setFocusOnElements(document.getElementsByTagName("input"));
Wicket.Focus.setFocusOnElements(document.getElementsByTagName("select"));
Wicket.Focus.setFocusOnElements(document.getElementsByTagName("textarea"));
//Wicket.Focus.setFocusOnElements(document.getElementsByTagName("button"));
//Wicket.Focus.setFocusOnElements(document.getElementsByTagName("a"));
}
Wicket.Event.addDomReadyEvent(Wicket.Focus.attachFocusEvent);
}
}
Attaching the behavior
=
What I do then is to add the WicketAjaxJsPatch to the page by doing.
page.add(new WicketAjaxJsPatch());
It seems to be doing its job for me. Please tell me if it doesn't work.
cheers, Peter
On Fri, Apr 17, 2009 at 12:15 PM, James Carman
wrote:
> Did that code actually work for you? I tried adding this js, but i
> couldn't get it to show up in the correct place. And, when I did, it
> didn't seem to improve much. Care to share your code?
>
> 2009/4/17 Peter Gardfjäll :
>> I have written a simple WicketAjaxJsPatch Behavior which simply adds
>> the aforementioned javascript to the page.
>> In our application, we have several pages that suffer from the same problem.
>> It would be tedious to have to update all of these pages one-by-one.
>> So is there any way for me to add this Behavior to my parent page
>> (which other pages extend) and still have the javascript rendered last
>> in the head?
>>
>> regards, Peter
>>
>> 2009/4/17 Peter Gardfjäll :
>>> Thanks Igor,
>>>
>>> the suggested workaround seems to work fine. However, it is not enough
>>> to just override the attachFocusEvent function -- you also need to
>>> deregister the previously registered function. I did as follows (I
>>> apologize for the lack of elegance, I'm not a js expert):
>>>
>>> if (typeof(Wicket) != "undefined") {
>>> if (typeof(Wicket.Focus) != "undefined") {
>>> // Deregister old attachFocusEvent function
>>> handlers = Wicket.Event.domReadyHandlers;
>>> filteredHandlers = new Array();
>>> for(i = 0; i < handlers.length; i++) {
>>> if (handlers[i] != Wicket.Focus.attachFocusEvent) {
>>> filteredHandlers.push(handlers[i]);
>>> }
>>> }
>>> Wicket.Event.domReadyHandlers = filteredHandlers;
>>>
>>> // Redefine and re-register attachFocusEvent
Re: wicket-ajax and IE performance problems for pages with many links
I have written a simple WicketAjaxJsPatch Behavior which simply adds
the aforementioned javascript to the page.
In our application, we have several pages that suffer from the same problem.
It would be tedious to have to update all of these pages one-by-one.
So is there any way for me to add this Behavior to my parent page
(which other pages extend) and still have the javascript rendered last
in the head?
regards, Peter
2009/4/17 Peter Gardfjäll :
> Thanks Igor,
>
> the suggested workaround seems to work fine. However, it is not enough
> to just override the attachFocusEvent function -- you also need to
> deregister the previously registered function. I did as follows (I
> apologize for the lack of elegance, I'm not a js expert):
>
> if (typeof(Wicket) != "undefined") {
> if (typeof(Wicket.Focus) != "undefined") {
> // Deregister old attachFocusEvent function
> handlers = Wicket.Event.domReadyHandlers;
> filteredHandlers = new Array();
> for(i = 0; i < handlers.length; i++) {
> if (handlers[i] != Wicket.Focus.attachFocusEvent) {
> filteredHandlers.push(handlers[i]);
> }
> }
> Wicket.Event.domReadyHandlers = filteredHandlers;
>
> // Redefine and re-register attachFocusEvent
> Wicket.Focus.attachFocusEvent=function() {
> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("input"));
> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("select"));
>
> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("textarea"));
>
> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("button"));
> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("a"));
> }
> Wicket.Event.addDomReadyEvent(Wicket.Focus.attachFocusEvent);
> }
> }
>
>
> By the way, I believe that this is, or has the potential of becoming,
> a major stumbling block for others.
> Should it be regarded as a bug?
>
> kind regards, Peter
>
>
> On Thu, Apr 16, 2009 at 6:23 PM, Igor Vaynberg
> wrote:
>> you can try adding this to the head after wicket-ajax.js
>>
>>
Re: wicket-ajax and IE performance problems for pages with many links
Thanks Igor,
the suggested workaround seems to work fine. However, it is not enough
to just override the attachFocusEvent function -- you also need to
deregister the previously registered function. I did as follows (I
apologize for the lack of elegance, I'm not a js expert):
if (typeof(Wicket) != "undefined") {
if (typeof(Wicket.Focus) != "undefined") {
// Deregister old attachFocusEvent function
handlers = Wicket.Event.domReadyHandlers;
filteredHandlers = new Array();
for(i = 0; i < handlers.length; i++) {
if (handlers[i] != Wicket.Focus.attachFocusEvent) {
filteredHandlers.push(handlers[i]);
}
}
Wicket.Event.domReadyHandlers = filteredHandlers;
// Redefine and re-register attachFocusEvent
Wicket.Focus.attachFocusEvent=function() {
Wicket.Focus.setFocusOnElements(document.getElementsByTagName("input"));
Wicket.Focus.setFocusOnElements(document.getElementsByTagName("select"));
Wicket.Focus.setFocusOnElements(document.getElementsByTagName("textarea"));
//Wicket.Focus.setFocusOnElements(document.getElementsByTagName("button"));
//Wicket.Focus.setFocusOnElements(document.getElementsByTagName("a"));
}
Wicket.Event.addDomReadyEvent(Wicket.Focus.attachFocusEvent);
}
}
By the way, I believe that this is, or has the potential of becoming,
a major stumbling block for others.
Should it be regarded as a bug?
kind regards, Peter
On Thu, Apr 16, 2009 at 6:23 PM, Igor Vaynberg wrote:
> you can try adding this to the head after wicket-ajax.js
>
>
Re: wicket-ajax and IE performance problems for pages with many links
Hi James,
I'm pretty sure that links are part of the problem.
To verify this, try replacing all tags with e.g. and see if
you can spot any difference in response time.
Alternatively, try replacing/commenting out ajax components/behaviors
on your page to prevent wicket-ajax.js from being pulled into the
page.
cheers, Peter
On Thu, Apr 16, 2009 at 3:52 PM, James Carman
wrote:
> Peter,
> I have experienced similar problems just recently. I didn't narrow it down
> to the fact that the links were the problem, as you have, though! I have
> been racking my brains trying to figure this thing out. My page is similar,
> a table with lots of cells in them that are links. I've turned off CSS and
> other stuff trying to find the bottleneck. I didn't think for a moment that
> it might be the links.
>
> James
>
> 2009/4/16 Peter Gardfjäll
>
>> Hi all,
>>
>> I am working on a wicket application intended to be executed both on
>> FF3 and IE7.
>> While working on this application I have discovered that the rendering
>> of some pages are a lot slower in IE.
>> The pages that were significantly slower on IE have a couple of things
>> in common: they are ajax-enabled and have lots of links.
>> These pages all appear to freeze for a while after all data has been
>> transferred, but before the page becomes responsive.
>>
>> The reason (or at least one of the reasons) is that wicket-ajax.js,
>> which gets pulled in whenever an Ajax component/behavior is added to a
>> page, registers a function
>> (addDomReadyEvent(Wicket.Focus.attachFocusEvent)) that traverses all
>> {input,select,a,textarea,button} tags in the DOM tree when the page
>> has been loaded.
>>
>> I timed this function for one of my pages (containing a single big
>> table with around 300 rows, with each row having about six links).
>> When the function is registered, the fireDomReadyHandlers in
>> wicket-event.js takes 2400 ms to execute, compared to 700 ms when not
>> registered. In firefox, the corresponding numbers are about 470 ms and
>> 400 ms.
>>
>> Hence, there seems to be quite a performance penalty involved in
>> loading ajax pages with lots of links in IE7.
>> I'm a bit worried about this overhead, particularly since I have a
>> rather fast machine (a lot better than most of the end users anyway).
>> I would not be surprised if clients see double page load times.
>>
>> Have anyone on this list experienced similar problems?
>> Is this a known issue? (I have not been able to find anything similar
>> on the mailing list)
>> Any suggestions or pointers are welcome.
>>
>> best regards, Peter
>>
>> /PS By the way, I am using wicket 1.3.5.
>>
>> -
>> 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
wicket-ajax and IE performance problems for pages with many links
Hi all,
I am working on a wicket application intended to be executed both on
FF3 and IE7.
While working on this application I have discovered that the rendering
of some pages are a lot slower in IE.
The pages that were significantly slower on IE have a couple of things
in common: they are ajax-enabled and have lots of links.
These pages all appear to freeze for a while after all data has been
transferred, but before the page becomes responsive.
The reason (or at least one of the reasons) is that wicket-ajax.js,
which gets pulled in whenever an Ajax component/behavior is added to a
page, registers a function
(addDomReadyEvent(Wicket.Focus.attachFocusEvent)) that traverses all
{input,select,a,textarea,button} tags in the DOM tree when the page
has been loaded.
I timed this function for one of my pages (containing a single big
table with around 300 rows, with each row having about six links).
When the function is registered, the fireDomReadyHandlers in
wicket-event.js takes 2400 ms to execute, compared to 700 ms when not
registered. In firefox, the corresponding numbers are about 470 ms and
400 ms.
Hence, there seems to be quite a performance penalty involved in
loading ajax pages with lots of links in IE7.
I'm a bit worried about this overhead, particularly since I have a
rather fast machine (a lot better than most of the end users anyway).
I would not be surprised if clients see double page load times.
Have anyone on this list experienced similar problems?
Is this a known issue? (I have not been able to find anything similar
on the mailing list)
Any suggestions or pointers are welcome.
best regards, Peter
/PS By the way, I am using wicket 1.3.5.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
