You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Martin Geisse <ma...@googlemail.com> on 2013/03/10 15:46:13 UTC
atmosphere: urls erased from response
Hi,
sorry if this mail arrives twice, but the mailing list seems to have dropped the first one.
I'm having problems with wicket-atmosphere. It seems like the various urlFor() methods return null when called from the "artificial" request cycle that gets triggered by EventBus.post(Object). Specifically, I have traced down the problem to be encodeUrl() returning null in such a case, which I *think* comes from the fake HttpServletResponse defined at the top of AtmosphereResponse. That class seems to be lacking other important methods as well.
I was able to reproduce the problem in the example from https://github.com/papegaaij/wicket-atmosphere-quickstart -- just add a Link<Void> with an empty onClick() handler to the page, setOutputMarkupId(true) and re-render the link in the subscribed methods. The link will appear correctly on the page when it is first requested, but the href attribute turns to nothing (null) when the link gets re-rendered.
As far as I can tell, Atmosphere uses WebSockets in my experiment.
So far I have been unsuccessful in building a workaround. Atmosphere seems to be especially stubborn about using that fake HttpServletResponse implementation, even though it is missing all important features. The wicket-atmosphere module isn't easily modified either -- both AtmosphereWebResponse and the relevant methods in EventBus are private. Short of actually building my own modified version of it, I can't seem to make it work.
Any ideas?
Greetings,
Martin Geisse
Re: atmosphere: urls erased from response
Posted by Martin Geisse <ma...@googlemail.com>.
Thank you very much. After reading the bugs you linked to, I ended up using an older version of Atmosphere (not wicket-atmosphere) -- atmosphere 1.0.9 -- and it works fine now.
Greetings,
Martin Geisse
On Mar 11, 2013, at 10:58 AM, Martin Grigorov wrote:
> Hi,
>
> This is a known bug in Atmosphere.
> https://github.com/Atmosphere/atmosphere/issues/949
> https://issues.apache.org/jira/browse/WICKET-5084
>
> I think you can use the previous version of wicket-atmosphere until the fix
> is incorporated.
>
>
> On Sun, Mar 10, 2013 at 4:46 PM, Martin Geisse
> <ma...@googlemail.com>wrote:
>
>> Hi,
>>
>> sorry if this mail arrives twice, but the mailing list seems to have
>> dropped the first one.
>>
>> I'm having problems with wicket-atmosphere. It seems like the various
>> urlFor() methods return null when called from the "artificial" request
>> cycle that gets triggered by EventBus.post(Object). Specifically, I have
>> traced down the problem to be encodeUrl() returning null in such a case,
>> which I *think* comes from the fake HttpServletResponse defined at the top
>> of AtmosphereResponse. That class seems to be lacking other important
>> methods as well.
>>
>> I was able to reproduce the problem in the example from
>> https://github.com/papegaaij/wicket-atmosphere-quickstart -- just add a
>> Link<Void> with an empty onClick() handler to the page,
>> setOutputMarkupId(true) and re-render the link in the subscribed methods.
>> The link will appear correctly on the page when it is first requested, but
>> the href attribute turns to nothing (null) when the link gets re-rendered.
>>
>> As far as I can tell, Atmosphere uses WebSockets in my experiment.
>>
>> So far I have been unsuccessful in building a workaround. Atmosphere seems
>> to be especially stubborn about using that fake HttpServletResponse
>> implementation, even though it is missing all important features. The
>> wicket-atmosphere module isn't easily modified either -- both
>> AtmosphereWebResponse and the relevant methods in EventBus are private.
>> Short of actually building my own modified version of it, I can't seem to
>> make it work.
>>
>> Any ideas?
>>
>> Greetings,
>> Martin Geisse
>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com <http://jweekend.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: atmosphere: urls erased from response
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
This is a known bug in Atmosphere.
https://github.com/Atmosphere/atmosphere/issues/949
https://issues.apache.org/jira/browse/WICKET-5084
I think you can use the previous version of wicket-atmosphere until the fix
is incorporated.
On Sun, Mar 10, 2013 at 4:46 PM, Martin Geisse
<ma...@googlemail.com>wrote:
> Hi,
>
> sorry if this mail arrives twice, but the mailing list seems to have
> dropped the first one.
>
> I'm having problems with wicket-atmosphere. It seems like the various
> urlFor() methods return null when called from the "artificial" request
> cycle that gets triggered by EventBus.post(Object). Specifically, I have
> traced down the problem to be encodeUrl() returning null in such a case,
> which I *think* comes from the fake HttpServletResponse defined at the top
> of AtmosphereResponse. That class seems to be lacking other important
> methods as well.
>
> I was able to reproduce the problem in the example from
> https://github.com/papegaaij/wicket-atmosphere-quickstart -- just add a
> Link<Void> with an empty onClick() handler to the page,
> setOutputMarkupId(true) and re-render the link in the subscribed methods.
> The link will appear correctly on the page when it is first requested, but
> the href attribute turns to nothing (null) when the link gets re-rendered.
>
> As far as I can tell, Atmosphere uses WebSockets in my experiment.
>
> So far I have been unsuccessful in building a workaround. Atmosphere seems
> to be especially stubborn about using that fake HttpServletResponse
> implementation, even though it is missing all important features. The
> wicket-atmosphere module isn't easily modified either -- both
> AtmosphereWebResponse and the relevant methods in EventBus are private.
> Short of actually building my own modified version of it, I can't seem to
> make it work.
>
> Any ideas?
>
> Greetings,
> Martin Geisse
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com <http://jweekend.com/>