Re: Enclosure can't find its markup anymore after restart of Tomcat

[Martin Grigorov]

Sounds like https://issues.apache.org/jira/browse/WICKET-6109
Please try with latest 7.3.0-SNAPSHOT if you are able.
Thanks!

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Fri, Mar 11, 2016 at 7:57 PM, Thorsten Schöning 
wrote:

> Guten Tag Thorsten Schöning,
> am Freitag, 11. März 2016 um 19:45 schrieben Sie:
>
> > I tried to track this down and recognized one important difference:
>
> The following are parts of the stacktrace after a clean startup with
> a breakpoint in EnclosureHandler, where the tag has the following id
> and content:
>
> > wicket_enclosure34: 
>
> > Daemon Thread [http-bio-127.0.0.1-8081-exec-5] (Suspended (breakpoint at
> line 131 in EnclosureHandler))
> > owns: SocketWrapper  (id=89)
> > EnclosureHandler.onComponentTag(ComponentTag) line: 131
> > EnclosureHandler(AbstractMarkupFilter).nextElement() line: 100
> > InlineEnclosureHandler(AbstractMarkupFilter).nextElement() line:
> 95
> > ConditionalCommentFilter(AbstractMarkupFilter).nextElement()
> line: 95
> > WicketContainerTagHandler(AbstractMarkupFilter).nextElement()
> line: 95
> > RelativePathPrefixHandler(AbstractMarkupFilter).nextElement()
> line: 95
> > StyleAndScriptIdentifier(AbstractMarkupFilter).nextElement()
> line: 95
> > MarkupFactory$1(AbstractMarkupParser).getNextTag() line: 217
> > MarkupFactory$1(AbstractMarkupParser).parseMarkup() line: 232
> > MarkupFactory$1(AbstractMarkupParser).parse() line: 185
> > SimpleMarkupLoader.loadMarkup(MarkupContainer,
> MarkupResourceStream, IMarkupLoader, boolean) line: 51
> > InheritedMarkupMarkupLoader.loadMarkup(MarkupContainer,
> MarkupResourceStream, IMarkupLoader, boolean) line: 57
> > DefaultMarkupLoader.loadMarkup(MarkupContainer,
> MarkupResourceStream, IMarkupLoader, boolean) line: 52
> > MarkupFactory.loadMarkup(MarkupContainer, MarkupResourceStream,
> boolean) line: 412
> > MarkupCache.loadMarkup(MarkupContainer, MarkupResourceStream,
> boolean) line: 447
> > MarkupCache.loadMarkupAndWatchForChanges(MarkupContainer,
> MarkupResourceStream, boolean) line: 543
> > MarkupCache.getMarkup(MarkupContainer, Class, boolean) line:
> 304
> > MarkupFactory.getMarkup(MarkupContainer, Class, boolean)
> line: 236
> > MarkupFactory.getMarkup(MarkupContainer, boolean) line: 194
> > PnNav(MarkupContainer).getAssociatedMarkup() line: 456
> > PnNav(MarkupContainer).getRegionMarkup() line: 2224
> > PnNav(Panel).getRegionMarkup() line: 96
> > PnNav(MarkupContainer).newDequeueContext() line: 2211
> > PnNav(MarkupContainer).dequeue() line: 2029
> > WebMarkupContainer(MarkupContainer).addedComponent(Component)
> line: 1049
> > WebMarkupContainer(MarkupContainer).add(Component...) line: 239
> > HomePage.(PageParameters) line: 25
> > NativeConstructorAccessorImpl.newInstance0(Constructor,
> Object[]) line: not available [native method]
> > NativeConstructorAccessorImpl.newInstance(Object[]) line: 57
> > DelegatingConstructorAccessorImpl.newInstance(Object[]) line: 45
> > Constructor.newInstance(Object...) line: 526
> > DefaultPageFactory.newPage(Constructor, PageParameters) line:
> 171
> > DefaultPageFactory.newPage(Class) line: 76
> > DefaultMapperContext.newPageInstance(Class,
> PageParameters) line: 102
> > PageProvider.resolvePageInstance(Integer,
> Class, PageParameters, Integer) line: 271
> > PageProvider.getPageInstance() line: 169
> > WebPageRenderer(PageRenderer).getPage() line: 78
> > WebPageRenderer.isPageStateless() line: 287
> > WebPageRenderer.shouldRenderPageAndWriteResponse(RequestCycle,
> Url, Url) line: 329
> > WebPageRenderer.respond(RequestCycle) line: 193
> > RenderPageRequestHandler.respond(IRequestCycle) line: 175
>
> The following is the same stacktrace after a restart of Tomcat and as
> you can see, the id of the tag in EnclosureHandler is different now
> and markup is only parsed because the Enclosure instance from the page
> cache with the old id needs its child component and tries to find it
> in the markup:
>
> > wicket_enclosure12: 
>
> > Daemon Thread [http-bio-127.0.0.1-8081-exec-3] (Suspended (breakpoint at
> line 131 in EnclosureHandler))
> > owns: SocketWrapper  (id=84)
> > EnclosureHandler.onComponentTag(ComponentTag) line: 131
> > EnclosureHandler(AbstractMarkupFilter).nextElement() line: 100
> > InlineEnclosureHandler(AbstractMarkupFilter).nextElement() line:
> 95
> > ConditionalCommentFilter(AbstractMarkupFilter).nextElement()
> line: 95
> > WicketContainerTagHandler(AbstractMarkupFilter).nextElement()
> line: 95
> > RelativePathPrefixHandler(AbstractMarkupFilter).nextElement()
> line: 95
> > 

Re: Enclosure can't find its markup anymore after restart of Tomcat

[Thorsten Schöning]

Guten Tag Thorsten Schöning,
am Freitag, 11. März 2016 um 19:45 schrieben Sie:

> I tried to track this down and recognized one important difference:

The following are parts of the stacktrace after a clean startup with
a breakpoint in EnclosureHandler, where the tag has the following id
and content:

> wicket_enclosure34: 

> Daemon Thread [http-bio-127.0.0.1-8081-exec-5] (Suspended (breakpoint at line 
> 131 in EnclosureHandler))
> owns: SocketWrapper  (id=89)
> EnclosureHandler.onComponentTag(ComponentTag) line: 131
> EnclosureHandler(AbstractMarkupFilter).nextElement() line: 100
> InlineEnclosureHandler(AbstractMarkupFilter).nextElement() line: 95
> ConditionalCommentFilter(AbstractMarkupFilter).nextElement() line: 95
> WicketContainerTagHandler(AbstractMarkupFilter).nextElement() line: 95
> RelativePathPrefixHandler(AbstractMarkupFilter).nextElement() line: 95
> StyleAndScriptIdentifier(AbstractMarkupFilter).nextElement() line: 95
> MarkupFactory$1(AbstractMarkupParser).getNextTag() line: 217
> MarkupFactory$1(AbstractMarkupParser).parseMarkup() line: 232
> MarkupFactory$1(AbstractMarkupParser).parse() line: 185
> SimpleMarkupLoader.loadMarkup(MarkupContainer, MarkupResourceStream, 
> IMarkupLoader, boolean) line: 51
> InheritedMarkupMarkupLoader.loadMarkup(MarkupContainer, 
> MarkupResourceStream, IMarkupLoader, boolean) line: 57
> DefaultMarkupLoader.loadMarkup(MarkupContainer, MarkupResourceStream, 
> IMarkupLoader, boolean) line: 52
> MarkupFactory.loadMarkup(MarkupContainer, MarkupResourceStream, 
> boolean) line: 412
> MarkupCache.loadMarkup(MarkupContainer, MarkupResourceStream, 
> boolean) line: 447
> MarkupCache.loadMarkupAndWatchForChanges(MarkupContainer, 
> MarkupResourceStream, boolean) line: 543
> MarkupCache.getMarkup(MarkupContainer, Class, boolean) line: 304
> MarkupFactory.getMarkup(MarkupContainer, Class, boolean) line: 236
> MarkupFactory.getMarkup(MarkupContainer, boolean) line: 194
> PnNav(MarkupContainer).getAssociatedMarkup() line: 456
> PnNav(MarkupContainer).getRegionMarkup() line: 2224
> PnNav(Panel).getRegionMarkup() line: 96
> PnNav(MarkupContainer).newDequeueContext() line: 2211
> PnNav(MarkupContainer).dequeue() line: 2029
> WebMarkupContainer(MarkupContainer).addedComponent(Component) line: 
> 1049
> WebMarkupContainer(MarkupContainer).add(Component...) line: 239
> HomePage.(PageParameters) line: 25
> NativeConstructorAccessorImpl.newInstance0(Constructor, Object[]) 
> line: not available [native method]
> NativeConstructorAccessorImpl.newInstance(Object[]) line: 57
> DelegatingConstructorAccessorImpl.newInstance(Object[]) line: 45
> Constructor.newInstance(Object...) line: 526
> DefaultPageFactory.newPage(Constructor, PageParameters) line: 171
> DefaultPageFactory.newPage(Class) line: 76
> DefaultMapperContext.newPageInstance(Class, 
> PageParameters) line: 102
> PageProvider.resolvePageInstance(Integer, Class, 
> PageParameters, Integer) line: 271
> PageProvider.getPageInstance() line: 169
> WebPageRenderer(PageRenderer).getPage() line: 78
> WebPageRenderer.isPageStateless() line: 287
> WebPageRenderer.shouldRenderPageAndWriteResponse(RequestCycle, Url, 
> Url) line: 329
> WebPageRenderer.respond(RequestCycle) line: 193
> RenderPageRequestHandler.respond(IRequestCycle) line: 175

The following is the same stacktrace after a restart of Tomcat and as
you can see, the id of the tag in EnclosureHandler is different now
and markup is only parsed because the Enclosure instance from the page
cache with the old id needs its child component and tries to find it
in the markup:

> wicket_enclosure12: 

> Daemon Thread [http-bio-127.0.0.1-8081-exec-3] (Suspended (breakpoint at line 
> 131 in EnclosureHandler))
> owns: SocketWrapper  (id=84)
> EnclosureHandler.onComponentTag(ComponentTag) line: 131
> EnclosureHandler(AbstractMarkupFilter).nextElement() line: 100
> InlineEnclosureHandler(AbstractMarkupFilter).nextElement() line: 95
> ConditionalCommentFilter(AbstractMarkupFilter).nextElement() line: 95
> WicketContainerTagHandler(AbstractMarkupFilter).nextElement() line: 95
> RelativePathPrefixHandler(AbstractMarkupFilter).nextElement() line: 95
> StyleAndScriptIdentifier(AbstractMarkupFilter).nextElement() line: 95
> MarkupFactory$1(AbstractMarkupParser).getNextTag() line: 217
> MarkupFactory$1(AbstractMarkupParser).parseMarkup() line: 232
> MarkupFactory$1(AbstractMarkupParser).parse() line: 185
> SimpleMarkupLoader.loadMarkup(MarkupContainer, MarkupResourceStream, 
> IMarkupLoader, boolean) line: 51
> 

Enclosure can't find its markup anymore after restart of Tomcat

[Thorsten Schöning]

Hi all,

I'm using some wicket:enclosures in the navigation of my web app to
hide some content surrounding links, if the links are invisible for
some reason. This worked well with Wicket 6.0.x, but now I get the
following problem:

Consider a fresh, clean, empty Tomcat server, no wicket persistent
data whatsoever, no session, no DiskDataStore, nothing. If I now
start my app I can use it without any problems, click links, reload
pages, some enclosures are hidden, some are visible, all depending on
the visibility of the containing links, everything like I need it.

The only thing I'm doing now is restarting the Tomcat server and on
refreshing the current page in the browser I get a stackoverflow in
Enclosure while trying to determine its visibility. It tries to find
its markup, can't, which somehow leads back to where the caller came
from in AbstractMarkupSourcingStrategy#searchMarkupInTransparentResolvers
and which once again tries to find the markup with the same Enclosure
already tried before... The stackoverflow happens in my web app with
more complex HTML, but in a reduced version based on a quickstart I
don't get one, but instead the following exception is thrown:

> java.lang.IllegalArgumentException: Argument 'markup' may not be null.

So I guess the root cause is the same in both cases, Enclosure can't
find it's markup anymore.

Sadly I couldn't reproduce this with Jetty and an original quickstart,
because I don't know how to restart Jetty the same way I do with
Tomcat. If it gets stopped and started again, it generates a new
random temp working dir and starts without persistent data as well, so
the problem doesn't occur. Tomcat instead keeps some session data and
such during restarts and I guess that's part of the problem. Whenever
I clean the working dir of Tomcat, the problem is gone again until I a
restart is issued without cleaning the working dir.

I tried to track this down and recognized one important difference:

On the first empty start of Tomcat without any persistent data, the
ids recognized in EnclosureHandler for the tags are different than
after a restart of Tomcat. The numeric part of the tag ids is
incremented whenever a new tag is recognized and on the first clean
start this numeric part is simply higher, e.g. 20, than after a
restart, in which case it might be 15. This indicates that after the
restart less tags are parsed from the underlying markup compared to
the first start of the web app. Because of the wicket page cache and
such, the Enclosures with the OLD ids are still assigned to pages
after a restart, so if a subsequent process of the markup produces
different ids now, Wicket seems unable to find the OLD enclosure
ids in the markup, because the MarkupStream now contains Enclosures
with NEW ids. I could verify that in the debugger: Wicket tries to
determine visibility for Enclosure with id 20, because that was stores
in the page cache, and after a restart the logical same markup
component now has the id e.g. 15 and therefore can't be found anymore.

I think this has to do something with my HTML structure:

I have a main div as a WebMarkupContainer, which contains two Panels
on the same level, which both contains links. Only second Panel
contains the links embedded into enclosures. My feeling is that after
a restart the links of the first Panel are not parsed anymore from
their markup, because the objects where in the store already, so when
the markup for the enclosures in the second panel are parsed, the
request unique id is simply less than it was after the first clean
start without any persistent data.

I have two questions now:

1. Workaround?

I think if I'm able to get Wicket to not store any pages anymore
persistently, I could workaround the problem. I don't care if people
need to login or whatever in the worst case, but the app needs to be
functional after a restart of Tomcat without manually cleaning working
directories and such.

I already tried with a custom DefaultPageManagerProvider and
IDataStore implementation which simply doesn't store and retrieve any
data. But this is not enough, the problem still occurs.

2. Root cause?

In the end of course I need to find the root cause and would like to
fix that. How should Wicket behave in parsing markup when pages come
from the cache? Does it only parse some missing pieces of markup like
for Enclosure, because t doesn't cache it's associated markup/child
component or always everything like from a clean start? I guess the
first, but that would mean that ids always change and relying on them
during subsequent requests is not save.

Thanks for any hints!

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail: thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon...05151-  9468- 55
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: 

Re: [7.2] multiple pages Access Denied

[nino martinez wael]

IT would appear so. BUT we actually do not have a direct link between
A and B, in our testing we manually open a secondary tab and put in an
url for the mounted page B which.. After page B are loaded this error
happens on page A when the link are pressed..

On Fri, Mar 11, 2016 at 11:28 AM, Martin Grigorov  wrote:
> It looks like you have logic that changes addcontactButton's visibility or
> enable-bility in some conditions.
> Check what exactly changes when you open page B.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Fri, Mar 11, 2016 at 9:25 AM, nino martinez wael <
> nino.martinez.w...@gmail.com> wrote:
>
>> Hi
>>
>> I have something strange (as always). Two pages A and B
>>
>> If I open the two pages in the same session on two different tabs.
>> Invoking an ajax behavior (wicket modal panel) yields
>>
>> Access Denied
>>
>> stack tells me this:
>>
>> Behavior rejected interface invocation. Component: [AjaxLink
>> [Component id = addcontactButton]] Behavior:
>> org.apache.wicket.ajax.markup.html.AjaxLink$1@79f8700 Listener:
>> [RequestListenerInterface name=IBehaviorListener, method=public
>> abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()]
>>
>> If I only mess around with page A there are no problems. But opening
>> Page B in another tab apparently triggers this. It does not matter if
>> there is ajax or not on page B
>>
>>
>> --
>> Best regards / Med venlig hilsen
>> Nino Martinez
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>



-- 
Best regards / Med venlig hilsen
Nino Martinez

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: [7.2] multiple pages Access Denied

[Martin Grigorov]

It looks like you have logic that changes addcontactButton's visibility or
enable-bility in some conditions.
Check what exactly changes when you open page B.

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Fri, Mar 11, 2016 at 9:25 AM, nino martinez wael <
nino.martinez.w...@gmail.com> wrote:

> Hi
>
> I have something strange (as always). Two pages A and B
>
> If I open the two pages in the same session on two different tabs.
> Invoking an ajax behavior (wicket modal panel) yields
>
> Access Denied
>
> stack tells me this:
>
> Behavior rejected interface invocation. Component: [AjaxLink
> [Component id = addcontactButton]] Behavior:
> org.apache.wicket.ajax.markup.html.AjaxLink$1@79f8700 Listener:
> [RequestListenerInterface name=IBehaviorListener, method=public
> abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()]
>
> If I only mess around with page A there are no problems. But opening
> Page B in another tab apparently triggers this. It does not matter if
> there is ajax or not on page B
>
>
> --
> Best regards / Med venlig hilsen
> Nino Martinez
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

[7.2] multiple pages Access Denied

[nino martinez wael]

Hi

I have something strange (as always). Two pages A and B

If I open the two pages in the same session on two different tabs.
Invoking an ajax behavior (wicket modal panel) yields

Access Denied

stack tells me this:

Behavior rejected interface invocation. Component: [AjaxLink
[Component id = addcontactButton]] Behavior:
org.apache.wicket.ajax.markup.html.AjaxLink$1@79f8700 Listener:
[RequestListenerInterface name=IBehaviorListener, method=public
abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()]

If I only mess around with page A there are no problems. But opening
Page B in another tab apparently triggers this. It does not matter if
there is ajax or not on page B


-- 
Best regards / Med venlig hilsen
Nino Martinez

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org