Fast2WicketSerializer StackOverflowError
Hi,
I get a strange StackOverflowError with Fast2WicketSerializer
Env : Wicket version 9.0.0.M2 and previous with Fast2WicketSerializer
quickstart : https://issues.apache.org/jira/browse/WICKET-6679
When Session.get() is called in a non serialized object
and session.getMetaData(MetaDataKey) is in a serialized object
there is a StackOverflowError
Will produce a StackOverflowError
@Override
protected void onInitialize() {
super.onInitialize();
Session session = Session.get();
add(new AjaxLink("link") {
@Override
public void onClick(AjaxRequestTarget target) {
Boolean showgrid = session.getMetaData(KeyGrid);
//
}
});
}
Will not produce StackOverflowError
@Override
protected void onInitialize() {
super.onInitialize();
add(new AjaxLink("link") {
@Override
public void onClick(AjaxRequestTarget target) {
Boolean showgrid = Session.get().getMetaData(KeyGrid);
//
}
});
}
Exception in thread "Wicket-AsyncPageStore-PageSavingThread"
java.lang.StackOverflowError
at
org.nustaq.serialization.FSTObjectOutput.writeObjectCompatibleRecursive(FSTObjectOutput.java:568)
at
org.nustaq.serialization.FSTObjectOutput.writeObjectCompatible(FSTObjectOutput.java:554)
at
org.nustaq.serialization.FSTObjectOutput.writeObjectWithContext(FSTObjectOutput.java:450)
at
org.nustaq.serialization.FSTObjectOutput.writeObjectWithContext(FSTObjectOutput.java:369)
at
org.nustaq.serialization.FSTObjectOutput.writeObjectFields(FSTObjectOutput.java:664)
at
org.nustaq.serialization.FSTObjectOutput.defaultWriteObject(FSTObjectOutput.java:546)
at
org.nustaq.serialization.FSTObjectOutput.writeObjectWithContext(FSTObjectOutput.java:458)
at
org.nustaq.serialization.FSTObjectOutput.writeObjectWithContext(FSTObjectOutput.java:369)
at
org.nustaq.serialization.FSTObjectOutput.writeObjectFields(FSTObjectOutput.java:664)
at
org.nustaq.serialization.FSTObjectOutput.defaultWriteObject(FSTObjectOutput.java:546)
at
org.nustaq.serialization.FSTObjectOutput.writeObjectWithContext(FSTObjectOutput.java:458)
at
org.nustaq.serialization.FSTObjectOutput.writeObjectWithContext(FSTObjectOutput.java:369)
at
org.nustaq.serialization.FSTObjectOutput.writeObjectFields(FSTObjectOutput.java:664)
at
org.nustaq.serialization.FSTObjectOutput.defaultWriteObject(FSTObjectOutput.java:546)
at
org.nustaq.serialization.FSTObjectOutput.writeObjectWithContext(FSTObjectOutput.java:458)
at
org.nustaq.serialization.FSTObjectOutput.writeObjectInternal(FSTObjectOutput.java:327)
at
org.nustaq.serialization.serializers.FSTArrayListSerializer.writeObject(FSTArrayListSerializer.java:49)
at
org.nustaq.serialization.FSTObjectOutput.writeObjectWithContext(FSTObjectOutput.java:476)
at
org.nustaq.serialization.FSTObjectOutput.writeObjectWithContext(FSTObjectOutput.java:369)
at
org.nustaq.serialization.FSTObjectOutput.writeObjectFields(FSTObjectOutput.java:664)
at
org.nustaq.serialization.FSTObjectOutput.defaultWriteObject(FSTObjectOutput.java:546)
at
org.nustaq.serialization.FSTObjectOutput.writeObjectWithContext(FSTObjectOutput.java:458)
at
org.nustaq.serialization.FSTObjectOutput.writeObjectInternal(FSTObjectOutput.java:327)
at
org.nustaq.serialization.FSTObjectOutput.writeObject(FSTObjectOutput.java:294)
at
org.nustaq.serialization.FSTObjectOutput.writeObject(FSTObjectOutput.java:204)
at
org.wicketstuff.pageserializer.fast2.Fast2WicketSerializer.serialize(Fast2WicketSerializer.java:77)
at
org.apache.wicket.pageStore.InSessionPageStore$SessionData.writeObject(InSessionPageStore.java:317)
Do I miss something with the MetaData ?
François
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket 6.x / FeedbackPanel StackOverflowError
Thank you Tobias,
I followed your advice and it worked, after looking at
https://ci.apache.org/projects/wicket/guide/6.x/guide/componentLifecycle.html
it seems the best way to fix this is e.g.:
@Override
protected void onConfigure() {
if(loginForm.hasError()) {
setVisible(true);
} else {
setVisible(false);
}
}
The lifecycle is a bit off from my wicket 1.3/ 1.4 memories it seems :)
Best,
Korbinian
- Ursprüngliche Mail -
> Von: "Tobias Soloschenko"
> An: users@wicket.apache.org
> Gesendet: Samstag, 14. Mai 2016 14:07:51
> Betreff: Re: wicket 6.x / FeedbackPanel StackOverflowError
> Hi,
>
> try to set the visibility in onConfigure and store it as field in that local
> anonymous class - (return myVisibilityField;)
>
> kind regards
>
> Tobias
>
>> Am 14.05.2016 um 13:23 schrieb Korbinian Bachl
>> :
>>
>> Hello,
>>
>> I'm currently migrating a wicket / brix application from wicket 1.4 to wicket
>> 6.23; So far most seems well, but there is a thing I'm really stuck at. My
>> code
>> uses FeedbackPanel regularly like this (on many many pages/ tiles):
>>
>> loginForm.add(new FeedbackPanel("feedBack") {
>>private static final long serialVersionUID =
>> -2594094600209896717L;
>>
>>@Override
>>public boolean isVisible() {
>>return loginForm.hasError();
>>}
>>
>>
>>}.setEscapeModelStrings(false));
>>
>> and this worked fine in wicket 1.4; With wicket 6 now if I access a page
>> containing this I get
>>
>> [2016-05-14T13:14:48.163+0200] [Payara 4.1] [WARNING] []
>> [javax.enterprise.web]
>> [tid: _ThreadID=33 _ThreadName=http-listener-2(1)] [timeMillis:
>> 1463224488163]
>> [levelValue: 900] [[
>> StandardWrapperValve[default]: Servlet.service() for servlet default threw
>> exception
>> java.lang.StackOverflowError
>>at org.apache.wicket.Component.isVisibleInHierarchy(Component.java:2132)
>>at org.apache.wicket.Component.isVisibleInHierarchy(Component.java:2132)
>>at org.apache.wicket.Component.isVisibleInHierarchy(Component.java:2132)
>>at org.apache.wicket.Component.isVisibleInHierarchy(Component.java:2132)
>>at org.apache.wicket.markup.html.form.Form$8.component(Form.java:1161)
>>at org.apache.wicket.markup.html.form.Form$8.component(Form.java:1157)
>>at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:144)
>>at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:123)
>>at
>> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:860)
>>at
>> org.apache.wicket.markup.html.form.Form.anyFormComponentError(Form.java:1156)
>>at org.apache.wicket.markup.html.form.Form.hasError(Form.java:667)
>>at xxx.login.LoginExistingPanel$2.isVisible(LoginExistingPanel.java:92)
>>at org.apache.wicket.Component.determineVisibility(Component.java:4347)
>>at org.apache.wicket.Component.isVisibleInHierarchy(Component.java:2138)
>>at org.apache.wicket.markup.html.form.Form$8.component(Form.java:1161)
>>at org.apache.wicket.markup.html.form.Form$8.component(Form.java:1157)
>>at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:144)
>>at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:123)
>>at
>> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:860)
>>at
>> org.apache.wicket.markup.html.form.Form.anyFormComponentError(Form.java:1156)
>>at org.apache.wicket.markup.html.form.Form.hasError(Form.java:667)
>>at .LoginExistingPanel$2.isVisible(LoginExistingPanel.java:92)
>> repeating the error dozens of times;
>>
>> Did anything change here that makes the good old isVisible() not usable
>> anymore?
>>
>>
>> Best,
>>
>> Korbinian
>>
>>
>>
>>
>>
>>
>> -
>> 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 6.x / FeedbackPanel StackOverflowError
Hi,
try to set the visibility in onConfigure and store it as field in that local
anonymous class - (return myVisibilityField;)
kind regards
Tobias
> Am 14.05.2016 um 13:23 schrieb Korbinian Bachl
> :
>
> Hello,
>
> I'm currently migrating a wicket / brix application from wicket 1.4 to wicket
> 6.23; So far most seems well, but there is a thing I'm really stuck at. My
> code uses FeedbackPanel regularly like this (on many many pages/ tiles):
>
> loginForm.add(new FeedbackPanel("feedBack") {
>private static final long serialVersionUID = -2594094600209896717L;
>
>@Override
>public boolean isVisible() {
>return loginForm.hasError();
>}
>
>
>}.setEscapeModelStrings(false));
>
> and this worked fine in wicket 1.4; With wicket 6 now if I access a page
> containing this I get
>
> [2016-05-14T13:14:48.163+0200] [Payara 4.1] [WARNING] []
> [javax.enterprise.web] [tid: _ThreadID=33 _ThreadName=http-listener-2(1)]
> [timeMillis: 1463224488163] [levelValue: 900] [[
> StandardWrapperValve[default]: Servlet.service() for servlet default threw
> exception
> java.lang.StackOverflowError
>at org.apache.wicket.Component.isVisibleInHierarchy(Component.java:2132)
>at org.apache.wicket.Component.isVisibleInHierarchy(Component.java:2132)
>at org.apache.wicket.Component.isVisibleInHierarchy(Component.java:2132)
>at org.apache.wicket.Component.isVisibleInHierarchy(Component.java:2132)
>at org.apache.wicket.markup.html.form.Form$8.component(Form.java:1161)
>at org.apache.wicket.markup.html.form.Form$8.component(Form.java:1157)
>at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:144)
>at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:123)
>at
> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:860)
>at
> org.apache.wicket.markup.html.form.Form.anyFormComponentError(Form.java:1156)
>at org.apache.wicket.markup.html.form.Form.hasError(Form.java:667)
>at xxx.login.LoginExistingPanel$2.isVisible(LoginExistingPanel.java:92)
>at org.apache.wicket.Component.determineVisibility(Component.java:4347)
>at org.apache.wicket.Component.isVisibleInHierarchy(Component.java:2138)
>at org.apache.wicket.markup.html.form.Form$8.component(Form.java:1161)
>at org.apache.wicket.markup.html.form.Form$8.component(Form.java:1157)
>at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:144)
>at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:123)
>at
> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:860)
>at
> org.apache.wicket.markup.html.form.Form.anyFormComponentError(Form.java:1156)
>at org.apache.wicket.markup.html.form.Form.hasError(Form.java:667)
>at .LoginExistingPanel$2.isVisible(LoginExistingPanel.java:92)
> repeating the error dozens of times;
>
> Did anything change here that makes the good old isVisible() not usable
> anymore?
>
>
> Best,
>
> Korbinian
>
>
>
>
>
>
> -
> 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 6.x / FeedbackPanel StackOverflowError
Hello,
I'm currently migrating a wicket / brix application from wicket 1.4 to wicket
6.23; So far most seems well, but there is a thing I'm really stuck at. My code
uses FeedbackPanel regularly like this (on many many pages/ tiles):
loginForm.add(new FeedbackPanel("feedBack") {
private static final long serialVersionUID = -2594094600209896717L;
@Override
public boolean isVisible() {
return loginForm.hasError();
}
}.setEscapeModelStrings(false));
and this worked fine in wicket 1.4; With wicket 6 now if I access a page
containing this I get
[2016-05-14T13:14:48.163+0200] [Payara 4.1] [WARNING] [] [javax.enterprise.web]
[tid: _ThreadID=33 _ThreadName=http-listener-2(1)] [timeMillis: 1463224488163]
[levelValue: 900] [[
StandardWrapperValve[default]: Servlet.service() for servlet default threw
exception
java.lang.StackOverflowError
at org.apache.wicket.Component.isVisibleInHierarchy(Component.java:2132)
at org.apache.wicket.Component.isVisibleInHierarchy(Component.java:2132)
at org.apache.wicket.Component.isVisibleInHierarchy(Component.java:2132)
at org.apache.wicket.Component.isVisibleInHierarchy(Component.java:2132)
at org.apache.wicket.markup.html.form.Form$8.component(Form.java:1161)
at org.apache.wicket.markup.html.form.Form$8.component(Form.java:1157)
at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:144)
at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:123)
at
org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:860)
at
org.apache.wicket.markup.html.form.Form.anyFormComponentError(Form.java:1156)
at org.apache.wicket.markup.html.form.Form.hasError(Form.java:667)
at xxx.login.LoginExistingPanel$2.isVisible(LoginExistingPanel.java:92)
at org.apache.wicket.Component.determineVisibility(Component.java:4347)
at org.apache.wicket.Component.isVisibleInHierarchy(Component.java:2138)
at org.apache.wicket.markup.html.form.Form$8.component(Form.java:1161)
at org.apache.wicket.markup.html.form.Form$8.component(Form.java:1157)
at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:144)
at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:123)
at
org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:860)
at
org.apache.wicket.markup.html.form.Form.anyFormComponentError(Form.java:1156)
at org.apache.wicket.markup.html.form.Form.hasError(Form.java:667)
at .LoginExistingPanel$2.isVisible(LoginExistingPanel.java:92)
repeating the error dozens of times;
Did anything change here that makes the good old isVisible() not usable anymore?
Best,
Korbinian
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: JsonRequestLogger --> JsonMappingException --> StackOverflowError Infinite recursion
sounds good
François
Le 18 févr. 2016 à 10:43, Martin Grigorov a écrit :
> I'd suggest to fix it by:
> 1) in Wicket 7.x upgrade Jackson to 2.6.latest and add the second method
> 2) in Wicket 8.x upgrade to 2.7.latest and update the argument.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Thu, Feb 18, 2016 at 10:39 AM, Francois Meillet <
> francois.meil...@gmail.com> wrote:
>
>>
>> Before the 7.0.0 release, wicket-extension used
>>
>>org.codehaus.jackson
>>jackson-mapper-asl
>>1.8.5
>>
>> So no change can be done.
>>
>>
>> 7.0.0, 7.1.0 and 7.2.0 use
>>
>>com.fasterxml.jackson.core
>>jackson-databind
>>2.4.1.3
>>
>>
>>
>> JacksonAnnotationIntrospector
>>
>>/**
>> * @deprecated (since 2.3) Use {@link #findFilterId(Annotated)} instead
>> */
>>@Deprecated
>>@Override
>>public Object findFilterId(AnnotatedClass ac) {
>>return _findFilterId(ac);
>>}
>>
>>@Override
>>public Object findFilterId(Annotated a) {
>>return _findFilterId(a);
>>}
>>
>> so the findFilterId(Annotated a) can be used in the JsonRequestLogger #
>> FilteredIntrospector
>>
>>
>> findFilterId(AnnotatedClass ac) has been removed from the 2.7 release.
>>
>>
>> The sole Wicket' class using Jackson I found is
>> JacksonAnnotationIntrospector,
>> so using Jackson 2.7.1 release can be done.
>> Tested. ok.
>>
>> François
>>
>>
>>
>>
>>
>>
>>
>> Le 18 févr. 2016 à 09:43, Martin Grigorov a écrit :
>>
>>> Good!
>>>
>>> The question now is how to introduce this change without breaking old
>>> applications.
>>> Having both methods looks like a solution but it may break if the
>>> application uses older version of Jackson.
>>> I think it should work.
>>> Can you try it ?
>>>
>>>
>>> Martin Grigorov
>>> Wicket Training and Consulting
>>> https://twitter.com/mtgrigorov
>>>
>>> On Thu, Feb 18, 2016 at 9:35 AM, Francois Meillet <
>>> francois.meil...@gmail.com> wrote:
>>>
>>>> Hi Martin,
>>>>
>>>> Jackson JacksonAnnotationIntrospector # findFilterId() method signature
>>>> has been changed
>>>>
>>>> from findFilterId(AnnotatedClass ac) to findFilterId(Annotated a)
>>>>
>>>>
>>>> in the JsonRequestLogger, changing this
>>>>
>>>> private static final class FilteredIntrospector extends
>>>> JacksonAnnotationIntrospector
>>>> {
>>>> @Override
>>>> public Object findFilterId(AnnotatedClass ac)
>>>> {
>>>> return "default";
>>>> }
>>>> }
>>>>
>>>>
>>>> to that resolved the problem
>>>>
>>>> private static final class FilteredIntrospector extends
>>>> JacksonAnnotationIntrospector
>>>> {
>>>> @Override
>>>> public Object findFilterId(Annotated a)
>>>> {
>>>> return "default";
>>>> }
>>>> }
>>>>
>>>>
>>>> François
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Le 18 févr. 2016 à 08:24, Martin Grigorov a
>> écrit :
>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>> On Wed, Feb 17, 2016 at 12:10 PM, Francois Meillet <
>>>>> francois.meil...@gmail.com> wrote:
>>>>>
>>>>>> Dear Team,
>>>>>>
>>>>>> The JsonRequestLogger is not working correctly:
>>>>>>
>>>>>> JsonRequestLogger --> JsonMappingException --> StackOverflowError
>>>> Infinite
>>>>>> recursion
>>>>>>
>>>>>> Wicket : 7.2.0
>>>>>> Jackson : 2.7.1
>>>>>>
>>>>>> JsonRequestLogger throw a JsonMappingException when
Re: JsonRequestLogger --> JsonMappingException --> StackOverflowError Infinite recursion
I'd suggest to fix it by:
1) in Wicket 7.x upgrade Jackson to 2.6.latest and add the second method
2) in Wicket 8.x upgrade to 2.7.latest and update the argument.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Thu, Feb 18, 2016 at 10:39 AM, Francois Meillet <
francois.meil...@gmail.com> wrote:
>
> Before the 7.0.0 release, wicket-extension used
>
> org.codehaus.jackson
> jackson-mapper-asl
> 1.8.5
>
> So no change can be done.
>
>
> 7.0.0, 7.1.0 and 7.2.0 use
>
> com.fasterxml.jackson.core
> jackson-databind
> 2.4.1.3
>
>
>
> JacksonAnnotationIntrospector
>
> /**
> * @deprecated (since 2.3) Use {@link #findFilterId(Annotated)} instead
> */
> @Deprecated
> @Override
> public Object findFilterId(AnnotatedClass ac) {
> return _findFilterId(ac);
> }
>
> @Override
> public Object findFilterId(Annotated a) {
> return _findFilterId(a);
> }
>
> so the findFilterId(Annotated a) can be used in the JsonRequestLogger #
> FilteredIntrospector
>
>
> findFilterId(AnnotatedClass ac) has been removed from the 2.7 release.
>
>
> The sole Wicket' class using Jackson I found is
> JacksonAnnotationIntrospector,
> so using Jackson 2.7.1 release can be done.
> Tested. ok.
>
> François
>
>
>
>
>
>
>
> Le 18 févr. 2016 à 09:43, Martin Grigorov a écrit :
>
> > Good!
> >
> > The question now is how to introduce this change without breaking old
> > applications.
> > Having both methods looks like a solution but it may break if the
> > application uses older version of Jackson.
> > I think it should work.
> > Can you try it ?
> >
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >
> > On Thu, Feb 18, 2016 at 9:35 AM, Francois Meillet <
> > francois.meil...@gmail.com> wrote:
> >
> >> Hi Martin,
> >>
> >> Jackson JacksonAnnotationIntrospector # findFilterId() method signature
> >> has been changed
> >>
> >> from findFilterId(AnnotatedClass ac) to findFilterId(Annotated a)
> >>
> >>
> >>in the JsonRequestLogger, changing this
> >>
> >>private static final class FilteredIntrospector extends
> >> JacksonAnnotationIntrospector
> >>{
> >>@Override
> >>public Object findFilterId(AnnotatedClass ac)
> >>{
> >>return "default";
> >>}
> >>}
> >>
> >>
> >>to that resolved the problem
> >>
> >>private static final class FilteredIntrospector extends
> >> JacksonAnnotationIntrospector
> >>{
> >>@Override
> >>public Object findFilterId(Annotated a)
> >>{
> >>return "default";
> >>}
> >>}
> >>
> >>
> >> François
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> Le 18 févr. 2016 à 08:24, Martin Grigorov a
> écrit :
> >>
> >>> Hi,
> >>>
> >>>
> >>> On Wed, Feb 17, 2016 at 12:10 PM, Francois Meillet <
> >>> francois.meil...@gmail.com> wrote:
> >>>
> >>>> Dear Team,
> >>>>
> >>>> The JsonRequestLogger is not working correctly:
> >>>>
> >>>> JsonRequestLogger --> JsonMappingException --> StackOverflowError
> >> Infinite
> >>>> recursion
> >>>>
> >>>> Wicket : 7.2.0
> >>>> Jackson : 2.7.1
> >>>>
> >>>> JsonRequestLogger throw a JsonMappingException when executing
> >>>> getMapper().writeValueAsString(new RequestSessionTuple(rd, sd));
> >>>>
> >>>> java.lang.RuntimeException:
> >>>> com.fasterxml.jackson.databind.JsonMappingException:
> >>>> Infinite recursion (StackOverflowError)
> >>>> (through reference chain:
> >>>>
> >>
> org.apache.wicket.PageReference["page"]->com.mycompany.SimplePage["pageReference"]->org.apache.wicket.PageReference["page"]->com.mycompany.SimplePage["pageReference"]->org.
Re: JsonRequestLogger --> JsonMappingException --> StackOverflowError Infinite recursion
Before the 7.0.0 release, wicket-extension used
org.codehaus.jackson
jackson-mapper-asl
1.8.5
So no change can be done.
7.0.0, 7.1.0 and 7.2.0 use
com.fasterxml.jackson.core
jackson-databind
2.4.1.3
JacksonAnnotationIntrospector
/**
* @deprecated (since 2.3) Use {@link #findFilterId(Annotated)} instead
*/
@Deprecated
@Override
public Object findFilterId(AnnotatedClass ac) {
return _findFilterId(ac);
}
@Override
public Object findFilterId(Annotated a) {
return _findFilterId(a);
}
so the findFilterId(Annotated a) can be used in the JsonRequestLogger #
FilteredIntrospector
findFilterId(AnnotatedClass ac) has been removed from the 2.7 release.
The sole Wicket' class using Jackson I found is JacksonAnnotationIntrospector,
so using Jackson 2.7.1 release can be done.
Tested. ok.
François
Le 18 févr. 2016 à 09:43, Martin Grigorov a écrit :
> Good!
>
> The question now is how to introduce this change without breaking old
> applications.
> Having both methods looks like a solution but it may break if the
> application uses older version of Jackson.
> I think it should work.
> Can you try it ?
>
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Thu, Feb 18, 2016 at 9:35 AM, Francois Meillet <
> francois.meil...@gmail.com> wrote:
>
>> Hi Martin,
>>
>> Jackson JacksonAnnotationIntrospector # findFilterId() method signature
>> has been changed
>>
>> from findFilterId(AnnotatedClass ac) to findFilterId(Annotated a)
>>
>>
>>in the JsonRequestLogger, changing this
>>
>>private static final class FilteredIntrospector extends
>> JacksonAnnotationIntrospector
>>{
>>@Override
>>public Object findFilterId(AnnotatedClass ac)
>>{
>>return "default";
>>}
>>}
>>
>>
>>to that resolved the problem
>>
>>private static final class FilteredIntrospector extends
>> JacksonAnnotationIntrospector
>>{
>>@Override
>>public Object findFilterId(Annotated a)
>>{
>>return "default";
>>}
>>}
>>
>>
>> François
>>
>>
>>
>>
>>
>>
>>
>>
>> Le 18 févr. 2016 à 08:24, Martin Grigorov a écrit :
>>
>>> Hi,
>>>
>>>
>>> On Wed, Feb 17, 2016 at 12:10 PM, Francois Meillet <
>>> francois.meil...@gmail.com> wrote:
>>>
>>>> Dear Team,
>>>>
>>>> The JsonRequestLogger is not working correctly:
>>>>
>>>> JsonRequestLogger --> JsonMappingException --> StackOverflowError
>> Infinite
>>>> recursion
>>>>
>>>> Wicket : 7.2.0
>>>> Jackson : 2.7.1
>>>>
>>>> JsonRequestLogger throw a JsonMappingException when executing
>>>> getMapper().writeValueAsString(new RequestSessionTuple(rd, sd));
>>>>
>>>> java.lang.RuntimeException:
>>>> com.fasterxml.jackson.databind.JsonMappingException:
>>>> Infinite recursion (StackOverflowError)
>>>> (through reference chain:
>>>>
>> org.apache.wicket.PageReference["page"]->com.mycompany.SimplePage["pageReference"]->org.apache.wicket.PageReference["page"]->com.mycompany.SimplePage["pageReference"]->org.apache.wicket.PageReference["page"]->
>>>>
>>>>
>>>> at
>>>>
>> org.apache.wicket.extensions.requestlogger.JsonRequestLogger.getLogString(JsonRequestLogger.java:141)
>>>> ~[wicket-extensions-7.2.0.jar:7.2.0]
>>>> at
>>>>
>> org.apache.wicket.extensions.requestlogger.JsonRequestLogger.log(JsonRequestLogger.java:125)
>>>> ~[wicket-extensions-7.2.0.jar:7.2.0]
>>>> at
>>>>
>> org.apache.wicket.protocol.http.AbstractRequestLogger.performLogging(AbstractRequestLogger.java:325)
>>>> ~[wicket-core-7.2.0.jar:7.2.0]
>>>> at
>>>>
>> org.apache.wicket.request.cycle.RequestCycle.onInternalDetach(RequestCycle.java:620)
>>>> ~[wicket-core-7.2.0.jar:7.2.0]
>>>> at
>>>>
>> org.apache.wicke
Re: JsonRequestLogger --> JsonMappingException --> StackOverflowError Infinite recursion
Good!
The question now is how to introduce this change without breaking old
applications.
Having both methods looks like a solution but it may break if the
application uses older version of Jackson.
I think it should work.
Can you try it ?
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Thu, Feb 18, 2016 at 9:35 AM, Francois Meillet <
francois.meil...@gmail.com> wrote:
> Hi Martin,
>
> Jackson JacksonAnnotationIntrospector # findFilterId() method signature
> has been changed
>
> from findFilterId(AnnotatedClass ac) to findFilterId(Annotated a)
>
>
> in the JsonRequestLogger, changing this
>
> private static final class FilteredIntrospector extends
> JacksonAnnotationIntrospector
> {
> @Override
> public Object findFilterId(AnnotatedClass ac)
> {
> return "default";
> }
> }
>
>
> to that resolved the problem
>
> private static final class FilteredIntrospector extends
> JacksonAnnotationIntrospector
> {
> @Override
> public Object findFilterId(Annotated a)
> {
> return "default";
> }
> }
>
>
> François
>
>
>
>
>
>
>
>
> Le 18 févr. 2016 à 08:24, Martin Grigorov a écrit :
>
> > Hi,
> >
> >
> > On Wed, Feb 17, 2016 at 12:10 PM, Francois Meillet <
> > francois.meil...@gmail.com> wrote:
> >
> >> Dear Team,
> >>
> >> The JsonRequestLogger is not working correctly:
> >>
> >> JsonRequestLogger --> JsonMappingException --> StackOverflowError
> Infinite
> >> recursion
> >>
> >> Wicket : 7.2.0
> >> Jackson : 2.7.1
> >>
> >> JsonRequestLogger throw a JsonMappingException when executing
> >> getMapper().writeValueAsString(new RequestSessionTuple(rd, sd));
> >>
> >> java.lang.RuntimeException:
> >> com.fasterxml.jackson.databind.JsonMappingException:
> >> Infinite recursion (StackOverflowError)
> >> (through reference chain:
> >>
> org.apache.wicket.PageReference["page"]->com.mycompany.SimplePage["pageReference"]->org.apache.wicket.PageReference["page"]->com.mycompany.SimplePage["pageReference"]->org.apache.wicket.PageReference["page"]->
> >>
> >>
> >> at
> >>
> org.apache.wicket.extensions.requestlogger.JsonRequestLogger.getLogString(JsonRequestLogger.java:141)
> >> ~[wicket-extensions-7.2.0.jar:7.2.0]
> >> at
> >>
> org.apache.wicket.extensions.requestlogger.JsonRequestLogger.log(JsonRequestLogger.java:125)
> >> ~[wicket-extensions-7.2.0.jar:7.2.0]
> >> at
> >>
> org.apache.wicket.protocol.http.AbstractRequestLogger.performLogging(AbstractRequestLogger.java:325)
> >> ~[wicket-core-7.2.0.jar:7.2.0]
> >> at
> >>
> org.apache.wicket.request.cycle.RequestCycle.onInternalDetach(RequestCycle.java:620)
> >> ~[wicket-core-7.2.0.jar:7.2.0]
> >> at
> >>
> org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:600)
> >> ~[wicket-core-7.2.0.jar:7.2.0]
> >> at
> >>
> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:297)
> >> ~[wicket-core-7.2.0.jar:7.2.0]
> >> at
> >>
> org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:261)
> >> ~[wicket-core-7.2.0.jar:7.2.0]
> >> at
> >>
> com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:694)
> >> ~[jackson-databind-2.7.1.jar:2.7.1]
> >> at
> >>
> com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:157)
> >> ~[jackson-databind-2.7.1.jar:2.7.1]
> >> at
> >>
> com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:672)
> >> ~[jackson-databind-2.7.1.jar:2.7.1]
> >> at
> >>
> com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:678)
> >> ~[jackson-databind-2.7.1.jar:2.7.1]
> >> at
> >>
> com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:157)
> >> ~[jackson-databind-2.7.1.jar:2.7.1]
> >> at
> >>
> com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:672)
> >> ~[jackson-data
Re: JsonRequestLogger --> JsonMappingException --> StackOverflowError Infinite recursion
Hi Martin,
Jackson JacksonAnnotationIntrospector # findFilterId() method signature has
been changed
from findFilterId(AnnotatedClass ac) to findFilterId(Annotated a)
in the JsonRequestLogger, changing this
private static final class FilteredIntrospector extends
JacksonAnnotationIntrospector
{
@Override
public Object findFilterId(AnnotatedClass ac)
{
return "default";
}
}
to that resolved the problem
private static final class FilteredIntrospector extends
JacksonAnnotationIntrospector
{
@Override
public Object findFilterId(Annotated a)
{
return "default";
}
}
François
Le 18 févr. 2016 à 08:24, Martin Grigorov a écrit :
> Hi,
>
>
> On Wed, Feb 17, 2016 at 12:10 PM, Francois Meillet <
> francois.meil...@gmail.com> wrote:
>
>> Dear Team,
>>
>> The JsonRequestLogger is not working correctly:
>>
>> JsonRequestLogger --> JsonMappingException --> StackOverflowError Infinite
>> recursion
>>
>> Wicket : 7.2.0
>> Jackson : 2.7.1
>>
>> JsonRequestLogger throw a JsonMappingException when executing
>> getMapper().writeValueAsString(new RequestSessionTuple(rd, sd));
>>
>> java.lang.RuntimeException:
>> com.fasterxml.jackson.databind.JsonMappingException:
>> Infinite recursion (StackOverflowError)
>> (through reference chain:
>> org.apache.wicket.PageReference["page"]->com.mycompany.SimplePage["pageReference"]->org.apache.wicket.PageReference["page"]->com.mycompany.SimplePage["pageReference"]->org.apache.wicket.PageReference["page"]->
>>
>>
>> at
>> org.apache.wicket.extensions.requestlogger.JsonRequestLogger.getLogString(JsonRequestLogger.java:141)
>> ~[wicket-extensions-7.2.0.jar:7.2.0]
>> at
>> org.apache.wicket.extensions.requestlogger.JsonRequestLogger.log(JsonRequestLogger.java:125)
>> ~[wicket-extensions-7.2.0.jar:7.2.0]
>> at
>> org.apache.wicket.protocol.http.AbstractRequestLogger.performLogging(AbstractRequestLogger.java:325)
>> ~[wicket-core-7.2.0.jar:7.2.0]
>> at
>> org.apache.wicket.request.cycle.RequestCycle.onInternalDetach(RequestCycle.java:620)
>> ~[wicket-core-7.2.0.jar:7.2.0]
>> at
>> org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:600)
>> ~[wicket-core-7.2.0.jar:7.2.0]
>> at
>> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:297)
>> ~[wicket-core-7.2.0.jar:7.2.0]
>> at
>> org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:261)
>> ~[wicket-core-7.2.0.jar:7.2.0]
>> at
>> com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:694)
>> ~[jackson-databind-2.7.1.jar:2.7.1]
>> at
>> com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:157)
>> ~[jackson-databind-2.7.1.jar:2.7.1]
>> at
>> com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:672)
>> ~[jackson-databind-2.7.1.jar:2.7.1]
>> at
>> com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:678)
>> ~[jackson-databind-2.7.1.jar:2.7.1]
>> at
>> com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:157)
>> ~[jackson-databind-2.7.1.jar:2.7.1]
>> at
>> com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:672)
>> ~[jackson-databind-2.7.1.jar:2.7.1]
>> at
>> com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:678)
>> ~[jackson-databind-2.7.1.jar:2.7.1]
>> at
>> com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:157)
>> ~[jackson-databind-2.7.1.jar:2.7.1]
>> at
>> com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:672)
>> ~[jackson-databind-2.7.1.jar:2.7.1]
>>
>>
>> https://issues.apache.org/jira/browse/WICKET-6097
>>
>
> I'll debug it when I have some time.
>
>
>>
>>
>> BTW, is it worth to mainten this logger ?
>>
>
> AFAIK Martijn and Emond use it in their application.
> But if it fails always with this then maybe they don't use it anymore. Or
> they use it with an older version of Jackson. I've had some problems with
> Jackson backward compatibility lately.
>
>
>>
>>
>> François
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
Re: JsonRequestLogger --> JsonMappingException --> StackOverflowError Infinite recursion
Hi, On Wed, Feb 17, 2016 at 12:10 PM, Francois Meillet < francois.meil...@gmail.com> wrote: > Dear Team, > > The JsonRequestLogger is not working correctly: > > JsonRequestLogger --> JsonMappingException --> StackOverflowError Infinite > recursion > > Wicket : 7.2.0 > Jackson : 2.7.1 > > JsonRequestLogger throw a JsonMappingException when executing > getMapper().writeValueAsString(new RequestSessionTuple(rd, sd)); > > java.lang.RuntimeException: > com.fasterxml.jackson.databind.JsonMappingException: > Infinite recursion (StackOverflowError) > (through reference chain: > org.apache.wicket.PageReference["page"]->com.mycompany.SimplePage["pageReference"]->org.apache.wicket.PageReference["page"]->com.mycompany.SimplePage["pageReference"]->org.apache.wicket.PageReference["page"]-> > > > at > org.apache.wicket.extensions.requestlogger.JsonRequestLogger.getLogString(JsonRequestLogger.java:141) > ~[wicket-extensions-7.2.0.jar:7.2.0] > at > org.apache.wicket.extensions.requestlogger.JsonRequestLogger.log(JsonRequestLogger.java:125) > ~[wicket-extensions-7.2.0.jar:7.2.0] > at > org.apache.wicket.protocol.http.AbstractRequestLogger.performLogging(AbstractRequestLogger.java:325) > ~[wicket-core-7.2.0.jar:7.2.0] > at > org.apache.wicket.request.cycle.RequestCycle.onInternalDetach(RequestCycle.java:620) > ~[wicket-core-7.2.0.jar:7.2.0] > at > org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:600) > ~[wicket-core-7.2.0.jar:7.2.0] > at > org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:297) > ~[wicket-core-7.2.0.jar:7.2.0] > at > org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:261) > ~[wicket-core-7.2.0.jar:7.2.0] > at > com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:694) > ~[jackson-databind-2.7.1.jar:2.7.1] > at > com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:157) > ~[jackson-databind-2.7.1.jar:2.7.1] > at > com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:672) > ~[jackson-databind-2.7.1.jar:2.7.1] > at > com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:678) > ~[jackson-databind-2.7.1.jar:2.7.1] > at > com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:157) > ~[jackson-databind-2.7.1.jar:2.7.1] > at > com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:672) > ~[jackson-databind-2.7.1.jar:2.7.1] > at > com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:678) > ~[jackson-databind-2.7.1.jar:2.7.1] > at > com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:157) > ~[jackson-databind-2.7.1.jar:2.7.1] > at > com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:672) > ~[jackson-databind-2.7.1.jar:2.7.1] > > > https://issues.apache.org/jira/browse/WICKET-6097 > I'll debug it when I have some time. > > > BTW, is it worth to mainten this logger ? > AFAIK Martijn and Emond use it in their application. But if it fails always with this then maybe they don't use it anymore. Or they use it with an older version of Jackson. I've had some problems with Jackson backward compatibility lately. > > > François > > > > > > > > > > > > >
Re: Wicket StackOverflowError in Serializing or Seserializing Session
thanks a a lot. I found the object that did not implement Serializable. On Mon, Jul 28, 2014 at 1:56 PM, Martin Grigorov-4 [via Apache Wicket] < ml-node+s1842946n4666765...@n4.nabble.com> wrote: > Hi, > > Wicket will use CheckingObjectOutputStream in DEV mode only if the normal > serialization has failed with NotSerializableException before that, to > give > you a better explanation which field in which class is the problem: > > https://github.com/apache/wicket/blob/442932d4e4c5cc27940bc2ef956cb24c1ba54df0/wicket-core/src/main/java/org/apache/wicket/serialize/java/JavaSerializer.java#L262 > > Put a breakpoint inside the catch and see which class causes the > NotSerializableException before the usage of CheckingObjectOutputStream. > > I have no idea why it fails with StackOverflowError. > > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > > On Sun, Jul 27, 2014 at 9:01 PM, hoosssein <[hidden email] > <http://user/SendEmail.jtp?type=node&node=4666765&i=0>> wrote: > > > I'm using Wicket 6.15 and I got following exception in my program > > > > java.lang.StackOverflowError > > at java.lang.Exception.(Exception.java:102) > > at > > > > > java.lang.ReflectiveOperationException.(ReflectiveOperationException.java:89) > > > at > > > > > java.lang.reflect.InvocationTargetException.(InvocationTargetException.java:72) > > > at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source) > > at > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > > at java.lang.reflect.Method.invoke(Method.java:606) > > at > > > > > org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.internalCheck(CheckingObjectOutputStream.java:398) > > > at > > > > > org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.check(CheckingObjectOutputStream.java:361) > > > at > > > > > org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.checkFields(CheckingObjectOutputStream.java:645) > > > at > > > > > org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.internalCheck(CheckingObjectOutputStream.java:569) > > > at > > > > > org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.check(CheckingObjectOutputStream.java:361) > > > at > > > > > org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.checkFields(CheckingObjectOutputStream.java:645) > > > at > > > > > org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.internalCheck(CheckingObjectOutputStream.java:569) > > > at > > > > > org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.check(CheckingObjectOutputStream.java:361) > > > at > > > > > org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.checkFields(CheckingObjectOutputStream.java:645) > > > at > > > > > org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.internalCheck(CheckingObjectOutputStream.java:569) > > > at > > > > > org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.check(CheckingObjectOutputStream.java:361) > > > at > > > > > org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.checkFields(CheckingObjectOutputStream.java:645) > > > at > > > > > org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.internalCheck(CheckingObjectOutputStream.java:569) > > > at > > > > > org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.check(CheckingObjectOutputStream.java:361) > > > ... > > > > I have no idea what can cause such StackOverFlow in wicket-core. > > > > I search for this exception and found that these part of exception are > > belongs to Serialization. so I checked all of my object and all of them > > implements Serializable > > > > an other interesting port of problem is that this exception doesn't > occurs > > at the first time, It occurs after i try to render component 2 or 3 > time. > > > > Any help would be greatly appreciated. > > > > -- > > View this message in context: > > > http://apache-wicket.1842946.n4.nabble.com/Wicket-StackOverflowError-in-Serializing-or-Seserializing-Session-tp4666758.html > > Sent from the Users forum mailing list archive at Nabble.com. > > &g
Re: Wicket StackOverflowError in Serializing or Seserializing Session
Hi, Wicket will use CheckingObjectOutputStream in DEV mode only if the normal serialization has failed with NotSerializableException before that, to give you a better explanation which field in which class is the problem: https://github.com/apache/wicket/blob/442932d4e4c5cc27940bc2ef956cb24c1ba54df0/wicket-core/src/main/java/org/apache/wicket/serialize/java/JavaSerializer.java#L262 Put a breakpoint inside the catch and see which class causes the NotSerializableException before the usage of CheckingObjectOutputStream. I have no idea why it fails with StackOverflowError. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Sun, Jul 27, 2014 at 9:01 PM, hoosssein wrote: > I'm using Wicket 6.15 and I got following exception in my program > > java.lang.StackOverflowError > at java.lang.Exception.(Exception.java:102) > at > > java.lang.ReflectiveOperationException.(ReflectiveOperationException.java:89) > at > > java.lang.reflect.InvocationTargetException.(InvocationTargetException.java:72) > at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source) > at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > > org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.internalCheck(CheckingObjectOutputStream.java:398) > at > > org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.check(CheckingObjectOutputStream.java:361) > at > > org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.checkFields(CheckingObjectOutputStream.java:645) > at > > org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.internalCheck(CheckingObjectOutputStream.java:569) > at > > org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.check(CheckingObjectOutputStream.java:361) > at > > org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.checkFields(CheckingObjectOutputStream.java:645) > at > > org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.internalCheck(CheckingObjectOutputStream.java:569) > at > > org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.check(CheckingObjectOutputStream.java:361) > at > > org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.checkFields(CheckingObjectOutputStream.java:645) > at > > org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.internalCheck(CheckingObjectOutputStream.java:569) > at > > org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.check(CheckingObjectOutputStream.java:361) > at > > org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.checkFields(CheckingObjectOutputStream.java:645) > at > > org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.internalCheck(CheckingObjectOutputStream.java:569) > at > > org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.check(CheckingObjectOutputStream.java:361) > ... > > I have no idea what can cause such StackOverFlow in wicket-core. > > I search for this exception and found that these part of exception are > belongs to Serialization. so I checked all of my object and all of them > implements Serializable > > an other interesting port of problem is that this exception doesn't occurs > at the first time, It occurs after i try to render component 2 or 3 time. > > Any help would be greatly appreciated. > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Wicket-StackOverflowError-in-Serializing-or-Seserializing-Session-tp4666758.html > Sent from the Users forum mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Wicket StackOverflowError in Serializing or Seserializing Session
I'm using Wicket 6.15 and I got following exception in my program java.lang.StackOverflowError at java.lang.Exception.(Exception.java:102) at java.lang.ReflectiveOperationException.(ReflectiveOperationException.java:89) at java.lang.reflect.InvocationTargetException.(InvocationTargetException.java:72) at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.internalCheck(CheckingObjectOutputStream.java:398) at org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.check(CheckingObjectOutputStream.java:361) at org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.checkFields(CheckingObjectOutputStream.java:645) at org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.internalCheck(CheckingObjectOutputStream.java:569) at org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.check(CheckingObjectOutputStream.java:361) at org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.checkFields(CheckingObjectOutputStream.java:645) at org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.internalCheck(CheckingObjectOutputStream.java:569) at org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.check(CheckingObjectOutputStream.java:361) at org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.checkFields(CheckingObjectOutputStream.java:645) at org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.internalCheck(CheckingObjectOutputStream.java:569) at org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.check(CheckingObjectOutputStream.java:361) at org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.checkFields(CheckingObjectOutputStream.java:645) at org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.internalCheck(CheckingObjectOutputStream.java:569) at org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.check(CheckingObjectOutputStream.java:361) ... I have no idea what can cause such StackOverFlow in wicket-core. I search for this exception and found that these part of exception are belongs to Serialization. so I checked all of my object and all of them implements Serializable an other interesting port of problem is that this exception doesn't occurs at the first time, It occurs after i try to render component 2 or 3 time. Any help would be greatly appreciated. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-StackOverflowError-in-Serializing-or-Seserializing-Session-tp4666758.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: StackOverflowError in session creation
OhI made a stupid mistakesorry for that and thanks for solving my problem... -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/StackOverflowError-in-session-creation-tp4516170p4521161.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: StackOverflowError in session creation
ethod.java:601) > at > org.apache.wicket.RequestListenerInterface.invoke(RequestListenerInterface.java:182) > at > org.apache.wicket.request.target.component.BookmarkableListenerInterfaceRequestTarget.processEvents(BookmarkableListenerInterfaceRequestTarget.java:161) > at > org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92) > at > org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1252) > at org.apache.wicket.RequestCycle.step(RequestCycle.java:1331) > at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1438) > at org.apache.wicket.RequestCycle.request(RequestCycle.java:546) > at > org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:486) > > What is the reason behind this errorare too many sessions being > created??? > > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/StackOverflowError-in-session-creation-tp4516170p4516170.html > Sent from the Users forum mailing list archive at Nabble.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
Re: StackOverflowError
I have seen an application (not mine!) fail horribly and costly on the second
example.
The problem with getting an object from the session and passing the reference to
a (Compound)PropertyModel is that the natural assumption, the session object is
updated too, is wrong.
So this is exactly the same problem as keeping a reference to the session
itself, only now restricted to less data.
Regards,
Erik.
Op 22-11-10 20:51, Igor Vaynberg schreef:
no. the example below doesnt hit any pitfalls because it doesnt
reference the session itself. as long as objects retrieved from
session do not contain references back to session he is ok.
however, declaring Session instance as final is not a good idea
because it makes it easy to reference it in anonymous classes.
-igor
On Mon, Nov 22, 2010 at 11:49 AM, Erik van Oosten wrote:
Yes, both are very wrong.
Pitfalls are in earlier messages in this thread.
On 22-11-10 16:36, mzem...@osc.state.ny.us wrote:
By "keep a reference to the session in their class" do you mean something
like this?
Are there any pitfalls to doing this?
final Session session = getSession();
add(new Label("userNameLabel", new Model(session.getUser
().getUserName(;
How about this?
final UserDTO dto = session.getUser();
CompoundPropertyModel cpm = new CompoundPropertyModel(dto);
--
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
Re: StackOverflowError
no. the example below doesnt hit any pitfalls because it doesnt
reference the session itself. as long as objects retrieved from
session do not contain references back to session he is ok.
however, declaring Session instance as final is not a good idea
because it makes it easy to reference it in anonymous classes.
-igor
On Mon, Nov 22, 2010 at 11:49 AM, Erik van Oosten wrote:
> Yes, both are very wrong.
>
> Pitfalls are in earlier messages in this thread.
>
>
> On 22-11-10 16:36, mzem...@osc.state.ny.us wrote:
>>
>> By "keep a reference to the session in their class" do you mean something
>> like this?
>>
>> Are there any pitfalls to doing this?
>>
>> final Session session = getSession();
>> add(new Label("userNameLabel", new Model(session.getUser
>> ().getUserName(;
>>
>> How about this?
>> final UserDTO dto = session.getUser();
>> CompoundPropertyModel cpm = new CompoundPropertyModel(dto);
>>
>
> --
> 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
Yes, both are very wrong.
Pitfalls are in earlier messages in this thread.
On 22-11-10 16:36, mzem...@osc.state.ny.us wrote:
By "keep a reference to the session in their class" do you mean something
like this?
Are there any pitfalls to doing this?
final Session session = getSession();
add(new Label("userNameLabel", new Model(session.getUser
().getUserName(;
How about this?
final UserDTO dto = session.getUser();
CompoundPropertyModel cpm = new CompoundPropertyModel(dto);
--
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
Re: StackOverflowError
By "keep a reference to the session in their class" do you mean something
like this?
Are there any pitfalls to doing this?
final Session session = getSession();
add(new Label("userNameLabel", new Model(session.getUser
().getUserName(;
How about this?
final UserDTO dto = session.getUser();
CompoundPropertyModel cpm = new CompoundPropertyModel(dto);
From: Martijn Dashorst
To: users@wicket.apache.org
Date: 11/20/2010 12:02 PM
Subject:Re: StackOverflowError
Problem is that there's no single super constructor. For Wicket all
really matters is the IModel interface of which many implementations
exist outside wicket as well. And it is of course not only the model
that is dangerous. Folks can easily keep a reference to the session in
their class, or make a local variable final and reference that inside
an anon-inner class.
It is not possible to make this water tight. As you are about the
first company running into this issue, I'd say it is not worth the
effort trying to fix it.
What we might do is add a check in the serializable checker and ensure
no wicket session ends up in the tree.
Martijn
On Sat, Nov 20, 2010 at 2:27 PM, Douglas Ferguson
wrote:
> 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:
>>>>>&
Re: StackOverflowError
Problem is that there's no single super constructor. For Wicket all
really matters is the IModel interface of which many implementations
exist outside wicket as well. And it is of course not only the model
that is dangerous. Folks can easily keep a reference to the session in
their class, or make a local variable final and reference that inside
an anon-inner class.
It is not possible to make this water tight. As you are about the
first company running into this issue, I'd say it is not worth the
effort trying to fix it.
What we might do is add a check in the serializable checker and ensure
no wicket session ends up in the tree.
Martijn
On Sat, Nov 20, 2010 at 2:27 PM, Douglas Ferguson
wrote:
> 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...@wicke
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
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
Re: StackOverflowError
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 Oosten wrote:
>
>> 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
>>
>>
>
>
> --
> Pedro Henrique Oliveira dos Santos
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: StackOverflowError
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 Oosten wrote:
> 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
>
>
--
Pedro Henrique Oliveira dos Santos
Re: StackOverflowError
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 Oostenwrote:
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
Re: StackOverflowError
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.
>>
>> -igor
>>
>> On Tue, Nov 16, 2010 at 9:46 AM, Douglas Ferguson
>> 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...
>>>
>>
>>
>
> --
> Erik van Oosten
> http://www.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
>
>
--
Pedro Henrique Oliveira dos Santos
Re: StackOverflowError
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. -igor On Tue, Nov 16, 2010 at 9:46 AM, Douglas Ferguson 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... -- Erik van Oosten http://www.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
Re: StackOverflowError
2010/11/16 Douglas Ferguson > so I guess it knows not to serialize itself again if it sees it in a model? > close 'this' is the page it gets serialized anyway. and "session.property" gets transformed into a 'getSession().getProperty()" whenever PropertyModel.getObject() is called. mf > > 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
>>>>>>>> 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.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 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 Source) >>>>>>>>> at java.io.ObjectOutputStream.writeObject(Unknown Source) >>>>>>>>> at >>> org.apache.wicket.util.io.IObjectStreamFactory$DefaultObjectStreamFactory$2.writeObjectOverride(IObjectStreamFactory.java:121) >>> >>>>>>>>> at java.io.ObjectOutputStream.writeObject(Unknown Source) >>>>>>>>> at >>> org.apache.wicket.util.lang.Objects.objectToByteArray(Objects.java:1124) >>>>>>>>> at >>> org.apache.wicket.protocol.http.pagestore.AbstractPageStore.serializePage(AbstractPageStore.java:203) >>> >>>>>>>>> at >>> org.apache.wicket.protocol.http.pagestore.DiskPageStore.prepareForSerialization(DiskPageStore.java:1190) >>> >>>>>>>>> at >>> org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.writeObject(SecondLevelCacheSessionStore.java:389) >>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Become a Wicket expert, learn from the best: >>> http://wicketinaction.com <http://wicketinaction.com?by-user=t> >>>>>>> >>>>>>> - >>>>>>> To unsubscribe, e-mail: [hidden >>>>>>> email]<http://user/SendEmail.jtp?type=node&node=3045359&i=2> >>>>>>> For additional commands, e-mail: [hidden >>>>>>> email]<http://user/SendEmail.jtp?type=node&node=3045359&i=3> >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> - >>>> To unsubscribe, e-mail: [hidden >>>> email]<http://user/SendEmail.jtp?type=node&node=3045359&i=4> >>>> For additional commands, e-mail: [hidden >>>> email]<http://user/SendEmail.jtp?type=node&node=3045359&i=5> >>>> >>>> >>> >>> - >>> To unsubscribe, e-mail: [hidden >>> email]<http://user/SendEmail.jtp?type=node&node=3045359&i=6> >>> For additional commands, e-mail: [hidden >>> email]<http://user/SendEmail.jtp?type=node&node=3045359&i=7> >>> >>> >>> >>> -- >>> View message @ >>> http://apache-wicket.1842946.n4.nabble.com/StackOverflowError-tp3044241p3045359.html >>> To start a new topic under Apache Wicket, email >>> ml-node+1842946-398011874-65...@n4.nabble.com >>> To unsubscribe from Apache Wicket, click >>> here<http://apache-wicket.1842946.n4.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_code&node=1842946&code=amNnYXJjaWFtQGdtYWlsLmNvbXwxODQyOTQ2fDEyNTYxMzc3ODY=>. >>> >>> >>> >> >> >> -- >> Sincerely, >> JC (http://www.linkedin.com/in/jcgarciam) >> Work smarter, not harder!. >> >> -- >> View this message in context: >> http://apache-wicket.1842946.n4.nabble.com/StackOverflowError-tp3044241p3045367.html >> Sent from the Users forum mailing list archive at Nabble.com. >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > > > -- > Become a Wicket expert, learn from the best: http://wicketinaction.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
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
eObject0(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.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 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 Source) >>>>>>>>> at java.io.ObjectOutputStream.writeObject(Unknown Source) >>>>>>>>> at >>> org.apache.wicket.util.io.IObjectStreamFactory$DefaultObjectStreamFactory$2.writeObjectOverride(IObjectStreamFactory.java:121) >>> >>>>>>>>> at java.io.ObjectOutputStream.writeObject(Unknown Source) >>>>>>>>> at >>> org.apache.wicket.util.lang.Objects.objectToByteArray(Objects.java:1124) >>>>>>>>> at >>> org.apache.wicket.protocol.http.pagestore.AbstractPageStore.serializePage(AbstractPageStore.java:203) >>> >>>>>>>>> at >>> org.apache.wicket.protocol.http.pagestore.DiskPageStore.prepareForSerialization(DiskPageStore.java:1190) >>> >>>>>>>>> at >>> org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.writeObject(SecondLevelCacheSessionStore.java:389) >>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Become a Wicket expert, learn from the best: >>> http://wicketinaction.com <http://wicketinaction.com?by-user=t> >>>>>>> >>>>>>> - >>>>>>> To unsubscribe, e-mail: [hidden >>>>>>> email]<http://user/SendEmail.jtp?type=node&node=3045359&i=2> >>>>>>> For additional commands, e-mail: [hidden >>>>>>> email]<http://user/SendEmail.jtp?type=node&node=3045359&i=3> >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> - >>>> To unsubscribe, e-mail: [hidden >>>> email]<http://user/SendEmail.jtp?type=node&node=3045359&i=4> >>>> For additional commands, e-mail: [hidden >>>> email]<http://user/SendEmail.jtp?type=node&node=3045359&i=5> >>>> >>>> >>> >>> - >>> To unsubscribe, e-mail: [hidden >>> email]<http://user/SendEmail.jtp?type=node&node=3045359&i=6> >>> For additional commands, e-mail: [hidden >>> email]<http://user/SendEmail.jtp?type=node&node=3045359&i=7> >>> >>> >>> >>> -- >>> View message @ >>> http://apache-wicket.1842946.n4.nabble.com/StackOverflowError-tp3044241p3045359.html >>> To start a new topic under Apache Wicket, email >>> ml-node+1842946-398011874-65...@n4.nabble.com >>> To unsubscribe from Apache Wicket, click >>> here<http://apache-wicket.1842946.n4.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_code&node=1842946&code=amNnYXJjaWFtQGdtYWlsLmNvbXwxODQyOTQ2fDEyNTYxMzc3ODY=>. >>> >>> >>> >> >> >> -- >> Sincerely, >> JC (http://www.linkedin.com/in/jcgarciam) >> Work smarter, not harder!. >> >> -- >> View this message in context: >> http://apache-wicket.1842946.n4.nabble.com/StackOverflowError-tp3044241p3045367.html >> Sent from the Users forum mailing list archive at Nabble.com. >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > > > -- > Become a Wicket expert, learn from the best: http://wicketinaction.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
urce) >> >> >>>>>> 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 Source) >> >>>>>> at java.io.ObjectOutputStream.writeObject(Unknown Source) >> >>>>>> at >> org.apache.wicket.util.io.IObjectStreamFactory$DefaultObjectStreamFactory$2.writeObjectOverride(IObjectStreamFactory.java:121) >> >> >>>>>> at java.io.ObjectOutputStream.writeObject(Unknown Source) >> >>>>>> at >> org.apache.wicket.util.lang.Objects.objectToByteArray(Objects.java:1124) >> >>>>>> at >> org.apache.wicket.protocol.http.pagestore.AbstractPageStore.serializePage(AbstractPageStore.java:203) >> >> >>>>>> at >> org.apache.wicket.protocol.http.pagestore.DiskPageStore.prepareForSerialization(DiskPageStore.java:1190) >> >> >>>>>> at >> org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.writeObject(SecondLevelCacheSessionStore.java:389) >> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Become a Wicket expert, learn from the best: >> http://wicketinaction.com <http://wicketinaction.com?by-user=t> >> >>>> >> >>>> - >> >>>> To unsubscribe, e-mail: [hidden >> >>>> email]<http://user/SendEmail.jtp?type=node&node=3045359&i=2> >> >>>> For additional commands, e-mail: [hidden >> >>>> email]<http://user/SendEmail.jtp?type=node&node=3045359&i=3> >> >>>> >> >>> >> >> >> > >> > >> > - >> > To unsubscribe, e-mail: [hidden >> > email]<http://user/SendEmail.jtp?type=node&node=3045359&i=4> >> > For additional commands, e-mail: [hidden >> > email]<http://user/SendEmail.jtp?type=node&node=3045359&i=5> >> > >> > >> >> - >> To unsubscribe, e-mail: [hidden >> email]<http://user/SendEmail.jtp?type=node&node=3045359&i=6> >> For additional commands, e-mail: [hidden >> email]<http://user/SendEmail.jtp?type=node&node=3045359&i=7> >> >> >> >> -- >> View message @ >> http://apache-wicket.1842946.n4.nabble.com/StackOverflowError-tp3044241p3045359.html >> To start a new topic under Apache Wicket, email >> ml-node+1842946-398011874-65...@n4.nabble.com >> To unsubscribe from Apache Wicket, click >> here<http://apache-wicket.1842946.n4.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_code&node=1842946&code=amNnYXJjaWFtQGdtYWlsLmNvbXwxODQyOTQ2fDEyNTYxMzc3ODY=>. >> >> >> > > > -- > Sincerely, > JC (http://www.linkedin.com/in/jcgarciam) > Work smarter, not harder!. > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/StackOverflowError-tp3044241p3045367.html > Sent from the Users forum mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Become a Wicket expert, learn from the best: http://wicketinaction.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: StackOverflowError
added a log warning to property models when they reference session. -igor On Tue, Nov 16, 2010 at 9:46 AM, Douglas Ferguson 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 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 # Size Growth >> 13 389523448 1.93 >> 12 202059096 1.93 >> 11 104804096 1.93 >> 10 54352280 1.93 >> 9 28182760 1.93 >> 8 14594976 1.93 >> 7 7549336 1.94 >> 6 3900704 1.94 >> 5 2013480 2 >> 4 1006960 2 >> 3 503696 2 >> 2 252072 1.86 >> 1 135704 > > > 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.writeOrdinar
Re: StackOverflowError
eObject(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 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 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 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 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 Source) > >>>>>>
Re: StackOverflowError
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 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 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 # Size Growth >> 13 389523448 1.93 >> 12 202059096 1.93 >> 11 104804096 1.93 >> 10 54352280 1.93 >> 9 28182760 1.93 >> 8 14594976 1.93 >> 7 7549336 1.94 >> 6 3900704 1.94 >> 5 2013480 2 >> 4 1006960 2 >> 3 503696 2 >> 2 252072 1.86 >> 1 135704 > > > 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.defaultWriteFi
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(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 Source) > at java.io.ObjectOutputStream.writeArray(Unknown Source) > at java.io.ObjectOutputStream.writeObject0(Unknown Source
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) 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.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 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 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 Source) >>> at java.io.ObjectOutputStream.writeArray(Unknown Source) >>> at java.io.ObjectOutputStream.writeObject0(Unknown Source) >>> at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source) >>> at
Re: StackOverflowError
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 # Size Growth >> 13 389523448 1.93 >> 12 202059096 1.93 >> 11 104804096 1.93 >> 10 54352280 1.93 >> 9 28182760 1.93 >> 8 14594976 1.93 >> 7 7549336 1.94 >> 6 3900704 1.94 >> 5 2013480 2 >> 4 1006960 2 >> 3 503696 2 >> 2 252072 1.86 >> 1 135704 > > > 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 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 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 Source) >> at java.io.Object
StackOverflowError
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 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 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 Source) > at java.io.ObjectOutputStream.writeArray(Unknown Source) > at java.io.ObjectOutputStream.writeObject0(Unknown Source) > at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source) > a
Re: StackOverFlowError
Hello, Pages are serialized at the end of the request cycle (this includes at the end of ajax requests) Look at AbstractPageStore.serializePage(...) Specificically the call to Objects.objectToByteArray(page.getPageMapEntry()) which turns the page into a bytearray. http://grepcode.com/file/repo1.maven.org/maven2/org.apache.wicket/wicket/1.4.10/org/apache/wicket/protocol/http/pagestore/AbstractPageStore.java#AbstractPageStore.serializePage%28org.apache.wicket.Page%29 Regards, Mike When exactly does a page get serialized/serialized? On Thu, Sep 23, 2010 at 12:54 PM, Igor Vaynbergwrote: in dev serialization should happen just like in production. -igor On Thu, Sep 23, 2010 at 10:34 AM, Douglas Ferguson wrote: Hey guys, We overwrote "IObjectStreamFactory" with a copy that has more logging and we found the object that is causing the problems in our production logs. Now we need to recreate it in a more controlled environment. How could we force serialization of this object in a dev environmental? D/ On Wed, Sep 22, 2010 at 6:23 PM, Andreas Petersson i had a very similar problem occuring in production when where was a cluster failover. i could never reproduce it. did something strange happen to you like, the filesystem was partially wiped during writing? - 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: StackOverFlowError
at the end of request -igor On Thu, Sep 23, 2010 at 11:55 AM, Douglas Ferguson wrote: > When exactly does a page get serialized/serialized? > > On Thu, Sep 23, 2010 at 12:54 PM, Igor Vaynberg > wrote: > >> in dev serialization should happen just like in production. >> >> -igor >> >> On Thu, Sep 23, 2010 at 10:34 AM, Douglas Ferguson >> wrote: >> > Hey guys, >> > >> > We overwrote "IObjectStreamFactory" with a copy that has more logging and >> we >> > found the object that is causing the problems in our production logs. Now >> we >> > need to recreate it in a more controlled environment. >> > >> > How could we force serialization of this object in a dev environmental? >> > >> > D/ >> > >> > On Wed, Sep 22, 2010 at 6:23 PM, Andreas Petersson > >wrote: >> > >> >> i had a very similar problem occuring in production when where was a >> >> cluster failover. i could never reproduce it. did something strange >> happen >> >> to you like, the filesystem was partially wiped during writing? >> >> >> >> >> >> - >> >> 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: StackOverFlowError
When exactly does a page get serialized/serialized? On Thu, Sep 23, 2010 at 12:54 PM, Igor Vaynberg wrote: > in dev serialization should happen just like in production. > > -igor > > On Thu, Sep 23, 2010 at 10:34 AM, Douglas Ferguson > wrote: > > Hey guys, > > > > We overwrote "IObjectStreamFactory" with a copy that has more logging and > we > > found the object that is causing the problems in our production logs. Now > we > > need to recreate it in a more controlled environment. > > > > How could we force serialization of this object in a dev environmental? > > > > D/ > > > > On Wed, Sep 22, 2010 at 6:23 PM, Andreas Petersson >wrote: > > > >> i had a very similar problem occuring in production when where was a > >> cluster failover. i could never reproduce it. did something strange > happen > >> to you like, the filesystem was partially wiped during writing? > >> > >> > >> - > >> 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
in dev serialization should happen just like in production. -igor On Thu, Sep 23, 2010 at 10:34 AM, Douglas Ferguson wrote: > Hey guys, > > We overwrote "IObjectStreamFactory" with a copy that has more logging and we > found the object that is causing the problems in our production logs. Now we > need to recreate it in a more controlled environment. > > How could we force serialization of this object in a dev environmental? > > D/ > > On Wed, Sep 22, 2010 at 6:23 PM, Andreas Petersson > wrote: > >> i had a very similar problem occuring in production when where was a >> cluster failover. i could never reproduce it. did something strange happen >> to you like, the filesystem was partially wiped during writing? >> >> >> - >> 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
Hey guys, We overwrote "IObjectStreamFactory" with a copy that has more logging and we found the object that is causing the problems in our production logs. Now we need to recreate it in a more controlled environment. How could we force serialization of this object in a dev environmental? D/ On Wed, Sep 22, 2010 at 6:23 PM, Andreas Petersson wrote: > i had a very similar problem occuring in production when where was a > cluster failover. i could never reproduce it. did something strange happen > to you like, the filesystem was partially wiped during writing? > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: StackOverFlowError
i had a very similar problem occuring in production when where was a cluster failover. i could never reproduce it. did something strange happen to you like, the filesystem was partially wiped during writing? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: StackOverFlowError
setresponsepage(new mypage(thispage)); or indirectly via an anonymous model class or something that holds a reference to the page. -igor On Fri, Jul 2, 2010 at 9:57 AM, Douglas Ferguson wrote: > Hmm... I don't really follow. > > > > On Fri, Jul 2, 2010 at 11:31 AM, robert.mcguinness < > robert.mcguinness@gmail.com> wrote: > >> >> this happened to me the other day. turned out to be a coding error. i >> wrapped a compoundpropertymodel in a propertylistview (which already wraps >> a >> model into a compoundpropertymodel). once the code was fix the problem >> went >> away. >> >> my data set was also large. about 1000 rows in a table being displayed on >> screen. >> -- >> View this message in context: >> http://apache-wicket.1842946.n4.nabble.com/StackOverFlowError-tp2276618p2276655.html >> Sent from the Wicket - User mailing list archive at Nabble.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
Hmm... I don't really follow. On Fri, Jul 2, 2010 at 11:31 AM, robert.mcguinness < robert.mcguinness@gmail.com> wrote: > > this happened to me the other day. turned out to be a coding error. i > wrapped a compoundpropertymodel in a propertylistview (which already wraps > a > model into a compoundpropertymodel). once the code was fix the problem > went > away. > > my data set was also large. about 1000 rows in a table being displayed on > screen. > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/StackOverFlowError-tp2276618p2276655.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: StackOverFlowError
this happened to me the other day. turned out to be a coding error. i wrapped a compoundpropertymodel in a propertylistview (which already wraps a model into a compoundpropertymodel). once the code was fix the problem went away. my data set was also large. about 1000 rows in a table being displayed on screen. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/StackOverFlowError-tp2276618p2276655.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: StackOverflowError under serialization leaves pagemap locked
OK, WICKET-2789 added. Thanks again Nigel --- we can modify serializable checker to check if anything is holding a reference to session or application and catch the error right away. please add a jira issue for this. -igor
Re: StackOverflowError under serialization leaves pagemap locked
we can modify serializable checker to check if anything is holding a reference to session or application and catch the error right away. please add a jira issue for this. -igor On Thu, Mar 18, 2010 at 11:17 PM, Nigel Parker wrote: > Thanks for all your help, Johan and Igor. Problem solved we think. One > of the pages was holding a reference to the session. With multiple > Ajax requests on the same page the session size was doubling each > time, eventually giving stack overflow. > > Nigel > > > Or: > > http://wicketstuff.org/maven/repository/org/apache/wicket/wicket/1.4-SNAPSHOT/ > > That should also have the latest fix > > - Original message - > > the fix is in 1.4.x branch and will be part of 1.4.8. > > in the meantime you can build a fresh snapshot yourself and drop that > into your application > > http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.x > > -igor > > - > 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 under serialization leaves pagemap locked
Thanks for all your help, Johan and Igor. Problem solved we think. One of the pages was holding a reference to the session. With multiple Ajax requests on the same page the session size was doubling each time, eventually giving stack overflow. Nigel Or: http://wicketstuff.org/maven/repository/org/apache/wicket/wicket/1.4-SNAPSHOT/ That should also have the latest fix - Original message - the fix is in 1.4.x branch and will be part of 1.4.8. in the meantime you can build a fresh snapshot yourself and drop that into your application http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.x -igor - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: StackOverflowError under serialization leaves pagemap locked
Or: http://wicketstuff.org/maven/repository/org/apache/wicket/wicket/1.4-SNAPSHOT/ That should also have the latest fix - Original message - > the fix is in 1.4.x branch and will be part of 1.4.8. > > in the meantime you can build a fresh snapshot yourself and drop that > into your application > > http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.x > > -igor > > On Thu, Mar 18, 2010 at 3:27 PM, Nigel Parker wrote: > > > > Thank you Johan for your reply. Agree that original problem should be fixed. > > This is a critical problem for us. We have found out during the last 24 > > hours that some of our pages are retaining a session reference. With Ajax > > requests this gives a doubling of session size for every request, and we now > > believe this to be the cause of the StackOverflowErrors. We will try this in > > production tomorrow. > > > > We upgraded to to 1.4.7 but still see that the pagemap is locked when the > > stack overflows. Do you know if the fix to WICKET-2075 is in 1.4.7? > > > > Thanks > > Nigel > > > > > > Johan Compagner wrote: > > > > > > i fixed 2075 so that it should always unlock the pages. > > > > > > Problem is that you still could get weird errors because that page is not > > > in > > > a valid state in the session. > > > So if back buttons/page versions are used it could be that that doesnt > > > work > > > > > > So what should be fixed is the original problem > > > > > > > > > > > > On Wed, Mar 17, 2010 at 21:03, Nigel Parker > > > wrote: > > > > > > > We are a Wicket shop and for one of our clients have been running a > > > > Wicket application successfully for over 2 years. We are now at > > > > version 1.4.0. The traffic on the system is increasing and we are now > > > > seeing an increased frequency of pagemap locking which is beginning to > > > > be a serious problem for the users. By subclassing WebRequestCycle we > > > > have identified that a StackOverflowError under serialization in > > > > RequestCycle.detach() leaves the pagemap locked for the next minute. > > > > If our analysis is correct this is essentially the problem reported as > > > > https://issues.apache.org/jira/browse/WICKET-2075. Unfortunately we > > > > cannot reproduce the problem in our test environment and it occurs > > > > only in about one in every thousand requests with no apparent > > > > consistent pattern about what the user has been doing. Can anybody > > > > suggest an immediate strategy for further investigations? In > > > > particular: > > > > > > > > - is there a practical way to find out what is causing the > > > > serialization problem. The stack trace is no help. We do in many cases > > > > have large amounts of data in the session, but doubling the default > > > > stack size leaves the problem frequency unchanged leading us to > > > > suspect a logical error rather the sheer amount of data. > > > > > > > > - by overriding RequestCycle.detach() and catching the > > > > StackOverflowError we can get control when the error occurs. Is there > > > > any way we can persuade Wicket to release the pagemap lock? I have > > > > looked at the code and this doesn't look straightforward. > > > > > > > > - can we get Wicket itself to suppress the StackOverflowError so that > > > > detach() continues and releases the lock? > > > > > > > > Grateful for any suggestions. > > > > > > > > Nigel > > > > > > > > - > > > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > > > > > > > > > > > > > > -- > > View this message in context: > > http://old.nabble.com/StackOverflowError-under-serialization-leaves-pagemap-locked-tp27938028p27950858.html > > Sent from the Wicket - User mailing list archive at Nabble.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 under serialization leaves pagemap locked
the fix is in 1.4.x branch and will be part of 1.4.8. in the meantime you can build a fresh snapshot yourself and drop that into your application http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.x -igor On Thu, Mar 18, 2010 at 3:27 PM, Nigel Parker wrote: > > Thank you Johan for your reply. Agree that original problem should be fixed. > This is a critical problem for us. We have found out during the last 24 > hours that some of our pages are retaining a session reference. With Ajax > requests this gives a doubling of session size for every request, and we now > believe this to be the cause of the StackOverflowErrors. We will try this in > production tomorrow. > > We upgraded to to 1.4.7 but still see that the pagemap is locked when the > stack overflows. Do you know if the fix to WICKET-2075 is in 1.4.7? > > Thanks > Nigel > > > Johan Compagner wrote: >> >> i fixed 2075 so that it should always unlock the pages. >> >> Problem is that you still could get weird errors because that page is not >> in >> a valid state in the session. >> So if back buttons/page versions are used it could be that that doesnt >> work >> >> So what should be fixed is the original problem >> >> >> >> On Wed, Mar 17, 2010 at 21:03, Nigel Parker >> wrote: >> >>> We are a Wicket shop and for one of our clients have been running a >>> Wicket application successfully for over 2 years. We are now at >>> version 1.4.0. The traffic on the system is increasing and we are now >>> seeing an increased frequency of pagemap locking which is beginning to >>> be a serious problem for the users. By subclassing WebRequestCycle we >>> have identified that a StackOverflowError under serialization in >>> RequestCycle.detach() leaves the pagemap locked for the next minute. >>> If our analysis is correct this is essentially the problem reported as >>> https://issues.apache.org/jira/browse/WICKET-2075. Unfortunately we >>> cannot reproduce the problem in our test environment and it occurs >>> only in about one in every thousand requests with no apparent >>> consistent pattern about what the user has been doing. Can anybody >>> suggest an immediate strategy for further investigations? In >>> particular: >>> >>> - is there a practical way to find out what is causing the >>> serialization problem. The stack trace is no help. We do in many cases >>> have large amounts of data in the session, but doubling the default >>> stack size leaves the problem frequency unchanged leading us to >>> suspect a logical error rather the sheer amount of data. >>> >>> - by overriding RequestCycle.detach() and catching the >>> StackOverflowError we can get control when the error occurs. Is there >>> any way we can persuade Wicket to release the pagemap lock? I have >>> looked at the code and this doesn't look straightforward. >>> >>> - can we get Wicket itself to suppress the StackOverflowError so that >>> detach() continues and releases the lock? >>> >>> Grateful for any suggestions. >>> >>> Nigel >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >> > > -- > View this message in context: > http://old.nabble.com/StackOverflowError-under-serialization-leaves-pagemap-locked-tp27938028p27950858.html > Sent from the Wicket - User mailing list archive at Nabble.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 under serialization leaves pagemap locked
Thank you Johan for your reply. Agree that original problem should be fixed. This is a critical problem for us. We have found out during the last 24 hours that some of our pages are retaining a session reference. With Ajax requests this gives a doubling of session size for every request, and we now believe this to be the cause of the StackOverflowErrors. We will try this in production tomorrow. We upgraded to to 1.4.7 but still see that the pagemap is locked when the stack overflows. Do you know if the fix to WICKET-2075 is in 1.4.7? Thanks Nigel Johan Compagner wrote: > > i fixed 2075 so that it should always unlock the pages. > > Problem is that you still could get weird errors because that page is not > in > a valid state in the session. > So if back buttons/page versions are used it could be that that doesnt > work > > So what should be fixed is the original problem > > > > On Wed, Mar 17, 2010 at 21:03, Nigel Parker > wrote: > >> We are a Wicket shop and for one of our clients have been running a >> Wicket application successfully for over 2 years. We are now at >> version 1.4.0. The traffic on the system is increasing and we are now >> seeing an increased frequency of pagemap locking which is beginning to >> be a serious problem for the users. By subclassing WebRequestCycle we >> have identified that a StackOverflowError under serialization in >> RequestCycle.detach() leaves the pagemap locked for the next minute. >> If our analysis is correct this is essentially the problem reported as >> https://issues.apache.org/jira/browse/WICKET-2075. Unfortunately we >> cannot reproduce the problem in our test environment and it occurs >> only in about one in every thousand requests with no apparent >> consistent pattern about what the user has been doing. Can anybody >> suggest an immediate strategy for further investigations? In >> particular: >> >> - is there a practical way to find out what is causing the >> serialization problem. The stack trace is no help. We do in many cases >> have large amounts of data in the session, but doubling the default >> stack size leaves the problem frequency unchanged leading us to >> suspect a logical error rather the sheer amount of data. >> >> - by overriding RequestCycle.detach() and catching the >> StackOverflowError we can get control when the error occurs. Is there >> any way we can persuade Wicket to release the pagemap lock? I have >> looked at the code and this doesn't look straightforward. >> >> - can we get Wicket itself to suppress the StackOverflowError so that >> detach() continues and releases the lock? >> >> Grateful for any suggestions. >> >> Nigel >> >> ----- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > -- View this message in context: http://old.nabble.com/StackOverflowError-under-serialization-leaves-pagemap-locked-tp27938028p27950858.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: StackOverflowError under serialization leaves pagemap locked
i fixed 2075 so that it should always unlock the pages. Problem is that you still could get weird errors because that page is not in a valid state in the session. So if back buttons/page versions are used it could be that that doesnt work So what should be fixed is the original problem On Wed, Mar 17, 2010 at 21:03, Nigel Parker wrote: > We are a Wicket shop and for one of our clients have been running a > Wicket application successfully for over 2 years. We are now at > version 1.4.0. The traffic on the system is increasing and we are now > seeing an increased frequency of pagemap locking which is beginning to > be a serious problem for the users. By subclassing WebRequestCycle we > have identified that a StackOverflowError under serialization in > RequestCycle.detach() leaves the pagemap locked for the next minute. > If our analysis is correct this is essentially the problem reported as > https://issues.apache.org/jira/browse/WICKET-2075. Unfortunately we > cannot reproduce the problem in our test environment and it occurs > only in about one in every thousand requests with no apparent > consistent pattern about what the user has been doing. Can anybody > suggest an immediate strategy for further investigations? In > particular: > > - is there a practical way to find out what is causing the > serialization problem. The stack trace is no help. We do in many cases > have large amounts of data in the session, but doubling the default > stack size leaves the problem frequency unchanged leading us to > suspect a logical error rather the sheer amount of data. > > - by overriding RequestCycle.detach() and catching the > StackOverflowError we can get control when the error occurs. Is there > any way we can persuade Wicket to release the pagemap lock? I have > looked at the code and this doesn't look straightforward. > > - can we get Wicket itself to suppress the StackOverflowError so that > detach() continues and releases the lock? > > Grateful for any suggestions. > > Nigel > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
StackOverflowError under serialization leaves pagemap locked
We are a Wicket shop and for one of our clients have been running a Wicket application successfully for over 2 years. We are now at version 1.4.0. The traffic on the system is increasing and we are now seeing an increased frequency of pagemap locking which is beginning to be a serious problem for the users. By subclassing WebRequestCycle we have identified that a StackOverflowError under serialization in RequestCycle.detach() leaves the pagemap locked for the next minute. If our analysis is correct this is essentially the problem reported as https://issues.apache.org/jira/browse/WICKET-2075. Unfortunately we cannot reproduce the problem in our test environment and it occurs only in about one in every thousand requests with no apparent consistent pattern about what the user has been doing. Can anybody suggest an immediate strategy for further investigations? In particular: - is there a practical way to find out what is causing the serialization problem. The stack trace is no help. We do in many cases have large amounts of data in the session, but doubling the default stack size leaves the problem frequency unchanged leading us to suspect a logical error rather the sheer amount of data. - by overriding RequestCycle.detach() and catching the StackOverflowError we can get control when the error occurs. Is there any way we can persuade Wicket to release the pagemap lock? I have looked at the code and this doesn't look straightforward. - can we get Wicket itself to suppress the StackOverflowError so that detach() continues and releases the lock? Grateful for any suggestions. Nigel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: StackOverflowError on cluster failover.
it looks like it may be a problem deserializing a joda time object. you will have to debug and see which class exactly fails. -igor On Thu, Sep 3, 2009 at 5:11 AM, HarriSoft Ltd wrote: > > Hi, > > Firstly, I'm using Tomcat 5.5 and Wicket 1.3.5 > > I've recently been tasked with running our current application in a > clustered environment. Having got the cluster configured (sticky sessions > and session replication) I figured the app should run without a problem > and it does, mostly. > > I've found a problem whereby it does not appear that the DiskPageStore > file is being clustered correctly (its also possible that I've missed > something).. Our app has a feature that lets the user navigate backwards > from the current page, retrieving the previous pages from the > DiskPageStore and providing links on the pages (Back to SearchResults, > previous page, etc.) to allow for backwards navigation. On a single > server this works, but in a clustered environment if the session was > created on server A, then if server A failed over to server B, Wicket > throws a StackOverflowError (Top of the stack trace is below). Has > anybody seen this behaviour before? I have seen some comments about > clusters failing over and exceptions being thrown on a subsequent use of > the back button; is this still the case as that is essentially what we are > doing with pages in a flow. > > Any help appreciated. > > java.lang.StackOverflowError > java.io.ObjectStreamClass.readNonProxy(ObjectStreamClass.java:600) > > java.io.ObjectInputStream.readClassDescriptor(ObjectInputStream.java:789) > java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1534) > java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466) > > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699) > java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) > java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) > > org.joda.time.chrono.ISOChronology$Stub.readObject(ISOChronology.java:210) > sun.reflect.GeneratedMethodAccessor34.invoke(Unknown Source) > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > java.lang.reflect.Method.invoke(Method.java:585) > java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946) > java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1809) > > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719) > java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) > > java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908) > java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832) > > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719) > java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) > > java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908) > java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832) > > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719) > java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) > > java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908) > java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832) > > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719) > java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) > java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) > java.util.ArrayList.readObject(ArrayList.java:591) > sun.reflect.GeneratedMethodAccessor33.invoke(Unknown Source) > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > java.lang.reflect.Method.invoke(Method.java:585) > java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946) > java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1809) > > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719) > java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) > > java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908) > java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832) > > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719) > java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) > java.io.ObjectInputStream.readArray(ObjectInputStream.java:1634) > java.io.ObjectI
StackOverflowError on cluster failover.
Hi, Firstly, I'm using Tomcat 5.5 and Wicket 1.3.5 I've recently been tasked with running our current application in a clustered environment. Having got the cluster configured (sticky sessions and session replication) I figured the app should run without a problem and it does, mostly. I've found a problem whereby it does not appear that the DiskPageStore file is being clustered correctly (its also possible that I've missed something).. Our app has a feature that lets the user navigate backwards from the current page, retrieving the previous pages from the DiskPageStore and providing links on the pages (Back to SearchResults, previous page, etc.) to allow for backwards navigation. On a single server this works, but in a clustered environment if the session was created on server A, then if server A failed over to server B, Wicket throws a StackOverflowError (Top of the stack trace is below). Has anybody seen this behaviour before? I have seen some comments about clusters failing over and exceptions being thrown on a subsequent use of the back button; is this still the case as that is essentially what we are doing with pages in a flow. Any help appreciated. java.lang.StackOverflowError java.io.ObjectStreamClass.readNonProxy(ObjectStreamClass.java:600) java.io.ObjectInputStream.readClassDescriptor(ObjectInputStream.java:789) java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1534) java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466) java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699) java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) org.joda.time.chrono.ISOChronology$Stub.readObject(ISOChronology.java:210) sun.reflect.GeneratedMethodAccessor34.invoke(Unknown Source) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) java.lang.reflect.Method.invoke(Method.java:585) java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946) java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1809) java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719) java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908) java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832) java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719) java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908) java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832) java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719) java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908) java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832) java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719) java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) java.util.ArrayList.readObject(ArrayList.java:591) sun.reflect.GeneratedMethodAccessor33.invoke(Unknown Source) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) java.lang.reflect.Method.invoke(Method.java:585) java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946) java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1809) java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719) java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908) java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832) java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719) java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) java.io.ObjectInputStream.readArray(ObjectInputStream.java:1634) java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299) java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908) java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832) java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719) java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) org.apache.wicket.util.lang.Objects.byteArrayToObj
Re: StackOverflowError using 1.3.2
i was able to reproduce it in a quickstart. see WICKET-1476 Gerolf On Wed, Apr 2, 2008 at 9:02 PM, Johan Compagner <[EMAIL PROTECTED]> wrote: > if we have a quickstart for this we could look for the solution... > > > On Wed, Apr 2, 2008 at 8:26 PM, André Souza <[EMAIL PROTECTED]> > wrote: > > > I have the exactly same problem. Someone found the solution? > > > > On Tue, Apr 1, 2008 at 6:09 PM, Johan Compagner <[EMAIL PROTECTED]> > > wrote: > > > > > do you have a unit test or quickstart for this? > > > > > > johan > > > > > > > > > On Tue, Apr 1, 2008 at 10:57 PM, Mark Lichtenberg < > > [EMAIL PROTECTED] > > > > > > > wrote: > > > > > > > Hi, > > > > We've been experiencing StackOverflowErrors when our application is > > > > under a load of around 4 sessions, mostly clicks to load pages > without > > > > necessarily waiting for the previous click to finish. I saw this > was > > > > addressed with jira issue 1365, and was part of 1.3.2, which we are > > > > using. For good measure, we took out all instance variables > > > > referencing Page objects, which was mentioned in the jira issue, but > > > > this did not help either. We also tried the wicket nightly today, > but > > > > got the same results. Seems to be due to page deserialization - a > > > > snippet of the exception is below. > > > > > > > > Any help would be greatly appreciated. > > > > > > > > 11:15:15,497 ERROR [[default]] Servlet.service() for servlet default > > > > threw exception > > > > java.lang.StackOverflowError > > > >at java.io.ObjectInputStream > > > > $PeekInputStream.read(ObjectInputStream.java:2213) > > > >at java.io.ObjectInputStream > > > > $PeekInputStream.readFully(ObjectInputStream.java:2226) > > > >at java.io.ObjectInputStream > > > > $BlockDataInputStream.readUTFBody(ObjectInputStream.java:2963) > > > >at java.io.ObjectInputStream > > > > $BlockDataInputStream.readUTF(ObjectInputStream.java:2764) > > > >at > > java.io.ObjectInputStream.readUTF(ObjectInputStream.java:1032) > > > >at > > java.io.ObjectStreamClass.readNonProxy(ObjectStreamClass.java > > > > :600) > > > >at > > > > > java.io.ObjectInputStream.readClassDescriptor(ObjectInputStream.java: > > > > 789) > > > >at java.io.ObjectInputStream.readNonProxyDesc( > > > > ObjectInputStream.java: > > > > 1534) > > > >at > > java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java > > > > :1466) > > > >at > > > > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: > > > > 1699) > > > >at > java.io.ObjectInputStream.readObject0(ObjectInputStream.java > > > > :1305) > > > >at > > > java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) > > > >at java.util.HashSet.readObject(HashSet.java:278) > > > >at sun.reflect.GeneratedMethodAccessor121.invoke(Unknown > > Source) > > > >at > > > > sun > > > > .reflect > > > > > > .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: > > > > 25) > > > >at java.lang.reflect.Method.invoke(Method.java:585) > > > >at java.io.ObjectStreamClass.invokeReadObject( > > > > ObjectStreamClass.java: > > > > 946) > > > >at > > > java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: > > > > 1809) > > > >at > > > > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: > > > > 1719) > > > >at > java.io.ObjectInputStream.readObject0(ObjectInputStream.java > > > > :1305) > > > >at java.io.ObjectInputStream.defaultReadFields( > > > > ObjectInputStream.java: > > > > 1908) > > > >at > > > java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: > > > > 1832) > > > >at > > > > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: > > > > 1719) > > > >at > java.io.ObjectInputStream.readObject0(ObjectInputStream.java > > > > :1305) > > > >at > > > java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) > > > >at java.util.HashMap.readObject(HashMap.java:1067) > > > >at sun.reflect.GeneratedMethodAccessor122.invoke(Unknown > > Source) > > > >at > > > > sun > > > > .reflect > > > > > > .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: > > > > 25) > > > >at java.lang.reflect.Method.invoke(Method.java:585) > > > >at java.io.ObjectStreamClass.invokeReadObject( > > > > ObjectStreamClass.java: > > > > 946) > > > >at > > > java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: > > > > 1809) > > > >at > > > > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: > > > > 1719) > > > > > > > >at > > > > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: > > > > 1719) > > > >at > java.io.ObjectInputStream.readObject0(ObjectInputStream.java > > > > :1305) > > > >at > > > java.io.ObjectInputStream.readObject(ObjectInputS
Re: StackOverflowError using 1.3.2
if we have a quickstart for this we could look for the solution... On Wed, Apr 2, 2008 at 8:26 PM, André Souza <[EMAIL PROTECTED]> wrote: > I have the exactly same problem. Someone found the solution? > > On Tue, Apr 1, 2008 at 6:09 PM, Johan Compagner <[EMAIL PROTECTED]> > wrote: > > > do you have a unit test or quickstart for this? > > > > johan > > > > > > On Tue, Apr 1, 2008 at 10:57 PM, Mark Lichtenberg < > [EMAIL PROTECTED] > > > > > wrote: > > > > > Hi, > > > We've been experiencing StackOverflowErrors when our application is > > > under a load of around 4 sessions, mostly clicks to load pages without > > > necessarily waiting for the previous click to finish. I saw this was > > > addressed with jira issue 1365, and was part of 1.3.2, which we are > > > using. For good measure, we took out all instance variables > > > referencing Page objects, which was mentioned in the jira issue, but > > > this did not help either. We also tried the wicket nightly today, but > > > got the same results. Seems to be due to page deserialization - a > > > snippet of the exception is below. > > > > > > Any help would be greatly appreciated. > > > > > > 11:15:15,497 ERROR [[default]] Servlet.service() for servlet default > > > threw exception > > > java.lang.StackOverflowError > > >at java.io.ObjectInputStream > > > $PeekInputStream.read(ObjectInputStream.java:2213) > > >at java.io.ObjectInputStream > > > $PeekInputStream.readFully(ObjectInputStream.java:2226) > > >at java.io.ObjectInputStream > > > $BlockDataInputStream.readUTFBody(ObjectInputStream.java:2963) > > >at java.io.ObjectInputStream > > > $BlockDataInputStream.readUTF(ObjectInputStream.java:2764) > > >at > java.io.ObjectInputStream.readUTF(ObjectInputStream.java:1032) > > >at > java.io.ObjectStreamClass.readNonProxy(ObjectStreamClass.java > > > :600) > > >at > > > java.io.ObjectInputStream.readClassDescriptor(ObjectInputStream.java: > > > 789) > > >at java.io.ObjectInputStream.readNonProxyDesc( > > > ObjectInputStream.java: > > > 1534) > > >at > java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java > > > :1466) > > >at > > > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: > > > 1699) > > >at java.io.ObjectInputStream.readObject0(ObjectInputStream.java > > > :1305) > > >at > > java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) > > >at java.util.HashSet.readObject(HashSet.java:278) > > >at sun.reflect.GeneratedMethodAccessor121.invoke(Unknown > Source) > > >at > > > sun > > > .reflect > > > > .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: > > > 25) > > >at java.lang.reflect.Method.invoke(Method.java:585) > > >at java.io.ObjectStreamClass.invokeReadObject( > > > ObjectStreamClass.java: > > > 946) > > >at > > java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: > > > 1809) > > >at > > > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: > > > 1719) > > >at java.io.ObjectInputStream.readObject0(ObjectInputStream.java > > > :1305) > > >at java.io.ObjectInputStream.defaultReadFields( > > > ObjectInputStream.java: > > > 1908) > > >at > > java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: > > > 1832) > > >at > > > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: > > > 1719) > > >at java.io.ObjectInputStream.readObject0(ObjectInputStream.java > > > :1305) > > >at > > java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) > > >at java.util.HashMap.readObject(HashMap.java:1067) > > >at sun.reflect.GeneratedMethodAccessor122.invoke(Unknown > Source) > > >at > > > sun > > > .reflect > > > > .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: > > > 25) > > >at java.lang.reflect.Method.invoke(Method.java:585) > > >at java.io.ObjectStreamClass.invokeReadObject( > > > ObjectStreamClass.java: > > > 946) > > >at > > java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: > > > 1809) > > >at > > > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: > > > 1719) > > > > > >at > > > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: > > > 1719) > > >at java.io.ObjectInputStream.readObject0(ObjectInputStream.java > > > :1305) > > >at > > java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) > > >at org.apache.wicket.util.lang.Objects.byteArrayToObject( > > > Objects.java: > > > 392) > > >at > > > org > > > .apache > > > .wicket > > > .protocol > > > .http > > > > .pagestore.AbstractPageStore.deserializePage(AbstractPageStore.java:228) > > >at > > > org > > > .apache > > > .wicket > > > .protocol.http.pagestore.DiskPageStore.getPage(DiskPageStore.java:706) >
Re: StackOverflowError using 1.3.2
I have the exactly same problem. Someone found the solution? On Tue, Apr 1, 2008 at 6:09 PM, Johan Compagner <[EMAIL PROTECTED]> wrote: > do you have a unit test or quickstart for this? > > johan > > > On Tue, Apr 1, 2008 at 10:57 PM, Mark Lichtenberg <[EMAIL PROTECTED] > > > wrote: > > > Hi, > > We've been experiencing StackOverflowErrors when our application is > > under a load of around 4 sessions, mostly clicks to load pages without > > necessarily waiting for the previous click to finish. I saw this was > > addressed with jira issue 1365, and was part of 1.3.2, which we are > > using. For good measure, we took out all instance variables > > referencing Page objects, which was mentioned in the jira issue, but > > this did not help either. We also tried the wicket nightly today, but > > got the same results. Seems to be due to page deserialization - a > > snippet of the exception is below. > > > > Any help would be greatly appreciated. > > > > 11:15:15,497 ERROR [[default]] Servlet.service() for servlet default > > threw exception > > java.lang.StackOverflowError > >at java.io.ObjectInputStream > > $PeekInputStream.read(ObjectInputStream.java:2213) > >at java.io.ObjectInputStream > > $PeekInputStream.readFully(ObjectInputStream.java:2226) > >at java.io.ObjectInputStream > > $BlockDataInputStream.readUTFBody(ObjectInputStream.java:2963) > >at java.io.ObjectInputStream > > $BlockDataInputStream.readUTF(ObjectInputStream.java:2764) > >at java.io.ObjectInputStream.readUTF(ObjectInputStream.java:1032) > >at java.io.ObjectStreamClass.readNonProxy(ObjectStreamClass.java > > :600) > >at > > java.io.ObjectInputStream.readClassDescriptor(ObjectInputStream.java: > > 789) > >at java.io.ObjectInputStream.readNonProxyDesc( > > ObjectInputStream.java: > > 1534) > >at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java > > :1466) > >at > > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: > > 1699) > >at java.io.ObjectInputStream.readObject0(ObjectInputStream.java > > :1305) > >at > java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) > >at java.util.HashSet.readObject(HashSet.java:278) > >at sun.reflect.GeneratedMethodAccessor121.invoke(Unknown Source) > >at > > sun > > .reflect > > .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: > > 25) > >at java.lang.reflect.Method.invoke(Method.java:585) > >at java.io.ObjectStreamClass.invokeReadObject( > > ObjectStreamClass.java: > > 946) > >at > java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: > > 1809) > >at > > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: > > 1719) > >at java.io.ObjectInputStream.readObject0(ObjectInputStream.java > > :1305) > >at java.io.ObjectInputStream.defaultReadFields( > > ObjectInputStream.java: > > 1908) > >at > java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: > > 1832) > >at > > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: > > 1719) > >at java.io.ObjectInputStream.readObject0(ObjectInputStream.java > > :1305) > >at > java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) > >at java.util.HashMap.readObject(HashMap.java:1067) > >at sun.reflect.GeneratedMethodAccessor122.invoke(Unknown Source) > >at > > sun > > .reflect > > .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: > > 25) > >at java.lang.reflect.Method.invoke(Method.java:585) > >at java.io.ObjectStreamClass.invokeReadObject( > > ObjectStreamClass.java: > > 946) > >at > java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: > > 1809) > >at > > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: > > 1719) > > > >at > > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: > > 1719) > >at java.io.ObjectInputStream.readObject0(ObjectInputStream.java > > :1305) > >at > java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) > >at org.apache.wicket.util.lang.Objects.byteArrayToObject( > > Objects.java: > > 392) > >at > > org > > .apache > > .wicket > > .protocol > > .http > > .pagestore.AbstractPageStore.deserializePage(AbstractPageStore.java:228) > >at > > org > > .apache > > .wicket > > .protocol.http.pagestore.DiskPageStore.getPage(DiskPageStore.java:706) > >at org.apache.wicket.protocol.http.SecondLevelCacheSessionStore > > $SecondLevelCachePageMap.get(SecondLevelCacheSessionStore.java:311) > >at org.apache.wicket.Session.getPage(Session.java:751) > >at org.apache.wicket.protocol.http.pagestore.AbstractPageStore > > $PageHolder.readResolve(AbstractPageStore.java:363) > >at sun.reflect.GeneratedMethodAccessor136.invoke(Unknown Sourc
Re: StackOverflowError using 1.3.2
do you have a unit test or quickstart for this? johan On Tue, Apr 1, 2008 at 10:57 PM, Mark Lichtenberg <[EMAIL PROTECTED]> wrote: > Hi, > We've been experiencing StackOverflowErrors when our application is > under a load of around 4 sessions, mostly clicks to load pages without > necessarily waiting for the previous click to finish. I saw this was > addressed with jira issue 1365, and was part of 1.3.2, which we are > using. For good measure, we took out all instance variables > referencing Page objects, which was mentioned in the jira issue, but > this did not help either. We also tried the wicket nightly today, but > got the same results. Seems to be due to page deserialization - a > snippet of the exception is below. > > Any help would be greatly appreciated. > > 11:15:15,497 ERROR [[default]] Servlet.service() for servlet default > threw exception > java.lang.StackOverflowError >at java.io.ObjectInputStream > $PeekInputStream.read(ObjectInputStream.java:2213) >at java.io.ObjectInputStream > $PeekInputStream.readFully(ObjectInputStream.java:2226) >at java.io.ObjectInputStream > $BlockDataInputStream.readUTFBody(ObjectInputStream.java:2963) >at java.io.ObjectInputStream > $BlockDataInputStream.readUTF(ObjectInputStream.java:2764) >at java.io.ObjectInputStream.readUTF(ObjectInputStream.java:1032) >at java.io.ObjectStreamClass.readNonProxy(ObjectStreamClass.java > :600) >at > java.io.ObjectInputStream.readClassDescriptor(ObjectInputStream.java: > 789) >at java.io.ObjectInputStream.readNonProxyDesc( > ObjectInputStream.java: > 1534) >at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java > :1466) >at > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: > 1699) >at java.io.ObjectInputStream.readObject0(ObjectInputStream.java > :1305) >at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) >at java.util.HashSet.readObject(HashSet.java:278) >at sun.reflect.GeneratedMethodAccessor121.invoke(Unknown Source) >at > sun > .reflect > .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: > 25) >at java.lang.reflect.Method.invoke(Method.java:585) >at java.io.ObjectStreamClass.invokeReadObject( > ObjectStreamClass.java: > 946) >at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: > 1809) >at > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: > 1719) >at java.io.ObjectInputStream.readObject0(ObjectInputStream.java > :1305) >at java.io.ObjectInputStream.defaultReadFields( > ObjectInputStream.java: > 1908) >at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: > 1832) >at > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: > 1719) >at java.io.ObjectInputStream.readObject0(ObjectInputStream.java > :1305) >at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) >at java.util.HashMap.readObject(HashMap.java:1067) >at sun.reflect.GeneratedMethodAccessor122.invoke(Unknown Source) >at > sun > .reflect > .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: > 25) >at java.lang.reflect.Method.invoke(Method.java:585) >at java.io.ObjectStreamClass.invokeReadObject( > ObjectStreamClass.java: > 946) >at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: > 1809) >at > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: > 1719) > >at > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: > 1719) >at java.io.ObjectInputStream.readObject0(ObjectInputStream.java > :1305) >at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) >at org.apache.wicket.util.lang.Objects.byteArrayToObject( > Objects.java: > 392) >at > org > .apache > .wicket > .protocol > .http > .pagestore.AbstractPageStore.deserializePage(AbstractPageStore.java:228) >at > org > .apache > .wicket > .protocol.http.pagestore.DiskPageStore.getPage(DiskPageStore.java:706) >at org.apache.wicket.protocol.http.SecondLevelCacheSessionStore > $SecondLevelCachePageMap.get(SecondLevelCacheSessionStore.java:311) >at org.apache.wicket.Session.getPage(Session.java:751) >at org.apache.wicket.protocol.http.pagestore.AbstractPageStore > $PageHolder.readResolve(AbstractPageStore.java:363) >at sun.reflect.GeneratedMethodAccessor136.invoke(Unknown Source) >at > sun > .reflect > .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: > 25) > .. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
StackOverflowError using 1.3.2
Hi, We've been experiencing StackOverflowErrors when our application is under a load of around 4 sessions, mostly clicks to load pages without necessarily waiting for the previous click to finish. I saw this was addressed with jira issue 1365, and was part of 1.3.2, which we are using. For good measure, we took out all instance variables referencing Page objects, which was mentioned in the jira issue, but this did not help either. We also tried the wicket nightly today, but got the same results. Seems to be due to page deserialization - a snippet of the exception is below. Any help would be greatly appreciated. 11:15:15,497 ERROR [[default]] Servlet.service() for servlet default threw exception java.lang.StackOverflowError at java.io.ObjectInputStream $PeekInputStream.read(ObjectInputStream.java:2213) at java.io.ObjectInputStream $PeekInputStream.readFully(ObjectInputStream.java:2226) at java.io.ObjectInputStream $BlockDataInputStream.readUTFBody(ObjectInputStream.java:2963) at java.io.ObjectInputStream $BlockDataInputStream.readUTF(ObjectInputStream.java:2764) at java.io.ObjectInputStream.readUTF(ObjectInputStream.java:1032) at java.io.ObjectStreamClass.readNonProxy(ObjectStreamClass.java:600) at java.io.ObjectInputStream.readClassDescriptor(ObjectInputStream.java: 789) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java: 1534) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1699) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at java.util.HashSet.readObject(HashSet.java:278) at sun.reflect.GeneratedMethodAccessor121.invoke(Unknown Source) at sun .reflect .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) at java.lang.reflect.Method.invoke(Method.java:585) at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java: 946) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: 1809) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1719) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java: 1908) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: 1832) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1719) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at java.util.HashMap.readObject(HashMap.java:1067) at sun.reflect.GeneratedMethodAccessor122.invoke(Unknown Source) at sun .reflect .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) at java.lang.reflect.Method.invoke(Method.java:585) at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java: 946) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: 1809) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1719) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1719) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at org.apache.wicket.util.lang.Objects.byteArrayToObject(Objects.java: 392) at org .apache .wicket .protocol .http .pagestore.AbstractPageStore.deserializePage(AbstractPageStore.java:228) at org .apache .wicket .protocol.http.pagestore.DiskPageStore.getPage(DiskPageStore.java:706) at org.apache.wicket.protocol.http.SecondLevelCacheSessionStore $SecondLevelCachePageMap.get(SecondLevelCacheSessionStore.java:311) at org.apache.wicket.Session.getPage(Session.java:751) at org.apache.wicket.protocol.http.pagestore.AbstractPageStore $PageHolder.readResolve(AbstractPageStore.java:363) at sun.reflect.GeneratedMethodAccessor136.invoke(Unknown Source) at sun .reflect .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) .. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Newbie][1.3 beta] StackOverflowError on LogFactory.getContextClassLoader
I found a way I've just copied all *.jar from /lib in "wicket-examples-1.3.0-beta4.war" to "myapp/WEB-INF/lib", ant that works fine ;) I still don't know exactly which jar are required by Wicket, but now it works ;) -- View this message in context: http://www.nabble.com/-Newbie--1.3-beta--StackOverflowError-on-LogFactory.getContextClassLoader-tf4706676.html#a13454622 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Newbie][1.3 beta] StackOverflowError on LogFactory.getContextClassLoader
Hello everybody, I'm a new user of Wicket, and I got to make the HelloWorldApplication works with Wicket 1.2.6 . I tried to do the same with wicket 1.3 beta, but it throw a StackOverflowError: java.lang.StackOverflowError at java.lang.reflect.Method.copy(Unknown Source) at java.lang.reflect.ReflectAccess.copyMethod(Unknown Source) at sun.reflect.ReflectionFactory.copyMethod(Unknown Source) at java.lang.Class.searchMethods(Unknown Source) at java.lang.Class.getMethod0(Unknown Source) at java.lang.Class.getMethod(Unknown Source) at org.apache.commons.logging.LogFactory.getContextClassLoader(LogFactory.java:482) at org.apache.commons.logging.LogFactory$1.run(LogFactory.java:266) at java.security.AccessController.doPrivileged(Native Method) at org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:262) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:414) at org.slf4j.impl.JCLLoggerFactory.getLogger(JCLLoggerFactory.java:69) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:88) at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:155) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:414) at org.slf4j.impl.JCLLoggerFactory.getLogger(JCLLoggerFactory.java:69) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:88) [loop on these lines] at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:155) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:414) at org.slf4j.impl.JCLLoggerFactory.getLogger(JCLLoggerFactory.java:69) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:88) It looks like the logging API isn't correctly set. Is there something I've made wrong? Thanks for your help! S. Piller - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
