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