Re: Wicket Example
How do I get off this list? I've emailed users-unsubscr...@wicket.apache.org and I'm still on it. Could be an email alias thing. Can anybody help? ᐧ On Mon, Oct 30, 2017 at 3:49 PM, Andrea Del Bene wrote: > hi, > > use http://examples7x.wicket.apache.org/wicket-examples/index.html > > Thank you for pointing that out, I'm fixing the link. > > > On 30/10/2017 21:00, Mihir Chhaya wrote: > >> Hello, >> >> Live Examples link on https://wicket.apache.org/ is throwing 404 error. >> Could anybody please direct me to working link? >> >> Thanks, >> -Mihir. >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Can't post variables to a wicket page
I'm trying to support both get and post to a wicket page. When I do a post, the containterRequest object is reporting it as a GET and I can't seem to find my post variables. What am I missing? --- Douglas W. Ferguson Software Development Manager Escalation Point, Inc. dfergu...@escalation-point.com www.escalation-point.com mobile: 512-293-7279 office: 512-524-4510
download page
I've done downloads before in wicket by creating a resource stream, but this requires a user to click on a button or some other ajax. I'd like to create a page that will stream content back to the user based on parameters. This means I'd have bookmarkable urls for download and it would be secured based on my wicket authentication. I assuming I can just get hold of the response from the RequestCycle to stream the bytes. But I'm not sure the how to create a page without markup and also prevent wicket from trying to write to the response. Douglas - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket 6 beta3 -> wicket 6
Ok.. I figured it out. beta3 was SUPER lenient apparently. One of the guys on my team, had sub classed AjaxTabbedPanel and instead of putting the wrote: > Thanks.. I'll check it out. I don't think that would cause these problems. :) > > It's as if the wicket can't see any of the wicket:ids.. > > Did anything change with regards to enclosures? Or child & extend? > > Douglas > > On Sep 27, 2012, at 9:24 AM, Jesse Long wrote: > >> WebSession#authenticate() disappeared after 6.0.0-beta3. Affected me... >> >> Cheers, >> Jesse >> >> On 27/09/2012 14:41, Douglas Ferguson wrote: >>> That may take some time, there are some layers.. >>> >>> I just was curious if there are any known issues from beta3 to the stable >>> release. >>> >>> Douglas >>> >>> On Sep 27, 2012, at 7:36 AM, Thomas Götz wrote: >>> >>>> Please show us some code or create a Quickstart that demonstrates the >>>> problem, else it will be very hard to help you. >>>> >>>> >>>> On 27.09.2012, at 14:23, Douglas Ferguson wrote: >>>> >>>>> I just tried to upgrade from beta3 to wicket 6 and one of my main pages >>>>> blows up with a vengeance. >>>>> >>>>> It's the typical error indicating that something is in the code but now >>>>> the markup and it lists out almost every field! >>>>> You guys have any idea what might cause this? >>>>> >>>>> Works fine under beta3... >>>>> >>>>> Douglas >>>> >>>> >>>> - >>>> 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
Re: sicket 6 beta3 -> wicket 6
Thanks.. I'll check it out. I don't think that would cause these problems. :) It's as if the wicket can't see any of the wicket:ids.. Did anything change with regards to enclosures? Or child & extend? Douglas On Sep 27, 2012, at 9:24 AM, Jesse Long wrote: > WebSession#authenticate() disappeared after 6.0.0-beta3. Affected me... > > Cheers, > Jesse > > On 27/09/2012 14:41, Douglas Ferguson wrote: >> That may take some time, there are some layers.. >> >> I just was curious if there are any known issues from beta3 to the stable >> release. >> >> Douglas >> >> On Sep 27, 2012, at 7:36 AM, Thomas Götz wrote: >> >>> Please show us some code or create a Quickstart that demonstrates the >>> problem, else it will be very hard to help you. >>> >>> >>> On 27.09.2012, at 14:23, Douglas Ferguson wrote: >>> >>>> I just tried to upgrade from beta3 to wicket 6 and one of my main pages >>>> blows up with a vengeance. >>>> >>>> It's the typical error indicating that something is in the code but now >>>> the markup and it lists out almost every field! >>>> You guys have any idea what might cause this? >>>> >>>> Works fine under beta3... >>>> >>>> Douglas >>> >>> >>> - >>> 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
Re: sicket 6 beta3 -> wicket 6
That may take some time, there are some layers.. I just was curious if there are any known issues from beta3 to the stable release. Douglas On Sep 27, 2012, at 7:36 AM, Thomas Götz wrote: > Please show us some code or create a Quickstart that demonstrates the > problem, else it will be very hard to help you. > > > On 27.09.2012, at 14:23, Douglas Ferguson wrote: > >> I just tried to upgrade from beta3 to wicket 6 and one of my main pages >> blows up with a vengeance. >> >> It's the typical error indicating that something is in the code but now the >> markup and it lists out almost every field! >> You guys have any idea what might cause this? >> >> Works fine under beta3... >> >> Douglas > > > > - > 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
sicket 6 beta3 -> wicket 6
I just tried to upgrade from beta3 to wicket 6 and one of my main pages blows up with a vengeance. It's the typical error indicating that something is in the code but now the markup and it lists out almost every field! You guys have any idea what might cause this? Works fine under beta3... Douglas - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: FormTester - wicket 1.6
I got it to work using this: tester.startComponentInPage(tester.getComponentFromLastRenderedPage(myPanel)); Does this ring any bells? Martin do you want to see the test code or the app code as well? The app code uses alot of custom components, so I'd prolly want to figure out tease things out and figure out what's causing the problem before dumping all that in your lap. Douglas On Jul 31, 2012, at 2:17 AM, Martin Grigorov wrote: > Show us some code. > > On Tue, Jul 31, 2012 at 1:50 AM, Douglas Ferguson wrote: >> We are trying to write some tests using FormTester. >> >> We are setting values on a text field and then submitting the form. >> The form is erroring out because the field is required. >> >> Does anybody have any ideas why the value is not getting set properly? >> >> Douglas >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> > > > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.com > > - > 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
FormTester - wicket 1.6
We are trying to write some tests using FormTester. We are setting values on a text field and then submitting the form. The form is erroring out because the field is required. Does anybody have any ideas why the value is not getting set properly? Douglas - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Apache Wicket 6.0.0-beta3 is released
How long should it take for this to appear in maven central?
I currently don't see it there...
http://mvnrepository.com/artifact/org.apache.wicket/wicket-core
On Jul 17, 2012, at 4:08 AM, Martijn Dashorst wrote:
> The Wicket team is proud to announce the third beta release of
> the Wicket 6.x series. This release is an intermediary release
> just before we give you 6.0.0 final.
>
> There are no more planned API breaks but if you find something
> that can be made better now it the time to discuss it! The
> next planned release is 6.0.0 final, so speak now or forever
> be silenced (or learn to live with it until 7.0.0 comes out).
>
> Any feedback about the new features, their implementation and
> their documentation is very welcome!
>
> New and Noteworthy in 6.0.0-beta3
> =
>
> ** NOTA BENE: ** the use of modules that are marked experimental,
> by being part of the sub module 'wicket-experimental', are really
> that: experimental. These modules can change, disappear or blow up
> your computer without notice and you really use/depend on them at
> your own risk.
>
> Wicket Native Websockets
>
>
> A new **experimental** module has been added to Wicket 6 - Wicket
> Native WebSocket. This module adds support for using HTML5
> WebSockets as you may use Ajax in your Wicket applications.
>
> All you have to do is to add a WebSocketBehavior to your page and from
> there on you can receive messages from the clients and push messages
> back to them.
>
> At https://cwiki.apache.org/confluence/x/0vSoAQ you may find the
> documentation and a link to a demo application.
>
> If something is not clear feel free to ask your question in the
> mailing lists and we will improve the documentation.
>
> Wicket Bootstrap
>
>
> The **experimental** modules now contain a new module for integration
> with Twitter's Bootstrap. Currently this module only provides a
> central way of using the Bootstrap resources. In the future we
> will provide proper components and behaviors for the Bootstrap
> concepts.
>
> To use this new **experimental** module, add this to your pom:
>
>
>org.apache.wicket
>wicket-bootstrap
>0.1
>
>
> To add Bootstrap support to your pages, add this in the `renderHead`
> method:
>
>@Override
>public void renderHead(IHeaderResponse response) {
>super.renderHead(response);
>
>Bootstrap.renderHead(response);
>}
>
> This will render a dependency to the Twitter bootstrap CSS and JS files,
> including the required dependency to JQuery.
>
> New Wicket Examples
> ---
> We have started an effort to revamp the tried and tested Wicket Examples
> and bring them into 2012. The new examples are located in the
> **experimental** module.
>
> It is currently a copy of Twitter Bootstrap's design but with Wicket
> specific filling.
>
> You can test the examples by running the
>
>wicket-examples-jar/src/test/java/Start.java
>
> class in the default package.
>
> The examples will feature a component reference with typical use
> cases, full examples such as Hello, World, and descriptions of the
> code in play.
>
> Wicket Atmosphere
> -
>
> Wicket Atmosphere in the experimental modules has seen an upgrade of
> the Atmosphere dependency to 1.0.0-beta3. This has caused an
> incompatibility with Jetty 7.6.3 (used with Wicket and the examples). To
> mitigate this, you need to override either:
>
> - the dependency on Jetty to 8.1.3 or newer, or
> - the dependency on Atmosphere to 0.9.5 (0.9.6 and 0.9.7 are broken as
> well)
>
> See https://issues.apache.org/jira/browse/WICKET-4656 for more
> information regarding this issue.
>
> This release
>
>
> * Check the roadmap with a list of the major
> goals: https://cwiki.apache.org/WICKET/wicket-60-roadmap.html
>
> * And the migration guide with all major and some minor changes
> between 1.5.x and 6.x series: http://s.apache.org/wicket-6.0-migration
>
> * The Jira changelog of all closed ticket at
> Jira: http://s.apache.org/wicket-6.0.0-beta3-changelog
>
> To use it in Maven:
>
>
>org.apache.wicket
>wicket-core
>6.0.0-beta3
>
>
> If you don’t use a dependencies management build tool then you
> can download the full distribution (including source) and build from
> source yourself.
>
> Have fun,
>
> The Wicket team!
>
> -
> 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
AjaxCallThrottlingDecorator - 1.6
How do you throttle ajax calls in 1.6? Douglas - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
1.6 - Verify Error - AbstractResourceStreamWriter
java.lang.VerifyError: (class: com/visiblehealth/ui/admin/reports/SQLReports,
method: generateReport signature:
(Ljava/io/File;)Lorg/apache/wicket/core/util/resource/AbstractResourceStreamWriter;)
Wrong return type in function
at java.lang.Class.getDeclaredConstructors0(Native Method)
Anybody else seen this before?
This is my code:
AbstractResourceStreamWriter
resourceStream = generateReport(file);
String fileName =
file.getName().replaceAll(".sql$", ".csv");
ResourceStreamRequestHandler
resourceStreamRequestHandler =
new
ResourceStreamRequestHandler(resourceStream, fileName);
getRequestCycle().scheduleRequestHandlerAfterCurrent(resourceStreamRequestHandler);
with generateReport:
public AbstractResourceStreamWriter generateReport(final File file){
return new AbstractResourceStreamWriter() {
private static final long serialVersionUID = 1L;
@Override
public String getContentType() {
return "text/csv;charset=utf-8";
}
@Override
public void write(Response output) {
//write my stuff..
}
};
}
Re: Wicket Events
I was able to get the EventDispatcher to work.
I added an annotation and as well as an Enum with my EventTypes.
It works quite nicely.
Thanks for the tips.
Douglas
On Jun 19, 2012, at 7:15 PM, Douglas Ferguson wrote:
> Yeah.. when I read Jeremy's reply it was the kind of thing I was looking for
> but my understanding was that
> Jeremy was suggesting it as a possible approach. Are you saying this will
> work out of the box?
>
>
> On Jun 19, 2012, at 3:40 PM, Martin Grigorov wrote:
>
>> As the tests shows this is pluggable in Wicket.
>> There is a default impl that uses casting of the payload and there is
>> a way to setup your own impl that does it your way.
>> See Jeremy's message in this thread for a solution that works as Google's
>> one.
>>
>> On Tue, Jun 19, 2012 at 11:36 PM, Douglas Ferguson wrote:
>>> Yeah... i just don't like the idea of unpacking the payload and doing
>>> instanceOf, if/else do decide if I care about that message.
>>>
>>> The GoogleEvent buss approach seems better. I.E. Implement the specific
>>> methods for the specific event types.
>>>
>>> Douglas
>>>
>>> On Jun 19, 2012, at 3:20 PM, Martin Grigorov wrote:
>>>
>>>> Wicket always sends ComponentEvent.
>>>> The dynamic part is the event's payload.
>>>> The test shows how to receive the payload in a type-safe way.
>>>>
>>>> On Tue, Jun 19, 2012 at 11:16 PM, Douglas Ferguson
>>>> wrote:
>>>>> Ok.. So I took a look at it and it is ignoring the IEvent.
>>>>>
>>>>> I'm actually interested in how to cleanly handle multiple type of IEvents
>>>>> without having to
>>>>> do if/else or instanceOf. Was curious if anybody had a nice pattern to
>>>>> follow.
>>>>>
>>>>> @Override
>>>>> 115 public void onEvent(Component component, IEvent event)
>>>>> 116 {
>>>>> 117 invocationTimes++;
>>>>> 118 }
>>>>> 119
>>>>>
>>>>>
>>>>>
>>>>> On Jun 19, 2012, at 2:20 PM, Martin Grigorov wrote:
>>>>>
>>>>>> See org.apache.wicket.EventDispatcherTest in wicket-core's tests
>>>>>>
>>>>>> On Tue, Jun 19, 2012 at 9:58 PM, Douglas Ferguson
>>>>>> wrote:
>>>>>>> Anybody have a good pattern for using Events without having lots of
>>>>>>> instanceOf, if/else, or switch statements?
>>>>>>> -
>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Martin Grigorov
>>>>>> jWeekend
>>>>>> Training, Consulting, Development
>>>>>> http://jWeekend.com
>>>>>>
>>>>>> -
>>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Martin Grigorov
>>>> jWeekend
>>>> Training, Consulting, Development
>>>> http://jWeekend.com
>>>>
>>>> -
>>>> 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
>>>
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>> -
>> 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
Re: Wicket Events
Yeah.. when I read Jeremy's reply it was the kind of thing I was looking for
but my understanding was that
Jeremy was suggesting it as a possible approach. Are you saying this will work
out of the box?
On Jun 19, 2012, at 3:40 PM, Martin Grigorov wrote:
> As the tests shows this is pluggable in Wicket.
> There is a default impl that uses casting of the payload and there is
> a way to setup your own impl that does it your way.
> See Jeremy's message in this thread for a solution that works as Google's one.
>
> On Tue, Jun 19, 2012 at 11:36 PM, Douglas Ferguson wrote:
>> Yeah... i just don't like the idea of unpacking the payload and doing
>> instanceOf, if/else do decide if I care about that message.
>>
>> The GoogleEvent buss approach seems better. I.E. Implement the specific
>> methods for the specific event types.
>>
>> Douglas
>>
>> On Jun 19, 2012, at 3:20 PM, Martin Grigorov wrote:
>>
>>> Wicket always sends ComponentEvent.
>>> The dynamic part is the event's payload.
>>> The test shows how to receive the payload in a type-safe way.
>>>
>>> On Tue, Jun 19, 2012 at 11:16 PM, Douglas Ferguson wrote:
>>>> Ok.. So I took a look at it and it is ignoring the IEvent.
>>>>
>>>> I'm actually interested in how to cleanly handle multiple type of IEvents
>>>> without having to
>>>> do if/else or instanceOf. Was curious if anybody had a nice pattern to
>>>> follow.
>>>>
>>>>@Override
>>>> 115 public void onEvent(Component component, IEvent event)
>>>> 116 {
>>>> 117 invocationTimes++;
>>>> 118 }
>>>> 119
>>>>
>>>>
>>>>
>>>> On Jun 19, 2012, at 2:20 PM, Martin Grigorov wrote:
>>>>
>>>>> See org.apache.wicket.EventDispatcherTest in wicket-core's tests
>>>>>
>>>>> On Tue, Jun 19, 2012 at 9:58 PM, Douglas Ferguson
>>>>> wrote:
>>>>>> Anybody have a good pattern for using Events without having lots of
>>>>>> instanceOf, if/else, or switch statements?
>>>>>> -
>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Martin Grigorov
>>>>> jWeekend
>>>>> Training, Consulting, Development
>>>>> http://jWeekend.com
>>>>>
>>>>> -
>>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> Martin Grigorov
>>> jWeekend
>>> Training, Consulting, Development
>>> http://jWeekend.com
>>>
>>> -
>>> 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
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> -
> 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
Re: wicket 1.6
Cool.. that works.. On Jun 19, 2012, at 3:25 PM, Martin Grigorov wrote: > Do you hit https://issues.apache.org/jira/browse/WICKET-4581 ? > This is fixed in -SNAPSHOT > > On Tue, Jun 19, 2012 at 11:14 PM, Martin Grigorov > wrote: >> Use Jira for bug reports. >> >> On Tue, Jun 19, 2012 at 11:13 PM, Douglas Ferguson wrote: >>> Martin, >>> >>> You still up for fixing issues? We found one. ;) >>> >>> The auto complete text field throws a javascript here. >>> Would you like me to post the details here? >>> >>> Douglas >>> >>> >>> >>> On Jun 5, 2012, at 11:15 AM, Martin Grigorov wrote: >>> >>>> Hi, >>>> >>>> I think 6.0.0-beta2 is good enough for production. >>>> If you find any problems I promise I'll try to solve them as soon as >>>> possible. >>>> If there are no workarounds you may need to use 6.0-SNAPSHOT for your >>>> development until the next RC is released. >>>> >>>> On Tue, Jun 5, 2012 at 7:07 PM, Douglas Ferguson wrote: >>>>> I would be deploying my app in a couple months. Is that too aggressive >>>>> for 1.6? >>>>> >>>>> On Jun 4, 2012, at 10:32 AM, Martin Grigorov wrote: >>>>> >>>>>> On Mon, Jun 4, 2012 at 6:25 PM, Dan Tran wrote: >>>>>>> totally agree with Vineet here. >>>>>> >>>>>> The problem is that once we release the first Release Candidate it is >>>>>> not possible (recommended) to make fixes in the APIs. >>>>>> As far as I know there are no open tickets for bugs in Wicket >>>>>> 6.0.0-beta2 (released in less than a week). >>>>>> If there are no major problems I guess next release will be RC1. We >>>>>> will vote about this at dev@ mailing list. Feel free to participate! >>>>>> >>>>>>> >>>>>>> -D >>>>>>> >>>>>>> On Mon, Jun 4, 2012 at 7:59 AM, vineet semwal >>>>>>> wrote: >>>>>>>> as soon as it will be released,people will start using it ;) >>>>>>>> >>>>>>>> On Mon, Jun 4, 2012 at 8:03 PM, Martin Grigorov >>>>>>>> wrote: >>>>>>>>> As soon as people start using it and send feedback ... >>>>>>>>> >>>>>>>>> On Mon, Jun 4, 2012 at 5:29 PM, Douglas Ferguson >>>>>>>>> wrote: >>>>>>>>>> Is there a projected release date for wicket 1.6? >>>>>>>>>> >>>>>>>>>> Just curious because I'm starting a new project and am trying to >>>>>>>>>> decide if I should start it using 1.6. >>>>>>>>>> >>>>>>>>>> Douglas >>>>>>>>>> - >>>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>>>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Martin Grigorov >>>>>>>>> jWeekend >>>>>>>>> Training, Consulting, Development >>>>>>>>> http://jWeekend.com >>>>>>>>> >>>>>>>>> - >>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> thank you, >>>>>>>> >>>>>>>> regards, >>>>>>>> Vineet Semwal >>>>>>>> >>>>>>>> - >>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>>>>>> For additiona
Re: Wicket Events
Yeah... i just don't like the idea of unpacking the payload and doing
instanceOf, if/else do decide if I care about that message.
The GoogleEvent buss approach seems better. I.E. Implement the specific methods
for the specific event types.
Douglas
On Jun 19, 2012, at 3:20 PM, Martin Grigorov wrote:
> Wicket always sends ComponentEvent.
> The dynamic part is the event's payload.
> The test shows how to receive the payload in a type-safe way.
>
> On Tue, Jun 19, 2012 at 11:16 PM, Douglas Ferguson wrote:
>> Ok.. So I took a look at it and it is ignoring the IEvent.
>>
>> I'm actually interested in how to cleanly handle multiple type of IEvents
>> without having to
>> do if/else or instanceOf. Was curious if anybody had a nice pattern to
>> follow.
>>
>>@Override
>> 115 public void onEvent(Component component, IEvent event)
>> 116 {
>> 117 invocationTimes++;
>> 118 }
>> 119
>>
>>
>>
>> On Jun 19, 2012, at 2:20 PM, Martin Grigorov wrote:
>>
>>> See org.apache.wicket.EventDispatcherTest in wicket-core's tests
>>>
>>> On Tue, Jun 19, 2012 at 9:58 PM, Douglas Ferguson wrote:
>>>> Anybody have a good pattern for using Events without having lots of
>>>> instanceOf, if/else, or switch statements?
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Martin Grigorov
>>> jWeekend
>>> Training, Consulting, Development
>>> http://jWeekend.com
>>>
>>> -
>>> 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
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> -
> 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
Re: Wicket Events
Ok.. So I took a look at it and it is ignoring the IEvent.
I'm actually interested in how to cleanly handle multiple type of IEvents
without having to
do if/else or instanceOf. Was curious if anybody had a nice pattern to follow.
@Override
115 public void onEvent(Component component, IEvent event)
116 {
117 invocationTimes++;
118 }
119
On Jun 19, 2012, at 2:20 PM, Martin Grigorov wrote:
> See org.apache.wicket.EventDispatcherTest in wicket-core's tests
>
> On Tue, Jun 19, 2012 at 9:58 PM, Douglas Ferguson wrote:
>> Anybody have a good pattern for using Events without having lots of
>> instanceOf, if/else, or switch statements?
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> -
> 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
Re: Wicket Events
This seems similar to the google EventBus approach.
On Jun 19, 2012, at 2:58 PM, Jeremy Thomerson wrote:
> Have we talked about adding an IEventDispatcher that dispatches events by
> their class type based on event method signature?
>
> Example:
>
> class MyComponent {
>
> @EventListener // or some annotation
> public void onUserAddedEvent(UserAddedEvent event) {
> // do something here
> }
>
> }
>
> Then when someone calls sink(new UserAddedEvent()) it gets dispatched to
> only those methods that take a UserAddedEvent as their method argument?
>
> Would that be useful (it seems like it to me - it avoids the instanceof
> checks)? Am I off track? Is there something like this or better already
> built?
>
> An alternative would be that the annotation could take an argument of event
> class(es) that it want's to be notified of.
>
>
>
>
> --
> Jeremy Thomerson
> http://wickettraining.com
> *Need a CMS for Wicket? Use Brix! http://brixcms.org*
>
>
>
> On Tue, Jun 19, 2012 at 2:36 PM, Igor Vaynberg wrote:
>
>>
>> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.wicket/wicket-core/6.0.0-beta1/org/apache/wicket/EventDispatcherTest.java#EventDispatcherTest
>>
>> -igor
>>
>> On Tue, Jun 19, 2012 at 12:31 PM, Douglas Ferguson
>> wrote:
>>> Where's the source repository located?
>>>
>>>
>>> On Jun 19, 2012, at 2:20 PM, Martin Grigorov wrote:
>>>
>>>> See org.apache.wicket.EventDispatcherTest in wicket-core's tests
>>>>
>>>> On Tue, Jun 19, 2012 at 9:58 PM, Douglas Ferguson
>> wrote:
>>>>> Anybody have a good pattern for using Events without having lots of
>> instanceOf, if/else, or switch statements?
>>>>> -
>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Martin Grigorov
>>>> jWeekend
>>>> Training, Consulting, Development
>>>> http://jWeekend.com
>>>>
>>>> -
>>>> 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
Re: wicket 1.6
Martin, You still up for fixing issues? We found one. ;) The auto complete text field throws a javascript here. Would you like me to post the details here? Douglas On Jun 5, 2012, at 11:15 AM, Martin Grigorov wrote: > Hi, > > I think 6.0.0-beta2 is good enough for production. > If you find any problems I promise I'll try to solve them as soon as possible. > If there are no workarounds you may need to use 6.0-SNAPSHOT for your > development until the next RC is released. > > On Tue, Jun 5, 2012 at 7:07 PM, Douglas Ferguson wrote: >> I would be deploying my app in a couple months. Is that too aggressive for >> 1.6? >> >> On Jun 4, 2012, at 10:32 AM, Martin Grigorov wrote: >> >>> On Mon, Jun 4, 2012 at 6:25 PM, Dan Tran wrote: >>>> totally agree with Vineet here. >>> >>> The problem is that once we release the first Release Candidate it is >>> not possible (recommended) to make fixes in the APIs. >>> As far as I know there are no open tickets for bugs in Wicket >>> 6.0.0-beta2 (released in less than a week). >>> If there are no major problems I guess next release will be RC1. We >>> will vote about this at dev@ mailing list. Feel free to participate! >>> >>>> >>>> -D >>>> >>>> On Mon, Jun 4, 2012 at 7:59 AM, vineet semwal >>>> wrote: >>>>> as soon as it will be released,people will start using it ;) >>>>> >>>>> On Mon, Jun 4, 2012 at 8:03 PM, Martin Grigorov >>>>> wrote: >>>>>> As soon as people start using it and send feedback ... >>>>>> >>>>>> On Mon, Jun 4, 2012 at 5:29 PM, Douglas Ferguson >>>>>> wrote: >>>>>>> Is there a projected release date for wicket 1.6? >>>>>>> >>>>>>> Just curious because I'm starting a new project and am trying to decide >>>>>>> if I should start it using 1.6. >>>>>>> >>>>>>> Douglas >>>>>>> - >>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Martin Grigorov >>>>>> jWeekend >>>>>> Training, Consulting, Development >>>>>> http://jWeekend.com >>>>>> >>>>>> - >>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> thank you, >>>>> >>>>> regards, >>>>> Vineet Semwal >>>>> >>>>> - >>>>> 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 >>>> >>> >>> >>> >>> -- >>> Martin Grigorov >>> jWeekend >>> Training, Consulting, Development >>> http://jWeekend.com >>> >>> - >>> 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 >> > > > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.com > > - > 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
Re: Models and Session Size
Yes.. LoadableDetachable makes more sense. Douglas On Jun 19, 2012, at 2:17 PM, Carl-Eric Menzel wrote: > On Tue, 19 Jun 2012 14:01:13 -0500 > Douglas Ferguson wrote: > >> I was intrigued by the comment that more extensive use of Model >> would reduce session size. >> >> Why would this be? Won't models still wind up in the data graph for >> the Page and thus be in the pagemap? > > Well, apart from the fact that you should pretty much always be passing > Models around in your Wicket layer rather than bare objects, I'm almost > sure that article refers to LoadableDetachableModels. Those drop all > references at the end of the request, except for something like a > database key. In the next request, the required data is loaded again on > the fly. > > Carl-Eric > > - > 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
Re: Wicket Events
Where's the source repository located? On Jun 19, 2012, at 2:20 PM, Martin Grigorov wrote: > See org.apache.wicket.EventDispatcherTest in wicket-core's tests > > On Tue, Jun 19, 2012 at 9:58 PM, Douglas Ferguson wrote: >> Anybody have a good pattern for using Events without having lots of >> instanceOf, if/else, or switch statements? >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> > > > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.com > > - > 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
Wicket Events
Anybody have a good pattern for using Events without having lots of instanceOf, if/else, or switch statements? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Models and Session Size
I've been working in wicket for awhile now. I was just reading this post last night. http://www.small-improvements.com/10-things-about-apache-wicket-i-love/wicket:pageMapName/wicket-0 I was intrigued by the comment that more extensive use of Model would reduce session size. Why would this be? Won't models still wind up in the data graph for the Page and thus be in the pagemap? Douglas
Autocomplete when Converter not available/possible
Does anybody have a good example of using the AutoCompleteField when a Converter is not available? For example, I have a UserAccount object. I want to display "Joe Blow" with a photo on my auto suggest. But the string "Joe Blow" isn't enough information for a converter to convert back to a UserAccount. To work around this I overwrote getOnSelectJavascriptExpression and in that expression I call WicketAjaxGet() Which points to behavior and passes the id of the UserAccount. In this behavior I can look up the UserAccount and wire it up. Is there a better way to do this? Douglas - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket 1.6
I would be deploying my app in a couple months. Is that too aggressive for 1.6? On Jun 4, 2012, at 10:32 AM, Martin Grigorov wrote: > On Mon, Jun 4, 2012 at 6:25 PM, Dan Tran wrote: >> totally agree with Vineet here. > > The problem is that once we release the first Release Candidate it is > not possible (recommended) to make fixes in the APIs. > As far as I know there are no open tickets for bugs in Wicket > 6.0.0-beta2 (released in less than a week). > If there are no major problems I guess next release will be RC1. We > will vote about this at dev@ mailing list. Feel free to participate! > >> >> -D >> >> On Mon, Jun 4, 2012 at 7:59 AM, vineet semwal >> wrote: >>> as soon as it will be released,people will start using it ;) >>> >>> On Mon, Jun 4, 2012 at 8:03 PM, Martin Grigorov >>> wrote: >>>> As soon as people start using it and send feedback ... >>>> >>>> On Mon, Jun 4, 2012 at 5:29 PM, Douglas Ferguson wrote: >>>>> Is there a projected release date for wicket 1.6? >>>>> >>>>> Just curious because I'm starting a new project and am trying to decide >>>>> if I should start it using 1.6. >>>>> >>>>> Douglas >>>>> - >>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>>> >>>> >>>> >>>> >>>> -- >>>> Martin Grigorov >>>> jWeekend >>>> Training, Consulting, Development >>>> http://jWeekend.com >>>> >>>> - >>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>> >>> >>> >>> >>> -- >>> thank you, >>> >>> regards, >>> Vineet Semwal >>> >>> - >>> 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 >> > > > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.com > > - > 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
wicket 1.6
Is there a projected release date for wicket 1.6? Just curious because I'm starting a new project and am trying to decide if I should start it using 1.6. Douglas - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket & ajax push
Yeah.. I was looking at both of those. I was curious if anybody had any anecdotal or empirical evidence supporting either approach. The client is currently using a polling approach and I have some concerns about wasted resources. Also, the deadline is a little tight, so I'm not sure if I want to risk uncharted territory. Douglas On May 31, 2012, at 3:07 AM, heapifyman wrote: > If you are looking for examples, wicketstuff has a push module ( > https://github.com/wicketstuff/core/tree/master/jdk-1.6-parent/push-parent), > atmosphere examples also contain a wicket example ( > https://github.com/Atmosphere/atmosphere/tree/master/samples) and the just > released wicket 6 beta2 comes with a wicket-atmosphere module ( > http://wicket.apache.org/2012/05/29/wicket-6.0.0-beta2-released.html) > > > 2012/5/30 Douglas Ferguson > >> Anybody doing any ajax push stuff using wicket? >> >> Douglas >> >> - >> 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
wicket & ajax push
Anybody doing any ajax push stuff using wicket? Douglas - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: 1.5 Wicket Enclosure
Is this expected behavior? Is there a workaround? On Apr 5, 2012, at 6:58 PM, Douglas Ferguson wrote: > I just found a different between 1.4 and 1.5 with regards to wicket enclosure. > > If you have a component in a wicket enclosure (say a feedback panel) and you > set it visible false. > Then subsequently try to set it visible true, wicket 1.5 will not be able to > make it reappear. > > 1.4 had no problem with this. > > I get this in the debugger console: > > ERROR: Wicket.Ajax.Call.processComponent: Component with id [[id3]] was not > found while trying to perform markup update. Make sure you called > component.setOutputMarkupId(true) on the component whose markup you are > trying to update. > > Douglas
1.5 Wicket Enclosure
I just found a different between 1.4 and 1.5 with regards to wicket enclosure. If you have a component in a wicket enclosure (say a feedback panel) and you set it visible false. Then subsequently try to set it visible true, wicket 1.5 will not be able to make it reappear. 1.4 had no problem with this. I get this in the debugger console: ERROR: Wicket.Ajax.Call.processComponent: Component with id [[id3]] was not found while trying to perform markup update. Make sure you called component.setOutputMarkupId(true) on the component whose markup you are trying to update. Douglas
Using AbstractResourceStreamWriter in wicket 1.5
Can anybody give me tips on using AbstractResourceStreamWriter in 1.5? Douglas
Re: MountedMapper NullPointer
Turns out my Application.getHomePage() was returning null. On Mar 6, 2012, at 10:37 AM, Douglas Ferguson wrote: > I'm seeing this exception from time to time and I'm not sure where it's > coming from. > > java.lang.NullPointerException > at > org.apache.wicket.request.mapper.MountedMapper.checkHomePage(MountedMapper.java:459) > at > org.apache.wicket.request.mapper.MountedMapper.parseRequest(MountedMapper.java:242) > at > org.apache.wicket.request.mapper.HomePageMapper.parseRequest(HomePageMapper.java:98) > at > org.apache.wicket.request.mapper.AbstractBookmarkableMapper.mapRequest(AbstractBookmarkableMapper.java:263) > at > org.apache.wicket.request.mapper.CompoundRequestMapper.mapRequest(CompoundRequestMapper.java:131) > at > org.apache.wicket.protocol.https.HttpsMapper.mapRequest(HttpsMapper.java:91) > at > org.apache.wicket.request.cycle.RequestCycle.resolveRequestHandler(RequestCycle.java:184) > at > org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:209) > at > org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:283) > at > org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162) > at > org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:137) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) > at > org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:550) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:486) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:517) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:229) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:970) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:414) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:187) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:904) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) > at > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110) > at org.eclipse.jetty.server.Server.handle(Server.java:347) > at > org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:590) > at > org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:1054) > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:601) > at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:214) > at > org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:411) > at > org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:241) > at > org.eclipse.jetty.server.ssl.SslSocketConnector$SslConnectorEndPoint.run(SslSocketConnector.java:664) > at > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:529) > at java.lang.Thread.run(Thread.java:680)
MountedMapper NullPointer
I'm seeing this exception from time to time and I'm not sure where it's coming from. java.lang.NullPointerException at org.apache.wicket.request.mapper.MountedMapper.checkHomePage(MountedMapper.java:459) at org.apache.wicket.request.mapper.MountedMapper.parseRequest(MountedMapper.java:242) at org.apache.wicket.request.mapper.HomePageMapper.parseRequest(HomePageMapper.java:98) at org.apache.wicket.request.mapper.AbstractBookmarkableMapper.mapRequest(AbstractBookmarkableMapper.java:263) at org.apache.wicket.request.mapper.CompoundRequestMapper.mapRequest(CompoundRequestMapper.java:131) at org.apache.wicket.protocol.https.HttpsMapper.mapRequest(HttpsMapper.java:91) at org.apache.wicket.request.cycle.RequestCycle.resolveRequestHandler(RequestCycle.java:184) at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:209) at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:283) at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162) at org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:137) at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:550) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:486) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:517) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:229) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:970) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:414) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:187) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:904) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110) at org.eclipse.jetty.server.Server.handle(Server.java:347) at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:590) at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:1054) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:601) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:214) at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:411) at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:241) at org.eclipse.jetty.server.ssl.SslSocketConnector$SslConnectorEndPoint.run(SslSocketConnector.java:664) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:529) at java.lang.Thread.run(Thread.java:680)
Re: 404 on resource
How does wicket 1.5 reference resources that are inside the class path from the browser? Douglas On Mar 5, 2012, at 1:55 AM, Martin Grigorov wrote: > Hi, > > On Mon, Mar 5, 2012 at 6:05 AM, Douglas Ferguson wrote: >> Does wicket 1.5 still use the resource urls? >> >> I'm getting a 404 on this >> >> resources/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/indicator.gif > > This url is generated by Wicket 1.4.x. AFAIK you upgrade your app to > 1.5 where this URL is not handled by Wicket and thus no one knows how > to process it. > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.com > > - > 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
logging 404s
I setup a 404 handler in my web.xml to point to a wicket page. I'd like to be able to log what the original request was, but I'm having trouble figuring this out. Douglas - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
404 on resource
Does wicket 1.5 still use the resource urls? I'm getting a 404 on this resources/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/indicator.gif
Re: redirecting in IRequestCyleListener.onException
I don't have a no arg constructor, and it was blowing up trying to construct the page. On Mar 4, 2012, at 9:38 AM, vineet semwal wrote: > hi martin, > WebPage exceptionPage = new NotifyUserOfException(ex); > IPageProvider provider = new PageProvider(page); > return new RenderPageRequestHandler(provider /*, > RenderPageRequestHandler.RedirectPolicy.XYZ */ ); > > > he actually means page instance not found in page store and new page > instance is created ,the above code is breakable in the case when page > has setstatelesshint(true) or somehow it can also be broken if you > have a zero constructor in error page,you can also reproduce this > problem > > page.setstatelesshint(false) will fix the problem as it will guarantee > the page is stored i think > > > On Sun, Mar 4, 2012 at 6:59 PM, Martin Grigorov wrote: >> I'm not sure what you mean by "throws away the page". It should work. >> >> On Sat, Mar 3, 2012 at 7:19 PM, Douglas Ferguson wrote: >>> I decided to just put the exception in the session and just grab it from >>> there. >> >> Another place to put it is RequestCycle#metaData. This way you wont >> have to clean it. >> >>> >>> Douglas >>> >>> On Mar 3, 2012, at 10:26 AM, vineet semwal wrote: >>> >>>> you should also do page.setStatelessHint(false) >>>> >>>> Page page=new ClientErrorPage(ex); >>>> IPageProvider provider = new PageProvider(page); >>>> page.setStatelessHint(false); >>>> return new RenderPageRequestHandler(provider, >>>> RedirectPolicy.ALWAYS_REDIRECT); >>>> >>>> On Sat, Mar 3, 2012 at 8:23 PM, Douglas Ferguson wrote: >>>>> Yeah Martin Grigorov recomended that I do just that: >>>>> >>>>>> WebPage exceptionPage = new NotifyUserOfException(ex); >>>>>> IPageProvider provider = new PageProvider(page); >>>>>> return new RenderPageRequestHandler(provider /*, >>>>>> RenderPageRequestHandler.RedirectPolicy.XYZ */ ); >>>>> >>>>> >>>>> But I finding that it throws away the page that I pass in and just uses >>>>> the class object. >>>>> I discovered this because I don't have a default constructor so it blows >>>>> up on newInstance(). >>>>> >>>>> Douglas >>>>> >>>>> On Mar 3, 2012, at 1:36 AM, vineet semwal wrote: >>>>> >>>>>> i think scheduling is wrong in this usecase ,actually just overriding >>>>>> onexception and returning your handler like you did before should have >>>>>> worked but wait for some one else to respond if its not working >>>>>> >>>>>> On Sat, Mar 3, 2012 at 12:47 PM, Douglas Ferguson >>>>>> wrote: >>>>>>> I tried overriding onExceptionRequestHandlerResolved but I can't get >>>>>>> this to work. >>>>>>> >>>>>>> I'm still not getting my error page to load on errors. >>>>>>> >>>>>>> Douglas >>>>>>> >>>>>>> On Mar 3, 2012, at 12:36 AM, Douglas Ferguson wrote: >>>>>>> >>>>>>>> I mean "too many redirects" >>>>>>>> >>>>>>>> On Mar 3, 2012, at 12:36 AM, Douglas Ferguson wrote: >>>>>>>> >>>>>>>>> Causes an infinite loop. >>>>>>>>> >>>>>>>>> Douglas >>>>>>>>> >>>>>>>>> On Mar 3, 2012, at 12:20 AM, vineet semwal wrote: >>>>>>>>> >>>>>>>>>> i think you need to return the handler which you have scheduled >>>>>>>>>> >>>>>>>>>> On Sat, Mar 3, 2012 at 11:30 AM, Douglas Ferguson >>>>>>>>>> wrote: >>>>>>>>>>> onException() wants be to run a redirectHandler. do I just return >>>>>>>>>>> null? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Mar 2, 2012, at 11:44 PM, vineet semwal wrote: >>>>>>>>>>> >>>>>>>>>>>> you need to do >>>>>>>>>>>&
Re: redirecting in IRequestCyleListener.onException
See below: On Mar 4, 2012, at 7:29 AM, Martin Grigorov wrote: > I'm not sure what you mean by "throws away the page". It should work. What I mean is that the even thought I "new up" a page and pass the into the the PageProvider/RequestHander. It still does a Page.class.newInstance() > > On Sat, Mar 3, 2012 at 7:19 PM, Douglas Ferguson wrote: >> I decided to just put the exception in the session and just grab it from >> there. > > Another place to put it is RequestCycle#metaData. This way you wont > have to clean it. Cooll I'll give it a whirl. > >> >> Douglas >> >> On Mar 3, 2012, at 10:26 AM, vineet semwal wrote: >> >>> you should also do page.setStatelessHint(false) >>> >>> Page page=new ClientErrorPage(ex); >>> IPageProvider provider = new PageProvider(page); >>> page.setStatelessHint(false); >>> return new RenderPageRequestHandler(provider, >>> RedirectPolicy.ALWAYS_REDIRECT); >>> >>> On Sat, Mar 3, 2012 at 8:23 PM, Douglas Ferguson wrote: >>>> Yeah Martin Grigorov recomended that I do just that: >>>> >>>>> WebPage exceptionPage = new NotifyUserOfException(ex); >>>>> IPageProvider provider = new PageProvider(page); >>>>> return new RenderPageRequestHandler(provider /*, >>>>> RenderPageRequestHandler.RedirectPolicy.XYZ */ ); >>>> >>>> >>>> But I finding that it throws away the page that I pass in and just uses >>>> the class object. >>>> I discovered this because I don't have a default constructor so it blows >>>> up on newInstance(). >>>> >>>> Douglas >>>> >>>> On Mar 3, 2012, at 1:36 AM, vineet semwal wrote: >>>> >>>>> i think scheduling is wrong in this usecase ,actually just overriding >>>>> onexception and returning your handler like you did before should have >>>>> worked but wait for some one else to respond if its not working >>>>> >>>>> On Sat, Mar 3, 2012 at 12:47 PM, Douglas Ferguson >>>>> wrote: >>>>>> I tried overriding onExceptionRequestHandlerResolved but I can't get >>>>>> this to work. >>>>>> >>>>>> I'm still not getting my error page to load on errors. >>>>>> >>>>>> Douglas >>>>>> >>>>>> On Mar 3, 2012, at 12:36 AM, Douglas Ferguson wrote: >>>>>> >>>>>>> I mean "too many redirects" >>>>>>> >>>>>>> On Mar 3, 2012, at 12:36 AM, Douglas Ferguson wrote: >>>>>>> >>>>>>>> Causes an infinite loop. >>>>>>>> >>>>>>>> Douglas >>>>>>>> >>>>>>>> On Mar 3, 2012, at 12:20 AM, vineet semwal wrote: >>>>>>>> >>>>>>>>> i think you need to return the handler which you have scheduled >>>>>>>>> >>>>>>>>> On Sat, Mar 3, 2012 at 11:30 AM, Douglas Ferguson >>>>>>>>> wrote: >>>>>>>>>> onException() wants be to run a redirectHandler. do I just return >>>>>>>>>> null? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mar 2, 2012, at 11:44 PM, vineet semwal wrote: >>>>>>>>>> >>>>>>>>>>> you need to do requestcycle.scheduleRequestHandlerAfterCurrent(new >>>>>>>>>>> RenderPageRequestHandler(provider, RedirectPolicy.ALWAYS_REDIRECT)); >>>>>>>>>>> >>>>>>>>>>> On Sat, Mar 3, 2012 at 10:53 AM, Douglas Ferguson >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> In migrating to wicket 1.5 from 1.4 I used this to redirect to my >>>>>>>>>>>> error page when an exception is thrown. >>>>>>>>>>>> But when I do this it is trying to instantiate a new copy of the >>>>>>>>>>>> page rather than using the one I pass in. >>>>>>>>>>>> >>>>>>>>>>>> IPageProvider provider = new PageProvider(new >>>>>&g
Re: WicketTester & Spring
Yes.
Now on to others. :(
On Mar 4, 2012, at 4:27 AM, Per Newgro wrote:
> So problem is solved?
> Per
>
> Am 04.03.2012 11:22, schrieb Douglas Ferguson:
>> I'm doing that.
>>
>> The fix involved moving the injector initialization to a template method so
>> I could override.
>>
>> tester = new WicketTester(new MyApp(){
>>
>> @Override
>> public SpringComponentInjector setupInjector() {
>> SpringComponentInjector injector = new
>> SpringComponentInjector(this, applicationContext);
>>
>> getComponentInstantiationListeners().add(injector);
>> injector.inject(this);
>> return injector;
>> }
>> });
>>
>> On Mar 4, 2012, at 3:19 AM, Per Newgro wrote:
>>
>>> Assign the app to the wicket tester instance you use. See section
>>> below.
>>> Per
>>>
>>> Am 04.03.2012 10:11, schrieb Douglas Ferguson:
>>>> What does this mean? "you have to set the app to wicket tester instance."
>>>>
>>>> Douglas
>>>>
>>>> On Mar 4, 2012, at 1:32 AM, Per Newgro wrote:
>>>>
>>>>> And the app should know the context in which way? No no you have to set
>>>>> the app to wicket tester instance.
>>>>>
>>>>>tester = new WicketTester(new MyApp());
>>>>>
>>>>>
>>>>> Cheers
>>>>> Per
>>>>>
>>>>> Am 04.03.2012 06:17, schrieb Douglas Ferguson:
>>>>>> I'm trying to use wicket tester to test an app that is running with
>>>>>> spring.
>>>>>>
>>>>>> I'm getting this error:
>>>>>>
>>>>>> java.lang.IllegalStateException: No WebApplicationContext found: no
>>>>>> ContextLoaderListener registered?
>>>>>>
>>>>>> I thought perhaps I would be able to use SpringJunit4ClassRunning, but
>>>>>> that didn't work. Any tips?
>>>>>>
>>>>>> @RunWith(SpringJUnit4ClassRunner.class)
>>>>>> @ContextConfiguration(locations = {
>>>>>> "classpath:spring/mockApplicationContext.xml"})
>>>>> -
>>>>> 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
Re: WicketTester & Spring
I'm doing that.
The fix involved moving the injector initialization to a template method so I
could override.
tester = new WicketTester(new MyApp(){
@Override
public SpringComponentInjector setupInjector() {
SpringComponentInjector injector = new
SpringComponentInjector(this, applicationContext);
getComponentInstantiationListeners().add(injector);
injector.inject(this);
return injector;
}
});
On Mar 4, 2012, at 3:19 AM, Per Newgro wrote:
> Assign the app to the wicket tester instance you use. See section
> below.
> Per
>
> Am 04.03.2012 10:11, schrieb Douglas Ferguson:
>> What does this mean? "you have to set the app to wicket tester instance."
>>
>> Douglas
>>
>> On Mar 4, 2012, at 1:32 AM, Per Newgro wrote:
>>
>>> And the app should know the context in which way? No no you have to set the
>>> app to wicket tester instance.
>>>
>>>tester = new WicketTester(new MyApp());
>>>
>>>
>>> Cheers
>>> Per
>>>
>>> Am 04.03.2012 06:17, schrieb Douglas Ferguson:
>>>> I'm trying to use wicket tester to test an app that is running with spring.
>>>>
>>>> I'm getting this error:
>>>>
>>>> java.lang.IllegalStateException: No WebApplicationContext found: no
>>>> ContextLoaderListener registered?
>>>>
>>>> I thought perhaps I would be able to use SpringJunit4ClassRunning, but
>>>> that didn't work. Any tips?
>>>>
>>>>@RunWith(SpringJUnit4ClassRunner.class)
>>>>@ContextConfiguration(locations = {
>>>> "classpath:spring/mockApplicationContext.xml"})
>>>
>>> -
>>> 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
Re: WicketTester & Spring
What does this mean? "you have to set the app to wicket tester instance."
Douglas
On Mar 4, 2012, at 1:32 AM, Per Newgro wrote:
> And the app should know the context in which way? No no you have to set the
> app to wicket tester instance.
>
>tester = new WicketTester(new MyApp());
>
>
> Cheers
> Per
>
> Am 04.03.2012 06:17, schrieb Douglas Ferguson:
>> I'm trying to use wicket tester to test an app that is running with spring.
>>
>> I'm getting this error:
>>
>> java.lang.IllegalStateException: No WebApplicationContext found: no
>> ContextLoaderListener registered?
>>
>> I thought perhaps I would be able to use SpringJunit4ClassRunning, but that
>> didn't work. Any tips?
>>
>> @RunWith(SpringJUnit4ClassRunner.class)
>> @ContextConfiguration(locations = {
>> "classpath:spring/mockApplicationContext.xml"})
>
>
> -
> 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
WicketTester & Spring
I'm trying to use wicket tester to test an app that is running with spring.
I'm getting this error:
java.lang.IllegalStateException: No WebApplicationContext found: no
ContextLoaderListener registered?
I thought perhaps I would be able to use SpringJunit4ClassRunning, but that
didn't work. Any tips?
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = {
"classpath:spring/mockApplicationContext.xml"})
Re: redirecting in IRequestCyleListener.onException
I decided to just put the exception in the session and just grab it from there. Douglas On Mar 3, 2012, at 10:26 AM, vineet semwal wrote: > you should also do page.setStatelessHint(false) > > Page page=new ClientErrorPage(ex); > IPageProvider provider = new PageProvider(page); > page.setStatelessHint(false); > return new RenderPageRequestHandler(provider, RedirectPolicy.ALWAYS_REDIRECT); > > On Sat, Mar 3, 2012 at 8:23 PM, Douglas Ferguson wrote: >> Yeah Martin Grigorov recomended that I do just that: >> >>> WebPage exceptionPage = new NotifyUserOfException(ex); >>> IPageProvider provider = new PageProvider(page); >>> return new RenderPageRequestHandler(provider /*, >>> RenderPageRequestHandler.RedirectPolicy.XYZ */ ); >> >> >> But I finding that it throws away the page that I pass in and just uses the >> class object. >> I discovered this because I don't have a default constructor so it blows up >> on newInstance(). >> >> Douglas >> >> On Mar 3, 2012, at 1:36 AM, vineet semwal wrote: >> >>> i think scheduling is wrong in this usecase ,actually just overriding >>> onexception and returning your handler like you did before should have >>> worked but wait for some one else to respond if its not working >>> >>> On Sat, Mar 3, 2012 at 12:47 PM, Douglas Ferguson wrote: >>>> I tried overriding onExceptionRequestHandlerResolved but I can't get this >>>> to work. >>>> >>>> I'm still not getting my error page to load on errors. >>>> >>>> Douglas >>>> >>>> On Mar 3, 2012, at 12:36 AM, Douglas Ferguson wrote: >>>> >>>>> I mean "too many redirects" >>>>> >>>>> On Mar 3, 2012, at 12:36 AM, Douglas Ferguson wrote: >>>>> >>>>>> Causes an infinite loop. >>>>>> >>>>>> Douglas >>>>>> >>>>>> On Mar 3, 2012, at 12:20 AM, vineet semwal wrote: >>>>>> >>>>>>> i think you need to return the handler which you have scheduled >>>>>>> >>>>>>> On Sat, Mar 3, 2012 at 11:30 AM, Douglas Ferguson >>>>>>> wrote: >>>>>>>> onException() wants be to run a redirectHandler. do I just return null? >>>>>>>> >>>>>>>> >>>>>>>> On Mar 2, 2012, at 11:44 PM, vineet semwal wrote: >>>>>>>> >>>>>>>>> you need to do requestcycle.scheduleRequestHandlerAfterCurrent(new >>>>>>>>> RenderPageRequestHandler(provider, RedirectPolicy.ALWAYS_REDIRECT)); >>>>>>>>> >>>>>>>>> On Sat, Mar 3, 2012 at 10:53 AM, Douglas Ferguson >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> In migrating to wicket 1.5 from 1.4 I used this to redirect to my >>>>>>>>>> error page when an exception is thrown. >>>>>>>>>> But when I do this it is trying to instantiate a new copy of the >>>>>>>>>> page rather than using the one I pass in. >>>>>>>>>> >>>>>>>>>> IPageProvider provider = new PageProvider(new >>>>>>>>>> ClientErrorPage(ex)); >>>>>>>>>> return new RenderPageRequestHandler(provider, >>>>>>>>>> RedirectPolicy.ALWAYS_REDIRECT); >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> thank you, >>>>>>>>> >>>>>>>>> regards, >>>>>>>>> Vineet Semwal >>>>>>>>> >>>>>>>>> - >>>>>>>>> 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 >>>>>>
Re: redirecting in IRequestCyleListener.onException
Yeah Martin Grigorov recomended that I do just that: > WebPage exceptionPage = new NotifyUserOfException(ex); > IPageProvider provider = new PageProvider(page); > return new RenderPageRequestHandler(provider /*, > RenderPageRequestHandler.RedirectPolicy.XYZ */ ); But I finding that it throws away the page that I pass in and just uses the class object. I discovered this because I don't have a default constructor so it blows up on newInstance(). Douglas On Mar 3, 2012, at 1:36 AM, vineet semwal wrote: > i think scheduling is wrong in this usecase ,actually just overriding > onexception and returning your handler like you did before should have > worked but wait for some one else to respond if its not working > > On Sat, Mar 3, 2012 at 12:47 PM, Douglas Ferguson wrote: >> I tried overriding onExceptionRequestHandlerResolved but I can't get this to >> work. >> >> I'm still not getting my error page to load on errors. >> >> Douglas >> >> On Mar 3, 2012, at 12:36 AM, Douglas Ferguson wrote: >> >>> I mean "too many redirects" >>> >>> On Mar 3, 2012, at 12:36 AM, Douglas Ferguson wrote: >>> >>>> Causes an infinite loop. >>>> >>>> Douglas >>>> >>>> On Mar 3, 2012, at 12:20 AM, vineet semwal wrote: >>>> >>>>> i think you need to return the handler which you have scheduled >>>>> >>>>> On Sat, Mar 3, 2012 at 11:30 AM, Douglas Ferguson >>>>> wrote: >>>>>> onException() wants be to run a redirectHandler. do I just return null? >>>>>> >>>>>> >>>>>> On Mar 2, 2012, at 11:44 PM, vineet semwal wrote: >>>>>> >>>>>>> you need to do requestcycle.scheduleRequestHandlerAfterCurrent(new >>>>>>> RenderPageRequestHandler(provider, RedirectPolicy.ALWAYS_REDIRECT)); >>>>>>> >>>>>>> On Sat, Mar 3, 2012 at 10:53 AM, Douglas Ferguson >>>>>>> wrote: >>>>>>>> >>>>>>>> In migrating to wicket 1.5 from 1.4 I used this to redirect to my >>>>>>>> error page when an exception is thrown. >>>>>>>> But when I do this it is trying to instantiate a new copy of the page >>>>>>>> rather than using the one I pass in. >>>>>>>> >>>>>>>> IPageProvider provider = new PageProvider(new >>>>>>>> ClientErrorPage(ex)); >>>>>>>> return new RenderPageRequestHandler(provider, >>>>>>>> RedirectPolicy.ALWAYS_REDIRECT); >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> thank you, >>>>>>> >>>>>>> regards, >>>>>>> Vineet Semwal >>>>>>> >>>>>>> - >>>>>>> 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 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> thank you, >>>>> >>>>> regards, >>>>> Vineet Semwal >>>>> >>>>> - >>>>> 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 >> > > > > -- > thank you, > > regards, > Vineet Semwal > > - > 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
Re: Wicket 1.5 - Accessing the "Previously Requested Page"
I think something else was interfering because it is working now. If you put
the setRootRequstMapper after all the other mounts it works.
It's a shame it has to be order dependent.
The null pointer happens when you do this:
>>> mount(new HttpsMapper(new MountedMapper("myPage", page, new
>>> UrlPathPageParametersEncoder()), httpsConfig));
Then hit localhost/myPage in a browser.
I've been burning the candle at both ends. Gonna get some rest. I'll post a
quick start in a couple days.
Cheers.
Douglas
On Mar 3, 2012, at 2:37 AM, Martin Grigorov wrote:
> See the code of http://www.wicket-library.com/wicket-examples/mappers/
> example.
>
> Create a quickstart app with the NullPointerException and attach it to a
> ticket.
>
> On Sat, Mar 3, 2012 at 9:06 AM, Douglas Ferguson wrote:
>> I just read that the setRootRequestMapper should be after all the mounts.
>>
>> I tried it and it still down't work.
>>
>>setRootRequestMapper(new
>> HttpsMapper(getRootRequestMapper(), httpsConfig));
>>
>>
>>
>> On Mar 3, 2012, at 12:12 AM, Douglas Ferguson wrote:
>>
>>> After tracing through the code, I see that when mounting pages, those
>>> mappers will bypass the root mapper by wrapping it in a "composite"
>>>
>>> So then I tried this:
>>>
>>> mount(new HttpsMapper(new MountedMapper(PAGE_MOUNT_MAP.get(page), page, new
>>> UrlPathPageParametersEncoder()), httpsConfig));
>>>
>>> Now my pages are redirecting as I would expect, however, I get a null
>>> pointer:
>>>
>>> java.lang.NullPointerException
>>> at
>>> org.apache.wicket.protocol.https.HttpsMapper.mapHandler(HttpsMapper.java:129)
>>> at
>>> org.apache.wicket.request.mapper.CompoundRequestMapper.mapHandler(CompoundRequestMapper.java:157)
>>>
>>> On Mar 2, 2012, at 11:00 AM, Douglas Ferguson wrote:
>>>
>>>> Thanks. I just found that and was about to report back. ;)
>>>>
>>>> One thing I just noticed is that my @RequireHttps annotation doesn't
>>>> appear to be working.
>>>> Do I need to configure that app to work with that?
>>>>
>>>> Douglas
>>>>
>>>> On Mar 2, 2012, at 10:20 AM, Igor Vaynberg wrote:
>>>>
>>>>> write your own irequestcyclelistener, implement
>>>>> onrequesthandlerresolved() and in that method check if the handler is
>>>>> a IPageRequestHandler and stash the page anywhere you want, like in
>>>>> the request cycle's metadata.
>>>>>
>>>>> -igor
>>>>>
>>>>> On Fri, Mar 2, 2012 at 8:08 AM, Douglas Ferguson wrote:
>>>>>> This doesn't work.
>>>>>>
>>>>>> Seems like cycle.getActiveRequestHandler() always returns null when in
>>>>>> the endRequest call back.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> Douglas
>>>>>>
>>>>>> On Mar 2, 2012, at 8:13 AM, Douglas Ferguson wrote:
>>>>>>
>>>>>>> I want to save off the previous page at then end of each request.
>>>>>>> Can be handy for things like oauth (making sure we return to the
>>>>>>> correct spot in the app).
>>>>>>>
>>>>>>> In 1.4 I could just pull the page class and parameters off the
>>>>>>> RequestCycle.
>>>>>>> Not I have to check to see if the active handler is IPageRequestHandler.
>>>>>>>
>>>>>>> Is this safe? What scenarios exist where the RequestHandler will not be
>>>>>>> an IPageClassRequestHandler?
>>>>>>>
>>>>>>> This is the only thing I could come up with.
>>>>>>>
>>>>>>> public void onEndRequest(RequestCycle cycle)
>>>>>>> {
>>>>>>> if(cycle.getActiveRequestHandler()
>>>>>>> instanceof IPageClassRequestHandler){
>>>>>>> previousPageClass =
>>>>>>> ((IPageClassRequestHandler)cycle.getActiveRequestHandler()).getPageClass()
>>>>>>> }else{
>&
Re: redirecting in IRequestCyleListener.onException
I tried overriding onExceptionRequestHandlerResolved but I can't get this to work. I'm still not getting my error page to load on errors. Douglas On Mar 3, 2012, at 12:36 AM, Douglas Ferguson wrote: > I mean "too many redirects" > > On Mar 3, 2012, at 12:36 AM, Douglas Ferguson wrote: > >> Causes an infinite loop. >> >> Douglas >> >> On Mar 3, 2012, at 12:20 AM, vineet semwal wrote: >> >>> i think you need to return the handler which you have scheduled >>> >>> On Sat, Mar 3, 2012 at 11:30 AM, Douglas Ferguson wrote: >>>> onException() wants be to run a redirectHandler. do I just return null? >>>> >>>> >>>> On Mar 2, 2012, at 11:44 PM, vineet semwal wrote: >>>> >>>>> you need to do requestcycle.scheduleRequestHandlerAfterCurrent(new >>>>> RenderPageRequestHandler(provider, RedirectPolicy.ALWAYS_REDIRECT)); >>>>> >>>>> On Sat, Mar 3, 2012 at 10:53 AM, Douglas Ferguson >>>>> wrote: >>>>>> >>>>>> In migrating to wicket 1.5 from 1.4 I used this to redirect to my error >>>>>> page when an exception is thrown. >>>>>> But when I do this it is trying to instantiate a new copy of the page >>>>>> rather than using the one I pass in. >>>>>> >>>>>> IPageProvider provider = new PageProvider(new >>>>>> ClientErrorPage(ex)); >>>>>> return new RenderPageRequestHandler(provider, >>>>>> RedirectPolicy.ALWAYS_REDIRECT); >>>>> >>>>> >>>>> >>>>> -- >>>>> thank you, >>>>> >>>>> regards, >>>>> Vineet Semwal >>>>> >>>>> - >>>>> 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 >>>> >>> >>> >>> >>> -- >>> thank you, >>> >>> regards, >>> Vineet Semwal >>> >>> - >>> 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
Re: Wicket 1.5 - Accessing the "Previously Requested Page"
I just read that the setRootRequestMapper should be after all the mounts.
I tried it and it still down't work.
setRootRequestMapper(new
HttpsMapper(getRootRequestMapper(), httpsConfig));
On Mar 3, 2012, at 12:12 AM, Douglas Ferguson wrote:
> After tracing through the code, I see that when mounting pages, those mappers
> will bypass the root mapper by wrapping it in a "composite"
>
> So then I tried this:
>
> mount(new HttpsMapper(new MountedMapper(PAGE_MOUNT_MAP.get(page), page, new
> UrlPathPageParametersEncoder()), httpsConfig));
>
> Now my pages are redirecting as I would expect, however, I get a null pointer:
>
> java.lang.NullPointerException
> at
> org.apache.wicket.protocol.https.HttpsMapper.mapHandler(HttpsMapper.java:129)
> at
> org.apache.wicket.request.mapper.CompoundRequestMapper.mapHandler(CompoundRequestMapper.java:157)
>
> On Mar 2, 2012, at 11:00 AM, Douglas Ferguson wrote:
>
>> Thanks. I just found that and was about to report back. ;)
>>
>> One thing I just noticed is that my @RequireHttps annotation doesn't appear
>> to be working.
>> Do I need to configure that app to work with that?
>>
>> Douglas
>>
>> On Mar 2, 2012, at 10:20 AM, Igor Vaynberg wrote:
>>
>>> write your own irequestcyclelistener, implement
>>> onrequesthandlerresolved() and in that method check if the handler is
>>> a IPageRequestHandler and stash the page anywhere you want, like in
>>> the request cycle's metadata.
>>>
>>> -igor
>>>
>>> On Fri, Mar 2, 2012 at 8:08 AM, Douglas Ferguson wrote:
>>>> This doesn't work.
>>>>
>>>> Seems like cycle.getActiveRequestHandler() always returns null when in the
>>>> endRequest call back.
>>>>
>>>> Thoughts?
>>>>
>>>> Douglas
>>>>
>>>> On Mar 2, 2012, at 8:13 AM, Douglas Ferguson wrote:
>>>>
>>>>> I want to save off the previous page at then end of each request.
>>>>> Can be handy for things like oauth (making sure we return to the correct
>>>>> spot in the app).
>>>>>
>>>>> In 1.4 I could just pull the page class and parameters off the
>>>>> RequestCycle.
>>>>> Not I have to check to see if the active handler is IPageRequestHandler.
>>>>>
>>>>> Is this safe? What scenarios exist where the RequestHandler will not be
>>>>> an IPageClassRequestHandler?
>>>>>
>>>>> This is the only thing I could come up with.
>>>>>
>>>>> public void onEndRequest(RequestCycle cycle)
>>>>> {
>>>>> if(cycle.getActiveRequestHandler()
>>>>> instanceof IPageClassRequestHandler){
>>>>> previousPageClass =
>>>>> ((IPageClassRequestHandler)cycle.getActiveRequestHandler()).getPageClass()
>>>>> }else{
>>>>> log.error("cycle is not an
>>>>> IpageClassRequesthandler "+cycle);
>>>>> }
>>>>> }
>>>>
>>>>
>>>> -
>>>> 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
Re: redirecting in IRequestCyleListener.onException
I mean "too many redirects" On Mar 3, 2012, at 12:36 AM, Douglas Ferguson wrote: > Causes an infinite loop. > > Douglas > > On Mar 3, 2012, at 12:20 AM, vineet semwal wrote: > >> i think you need to return the handler which you have scheduled >> >> On Sat, Mar 3, 2012 at 11:30 AM, Douglas Ferguson wrote: >>> onException() wants be to run a redirectHandler. do I just return null? >>> >>> >>> On Mar 2, 2012, at 11:44 PM, vineet semwal wrote: >>> >>>> you need to do requestcycle.scheduleRequestHandlerAfterCurrent(new >>>> RenderPageRequestHandler(provider, RedirectPolicy.ALWAYS_REDIRECT)); >>>> >>>> On Sat, Mar 3, 2012 at 10:53 AM, Douglas Ferguson wrote: >>>>> >>>>> In migrating to wicket 1.5 from 1.4 I used this to redirect to my error >>>>> page when an exception is thrown. >>>>> But when I do this it is trying to instantiate a new copy of the page >>>>> rather than using the one I pass in. >>>>> >>>>> IPageProvider provider = new PageProvider(new >>>>> ClientErrorPage(ex)); >>>>> return new RenderPageRequestHandler(provider, >>>>> RedirectPolicy.ALWAYS_REDIRECT); >>>> >>>> >>>> >>>> -- >>>> thank you, >>>> >>>> regards, >>>> Vineet Semwal >>>> >>>> - >>>> 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 >>> >> >> >> >> -- >> thank you, >> >> regards, >> Vineet Semwal >> >> - >> 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
Re: redirecting in IRequestCyleListener.onException
Causes an infinite loop. Douglas On Mar 3, 2012, at 12:20 AM, vineet semwal wrote: > i think you need to return the handler which you have scheduled > > On Sat, Mar 3, 2012 at 11:30 AM, Douglas Ferguson wrote: >> onException() wants be to run a redirectHandler. do I just return null? >> >> >> On Mar 2, 2012, at 11:44 PM, vineet semwal wrote: >> >>> you need to do requestcycle.scheduleRequestHandlerAfterCurrent(new >>> RenderPageRequestHandler(provider, RedirectPolicy.ALWAYS_REDIRECT)); >>> >>> On Sat, Mar 3, 2012 at 10:53 AM, Douglas Ferguson wrote: >>>> >>>> In migrating to wicket 1.5 from 1.4 I used this to redirect to my error >>>> page when an exception is thrown. >>>> But when I do this it is trying to instantiate a new copy of the page >>>> rather than using the one I pass in. >>>> >>>>IPageProvider provider = new PageProvider(new >>>> ClientErrorPage(ex)); >>>>return new RenderPageRequestHandler(provider, >>>> RedirectPolicy.ALWAYS_REDIRECT); >>> >>> >>> >>> -- >>> thank you, >>> >>> regards, >>> Vineet Semwal >>> >>> - >>> 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 >> > > > > -- > thank you, > > regards, > Vineet Semwal > > - > 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
Re: Wicket 1.5 - Accessing the "Previously Requested Page"
After tracing through the code, I see that when mounting pages, those mappers
will bypass the root mapper by wrapping it in a "composite"
So then I tried this:
mount(new HttpsMapper(new MountedMapper(PAGE_MOUNT_MAP.get(page), page, new
UrlPathPageParametersEncoder()), httpsConfig));
Now my pages are redirecting as I would expect, however, I get a null pointer:
java.lang.NullPointerException
at
org.apache.wicket.protocol.https.HttpsMapper.mapHandler(HttpsMapper.java:129)
at
org.apache.wicket.request.mapper.CompoundRequestMapper.mapHandler(CompoundRequestMapper.java:157)
On Mar 2, 2012, at 11:00 AM, Douglas Ferguson wrote:
> Thanks. I just found that and was about to report back. ;)
>
> One thing I just noticed is that my @RequireHttps annotation doesn't appear
> to be working.
> Do I need to configure that app to work with that?
>
> Douglas
>
> On Mar 2, 2012, at 10:20 AM, Igor Vaynberg wrote:
>
>> write your own irequestcyclelistener, implement
>> onrequesthandlerresolved() and in that method check if the handler is
>> a IPageRequestHandler and stash the page anywhere you want, like in
>> the request cycle's metadata.
>>
>> -igor
>>
>> On Fri, Mar 2, 2012 at 8:08 AM, Douglas Ferguson wrote:
>>> This doesn't work.
>>>
>>> Seems like cycle.getActiveRequestHandler() always returns null when in the
>>> endRequest call back.
>>>
>>> Thoughts?
>>>
>>> Douglas
>>>
>>> On Mar 2, 2012, at 8:13 AM, Douglas Ferguson wrote:
>>>
>>>> I want to save off the previous page at then end of each request.
>>>> Can be handy for things like oauth (making sure we return to the correct
>>>> spot in the app).
>>>>
>>>> In 1.4 I could just pull the page class and parameters off the
>>>> RequestCycle.
>>>> Not I have to check to see if the active handler is IPageRequestHandler.
>>>>
>>>> Is this safe? What scenarios exist where the RequestHandler will not be an
>>>> IPageClassRequestHandler?
>>>>
>>>> This is the only thing I could come up with.
>>>>
>>>> public void onEndRequest(RequestCycle cycle)
>>>> {
>>>> if(cycle.getActiveRequestHandler()
>>>> instanceof IPageClassRequestHandler){
>>>> previousPageClass =
>>>> ((IPageClassRequestHandler)cycle.getActiveRequestHandler()).getPageClass()
>>>> }else{
>>>> log.error("cycle is not an
>>>> IpageClassRequesthandler "+cycle);
>>>> }
>>>> }
>>>
>>>
>>> -
>>> 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
Re: redirecting in IRequestCyleListener.onException
onException() wants be to run a redirectHandler. do I just return null? On Mar 2, 2012, at 11:44 PM, vineet semwal wrote: > you need to do requestcycle.scheduleRequestHandlerAfterCurrent(new > RenderPageRequestHandler(provider, RedirectPolicy.ALWAYS_REDIRECT)); > > On Sat, Mar 3, 2012 at 10:53 AM, Douglas Ferguson wrote: >> >> In migrating to wicket 1.5 from 1.4 I used this to redirect to my error page >> when an exception is thrown. >> But when I do this it is trying to instantiate a new copy of the page rather >> than using the one I pass in. >> >>IPageProvider provider = new PageProvider(new >> ClientErrorPage(ex)); >>return new RenderPageRequestHandler(provider, >> RedirectPolicy.ALWAYS_REDIRECT); > > > > -- > thank you, > > regards, > Vineet Semwal > > - > 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
redirecting in IRequestCyleListener.onException
In migrating to wicket 1.5 from 1.4 I used this to redirect to my error page when an exception is thrown. But when I do this it is trying to instantiate a new copy of the page rather than using the one I pass in. IPageProvider provider = new PageProvider(new ClientErrorPage(ex)); return new RenderPageRequestHandler(provider, RedirectPolicy.ALWAYS_REDIRECT);
Re: Wicket 1.5 - Accessing the "Previously Requested Page"
Thanks. I just found that and was about to report back. ;)
One thing I just noticed is that my @RequireHttps annotation doesn't appear to
be working.
Do I need to configure that app to work with that?
Douglas
On Mar 2, 2012, at 10:20 AM, Igor Vaynberg wrote:
> write your own irequestcyclelistener, implement
> onrequesthandlerresolved() and in that method check if the handler is
> a IPageRequestHandler and stash the page anywhere you want, like in
> the request cycle's metadata.
>
> -igor
>
> On Fri, Mar 2, 2012 at 8:08 AM, Douglas Ferguson wrote:
>> This doesn't work.
>>
>> Seems like cycle.getActiveRequestHandler() always returns null when in the
>> endRequest call back.
>>
>> Thoughts?
>>
>> Douglas
>>
>> On Mar 2, 2012, at 8:13 AM, Douglas Ferguson wrote:
>>
>>> I want to save off the previous page at then end of each request.
>>> Can be handy for things like oauth (making sure we return to the correct
>>> spot in the app).
>>>
>>> In 1.4 I could just pull the page class and parameters off the RequestCycle.
>>> Not I have to check to see if the active handler is IPageRequestHandler.
>>>
>>> Is this safe? What scenarios exist where the RequestHandler will not be an
>>> IPageClassRequestHandler?
>>>
>>> This is the only thing I could come up with.
>>>
>>> public void onEndRequest(RequestCycle cycle)
>>> {
>>> if(cycle.getActiveRequestHandler()
>>> instanceof IPageClassRequestHandler){
>>> previousPageClass =
>>> ((IPageClassRequestHandler)cycle.getActiveRequestHandler()).getPageClass()
>>> }else{
>>> log.error("cycle is not an
>>> IpageClassRequesthandler "+cycle);
>>> }
>>> }
>>
>>
>> -
>> 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
Re: Wicket 1.5 - Accessing the "Previously Requested Page"
This doesn't work.
Seems like cycle.getActiveRequestHandler() always returns null when in the
endRequest call back.
Thoughts?
Douglas
On Mar 2, 2012, at 8:13 AM, Douglas Ferguson wrote:
> I want to save off the previous page at then end of each request.
> Can be handy for things like oauth (making sure we return to the correct spot
> in the app).
>
> In 1.4 I could just pull the page class and parameters off the RequestCycle.
> Not I have to check to see if the active handler is IPageRequestHandler.
>
> Is this safe? What scenarios exist where the RequestHandler will not be an
> IPageClassRequestHandler?
>
> This is the only thing I could come up with.
>
> public void onEndRequest(RequestCycle cycle)
> {
> if(cycle.getActiveRequestHandler()
> instanceof IPageClassRequestHandler){
> previousPageClass =
> ((IPageClassRequestHandler)cycle.getActiveRequestHandler()).getPageClass()
> }else{
> log.error("cycle is not an
> IpageClassRequesthandler "+cycle);
> }
> }
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: web.xml for Spring & Wicket 1.5
Yeah.. just figured that out. I'm going to update the wiki.. I'm toying around with where to but the wicket.configuration setting using this format as well. Douglas On Mar 2, 2012, at 9:10 AM, Sergej Sizov wrote: > Hi, > > > contextConfigLocation > classpath:context.xml > > > wicket > > org.apache.wicket.protocol.http.WicketServlet > > >applicationFactoryClassName > > org.apache.wicket.spring.SpringWebApplicationFactory ue> > > >applicationBean >wicketApplication > > 1 > > > wicket > /* > > > > org.springframework.web.context.ContextLoaderListener ner-class> > > > > Sergej > > -Original Message- > From: Douglas Ferguson [mailto:the...@gmail.com] > Sent: Friday, March 02, 2012 4:05 PM > To: Wicket Mailing List List > Subject: web.xml for Spring & Wicket 1.5 > > I'm not sure the example web.xml here is complete - > https://cwiki.apache.org/WICKET/spring.html > > There is no filter mapping so there is no request get sent to the wicket > servlet. > > I've always used the the wicket filter and a filter mapping so I need to > figure out how to do the same with a servlet. > > Douglas > > > > - > 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
web.xml for Spring & Wicket 1.5
I'm not sure the example web.xml here is complete - https://cwiki.apache.org/WICKET/spring.html There is no filter mapping so there is no request get sent to the wicket servlet. I've always used the the wicket filter and a filter mapping so I need to figure out how to do the same with a servlet. Douglas
Wicket 1.5 - Accessing the "Previously Requested Page"
I want to save off the previous page at then end of each request.
Can be handy for things like oauth (making sure we return to the correct spot
in the app).
In 1.4 I could just pull the page class and parameters off the RequestCycle.
Not I have to check to see if the active handler is IPageRequestHandler.
Is this safe? What scenarios exist where the RequestHandler will not be an
IPageClassRequestHandler?
This is the only thing I could come up with.
public void onEndRequest(RequestCycle cycle)
{
if(cycle.getActiveRequestHandler()
instanceof IPageClassRequestHandler){
previousPageClass =
((IPageClassRequestHandler)cycle.getActiveRequestHandler()).getPageClass()
}else{
log.error("cycle is not an
IpageClassRequesthandler "+cycle);
}
}
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: SpringComponentInjector
That's the latest version of the annotation module. I guess it got merged into
another module?
On Mar 2, 2012, at 3:18 AM, Martin Grigorov wrote:
> On Fri, Mar 2, 2012 at 11:16 AM, Douglas Ferguson wrote:
>> I'm getting classloader issues. I get this from eclipse:
>>
>> The type org.apache.wicket.injection.ComponentInjector cannot be resolved.
>> It is indirectly referenced from required .class files
>> VHConnectApplication.java
>>
>> It seems like ComponentInjector is not in the 1.5 ioc jar, and
>> SpringComponentInjector extends ComponentInjector
>>
>> These are my dependencies
>>
>>
>>
>>
>>org.apache.wicket
>>wicket
>>${wicket.version}
>>pom
>>
>>
>>org.apache.wicket
>>wicket-datetime
>>${wicket.version}
>>
>>
>>
>>org.apache.wicket
>>wicket-spring-annot
>>1.3.7
>
> Why you have 1.3.x dependency for project based on 1.5.x ?
>
>>
>>
>>
>>org.apache.wicket
>>wicket-ioc
>>${wicket.version}
>>
>>
>>
>>org.apache.wicket
>> wicket-spring
>>${wicket.version}
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Mar 2, 2012, at 2:54 AM, Martin Grigorov wrote:
>>
>>> The same
>>>
>>> On Fri, Mar 2, 2012 at 10:49 AM, Douglas Ferguson wrote:
>>>> I just pulled in SpringComponentInjector and it seems to be subclassing a
>>>> class that is not longer in wicket-ioc.
>>>>
>>>> What's the correct way to using Spring injection with 1.5?
>>>>
>>>> Douglas
>>>
>>>
>>>
>>> --
>>> Martin Grigorov
>>> jWeekend
>>> Training, Consulting, Development
>>> http://jWeekend.com
>>>
>>> -
>>> 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
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: SpringComponentInjector
I'm getting classloader issues. I get this from eclipse:
The type org.apache.wicket.injection.ComponentInjector cannot be resolved. It
is indirectly referenced from required .class files
VHConnectApplication.java
It seems like ComponentInjector is not in the 1.5 ioc jar, and
SpringComponentInjector extends ComponentInjector
These are my dependencies
org.apache.wicket
wicket
${wicket.version}
pom
org.apache.wicket
wicket-datetime
${wicket.version}
org.apache.wicket
wicket-spring-annot
1.3.7
org.apache.wicket
wicket-ioc
${wicket.version}
org.apache.wicket
wicket-spring
${wicket.version}
On Mar 2, 2012, at 2:54 AM, Martin Grigorov wrote:
> The same
>
> On Fri, Mar 2, 2012 at 10:49 AM, Douglas Ferguson wrote:
>> I just pulled in SpringComponentInjector and it seems to be subclassing a
>> class that is not longer in wicket-ioc.
>>
>> What's the correct way to using Spring injection with 1.5?
>>
>> Douglas
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> -
> 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
SpringComponentInjector
I just pulled in SpringComponentInjector and it seems to be subclassing a class that is not longer in wicket-ioc. What's the correct way to using Spring injection with 1.5? Douglas
Re: More wicket 1.5 questions
I want to save off the previous page at then end of each request.
Can be handy for things like oauth (making sure we return to the correct spot
in the app).
This is the only thing I could come up with.
public void onEndRequest(RequestCycle cycle)
{
if(cycle.getActiveRequestHandler()
instanceof IPageClassRequestHandler){
VHConnectSession.get().setPreviousPage((IPageClassRequestHandler)cycle.getActiveRequestHandler());
}else{
log.error("cycle is not an
IpageClassRequesthandler "+cycle);
}
}
On Mar 2, 2012, at 2:26 AM, Martin Grigorov wrote:
> On Fri, Mar 2, 2012 at 10:21 AM, Douglas Ferguson wrote:
>> In 1.4 I did the following, what are the alternatives in 1.5?
>>
>> 1) AbstractRequestTargetUrlCodingStrategy to mount a path to 301 redirect
>
> I don't understand you
>
>> 2) Overrode newRequestCycleProcessor so that I can set the no cache headers.
>
> https://cwiki.apache.org/WICKET/caching-in-wicket-15.html
>
>>
>>private void setNoCacheHeader(RequestCycle requestCycle) {
>>final WebResponse response = ((WebRequestCycle)
>> requestCycle).getWebResponse();
>>// so firefox won't keep a cached version of the page which
>> breaks the back button
>>response.getHttpServletResponse().setHeader("Cache-Control",
>> "no-cache, max-age=0, must-revalidate, no-store");
>>}
>>
>>
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> -
> 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
Re: More wicket 1.5 questions
On Mar 2, 2012, at 2:26 AM, Martin Grigorov wrote:
> On Fri, Mar 2, 2012 at 10:21 AM, Douglas Ferguson wrote:
>> In 1.4 I did the following, what are the alternatives in 1.5?
>>
>> 1) AbstractRequestTargetUrlCodingStrategy to mount a path to 301 redirect
>
> I don't understand you
Does this work?
mount(new MountMapper(path, new
RedirectRequestHandler(destination, 301)));
>
>> 2) Overrode newRequestCycleProcessor so that I can set the no cache headers.
>
> https://cwiki.apache.org/WICKET/caching-in-wicket-15.html
>
>>
>>private void setNoCacheHeader(RequestCycle requestCycle) {
>>final WebResponse response = ((WebRequestCycle)
>> requestCycle).getWebResponse();
>>// so firefox won't keep a cached version of the page which
>> breaks the back button
>>response.getHttpServletResponse().setHeader("Cache-Control",
>> "no-cache, max-age=0, must-revalidate, no-store");
>>}
>>
>>
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> -
> 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
More wicket 1.5 questions
In 1.4 I did the following, what are the alternatives in 1.5?
1) AbstractRequestTargetUrlCodingStrategy to mount a path to 301 redirect
2) Overrode newRequestCycleProcessor so that I can set the no cache headers.
private void setNoCacheHeader(RequestCycle requestCycle) {
final WebResponse response = ((WebRequestCycle)
requestCycle).getWebResponse();
// so firefox won't keep a cached version of the page which
breaks the back button
response.getHttpServletResponse().setHeader("Cache-Control",
"no-cache, max-age=0, must-revalidate, no-store");
}
Re: http/https in wicket 1.5
Wow.. that is much easier :) Is there a way to set a default for the entire app? I assume if I have a base class for a bunch of pages I only need to define it in the parent class? Douglas On Mar 1, 2012, at 10:04 AM, Fergal Keating wrote: >You can mark specific pages as HTTPS specific using @requiresHttps. > > Then just set the ports in your application class. > > setRootRequestMapper(new HttpsMapper(getRootRequestMapper(), new > HttpsConfig(80, 443))); > > > On 1 March 2012 14:10, Douglas Ferguson wrote: > >> In 1.4 I had ao code up some interesting work arounds to get my app to >> redirect between http and https based on which page you are requesting. >> >> I remember at the time Igor told me that it would be much easer in 1.5. >> Can anybody point me in the redirection? >> >> I'm considering 2 schemes. >> >> 1) Running the entire app over ssl (then I just need to detect http and >> redirect to https) >> 2) Keep it as is, Only have the login, signup and payment screens be https >> and then redirect to http. >> >> Regardless I'll need to detect http/https and then redirect if necessary. >> Would this still be done in the AuthorizationStrategy? >> >> I've noticed that RequestCycle has changed, and many methods I used are >> gone. >> I.E. I used to use requestCycle.getPageParameters() to get the parameters >> do that I when I redirected to login I would retain the params, >> so after logging in the user could be sent to their original page. >> >> Douglas >> >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > > -- > Fergal Keating > IT Senior Engineer > --- > e. fergal.keat...@directski.com > p. NA > w. www.directski.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
http/https in wicket 1.5
In 1.4 I had ao code up some interesting work arounds to get my app to redirect between http and https based on which page you are requesting. I remember at the time Igor told me that it would be much easer in 1.5. Can anybody point me in the redirection? I'm considering 2 schemes. 1) Running the entire app over ssl (then I just need to detect http and redirect to https) 2) Keep it as is, Only have the login, signup and payment screens be https and then redirect to http. Regardless I'll need to detect http/https and then redirect if necessary. Would this still be done in the AuthorizationStrategy? I've noticed that RequestCycle has changed, and many methods I used are gone. I.E. I used to use requestCycle.getPageParameters() to get the parameters do that I when I redirected to login I would retain the params, so after logging in the user could be sent to their original page. Douglas - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Migrating to wicket 1.5
If I mount a page to the url "page1"
Then hit page1/foo/bar/abc/xyz
Then in my code i say pageParameters.get("foo") it returns null.
In 1.4 it would return "bar"
Douglas
On Mar 1, 2012, at 2:09 AM, Martin Grigorov wrote:
> On Thu, Mar 1, 2012 at 10:05 AM, Douglas Ferguson wrote:
>> Thanks!
>>
>> I also noticed that hybridurlcodingstrategy is missing.
>>
>> I did some reading but haven't found a solution that is 100%
>
> The default mounting works as HybridUCS - WebApplication#mountPage(),
> this uses MountedMapper behind the scenes.
> What functionality is missing ?
>
>>
>> Douglas
>>
>> On Mar 1, 2012, at 2:01 AM, Martin Grigorov wrote:
>>
>>> On Thu, Mar 1, 2012 at 8:52 AM, Douglas Ferguson wrote:
>>>> See below...
>>>>
>>>> On Feb 29, 2012, at 11:49 PM, Dan Retzlaff wrote:
>>>>
>>>>> Douglas,
>>>>>
>>>>> Regarding javascript references: instead of adding a header contributor,
>>>>> have your component override renderHead(IHeaderResponse response) and use
>>>>> response.renderJavaScriptReference().
>>>>
>>>> Thanks!
>>>>
>>>>>
>>>>> Regarding AbortException: instead of grabbing the servlet response,
>>>>> writing
>>>>> to it immediately, and throwing AbortException, replace the current
>>>>> request
>>>>> handler with one that writes the response. See DownloadLink#onClick for an
>>>>> example. (Ref
>>>>> http://mail-archives.apache.org/mod_mbox/wicket-users/201105.mbox/%3cbanlktimkstujmwzsd2lhhkbyzcungcq...@mail.gmail.com%3E
>>>>> )
>>>>
>>>> I was catching it not throwing it. Is there a comparable scenario in 1.5?
>>>>
>>>> Here are some other things I ran into that I don't see in the migration doc
>>>>
>>>> 1) RestartResponseAtInterceptPageException
>>> org.apache.wicket.RestartResponseAtInterceptPageException
>>>
>>>> 2) getRequestCycle().setRedirect(false)
>>> This is handled automatically by Wicket, but if you want full control
>>> then you need to use this:
>>>
>>> cycle.scheduleRequestHandlerAfterCurrent(new
>>> RenderPageRequestHandler(new PageProvider(..),
>>> RenderPageRequestHandler.RedirectPolicy.NEVER))
>>>
>>>> 3) IRequestTarget is gone
>>> Replaced by IRequestHandler
>>> http://wicketinaction.com/2011/07/wicket-1-5-request-mapper/
>>> http://wicketinaction.com/2011/07/wicket-1-5-mounting-pages/
>>> http://wicketinaction.com/2011/07/wicket-1-5-mounting-resources/
>>>
>>>> 4) AbstractRequestTargetUrlCodingStrategy is goine
>>> The links above should explain this.
>>>
>>>> 5) UploadWebRequest is gone
>>> No need of this anymore. See "wicket-examples -> upload" for a demo
>>> (org.apache.wicket.examples.upload.UploadApplication)
>>>
>>> Feel free to update the migration page where you see it misses some info.
>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> Dan
>>>>>
>>>>> On Wed, Feb 29, 2012 at 9:01 PM, Douglas Ferguson
>>>>> wrote:
>>>>>
>>>>>> Just found another one:
>>>>>>
>>>>>> What did AbortException get replaced with?
>>>>>>
>>>>>> Douglas
>>>>>>
>>>>>> On Feb 29, 2012, at 10:44 PM, Douglas Ferguson wrote:
>>>>>>
>>>>>>> I was reading the migration doc and I'm not sure how I would migrate
>>>>>> this to 1.5:
>>>>>>>
>>>>>>> WebRequest webRequest = (WebRequest)
>>>>>> RequestCycle.get().getRequest();
>>>>>>> HttpServletRequest httpServletRequest =
>>>>>> (HttpServletRequest)webRequest.getContainerRequest();
>>>>>>> String jqueryURl = "
>>>>>> http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js";;
>>>>>>> if(httpServletRequest.isSecure()){
>>>>>>> jqueryURl = jqueryURl.replaceFirst("http://";,
>>>>>> "https://";);
>>>>>>> }
>>>>>>>
&
Re: Migrating to wicket 1.5
>
>
> Feel free to update the migration page where you see it misses some info.
What's the process for updating?
>
>>
>>
>>
>>
>>>
>>> Dan
>>>
>>> On Wed, Feb 29, 2012 at 9:01 PM, Douglas Ferguson wrote:
>>>
>>>> Just found another one:
>>>>
>>>> What did AbortException get replaced with?
>>>>
>>>> Douglas
>>>>
>>>> On Feb 29, 2012, at 10:44 PM, Douglas Ferguson wrote:
>>>>
>>>>> I was reading the migration doc and I'm not sure how I would migrate
>>>> this to 1.5:
>>>>>
>>>>> WebRequest webRequest = (WebRequest)
>>>> RequestCycle.get().getRequest();
>>>>> HttpServletRequest httpServletRequest =
>>>> (HttpServletRequest)webRequest.getContainerRequest();
>>>>> String jqueryURl = "
>>>> http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js";;
>>>>> if(httpServletRequest.isSecure()){
>>>>> jqueryURl = jqueryURl.replaceFirst("http://";,
>>>> "https://";);
>>>>> }
>>>>>
>>>> component.add(JavascriptPackageResource.getHeaderContribution(jqueryURl));
>>>>
>>>>
>>>> -
>>>> 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
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> -
> 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
Re: Migrating to wicket 1.5
Thanks!
I also noticed that hybridurlcodingstrategy is missing.
I did some reading but haven't found a solution that is 100%
Douglas
On Mar 1, 2012, at 2:01 AM, Martin Grigorov wrote:
> On Thu, Mar 1, 2012 at 8:52 AM, Douglas Ferguson wrote:
>> See below...
>>
>> On Feb 29, 2012, at 11:49 PM, Dan Retzlaff wrote:
>>
>>> Douglas,
>>>
>>> Regarding javascript references: instead of adding a header contributor,
>>> have your component override renderHead(IHeaderResponse response) and use
>>> response.renderJavaScriptReference().
>>
>> Thanks!
>>
>>>
>>> Regarding AbortException: instead of grabbing the servlet response, writing
>>> to it immediately, and throwing AbortException, replace the current request
>>> handler with one that writes the response. See DownloadLink#onClick for an
>>> example. (Ref
>>> http://mail-archives.apache.org/mod_mbox/wicket-users/201105.mbox/%3cbanlktimkstujmwzsd2lhhkbyzcungcq...@mail.gmail.com%3E
>>> )
>>
>> I was catching it not throwing it. Is there a comparable scenario in 1.5?
>>
>> Here are some other things I ran into that I don't see in the migration doc
>>
>> 1) RestartResponseAtInterceptPageException
> org.apache.wicket.RestartResponseAtInterceptPageException
>
>> 2) getRequestCycle().setRedirect(false)
> This is handled automatically by Wicket, but if you want full control
> then you need to use this:
>
> cycle.scheduleRequestHandlerAfterCurrent(new
> RenderPageRequestHandler(new PageProvider(..),
> RenderPageRequestHandler.RedirectPolicy.NEVER))
>
>> 3) IRequestTarget is gone
> Replaced by IRequestHandler
> http://wicketinaction.com/2011/07/wicket-1-5-request-mapper/
> http://wicketinaction.com/2011/07/wicket-1-5-mounting-pages/
> http://wicketinaction.com/2011/07/wicket-1-5-mounting-resources/
>
>> 4) AbstractRequestTargetUrlCodingStrategy is goine
> The links above should explain this.
>
>> 5) UploadWebRequest is gone
> No need of this anymore. See "wicket-examples -> upload" for a demo
> (org.apache.wicket.examples.upload.UploadApplication)
>
> Feel free to update the migration page where you see it misses some info.
>
>>
>>
>>
>>
>>>
>>> Dan
>>>
>>> On Wed, Feb 29, 2012 at 9:01 PM, Douglas Ferguson wrote:
>>>
>>>> Just found another one:
>>>>
>>>> What did AbortException get replaced with?
>>>>
>>>> Douglas
>>>>
>>>> On Feb 29, 2012, at 10:44 PM, Douglas Ferguson wrote:
>>>>
>>>>> I was reading the migration doc and I'm not sure how I would migrate
>>>> this to 1.5:
>>>>>
>>>>> WebRequest webRequest = (WebRequest)
>>>> RequestCycle.get().getRequest();
>>>>> HttpServletRequest httpServletRequest =
>>>> (HttpServletRequest)webRequest.getContainerRequest();
>>>>> String jqueryURl = "
>>>> http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js";;
>>>>> if(httpServletRequest.isSecure()){
>>>>> jqueryURl = jqueryURl.replaceFirst("http://";,
>>>> "https://";);
>>>>> }
>>>>>
>>>> component.add(JavascriptPackageResource.getHeaderContribution(jqueryURl));
>>>>
>>>>
>>>> -
>>>> 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
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> -
> 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
onException() 1.5
I want to redirect to an error page when there is an Exception.
I see that there is a RedirectRequestHandler, but this only allows you to
redirect to url via string literal.
I want to redirect to a construction Page.
I was grasping at straws and tried this and no dice..
public IRequestHandler onException(RequestCycle cycle,
Exception ex)
{
cycle.setResponsePage(new
NotifyUserOfException());
return cycle.getActiveRequestHandler();
}
Re: Migrating to wicket 1.5
See below...
On Feb 29, 2012, at 11:49 PM, Dan Retzlaff wrote:
> Douglas,
>
> Regarding javascript references: instead of adding a header contributor,
> have your component override renderHead(IHeaderResponse response) and use
> response.renderJavaScriptReference().
Thanks!
>
> Regarding AbortException: instead of grabbing the servlet response, writing
> to it immediately, and throwing AbortException, replace the current request
> handler with one that writes the response. See DownloadLink#onClick for an
> example. (Ref
> http://mail-archives.apache.org/mod_mbox/wicket-users/201105.mbox/%3cbanlktimkstujmwzsd2lhhkbyzcungcq...@mail.gmail.com%3E
> )
I was catching it not throwing it. Is there a comparable scenario in 1.5?
Here are some other things I ran into that I don't see in the migration doc
1) RestartResponseAtInterceptPageException
2) getRequestCycle().setRedirect(false)
3) IRequestTarget is gone
4) AbstractRequestTargetUrlCodingStrategy is goine
5) UploadWebRequest is gone
>
> Dan
>
> On Wed, Feb 29, 2012 at 9:01 PM, Douglas Ferguson wrote:
>
>> Just found another one:
>>
>> What did AbortException get replaced with?
>>
>> Douglas
>>
>> On Feb 29, 2012, at 10:44 PM, Douglas Ferguson wrote:
>>
>>> I was reading the migration doc and I'm not sure how I would migrate
>> this to 1.5:
>>>
>>> WebRequest webRequest = (WebRequest)
>> RequestCycle.get().getRequest();
>>> HttpServletRequest httpServletRequest =
>> (HttpServletRequest)webRequest.getContainerRequest();
>>> String jqueryURl = "
>> http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js";;
>>> if(httpServletRequest.isSecure()){
>>> jqueryURl = jqueryURl.replaceFirst("http://";,
>> "https://";);
>>> }
>>>
>> component.add(JavascriptPackageResource.getHeaderContribution(jqueryURl));
>>
>>
>> -
>> 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
Re: Migrating to wicket 1.5
Just found another one:
What did AbortException get replaced with?
Douglas
On Feb 29, 2012, at 10:44 PM, Douglas Ferguson wrote:
> I was reading the migration doc and I'm not sure how I would migrate this to
> 1.5:
>
> WebRequest webRequest = (WebRequest)
> RequestCycle.get().getRequest();
> HttpServletRequest httpServletRequest =
> (HttpServletRequest)webRequest.getContainerRequest();
> String jqueryURl =
> "http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js";;
> if(httpServletRequest.isSecure()){
> jqueryURl = jqueryURl.replaceFirst("http://";,
> "https://";);
> }
>
> component.add(JavascriptPackageResource.getHeaderContribution(jqueryURl));
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Migrating to wicket 1.5
I was reading the migration doc and I'm not sure how I would migrate this to
1.5:
WebRequest webRequest = (WebRequest)
RequestCycle.get().getRequest();
HttpServletRequest httpServletRequest =
(HttpServletRequest)webRequest.getContainerRequest();
String jqueryURl =
"http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js";;
if(httpServletRequest.isSecure()){
jqueryURl = jqueryURl.replaceFirst("http://";,
"https://";);
}
component.add(JavascriptPackageResource.getHeaderContribution(jqueryURl));
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Book covering 1.5
I remember from a few years ago that 1.5 is going to be a non trivial change in architecture. Are there any docs available that explain how to migrate or what the differences are? Actually, now that I type this I remember Igor saying that migration may not be advised.. Douglas On Aug 24, 2011, at 11:34 AM, Fabian Schwarzer wrote: > Hi! > > Does anyone know if there is anyone out there writing a book covering the > upcoming Wicket release 1.5? > Or is e.g. Wicket in Action planing a new edition? > > Thanks, > Fabian > - > 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
Re: streaming files with wicket
Yeah.. I thought of that, but I liked the idea of streaming without hitting disc. On Mon, Jun 20, 2011 at 3:55 PM, Igor Vaynberg wrote: > i dont think there is a way once you start streaming with an > attachment header... > > you can try rendering the page into memory and writing that out > instead - so then you at least know your page rendered ok. > > -igor > > On Mon, Jun 20, 2011 at 1:50 PM, Douglas Ferguson > wrote: > > I built a page with markup type = xml and set the content type and > disposition so that the file will download. > > > > This is great except when there is a fatal exception thrown, my error > page is getting written to the downloaded file. > > > > Any ideas how make the browser load the error page? > > > > Only thought I had was to stream the file to disc and then send A) stream > to browser if there is no exception or B) forward to error page. > > But that kinda sucks as it is not truing streaming back to browser. > > > > D/ > > - > > 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 > >
using a different pagemap
We are using ResourceStreamRequestTarget for streaming an export. Is there a way to have this request use a different page map, sorta like the way that when you open a new tab it uses a different page map? Douglas
streaming files with wicket
I built a page with markup type = xml and set the content type and disposition so that the file will download. This is great except when there is a fatal exception thrown, my error page is getting written to the downloaded file. Any ideas how make the browser load the error page? Only thought I had was to stream the file to disc and then send A) stream to browser if there is no exception or B) forward to error page. But that kinda sucks as it is not truing streaming back to browser. D/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [Ljava.lang.String; cannot be cast to java.lang.String - BookmarkablePageRequestTargetUrlCodingStrategy
tomcat
On Jan 18, 2011, at 2:49 PM, Igor Vaynberg wrote:
> not sure then. seems rather strange that you cant reproduce it
> locally. what container is it running in?
>
> -igor
>
> On Tue, Jan 18, 2011 at 12:41 PM, Douglas Ferguson
> wrote:
>> There is no proxy
>>
>> On Jan 18, 2011, at 10:48 AM, Igor Vaynberg wrote:
>>
>>> is the app proxied? could be a proxy mangling it on a rewrite.
>>>
>>> -igor
>>>
>>> On Tue, Jan 18, 2011 at 1:57 AM, Douglas Ferguson
>>> wrote:
>>>> I only see it in production
>>>>
>>>>
>>>> On Jan 17, 2011, at 6:38 PM, Igor Vaynberg wrote:
>>>>
>>>>> not really sure what is happenning. that url is pretty badly mangled.
>>>>> can you set a breakpoint in part of the code that generates it and see
>>>>> if its wicket or someone is playing with the url.
>>>>>
>>>>> -igor
>>>>>
>>>>>
>>>>> On Mon, Jan 17, 2011 at 11:56 AM, Douglas Ferguson
>>>>> wrote:
>>>>>> Thoughts?
>>>>>>
>>>>>> On Jan 14, 2011, at 5:44 PM, Douglas Ferguson wrote:
>>>>>>
>>>>>>> This looks like it must have been one of them.
>>>>>>>
>>>>>>> - - [13/Jan/2011:14:26:34 -0600] "GET
>>>>>>> /?wicket:interface=:26::INewBrowserWindowListener:: HTTP/1.1" 302 -
>>>>>>> "http://app.buzzstream.com/link_partners/wicket:pageMapName/link_partners/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js/wicket:pageMapName/resources";
>>>>>>> "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13)
>>>>>>> Gecko/20101203 Firefox/3.6.13 GTB7.1 ( .NET CLR 3.5.30729)"
>>>>>>> - - [13/Jan/2011:14:26:34 -0600] "GET
>>>>>>> /?wicket:interface=wicket-8:27 HTTP/1.1" 200 3163
>>>>>>> "http://app.buzzstream.com/link_partners/wicket:pageMapName/link_partners/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js/wicket:pageMapName/resources";
>>>>>>> "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13)
>>>>>>> Gecko/20101203 Firefox/3.6.13 GTB7.1 ( .NET CLR 3.5.30729)"
>>>>>>>
>>>>>>>
>>>>>>> On Jan 14, 2011, at 5:23 PM, Igor Vaynberg wrote:
>>>>>>>
>>>>>>>> do their apache logs contain a sample of the url that caused this
>>>>>>>> error? would be helpful to see one.
>>>>>>>>
>>>>>>>> -igor
>>>>>>>>
>>>>>>>> On Fri, Jan 14, 2011 at 3:12 PM, Douglas Ferguson
>>>>>>>> wrote:
>>>>>>>>> Sorry about my previous title.
>>>>>>>>>
>>>>>>>>> I'm not sure what's causing this, but I've spoken with some of my
>>>>>>>>> clients, who spawned these errors and they weren't manipulating the
>>>>>>>>> querystrings..
>>>>>>>>> So I'm not sure how two pagemap paramenters are getting in there..
>>>>>>>>>
>>>>>>>>> D/
>>>>>>>>>
>>>>>>>>> On Jan 13, 2011, at 11:40 AM, Douglas Ferguson wrote:
>>>>>>>>>
>>>>>>>>>> I see the stack trace below in my production logs quite often.
>>>>>>>>>>
>>>>>>>>>> I'm not sure what is causing it but it seems that this error need
>>>>>>>>>> not happen. I.E. Why Cast this to a string when it could easily be
>>>>>>>>>> String[] if somebody messes with the query string?
>>>>>>>>>>
>>>>>>>>>> Seem like a parameters.removeFirst() method could prevent this..
>>>>>>>>>>
>>>>>>>>>> String pageMapNameEncoded =
>>>>>>>>>> (String)parameters.remove(WebRequestCodingStrategy.PAGEMAP);
>>>>>>>>>> if (requestParameters.getPageMapName() == null)
>>>>>>>>>> {
>>>>>>>>>>
Re: [Ljava.lang.String; cannot be cast to java.lang.String - BookmarkablePageRequestTargetUrlCodingStrategy
There is no proxy
On Jan 18, 2011, at 10:48 AM, Igor Vaynberg wrote:
> is the app proxied? could be a proxy mangling it on a rewrite.
>
> -igor
>
> On Tue, Jan 18, 2011 at 1:57 AM, Douglas Ferguson
> wrote:
>> I only see it in production
>>
>>
>> On Jan 17, 2011, at 6:38 PM, Igor Vaynberg wrote:
>>
>>> not really sure what is happenning. that url is pretty badly mangled.
>>> can you set a breakpoint in part of the code that generates it and see
>>> if its wicket or someone is playing with the url.
>>>
>>> -igor
>>>
>>>
>>> On Mon, Jan 17, 2011 at 11:56 AM, Douglas Ferguson
>>> wrote:
>>>> Thoughts?
>>>>
>>>> On Jan 14, 2011, at 5:44 PM, Douglas Ferguson wrote:
>>>>
>>>>> This looks like it must have been one of them.
>>>>>
>>>>> - - [13/Jan/2011:14:26:34 -0600] "GET
>>>>> /?wicket:interface=:26::INewBrowserWindowListener:: HTTP/1.1" 302 -
>>>>> "http://app.buzzstream.com/link_partners/wicket:pageMapName/link_partners/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js/wicket:pageMapName/resources";
>>>>> "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13)
>>>>> Gecko/20101203 Firefox/3.6.13 GTB7.1 ( .NET CLR 3.5.30729)"
>>>>> - - [13/Jan/2011:14:26:34 -0600] "GET /?wicket:interface=wicket-8:27
>>>>> HTTP/1.1" 200 3163
>>>>> "http://app.buzzstream.com/link_partners/wicket:pageMapName/link_partners/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js/wicket:pageMapName/resources";
>>>>> "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13)
>>>>> Gecko/20101203 Firefox/3.6.13 GTB7.1 ( .NET CLR 3.5.30729)"
>>>>>
>>>>>
>>>>> On Jan 14, 2011, at 5:23 PM, Igor Vaynberg wrote:
>>>>>
>>>>>> do their apache logs contain a sample of the url that caused this
>>>>>> error? would be helpful to see one.
>>>>>>
>>>>>> -igor
>>>>>>
>>>>>> On Fri, Jan 14, 2011 at 3:12 PM, Douglas Ferguson
>>>>>> wrote:
>>>>>>> Sorry about my previous title.
>>>>>>>
>>>>>>> I'm not sure what's causing this, but I've spoken with some of my
>>>>>>> clients, who spawned these errors and they weren't manipulating the
>>>>>>> querystrings..
>>>>>>> So I'm not sure how two pagemap paramenters are getting in there..
>>>>>>>
>>>>>>> D/
>>>>>>>
>>>>>>> On Jan 13, 2011, at 11:40 AM, Douglas Ferguson wrote:
>>>>>>>
>>>>>>>> I see the stack trace below in my production logs quite often.
>>>>>>>>
>>>>>>>> I'm not sure what is causing it but it seems that this error need not
>>>>>>>> happen. I.E. Why Cast this to a string when it could easily be
>>>>>>>> String[] if somebody messes with the query string?
>>>>>>>>
>>>>>>>> Seem like a parameters.removeFirst() method could prevent this..
>>>>>>>>
>>>>>>>> String pageMapNameEncoded =
>>>>>>>> (String)parameters.remove(WebRequestCodingStrategy.PAGEMAP);
>>>>>>>> if (requestParameters.getPageMapName() == null)
>>>>>>>> {
>>>>>>>>
>>>>>>>> requestParameters.setPageMapName(pageMapNameEncoded);
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [Ljava.lang.String; cannot be cast to java.lang.String
>>>>>>>>> java.lang.ClassCastException: [Ljava.lang.String; cannot be cast to
>>>>>>>>> java.lang.String
>>>>>>>>> at
>>>>>>>>> org.apache.wicket.request.target.coding.BookmarkablePageRequestTargetUrlCodingStrategy.decode(BookmarkablePageRequestTargetUrlCodingStrategy.java:91)
>>>>>>>>> at
>>>>>>>>> org.a
Re: [Ljava.lang.String; cannot be cast to java.lang.String - BookmarkablePageRequestTargetUrlCodingStrategy
I only see it in production
On Jan 17, 2011, at 6:38 PM, Igor Vaynberg wrote:
> not really sure what is happenning. that url is pretty badly mangled.
> can you set a breakpoint in part of the code that generates it and see
> if its wicket or someone is playing with the url.
>
> -igor
>
>
> On Mon, Jan 17, 2011 at 11:56 AM, Douglas Ferguson
> wrote:
>> Thoughts?
>>
>> On Jan 14, 2011, at 5:44 PM, Douglas Ferguson wrote:
>>
>>> This looks like it must have been one of them.
>>>
>>> - - [13/Jan/2011:14:26:34 -0600] "GET
>>> /?wicket:interface=:26::INewBrowserWindowListener:: HTTP/1.1" 302 -
>>> "http://app.buzzstream.com/link_partners/wicket:pageMapName/link_partners/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js/wicket:pageMapName/resources";
>>> "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13)
>>> Gecko/20101203 Firefox/3.6.13 GTB7.1 ( .NET CLR 3.5.30729)"
>>> - - [13/Jan/2011:14:26:34 -0600] "GET /?wicket:interface=wicket-8:27
>>> HTTP/1.1" 200 3163
>>> "http://app.buzzstream.com/link_partners/wicket:pageMapName/link_partners/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js/wicket:pageMapName/resources";
>>> "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13)
>>> Gecko/20101203 Firefox/3.6.13 GTB7.1 ( .NET CLR 3.5.30729)"
>>>
>>>
>>> On Jan 14, 2011, at 5:23 PM, Igor Vaynberg wrote:
>>>
>>>> do their apache logs contain a sample of the url that caused this
>>>> error? would be helpful to see one.
>>>>
>>>> -igor
>>>>
>>>> On Fri, Jan 14, 2011 at 3:12 PM, Douglas Ferguson
>>>> wrote:
>>>>> Sorry about my previous title.
>>>>>
>>>>> I'm not sure what's causing this, but I've spoken with some of my
>>>>> clients, who spawned these errors and they weren't manipulating the
>>>>> querystrings..
>>>>> So I'm not sure how two pagemap paramenters are getting in there..
>>>>>
>>>>> D/
>>>>>
>>>>> On Jan 13, 2011, at 11:40 AM, Douglas Ferguson wrote:
>>>>>
>>>>>> I see the stack trace below in my production logs quite often.
>>>>>>
>>>>>> I'm not sure what is causing it but it seems that this error need not
>>>>>> happen. I.E. Why Cast this to a string when it could easily be String[]
>>>>>> if somebody messes with the query string?
>>>>>>
>>>>>> Seem like a parameters.removeFirst() method could prevent this..
>>>>>>
>>>>>> String pageMapNameEncoded =
>>>>>> (String)parameters.remove(WebRequestCodingStrategy.PAGEMAP);
>>>>>> if (requestParameters.getPageMapName() == null)
>>>>>> {
>>>>>>
>>>>>> requestParameters.setPageMapName(pageMapNameEncoded);
>>>>>> }
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [Ljava.lang.String; cannot be cast to java.lang.String
>>>>>>> java.lang.ClassCastException: [Ljava.lang.String; cannot be cast to
>>>>>>> java.lang.String
>>>>>>> at
>>>>>>> org.apache.wicket.request.target.coding.BookmarkablePageRequestTargetUrlCodingStrategy.decode(BookmarkablePageRequestTargetUrlCodingStrategy.java:91)
>>>>>>> at
>>>>>>> org.apache.wicket.protocol.http.request.WebRequestCodingStrategy.targetForRequest(WebRequestCodingStrategy.java:537)
>>>>>>> at
>>>>>>> org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:191)
>>>>>>> at
>>>>>>> org.apache.wicket.protocol.https.HttpsRequestCycleProcessor.resolve(HttpsRequestCycleProcessor.java:219)
>>>>>>> at
>>>>>>> com.conducive.wicket.PRManagerApplication$8.resolve(PRManagerApplication.java:709)
>>>>>>> at org.apache.wicket.RequestCycle.step(RequestCycle.java:1310)
>>>>>>> at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1436)
>>>>>>> at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
>
Re: [Ljava.lang.String; cannot be cast to java.lang.String - BookmarkablePageRequestTargetUrlCodingStrategy
Thoughts?
On Jan 14, 2011, at 5:44 PM, Douglas Ferguson wrote:
> This looks like it must have been one of them.
>
> - - [13/Jan/2011:14:26:34 -0600] "GET
> /?wicket:interface=:26::INewBrowserWindowListener:: HTTP/1.1" 302 -
> "http://app.buzzstream.com/link_partners/wicket:pageMapName/link_partners/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js/wicket:pageMapName/resources";
> "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101203
> Firefox/3.6.13 GTB7.1 ( .NET CLR 3.5.30729)"
> - - [13/Jan/2011:14:26:34 -0600] "GET /?wicket:interface=wicket-8:27
> HTTP/1.1" 200 3163
> "http://app.buzzstream.com/link_partners/wicket:pageMapName/link_partners/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js/wicket:pageMapName/resources";
> "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101203
> Firefox/3.6.13 GTB7.1 ( .NET CLR 3.5.30729)"
>
>
> On Jan 14, 2011, at 5:23 PM, Igor Vaynberg wrote:
>
>> do their apache logs contain a sample of the url that caused this
>> error? would be helpful to see one.
>>
>> -igor
>>
>> On Fri, Jan 14, 2011 at 3:12 PM, Douglas Ferguson
>> wrote:
>>> Sorry about my previous title.
>>>
>>> I'm not sure what's causing this, but I've spoken with some of my clients,
>>> who spawned these errors and they weren't manipulating the querystrings..
>>> So I'm not sure how two pagemap paramenters are getting in there..
>>>
>>> D/
>>>
>>> On Jan 13, 2011, at 11:40 AM, Douglas Ferguson wrote:
>>>
>>>> I see the stack trace below in my production logs quite often.
>>>>
>>>> I'm not sure what is causing it but it seems that this error need not
>>>> happen. I.E. Why Cast this to a string when it could easily be String[] if
>>>> somebody messes with the query string?
>>>>
>>>> Seem like a parameters.removeFirst() method could prevent this..
>>>>
>>>> String pageMapNameEncoded =
>>>> (String)parameters.remove(WebRequestCodingStrategy.PAGEMAP);
>>>> if (requestParameters.getPageMapName() == null)
>>>> {
>>>> requestParameters.setPageMapName(pageMapNameEncoded);
>>>> }
>>>>
>>>>
>>>>>
>>>>>
>>>>> [Ljava.lang.String; cannot be cast to java.lang.String
>>>>> java.lang.ClassCastException: [Ljava.lang.String; cannot be cast to
>>>>> java.lang.String
>>>>> at
>>>>> org.apache.wicket.request.target.coding.BookmarkablePageRequestTargetUrlCodingStrategy.decode(BookmarkablePageRequestTargetUrlCodingStrategy.java:91)
>>>>> at
>>>>> org.apache.wicket.protocol.http.request.WebRequestCodingStrategy.targetForRequest(WebRequestCodingStrategy.java:537)
>>>>> at
>>>>> org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:191)
>>>>> at
>>>>> org.apache.wicket.protocol.https.HttpsRequestCycleProcessor.resolve(HttpsRequestCycleProcessor.java:219)
>>>>> at
>>>>> com.conducive.wicket.PRManagerApplication$8.resolve(PRManagerApplication.java:709)
>>>>> at org.apache.wicket.RequestCycle.step(RequestCycle.java:1310)
>>>>> at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1436)
>>>>> at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
>>>>> at
>>>>> org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:484)
>>>>> at
>>>>> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:317)
>>>>> at
>>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
>>>>> at
>>>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
>>>>> at
>>>>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>>>>> at
>>>>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
>>>>> at
>>>>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>>>>> at
>>>>> org.apache.catalina.valves.Er
Re: [Ljava.lang.String; cannot be cast to java.lang.String - BookmarkablePageRequestTargetUrlCodingStrategy
This looks like it must have been one of them.
- - [13/Jan/2011:14:26:34 -0600] "GET
/?wicket:interface=:26::INewBrowserWindowListener:: HTTP/1.1" 302 -
"http://app.buzzstream.com/link_partners/wicket:pageMapName/link_partners/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js/wicket:pageMapName/resources";
"Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101203
Firefox/3.6.13 GTB7.1 ( .NET CLR 3.5.30729)"
- - [13/Jan/2011:14:26:34 -0600] "GET /?wicket:interface=wicket-8:27
HTTP/1.1" 200 3163
"http://app.buzzstream.com/link_partners/wicket:pageMapName/link_partners/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js/wicket:pageMapName/resources";
"Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101203
Firefox/3.6.13 GTB7.1 ( .NET CLR 3.5.30729)"
On Jan 14, 2011, at 5:23 PM, Igor Vaynberg wrote:
> do their apache logs contain a sample of the url that caused this
> error? would be helpful to see one.
>
> -igor
>
> On Fri, Jan 14, 2011 at 3:12 PM, Douglas Ferguson
> wrote:
>> Sorry about my previous title.
>>
>> I'm not sure what's causing this, but I've spoken with some of my clients,
>> who spawned these errors and they weren't manipulating the querystrings..
>> So I'm not sure how two pagemap paramenters are getting in there..
>>
>> D/
>>
>> On Jan 13, 2011, at 11:40 AM, Douglas Ferguson wrote:
>>
>>> I see the stack trace below in my production logs quite often.
>>>
>>> I'm not sure what is causing it but it seems that this error need not
>>> happen. I.E. Why Cast this to a string when it could easily be String[] if
>>> somebody messes with the query string?
>>>
>>> Seem like a parameters.removeFirst() method could prevent this..
>>>
>>> String pageMapNameEncoded =
>>> (String)parameters.remove(WebRequestCodingStrategy.PAGEMAP);
>>> if (requestParameters.getPageMapName() == null)
>>> {
>>> requestParameters.setPageMapName(pageMapNameEncoded);
>>> }
>>>
>>>
>>>>
>>>>
>>>> [Ljava.lang.String; cannot be cast to java.lang.String
>>>> java.lang.ClassCastException: [Ljava.lang.String; cannot be cast to
>>>> java.lang.String
>>>> at
>>>> org.apache.wicket.request.target.coding.BookmarkablePageRequestTargetUrlCodingStrategy.decode(BookmarkablePageRequestTargetUrlCodingStrategy.java:91)
>>>> at
>>>> org.apache.wicket.protocol.http.request.WebRequestCodingStrategy.targetForRequest(WebRequestCodingStrategy.java:537)
>>>> at
>>>> org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:191)
>>>> at
>>>> org.apache.wicket.protocol.https.HttpsRequestCycleProcessor.resolve(HttpsRequestCycleProcessor.java:219)
>>>> at
>>>> com.conducive.wicket.PRManagerApplication$8.resolve(PRManagerApplication.java:709)
>>>> at org.apache.wicket.RequestCycle.step(RequestCycle.java:1310)
>>>> at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1436)
>>>> at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
>>>> at
>>>> org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:484)
>>>> at
>>>> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:317)
>>>> at
>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
>>>> at
>>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
>>>> at
>>>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>>>> at
>>>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
>>>> at
>>>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>>>> at
>>>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
>>>> at
>>>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
>>>> at
>>>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
>>>> at
>>>> org
[Ljava.lang.String; cannot be cast to java.lang.String - BookmarkablePageRequestTargetUrlCodingStrategy
Sorry about my previous title.
I'm not sure what's causing this, but I've spoken with some of my clients, who
spawned these errors and they weren't manipulating the querystrings..
So I'm not sure how two pagemap paramenters are getting in there..
D/
On Jan 13, 2011, at 11:40 AM, Douglas Ferguson wrote:
> I see the stack trace below in my production logs quite often.
>
> I'm not sure what is causing it but it seems that this error need not happen.
> I.E. Why Cast this to a string when it could easily be String[] if somebody
> messes with the query string?
>
> Seem like a parameters.removeFirst() method could prevent this..
>
> String pageMapNameEncoded =
> (String)parameters.remove(WebRequestCodingStrategy.PAGEMAP);
> if (requestParameters.getPageMapName() == null)
> {
> requestParameters.setPageMapName(pageMapNameEncoded);
> }
>
>
>>
>>
>> [Ljava.lang.String; cannot be cast to java.lang.String
>> java.lang.ClassCastException: [Ljava.lang.String; cannot be cast to
>> java.lang.String
>> at
>> org.apache.wicket.request.target.coding.BookmarkablePageRequestTargetUrlCodingStrategy.decode(BookmarkablePageRequestTargetUrlCodingStrategy.java:91)
>> at
>> org.apache.wicket.protocol.http.request.WebRequestCodingStrategy.targetForRequest(WebRequestCodingStrategy.java:537)
>> at
>> org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:191)
>> at
>> org.apache.wicket.protocol.https.HttpsRequestCycleProcessor.resolve(HttpsRequestCycleProcessor.java:219)
>> at
>> com.conducive.wicket.PRManagerApplication$8.resolve(PRManagerApplication.java:709)
>> at org.apache.wicket.RequestCycle.step(RequestCycle.java:1310)
>> at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1436)
>> at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
>> at
>> org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:484)
>> at
>> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:317)
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
>> at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
>> at
>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>> at
>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
>> at
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>> at
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
>> at
>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
>> at
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
>> at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:200)
>> at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283)
>> at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:773)
>> at
>> org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:703)
>> at
>> org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:895)
>> at
>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
>> at java.lang.Thread.run(Unknown Source)
>>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Fwd: FogBugz (Case 17743) Inbox - Application Error : prmanager : [Ljava.lang.String; cannot be cast to java.lang.String
I see the stack trace below in my production logs quite often.
I'm not sure what is causing it but it seems that this error need not happen.
I.E. Why Cast this to a string when it could easily be String[] if somebody
messes with the query string?
Seem like a parameters.removeFirst() method could prevent this..
String pageMapNameEncoded =
(String)parameters.remove(WebRequestCodingStrategy.PAGEMAP);
if (requestParameters.getPageMapName() == null)
{
requestParameters.setPageMapName(pageMapNameEncoded);
}
>
>
> [Ljava.lang.String; cannot be cast to java.lang.String
> java.lang.ClassCastException: [Ljava.lang.String; cannot be cast to
> java.lang.String
> at
> org.apache.wicket.request.target.coding.BookmarkablePageRequestTargetUrlCodingStrategy.decode(BookmarkablePageRequestTargetUrlCodingStrategy.java:91)
> at
> org.apache.wicket.protocol.http.request.WebRequestCodingStrategy.targetForRequest(WebRequestCodingStrategy.java:537)
> at
> org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:191)
> at
> org.apache.wicket.protocol.https.HttpsRequestCycleProcessor.resolve(HttpsRequestCycleProcessor.java:219)
> at
> com.conducive.wicket.PRManagerApplication$8.resolve(PRManagerApplication.java:709)
> at org.apache.wicket.RequestCycle.step(RequestCycle.java:1310)
> at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1436)
> at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
> at
> org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:484)
> at
> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:317)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
> at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:200)
> at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283)
> at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:773)
> at
> org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:703)
> at
> org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:895)
> at
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
> at java.lang.Thread.run(Unknown Source)
>
getStatelessHint()?
I'm seeing some exceptions in my production log with this message "it could be that the component is inside a repeater make your component return false in getStatelessHint()" What does this mean? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: component not visible exception
We don't override isVisible() and we don't call setVisible() on the save button. But we do on the container. The container starts off hidden and an AjaxTimer is used to set it visible. On Nov 30, 2010, at 1:57 AM, Matthias Keller wrote: > One other thing to check is, do you have a custom isVisible() override in the > container or do you explicitly set it to visible/invisible using setVisible()? > If the former, this logic will usually be re-evaluated upon form submission > and if that logic depends on some state which might change upon submission, > you might get exactly that error. > > Matt > > On 2010-11-29 20:21, Igor Vaynberg wrote: >> another possibility, if this page is using hybrid url coding strategy, >> is that the session expires and the form is submitted against a new >> instance of the page - where the button is not visible. >> >> -igor >> >> On Mon, Nov 29, 2010 at 11:05 AM, Douglas Ferguson >> wrote: >>> The problem is that I can't recreate this error, but I see it in production >>> alot. >>> >>> So I have no way of looking at the action url. >>> >>> D/ >>> >>> >>> On Nov 29, 2010, at 12:59 PM, Igor Vaynberg wrote: >>> >>>> easy. >>>> >>>> the form's action url points to a version of the page where the button >>>> is not visible. so when the button is clicked and the form is >>>> submitted wicket rolls back the version of the page to one where >>>> button is not visible and you get the error. not sure that is what is >>>> happening in your app, but its one possible explanation. look at >>>> form's url and make sure none of your ajax actions are changing the >>>> page version. >>>> >>>> -igor >>>> >>>> On Mon, Nov 29, 2010 at 10:41 AM, Douglas Ferguson >>>> wrote: >>>>> We do toggle the visibility of the web markup container that contains the >>>>> button. >>>>> >>>>> Here's how it works. >>>>> >>>>> 1) Page loads and the container is hidden >>>>> 2) An ajax timer is used to watch for state to change >>>>> 3) When state changes we make the container visible (which then makes the >>>>> submit button visible) >>>>> >>>>> How could they user manage to click on the save button when is it not >>>>> visible? >>>>> >>>>> The only thing I can think of is that this could be some back button >>>>> issue. >>>>> But then again, I'm not sure how that would manifest... >>>>> >>>>> D/ >>>>> >>>>> On Nov 29, 2010, at 11:25 AM, Igor Vaynberg wrote: >>>>> >>>>>> in order for component to be visible all of its parents have to be >>>>>> visible from the page down to the component. same for the enabled >>>>>> state. >>>>>> >>>>>> -igor >>>>>> >>>>>> On Mon, Nov 29, 2010 at 9:21 AM, Douglas Ferguson >>>>>> wrote: >>>>>>> Hmm... even if we aren't changing the visibility of the button? >>>>>>> >>>>>>> On Nov 29, 2010, at 10:42 AM, Marco Mancini wrote: >>>>>>> >>>>>>>> try to set >>>>>>>> >>>>>>>> mybutton.setOutputMarkupPlaceholderTag(true); >>>>>>>> >>>>>>>> bye >>>>>>>> marco >>>>>>>> >>>>>>>> 2010/11/29 Martin Grigorov >>>>>>>> >>>>>>>>> On Mon, Nov 29, 2010 at 4:46 PM, Douglas Ferguson< >>>>>>>>> doug...@douglasferguson.us> wrote: >>>>>>>>> >>>>>>>>>> We have not overridden isVisible, nor have we do we have a popup >>>>>>>>>> modal. >>>>>>>>>> That's why I was asking if this could be a back button issue. >>>>>>>>>> >>>>>>>>>> The only thing we do is set the button enabled. Could this be the >>>>>>>>>> problem >>>>>>>>>> even thought he message it talking about visibility? >>>>>>>>>> >>>>>>>>> No. Th
Re: component not visible exception
That seems more likely to me. Is there anything I could do to prevent this? D/ On Nov 29, 2010, at 1:21 PM, Igor Vaynberg wrote: > another possibility, if this page is using hybrid url coding strategy, > is that the session expires and the form is submitted against a new > instance of the page - where the button is not visible. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: component not visible exception
The problem is that I can't recreate this error, but I see it in production alot. So I have no way of looking at the action url. D/ On Nov 29, 2010, at 12:59 PM, Igor Vaynberg wrote: > easy. > > the form's action url points to a version of the page where the button > is not visible. so when the button is clicked and the form is > submitted wicket rolls back the version of the page to one where > button is not visible and you get the error. not sure that is what is > happening in your app, but its one possible explanation. look at > form's url and make sure none of your ajax actions are changing the > page version. > > -igor > > On Mon, Nov 29, 2010 at 10:41 AM, Douglas Ferguson > wrote: >> We do toggle the visibility of the web markup container that contains the >> button. >> >> Here's how it works. >> >> 1) Page loads and the container is hidden >> 2) An ajax timer is used to watch for state to change >> 3) When state changes we make the container visible (which then makes the >> submit button visible) >> >> How could they user manage to click on the save button when is it not >> visible? >> >> The only thing I can think of is that this could be some back button issue. >> But then again, I'm not sure how that would manifest... >> >> D/ >> >> On Nov 29, 2010, at 11:25 AM, Igor Vaynberg wrote: >> >>> in order for component to be visible all of its parents have to be >>> visible from the page down to the component. same for the enabled >>> state. >>> >>> -igor >>> >>> On Mon, Nov 29, 2010 at 9:21 AM, Douglas Ferguson >>> wrote: >>>> Hmm... even if we aren't changing the visibility of the button? >>>> >>>> On Nov 29, 2010, at 10:42 AM, Marco Mancini wrote: >>>> >>>>> try to set >>>>> >>>>> mybutton.setOutputMarkupPlaceholderTag(true); >>>>> >>>>> bye >>>>> marco >>>>> >>>>> 2010/11/29 Martin Grigorov >>>>> >>>>>> On Mon, Nov 29, 2010 at 4:46 PM, Douglas Ferguson < >>>>>> doug...@douglasferguson.us> wrote: >>>>>> >>>>>>> We have not overridden isVisible, nor have we do we have a popup modal. >>>>>>> That's why I was asking if this could be a back button issue. >>>>>>> >>>>>>> The only thing we do is set the button enabled. Could this be the >>>>>>> problem >>>>>>> even thought he message it talking about visibility? >>>>>>> >>>>>> No. There is a separate check for enabled state. It is definitely for >>>>>> visibility. >>>>>> >>>>>>> >>>>>>> D/ >>>>>>> >>>>>>> On Nov 29, 2010, at 3:15 AM, Martin Grigorov wrote: >>>>>>> >>>>>>>> Here is another scenario: >>>>>>>> >>>>>>>> Ajax request sets the visibility of the submit button (or its parent) >>>>>> to >>>>>>>> false but forgets to repaint the button so it is still visible for the >>>>>>> user. >>>>>>>> Then the user clicks on this button, it fires and then the backend >>>>>> shows >>>>>>>> this message - the button is invisible so it cannot be clicked. >>>>>>>> >>>>>>>> On Mon, Nov 29, 2010 at 9:04 AM, Chris Colman >>>>>>>> wrote: >>>>>>>> >>>>>>>>> A back button where? >>>>>>>>> >>>>>>>>> The form is on a page and has a submit button only. If there is an >>>>>> error >>>>>>>>> a ModalWindow pops up - it only has an OK button which is meant to >>>>>> make >>>>>>>>> the ModalWindow simply disappear and thus re-enable the page beneath - >>>>>>>>> the one with the form on it. >>>>>>>>> >>>>>>>>> Chris >>>>>>>>>> -Original Message- >>>>>>>>>> From: Douglas Ferguson [mailto:doug...@douglasferguson.us] >>>>>>>>>> Sent: Monday, 29 November 2010 6:53 PM >>>>&
Re: component not visible exception
We do toggle the visibility of the web markup container that contains the button. Here's how it works. 1) Page loads and the container is hidden 2) An ajax timer is used to watch for state to change 3) When state changes we make the container visible (which then makes the submit button visible) How could they user manage to click on the save button when is it not visible? The only thing I can think of is that this could be some back button issue. But then again, I'm not sure how that would manifest... D/ On Nov 29, 2010, at 11:25 AM, Igor Vaynberg wrote: > in order for component to be visible all of its parents have to be > visible from the page down to the component. same for the enabled > state. > > -igor > > On Mon, Nov 29, 2010 at 9:21 AM, Douglas Ferguson > wrote: >> Hmm... even if we aren't changing the visibility of the button? >> >> On Nov 29, 2010, at 10:42 AM, Marco Mancini wrote: >> >>> try to set >>> >>> mybutton.setOutputMarkupPlaceholderTag(true); >>> >>> bye >>> marco >>> >>> 2010/11/29 Martin Grigorov >>> >>>> On Mon, Nov 29, 2010 at 4:46 PM, Douglas Ferguson < >>>> doug...@douglasferguson.us> wrote: >>>> >>>>> We have not overridden isVisible, nor have we do we have a popup modal. >>>>> That's why I was asking if this could be a back button issue. >>>>> >>>>> The only thing we do is set the button enabled. Could this be the problem >>>>> even thought he message it talking about visibility? >>>>> >>>> No. There is a separate check for enabled state. It is definitely for >>>> visibility. >>>> >>>>> >>>>> D/ >>>>> >>>>> On Nov 29, 2010, at 3:15 AM, Martin Grigorov wrote: >>>>> >>>>>> Here is another scenario: >>>>>> >>>>>> Ajax request sets the visibility of the submit button (or its parent) >>>> to >>>>>> false but forgets to repaint the button so it is still visible for the >>>>> user. >>>>>> Then the user clicks on this button, it fires and then the backend >>>> shows >>>>>> this message - the button is invisible so it cannot be clicked. >>>>>> >>>>>> On Mon, Nov 29, 2010 at 9:04 AM, Chris Colman >>>>>> wrote: >>>>>> >>>>>>> A back button where? >>>>>>> >>>>>>> The form is on a page and has a submit button only. If there is an >>>> error >>>>>>> a ModalWindow pops up - it only has an OK button which is meant to >>>> make >>>>>>> the ModalWindow simply disappear and thus re-enable the page beneath - >>>>>>> the one with the form on it. >>>>>>> >>>>>>> Chris >>>>>>>> -Original Message- >>>>>>>> From: Douglas Ferguson [mailto:doug...@douglasferguson.us] >>>>>>>> Sent: Monday, 29 November 2010 6:53 PM >>>>>>>> To: users@wicket.apache.org >>>>>>>> Subject: Re: component not visible exception >>>>>>>> >>>>>>>> Could this be happening because of the back button? >>>>>>>> >>>>>>>> D/ >>>>>>>> >>>>>>>> On Nov 28, 2010, at 4:54 AM, Chris Colman wrote: >>>>>>>> >>>>>>>>> I had a similar problem. In my scenario it occurred when a >>>>>>> ModalWindow >>>>>>>>> was brought up when a form failed validation. When they clicked ok >>>> to >>>>>>>>> close the ModalWindow and then clicked Submit on the form again I >>>> got >>>>>>> a >>>>>>>>> similar message saying that the Submit button was no longer visible. >>>>>>>>> >>>>>>>>> It doesn't happen if I use the normal validation 'feedback' panel to >>>>>>>>> display the validation error messages. >>>>>>>>> >>>>>>>>> Chris >>>>>>>>> >>>>>>>>>> -Original Message- >>>>>>>>>
Re: component not visible exception
Hmm... even if we aren't changing the visibility of the button? On Nov 29, 2010, at 10:42 AM, Marco Mancini wrote: > try to set > > mybutton.setOutputMarkupPlaceholderTag(true); > > bye > marco > > 2010/11/29 Martin Grigorov > >> On Mon, Nov 29, 2010 at 4:46 PM, Douglas Ferguson < >> doug...@douglasferguson.us> wrote: >> >>> We have not overridden isVisible, nor have we do we have a popup modal. >>> That's why I was asking if this could be a back button issue. >>> >>> The only thing we do is set the button enabled. Could this be the problem >>> even thought he message it talking about visibility? >>> >> No. There is a separate check for enabled state. It is definitely for >> visibility. >> >>> >>> D/ >>> >>> On Nov 29, 2010, at 3:15 AM, Martin Grigorov wrote: >>> >>>> Here is another scenario: >>>> >>>> Ajax request sets the visibility of the submit button (or its parent) >> to >>>> false but forgets to repaint the button so it is still visible for the >>> user. >>>> Then the user clicks on this button, it fires and then the backend >> shows >>>> this message - the button is invisible so it cannot be clicked. >>>> >>>> On Mon, Nov 29, 2010 at 9:04 AM, Chris Colman >>>> wrote: >>>> >>>>> A back button where? >>>>> >>>>> The form is on a page and has a submit button only. If there is an >> error >>>>> a ModalWindow pops up - it only has an OK button which is meant to >> make >>>>> the ModalWindow simply disappear and thus re-enable the page beneath - >>>>> the one with the form on it. >>>>> >>>>> Chris >>>>>> -Original Message- >>>>>> From: Douglas Ferguson [mailto:doug...@douglasferguson.us] >>>>>> Sent: Monday, 29 November 2010 6:53 PM >>>>>> To: users@wicket.apache.org >>>>>> Subject: Re: component not visible exception >>>>>> >>>>>> Could this be happening because of the back button? >>>>>> >>>>>> D/ >>>>>> >>>>>> On Nov 28, 2010, at 4:54 AM, Chris Colman wrote: >>>>>> >>>>>>> I had a similar problem. In my scenario it occurred when a >>>>> ModalWindow >>>>>>> was brought up when a form failed validation. When they clicked ok >> to >>>>>>> close the ModalWindow and then clicked Submit on the form again I >> got >>>>> a >>>>>>> similar message saying that the Submit button was no longer visible. >>>>>>> >>>>>>> It doesn't happen if I use the normal validation 'feedback' panel to >>>>>>> display the validation error messages. >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>>> -Original Message- >>>>>>>> From: Douglas Ferguson [mailto:doug...@douglasferguson.us] >>>>>>>> Sent: Saturday, 27 November 2010 3:13 AM >>>>>>>> To: Wicket Mailing List List >>>>>>>> Subject: component not visible exception >>>>>>>> >>>>>>>> I have an error I've been seeing in the production logs for awhile >>>>> now >>>>>>> and >>>>>>>> haven't been able to to figure it out. >>>>>>>> >>>>>>>> My thought is that it is due to a stale page or the back button, >> but >>>>> it >>>>>>>> seems to me that it is happening alot, so I thought I might >> inquire. >>>>>>>> >>>>>>>> Any thoughts on what might be causing this and how to avoid it? >>>>>>>> >>>>>>>> 2010-11-26 08:36:36,676 ERROR [TP-Processor34] wicket.RequestCycle >> - >>>>>>> Submit >>>>>>>> Button add (path=dataPanel:contentCenterBox:addUserForm:add) is not >>>>>>> visible >>>>>>>> org.apache.wicket.WicketRuntimeException: Submit Button add >>>>>>>> (path=dataPanel:contentCenterBox:addUserForm:add) is not visible >>>>>>>> at >>>>>>>
Re: component not visible exception
That is wierd.. the component is a field and is private. We don't set visible nor do we override isVisible(). Could this have to do with the parent container? We do set that visible... On Nov 29, 2010, at 9:58 AM, Martin Grigorov wrote: > On Mon, Nov 29, 2010 at 4:46 PM, Douglas Ferguson < > doug...@douglasferguson.us> wrote: > >> We have not overridden isVisible, nor have we do we have a popup modal. >> That's why I was asking if this could be a back button issue. >> >> The only thing we do is set the button enabled. Could this be the problem >> even thought he message it talking about visibility? >> > No. There is a separate check for enabled state. It is definitely for > visibility. > >> >> D/ >> >> On Nov 29, 2010, at 3:15 AM, Martin Grigorov wrote: >> >>> Here is another scenario: >>> >>> Ajax request sets the visibility of the submit button (or its parent) to >>> false but forgets to repaint the button so it is still visible for the >> user. >>> Then the user clicks on this button, it fires and then the backend shows >>> this message - the button is invisible so it cannot be clicked. >>> >>> On Mon, Nov 29, 2010 at 9:04 AM, Chris Colman >>> wrote: >>> >>>> A back button where? >>>> >>>> The form is on a page and has a submit button only. If there is an error >>>> a ModalWindow pops up - it only has an OK button which is meant to make >>>> the ModalWindow simply disappear and thus re-enable the page beneath - >>>> the one with the form on it. >>>> >>>> Chris >>>>> -Original Message- >>>>> From: Douglas Ferguson [mailto:doug...@douglasferguson.us] >>>>> Sent: Monday, 29 November 2010 6:53 PM >>>>> To: users@wicket.apache.org >>>>> Subject: Re: component not visible exception >>>>> >>>>> Could this be happening because of the back button? >>>>> >>>>> D/ >>>>> >>>>> On Nov 28, 2010, at 4:54 AM, Chris Colman wrote: >>>>> >>>>>> I had a similar problem. In my scenario it occurred when a >>>> ModalWindow >>>>>> was brought up when a form failed validation. When they clicked ok to >>>>>> close the ModalWindow and then clicked Submit on the form again I got >>>> a >>>>>> similar message saying that the Submit button was no longer visible. >>>>>> >>>>>> It doesn't happen if I use the normal validation 'feedback' panel to >>>>>> display the validation error messages. >>>>>> >>>>>> Chris >>>>>> >>>>>>> -Original Message- >>>>>>> From: Douglas Ferguson [mailto:doug...@douglasferguson.us] >>>>>>> Sent: Saturday, 27 November 2010 3:13 AM >>>>>>> To: Wicket Mailing List List >>>>>>> Subject: component not visible exception >>>>>>> >>>>>>> I have an error I've been seeing in the production logs for awhile >>>> now >>>>>> and >>>>>>> haven't been able to to figure it out. >>>>>>> >>>>>>> My thought is that it is due to a stale page or the back button, but >>>> it >>>>>>> seems to me that it is happening alot, so I thought I might inquire. >>>>>>> >>>>>>> Any thoughts on what might be causing this and how to avoid it? >>>>>>> >>>>>>> 2010-11-26 08:36:36,676 ERROR [TP-Processor34] wicket.RequestCycle - >>>>>> Submit >>>>>>> Button add (path=dataPanel:contentCenterBox:addUserForm:add) is not >>>>>> visible >>>>>>> org.apache.wicket.WicketRuntimeException: Submit Button add >>>>>>> (path=dataPanel:contentCenterBox:addUserForm:add) is not visible >>>>>>> at >>>>>> org.apache.wicket.markup.html.form.Form$2.component(Form.java:622) >>>>>>> at >>>>>>> >>>> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:89 >>>>>> 9) >>>>>>> at >>>>>>> >>>> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 >>>>>> 4) >>>
Re: component not visible exception
We have not overridden isVisible, nor have we do we have a popup modal. That's why I was asking if this could be a back button issue. The only thing we do is set the button enabled. Could this be the problem even thought he message it talking about visibility? D/ On Nov 29, 2010, at 3:15 AM, Martin Grigorov wrote: > Here is another scenario: > > Ajax request sets the visibility of the submit button (or its parent) to > false but forgets to repaint the button so it is still visible for the user. > Then the user clicks on this button, it fires and then the backend shows > this message - the button is invisible so it cannot be clicked. > > On Mon, Nov 29, 2010 at 9:04 AM, Chris Colman > wrote: > >> A back button where? >> >> The form is on a page and has a submit button only. If there is an error >> a ModalWindow pops up - it only has an OK button which is meant to make >> the ModalWindow simply disappear and thus re-enable the page beneath - >> the one with the form on it. >> >> Chris >>> -Original Message- >>> From: Douglas Ferguson [mailto:doug...@douglasferguson.us] >>> Sent: Monday, 29 November 2010 6:53 PM >>> To: users@wicket.apache.org >>> Subject: Re: component not visible exception >>> >>> Could this be happening because of the back button? >>> >>> D/ >>> >>> On Nov 28, 2010, at 4:54 AM, Chris Colman wrote: >>> >>>> I had a similar problem. In my scenario it occurred when a >> ModalWindow >>>> was brought up when a form failed validation. When they clicked ok to >>>> close the ModalWindow and then clicked Submit on the form again I got >> a >>>> similar message saying that the Submit button was no longer visible. >>>> >>>> It doesn't happen if I use the normal validation 'feedback' panel to >>>> display the validation error messages. >>>> >>>> Chris >>>> >>>>> -Original Message- >>>>> From: Douglas Ferguson [mailto:doug...@douglasferguson.us] >>>>> Sent: Saturday, 27 November 2010 3:13 AM >>>>> To: Wicket Mailing List List >>>>> Subject: component not visible exception >>>>> >>>>> I have an error I've been seeing in the production logs for awhile >> now >>>> and >>>>> haven't been able to to figure it out. >>>>> >>>>> My thought is that it is due to a stale page or the back button, but >> it >>>>> seems to me that it is happening alot, so I thought I might inquire. >>>>> >>>>> Any thoughts on what might be causing this and how to avoid it? >>>>> >>>>> 2010-11-26 08:36:36,676 ERROR [TP-Processor34] wicket.RequestCycle - >>>> Submit >>>>> Button add (path=dataPanel:contentCenterBox:addUserForm:add) is not >>>> visible >>>>> org.apache.wicket.WicketRuntimeException: Submit Button add >>>>> (path=dataPanel:contentCenterBox:addUserForm:add) is not visible >>>>>at >>>> org.apache.wicket.markup.html.form.Form$2.component(Form.java:622) >>>>>at >>>>> >> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:89 >>>> 9) >>>>>at >>>>> >> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 >>>> 4) >>>>>at >>>>> >> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 >>>> 4) >>>>>at >>>>> >> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 >>>> 4) >>>>>at >>>>> >> org.apache.wicket.markup.html.form.Form.findSubmittingButton(Form.java: >>>> 604) >>>>>at >>>>> >> org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:899) >>>>>at >>>>> >> org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubm >>>> itBe >>>>> havior.java:135) >>>>>at >>>>> >> org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java >>>> :177 >>>>> ) >>>>>at >>>>> >> org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDe >>>> faul >>>>> tAjaxBehavior.java:300) >>>>>
Re: component not visible exception
Could this be happening because of the back button? D/ On Nov 28, 2010, at 4:54 AM, Chris Colman wrote: > I had a similar problem. In my scenario it occurred when a ModalWindow > was brought up when a form failed validation. When they clicked ok to > close the ModalWindow and then clicked Submit on the form again I got a > similar message saying that the Submit button was no longer visible. > > It doesn't happen if I use the normal validation 'feedback' panel to > display the validation error messages. > > Chris > >> -Original Message- >> From: Douglas Ferguson [mailto:doug...@douglasferguson.us] >> Sent: Saturday, 27 November 2010 3:13 AM >> To: Wicket Mailing List List >> Subject: component not visible exception >> >> I have an error I've been seeing in the production logs for awhile now > and >> haven't been able to to figure it out. >> >> My thought is that it is due to a stale page or the back button, but it >> seems to me that it is happening alot, so I thought I might inquire. >> >> Any thoughts on what might be causing this and how to avoid it? >> >> 2010-11-26 08:36:36,676 ERROR [TP-Processor34] wicket.RequestCycle - > Submit >> Button add (path=dataPanel:contentCenterBox:addUserForm:add) is not > visible >> org.apache.wicket.WicketRuntimeException: Submit Button add >> (path=dataPanel:contentCenterBox:addUserForm:add) is not visible >> at > org.apache.wicket.markup.html.form.Form$2.component(Form.java:622) >> at >> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:89 > 9) >> at >> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 > 4) >> at >> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 > 4) >> at >> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:91 > 4) >> at >> org.apache.wicket.markup.html.form.Form.findSubmittingButton(Form.java: > 604) >> at >> org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:899) >> at >> org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubm > itBe >> havior.java:135) >> at >> org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java > :177 >> ) >> at >> org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDe > faul >> tAjaxBehavior.java:300) >> at >> org.apache.wicket.request.target.component.listener.BehaviorRequestTarg > et.p >> rocessEvents(BehaviorRequestTarget.java:119) >> at >> org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(A > bstr >> actRequestCycleProcessor.java:92) >> at >> org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.jav > a:12 >> 50) >> at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329) >> at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1436) >> at org.apache.wicket.RequestCycle.request(RequestCycle.java:545) >> at >> org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:48 > 4) >> at >> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java > :317 >> ) >> at >> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applic > atio >> nFilterChain.java:215) >> at >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFil > terC >> hain.java:188) >> at >> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperVal > ve.j >> ava:213) >> at >> org.apache.catalina.core.StandardContextValve.invoke(StandardContextVal > ve.j >> ava:172) >> at >> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.jav > a:12 >> 7) >> at >> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.jav > a:11 >> 7) >> at >> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve > .jav >> a:108) >> at >> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java: > 151) >> at >> org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:200) >> at >> org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283) >> at > org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:773) >> at >> org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java > :703 >> ) >
component not visible exception
I have an error I've been seeing in the production logs for awhile now and haven't been able to to figure it out. My thought is that it is due to a stale page or the back button, but it seems to me that it is happening alot, so I thought I might inquire. Any thoughts on what might be causing this and how to avoid it? 2010-11-26 08:36:36,676 ERROR [TP-Processor34] wicket.RequestCycle - Submit Button add (path=dataPanel:contentCenterBox:addUserForm:add) is not visible org.apache.wicket.WicketRuntimeException: Submit Button add (path=dataPanel:contentCenterBox:addUserForm:add) is not visible at org.apache.wicket.markup.html.form.Form$2.component(Form.java:622) at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:899) at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:914) at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:914) at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:914) at org.apache.wicket.markup.html.form.Form.findSubmittingButton(Form.java:604) at org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:899) at org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubmitBehavior.java:135) at org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:177) at org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:300) at org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:119) at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1250) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1436) at org.apache.wicket.RequestCycle.request(RequestCycle.java:545) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:484) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:317) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:200) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:773) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:703) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:895) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Unknown Source) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: StackOverflowError
Why not just throw and illegal argument exception when you try to create a
model with a session?
D/
On Nov 19, 2010, at 3:16 AM, Erik van Oosten wrote:
> Pedro's solution allows you to turn serialisation on and off for a given
> thread so you won't mess with serialisation by other users (such as the
> servlet container).
>
> Clever. The only missing piece is an override of the default serialisation to
> temporarily flip the switch.
>
> Still, in core it would be much more useful. Users that can configure this
> kind of tricks don't tend to make the mistake of referring a session anyway.
>
> Regards,
>Erik.
>
>
> Op 18-11-10 18:31, Martijn Dashorst schreef:
>> Sessions are meant to be serialized. That's the way they travel
>> through a cluster, or how sessions are preserved during a server
>> restart. I'd like to not break that by adding this functionality.
>>
>> Martijn
>>
>> On Thu, Nov 18, 2010 at 6:19 PM, Pedro Santos wrote:
>>> Ok, I still don't know how interest is to have it in the core. You can do it
>>> at an session extension, like:
>>>
>>> 1- providing some API
>>>
>>> MySession extends Session{
>>>private ThreadLocal sessionSerializationRestrictor = new
>>> ThreadLocal();
>>>public void inhibitSerializationOnThread(Object restrictor){
>>>sessionSerializationRestrictor.set(restrictor); }
>>>
>>>public void removeSerializationRestriction(){
>>>sessionSerializationRestrictor.set(null);}
>>>
>>>private void writeObject(java.io.ObjectOutputStream out) throws
>>> IOException {
>>>if (sessionSerializationRestrictor.get() != null) {
>>>throw some exception explaining that the restrictor do not allow
>>> this serialization;
>>>} else {
>>>out.defaultWriteObject();
>>>} }}
>>>
>>> 2- providing some Page.IPageSerializer that calls
>>> inhibitSerializationOnThread and removeSerializationRestriction before and
>>> after the page serialization.
>>>
>>> On Thu, Nov 18, 2010 at 6:48 AM, Erik van Oostenwrote:
>>>
That won't work in general as some servlet containers (like tomcat)
serialise the session to disk when its idle for too long.
What I meant is that when the page is serialised, it _must_ not contain a
reference to session.
but than some other developers can complain because they are deliberated
> serialializing some session.
>
They won't complain when the exception text specifies why this is wrong.
See Martijn's e-mail in this discussion thread for why it is wrong.
Regards,
Erik.
Op 17-11-10 21:05, Pedro Santos schreef:
I think it is to specific. You can override the Session on your app an
> catch
> this situation like:
>
> private void writeObject(java.io.ObjectOutputStream out) throws
> IOException {
> if (Application.get() != null&&
> Application.get().getConfigurationType().equals(Application.DEPLOYMENT)) {
> log.info("Session is being serialized in the development
> environment, which is an not a desirable behavior.");
> }}
>
> but than some other developers can complain because they are deliberated
> serialializing some session.
>
> On Wed, Nov 17, 2010 at 4:49 PM, Erik van Oosten> wrote:
>> Shouldn't serialization fail when it references session/application?
>> Perhaps only in development mode.
>>
>> Regards,
>>Erik.
>>
>> Op 16-11-10 19:03, Igor Vaynberg schreef:
>>
>> added a log warning to property models when they reference session.
>>
>
> --
> Sent from my SMTP compliant software
> Erik van Oosten
> http://day-to-day-stuff.blogspot.com/
>
>
>
> -
> 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
Re: StackOverflowError
Yeah.. there should really be a warning or a fatal exception in this case.. it
is an easy mistake for beginners.
I even knew to look for it and I couldn't find it..
D/
On Nov 16, 2010, at 12:05 PM, Martijn Dashorst wrote:
> DON'T DO THIS:
>
> the offending code probably was:
>
> add(new Label("id", new PropertyModel(getSession(), "someProperty")));
>
> This hard links the session to the page, and causes a cycle when serializing.
>
> Martijn
>
> On Tue, Nov 16, 2010 at 6:59 PM, jcgarciam wrote:
>>
>> Douglas, can you share any insight of how having the session in the property
>> model could actually provoke this leak?
>>
>> It seems weird.
>>
>> On Tue, Nov 16, 2010 at 2:56 PM, Igor Vaynberg-2 [via Apache Wicket] <
>> ml-node+3045359-698752336-65...@n4.nabble.com
>>> wrote:
>>
>>> it is perfectly valid to use page as the model object. in fact if you
>>> wanted to pull something out of session you can simply say new
>>> PropertyModel(this, "session.property"), this being the Page instance
>>> you are in.
>>>
>>> -igor
>>>
>>> On Tue, Nov 16, 2010 at 9:46 AM, Douglas Ferguson
>>> <[hidden email] <http://user/SendEmail.jtp?type=node&node=3045359&i=0>>
>>> wrote:
>>>
>>>> We found it.. Finally!!!
>>>>
>>>> There was a property model that was using the session as the model
>>> object.
>>>>
>>>> It would be cool if PropertyModel, etc would check for this and blow up
>>> on construction.
>>>> i.e. not allow Page, Session, Application as the model object...
>>>>
>>>> D/
>>>> On Nov 16, 2010, at 11:20 AM, Douglas Ferguson wrote:
>>>>
>>>>> Just tested on 1.4.13 and it still happens
>>>>>
>>>>> On Nov 16, 2010, at 9:43 AM, Douglas Ferguson wrote:
>>>>>
>>>>>> 1.4.12, but the problem has been around since a few versions back.
>>>>>>
>>>>>> D/
>>>>>>
>>>>>> On Nov 16, 2010, at 12:43 AM, Martijn Dashorst wrote:
>>>>>>
>>>>>>> Are you using 1.4.13?
>>>>>>>
>>>>>>> Martijn
>>>>>>>
>>>>>>> On Tue, Nov 16, 2010 at 5:54 AM, Douglas Ferguson
>>>>>>> <[hidden email]<http://user/SendEmail.jtp?type=node&node=3045359&i=1>>
>>> wrote:
>>>>>>>> Some time ago I posted to the list regarding a stack overflow error
>>> that I was receiving and the advice was to make sure that I didn't have a
>>> page storing a reference to another page.
>>>>>>>> We did track this down and have just had to ignore it in the
>>> production logs. Now we've made it a priority to track this down.
>>>>>>>>
>>>>>>>> Anyway, we've recently tracked this down to
>>> "AutomaticMultiWindowSupport" feature. We are able to recreate the bug by
>>> pasting a url into a new browser window and thus generating a new pagemap.
>>> On a certain page the memory consumption doubles as you generate new
>>> pagemaps (see the chart below). The profile is indicating that the memory is
>>> being taken up by a hashmap, but that's as far as we've been able to trace
>>> it so far.
>>>>>>>>
>>>>>>>>> PageMap #SizeGrowth
>>>>>>>>> 133895234481.93
>>>>>>>>> 122020590961.93
>>>>>>>>> 111048040961.93
>>>>>>>>> 10543522801.93
>>>>>>>>> 9281827601.93
>>>>>>>>> 8145949761.93
>>>>>>>>> 775493361.94
>>>>>>>>> 639007041.94
>>>>>>>>> 520134802
>>>>>>>>> 410069602
>>>>>>>>> 35036962
>>>>>>>>> 22520721.86
>>>>>>>>> 1135704
>>>>>>>>
>>>>>>>>
>>>>>>>> Any thoughts or tips on trying to get to the bottom of this one?
>>>>>>>>
>>>>>>>> Here's the stack trace
>>>>>>>>
>>>>>>>>>
Re: StackOverflowError
so I guess it knows not to serialize itself again if it sees it in a model? On Nov 16, 2010, at 11:55 AM, Igor Vaynberg wrote: > PropertyModel(this, "session.property"), this being the Page instance > you are in. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: StackOverflowError
yup..
On Nov 16, 2010, at 12:05 PM, Martijn Dashorst wrote:
> DON'T DO THIS:
>
> the offending code probably was:
>
> add(new Label("id", new PropertyModel(getSession(), "someProperty")));
>
> This hard links the session to the page, and causes a cycle when serializing.
>
> Martijn
>
> On Tue, Nov 16, 2010 at 6:59 PM, jcgarciam wrote:
>>
>> Douglas, can you share any insight of how having the session in the property
>> model could actually provoke this leak?
>>
>> It seems weird.
>>
>> On Tue, Nov 16, 2010 at 2:56 PM, Igor Vaynberg-2 [via Apache Wicket] <
>> ml-node+3045359-698752336-65...@n4.nabble.com
>>> wrote:
>>
>>> it is perfectly valid to use page as the model object. in fact if you
>>> wanted to pull something out of session you can simply say new
>>> PropertyModel(this, "session.property"), this being the Page instance
>>> you are in.
>>>
>>> -igor
>>>
>>> On Tue, Nov 16, 2010 at 9:46 AM, Douglas Ferguson
>>> <[hidden email] <http://user/SendEmail.jtp?type=node&node=3045359&i=0>>
>>> wrote:
>>>
>>>> We found it.. Finally!!!
>>>>
>>>> There was a property model that was using the session as the model
>>> object.
>>>>
>>>> It would be cool if PropertyModel, etc would check for this and blow up
>>> on construction.
>>>> i.e. not allow Page, Session, Application as the model object...
>>>>
>>>> D/
>>>> On Nov 16, 2010, at 11:20 AM, Douglas Ferguson wrote:
>>>>
>>>>> Just tested on 1.4.13 and it still happens
>>>>>
>>>>> On Nov 16, 2010, at 9:43 AM, Douglas Ferguson wrote:
>>>>>
>>>>>> 1.4.12, but the problem has been around since a few versions back.
>>>>>>
>>>>>> D/
>>>>>>
>>>>>> On Nov 16, 2010, at 12:43 AM, Martijn Dashorst wrote:
>>>>>>
>>>>>>> Are you using 1.4.13?
>>>>>>>
>>>>>>> Martijn
>>>>>>>
>>>>>>> On Tue, Nov 16, 2010 at 5:54 AM, Douglas Ferguson
>>>>>>> <[hidden email]<http://user/SendEmail.jtp?type=node&node=3045359&i=1>>
>>> wrote:
>>>>>>>> Some time ago I posted to the list regarding a stack overflow error
>>> that I was receiving and the advice was to make sure that I didn't have a
>>> page storing a reference to another page.
>>>>>>>> We did track this down and have just had to ignore it in the
>>> production logs. Now we've made it a priority to track this down.
>>>>>>>>
>>>>>>>> Anyway, we've recently tracked this down to
>>> "AutomaticMultiWindowSupport" feature. We are able to recreate the bug by
>>> pasting a url into a new browser window and thus generating a new pagemap.
>>> On a certain page the memory consumption doubles as you generate new
>>> pagemaps (see the chart below). The profile is indicating that the memory is
>>> being taken up by a hashmap, but that's as far as we've been able to trace
>>> it so far.
>>>>>>>>
>>>>>>>>> PageMap #SizeGrowth
>>>>>>>>> 133895234481.93
>>>>>>>>> 122020590961.93
>>>>>>>>> 111048040961.93
>>>>>>>>> 10543522801.93
>>>>>>>>> 9281827601.93
>>>>>>>>> 8145949761.93
>>>>>>>>> 775493361.94
>>>>>>>>> 639007041.94
>>>>>>>>> 520134802
>>>>>>>>> 410069602
>>>>>>>>> 35036962
>>>>>>>>> 22520721.86
>>>>>>>>> 1135704
>>>>>>>>
>>>>>>>>
>>>>>>>> Any thoughts or tips on trying to get to the bottom of this one?
>>>>>>>>
>>>>>>>> Here's the stack trace
>>>>>>>>
>>>>>>>>> at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)
>>>>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
Re: StackOverflowError
We found it.. Finally!!! There was a property model that was using the session as the model object. It would be cool if PropertyModel, etc would check for this and blow up on construction. i.e. not allow Page, Session, Application as the model object... D/ On Nov 16, 2010, at 11:20 AM, Douglas Ferguson wrote: > Just tested on 1.4.13 and it still happens > > On Nov 16, 2010, at 9:43 AM, Douglas Ferguson wrote: > >> 1.4.12, but the problem has been around since a few versions back. >> >> D/ >> >> On Nov 16, 2010, at 12:43 AM, Martijn Dashorst wrote: >> >>> Are you using 1.4.13? >>> >>> Martijn >>> >>> On Tue, Nov 16, 2010 at 5:54 AM, Douglas Ferguson >>> wrote: >>>> Some time ago I posted to the list regarding a stack overflow error that I >>>> was receiving and the advice was to make sure that I didn't have a page >>>> storing a reference to another page. >>>> We did track this down and have just had to ignore it in the production >>>> logs. Now we've made it a priority to track this down. >>>> >>>> Anyway, we've recently tracked this down to "AutomaticMultiWindowSupport" >>>> feature. We are able to recreate the bug by pasting a url into a new >>>> browser window and thus generating a new pagemap. On a certain page the >>>> memory consumption doubles as you generate new pagemaps (see the chart >>>> below). The profile is indicating that the memory is being taken up by a >>>> hashmap, but that's as far as we've been able to trace it so far. >>>> >>>>> PageMap #SizeGrowth >>>>> 133895234481.93 >>>>> 122020590961.93 >>>>> 111048040961.93 >>>>> 10543522801.93 >>>>> 9281827601.93 >>>>> 8145949761.93 >>>>> 775493361.94 >>>>> 639007041.94 >>>>> 520134802 >>>>> 410069602 >>>>> 35036962 >>>>> 22520721.86 >>>>> 1135704 >>>> >>>> >>>> Any thoughts or tips on trying to get to the bottom of this one? >>>> >>>> Here's the stack trace >>>> >>>>> at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source) >>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) >>>>> at java.lang.reflect.Method.invoke(Unknown Source) >>>>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source) >>>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source) >>>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) >>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source) >>>>> at java.io.ObjectOutputStream.writeObject(Unknown Source) >>>>> at java.util.LinkedList.writeObject(Unknown Source) >>>>> at sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source) >>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) >>>>> at java.lang.reflect.Method.invoke(Unknown Source) >>>>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source) >>>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source) >>>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) >>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source) >>>>> at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source) >>>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source) >>>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) >>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source) >>>>> at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source) >>>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source) >>>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) >>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source) >>>>> at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source) >>>>> at java.io.ObjectOutputStream.defaultWriteObject(Unknown Source) >>>>> at org.apache.wicket.Component.writeObject(Component.java:4660) >>>>> at sun.reflect.GeneratedMethodAccessor38.invoke
Re: StackOverflowError
Just tested on 1.4.13 and it still happens On Nov 16, 2010, at 9:43 AM, Douglas Ferguson wrote: > 1.4.12, but the problem has been around since a few versions back. > > D/ > > On Nov 16, 2010, at 12:43 AM, Martijn Dashorst wrote: > >> Are you using 1.4.13? >> >> Martijn >> >> On Tue, Nov 16, 2010 at 5:54 AM, Douglas Ferguson >> wrote: >>> Some time ago I posted to the list regarding a stack overflow error that I >>> was receiving and the advice was to make sure that I didn't have a page >>> storing a reference to another page. >>> We did track this down and have just had to ignore it in the production >>> logs. Now we've made it a priority to track this down. >>> >>> Anyway, we've recently tracked this down to "AutomaticMultiWindowSupport" >>> feature. We are able to recreate the bug by pasting a url into a new >>> browser window and thus generating a new pagemap. On a certain page the >>> memory consumption doubles as you generate new pagemaps (see the chart >>> below). The profile is indicating that the memory is being taken up by a >>> hashmap, but that's as far as we've been able to trace it so far. >>> >>>> PageMap #SizeGrowth >>>> 133895234481.93 >>>> 122020590961.93 >>>> 111048040961.93 >>>> 10543522801.93 >>>> 9281827601.93 >>>> 8145949761.93 >>>> 775493361.94 >>>> 639007041.94 >>>> 520134802 >>>> 410069602 >>>> 35036962 >>>> 22520721.86 >>>> 1135704 >>> >>> >>> Any thoughts or tips on trying to get to the bottom of this one? >>> >>> Here's the stack trace >>> >>>> at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source) >>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) >>>> at java.lang.reflect.Method.invoke(Unknown Source) >>>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source) >>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source) >>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) >>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source) >>>> at java.io.ObjectOutputStream.writeObject(Unknown Source) >>>> at java.util.LinkedList.writeObject(Unknown Source) >>>> at sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source) >>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) >>>> at java.lang.reflect.Method.invoke(Unknown Source) >>>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source) >>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source) >>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) >>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source) >>>> at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source) >>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source) >>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) >>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source) >>>> at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source) >>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source) >>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) >>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source) >>>> at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source) >>>> at java.io.ObjectOutputStream.defaultWriteObject(Unknown Source) >>>> at org.apache.wicket.Component.writeObject(Component.java:4660) >>>> at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source) >>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) >>>> at java.lang.reflect.Method.invoke(Unknown Source) >>>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source) >>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source) >>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) >>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source) >>>> at java.io.ObjectOutputStream.writeArray(Unknown Source) &
Re: StackOverflowError
1.4.12, but the problem has been around since a few versions back. D/ On Nov 16, 2010, at 12:43 AM, Martijn Dashorst wrote: > Are you using 1.4.13? > > Martijn > > On Tue, Nov 16, 2010 at 5:54 AM, Douglas Ferguson > wrote: >> Some time ago I posted to the list regarding a stack overflow error that I >> was receiving and the advice was to make sure that I didn't have a page >> storing a reference to another page. >> We did track this down and have just had to ignore it in the production >> logs. Now we've made it a priority to track this down. >> >> Anyway, we've recently tracked this down to "AutomaticMultiWindowSupport" >> feature. We are able to recreate the bug by pasting a url into a new browser >> window and thus generating a new pagemap. On a certain page the memory >> consumption doubles as you generate new pagemaps (see the chart below). The >> profile is indicating that the memory is being taken up by a hashmap, but >> that's as far as we've been able to trace it so far. >> >>> PageMap #SizeGrowth >>> 133895234481.93 >>> 122020590961.93 >>> 111048040961.93 >>> 10543522801.93 >>> 9281827601.93 >>> 8145949761.93 >>> 775493361.94 >>> 639007041.94 >>> 520134802 >>> 410069602 >>> 35036962 >>> 22520721.86 >>> 1135704 >> >> >> Any thoughts or tips on trying to get to the bottom of this one? >> >> Here's the stack trace >> >>> at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source) >>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) >>> at java.lang.reflect.Method.invoke(Unknown Source) >>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source) >>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source) >>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) >>> at java.io.ObjectOutputStream.writeObject0(Unknown Source) >>> at java.io.ObjectOutputStream.writeObject(Unknown Source) >>> at java.util.LinkedList.writeObject(Unknown Source) >>> at sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source) >>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) >>> at java.lang.reflect.Method.invoke(Unknown Source) >>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source) >>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source) >>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) >>> at java.io.ObjectOutputStream.writeObject0(Unknown Source) >>> at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source) >>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source) >>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) >>> at java.io.ObjectOutputStream.writeObject0(Unknown Source) >>> at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source) >>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source) >>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) >>> at java.io.ObjectOutputStream.writeObject0(Unknown Source) >>> at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source) >>> at java.io.ObjectOutputStream.defaultWriteObject(Unknown Source) >>> at org.apache.wicket.Component.writeObject(Component.java:4660) >>> at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source) >>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) >>> at java.lang.reflect.Method.invoke(Unknown Source) >>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source) >>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source) >>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) >>> at java.io.ObjectOutputStream.writeObject0(Unknown Source) >>> at java.io.ObjectOutputStream.writeArray(Unknown Source) >>> at java.io.ObjectOutputStream.writeObject0(Unknown Source) >>> at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source) >>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source) >>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) >>> at java.io.ObjectOutputStream.writeObject0(Unknown S
