> the browser. do you have a proxy between the servlet container and the
> outside? maybe something is injecting a redirect or something weird.

I did wonder if there was weird redirect issue, but after doing a lot
of reading yesterday it seems the xmlrequest object *should* handle
redirects fine. However either way we're not doing anything like that.
We've got a couple of tomcat instances load balanced through apache,
routed via a hardware firewall and out of the datacenter, so no
proxies or anything at least I'm aware of.

Its very frustrating.



On Sun, Nov 7, 2010 at 9:41 PM, Igor Vaynberg <igor.vaynb...@gmail.com> wrote:
> the only way i can see that happenning if the url is no longer
> processed by wicket's ajax support and so the response just ends up in
> the browser. do you have a proxy between the servlet container and the
> outside? maybe something is injecting a redirect or something weird.
>
> -igor
>
> On Sun, Nov 7, 2010 at 8:26 AM, Wayne W <waynemailingli...@gmail.com> wrote:
>> thanks Igor,
>>
>> I've just spent a few hours stepping though the code and I cannot see
>> anyway the content type could be set wrong - I see the content type is
>> set in the final respond(requestCycle) method, so I'm now thinking
>> this is not a content type issue.
>>
>> However we just got another user email with a screen shot showing the
>> wicket ajax-response in the browser so something is up.
>>
>> My javascript knowledge is weak at best so I've not been able to tell
>> much from the js .
>>
>> Any ideas on how we can resolve this or at least get more info?
>> many thanks
>>
>>
>>
>>
>> On Sat, Nov 6, 2010 at 6:40 PM, Igor Vaynberg <igor.vaynb...@gmail.com> 
>> wrote:
>>> see AjaxRequestTarget class, this is where the response is generated
>>> on the serverside
>>>
>>> wicket-ajax.js is where it is processed on the client side.
>>>
>>> -igor
>>>
>>> On Sat, Nov 6, 2010 at 2:49 AM, Wayne W <waynemailingli...@gmail.com> wrote:
>>>> Hi Igor,
>>>>
>>>> Whats odd is that one guy was getting it on his iPad consistently and
>>>> when we asked him to try his desktop he's got the same problem on
>>>> Firefox on Mac. We initially though it might have been a browser
>>>> issue. We then got another user who got it only once on Chrome on
>>>> windows - all in the space of 1 day. We're worried that's it happening
>>>> more often but users are not reporting the issue.
>>>>
>>>> Of course we cannot reproduce the issue, but its definitely happening.
>>>>
>>>> So you don;t think the shared resource could effect the threads in any way?
>>>>
>>>> Where can I start looking in the wicket code to understand where ajax
>>>> requests are serviced etc? Is there any where/docs I can find to get
>>>> started at looking at this? -  at least to complete more my
>>>> understanding of how it all works.
>>>>
>>>> thanks
>>>> Wayne
>>>>
>>>> On Fri, Nov 5, 2010 at 10:05 PM, Igor Vaynberg <igor.vaynb...@gmail.com> 
>>>> wrote:
>>>>> it may be a content type issue, but it is still weird because the
>>>>> response is received by the xml http request object, not the browser
>>>>> directly. strange indeed.
>>>>>
>>>>> -igor
>>>>>
>>>>> On Fri, Nov 5, 2010 at 7:51 AM, Wayne W <waynemailingli...@gmail.com> 
>>>>> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> has anyone had this issue? We're getting emails from our users that
>>>>>> sometime when clicking on an ajax link the raw wicket ajax response is
>>>>>> being rendered on the browser - ie the just see all the html source
>>>>>> code on the page. Its not any particular page.
>>>>>>
>>>>>> Anyone seen this or has any ideas?
>>>>>>
>>>>>>
>>>>>> The only thing we have changed recently was adding a non blocking file
>>>>>> download using a link and a shared resource which could be related due
>>>>>> to the Content Type.
>>>>>> In the configureResponse of the shared resource that we set the
>>>>>> Content Type for that request. Is there any chance that this is
>>>>>> somehow polluting the other threads requests?
>>>>>>
>>>>>> public class DownloadFileResourceReference extends ResourceReference {
>>>>>>        public DownloadFileResourceReference() {
>>>>>>                super(DownloadLink.class, "");
>>>>>>        }
>>>>>>
>>>>>>        private static final long serialVersionUID = 1L;
>>>>>>
>>>>>>        public Resource newResource() {
>>>>>>
>>>>>>                Resource r =  new Resource() {
>>>>>>                        private static final long serialVersionUID = 1L;
>>>>>>
>>>>>>                        public IResourceStream getResourceStream() {
>>>>>>
>>>>>>                                        Long id = 
>>>>>> getParameters().getLong(DownloadLink.DOCID);
>>>>>>                                        // get file
>>>>>>
>>>>>>                                        return new FileResourceStream(new 
>>>>>> File(file.getAbsolutePath()));
>>>>>>                        }
>>>>>>
>>>>>>
>>>>>>                        protected void configureResponse(Response 
>>>>>> response) {
>>>>>>
>>>>>>                                Long id = 
>>>>>> getParameters().getLong(DownloadLink.DOCID);
>>>>>>
>>>>>>                                // get file
>>>>>>
>>>>>>                                ((WebResponse) 
>>>>>> response).setAttachmentHeader(df.getFileName());
>>>>>>
>>>>>>                                String mimeType = 
>>>>>> ResourceHelper.getContentType(df.getFileName());
>>>>>>                                if (!StringUtils.isEmpty(mimeType)) {
>>>>>>                                        ((WebResponse) 
>>>>>> response).setContentType(mimeType);
>>>>>>                                }
>>>>>>
>>>>>>                        }
>>>>>>
>>>>>>                };
>>>>>>                r.setCacheable(false);
>>>>>>                return r;
>>>>>>        }
>>>>>>
>>>>>> }
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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

Reply via email to