[
https://issues.apache.org/jira/browse/WICKET-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Vaynberg updated WICKET-1910:
----------------------------------
Fix Version/s: (was: 1.4-RC2)
1.5-M1
Remaining Estimate: (was: 1h)
Original Estimate: (was: 1h)
moving this issue to 1.5
we cannot cache the value in 1.4 because it breaks wicket tester. the problem
is wicket-tester reuses request objects so they can be created without
wicket-ajax header in which case calling isajax() returns false but later the
header is added manually - which no longer helps since isajax()'s false value
has been cached for the lifetime of the request instance.
this is purely a problem with wickettester being the way that it is but we
cannot change that functionality because it will break any existing ajax tests.
so in 1.5 we will have to fix this properly.
> ServletWebRequest.isAjax Should be cached
> -----------------------------------------
>
> Key: WICKET-1910
> URL: https://issues.apache.org/jira/browse/WICKET-1910
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.4-M3
> Environment: Any
> Reporter: Martin Makundi
> Assignee: Igor Vaynberg
> Priority: Minor
> Fix For: 1.5-M1
>
> Attachments: profile.png
>
>
> I was profiling my Wicket application and noticed that Jetty's
> getHeader method was hit quite often.
> It turns out the ServletWebRequest.isAjax method is hit quite often by
> each of the page elements (I am generating a large HTML report page).
> Since the Servlet container may not have optimal design for processing
> the getHeader method, I wonder if the ServletWebRequest.isAjax -method
> could/should be cached within wicket.
> I made the following modification to the ServletWebRequest.isAjax
> method, and measured a notable increase in performance:
> public boolean isAjax() {
> if (ajax == null) {
> ajax = false;
> String ajaxHeader = httpServletRequest.getHeader("Wicket-Ajax");
> if (Strings.isEmpty(ajaxHeader) == false)
> {
> try
> {
> ajax = Strings.isTrue(ajaxHeader);
> }
> catch (StringValueConversionException e)
> {
> // We are not interested in this exception but we log it anyway
> log.debug("Couldn't convert the Wicket-Ajax header: " + ajaxHeader);
> }
> }
> }
> return ajax;
> }
> However, my question remains: is this a valid optimization or does it
> break the Wicket framework? Should it somehow be incorporated in the
> next releases?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
