So, I tried one more thing that worked...
setResponsePage(new RedirectPage(somePage));
The first time I tried it was without using the RedirectPage class.
J.D.
On 1/3/13 4:15 PM, "Corbin, James" wrote:
>Hi Sven,
>
>I did try redirecting a couple of ways with no success. I tried throwin
Hi Sven,
I did try redirecting a couple of ways with no success. I tried throwing
a RestartResponseException which didn't work, then tried
setResponsePage(Š) to the same page and that didn't work either. I was
still forced to press the "Clear" action again to see the cookies
disappear.
J.D.
Thanks to you both for you help.
Here's what I did so far:
-Upgraded from TomEE 1.0.0 to 1.5.1 (not sure if that made a change, but
it was a todo anyway)
-Removing the seam-conversation-weld dependency
-Finally, added the following section to my pom:
cdi-api
javax.enterpr
Thanks Sven. I wasn't sure if I could do so without a page reload, but I
think it is okay in this case.
J.D.
On 1/3/13 1:04 PM, "Sven Meier" wrote:
>Hi James,
>
>deleting a cookie on the response doesn't change the cookies in the HTTP
>request.
>
>A redirect should help to get a fresh cooki
Hi again,
Just wanted to update that the issue is resolved. There was a custom script
that sets the content type of AJAX on jQuery.$ to be text/plain and it had
a side effect.
Sorry for the inconvenience.
Regards,
Behrooz
On Thu, Jan 3, 2013 at 9:01 PM, Behrooz Nobakht wrote:
> Hi again,
>
Hi James,
deleting a cookie on the response doesn't change the cookies in the HTTP
request.
A redirect should help to get a fresh cookie list from the browser.
Sven
On 01/03/2013 08:29 PM, Corbin, James wrote:
This is a rehash of a previous discussion on this forum relating to immediate
re
Hi again,
I tried the quick start application and tracked down the issue to this.
When a selection is changed (using FireBug/Chrome),
* in the quick start application, I see that of the request is
Content-Type:
application/x-www-form-urlencoded; charset=UTF-8
* in my application, I see that the
This is a rehash of a previous discussion on this forum relating to immediate
removal of a browser cookie.
I have a list view that displays data loaded from 1 or more browser cookies.
On this panel I also have a "clear" action (Link) that when clicked deletes the
cookies. The underlying list
Thanks for clarifying.
I tested a bit with the new bean-validation module and so far everything
seems to be working.
2013/1/3 Igor Vaynberg
> there are some incompatibilities. ive optimized some code to make it
> faster and remove some other code that i do not thing belongs.
>
> so, no, it is n
there are some incompatibilities. ive optimized some code to make it
faster and remove some other code that i do not thing belongs.
so, no, it is not a drop in replacement
and, yes, this code deprecates the net.ftlines code for wicket 6+
-igor
On Thu, Jan 3, 2013 at 3:44 AM, heapifyman wrote:
>
Hi,
I've also tested without the prefix input name and it's still the same.
Thanks,
Behrooz
On Thu, Jan 3, 2013 at 9:08 AM, Martin Grigorov wrote:
> Hi,
>
> If you are able to reproduce the problem in a quickstart application then
> please attach it to a ticket in Jira.
> But I guess the prob
Thanks Martin,
I'll take a look at those,
Cheers
Simon
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/ResourceAggregator-in-Wicket-6-x-tp4655125p4655137.html
Sent from the Users forum mailing list archive at Nabble.com.
-
I think it is safe to use the new one.
On Thu, Jan 3, 2013 at 1:44 PM, heapifyman wrote:
> Hello,
>
> I've been using net.ftlines.wicket-bean-validation for a while now and I
> suppose that the new experimantal org.apache.wicket.wicket-bean-validation
> is based on the ftlines version and will
Hello,
I've been using net.ftlines.wicket-bean-validation for a while now and I
suppose that the new experimantal org.apache.wicket.wicket-bean-validation
is based on the ftlines version and will eventually replace it (at least
for wicket 6 and above)?
Can I just replace the ftlines version with t
Hi,
Check this article:
http://blog.agilecoders.de/index.php/2012/12/best-practices-for-speeding-up-your-wicket6-pages-part-1/
https://github.com/l0rdn1kk0n/wicket-bootstrap/blob/master/samples/src/main/java/de/agilecoders/wicket/samples/WicketApplication.java
shows
how to use it.
On Wed, Jan 2,
Hi,
If you are able to reproduce the problem in a quickstart application then
please attach it to a ticket in Jira.
But I guess the problem is related to the custom prefix you use (#
getInputNamePrefix()).
In FormComponent#getInputAsArray() check what is the inputName and compare
it against the on
Hi,
CookieValuePersister tells me that you use Wicket 1.4 or earlier.
1.4.x is not supported anymore. You are recommended to upgrade.
Additionally the stacktrace says that Tomcat doesn't allow the problematic
character.
Better ask in Tomcat's users@ mailing list about this restriction. I guess
so
17 matches
Mail list logo
