_extend48 - ring any bells?

[Wayne W]

Hi,

I've got a problem in production whereby our application home page
throws a :Unable to find component with id 'mainPanel' in
[MarkupContainer [Component id = _extend48]]

This only happens once or twice a week. We don't have any components
named '_extend48' or similar anywhere in the code. Whats odd is that
this page renders 99% of the time fine, but for the life of me I
cannot understand how this can happen.

Is the component id given a red herring? Any ideas on how I can find
out what causes this?

thanks

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

Re: _extend48 - ring any bells?

[Wayne W]

  /li
73  li
class=userDefinedBg
74  
a class=add_link announcements
wicket:id=switchAnnoncementsLinkspan
wicket:id=switchLabelsiwtch new/old announcements/span/a
75  /li
76  
wicket:enclosure
77  li
class=userDefinedBg
78  a
class=add_link newcube wicket:id=addCubeswicket:message
key=company.newCubeCreate a new Cube/wicket:message/a
79  /li
80  
/wicket:enclosure
81  li
class=expandable userDefinedBg
82  
div class=subscribe  wicket:id=subscribe/div
83  /li
84  
85  /ul
86  div
class=spacer/div
87  /div
88  div
class=contentBlock_bottomspan
class=right_endspan/span/span/div
89  
90  
91  
92  
93  h2
class=userDefinedBgspan class=right_endspan
class=startwicket:message key=company.hotstuffHot
Stuff/wicket:message/span/span/h2
94  div 
class=contentBox_body
95  div
class=contentBlock
96  div
wicket:id=hotStuff/div
97  div
class=spacer/div
98  /div
99  div
class=contentBlock_bottomspan
class=right_endspan/span/span/div
100 /div
101 
102 
103 
104 
105 
106 h2 class=userDefinedBg
filter wicket:id=workspaceFilterContainer
107 
spanwicket:container wicket:id=cubesTitleAll
Cubes/wicket:container/span
108 div class=filter 
109 a href=
wicket:id=filterCubes wicket:container wicket:id=filterTextMe
as member/wicket:container/a
110 span
class=loading spinner wicket:id=workspaceSpinnerContainer
style=display:nonenbsp;img src=images/icons/throbber.gif
//span
111 /div
112 /h2
113 div
class=contentBox_body
114 div
class=contentBlock wicket:id=allProjectsContainer
115 div
wicket:id=allProjects/div
116   div
class=spacer/div
117 /div
118 div
class=contentBlock_bottomspan
class=right_endspan/span/span/div
119 /div
120 
121 /div
122 /div
123 /wicket:panel
124 /body
125 /html

On Tue, Oct 19, 2010 at 7:50 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
 Would you show the html of this mainpanel and also its super panel?

 **
 Martin

 2010/10/19 Wayne W waynemailingli...@gmail.com:
 Hi,

 I've got a problem in production whereby our application home page
 throws a :Unable to find component with id 'mainPanel' in
 [MarkupContainer [Component id = _extend48]]

 This only happens once or twice a week. We don't have any components
 named '_extend48' or similar anywhere in the code. Whats odd is that
 this page renders 99% of the time fine, but for the life of me I
 cannot understand how this can happen.

 Is the component id given a red herring? Any ideas on how I can find
 out what causes this?

 thanks

 -
 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

Re: _extend48 - ring any bells?

[Wayne W]

Hi Jeremy,

 That is the id for the wicket extend tag in your markup

This might be a stupid question - but can I tell where in the page
this might be causing the problem from the _extend38? Is that the 38th
extend for example?
Any hints on how I can track this down?

thanks


On Tue, Oct 19, 2010 at 7:47 PM, Jeremy Thomerson
jer...@wickettraining.com wrote:
 That is the id for the wicket extend tag in your markup

 Jeremy Thomerson
 http://wickettraining.com
 -- sent from my smart phone, so please excuse spelling, formatting, or
 compiler errors

 On Oct 19, 2010 12:46 PM, Wayne W waynemailingli...@gmail.com wrote:

 Hi,

 I've got a problem in production whereby our application home page
 throws a :Unable to find component with id 'mainPanel' in
 [MarkupContainer [Component id = _extend48]]

 This only happens once or twice a week. We don't have any components
 named '_extend48' or similar anywhere in the code. Whats odd is that
 this page renders 99% of the time fine, but for the life of me I
 cannot understand how this can happen.

 Is the component id given a red herring? Any ideas on how I can find
 out what causes this?

 thanks

 -
 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: _extend48 - ring any bells?

[Wayne W]

Here's the code for the CompanyPage (the first panel)

public class CompanyPage extends DashboardMenuPage {

public CompanyPage() {
super(CompanySelected.dashboard);

if (ContextUtil.get().getUser() instanceof ExternalUser) {
TeamProject[] projs =
ContextUtil.get().getUser().getProjects().toArray(new TeamProject[0]);

if (projs.length == 0) {
User admin =
ServiceLocator.getUserService().getFirstAdmin(ContextUtil.get().getCompany());
String body = 
getString(noworkspace.message.body);
body = body.replace({0}, admin.getEmail());
setResponsePage(new
MessagePage(getString(noworkspace.message.title), body));
} else {
setResponsePage(new ProjectPage(new
HibernateEntityModelTeamProject(projs[0])));
}

return;
}

// perhaps they have configured their look and feel not to have 
the dashboard
// if not redirect to the All workspace page
if 
(!ContextUtil.get().getCompany().getGeneralSettings().isShowMyDashboard())
{
throw new RestartResponseException(new 
WorkspacesPage());
}

add(new CompanyDashboardPanel(mainPanel));
}

public CompanyPage(PageParameters params) {
super(CompanySelected.dashboard);
if (params.get(PostingLinkBuildingStrategy.POSTINGID) != null) {
IModelPosting postingModel = new
HibernateEntityModelPosting(Posting.class,
params.getLong(PostingLinkBuildingStrategy.POSTINGID));
add(new PostingDetailPanel(mainPanel, postingModel));
} else {
add(new CompanyDashboardPanel(mainPanel));
}
}


}


The second depends on the context, so thats a lot fo code to copy and
paste . Something that looks wrong here is calling setResponsePage
directly in the constructor rather than using
RestartResponseException. However calling setResponsePage does seem to
work fine - could it cause this issue?

What could I look for here?
many thanks
On Wed, Oct 20, 2010 at 4:58 PM, Jeremy Thomerson
jer...@wickettraining.com wrote:
 On Wed, Oct 20, 2010 at 5:12 AM, Wayne W waynemailingli...@gmail.comwrote:

 Hi Jeremy,

  That is the id for the wicket extend tag in your markup

 This might be a stupid question - but can I tell where in the page
 this might be causing the problem from the _extend38? Is that the 38th
 extend for example?
 Any hints on how I can track this down?


 Show us the java code for the two panels that you sent HTML for.

 --
 Jeremy Thomerson
 http://wickettraining.com
 *Need a CMS for Wicket?  Use Brix! http://brixcms.org*


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

Re: FileUpload in ModalWindow

[Wayne W]

We're on 1.4.7 currently and when I tried 1.4.11 we had a few issues
with ajax - unfortunality we've not had time to really try and
understand the issue.
I'll be interested if anyone else is having a problem.
I know there was some work done in the ajax area, but I'm not sure
where to start looking.

On Tue, Nov 2, 2010 at 10:45 AM, Stefan Lindner lind...@visionet.de wrote:
 To make it more clear: FileUpload with ProgressBar does not work at all for 
 me.  Not in FF not in IE. Without ProgressBar everything works well.
 This is a Problem since 1.4.11. In 1.4.10 it works well.

 Stefan


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

Firefox : ServletRequest does not contain multipart content

[Wayne W]

Hi,

we see this error time to time in production, and one of use here got
the problem ourselves.

We have a Form set to multipart true and a FileUploadField and
SubmitLink amongst some other fields, however there is no ajax submit.
This works 99% of the time it seems.

Now this happened using Firefox, Nick here selected the file on his
computer and hit submit, he said the browser took about 10 secs or so
then he got the error page (with the below stack) trace, and then when
back to the Form and tried again - this time is uploaded the image
file and refresh the page correctly in about 2 seconds.

Does anyone have a clue what could cause this? We're seeing them in production.


Caused by: java.lang.IllegalStateException: ServletRequest does not
contain multipart content. One possible solution is to explicitly call
Form.setMultipart(true), Wicket tries its best to auto-detect
multipart forms but there are certain situation where it cannot.
at 
org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.init(MultipartServletWebRequest.java:113)
at 
org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.init(MultipartServletWebRequest.java:83)
at 
org.apache.wicket.extensions.ajax.markup.html.form.upload.MultipartRequest.init(MultipartRequest.java:41)
at 
org.apache.wicket.extensions.ajax.markup.html.form.upload.UploadWebRequest.newMultipartWebRequest(UploadWebRequest.java:66)
at 
org.apache.wicket.markup.html.form.Form.handleMultiPart(Form.java:1668)
at 
org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:862)
... 32 more
2010-11-04 15:07:32,053 ERROR -
hub.app.wicket.app.HubWebRequestCycle.onRuntimeException(HubWebRequestCycle.java:67)
67 HubWebRequestCycle - Runtime Exception!
org.apache.wicket.WicketRuntimeException: Method onFormSubmitted of
interface org.apache.wicket.markup.html.form.IFormSubmitListener
targeted at component [MarkupContainer [Component id = form]] threw an
exception
at 
org.apache.wicket.RequestListenerInterface.invoke(RequestListenerInterface.java:193)
at 
org.apache.wicket.request.target.component.listener.ListenerInterfaceRequestTarget.processEvents(ListenerInterfaceRequestTarget.java:73)
at 
org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92)
at 
org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1250)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
at 
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:479)
at 
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:312)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
com.wideplay.warp.persist.PersistenceFilter$3.run(PersistenceFilter.java:141)
at 
com.wideplay.warp.persist.internal.Lifecycles.failEarlyAndLeaveNoOneBehind(Lifecycles.java:29)
at 
com.wideplay.warp.persist.PersistenceFilter.doFilter(PersistenceFilter.java:155)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)

  308166,2-999%
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:769)
at 
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:698)
at 
org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:891)
at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
at java.lang.Thread.run(Thread.java:619)

Ajax response render as source in the browser

[Wayne W]

Hi,

has anyone had this issue? We're getting emails from our users that
sometime when clicking on an ajax link the raw wicket ajax response is
being rendered on the browser - ie the just see all the html source
code on the page. Its not any particular page.

Anyone seen this or has any ideas?


The only thing we have changed recently was adding a non blocking file
download using a link and a shared resource which could be related due
to the Content Type.
In the configureResponse of the shared resource that we set the
Content Type for that request. Is there any chance that this is
somehow polluting the other threads requests?

public class DownloadFileResourceReference extends ResourceReference {
public DownloadFileResourceReference() {
super(DownloadLink.class, );
}

private static final long serialVersionUID = 1L;

public Resource newResource() {

Resource r =  new Resource() {
private static final long serialVersionUID = 1L;

public IResourceStream getResourceStream() {

Long id = 
getParameters().getLong(DownloadLink.DOCID);
// get file

return new FileResourceStream(new 
File(file.getAbsolutePath()));
}


protected void configureResponse(Response response) {

Long id = 
getParameters().getLong(DownloadLink.DOCID);

// get file

((WebResponse) 
response).setAttachmentHeader(df.getFileName());

String mimeType = 
ResourceHelper.getContentType(df.getFileName());
if (!StringUtils.isEmpty(mimeType)) {
((WebResponse) 
response).setContentType(mimeType);
}

}

};
r.setCacheable(false);
return r;
}

}

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

Re: Ajax response render as source in the browser

[Wayne W]

Hi Igor,

Whats odd is that one guy was getting it on his iPad consistently and
when we asked him to try his desktop he's got the same problem on
Firefox on Mac. We initially though it might have been a browser
issue. We then got another user who got it only once on Chrome on
windows - all in the space of 1 day. We're worried that's it happening
more often but users are not reporting the issue.

Of course we cannot reproduce the issue, but its definitely happening.

So you don;t think the shared resource could effect the threads in any way?

Where can I start looking in the wicket code to understand where ajax
requests are serviced etc? Is there any where/docs I can find to get
started at looking at this? -  at least to complete more my
understanding of how it all works.

thanks
Wayne

On Fri, Nov 5, 2010 at 10:05 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
 it may be a content type issue, but it is still weird because the
 response is received by the xml http request object, not the browser
 directly. strange indeed.

 -igor

 On Fri, Nov 5, 2010 at 7:51 AM, Wayne W waynemailingli...@gmail.com wrote:
 Hi,

 has anyone had this issue? We're getting emails from our users that
 sometime when clicking on an ajax link the raw wicket ajax response is
 being rendered on the browser - ie the just see all the html source
 code on the page. Its not any particular page.

 Anyone seen this or has any ideas?


 The only thing we have changed recently was adding a non blocking file
 download using a link and a shared resource which could be related due
 to the Content Type.
 In the configureResponse of the shared resource that we set the
 Content Type for that request. Is there any chance that this is
 somehow polluting the other threads requests?

 public class DownloadFileResourceReference extends ResourceReference {
        public DownloadFileResourceReference() {
                super(DownloadLink.class, );
        }

        private static final long serialVersionUID = 1L;

        public Resource newResource() {

                Resource r =  new Resource() {
                        private static final long serialVersionUID = 1L;

                        public IResourceStream getResourceStream() {

                                        Long id = 
 getParameters().getLong(DownloadLink.DOCID);
                                        // get file

                                        return new FileResourceStream(new 
 File(file.getAbsolutePath()));
                        }


                        protected void configureResponse(Response response) {

                                Long id = 
 getParameters().getLong(DownloadLink.DOCID);

                                // get file

                                ((WebResponse) 
 response).setAttachmentHeader(df.getFileName());

                                String mimeType = 
 ResourceHelper.getContentType(df.getFileName());
                                if (!StringUtils.isEmpty(mimeType)) {
                                        ((WebResponse) 
 response).setContentType(mimeType);
                                }

                        }

                };
                r.setCacheable(false);
                return r;
        }

 }

 -
 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: Ajax response render as source in the browser

[Wayne W]

thanks Igor,

I've just spent a few hours stepping though the code and I cannot see
anyway the content type could be set wrong - I see the content type is
set in the final respond(requestCycle) method, so I'm now thinking
this is not a content type issue.

However we just got another user email with a screen shot showing the
wicket ajax-response in the browser so something is up.

My javascript knowledge is weak at best so I've not been able to tell
much from the js .

Any ideas on how we can resolve this or at least get more info?
many thanks




On Sat, Nov 6, 2010 at 6:40 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
 see AjaxRequestTarget class, this is where the response is generated
 on the serverside

 wicket-ajax.js is where it is processed on the client side.

 -igor

 On Sat, Nov 6, 2010 at 2:49 AM, Wayne W waynemailingli...@gmail.com wrote:
 Hi Igor,

 Whats odd is that one guy was getting it on his iPad consistently and
 when we asked him to try his desktop he's got the same problem on
 Firefox on Mac. We initially though it might have been a browser
 issue. We then got another user who got it only once on Chrome on
 windows - all in the space of 1 day. We're worried that's it happening
 more often but users are not reporting the issue.

 Of course we cannot reproduce the issue, but its definitely happening.

 So you don;t think the shared resource could effect the threads in any way?

 Where can I start looking in the wicket code to understand where ajax
 requests are serviced etc? Is there any where/docs I can find to get
 started at looking at this? -  at least to complete more my
 understanding of how it all works.

 thanks
 Wayne

 On Fri, Nov 5, 2010 at 10:05 PM, Igor Vaynberg igor.vaynb...@gmail.com 
 wrote:
 it may be a content type issue, but it is still weird because the
 response is received by the xml http request object, not the browser
 directly. strange indeed.

 -igor

 On Fri, Nov 5, 2010 at 7:51 AM, Wayne W waynemailingli...@gmail.com wrote:
 Hi,

 has anyone had this issue? We're getting emails from our users that
 sometime when clicking on an ajax link the raw wicket ajax response is
 being rendered on the browser - ie the just see all the html source
 code on the page. Its not any particular page.

 Anyone seen this or has any ideas?


 The only thing we have changed recently was adding a non blocking file
 download using a link and a shared resource which could be related due
 to the Content Type.
 In the configureResponse of the shared resource that we set the
 Content Type for that request. Is there any chance that this is
 somehow polluting the other threads requests?

 public class DownloadFileResourceReference extends ResourceReference {
        public DownloadFileResourceReference() {
                super(DownloadLink.class, );
        }

        private static final long serialVersionUID = 1L;

        public Resource newResource() {

                Resource r =  new Resource() {
                        private static final long serialVersionUID = 1L;

                        public IResourceStream getResourceStream() {

                                        Long id = 
 getParameters().getLong(DownloadLink.DOCID);
                                        // get file

                                        return new FileResourceStream(new 
 File(file.getAbsolutePath()));
                        }


                        protected void configureResponse(Response response) 
 {

                                Long id = 
 getParameters().getLong(DownloadLink.DOCID);

                                // get file

                                ((WebResponse) 
 response).setAttachmentHeader(df.getFileName());

                                String mimeType = 
 ResourceHelper.getContentType(df.getFileName());
                                if (!StringUtils.isEmpty(mimeType)) {
                                        ((WebResponse) 
 response).setContentType(mimeType);
                                }

                        }

                };
                r.setCacheable(false);
                return r;
        }

 }

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



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



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



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

Re: Ajax response render as source in the browser

[Wayne W]

 the browser. do you have a proxy between the servlet container and the
 outside? maybe something is injecting a redirect or something weird.

I did wonder if there was weird redirect issue, but after doing a lot
of reading yesterday it seems the xmlrequest object *should* handle
redirects fine. However either way we're not doing anything like that.
We've got a couple of tomcat instances load balanced through apache,
routed via a hardware firewall and out of the datacenter, so no
proxies or anything at least I'm aware of.

Its very frustrating.



On Sun, Nov 7, 2010 at 9:41 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
 the only way i can see that happenning if the url is no longer
 processed by wicket's ajax support and so the response just ends up in
 the browser. do you have a proxy between the servlet container and the
 outside? maybe something is injecting a redirect or something weird.

 -igor

 On Sun, Nov 7, 2010 at 8:26 AM, Wayne W waynemailingli...@gmail.com wrote:
 thanks Igor,

 I've just spent a few hours stepping though the code and I cannot see
 anyway the content type could be set wrong - I see the content type is
 set in the final respond(requestCycle) method, so I'm now thinking
 this is not a content type issue.

 However we just got another user email with a screen shot showing the
 wicket ajax-response in the browser so something is up.

 My javascript knowledge is weak at best so I've not been able to tell
 much from the js .

 Any ideas on how we can resolve this or at least get more info?
 many thanks




 On Sat, Nov 6, 2010 at 6:40 PM, Igor Vaynberg igor.vaynb...@gmail.com 
 wrote:
 see AjaxRequestTarget class, this is where the response is generated
 on the serverside

 wicket-ajax.js is where it is processed on the client side.

 -igor

 On Sat, Nov 6, 2010 at 2:49 AM, Wayne W waynemailingli...@gmail.com wrote:
 Hi Igor,

 Whats odd is that one guy was getting it on his iPad consistently and
 when we asked him to try his desktop he's got the same problem on
 Firefox on Mac. We initially though it might have been a browser
 issue. We then got another user who got it only once on Chrome on
 windows - all in the space of 1 day. We're worried that's it happening
 more often but users are not reporting the issue.

 Of course we cannot reproduce the issue, but its definitely happening.

 So you don;t think the shared resource could effect the threads in any way?

 Where can I start looking in the wicket code to understand where ajax
 requests are serviced etc? Is there any where/docs I can find to get
 started at looking at this? -  at least to complete more my
 understanding of how it all works.

 thanks
 Wayne

 On Fri, Nov 5, 2010 at 10:05 PM, Igor Vaynberg igor.vaynb...@gmail.com 
 wrote:
 it may be a content type issue, but it is still weird because the
 response is received by the xml http request object, not the browser
 directly. strange indeed.

 -igor

 On Fri, Nov 5, 2010 at 7:51 AM, Wayne W waynemailingli...@gmail.com 
 wrote:
 Hi,

 has anyone had this issue? We're getting emails from our users that
 sometime when clicking on an ajax link the raw wicket ajax response is
 being rendered on the browser - ie the just see all the html source
 code on the page. Its not any particular page.

 Anyone seen this or has any ideas?


 The only thing we have changed recently was adding a non blocking file
 download using a link and a shared resource which could be related due
 to the Content Type.
 In the configureResponse of the shared resource that we set the
 Content Type for that request. Is there any chance that this is
 somehow polluting the other threads requests?

 public class DownloadFileResourceReference extends ResourceReference {
        public DownloadFileResourceReference() {
                super(DownloadLink.class, );
        }

        private static final long serialVersionUID = 1L;

        public Resource newResource() {

                Resource r =  new Resource() {
                        private static final long serialVersionUID = 1L;

                        public IResourceStream getResourceStream() {

                                        Long id = 
 getParameters().getLong(DownloadLink.DOCID);
                                        // get file

                                        return new FileResourceStream(new 
 File(file.getAbsolutePath()));
                        }


                        protected void configureResponse(Response 
 response) {

                                Long id = 
 getParameters().getLong(DownloadLink.DOCID);

                                // get file

                                ((WebResponse) 
 response).setAttachmentHeader(df.getFileName());

                                String mimeType = 
 ResourceHelper.getContentType(df.getFileName());
                                if (!StringUtils.isEmpty(mimeType)) {
                                        ((WebResponse) 
 response).setContentType(mimeType

Tree - component nodeLink not found on page

[Wayne W]

Hi,

we recently introduced a extensions.markup.html.tree.Tree component in
our product.
However we're seeing some errors in production where the nodeLink in
the component cannot be found in the page.

In our onNodeLinkClicked we just perform a setResponsePage with a
bookmarkable page.

I've done a lot of searching around this issue and it seems the main
culprits are invalid html or the browser caching something.

However we - alas - cannot reproduce this in any way.

How does this work? - is it basically telling me that that link
(nodeLink) has activity been removed from the page by are code
somewhere, however the url has code our of sync with our state on the
server? is that right?

thanks

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

Re: mobile Apllication via Wicket

[Wayne W]

We use the excellent wurfl open source project to help us out with devices.


On Wed, Nov 10, 2010 at 3:49 PM, jcgarciam jcgarc...@gmail.com wrote:

 In server side, just check the User-Agent header from your HttpRequest.


 On Wed, Nov 10, 2010 at 11:41 AM, Madlip89 [via Apache Wicket] 
 ml-node+3036192-1884488973-65...@n4.nabble.comml-node%2b3036192-1884488973-65...@n4.nabble.com
 wrote:

 Hey everyone,

 i must started a apllication with wicket.

 This is a Web-Application. A must find out, Who send the Request?
 (SmartPhones or Desctop PC)

 I started this with a Javascript that's call by browserdetect. Now I'm
 searching a way to realise that's in wicket. Can u help me, from what object
 or variable i get this information?

 please.

 thank u

 Madlip

 --
  View message @
 http://apache-wicket.1842946.n4.nabble.com/mobile-Apllication-via-Wicket-tp3036192p3036192.html
 To start a new topic under Apache Wicket, email
 ml-node+1842946-398011874-65...@n4.nabble.comml-node%2b1842946-398011874-65...@n4.nabble.com
 To unsubscribe from Apache Wicket, click 
 herehttp://apache-wicket.1842946.n4.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_codenode=1842946code=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/mobile-Apllication-via-Wicket-tp3036192p3036212.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



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

UploadProgressBar alternative that supports Chrome and Safari?

[Wayne W]

Hi,

I just want to check that there isn't an alternative out there already
that someone has done that supports webkit browsers?
We're finding nearly 20% of our users now are on these browsers so we
must support them better, hence why we're looking at alternatives.

If not we'll have to write something ourselves - I looked at the
current code, but cannot figure out a way of patching that.

thanks!

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

Re: UploadProgressBar alternative that supports Chrome and Safari?

[Wayne W]

Wow thanks Zilvnas - that looks great.

How on earth does it calculate the progress? very clever.


On Wed, Dec 8, 2010 at 4:08 PM, Zilvinas Vilutis cika...@gmail.com wrote:
 I use this AJAX uploader: http://valums.com/ajax-upload/

 Žilvinas Vilutis

 Mobile:   (+370) 652 38353
 E-mail:   cika...@gmail.com



 On Wed, Dec 8, 2010 at 7:46 AM, Martin Grigorov mgrigo...@apache.org wrote:
 On Wed, Dec 8, 2010 at 3:18 PM, Wayne W waynemailingli...@gmail.com wrote:

 Hi,

 I just want to check that there isn't an alternative out there already
 that someone has done that supports webkit browsers?
 We're finding nearly 20% of our users now are on these browsers so we
 must support them better, hence why we're looking at alternatives.

 If not we'll have to write something ourselves - I looked at the
 current code, but cannot figure out a way of patching that.

 Download Wicket source = patch it locally = test it against any browser =
 attach the patch in Jira ticket and it will be incorporated for the next
 versions of Wicket ;-)


 thanks!

 -
 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: Ajax response render as source in the browser

[Wayne W]

Hello everyone,

I thought you might be interested. At the weekend I experienced this
problem myself on my local machine, so I had the chance to debug and
figure what was happening.

The short version is 99.9% sure its a javascript engine bug on Firefox
(and we've had a couple of users say they had it on Chome). The only
way to 'fix' the issue was to clear all cached data from the browser.
Restarting the browser or the server made no difference. I will report
this to Mozilla today.

Luckily I could consistently make it fail and succeed so I could debug
and trace exactly what was happening. I don't know if thus is
something to do with the URL format of the request (I very much doubt
it) but its odd that this has never been reported before, but clearly
it wasn't working for use and for some of our users.

We observed the following:

GOOD REQUEST

We could set break points in the wicket-ajax.js and step though it
until the Request.doGet line 841 where transport.send(null) is called.
The headers where:

Response Headers
Content-Typetext/xml; charset=utf-8
Pragma  no-cache
Cache-Control   no-cache, must-revalidate
Expires Mon, 26 Jul 1997 05:00:00 GMT
Content-Length  3346
Server  Jetty(6.1.4)

Request Headers
Hostfoo7.glasscubesdev.com:8080
User-Agent  Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB;
rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729;
.NET4.0C)
Accept  text/xml
Accept-Language 
en-gb,en-us;q=0.9,de;q=0.8,es;q=0.7,pl;q=0.6,hu;q=0.4,nl;q=0.3,sv-se;q=0.2,en;q=0.1
Accept-Encoding gzip,deflate
Accept-Charset  ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive  115
Connection  keep-alive
Wicket-Ajax true
Wicket-FocusedElementId changeBillingAddress177
Referer http://foo7.glasscubesdev.com:8080/?wicket:interface=:20
Cookie  JSESSIONID=1vsuz0qz6v33o



Now for the BAD REQUEST

At first none of the break points in the javascript would hit at all ,
we'd click on the ajaxlink and immediately we would see the ajax
response from the server in the browser window and the URL in the
address bar as:
http://foo7.glasscubesdev.com:8080/?wicket:interface=:44:changeBillingAddress::IBehaviorListener:0:random=0.7035102055608244

So we knew the javascript must of been running as the random parameter
was different each time it failed.
I then realised that I needed to 're-set' the break points in the
wicket-ajax.js again. It seems that firefug was treating the js file
as a different file when on the failing request versus the good
request. Anyhow once I realised that I could step through it again to
the same line in the Request::doGet(). At this point we got the
behaviour as described before with the URL in the browser and the ajax
response in the page. Looking at the headers we can see:

Response Headers
Content-Typetext/xml; charset=utf-8
Expires Mon, 26 Jul 1997 05:00:00 GMT
Cache-Control   no-cache, must-revalidate
Pragma  no-cache
Content-Length  3346
Server  Jetty(6.1.4)

Request Headers
Hostfoo7.glasscubesdev.com:8080
User-Agent  Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB;
rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729;
.NET4.0C)
Accept  text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language 
en-gb,en-us;q=0.9,de;q=0.8,es;q=0.7,pl;q=0.6,hu;q=0.4,nl;q=0.3,sv-se;q=0.2,en;q=0.1
Accept-Encoding gzip,deflate
Accept-Charset  ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive  115
Connection  keep-alive
Cookie  JSESSIONID=1vsuz0qz6v33o


The wicket specific headers and content type are not there, even
though the code was explicitly setting them just before the call to
transport send.
Our only conclusion is that is must be a javascript engine bug, we
just surprised this has never reported before as its not a wicket bug
.



On Tue, Nov 16, 2010 at 5:29 PM, Wayne W waynemailingli...@gmail.com wrote:
 Hello,

 we've upgraded the apache to 2.2.15 in production and this made no difference.
 However today we got a screen shot from one client who has been having
 the issue see:

 https://home.glasscubes.com/share/code/8a8c7ecf37fe9d95cefaf787529b0828
 (you'll need to download to see the details of the URL)

 What's really odd about this is that it looks like the browser is
 doing a HTTP GET rather than using the xml request object - you can
 plainly see in the browser the URL. Looking at the code for the
 onclick event it looks (to me normal) (see below).

 Anyone got any further ideas on this? Its like the wicketAjaxGet is
 literally doing a GET!


 a onclick=if (document.getElementById('spinnerContainere'))
 (document.getElementById('spinnerContainere')).style.display =
 'inline';if (document.getElementById('filterEverythingc'))
 (document.getElementById('filterEverythingc')).disabled = true;var
 wcall=wicketAjaxGet('../?wicket:interface=:1:mainPanel:filterContainer:filterEverything::IBehaviorListener:0:1',function()
 { if (document.getElementById('spinnerContainere')) {
 (document.getElementById('spinnerContainere')).style.display

Is there anyway to get a bookmarkable url from calling setResponsePage?

[Wayne W]

Hi,

I love using wicket (1.4) its by far the best web framework for java I
have used. However the one thing that really is hard work is the url
handling for me.

Our users all the time want to copy and paste the url of a given page
in to an email or use in a comment to link to something in the app.
We've tried making as many links bookmarkable as possible but this
only works until they click on another link/action and then the url is
lost.

I have 2 questions:

1 - is there a way to have a bookmarkable url from using a
setResponsePage? Basically we have a tree view, and when one of the
nodes is click via ajax I want to redirect them to a given page.
However I want that page's URL in the browser to be bookmarkable so
they can copy and paste the url. Is there any way of doing this? I've
mounted the page using MixedParamUrlCodingStrategy but this doesn't
work.

2- is there a better strategy to having all url's bookmarkable
(providing the page supports pageparamters)? Are there any changes in
wicket 1.5 to make life more easy?

thanks

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

Re: Is there anyway to get a bookmarkable url from calling setResponsePage?

[Wayne W]

thanks Martijn,
I was looking at someone's else code and it was :
params.add(PROJECTID, info.getId().toString());
setResponsePage(new =ProjectPage(params));


rather than:
params.add(PROJECTID, info.getId().toString());
setResponsePage(ProjectPage.class, params);


Need coffee.
Sorry about that. Thanks for the pointer to wicket-annot - looks interesting

Another question if you don't mind? Quite often we have a bookmarkable
page with a form or link on it. This form/link will update the model
and redisplay the current page. When this happens we loose the
bookmarkable url. At the end of the onSubmit, or onClick we don't call
setResponsePage. Should be call setResponsePage to get the
bookmarkable url?


On Wed, Feb 9, 2011 at 10:10 AM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
 On Wed, Feb 9, 2011 at 9:37 AM, Wayne W waynemailingli...@gmail.com wrote:
 2- is there a better strategy to having all url's bookmarkable
 (providing the page supports pageparamters)? Are there any changes in
 wicket 1.5 to make life more easy?

 Default constructor or constructor with pageparameters: you can take a
 look at wicket-annot from wicketstuff core

 Martijn

 -
 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

Forms marked as multipart do not work with ajax and IE9

[Wayne W]

Hi,

We have a form that you can make comments in against something. This
is submitted normally via a AjaxSubmitLink, however if you attach a
file to the form then then form is submitted in a normal non-ajax
request.
The problem I'm seeing is if a form is marked as multipart/form-data
then is submited via ajax IE9 fails with :

Wicket.Ajax.Call.failure: Error while parsing response: Could not find
root ajax-response

IE8 and 7 work fine. Doing some debugging in IE9 versus FF I see that
in handleMultipartComplete() that the envelope is of type
DispHTMLDocument instead of XMLDocument

I'm now trying to work around the problem by removing the enctype
attribute if doing an ajax request.

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

Re: Ajax Response xml showing in browser

[Wayne W]

Hi Jeremy,

did you find a solution as we've had the problem for a long time now
and more and more people are reporting it as they move over to FF and
Chrome?


On Tue, Jan 25, 2011 at 3:39 AM, Jeremy Thomerson
jer...@wickettraining.com wrote:
 Perhaps this thread will help:
 http://apache-wicket.1842946.n4.nabble.com/Ajax-response-render-as-source-in-the-browser-tt3028722.html

 --
 Jeremy Thomerson
 http://wickettraining.com
 *Need a CMS for Wicket?  Use Brix! http://brixcms.org*

 On Mon, Jan 24, 2011 at 9:48 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote:

 please attach a quickstart that reproduce it to a jira issue.

 -igor

 On Sun, Jan 23, 2011 at 10:40 PM, Jeffrey Schneller
 jeffrey.schnel...@envisa.com wrote:
  Got an odd issue occurring where the Ajax Response xml is showing in the
  browser rather than modifying the DOM of the page as it usually does.
  The scenario is the following:
 
 
 
  My Login page is abstract and has an abstract method called
  onLoginSuccess.
 
  When the login is successful we call onLoginSuccess.
 
 
 
 
 
  Abstract Class called LoginLink which extends AjaxLink
 
  LoginLink has an abstract method called onSuccess() and
  onAlreadyLoggedIn()
 
  The Login page is constructed and has it's abstract method
  onLoginSuccess defined to call onSuccess()
 
  The onClick method of LoginLink does a setResponsePage to my Login page
  if not already logged in and calls onAlreadyLoggedIn() if the user is
  already logged into the site.
 
 
 
  I have a page called Page1 which contains a LoginLink.
 
  The onSuccess() method is defined to setResponsePage() to the page I
  ultimately need to go to say Page2.
 
  The onAlreadyLoggedIn() method is defined to setResponsePage() to the
  page I ultimately need to go to say Page2.
 
 
 
  On Page2, there are AjaxButtons to submit forms.  If any button is
  clicked I get the AjaxResponse xml showing in the browser window.
 
 
 
  Any ideas on how to solve this?   Is there another way of doing this
  interaction with built in wicket components.
 
 
 
  Thanks.
 
 
 
  Jeff
 
 
 
 
 
 

 -
 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: Ajax response render as source in the browser

[Wayne W]

just to say we still have this issue and its getting more and more
worse as people are moving to FF and Chrome.
We have no idea how to solve as we cannot reproduce it consistently.

On Mon, Dec 13, 2010 at 8:41 PM, Wayne W waynemailingli...@gmail.com wrote:
 Hello everyone,

 I thought you might be interested. At the weekend I experienced this
 problem myself on my local machine, so I had the chance to debug and
 figure what was happening.

 The short version is 99.9% sure its a javascript engine bug on Firefox
 (and we've had a couple of users say they had it on Chome). The only
 way to 'fix' the issue was to clear all cached data from the browser.
 Restarting the browser or the server made no difference. I will report
 this to Mozilla today.

 Luckily I could consistently make it fail and succeed so I could debug
 and trace exactly what was happening. I don't know if thus is
 something to do with the URL format of the request (I very much doubt
 it) but its odd that this has never been reported before, but clearly
 it wasn't working for use and for some of our users.

 We observed the following:

 GOOD REQUEST

 We could set break points in the wicket-ajax.js and step though it
 until the Request.doGet line 841 where transport.send(null) is called.
 The headers where:

 Response Headers
 Content-Type    text/xml; charset=utf-8
 Pragma  no-cache
 Cache-Control   no-cache, must-revalidate
 Expires Mon, 26 Jul 1997 05:00:00 GMT
 Content-Length  3346
 Server  Jetty(6.1.4)

 Request Headers
 Host    foo7.glasscubesdev.com:8080
 User-Agent      Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB;
 rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729;
 .NET4.0C)
 Accept  text/xml
 Accept-Language 
 en-gb,en-us;q=0.9,de;q=0.8,es;q=0.7,pl;q=0.6,hu;q=0.4,nl;q=0.3,sv-se;q=0.2,en;q=0.1
 Accept-Encoding gzip,deflate
 Accept-Charset  ISO-8859-1,utf-8;q=0.7,*;q=0.7
 Keep-Alive      115
 Connection      keep-alive
 Wicket-Ajax     true
 Wicket-FocusedElementId changeBillingAddress177
 Referer http://foo7.glasscubesdev.com:8080/?wicket:interface=:20
 Cookie  JSESSIONID=1vsuz0qz6v33o



 Now for the BAD REQUEST

 At first none of the break points in the javascript would hit at all ,
 we'd click on the ajaxlink and immediately we would see the ajax
 response from the server in the browser window and the URL in the
 address bar as:
 http://foo7.glasscubesdev.com:8080/?wicket:interface=:44:changeBillingAddress::IBehaviorListener:0:random=0.7035102055608244

 So we knew the javascript must of been running as the random parameter
 was different each time it failed.
 I then realised that I needed to 're-set' the break points in the
 wicket-ajax.js again. It seems that firefug was treating the js file
 as a different file when on the failing request versus the good
 request. Anyhow once I realised that I could step through it again to
 the same line in the Request::doGet(). At this point we got the
 behaviour as described before with the URL in the browser and the ajax
 response in the page. Looking at the headers we can see:

 Response Headers
 Content-Type    text/xml; charset=utf-8
 Expires Mon, 26 Jul 1997 05:00:00 GMT
 Cache-Control   no-cache, must-revalidate
 Pragma  no-cache
 Content-Length  3346
 Server  Jetty(6.1.4)

 Request Headers
 Host    foo7.glasscubesdev.com:8080
 User-Agent      Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB;
 rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729;
 .NET4.0C)
 Accept  text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
 Accept-Language 
 en-gb,en-us;q=0.9,de;q=0.8,es;q=0.7,pl;q=0.6,hu;q=0.4,nl;q=0.3,sv-se;q=0.2,en;q=0.1
 Accept-Encoding gzip,deflate
 Accept-Charset  ISO-8859-1,utf-8;q=0.7,*;q=0.7
 Keep-Alive      115
 Connection      keep-alive
 Cookie  JSESSIONID=1vsuz0qz6v33o


 The wicket specific headers and content type are not there, even
 though the code was explicitly setting them just before the call to
 transport send.
 Our only conclusion is that is must be a javascript engine bug, we
 just surprised this has never reported before as its not a wicket bug
 .



 On Tue, Nov 16, 2010 at 5:29 PM, Wayne W waynemailingli...@gmail.com wrote:
 Hello,

 we've upgraded the apache to 2.2.15 in production and this made no 
 difference.
 However today we got a screen shot from one client who has been having
 the issue see:

 https://home.glasscubes.com/share/code/8a8c7ecf37fe9d95cefaf787529b0828
 (you'll need to download to see the details of the URL)

 What's really odd about this is that it looks like the browser is
 doing a HTTP GET rather than using the xml request object - you can
 plainly see in the browser the URL. Looking at the code for the
 onclick event it looks (to me normal) (see below).

 Anyone got any further ideas on this? Its like the wicketAjaxGet is
 literally doing a GET!


 a onclick=if (document.getElementById('spinnerContainere'))
 (document.getElementById('spinnerContainere')).style.display =
 'inline

AjaxSubmitLink 1.4.18 issue/not working

[Wayne W]

Hi,

I'm trying to upgrade from 1.4.8 to 1.4.18 and I'm finding that
AjaxSubmitLink is not working  (at least with one form).

The form doesn't get submitted - the problem in wicket-ajax.js is (~line 1120):

// Submits a form using ajax.
// This method serializes a form and sends it as POST body.
submitForm: function(form, submitButton) {
var submittingAttribute = 'data-wicket-submitting';
if (form.onsubmit  !form.getAttribute(submittingAttribute)) {
form.setAttribute(submittingAttribute, 
submittingAttribute);
var retValue = form.onsubmit();
form.removeAttribute(submittingAttribute);
if (!retValue) return;
}


The problem is var retValue = form.onsubmit(); does not return any
value (retValue remains undefined) and hence it returns and doesn't do
the submit. I don't know enough about javascript to really understand
whats happening here. The form is fairly unremarkable.

For now I've patch the wicket-ajax.js code and comment out the return,
and it works fine again. I notice this code here was not in 1.4.8. But
obviously this is not the solution.

So I imagine it something to do with the form, but I don't know where
to start and look - what is normally returned by form.onsubmit();?
what can I look for?

many thanks

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

Re: AjaxSubmitLink 1.4.18 issue/not working

[Wayne W]

and in what case does it not return anything?


On Fri, Sep 16, 2011 at 5:04 PM, Martin Grigorov mgrigo...@apache.org wrote:
 It should return true or false.
 False if there is some reason to not submit the form, for example
 client side validation failed.
 True if everything is OK and the submit can proceed.

 On Fri, Sep 16, 2011 at 6:21 AM, Wayne W waynemailingli...@gmail.com wrote:
 Hi,

 I'm trying to upgrade from 1.4.8 to 1.4.18 and I'm finding that
 AjaxSubmitLink is not working  (at least with one form).

 The form doesn't get submitted - the problem in wicket-ajax.js is (~line 
 1120):

 // Submits a form using ajax.
        // This method serializes a form and sends it as POST body.
        submitForm: function(form, submitButton) {
                var submittingAttribute = 'data-wicket-submitting';
                if (form.onsubmit  !form.getAttribute(submittingAttribute)) 
 {
                        form.setAttribute(submittingAttribute, 
 submittingAttribute);
                        var retValue = form.onsubmit();
                        form.removeAttribute(submittingAttribute);
                        if (!retValue) return;
                }


 The problem is var retValue = form.onsubmit(); does not return any
 value (retValue remains undefined) and hence it returns and doesn't do
 the submit. I don't know enough about javascript to really understand
 whats happening here. The form is fairly unremarkable.

 For now I've patch the wicket-ajax.js code and comment out the return,
 and it works fine again. I notice this code here was not in 1.4.8. But
 obviously this is not the solution.

 So I imagine it something to do with the form, but I don't know where
 to start and look - what is normally returned by form.onsubmit();?
 what can I look for?

 many thanks

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





 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com

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



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

Re: AjaxSubmitLink 1.4.18 issue/not working

[Wayne W]

The thing is I'm not doing anything special here, just straight wicket
form stuff AFAIK.

Here is what is generated from wicket for the form and the link:

form id=userForm4e
action=../../?wicket:interface=:2:users:addPersonContainer:addPersonPanel:userForm::IFormSubmitListener::
method=post
...

a onclick=if (document.getElementById('spinnerContainer23'))
(document.getElementById('spinnerContainer23')).style.display =
'inline';if (document.getElementById('submitLink22'))
(document.getElementById('submitLink22')).disabled = true;var
wcall=wicketSubmitFormById('userForm1f',
'../../?wicket:interface=:1:users:addPersonContainer:addPersonPanel:userForm:submitLink::IActivePageBehaviorListener:0:2amp;wicket:ignoreIfNotActive=true',
'submitLink' ,function() { if
(document.getElementById('spinnerContainer23')) {
(document.getElementById('spinnerContainer23')).style.display =
'none';}if (document.getElementById('submitLink22'))
(document.getElementById('submitLink22')).disabled =
false;}.bind(this),function() { alert('There was a communication
problem. Please try refreshing your browser');if
(document.getElementById('spinnerContainer23')) {
(document.getElementById('spinnerContainer23')).style.display =
'none';}if (document.getElementById('submitLink22'))
(document.getElementById('submitLink22')).disabled =
false;}.bind(this), function() {return
Wicket.$$(this)amp;amp;Wicket.$$('userForm1f')}.bind(this));;;
return false; href=# id=submitLink22 
spanAdd this person or 
group/span
span class=left/span
span class=right/span
span id=spinnerContainer23 
style=display:nonenbsp;img
src=../../images/icons/spinnerflat.gif/span
/a


As you may see we have an ajax call decorator as well.





On Sat, Sep 17, 2011 at 3:59 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
 no. i thikn it should be

 if (typeof(retVal)==undefined) retVal=true;

 -igor

 On Fri, Sep 16, 2011 at 10:58 AM, Martin Grigorov mgrigo...@apache.org 
 wrote:
 return (typeOf retVal === undefined || retVal === true)

 in all other cases stop the submit

 looks OK ?

 On Fri, Sep 16, 2011 at 8:57 PM, Martin Grigorov mgrigo...@apache.org 
 wrote:
 Yes, sounds like a good idea.
 What if the user code returns an object ?

 On Fri, Sep 16, 2011 at 6:11 PM, Igor Vaynberg igor.vaynb...@gmail.com 
 wrote:
 i think in this case we should define the undefined to be true...

 -igor

 On Fri, Sep 16, 2011 at 5:56 AM, Martin Grigorov mgrigo...@apache.org 
 wrote:
 it seems in your code you have form onsubmit=something(); without
 returning anything. Since 'if (undefined)' is 'false' the call stops
 there.

 On Fri, Sep 16, 2011 at 3:25 PM, Wayne W waynemailingli...@gmail.com 
 wrote:
 and in what case does it not return anything?


 On Fri, Sep 16, 2011 at 5:04 PM, Martin Grigorov mgrigo...@apache.org 
 wrote:
 It should return true or false.
 False if there is some reason to not submit the form, for example
 client side validation failed.
 True if everything is OK and the submit can proceed.

 On Fri, Sep 16, 2011 at 6:21 AM, Wayne W waynemailingli...@gmail.com 
 wrote:
 Hi,

 I'm trying to upgrade from 1.4.8 to 1.4.18 and I'm finding that
 AjaxSubmitLink is not working  (at least with one form).

 The form doesn't get submitted - the problem in wicket-ajax.js is 
 (~line 1120):

 // Submits a form using ajax.
        // This method serializes a form and sends it as POST body.
        submitForm: function(form, submitButton) {
                var submittingAttribute = 'data-wicket-submitting';
                if (form.onsubmit  
 !form.getAttribute(submittingAttribute)) {
                        form.setAttribute(submittingAttribute, 
 submittingAttribute);
                        var retValue = form.onsubmit();
                        form.removeAttribute(submittingAttribute);
                        if (!retValue) return;
                }


 The problem is var retValue = form.onsubmit(); does not return any
 value (retValue remains undefined) and hence it returns and doesn't do
 the submit. I don't know enough about javascript to really understand
 whats happening here. The form is fairly unremarkable.

 For now I've patch the wicket-ajax.js code and comment out the return,
 and it works fine again. I notice this code here was not in 1.4.8. But
 obviously this is not the solution.

 So I imagine it something to do with the form, but I don't know where
 to start and look - what is normally returned by form.onsubmit();?
 what can I look for?

 many thanks

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





 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com

Cannot get Ajax Window Debug to trace responses

[Wayne W]

Hi,

I'm starting a new project so made the jump to wicket 1.5. However
when using ajax, I cannot see the responses being returned from the
server - this is a form thats submitted via ajax. However if I use an
ajx link then I get the response.

I'm sure this was not the case with 1.4.x

Am I missing something?
thanks

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

Model problem with my own component

[Wayne W]

Hello,

I cannot get my component model to update correctly when being set. I
have list of products and when I click on the name via ajax I update a
Product panel to display the info. In that panel I have my component
that displays the image of the product. sudo code:

ProductPanel(id, IModelProduct model) {
  super(id, new CompoundPropertyModel(model));

  add(new Label(name);
  add(new ProductImage(image, getDefaultModel());
}

ProductImage extends Image {
  ProductImage(id, IModelProduct model) {
super( id, model);

   Product p = getDefaultModelObject();
   // p always null

}


AjaxLink() {
  onclick(target) {
productPanel.setDefaultModel(getModel());
target.add(productPanel);
}}


When I click on the link the name is updated and displayed correctly.
However in the ProductImage component the product is always null. I
thought when setting the default model all the children are visited
and model updated.? I;ve tried debugging but get cannot figure it out.

Any ideas?

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

Re: Model problem with my own component

[Wayne W]

thanks Sven

On Wed, Jan 11, 2012 at 6:46 PM, Sven Meier s...@meiers.net wrote:
 Hi,


 add(new ProductImage(image, getDefaultModel());

 this line is causing the null product.


 I thought when setting the default model all the children are visited and
 model updated.?

 No, not at all. Either you have to do that by yourself or you have to give
 ProductImage a more intelligent model:

     add(new ProductImage(image, new AbstractReadOnlyModelProduct() {
          public Product getObject() {
              return getDefaultModel().getObject();
          }
     });

 Hope this helps
 Sven

 Am 11.01.2012 08:01, schrieb Wayne W:

 Hello,

 I cannot get my component model to update correctly when being set. I
 have list of products and when I click on the name via ajax I update a
 Product panel to display the info. In that panel I have my component
 that displays the image of the product. sudo code:

 ProductPanel(id, IModelProduct  model) {
   super(id, new CompoundPropertyModel(model));

   add(new Label(name);
   add(new ProductImage(image, getDefaultModel());
 }

 ProductImage extends Image {
   ProductImage(id, IModelProduct  model) {
     super( id, model);

    Product p = getDefaultModelObject();
    // p always null

 }


 AjaxLink() {
   onclick(target) {
     productPanel.setDefaultModel(getModel());
     target.add(productPanel);
 }}


 When I click on the link the name is updated and displayed correctly.
 However in the ProductImage component the product is always null. I
 thought when setting the default model all the children are visited
 and model updated.? I;ve tried debugging but get cannot figure it out.

 Any ideas?

 -
 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

Could not find root ajax-response element . Wicket 1.5.3

[Wayne W]

Hi,

this is something I have found - I'm getting a consistent ajax error
in this scenario:

I have a page that has an AjaxLink (Add Product), that displays a
panel that contains a form. If I use AjaxFormSubmitBehavior to perform
the submit on the form the sequence of events is:
 - Communication problem
-  Could not find root ajax-response element (in the ajax window)
- onError called (or onSubmit if form contents ok)
- page refreshed.

If I use AjaxSubmitLink all works as expected.


Any idea why this happens?


Wayne

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

Migrating from 1.4.21 to 6

[Wayne W]

Hi All,

I'm wanting to upgrade to the latest version of wicket but am worried about
the possible impact. Also I'm wanting to know the best migration plan. Do
you think it would be best to jump straight to 6 or first upgrade to 5?

Any tips or ideas would be much appreciated.

thanks

Re: Migrating from 1.4.21 to 6

[Wayne W]

I have about 200,000 lines of code. I don't have time to rewrite the app.
Is there a fundamental difference the requires a rewrite?


On Tue, Dec 31, 2013 at 4:34 PM, Martin Sachs sachs.mar...@gmail.comwrote:

 Hi,

 i would mirgate to 6 directly, if your application is relativ small and
 without special requesthandlings, webtrackings and last but not least
 javascript dependencies to other framework than wicket.

 e.g. for an application with round about 5.000 lines of code its easier
 to update. For big applications (20.000 LoC) an rewrite with wicket-6
 could be better and cleaner with the same effort as updating.

 cheers and good luck ;)

 Am 30.12.2013 17:45, schrieb Wayne W:
  Hi All,
 
  I'm wanting to upgrade to the latest version of wicket but am worried
 about
  the possible impact. Also I'm wanting to know the best migration plan. Do
  you think it would be best to jump straight to 6 or first upgrade to 5?
 
  Any tips or ideas would be much appreciated.
 
  thanks
 


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

Re: XSS vulnerability

[Wayne W]

Hi All,


please ignore this. We found the issue - it was due to AbstractBehavior
that was being added to the textfields that outputs the raw value in a div
before escaping it.




On Wed, May 7, 2014 at 11:23 AM, Wayne W waynemailingli...@gmail.comwrote:

 Hi

 Its been brought to my attention that wicket seems to be XSS vulnerable.
 We have a public internet facing form, and by simply putting

 img src=x onerror=prompt(1);

 In the fields you can get a js prompt appearing. As add the fields have
 validators on them, all code is passing through the wicket based code. If
 there any way to stop this?

 We're using wicket 1.4.21 but I've also just tried with the latest version
 of wicket with the same response.

 Its a standard form and we're not setting setEscapeModelStrings or
 anything.

 How can we sanitise the fields on an onError?

 thanks

XSS vulnerability

[Wayne W]

Hi

Its been brought to my attention that wicket seems to be XSS vulnerable. We
have a public internet facing form, and by simply putting

img src=x onerror=prompt(1);

In the fields you can get a js prompt appearing. As add the fields have
validators on them, all code is passing through the wicket based code. If
there any way to stop this?

We're using wicket 1.4.21 but I've also just tried with the latest version
of wicket with the same response.

Its a standard form and we're not setting setEscapeModelStrings or anything.

How can we sanitise the fields on an onError?

thanks

UploadProgressBar Wicket 6 issues

[Wayne W]

Hi,

we've just migrated from 1.4 to the 6.13 and I have to say its been very
painful! So many API breaks. We're also experiencing many UI issues mainly
brought about by how resources are now included. Anyhow we're though most
of them, however I cannot get the UploadProgressBar to work at all. I've
read just about everything I can find on the subject including adding
setUploadProgressUpdatesEnabled
in the Application.

I couldn't find anything about this setting, but presume I need it.

Any ideas what else I need to get this to work again?

Error page for AJAX requests

[Wayne W]

Hi all,

we've recently moved to Wicket 6.17 from 1.4 and I'm having trouble with
NOT showing the default wicket error page when a runtime exception is
thrown from an AjaxLink.

I've set the following in the application:

getApplicationSettings().setInternalErrorPage(ErrorPage.class);

getExceptionSettings().setUnexpectedExceptionDisplay(IExceptionSettings.
SHOW_INTERNAL_ERROR_PAGE);


but it does't seem to have any effect. We override
AbstractRequestCycleListener and specifically IRequestHandler
onException(RequestCycle cycle, Exception e) to perform different error
pages depending on the nature of the exception (for example entitynotfound
exception). We check here to see if its an ajax request like this:


if(cycle.getRequest() instanceof WebRequest  ((WebRequest)
cycle.getRequest()).isAjax()) {

return null; // let wicket take care of it.

}


Is there anyway for ajax requests I can do something like this (which is
what we return for non-ajax requests):


return new RenderPageRequestHandler(new PageProvider(new ErrorPage(page,
e)));


many thanks

Double submit with AjaxFormSubmitBehavior

[Wayne W]

Hi,

I have basically the following:

Form f = new Form('form) {

}

Double submit with AjaxFormSubmitBehavior

[Wayne W]

Hi,

I have basically the following

FormString typeInForm = new FormString(typeInForm) {
  @Override
  protected void onSubmit()
  {
doSubmit(this);
  }
};

AjaxFormSubmitBehavior ajax = new AjaxFormSubmitBehavior(onkeyup) {

  @Override
  protected void onSubmit(AjaxRequestTarget target) {
target.add(resultList);

  }
}
textField.add(ajax);

When the user just enter something in the the text field the both the form
onSubmit gets called once and the AjaxFormSubmitBehavior onSubmit  also
gets called. So far so good. However when the user hits return on the page
the forms onSubmit gets called twice. Looking at the call stack the second
call is coming from the AjaxFormSubmitBehavior.onEvent which intern calls
Form.onFormSubmitted


We need the form onSubmits because if the  user hits return  the
AjaxFormSubmitBehavior onSubmit never gets called.

How can I stop onSubmit getting called twice? I looked for a
'markformsubmitdone' or something but didn't see anything

many thanks

Is this possible?

[Wayne W]

We have a page that has a rather big DataView list. We need to be able to
make insertions and removals of this list without sending back the whole
list via AJAX as its a bit slow over the wire.

Is it possible to add a new element and return and insert that into the
list? Obviously we could insert in new item with JS on the page but we
still want to take advantage to any handlers in wicket for that new item
inserted into the list.

So something like:

onSubmit(AjaxRequestTarget target)

{

ItemMyModel item = new Item(); //!!

item.add(new AjaxFormComponentUpdatingBehavior(onchange)

{ protected void onUpdate(AjaxRequestTarget target) {...}});


thelist.add(item); //!!

...

target.appendJavaScript(js);

}



thanks

Wayne

Anyway of stopping this?

[Wayne W]

Hi,

we have a simple search form:

FormString form = new FormString(searchForm) {

@Override

protected void onSubmit() {

PageParameters params = new PageParameters();

params.add(0, search);

setResponsePage(SearchResultsPage.class, params);

}


 };


This displays a list of results with each row having a BookmarkablePageLink
to another page. If the user uses the form , the results are displayed.
Then they click on any of the links they are taken to the next page.


However when they click 'Back' on the browser they always get 'Confirm Form
Resubmission' in Chrome, 'Document Expired' in Firefox etc. How can we stop
this and just display the result page?


What I actually see in the URLs is:

server.com/searchFormPage

server.com?34-1.IFormSubmitListener-baseCont-search-searchForm

server.com/specificPage/842978

Then they click on back and you get

server.com?34-1.IFormSubmitListener-baseCont-search-searchForm

Re: Is this possible?

[Wayne W]

Many thanks - I will have a look.

On Thu, Oct 16, 2014 at 7:21 PM, Zala Pierre GOUPIL goupilpie...@gmail.com
wrote:

 You can try wicket-quickview, which is based on the stuff in the link
 Martin provided. It works pretty well IMHO, and it is Wicket 6.0 compliant:

 https://github.com/vineetsemwal/quickview

 Regards,

 Pierre





 On Thu, Oct 16, 2014 at 6:28 PM, Martin Grigorov mgrigo...@apache.org
 wrote:

  Hi,
 
  I'd recommend you to use JS for something like this.
  See
 
 
 http://wicketinaction.com/2008/10/repainting-only-newly-created-repeater-items-via-ajax/
  .
  Additionally I'd recommend to use event delegation, i.e. one change
  listener on the dataview that handles 'change' for all items.
 
  Martin Grigorov
  Wicket Training and Consulting
  https://twitter.com/mtgrigorov
 
  On Thu, Oct 16, 2014 at 7:09 PM, Wayne W waynemailingli...@gmail.com
  wrote:
 
   We have a page that has a rather big DataView list. We need to be able
 to
   make insertions and removals of this list without sending back the
 whole
   list via AJAX as its a bit slow over the wire.
  
   Is it possible to add a new element and return and insert that into the
   list? Obviously we could insert in new item with JS on the page but we
   still want to take advantage to any handlers in wicket for that new
 item
   inserted into the list.
  
   So something like:
  
   onSubmit(AjaxRequestTarget target)
  
   {
  
   ItemMyModel item = new Item(); //!!
  
   item.add(new AjaxFormComponentUpdatingBehavior(onchange)
  
   { protected void onUpdate(AjaxRequestTarget target) {...}});
  
  
   thelist.add(item); //!!
  
   ...
  
   target.appendJavaScript(js);
  
   }
  
  
  
   thanks
  
   Wayne
  
 



 --
 La vie est source de joie, la mort est source de paix, seule la transition
 est difficile.

Re: Anyway of stopping this?

[Wayne W]

Hi Sven,

We don't set the RenderStrategy so we should (in wicket 6) be using this
default strategy.

Any other idea?

On Thu, Oct 16, 2014 at 8:28 PM, Sven Meier s...@meiers.net wrote:

 Hi,

 what RenderStrategy are you using?

 WIth REDIRECT_TO_BUFFER Wicket should send a redirect to the search
 results page after your form's submit.

 Sven


 On 10/16/2014 07:16 PM, Wayne W wrote:

 Hi,

 we have a simple search form:

 FormString form = new FormString(searchForm) {

 @Override

 protected void onSubmit() {

 PageParameters params = new PageParameters();

 params.add(0, search);

 setResponsePage(SearchResultsPage.class, params);

 }


   };


 This displays a list of results with each row having a
 BookmarkablePageLink
 to another page. If the user uses the form , the results are displayed.
 Then they click on any of the links they are taken to the next page.


 However when they click 'Back' on the browser they always get 'Confirm
 Form
 Resubmission' in Chrome, 'Document Expired' in Firefox etc. How can we
 stop
 this and just display the result page?


 What I actually see in the URLs is:

 server.com/searchFormPage

 server.com?34-1.IFormSubmitListener-baseCont-search-searchForm

 server.com/specificPage/842978

 Then they click on back and you get

 server.com?34-1.IFormSubmitListener-baseCont-search-searchForm



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

Re: Anyway of stopping this?

[Wayne W]

Ah sorry please ignore me. It seems we had this in the code:

// use this page renderer provider to avoid useless 302 redirections

setPageRendererProvider(new IPageRendererProvider() {

@Override

public PageRenderer get(RenderPageRequestHandler context) {

return new WebPageRenderer(context) {

@Override

protected RedirectPolicy getRedirectPolicy() {

RedirectPolicy result;

if (!((WebRequest) RequestCycle.get().getRequest()).isAjax()) {

result = RedirectPolicy.NEVER_REDIRECT;

} else {

result = super.getRedirectPolicy();

}

return result;

}

};

}

});

On Fri, Oct 17, 2014 at 4:28 PM, Wayne W waynemailingli...@gmail.com
wrote:

 Hi Sven,

 We don't set the RenderStrategy so we should (in wicket 6) be using this
 default strategy.

 Any other idea?

 On Thu, Oct 16, 2014 at 8:28 PM, Sven Meier s...@meiers.net wrote:

 Hi,

 what RenderStrategy are you using?

 WIth REDIRECT_TO_BUFFER Wicket should send a redirect to the search
 results page after your form's submit.

 Sven


 On 10/16/2014 07:16 PM, Wayne W wrote:

 Hi,

 we have a simple search form:

 FormString form = new FormString(searchForm) {

 @Override

 protected void onSubmit() {

 PageParameters params = new PageParameters();

 params.add(0, search);

 setResponsePage(SearchResultsPage.class, params);

 }


   };


 This displays a list of results with each row having a
 BookmarkablePageLink
 to another page. If the user uses the form , the results are displayed.
 Then they click on any of the links they are taken to the next page.


 However when they click 'Back' on the browser they always get 'Confirm
 Form
 Resubmission' in Chrome, 'Document Expired' in Firefox etc. How can we
 stop
 this and just display the result page?


 What I actually see in the URLs is:

 server.com/searchFormPage

 server.com?34-1.IFormSubmitListener-baseCont-search-searchForm

 server.com/specificPage/842978

 Then they click on back and you get

 server.com?34-1.IFormSubmitListener-baseCont-search-searchForm



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

Wicket 6 Session issue

[Wayne W]

Hi,

we recently migrated to 6.17 from 4.x. Something we are now experiencing is
an odd session problem in production.

We have 2 tomcats load balance running the front end wicket code. We have a
certain flow that goes like this:


   1. User goes to : my.example.com/login (LoginPage.java)
   2. They log in
   3. We invalidate the session and do a redirect to : foo.example.com/login
   passing some parameters
   4. In the constructor of LoginPage we verify the parameters and if valid
   setup up the new current session with the user's details
   5. LoginPage then does
   a setResponsePage(Application.get().getHomePage());

This on a single node/machine/instance of tomcat works great and with
Wicket 4 it also worked great in a 2 node/instance load balanced situation
however we have a problem.

Problem:
If at step 3 the redirect gets load balances to a different instance of
tomcat, step 4 works fine (the request is read the the new session is got
and the user info set on it). But this is when it gets really odd. Step 5
is executed fine, but when the home page is constructed
our MetaDataRoleAuthorizationStrategy.isInstantiationAuthorized()  is
called as normal, and when we check the session to see if the users details
are ok, there is no user in the session at all and we have a different
session !

Any ideas at all what is happening here? Did something change around the
session handling? I'm wondering if its something to do with the 302
redirect to the new URL with parameters?

many thanks

Re: Wicket 6 Session issue

[Wayne W]

Hi Martin,

I don't think this is anything to do with session replication, as we
invalidate the session at step 3 and its not about trying to pick the
session up on a different instance. Its about creating a new session from a
redirect where the issue seems. We do use sticky session load balancing via
the JSESSION cookie on apache.



On Wed, Nov 5, 2014 at 10:56 AM, Martin Grigorov mgrigo...@apache.org
wrote:

 Hi,

 As far as I know the session replication supporting code is the same since
 Wicket 1.4.1 (or 1.4.2).

 The Wicket Session object is saved as an attribute in the HttpSession. The
 HttpSession is replicated by Tomcat itself. What is your Tomcat config
 related to replication ?
 Do you use sticky sessions ? It seems you don't but I have to ask.

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

 On Wed, Nov 5, 2014 at 12:43 PM, Wayne W waynemailingli...@gmail.com
 wrote:

  Hi,
 
  we recently migrated to 6.17 from 4.x. Something we are now experiencing
 is
  an odd session problem in production.
 
  We have 2 tomcats load balance running the front end wicket code. We
 have a
  certain flow that goes like this:
 
 
 1. User goes to : my.example.com/login (LoginPage.java)
 2. They log in
 3. We invalidate the session and do a redirect to :
  foo.example.com/login
 passing some parameters
 4. In the constructor of LoginPage we verify the parameters and if
 valid
 setup up the new current session with the user's details
 5. LoginPage then does
 a setResponsePage(Application.get().getHomePage());
 
  This on a single node/machine/instance of tomcat works great and with
  Wicket 4 it also worked great in a 2 node/instance load balanced
 situation
  however we have a problem.
 
  Problem:
  If at step 3 the redirect gets load balances to a different instance of
  tomcat, step 4 works fine (the request is read the the new session is got
  and the user info set on it). But this is when it gets really odd. Step 5
  is executed fine, but when the home page is constructed
  our MetaDataRoleAuthorizationStrategy.isInstantiationAuthorized()  is
  called as normal, and when we check the session to see if the users
 details
  are ok, there is no user in the session at all and we have a different
  session !
 
  Any ideas at all what is happening here? Did something change around the
  session handling? I'm wondering if its something to do with the 302
  redirect to the new URL with parameters?
 
  many thanks
 

Re: Wicket 6 Session issue

[Wayne W]

Sorry Martin its not clear enough. This any better?


   1. Tomcat1 / Session A / Thread 1: User goes to : my.example.com/login
(LoginPage.java)
   2. Tomcat1 / Session A / Thread 2: They log in
   3. Tomcat 1 / Session A / Thread 2 : We invalidate the session and do a
   redirect to : foo.example.com/login passing some parameters
   4. Tomcat 2 / Session B / Thread 1: In the constructor of LoginPage we
   verify the parameters and if valid setup up the new current session with
   the user's details (Session.setUser(user))
   5. Tomcat 2/ Session B / Thread 1: LoginPage then does
   a setResponsePage(Application.get().getHomePage());
   6. Tomcat 2/Session B / Thread
   1:  MetaDataRoleAuthorizationStrategy.isInstantiationAuthorized() finds
   null in the Session (Session.getUser() )




On Wed, Nov 5, 2014 at 11:22 AM, Martin Grigorov mgrigo...@apache.org
wrote:

 Then your first mail misleads.
 Would you please explain again the steps with more details which step on
 which node happens.

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

 On Wed, Nov 5, 2014 at 1:01 PM, Wayne W waynemailingli...@gmail.com
 wrote:

  Hi Martin,
 
  I don't think this is anything to do with session replication, as we
  invalidate the session at step 3 and its not about trying to pick the
  session up on a different instance. Its about creating a new session
 from a
  redirect where the issue seems. We do use sticky session load balancing
 via
  the JSESSION cookie on apache.
 
 
 
  On Wed, Nov 5, 2014 at 10:56 AM, Martin Grigorov mgrigo...@apache.org
  wrote:
 
   Hi,
  
   As far as I know the session replication supporting code is the same
  since
   Wicket 1.4.1 (or 1.4.2).
  
   The Wicket Session object is saved as an attribute in the HttpSession.
  The
   HttpSession is replicated by Tomcat itself. What is your Tomcat config
   related to replication ?
   Do you use sticky sessions ? It seems you don't but I have to ask.
  
   Martin Grigorov
   Wicket Training and Consulting
   https://twitter.com/mtgrigorov
  
   On Wed, Nov 5, 2014 at 12:43 PM, Wayne W waynemailingli...@gmail.com
   wrote:
  
Hi,
   
we recently migrated to 6.17 from 4.x. Something we are now
  experiencing
   is
an odd session problem in production.
   
We have 2 tomcats load balance running the front end wicket code. We
   have a
certain flow that goes like this:
   
   
   1. User goes to : my.example.com/login (LoginPage.java)
   2. They log in
   3. We invalidate the session and do a redirect to :
foo.example.com/login
   passing some parameters
   4. In the constructor of LoginPage we verify the parameters and if
   valid
   setup up the new current session with the user's details
   5. LoginPage then does
   a setResponsePage(Application.get().getHomePage());
   
This on a single node/machine/instance of tomcat works great and with
Wicket 4 it also worked great in a 2 node/instance load balanced
   situation
however we have a problem.
   
Problem:
If at step 3 the redirect gets load balances to a different instance
 of
tomcat, step 4 works fine (the request is read the the new session is
  got
and the user info set on it). But this is when it gets really odd.
  Step 5
is executed fine, but when the home page is constructed
our MetaDataRoleAuthorizationStrategy.isInstantiationAuthorized()  is
called as normal, and when we check the session to see if the users
   details
are ok, there is no user in the session at all and we have a
 different
session !
   
Any ideas at all what is happening here? Did something change around
  the
session handling? I'm wondering if its something to do with the 302
redirect to the new URL with parameters?
   
many thanks
   
  
 

Re: Wicket 6 Session issue

[Wayne W]

Hi Martin,

I think this might have solved it . Many thanks :-)

On Wed, Nov 5, 2014 at 1:49 PM, Martin Grigorov mgrigo...@apache.org
wrote:

 Thanks ! It is more clear now !


 On Wed, Nov 5, 2014 at 3:44 PM, Wayne W waynemailingli...@gmail.com
 wrote:

  Sorry Martin its not clear enough. This any better?
 
 
 1. Tomcat1 / Session A / Thread 1: User goes to :
 my.example.com/login
  (LoginPage.java)
 2. Tomcat1 / Session A / Thread 2: They log in
 3. Tomcat 1 / Session A / Thread 2 : We invalidate the session and do
 a
 redirect to : foo.example.com/login passing some parameters
 4. Tomcat 2 / Session B / Thread 1: In the constructor of LoginPage we
 verify the parameters and if valid setup up the new current session
 with
 the user's details (Session.setUser(user))
 5. Tomcat 2/ Session B / Thread 1: LoginPage then does
 a setResponsePage(Application.get().getHomePage());
 

 try by adding getSession().bind(); at step 5


 6. Tomcat 2/Session B / Thread
 1:  MetaDataRoleAuthorizationStrategy.isInstantiationAuthorized()
 finds
 null in the Session (Session.getUser() )
 
 
 
 
  On Wed, Nov 5, 2014 at 11:22 AM, Martin Grigorov mgrigo...@apache.org
  wrote:
 
   Then your first mail misleads.
   Would you please explain again the steps with more details which step
 on
   which node happens.
  
   Martin Grigorov
   Wicket Training and Consulting
   https://twitter.com/mtgrigorov
  
   On Wed, Nov 5, 2014 at 1:01 PM, Wayne W waynemailingli...@gmail.com
   wrote:
  
Hi Martin,
   
I don't think this is anything to do with session replication, as we
invalidate the session at step 3 and its not about trying to pick the
session up on a different instance. Its about creating a new session
   from a
redirect where the issue seems. We do use sticky session load
 balancing
   via
the JSESSION cookie on apache.
   
   
   
On Wed, Nov 5, 2014 at 10:56 AM, Martin Grigorov 
 mgrigo...@apache.org
  
wrote:
   
 Hi,

 As far as I know the session replication supporting code is the
 same
since
 Wicket 1.4.1 (or 1.4.2).

 The Wicket Session object is saved as an attribute in the
  HttpSession.
The
 HttpSession is replicated by Tomcat itself. What is your Tomcat
  config
 related to replication ?
 Do you use sticky sessions ? It seems you don't but I have to ask.

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

 On Wed, Nov 5, 2014 at 12:43 PM, Wayne W 
  waynemailingli...@gmail.com
 wrote:

  Hi,
 
  we recently migrated to 6.17 from 4.x. Something we are now
experiencing
 is
  an odd session problem in production.
 
  We have 2 tomcats load balance running the front end wicket code.
  We
 have a
  certain flow that goes like this:
 
 
 1. User goes to : my.example.com/login (LoginPage.java)
 2. They log in
 3. We invalidate the session and do a redirect to :
  foo.example.com/login
 passing some parameters
 4. In the constructor of LoginPage we verify the parameters
 and
  if
 valid
 setup up the new current session with the user's details
 5. LoginPage then does
 a setResponsePage(Application.get().getHomePage());
 
  This on a single node/machine/instance of tomcat works great and
  with
  Wicket 4 it also worked great in a 2 node/instance load balanced
 situation
  however we have a problem.
 
  Problem:
  If at step 3 the redirect gets load balances to a different
  instance
   of
  tomcat, step 4 works fine (the request is read the the new
 session
  is
got
  and the user info set on it). But this is when it gets really
 odd.
Step 5
  is executed fine, but when the home page is constructed
  our MetaDataRoleAuthorizationStrategy.isInstantiationAuthorized()
  is
  called as normal, and when we check the session to see if the
 users
 details
  are ok, there is no user in the session at all and we have a
   different
  session !
 
  Any ideas at all what is happening here? Did something change
  around
the
  session handling? I'm wondering if its something to do with the
 302
  redirect to the new URL with parameters?
 
  many thanks
 

   
  
 

Re: wicket + jsessionid and 302 issues

[Wayne W]

Perhaps your tomcats are not getting the session id? make sure your apache
is passing the JSESSION to the tomcat instance

ie ProxyPass / balancer://cluster/ stickysession=JSESSIONID nofailover=Off


On Thu, Nov 13, 2014 at 12:37 AM, Jason Novotny jason.novo...@gmail.com
wrote:

 Hi,

 I figured more detailed config info would be helpful. I want my production
 app to be accessible via https only. The connection is SSL to our Apache
 load balancer which is then http to our Tomcat7 instance.
 The Tomcat 7 connector is default:

  Connector port=8080 protocol=HTTP/1.1
connectionTimeout=2
redirectPort=8443 /

 Just not sure how to config the web.xml or if my tomcat config needs
 changing.

 Thanks, Jason


 On 11/12/14, 1:40 PM, Jason Novotny wrote:

 Hi wicketeers,

 I was hoping to get rid of the jsessionid that appears in the
 browsewr bar when running my wicket app under Tomcat 7, and I added the
 following to web.xml:

 session-config
 session-timeout30/session-timeout
 tracking-modeCOOKIE/tracking-mode
 /session-config

 However, now in production we get all these 302 redirects which are
 causing an infinite recursion. What is the best way to handle this? I also
 found a wiki page https://cwiki.apache.org/confluence/display/WICKET/SEO+
 -+Search+Engine+Optimization but wasn't sure if this also applied to
 using Wicket 6.

 Thanks, Jason



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

RenderStrategy.ONE_PASS_RENDER possible for single page?

[Wayne W]

Hi,

We have an issue with hyperlinks Microsoft Word and Excel documents. Its
seems to vary from version and OS, but the long and short of it is that
Word when a user clicks on a link it uses an internal library to try and
access the page, and once it gets a HTTP 200 it will open the default
browser. We have a page that is used for sharing files so it gets added to
documents.

We have several customers complaining they cannot open these links, and I
can verify this seems to happen depending on OS (Mac is worse for example).
After doing a lot of digging about the only thing we can do is make sure we
return a HTTP 200 from the first request, as anything else seems to
sometimes work, sometimes not.

So to my question:

Is it possible to set RenderStrategy.ONE_PASS_RENDER for a single page
only? We don't really want to loose the advantages of the 302 redirect
elsewhere

Any ideas?

many thanks
Wayne

Re: RenderStrategy.ONE_PASS_RENDER possible for single page?

[Wayne W]

Hi Sven,

I tried setting setStatelessHint(true); but it always does a 302 redirect.
I see something like this in the Net panel in Firebug:

https://www.example.com/share/df43f  302
https://www.example.com/share/df43f?1  200

Any idea?
thanks

On Thu, Nov 13, 2014 at 11:07 AM, Sven Meier s...@meiers.net wrote:

 Hi,

 make your page stateless, then no redirection will occur.

 Sven


 On 11/13/2014 11:55 AM, Wayne W wrote:

 Hi,

 We have an issue with hyperlinks Microsoft Word and Excel documents. Its
 seems to vary from version and OS, but the long and short of it is that
 Word when a user clicks on a link it uses an internal library to try and
 access the page, and once it gets a HTTP 200 it will open the default
 browser. We have a page that is used for sharing files so it gets added to
 documents.

 We have several customers complaining they cannot open these links, and I
 can verify this seems to happen depending on OS (Mac is worse for
 example).
 After doing a lot of digging about the only thing we can do is make sure
 we
 return a HTTP 200 from the first request, as anything else seems to
 sometimes work, sometimes not.

 So to my question:

 Is it possible to set RenderStrategy.ONE_PASS_RENDER for a single page
 only? We don't really want to loose the advantages of the 302 redirect
 elsewhere

 Any ideas?

 many thanks
 Wayne



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

Re: RenderStrategy.ONE_PASS_RENDER possible for single page?

[Wayne W]

Hi,

it looks like we cannot make the page stateless as we have many links that
require the model etc.

Martin- regarding RedirectPolicy#Never - is there any way we can 'mark' the
page to use that? As people are coming to this page from a mount url (with
a parameter), so we never get a chance to do something like:


 scheduleRequestHandlerAfterCurrent(new RenderPageRequestHandler(new
PageProvider(page),

RenderPageRequestHandler.RedirectPolicy.NEVER_REDIRECT));




On Thu, Nov 13, 2014 at 8:15 PM, Martin Grigorov mgrigo...@apache.org
wrote:

 See how RequestCycle#setResponsePage() works.
 You need to use RedirectPolicy#Never.

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

 On Thu, Nov 13, 2014 at 4:56 PM, Sven Meier s...@meiers.net wrote:

  Hi,
 
  your page doesn't become stateless, just by claiming it to be.
  #setStatelessHint() is just a hint.
 
  Here's a real stateless page:
 
 http://www.wicket-library.com/wicket-examples/stateless/foo
 
  Regards
  Sven
 
 
 
  On 11/13/2014 03:27 PM, Wayne W wrote:
 
  Hi Sven,
 
  I tried setting setStatelessHint(true); but it always does a 302
 redirect.
  I see something like this in the Net panel in Firebug:
 
  https://www.example.com/share/df43f  302
  https://www.example.com/share/df43f?1  200
 
  Any idea?
  thanks
 
  On Thu, Nov 13, 2014 at 11:07 AM, Sven Meier s...@meiers.net wrote:
 
   Hi,
 
  make your page stateless, then no redirection will occur.
 
  Sven
 
 
  On 11/13/2014 11:55 AM, Wayne W wrote:
 
   Hi,
 
  We have an issue with hyperlinks Microsoft Word and Excel documents.
 Its
  seems to vary from version and OS, but the long and short of it is
 that
  Word when a user clicks on a link it uses an internal library to try
 and
  access the page, and once it gets a HTTP 200 it will open the default
  browser. We have a page that is used for sharing files so it gets
 added
  to
  documents.
 
  We have several customers complaining they cannot open these links,
 and
  I
  can verify this seems to happen depending on OS (Mac is worse for
  example).
  After doing a lot of digging about the only thing we can do is make
 sure
  we
  return a HTTP 200 from the first request, as anything else seems to
  sometimes work, sometimes not.
 
  So to my question:
 
  Is it possible to set RenderStrategy.ONE_PASS_RENDER for a single page
  only? We don't really want to loose the advantages of the 302 redirect
  elsewhere
 
  Any ideas?
 
  many thanks
  Wayne
 
 
   -
  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: RenderStrategy.ONE_PASS_RENDER possible for single page?

[Wayne W]

Ah yes, brilliant - didn't think of that. Thanks Martin - that works a
treat.


On Fri, Nov 14, 2014 at 11:00 AM, Martin Grigorov mgrigo...@apache.org
wrote:

 You can setup your own PageRenderer
 via org.apache.wicket.Application#setPageRendererProvider.
 It should return the correct redirect policy per page type.

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

 On Fri, Nov 14, 2014 at 12:57 PM, Wayne W waynemailingli...@gmail.com
 wrote:

  Hi,
 
  it looks like we cannot make the page stateless as we have many links
 that
  require the model etc.
 
  Martin- regarding RedirectPolicy#Never - is there any way we can 'mark'
 the
  page to use that? As people are coming to this page from a mount url
 (with
  a parameter), so we never get a chance to do something like:
 
 
   scheduleRequestHandlerAfterCurrent(new RenderPageRequestHandler(new
  PageProvider(page),
 
  RenderPageRequestHandler.RedirectPolicy.NEVER_REDIRECT));
 
 
 
 
  On Thu, Nov 13, 2014 at 8:15 PM, Martin Grigorov mgrigo...@apache.org
  wrote:
 
   See how RequestCycle#setResponsePage() works.
   You need to use RedirectPolicy#Never.
  
   Martin Grigorov
   Wicket Training and Consulting
   https://twitter.com/mtgrigorov
  
   On Thu, Nov 13, 2014 at 4:56 PM, Sven Meier s...@meiers.net wrote:
  
Hi,
   
your page doesn't become stateless, just by claiming it to be.
#setStatelessHint() is just a hint.
   
Here's a real stateless page:
   
   http://www.wicket-library.com/wicket-examples/stateless/foo
   
Regards
Sven
   
   
   
On 11/13/2014 03:27 PM, Wayne W wrote:
   
Hi Sven,
   
I tried setting setStatelessHint(true); but it always does a 302
   redirect.
I see something like this in the Net panel in Firebug:
   
https://www.example.com/share/df43f  302
https://www.example.com/share/df43f?1  200
   
Any idea?
thanks
   
On Thu, Nov 13, 2014 at 11:07 AM, Sven Meier s...@meiers.net
 wrote:
   
 Hi,
   
make your page stateless, then no redirection will occur.
   
Sven
   
   
On 11/13/2014 11:55 AM, Wayne W wrote:
   
 Hi,
   
We have an issue with hyperlinks Microsoft Word and Excel
 documents.
   Its
seems to vary from version and OS, but the long and short of it is
   that
Word when a user clicks on a link it uses an internal library to
 try
   and
access the page, and once it gets a HTTP 200 it will open the
  default
browser. We have a page that is used for sharing files so it gets
   added
to
documents.
   
We have several customers complaining they cannot open these
 links,
   and
I
can verify this seems to happen depending on OS (Mac is worse for
example).
After doing a lot of digging about the only thing we can do is
 make
   sure
we
return a HTTP 200 from the first request, as anything else seems
 to
sometimes work, sometimes not.
   
So to my question:
   
Is it possible to set RenderStrategy.ONE_PASS_RENDER for a single
  page
only? We don't really want to loose the advantages of the 302
  redirect
elsewhere
   
Any ideas?
   
many thanks
Wayne
   
   
   
  -
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
   
   
  
 

IPageRendererProvider - HTTP 500 issue

[Wayne W]

Hi,

We had the requirement that we needed to use RedirectPolicy.NEVER_REDIRECT for
a single page in our app .
We used this code:


setPageRendererProvider(new IPageRendererProvider() {

@Override

public PageRenderer get(final RenderPageRequestHandler context) {

return new WebPageRenderer(context) {

@Override

protected RedirectPolicy getRedirectPolicy() {

RedirectPolicy result;

if (!((WebRequest) RequestCycle.get().getRequest()).isAjax()

  context.getPage() instanceof ExternalShareDocumentPage) {

result = RedirectPolicy.NEVER_REDIRECT;

} else {

result = super.getRedirectPolicy();

}

return result;

}

};

  }

});

This seemed to work fine. However we made it live in production and we
noticed that we where getting HTTP Status 500 - Cannot call sendRedirect()
after the response has been committed  a lot. It seemed to happen with a
flow like the following which was nothing to do with the
ExternalShareDocumentPage
tweak:

User clicks on link which does a setResponcePage(foo1.class)
in the constructor of foo1.class there is:
if (certainCondition) {

throw new RestartResponseException(foo2.class)
}


What I don't understand is why this is happening. It seems that by setting
the PageRenderProvider the way the redirects/commit seems to change.
Any ideas?

Re: IPageRendererProvider - HTTP 500 issue

[Wayne W]

)

org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:282)

com.wideplay.warp.persist.PersistenceFilter$3.run(PersistenceFilter.java:141)

com.wideplay.warp.persist.internal.Lifecycles.failEarlyAndLeaveNoOneBehind(Lifecycles.java:29)

com.wideplay.warp.persist.PersistenceFilter.doFilter(PersistenceFilter.java:155)


On Mon, Nov 17, 2014 at 7:16 PM, Sven Meier s...@meiers.net wrote:

 Can you reproduce the problem in a quickstart?

 Sven


 On 11/17/2014 06:46 PM, Wayne W wrote:

 Hi,

 We had the requirement that we needed to use
 RedirectPolicy.NEVER_REDIRECT for
 a single page in our app .
 We used this code:


 setPageRendererProvider(new IPageRendererProvider() {

 @Override

 public PageRenderer get(final RenderPageRequestHandler context) {

 return new WebPageRenderer(context) {

 @Override

 protected RedirectPolicy getRedirectPolicy() {

 RedirectPolicy result;

 if (!((WebRequest) RequestCycle.get().getRequest()).isAjax()

   context.getPage() instanceof ExternalShareDocumentPage) {

 result = RedirectPolicy.NEVER_REDIRECT;

 } else {

 result = super.getRedirectPolicy();

 }

 return result;

 }

 };

}

 });

 This seemed to work fine. However we made it live in production and we
 noticed that we where getting HTTP Status 500 - Cannot call
 sendRedirect()
 after the response has been committed  a lot. It seemed to happen with a
 flow like the following which was nothing to do with the
 ExternalShareDocumentPage
 tweak:

 User clicks on link which does a setResponcePage(foo1.class)
 in the constructor of foo1.class there is:
 if (certainCondition) {

 throw new RestartResponseException(foo2.class)
 }


 What I don't understand is why this is happening. It seems that by setting
 the PageRenderProvider the way the redirects/commit seems to change.
 Any ideas?



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

Re: IPageRendererProvider - HTTP 500 issue

[Wayne W]

Hi Sven,

Well that might explain a lot then!

We hired someone to do the migration from wicket 1.4 to 6 for us as we
didn't have time or the expertise with the latest version.

Previously we used :

getRequestCycle().setRequestTarget(new RedirectRequestTarget())


and the consultant replaced that everywhere with:


getRequestCycle().scheduleRequestHandlerAfterCurrent(new
RedirectRequestHandler())


I will test with RedirectToUrlException




On Wed, Nov 19, 2014 at 1:02 PM, Sven Meier s...@meiers.net wrote:

 Hi,

 I'm not exactly sure what you're trying to do, but the following is just
 wrong:

 getRequestCycle().scheduleRequestHandlerAfterCurrent(new
 RedirectRequestHandler(http://localhost:8080/wicket/
 bookmarkable/com.mycompany.Foo2?ff=gg));

 This will result in two responses written to the client, one redirect to
 the currently requested page and one to the url you have provided.

 Why aren't you using a RedirectToUrlException?

 Regards
 Sven



 On 11/18/2014 08:35 PM, Wayne W wrote:

 Hi Sven,

 Kind of - however its seems to happen only in 6.17. In 6.18 it seems to
 work ok with the quick start, but with our code base it still happens even
 with 6.18. I see this fix https://issues.apache.org/
 jira/browse/WICKET-5689
 which seems somewhat related (nested redirects). Its still very odd that
 just changing the  setPageRendererProvider would change  the behaviour.

 For you reference here is the quick start can be found here:

 https://customerservices.glasscubes.com/share/s/dvkg92u54


 It produces this:

 WARN  - ServletHandler - /

 java.lang.IllegalStateException: Committed

 at org.eclipse.jetty.server.Response.resetBuffer(Response.java:1141)

 at org.eclipse.jetty.server.Response.sendRedirect(Response.java:493)

 at org.apache.wicket.protocol.http.servlet.ServletWebResponse.
 sendRedirect(
 ServletWebResponse.java:297)

 at
 org.apache.wicket.protocol.http.BufferedWebResponse$
 SendRedirectAction.invoke(
 BufferedWebResponse.java:400)

 at org.apache.wicket.protocol.http.BufferedWebResponse.writeTo(
 BufferedWebResponse.java:588)

 at org.apache.wicket.protocol.http.HeaderBufferingWebResponse.
 stopBuffering(
 HeaderBufferingWebResponse.java:60)

 at org.apache.wicket.protocol.http.HeaderBufferingWebResponse.flush(
 HeaderBufferingWebResponse.java:97)

 at org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(
 WicketFilter.java:269)

 at org.apache.wicket.protocol.http.WicketFilter.processRequest(
 WicketFilter.java:201)

 at org.apache.wicket.protocol.http.WicketFilter.doFilter(
 WicketFilter.java:282)

 at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(
 ServletHandler.java:1291)

 at org.eclipse.jetty.servlet.ServletHandler.doHandle(
 ServletHandler.java:443
 )

 at org.eclipse.jetty.server.handler.ScopedHandler.handle(
 ScopedHandler.java:137)

 at org.eclipse.jetty.security.SecurityHandler.handle(
 SecurityHandler.java:556)

 at org.eclipse.jetty.server.session.SessionHandler.doHandle(
 SessionHandler.java:227)

 at org.eclipse.jetty.server.handler.ContextHandler.doHandle(
 ContextHandler.java:1044)

 at org.eclipse.jetty.servlet.ServletHandler.doScope(
 ServletHandler.java:372)

 at org.eclipse.jetty.server.session.SessionHandler.doScope(
 SessionHandler.java:189)

 at org.eclipse.jetty.server.handler.ContextHandler.doScope(
 ContextHandler.java:978)

 at org.eclipse.jetty.server.handler.ScopedHandler.handle(
 ScopedHandler.java:135)

 at org.eclipse.jetty.server.handler.HandlerWrapper.handle(
 HandlerWrapper.java:116)

 at org.eclipse.jetty.server.Server.handle(Server.java:369)

 at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(
 AbstractHttpConnection.java:486)

 at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(
 BlockingHttpConnection.java:53)

 at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(
 AbstractHttpConnection.java:933)

 at
 org.eclipse.jetty.server.AbstractHttpConnection$
 RequestHandler.headerComplete(
 AbstractHttpConnection.java:995)

 at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644)

 at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)

 at org.eclipse.jetty.server.BlockingHttpConnection.handle(
 BlockingHttpConnection.java:72)

 at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(
 SocketConnector.java:264)

 at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(
 QueuedThreadPool.java:608)

 at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(
 QueuedThreadPool.java:543)

 at java.lang.Thread.run(Thread.java:680)

 Why in production it produces this is not yet clear but seems related:
 HTTP Status 500 - Cannot call sendRedirect() after the response has been
 committed
 --

 *type* Exception report

 *message* *Cannot call sendRedirect() after the response has been
 committed*

 *description* *The server encountered an internal error that prevented it
 from fulfilling this request

ListenerInvocationNotAllowedException and InlineFrames

[Wayne W]

Hi,

we're trying to clear up our production logs at the moment and are going
through errors. I cannot understand what is happen here. We're getting :

org.apache.wicket.core.request.handler.ListenerInvocationNotAllowedException:
Component rejected interface invocationComponent: [InlineFrame [Component
id = customContent]] Listener: [RequestListenerInterface
name=ILinkListener, method=public abstract void
org.apache.wicket.markup.html.link.ILinkListener.onLinkClicked()]

Couple of points. The user can see and access this page no problem which
has an inline frame which is displaying some html. However sometimes this
exception is thrown. I don't understand why this is being thrown as the
inline frame is not enable to disabled at any point and why does an inline
frame have an onLinkClicked event? Looking at the source it seems it using
this to load the actual content. Is this something to do with perhaps the
session not being available? any ideas?

Does wicket instantiate a page even if the session has expired?

[Wayne W]

We have lots of really odd exceptions in our logs in production where
essentially the session is empty but pages are still being created.

Does wicket do this? and if so how do we handle the situation knowing that
data in the session is needed to build the page

thanks

Re: AttributeModifier not updated in Ajax request

[Wayne W]

Any ideas on this one?

On Thu, Jan 15, 2015 at 2:31 PM, Wayne W waynemailingli...@gmail.com
wrote:

 Hi,

 we have a list which gets updated via ajax. This works fine. I'm trying to
 get it so that the style attribute is updated as well. However even though
 I put break points in the getObject() and I can see its got the new User
 object the style attribute sent back via ajax is the old one even though
 the new user label is the correct one.

 Any ideas ?


 getAssignlistContainer().add( new DataViewUser(assignlist, provider)

 {

  @Override

 protected void populateItem(final ItemUser item)

 {

 item.setDefaultModel(new CompoundPropertyModelUser((IModelUser)
 item.getDefaultModel()));

 Label name = new Label(name);

 item.add(name);

 if (item.getModelObject() != null)

 name.add(AttributeModifier.replace(style, new ModelString()

 {

 @Override

 public String getObject()

 {

 User u = item.getModelObject();

 String f = background-color:  +
 LabelColourProvider.getColour(u.getInitials());

 return f;

 }

 }));

  }

 });

AttributeModifier not updated in Ajax request

[Wayne W]

Hi,

we have a list which gets updated via ajax. This works fine. I'm trying to
get it so that the style attribute is updated as well. However even though
I put break points in the getObject() and I can see its got the new User
object the style attribute sent back via ajax is the old one even though
the new user label is the correct one.

Any ideas ?


getAssignlistContainer().add( new DataViewUser(assignlist, provider)

{

 @Override

protected void populateItem(final ItemUser item)

{

item.setDefaultModel(new CompoundPropertyModelUser((IModelUser)
item.getDefaultModel()));

Label name = new Label(name);

item.add(name);

if (item.getModelObject() != null)

name.add(AttributeModifier.replace(style, new ModelString()

{

@Override

public String getObject()

{

User u = item.getModelObject();

String f = background-color:  +
LabelColourProvider.getColour(u.getInitials());

return f;

}

}));

 }

});

Re: ListenerInvocationNotAllowedException and InlineFrames

[Wayne W]

Wicket seems to think its not enabled  isEnabledInHierarchy() returns false
randomly

On Wed, Feb 18, 2015 at 4:48 PM, Wayne W waynemailingli...@gmail.com
wrote:

 Hi,

 we're still stuck on this. I can reproduce it - it seems a bit random but
 I suspect it to do when the browser makes the request. I can hit the same
 page and sometimes its good and sometimes this exception is thrown. There's
 definitely something wrong here.

 org.apache.wicket.core.request.handler.ListenerInvocationNotAllowedException:
 Component rejected interface invocationComponent: [InlineFrame [Component
 id = customContent]] Listener: [RequestListenerInterface
 name=ILinkListener, method=public abstract void
 org.apache.wicket.markup.html.link.ILinkListener.onLinkClicked()]
 at
 org.apache.wicket.RequestListenerInterface.invoke(RequestListenerInterface.java:212)
 at
 org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.invokeListener(ListenerInterfaceRequestHandler.java:243)
 at
 org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:236)
 at
 org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:862)
 at
 org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
 at
 org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:261)
 at
 org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:218)
 at
 org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289)
 at
 org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:259)
 at
 org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201)
 at
 org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:282)
 at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
 at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
 at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at
 com.wideplay.warp.persist.PersistenceFilter$3.run(PersistenceFilter.java:141)
 at
 com.wideplay.warp.persist.internal.Lifecycles.failEarlyAndLeaveNoOneBehind(Lifecycles.java:29)
 at
 com.wideplay.warp.persist.PersistenceFilter.doFilter(PersistenceFilter.java:155)
 at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
 at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
 at
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
 at
 org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501)
 at
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142)
 at
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
 at
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
 at
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:516)
 at
 org.apache.coyote.ajp.AbstractAjpProcessor.process(AbstractAjpProcessor.java:831)
 at
 org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:659)
 at
 org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1558)
 at
 org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1515)
 at
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at
 org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
 at java.lang.Thread.run(Thread.java:744)

 On Fri, Dec 19, 2014 at 1:36 PM, Wayne W waynemailingli...@gmail.com
 wrote:

 Hi,

 we're trying to clear up our production logs at the moment and are going
 through errors. I cannot understand what is happen here. We're getting :

 org.apache.wicket.core.request.handler.ListenerInvocationNotAllowedException:
 Component rejected interface invocationComponent: [InlineFrame [Component
 id = customContent]] Listener: [RequestListenerInterface
 name=ILinkListener, method=public abstract void
 org.apache.wicket.markup.html.link.ILinkListener.onLinkClicked()]

 Couple of points. The user can see and access this page no problem which
 has an inline frame which is displaying some html. However sometimes this
 exception is thrown. I don't understand why

Re: ListenerInvocationNotAllowedException and InlineFrames

[Wayne W]

Hi Tobias,

no the InlineFrame is never disabled (or anything in the hierarchy) so I
don't know why this happens. I've overridden the isEnabledInHierarchy() to
return true to side step the issue for now. I will perhaps try and get
a quick start together to show the issue.

thanks

On Wed, Feb 18, 2015 at 5:48 PM, Tobias Soloschenko 
tobiassolosche...@googlemail.com wrote:

 Hi again,

 I had a look at the method isEnabledInHierarchy() in Component and it
 hasn't changed for about 2 years. Even the places the flags are used
 (RFLAG_ENABLED_IN_HIERARCHY_SET, RFLAG_ENABLED_IN_HIERARCHY_VALUE)
 haven't changed.

 kind regards

 Tobias

 Am 18.02.15 um 18:06 schrieb Wayne W:

 Wicket seems to think its not enabled  isEnabledInHierarchy() returns
 false

 randomly

 On Wed, Feb 18, 2015 at 4:48 PM, Wayne W waynemailingli...@gmail.com
 wrote:

  Hi,

 we're still stuck on this. I can reproduce it - it seems a bit random but
 I suspect it to do when the browser makes the request. I can hit the same
 page and sometimes its good and sometimes this exception is thrown.
 There's
 definitely something wrong here.

 org.apache.wicket.core.request.handler.ListenerInvocationNotAllowedEx
 ception:
 Component rejected interface invocationComponent: [InlineFrame [Component
 id = customContent]] Listener: [RequestListenerInterface
 name=ILinkListener, method=public abstract void
 org.apache.wicket.markup.html.link.ILinkListener.onLinkClicked()]
  at
 org.apache.wicket.RequestListenerInterface.invoke(
 RequestListenerInterface.java:212)
  at
 org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandle
 r.invokeListener(ListenerInterfaceRequestHandler.java:243)
  at
 org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandle
 r.respond(ListenerInterfaceRequestHandler.java:236)
  at
 org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(
 RequestCycle.java:862)
  at
 org.apache.wicket.request.RequestHandlerStack.execute(
 RequestHandlerStack.java:64)
  at
 org.apache.wicket.request.cycle.RequestCycle.execute(
 RequestCycle.java:261)
  at
 org.apache.wicket.request.cycle.RequestCycle.
 processRequest(RequestCycle.java:218)
  at
 org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(
 RequestCycle.java:289)
  at
 org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(
 WicketFilter.java:259)
  at
 org.apache.wicket.protocol.http.WicketFilter.
 processRequest(WicketFilter.java:201)
  at
 org.apache.wicket.protocol.http.WicketFilter.doFilter(
 WicketFilter.java:282)
  at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
 ApplicationFilterChain.java:239)
  at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(
 ApplicationFilterChain.java:206)
  at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
 ApplicationFilterChain.java:239)
  at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(
 ApplicationFilterChain.java:206)
  at
 com.wideplay.warp.persist.PersistenceFilter$3.run(
 PersistenceFilter.java:141)
  at
 com.wideplay.warp.persist.internal.Lifecycles.
 failEarlyAndLeaveNoOneBehind(Lifecycles.java:29)
  at
 com.wideplay.warp.persist.PersistenceFilter.doFilter(
 PersistenceFilter.java:155)
  at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
 ApplicationFilterChain.java:239)
  at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(
 ApplicationFilterChain.java:206)
  at
 org.apache.catalina.core.StandardWrapperValve.invoke(
 StandardWrapperValve.java:219)
  at
 org.apache.catalina.core.StandardContextValve.invoke(
 StandardContextValve.java:106)
  at
 org.apache.catalina.authenticator.AuthenticatorBase.invoke(
 AuthenticatorBase.java:501)
  at
 org.apache.catalina.core.StandardHostValve.invoke(
 StandardHostValve.java:142)
  at
 org.apache.catalina.valves.ErrorReportValve.invoke(
 ErrorReportValve.java:79)
  at
 org.apache.catalina.core.StandardEngineValve.invoke(
 StandardEngineValve.java:88)
  at
 org.apache.catalina.connector.CoyoteAdapter.service(
 CoyoteAdapter.java:516)
  at
 org.apache.coyote.ajp.AbstractAjpProcessor.process(
 AbstractAjpProcessor.java:831)
  at
 org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.
 process(AbstractProtocol.java:659)
  at
 org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.
 doRun(NioEndpoint.java:1558)
  at
 org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.
 run(NioEndpoint.java:1515)
  at
 java.util.concurrent.ThreadPoolExecutor.runWorker(
 ThreadPoolExecutor.java:1145)
  at
 java.util.concurrent.ThreadPoolExecutor$Worker.run(
 ThreadPoolExecutor.java:615)
  at
 org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(
 TaskThread.java:61

Re: ListenerInvocationNotAllowedException and InlineFrames

[Wayne W]

Hi,

we're still stuck on this. I can reproduce it - it seems a bit random but I
suspect it to do when the browser makes the request. I can hit the same
page and sometimes its good and sometimes this exception is thrown. There's
definitely something wrong here.

org.apache.wicket.core.request.handler.ListenerInvocationNotAllowedException:
Component rejected interface invocationComponent: [InlineFrame [Component
id = customContent]] Listener: [RequestListenerInterface
name=ILinkListener, method=public abstract void
org.apache.wicket.markup.html.link.ILinkListener.onLinkClicked()]
at
org.apache.wicket.RequestListenerInterface.invoke(RequestListenerInterface.java:212)
at
org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.invokeListener(ListenerInterfaceRequestHandler.java:243)
at
org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:236)
at
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:862)
at
org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
at
org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:261)
at
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:218)
at
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289)
at
org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:259)
at
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201)
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:282)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
com.wideplay.warp.persist.PersistenceFilter$3.run(PersistenceFilter.java:141)
at
com.wideplay.warp.persist.internal.Lifecycles.failEarlyAndLeaveNoOneBehind(Lifecycles.java:29)
at
com.wideplay.warp.persist.PersistenceFilter.doFilter(PersistenceFilter.java:155)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:516)
at
org.apache.coyote.ajp.AbstractAjpProcessor.process(AbstractAjpProcessor.java:831)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:659)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1558)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1515)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:744)

On Fri, Dec 19, 2014 at 1:36 PM, Wayne W waynemailingli...@gmail.com
wrote:

 Hi,

 we're trying to clear up our production logs at the moment and are going
 through errors. I cannot understand what is happen here. We're getting :

 org.apache.wicket.core.request.handler.ListenerInvocationNotAllowedException:
 Component rejected interface invocationComponent: [InlineFrame [Component
 id = customContent]] Listener: [RequestListenerInterface
 name=ILinkListener, method=public abstract void
 org.apache.wicket.markup.html.link.ILinkListener.onLinkClicked()]

 Couple of points. The user can see and access this page no problem which
 has an inline frame which is displaying some html. However sometimes this
 exception is thrown. I don't understand why this is being thrown as the
 inline frame is not enable to disabled at any point and why does an inline
 frame have an onLinkClicked event? Looking at the source it seems it using
 this to load the actual content. Is this something to do with perhaps

Re: Anyone know a Wiki component?

[Wayne W]

I suppose what I am asking is, does anyone know of a wiki markup engine
that plays well with wicket. I need to create wiki pages from within a
wicket application. I'm not looking for a WYSIWG editor. Basically I'd like
to create a (wicket) page that once you land there, enables the user to
create wiki pages. So really I'm looking for a some form of wiki
engine/markup thats going to be able to handle links jumping from user
generate content page to other user generated content. At the moment wicket
would not be able to handle the URLs I don't think. I'd like to wrap these
user generated pages within a wicket page (that has other wicket
components/panels such as header and main menu, search etc).

On Mon, Jun 1, 2015 at 11:02 AM, Martin Grigorov mgrigo...@apache.org
wrote:

 Hi,

 What functionality exactly do you need ?
 A Wiki is more a product than a component.
 Maybe you need a WYSIWYG editor ?

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

 On Mon, Jun 1, 2015 at 12:55 PM, Wayne W waynemailingli...@gmail.com
 wrote:

  Hi,
 
  I'm looking for a wiki like component(s) as we need to add some wiki type
  functionality to a product. Anyone know of any projects or open source
  projects? I'd rather not start from scratch if there is something already
  out there. I see alots of full java based wiki apps but they are all
 based
  on JPS or struts,etc. Trying to find something that is wicket based, or
  just something reasonably simple that I can embed more easy.
 
  thanks
 

Anyone know a Wiki component?

[Wayne W]

Hi,

I'm looking for a wiki like component(s) as we need to add some wiki type
functionality to a product. Anyone know of any projects or open source
projects? I'd rather not start from scratch if there is something already
out there. I see alots of full java based wiki apps but they are all based
on JPS or struts,etc. Trying to find something that is wicket based, or
just something reasonably simple that I can embed more easy.

thanks

Re: Pagemap help

[Wayne W]

Ok thanks Martijn for the clarification.

On Mon, Nov 16, 2015 at 2:06 PM, Martijn Dashorst <
martijn.dasho...@gmail.com> wrote:

> Well, you can create a Wicket resource for the updates to avoid a
> pagemap lock, but it is essentially the price we pay for having a
> singe-threaded access to the component hierarchy.
>
> You can also create a servlet, but both options will block a thread on
> your server waiting for the processing to finish if you don't want
> polling. That is effectively a kill switch for your application (some
> users will double, triple or N-click links if things are not going
> fast enough).
>
> Martijn
>
>
> On Mon, Nov 16, 2015 at 2:57 PM, Wayne W <waynemailingli...@gmail.com>
> wrote:
> > Hi Martijn,
> >
> > are you basically saving that with wicket there is no way I can not avoid
> > the pagemap locking for a given ajax or iframe request when needed?
> >
> > BTW web sockets aren't supported in IE8.
> >
> > On Mon, Nov 16, 2015 at 1:47 PM, Martijn Dashorst <
> > martijn.dasho...@gmail.com> wrote:
> >
> >> you probably should look into websockets if you don't want polling.
> >>
> >> Martijn
> >>
> >> On Mon, Nov 16, 2015 at 12:50 PM, Wayne W <waynemailingli...@gmail.com>
> >> wrote:
> >> > Hi,
> >> >
> >> > I have a page that has a AbstractDefaultAjaxBehavior which adds a new
> >> panel
> >> > in the ajax request. This new panel can be a long running process to
> >> > generate some data. I'm find this is locking the page map so other
> >> requests
> >> > on that page get locked.
> >> >
> >> > How could I get around this aside from re-enginering the panel to
> >> > poll/notify? Is is possible to create a new page map? I looked at the
> >> > inline frame code but it doesn't seem to look any different regarding
> >> the
> >> > page map. I'd really like to avoid the polling solution if possible
> for
> >> > various reasons.
> >> >
> >> >
> >> > thanks
> >>
> >>
> >>
> >> --
> >> 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
> >>
> >>
>
>
>
> --
> 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
>
>

ListenerInvocationNotAllowedException question / help

[Wayne W]

Hi,

I have a org.apache.wicket.markup.html.link.Link within a page this is
visible only if a certain criteria is met.

If user A visits this page the changes the criteria the link is visible.
The user can then click on the link for some other functionality.

However I'm finding is User B (in a different session) visits the same page
and changes the criteria so that the link is no longer visible but the user
A still has this page open and user A then clicks on the link
a ListenerInvocationNotAllowedException is thrown which I just don't
understand.

I would get it if user B somehow got the hit the url that represents that
link, but why does this link component in another session throw the
exception? Would it be because wicket is checking boolean isVisible() when
making this decision? (as we override the links isVisible() to show
depending on the criteria.

thanks

Re: Pagemap help

[Wayne W]

Hi Martijn,

are you basically saving that with wicket there is no way I can not avoid
the pagemap locking for a given ajax or iframe request when needed?

BTW web sockets aren't supported in IE8.

On Mon, Nov 16, 2015 at 1:47 PM, Martijn Dashorst <
martijn.dasho...@gmail.com> wrote:

> you probably should look into websockets if you don't want polling.
>
> Martijn
>
> On Mon, Nov 16, 2015 at 12:50 PM, Wayne W <waynemailingli...@gmail.com>
> wrote:
> > Hi,
> >
> > I have a page that has a AbstractDefaultAjaxBehavior which adds a new
> panel
> > in the ajax request. This new panel can be a long running process to
> > generate some data. I'm find this is locking the page map so other
> requests
> > on that page get locked.
> >
> > How could I get around this aside from re-enginering the panel to
> > poll/notify? Is is possible to create a new page map? I looked at the
> > inline frame code but it doesn't seem to look any different regarding
> the
> > page map. I'd really like to avoid the polling solution if possible for
> > various reasons.
> >
> >
> > thanks
>
>
>
> --
> 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: ListenerInvocationNotAllowedException question / help

[Wayne W]

Hi Sven,

I tried overriding :

@Override

protected void onConfigure()

{

setVisible(documentModel.getObject().isLocked());

super.onConfigure();

}


and removing the isVisible() override but I still get the same exception.


org.apache.wicket.core.request.handler.ListenerInvocationNotAllowedException:
Component rejected interface invocationComponent: [Link [Component id =
unlock2]] Listener: [RequestListenerInterface name=ILinkListener,
method=public abstract void
org.apache.wicket.markup.html.link.ILinkListener.onLinkClicked()]

at org.apache.wicket.RequestListenerInterface.invoke(
RequestListenerInterface.java:212)

at
org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.invokeListener(
ListenerInterfaceRequestHandler.java:243)

at
org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.respond(
ListenerInterfaceRequestHandler.java:236)

at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(
RequestCycle.java:862)

at org.apache.wicket.request.RequestHandlerStack.execute(
RequestHandlerStack.java:64)





any ideas?



On Mon, Nov 16, 2015 at 4:54 PM, Sven Meier <s...@meiers.net> wrote:

> Hi,
>
> >Would it be because wicket is checking boolean isVisible() when
> >making this decision? (as we override the links isVisible()
>
> indeed.
>
> You should override #onConfigure() and call #setVisible() instead of
> overriding #isVisible().
>
> Regards
> Sven
>
>
>
> On 16.11.2015 16:59, Wayne W wrote:
>
>> Hi,
>>
>> I have a org.apache.wicket.markup.html.link.Link within a page this is
>> visible only if a certain criteria is met.
>>
>> If user A visits this page the changes the criteria the link is visible.
>> The user can then click on the link for some other functionality.
>>
>> However I'm finding is User B (in a different session) visits the same
>> page
>> and changes the criteria so that the link is no longer visible but the
>> user
>> A still has this page open and user A then clicks on the link
>> a ListenerInvocationNotAllowedException is thrown which I just don't
>> understand.
>>
>> I would get it if user B somehow got the hit the url that represents that
>> link, but why does this link component in another session throw the
>> exception? Would it be because wicket is checking boolean isVisible() when
>> making this decision? (as we override the links isVisible() to show
>> depending on the criteria.
>>
>> thanks
>>
>>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Pagemap help

[Wayne W]

Hi,

I have a page that has a AbstractDefaultAjaxBehavior which adds a new panel
in the ajax request. This new panel can be a long running process to
generate some data. I'm find this is locking the page map so other requests
on that page get locked.

How could I get around this aside from re-enginering the panel to
poll/notify? Is is possible to create a new page map? I looked at the
inline frame code but it doesn't seem to look any different regarding  the
page map. I'd really like to avoid the polling solution if possible for
various reasons.


thanks

Re: ListenerInvocationNotAllowedException question / help

[Wayne W]

Hi Sven,

yes it was something else in the hierarchy - many thanks for the help.

On Mon, Nov 16, 2015 at 8:52 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> OK, I see.
> You are right!
>
>
> On Mon, Nov 16, 2015 at 9:48 PM, Sven Meier <s...@meiers.net> wrote:
>
> > Hi Martin,
> >
> > to my knowledge the usual pattern is to override #onConfigure() and set
> up
> > the visibility and enabling of the component for the next rendering *and*
> > the following 'ACTION phase':
> >
> >
> >
> http://wicketinaction.com/2011/11/implement-wicket-component-visibility-changes-properly/
> >
> > Usually I don't see any need to override #canCallListenerInterface(),
> > except in very special cases. I would not advice to override it
> > lightheartedly.
> >
> > From Wayne's description I deduced that he used the 'old' pattern to
> > override #isVisible(), which leads to
> ListenerInvocationNotAllowedException
> > if the condition for visibility and/or enabling changes between rendering
> > and the next incoming request.
> >
> > Regards
> > Sven
> >
> >
> >
> > On 16.11.2015 21:38, Martin Grigorov wrote:
> >
> >> Hi Sven,
> >>
> >> What I'm saying is that Wicket uses Component#canCallListenerInterface()
> >> to
> >> decide whether the listener interface method could be executed or not.
> >> See
> >>
> >>
> https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/RequestListenerInterface.java#L207
> >>
> >> So overriding #onConfigure() won't help him because #onConfigure() is
> >> called later, after successful #onClick().
> >>
> >> He needs to override #canCallListenerInterface() if he needs to call
> >> onClick even on invisible/disabled component.
> >>
> >> Martin Grigorov
> >> Wicket Training and Consulting
> >> https://twitter.com/mtgrigorov
> >>
> >> On Mon, Nov 16, 2015 at 9:31 PM, Sven Meier <s...@meiers.net> wrote:
> >>
> >> Hi Martin,
> >>>
> >>> I didn't understand your comment.
> >>>
> >>> Do you think Wayne might have overriden #canCallListenerInterface()?
> >>>
> >>> Regards
> >>> Sven
> >>>
> >>>
> >>>
> >>> On 16.11.2015 19:32, Martin Grigorov wrote:
> >>>
> >>> Hi,
> >>>>
> >>>> Actually org.apache.wicket.Component#canCallListenerInterface() is
> >>>> responsible for the ACTION phase.
> >>>> #onConfigure() is called in the RENDER phase, i.e. after onClick().
> >>>>
> >>>> Martin Grigorov
> >>>> Wicket Training and Consulting
> >>>> https://twitter.com/mtgrigorov
> >>>>
> >>>> On Mon, Nov 16, 2015 at 7:27 PM, Sven Meier <s...@meiers.net> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>>>
> >>>>> this should work.
> >>>>>
> >>>>> Do you have #isVisible() or #isEnabled() overridden in one of the
> >>>>> component's parents?
> >>>>>
> >>>>> Have fun
> >>>>> Sven
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 16.11.2015 18:08, Wayne W wrote:
> >>>>>
> >>>>> Hi Sven,
> >>>>>
> >>>>>>
> >>>>>> I tried overriding :
> >>>>>>
> >>>>>> @Override
> >>>>>>
> >>>>>> protected void onConfigure()
> >>>>>>
> >>>>>> {
> >>>>>>
> >>>>>> setVisible(documentModel.getObject().isLocked());
> >>>>>>
> >>>>>> super.onConfigure();
> >>>>>>
> >>>>>> }
> >>>>>>
> >>>>>>
> >>>>>> and removing the isVisible() override but I still get the same
> >>>>>> exception.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> org.apache.wicket.core.request.handler.ListenerInvocationNotAllowedException:
> >>>>>> Component rejected interface invocationComponent: 

Re: Single Page Applications (SPA), Wicket and the history ajax back issue

[Wayne W]

Hi Martin,

many thanks for this - I will have a look (just got back from a trip hence
delay!)


On Sun, Jul 17, 2016 at 9:05 AM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> Hi,
>
> You might be also interested in Wicketstuff UrlFragment project (
>
> https://github.com/wicketstuff/core/blob/723bf245a7a9619c670fa493d541fcd9feae92bd/urlfragment-parent/README.md
> )
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Sat, Jul 16, 2016 at 10:31 PM, Martin Grigorov <mgrigo...@apache.org>
> wrote:
>
> > Hi,
> >
> > Here is a small demo application:
> > https://github.com/martin-g/blogs/tree/master/ajax-history
> > It uses HTML5 History API directly, so it won't work on old Internet
> > Explorers!
> > If you need to support old IE, good luck finding a decent JS library.
> > AFAIK https://github.com/browserstate/history.js is one of the best out
> > there, but looking at the number of open issues and PRs I wouldn't use it
> > in my applications.
> >
> > The demo application shows how to support Ajax history for "Ajax menu"
> use
> > case from the earlier mails in this thread. In the past I have used
> > something similar for Ajax pagination functionality.
> > The menu items show how to change the url's path, query string and/or
> > fragment
> > The impl just triggers the respective JS event on the respective Ajax
> > component for the history event. The rest is normal Wicket Ajax request.
> As
> > noted in the previous mail by clicking the browser's back button you will
> > not ask Wicket to load an old version of the page! From Wicket point of
> > view the navigation in the page always goes forward!
> >
> > This implementation is not in Wicket itself because I am sure it is not
> > generic enough for everyone's use cases (and because History API is not
> > available in old IEs!).
> > if you need help with a use case that doesn't work with this impl then
> > please create a demo application and I'll try to help!
> > If one day the implementation is generic enough it may land in Wicket!
> >
> > Have fun!
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >
> > On Wed, Jul 13, 2016 at 10:55 AM, Wayne W <waynemailingli...@gmail.com>
> > wrote:
> >
> >> Hi,
> >>
> >> On Thu, Jul 7, 2016 at 11:28 PM, Martin Grigorov <
> >> martin.grigo...@gmail.com>
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > It seems you use Wicket for several years now and you have no idea how
> >> to
> >> > use it!
> >> >
> >>
> >>
> >> Yes perhaps Martin, I do try but there's a lot too it.
> >>
> >>
> >> >
> >> > I have done this for a client of mine 4 years ago.
> >> > And I have explained how to do it few times in the mailing lists.
> >> > You could use HTML5 History API to manipulate the browser url on each
> >> Ajax
> >> > call. If you need to support old browsers (why?! almost no one does
> >> these
> >> > days) then you should use some JS library that falls back to using the
> >> > location fragment/hash.
> >> > The support of "back/forward" buttons is just registering an
> >> > AjaxEventBehavior that listens for "popState"/"hashchange" event.
> >> >
> >> >
> >> I did some extensive searching and only found a couple of threads about
> >> this:
> >>
> >>
> >>
> http://apache-wicket.1842946.n4.nabble.com/Wicket7-History-API-support-for-navigable-AJAX-pages-components-td4660502.html
> >>
> >>
> >> The main issue seems that the page map is not updated (just overriden)
> for
> >> ajax requests from my reading before. I came to the conclusion trying to
> >> get wicket to support the back button would be difficult and somewhat
> >> hacky. It seems we'd end up with unknown behaviour and issues possibly
> >> occurring and therefore too much of a risk. Hence this thread.
> >>
> >>
> >>
> >> >
> >> > I will try to find time to write a blog article with a demo app at
> >> > wicketinaction.com soon.
> >> >
> >> >
> >>
> >> That would be great.
> >>
> >>
> >>
> >>
> >> >
> >> >
> >>
> >
> >
>

Re: Single Page Applications (SPA), Wicket and the history ajax back issue

[Wayne W]

> So you don't use Ajax because of missing back button support?
> We have a feature request for that, but it didn't spark much interest:
>
> https://issues.apache.org/jira/browse/WICKET-5290




Yes in a lot of cases unfortunately. It confuses a lot of non tech users
who are used to using the navigation back button - we did some user testing
and a fair number of people still use it, from from a UX perspective its
not great dropping it. I did't see that request unfortunately




>
>
> Have fun
> Sven
>
>
>
> On 07.07.2016 14:13, Wayne W wrote:
>
>> Hi Sven,
>>
>> of course: Ok so this is simplified somewhat: lets say we have 4 main tab
>> areas of the application: Contacts, Files, Calendar, Tasks. When a user
>> navigates from one area to the next we need to currently do a whole page
>> refresh, where in fact all we really need to do is refresh a sub panel via
>> ajax. This already is more 'old school' as I put it in the fact the user
>> experiences the whole page refreshing rather than say a loading/spinner in
>> the main panel. We want to make the web pp fell more 'app like' rather
>> than
>> a succession of web pages. Another example is say we are in the "File" tab
>> and we want to drill down through some folders, at the moment we need to
>> refresh the page if we want to support the back button rather than load
>> via
>> ajax.
>>
>> It just gives a much less slick experience as the page reloads visually,
>> and there is more data sent over the wire - slower page loads. But
>> ultimately it about the users impression of the app and feeling like an
>> app
>> rather than a bunch of pages.
>>
>>
>> On Thu, Jul 7, 2016 at 1:01 PM, Sven Meier <s...@meiers.net> wrote:
>>
>> Hi,
>>>
>>> it would be interesting to hear what limitations you're fighting against.
>>> As a server-side rendered framework Wicket surely isn't the new kid on
>>> the
>>> block, but I can't think of anything forcing your application to be 'old
>>> school'.
>>>
>>> Can you be more specific?
>>>
>>> Sven
>>>
>>>
>>>
>>> Am 7. Juli 2016, 13:23, um 13:23, Wayne W <waynemailingli...@gmail.com>
>>> schrieb:
>>>
>>>> Hi,
>>>>
>>>> we're been using wicket for some time now and we have a very
>>>> established
>>>> application used by many clients. It is however feeling some what
>>>> dated,
>>>> due to the fact the we have to constantly reload pages to access
>>>> different
>>>> functionality/areas if the app. We use ajax fairly heavily within each
>>>> functional area.
>>>>
>>>> The problem is we are starting to 'feel' old school and we're loosing
>>>> out
>>>> to the competition that are based on the lasted SPA type JS frameworks
>>>> talking to APIs. They just feel more slick and more responsive.
>>>>
>>>> Doing some research it seems thats it not possible to transform our
>>>> current
>>>> wicket app into this form, mainly due to the issues around wicket ajax
>>>> state storage and history URL support in older browsers.
>>>>
>>>> Is this something the Wicket is never going to to attempt to support? I
>>>> cannot find anything around this subject.
>>>>
>>>> Having a huge investment in our Wicket based application, its going to
>>>> be
>>>> very very painful to move away from which we must do if we cannot keep
>>>> up
>>>> with the competition due to framework limitations.
>>>>
>>>> many thanks
>>>>
>>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: Single Page Applications (SPA), Wicket and the history ajax back issue

[Wayne W]

Hi,

On Thu, Jul 7, 2016 at 11:28 PM, Martin Grigorov 
wrote:

> Hi,
>
> It seems you use Wicket for several years now and you have no idea how to
> use it!
>


Yes perhaps Martin, I do try but there's a lot too it.


>
> I have done this for a client of mine 4 years ago.
> And I have explained how to do it few times in the mailing lists.
> You could use HTML5 History API to manipulate the browser url on each Ajax
> call. If you need to support old browsers (why?! almost no one does these
> days) then you should use some JS library that falls back to using the
> location fragment/hash.
> The support of "back/forward" buttons is just registering an
> AjaxEventBehavior that listens for "popState"/"hashchange" event.
>
>
I did some extensive searching and only found a couple of threads about
this:

http://apache-wicket.1842946.n4.nabble.com/Wicket7-History-API-support-for-navigable-AJAX-pages-components-td4660502.html


The main issue seems that the page map is not updated (just overriden) for
ajax requests from my reading before. I came to the conclusion trying to
get wicket to support the back button would be difficult and somewhat
hacky. It seems we'd end up with unknown behaviour and issues possibly
occurring and therefore too much of a risk. Hence this thread.



>
> I will try to find time to write a blog article with a demo app at
> wicketinaction.com soon.
>
>

That would be great.




>
>

Re: Single Page Applications (SPA), Wicket and the history ajax back issue

[Wayne W]

Hi Sven,

of course: Ok so this is simplified somewhat: lets say we have 4 main tab
areas of the application: Contacts, Files, Calendar, Tasks. When a user
navigates from one area to the next we need to currently do a whole page
refresh, where in fact all we really need to do is refresh a sub panel via
ajax. This already is more 'old school' as I put it in the fact the user
experiences the whole page refreshing rather than say a loading/spinner in
the main panel. We want to make the web pp fell more 'app like' rather than
a succession of web pages. Another example is say we are in the "File" tab
and we want to drill down through some folders, at the moment we need to
refresh the page if we want to support the back button rather than load via
ajax.

It just gives a much less slick experience as the page reloads visually,
and there is more data sent over the wire - slower page loads. But
ultimately it about the users impression of the app and feeling like an app
rather than a bunch of pages.


On Thu, Jul 7, 2016 at 1:01 PM, Sven Meier <s...@meiers.net> wrote:

> Hi,
>
> it would be interesting to hear what limitations you're fighting against.
> As a server-side rendered framework Wicket surely isn't the new kid on the
> block, but I can't think of anything forcing your application to be 'old
> school'.
>
> Can you be more specific?
>
> Sven
>
>
>
> Am 7. Juli 2016, 13:23, um 13:23, Wayne W <waynemailingli...@gmail.com>
> schrieb:
> >Hi,
> >
> >we're been using wicket for some time now and we have a very
> >established
> >application used by many clients. It is however feeling some what
> >dated,
> >due to the fact the we have to constantly reload pages to access
> >different
> >functionality/areas if the app. We use ajax fairly heavily within each
> >functional area.
> >
> >The problem is we are starting to 'feel' old school and we're loosing
> >out
> >to the competition that are based on the lasted SPA type JS frameworks
> >talking to APIs. They just feel more slick and more responsive.
> >
> >Doing some research it seems thats it not possible to transform our
> >current
> >wicket app into this form, mainly due to the issues around wicket ajax
> >state storage and history URL support in older browsers.
> >
> >Is this something the Wicket is never going to to attempt to support? I
> >cannot find anything around this subject.
> >
> >Having a huge investment in our Wicket based application, its going to
> >be
> >very very painful to move away from which we must do if we cannot keep
> >up
> >with the competition due to framework limitations.
> >
> >many thanks
>

Single Page Applications (SPA), Wicket and the history ajax back issue

[Wayne W]

Hi,

we're been using wicket for some time now and we have a very established
application used by many clients. It is however feeling some what dated,
due to the fact the we have to constantly reload pages to access different
functionality/areas if the app. We use ajax fairly heavily within each
functional area.

The problem is we are starting to 'feel' old school and we're loosing out
to the competition that are based on the lasted SPA type JS frameworks
talking to APIs. They just feel more slick and more responsive.

Doing some research it seems thats it not possible to transform our current
wicket app into this form, mainly due to the issues around wicket ajax
state storage and history URL support in older browsers.

Is this something the Wicket is never going to to attempt to support? I
cannot find anything around this subject.

Having a huge investment in our Wicket based application, its going to be
very very painful to move away from which we must do if we cannot keep up
with the competition due to framework limitations.

many thanks

Re: ComponentNotFoundException and Clustering failover

[Wayne W]

Thanks Martin,

I have a theory what this is, perhaps you could confirm?

What I observe is the following with the replication: If I visit page A and
then visit page B, then kill the instance I am on the session is
successfully failed over to the other node. Now I'm still looking at page B
in the browser - if I hit back on the browser I get PageExpiredException.
Is this the expected behaviour?

If it IS the expected behaviour, then the reason I think that I have an
issue with the page with the AbstractDefaultAjaxBehavior is because the
code in the AbstractDefaultAjaxBehaviour.respond is adding components to
the page which in turn marks the Session dirty which in turn replicates the
session. If only the last page/session commit is only replicated it could
explain why I get a ComponentNotFound exception from the page as
it overwriten by the update from the AbstractDefaultAjaxBehavior

What do you think?



On Fri, Mar 24, 2017 at 9:31 AM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> Hi,
>
> Once the http session is replicated this method should be executed on the
> node that did not process the request
> org.apache.wicket.page.PageStoreManager.SessionEntry#readObject().
> Here Wicket will either store the page(s) on the disk or will schedule them
> for storing.
> There is no much usage of Loggers here so you will have to attach a
> debugger and see what happens.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Thu, Mar 23, 2017 at 6:11 PM, Wayne W <waynemailingli...@gmail.com>
> wrote:
>
> > If I put the AbstractDefaultAjaxBehavior back in, it always fails. If I
> > remove the AbstractDefaultAjaxBehavior most of the time it works, but
> every
> > now and then it fails to replicate. Its really inconsistent.
> >
> > I have no idea how to get to the bottom of this. Any pointers or help is
> > much appreciated.
> >
> > On Thu, Mar 23, 2017 at 4:53 PM, Wayne W <waynemailingli...@gmail.com>
> > wrote:
> >
> > > So it seems the homepage is not the only page. However removing the
> > > AbstractDefaultAjaxBehavior makes no difference I still get the same
> > > issues. Just don;t know where to start with this one. Is there a way I
> > can
> > > turn on the logging around replication in wicket?
> > >
> > > On Thu, Mar 23, 2017 at 4:27 PM, Wayne W <waynemailingli...@gmail.com>
> > > wrote:
> > >
> > >> Hi Martin,
> > >>
> > >> no - I still get the ComponentNotFoundException in the new instance.
> :-/
> > >>
> > >> On Thu, Mar 23, 2017 at 3:57 PM, Martin Grigorov <
> mgrigo...@apache.org>
> > >> wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> On Thu, Mar 23, 2017 at 4:20 PM, Wayne W <
> waynemailingli...@gmail.com>
> > >>> wrote:
> > >>>
> > >>> > Hi Martin,
> > >>> >
> > >>> > that was a typo on my part. I've been doing a lot more testing
> > before I
> > >>> > replied to make sure things are as I say. This is what I am
> > observing:
> > >>> >
> > >>> >
> > >>> >- I have a 2 node tomcat cluster setup with apache balancing
> > between
> > >>> >them locally on my machine.
> > >>> >- Testing with a very simple Wicket app I can see the
> replication
> > is
> > >>> >working fine when shutting down either instance.
> > >>> >- Testing with our very heavy weight wicket app it sometimes
> work
> > >>> and
> > >>> >sometimes does not.
> > >>> >
> > >>> > Now the last point above I have narrowed down to our homepage. If I
> > am
> > >>> not
> > >>> > on the homepage the replication seems to work ok. However if I am
> on
> > >>> the
> > >>> > homepage I always get a ComponentNotFoundException when failing
> over
> > >>> to the
> > >>> > other instance.
> > >>> > The homepage has an AbstractDefaultAjaxBehavior which is called
> once
> > >>> the
> > >>> > page is rendered, this in turn adds to the the page a DataView
> > >>> containing a
> > >>> > lot of content and links. The user needs to be logged in before
> they
> > >>> see
> > >>> > the homepage, so the session is already setup.
> > >>> >
> > >>> > I don't know wh

Re: ComponentNotFoundException and Clustering failover

[Wayne W]

Hello Martin,

so I've been trying to still get to the bottom of this days later. So my
understanding is getting better and it appears that the session itself is
replicated fine. However I've tracked my issue down to the following:

- If I have a page that has 2 links at the top. Link A is a Bookmarkable
link back to the same page - it is also mounted thus:  mountPage(
"/cube/documents/${0}", CubeDocumentPage.class); It has a Long page param
needed to construct the page ( i.e. /cube/documents/12345 ). The second
link B is just a simple new Link("B")  .
- If both instances are up and running , lets say I am on instance A. I
visit link A 3 times. I then kill instance A and I am balanced over to
instance B. If I visit link B ,  the PageStoreManager cannot find the page
that contains link B in the store and then tries to create a new instance
of the page - the problem is then for some reason the page parameters are
always null and the Long is never passed. Why is the page parameter always
null here? Trying to debug it, is seems the IPageManager is got from the
wicket Application instance and not the Session, and this IPageManager
looks for a RequestAdaptor. Somewhere the page parameters are lost?.

However I can get it to work this way:
- start instance A, visit the page and say click link A 3 times.
- Now start up instance B
- Kill instance A
- Click on the link B and this time the PageStoreManager finds the page and
there the link B and everything works fine.
It only works if I don't visit another page just after instance B starts up.


I will do some more debugging tomorrow to try and understand this
PageStoreManager/request adaptor bit more. But if you have any ideas I'd
appreciate it.
Thanks



On Fri, Mar 24, 2017 at 12:48 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> Hi,
>
> On Fri, Mar 24, 2017 at 1:31 PM, Wayne W <waynemailingli...@gmail.com>
> wrote:
>
> > Thanks Martin,
> >
> > I have a theory what this is, perhaps you could confirm?
> >
> > What I observe is the following with the replication: If I visit page A
> and
> > then visit page B, then kill the instance I am on the session is
> > successfully failed over to the other node. Now I'm still looking at
> page B
> > in the browser - if I hit back on the browser I get PageExpiredException.
> > Is this the expected behaviour?
> >
>
> No.
> The expected behavior is to see the latest state of page A.
>
>
> >
> > If it IS the expected behaviour, then the reason I think that I have an
> > issue with the page with the AbstractDefaultAjaxBehavior is because the
> > code in the AbstractDefaultAjaxBehaviour.respond is adding components to
> > the page which in turn marks the Session dirty which in turn replicates
> the
> > session. If only the last page/session commit is only replicated it could
> > explain why I get a ComponentNotFound exception from the page as
> > it overwriten by the update from the AbstractDefaultAjaxBehavior
> >
>
> Any time the page is marked as dirty Wicket will store it in 1) the HTTP
> session and 2) on the disk
> 1) will notify the web server (e.g. Tomcat) that it has to replicate the
> session because some attribute has been modified
> At node2 Wicket will detect the replicated session in #readObject() and
> store it on the disk.
> From now on node2 will have the same history for that page as node1, i.e.
> PageA and PageB.
>
> In addition:
> Updates made in an Ajax requests do not add a new entry in the history
> (storages) but overrides the previous entry for that page instance!
> I.e. when PageA is rendered Wicket will assign a pageId for it, e.g. 5, and
> store it in the disk.
> Later when you make a change to PageA:5 in Ajax request then Wicket will
> override the entry on the disk.
> If you make a change in non-Ajax request then Wicket will assign a new
> pageId, e.g. 6, and add a new entry in the history (disk), so you will have
> two entries for this session.
> Later when you open PageB then this will be pageId 7, etc.
>
>
> >
> > What do you think?
> >
> >
> >
> > On Fri, Mar 24, 2017 at 9:31 AM, Martin Grigorov <mgrigo...@apache.org>
> > wrote:
> >
> > > Hi,
> > >
> > > Once the http session is replicated this method should be executed on
> the
> > > node that did not process the request
> > > org.apache.wicket.page.PageStoreManager.SessionEntry#readObject().
> > > Here Wicket will either store the page(s) on the disk or will schedule
> > them
> > > for storing.
> > > There is no much usage of Loggers here so you will have to attach a
> > > debugger and see what happens.
> > >
> > > Martin Grigorov

Re: ComponentNotFoundException and Clustering failover

[Wayne W]

On Thu, Mar 30, 2017 at 4:09 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:

>
>
> Whenever a stateful pages is used (touched) the SessionEntry is updated,
> i.e. the page is put into it.
>

Yes I can see that happening in PageStoreManager.storeTouchedPages()


> The SessionEntry is stored as an attribute in the HTTP Session.
>

I'm not seeing this. In the wicket.Session class there is line :

private transient ISessionStore sessionStore;

Which is loaded from the Application each request. The SessionStore
contains the SessionEntry's no???



> The web container has logic to detect if the HTTP session has been updated
> in a request and if it was then it replicates the whole session to the
> other nodes.
>

Yes I'm seeing the http session replicated no issues.


> Once the session is replicated it is deserialized. Here
> SessionEntry#readObject() comes to play. It reads the pages from the
> SessionEntry and stores them into the disk (via IDiskStore).
> So the stateful pages should be available in the disks of all nodes.
> Stateless pages are always recreated from scratch, so they are not
> replicated.
>


If this is the case why is wicket saying this page is stateless as the
SessionEntry is never replicated across?:



public class HomePage extends WebPage {

private static final long serialVersionUID = 1L;


public HomePage() {

super();


Session s= Session.get();

s.bind();

Integer i = (Integer)s.getAttribute("foo");

if (i == null) {

i = new Integer(0);

}

i++;

s.setAttribute("foo",i);

add(new Label("version", (Integer)s.getAttribute("foo")));


add(new Link("link1") {

@Override

public void onClick()

{

setResponsePage(new NextPage());

}

});

add(new Link("link2") {

@Override

public void onClick()

{

setResponsePage(new HomePage());

}

});

add(new AbstractDefaultAjaxBehavior() {

@Override

protected void respond(AjaxRequestTarget target) {

getSession().setAttribute("someKey", UUID.randomUUID().toString());

System.out.println("SLEEEPING");

try {

Thread.sleep(3000);

}catch(Exception e) {

}

System.out.println("DONE");

}

@Override

public void renderHead(Component component, IHeaderResponse response) {

super.renderHead(component, response);

String js = "(" + getCallbackFunction().toString() +")();";

response.render(OnDomReadyHeaderItem.forScript(js));

}

});

// TODO Add your page's components here


}

}



Sorry for all these questions but I must get to the bottom of this (5 days
work so far). Many thanks



>
>
> >
> >
> > thanks
> >
> > On Tue, Mar 28, 2017 at 9:39 PM, Martin Grigorov <mgrigo...@apache.org>
> > wrote:
> >
> > > Hi,
> > >
> > > Did you mention already which version of Wicket you use ?
> > > There was an improvement related to reusing the page parameters when
> > > constructing a new page instance in 7.0.0.
> > > I have the feeling you are using 6.x. Am I correct ?
> > >
> > > Martin Grigorov
> > > Wicket Training and Consulting
> > > https://twitter.com/mtgrigorov
> > >
> > > On Tue, Mar 28, 2017 at 7:22 PM, Wayne W <waynemailingli...@gmail.com>
> > > wrote:
> > >
> > > > Hello Martin,
> > > >
> > > > so I've been trying to still get to the bottom of this days later. So
> > my
> > > > understanding is getting better and it appears that the session
> itself
> > is
> > > > replicated fine. However I've tracked my issue down to the following:
> > > >
> > > > - If I have a page that has 2 links at the top. Link A is a
> > Bookmarkable
> > > > link back to the same page - it is also mounted thus:  mountPage(
> > > > "/cube/documents/${0}", CubeDocumentPage.class); It has a Long page
> > param
> > > > needed to construct the page ( i.e. /cube/documents/12345 ). The
> second
> > > > link B is just a simple new Link("B")  .
> > > > - If both instances are up and running , lets say I am on instance
> A. I
> > > > visit link A 3 times. I then kill instance A and I am balanced over
> to
> > > > instance B. If I visit link B ,  the PageStoreManager cannot find the
> > > page
> > > > that contains link B in the store and then tries to create a new
> > instance
> > > > of the page - the problem is then for some reason the page parameters
> > are
> > > > always null and the Long is never passed. Why is the page parameter
> > > always
> > > > null here? Trying to debug it, is seems the IPageManager is got from
> &

Re: ComponentNotFoundException and Clustering failover

[Wayne W]

Hi Martin,

yes we are on 6. I've just spent the day upgrading to 7 and got it running
ok. I've been debugging and I'm confused to one aspect:

The PageManager is stored in the Application. The page manger has the
RequestAdaptor/PageStoreManager stored within that holds the pages and
components. I observe that when a new instance joins the cluster this
pagestoremanager SessionEntry is serialized across to the new instance.
However further requests do NOT serialise the session entry across.
If the original node is then shutdown, on the new instance the page (from
the further requests) cannot be found in the pagestoremanager (its
bookmarkable page) and a new instance must be constructed instead. This is
where I get the problem as it can't find the component on the new instance
(I'm still debugging why this is the case).

However my question is whats the point of serialising across the
SessionEntry if its not done on each session commit? Its only of use if the
node is stop straight after the new instance is started.


thanks

On Tue, Mar 28, 2017 at 9:39 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> Hi,
>
> Did you mention already which version of Wicket you use ?
> There was an improvement related to reusing the page parameters when
> constructing a new page instance in 7.0.0.
> I have the feeling you are using 6.x. Am I correct ?
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Tue, Mar 28, 2017 at 7:22 PM, Wayne W <waynemailingli...@gmail.com>
> wrote:
>
> > Hello Martin,
> >
> > so I've been trying to still get to the bottom of this days later. So my
> > understanding is getting better and it appears that the session itself is
> > replicated fine. However I've tracked my issue down to the following:
> >
> > - If I have a page that has 2 links at the top. Link A is a Bookmarkable
> > link back to the same page - it is also mounted thus:  mountPage(
> > "/cube/documents/${0}", CubeDocumentPage.class); It has a Long page param
> > needed to construct the page ( i.e. /cube/documents/12345 ). The second
> > link B is just a simple new Link("B")  .
> > - If both instances are up and running , lets say I am on instance A. I
> > visit link A 3 times. I then kill instance A and I am balanced over to
> > instance B. If I visit link B ,  the PageStoreManager cannot find the
> page
> > that contains link B in the store and then tries to create a new instance
> > of the page - the problem is then for some reason the page parameters are
> > always null and the Long is never passed. Why is the page parameter
> always
> > null here? Trying to debug it, is seems the IPageManager is got from the
> > wicket Application instance and not the Session, and this IPageManager
> > looks for a RequestAdaptor. Somewhere the page parameters are lost?.
> >
> > However I can get it to work this way:
> > - start instance A, visit the page and say click link A 3 times.
> > - Now start up instance B
> > - Kill instance A
> > - Click on the link B and this time the PageStoreManager finds the page
> and
> > there the link B and everything works fine.
> > It only works if I don't visit another page just after instance B starts
> > up.
> >
> >
> > I will do some more debugging tomorrow to try and understand this
> > PageStoreManager/request adaptor bit more. But if you have any ideas I'd
> > appreciate it.
> > Thanks
> >
> >
> >
> > On Fri, Mar 24, 2017 at 12:48 PM, Martin Grigorov <mgrigo...@apache.org>
> > wrote:
> >
> > > Hi,
> > >
> > > On Fri, Mar 24, 2017 at 1:31 PM, Wayne W <waynemailingli...@gmail.com>
> > > wrote:
> > >
> > > > Thanks Martin,
> > > >
> > > > I have a theory what this is, perhaps you could confirm?
> > > >
> > > > What I observe is the following with the replication: If I visit
> page A
> > > and
> > > > then visit page B, then kill the instance I am on the session is
> > > > successfully failed over to the other node. Now I'm still looking at
> > > page B
> > > > in the browser - if I hit back on the browser I get
> > PageExpiredException.
> > > > Is this the expected behaviour?
> > > >
> > >
> > > No.
> > > The expected behavior is to see the latest state of page A.
> > >
> > >
> > > >
> > > > If it IS the expected behaviour, then the reason I think that I have
> an
> > > > issue with the page with the AbstractDefaultAjaxBehavior is because
&g

Re: ComponentNotFoundException and Clustering failover

[Wayne W]

Please ignore my last email I have done a lot more debugging and I *think*
I understand why replication does not work for us:


Whenever a stateful pages is used (touched) the SessionEntry is updated,
> i.e. the page is put into it.
> The SessionEntry is stored as an attribute in the HTTP Session.
> The web container has logic to detect if the HTTP session has been updated
> in a request and if it was then it replicates the whole session to the
> other nodes.
> Once the session is replicated it is deserialized. Here
> SessionEntry#readObject() comes to play. It reads the pages from the
> SessionEntry and stores them into the disk (via IDiskStore).
> So the stateful pages should be available in the disks of all nodes.
> Stateless pages are always recreated from scratch, so they are not
> replicated.


I think this is a little wrong. Yes the SessionEntry in stored as an
attribute in the http session and is replicated. However the pages in the
SessionEntry cache are not replicated as they are transient.

private transient List sessionCache;

private transient List afterReadObject

Therefore the pages are *not* deserialised as you say. The only time
SessionEntry#readObject()
comes to play (at least with Tomcat) is when a node is first brought up and
the daltamanager replicates ALL sessions across, at this point all the
current SessionEntry's in the other nodes http sessions are written across.
After this is done SessionEntry#readObject() is not called anymore. Any new
pages/updates on the original instance are not replicated across (only the
sessionId in the SessionEntry).

This means any new pages created on the old instance (after the new
instance has started up) are not available in the http session or the
second level page store on the new instance.
Therefore when the old instance in shut down the user is load balanced to
the new instance. At this point the link in the page Wicket is looking for
does not exist in the SessionEntry cache or the PageStore so it creates the
page and looks for the component/link.

This causes a ComponentNotFoundException for us because the links are
either in a DataView which is never rendered so does not exist, or the
other links are actually added to the page in an Ajax request and again
because the page is not rendered are not there, Wicket then throws the
exception and it appears to the user the session is lost.

This is at least what I am observing. I can provide a Quick start to
demonstrate if needed.

many thanks for you time thus far.


On Thu, Mar 30, 2017 at 4:29 PM, Wayne W <waynemailingli...@gmail.com>
wrote:

>
>
> On Thu, Mar 30, 2017 at 4:09 PM, Martin Grigorov <mgrigo...@apache.org>
> wrote:
>
>>
>>
>> Whenever a stateful pages is used (touched) the SessionEntry is updated,
>> i.e. the page is put into it.
>>
>
> Yes I can see that happening in PageStoreManager.storeTouchedPages()
>
>
>> The SessionEntry is stored as an attribute in the HTTP Session.
>>
>
> I'm not seeing this. In the wicket.Session class there is line :
>
> private transient ISessionStore sessionStore;
>
> Which is loaded from the Application each request. The SessionStore
> contains the SessionEntry's no???
>
>
>
>> The web container has logic to detect if the HTTP session has been updated
>> in a request and if it was then it replicates the whole session to the
>> other nodes.
>>
>
> Yes I'm seeing the http session replicated no issues.
>
>
>> Once the session is replicated it is deserialized. Here
>> SessionEntry#readObject() comes to play. It reads the pages from the
>> SessionEntry and stores them into the disk (via IDiskStore).
>> So the stateful pages should be available in the disks of all nodes.
>> Stateless pages are always recreated from scratch, so they are not
>> replicated.
>>
>
>
> If this is the case why is wicket saying this page is stateless as the
> SessionEntry is never replicated across?:
>
>
>
> public class HomePage extends WebPage {
>
> private static final long serialVersionUID = 1L;
>
>
> public HomePage() {
>
> super();
>
>
> Session s= Session.get();
>
> s.bind();
>
> Integer i = (Integer)s.getAttribute("foo");
>
> if (i == null) {
>
> i = new Integer(0);
>
> }
>
> i++;
>
> s.setAttribute("foo",i);
>
> add(new Label("version", (Integer)s.getAttribute("foo")));
>
>
> add(new Link("link1") {
>
> @Override
>
> public void onClick()
>
> {
>
> setResponsePage(new NextPage());
>
> }
>
> });
>
> add(new Link("link2") {
>
> @Override
>
> public void onClick()
>
> {
>
> setResponsePage(new HomePage());
>
> }

Re: ComponentNotFoundException and Clustering failover

[Wayne W]

So it seems the homepage is not the only page. However removing the
AbstractDefaultAjaxBehavior
makes no difference I still get the same issues. Just don;t know where to
start with this one. Is there a way I can turn on the logging around
replication in wicket?

On Thu, Mar 23, 2017 at 4:27 PM, Wayne W <waynemailingli...@gmail.com>
wrote:

> Hi Martin,
>
> no - I still get the ComponentNotFoundException in the new instance. :-/
>
> On Thu, Mar 23, 2017 at 3:57 PM, Martin Grigorov <mgrigo...@apache.org>
> wrote:
>
>> Hi,
>>
>> On Thu, Mar 23, 2017 at 4:20 PM, Wayne W <waynemailingli...@gmail.com>
>> wrote:
>>
>> > Hi Martin,
>> >
>> > that was a typo on my part. I've been doing a lot more testing before I
>> > replied to make sure things are as I say. This is what I am observing:
>> >
>> >
>> >- I have a 2 node tomcat cluster setup with apache balancing between
>> >them locally on my machine.
>> >- Testing with a very simple Wicket app I can see the replication is
>> >working fine when shutting down either instance.
>> >- Testing with our very heavy weight wicket app it sometimes work and
>> >sometimes does not.
>> >
>> > Now the last point above I have narrowed down to our homepage. If I am
>> not
>> > on the homepage the replication seems to work ok. However if I am on the
>> > homepage I always get a ComponentNotFoundException when failing over to
>> the
>> > other instance.
>> > The homepage has an AbstractDefaultAjaxBehavior which is called once the
>> > page is rendered, this in turn adds to the the page a DataView
>> containing a
>> > lot of content and links. The user needs to be logged in before they see
>> > the homepage, so the session is already setup.
>> >
>> > I don't know what it is about this page that breaks the replication. Is
>> > there anything around the ajax part that could do this? Any pointers
>> would
>> > be most welcome as it will be a long long task to break that page down
>> and
>> > do rounds and rounds of cluster testing
>> >
>>
>> Let's try something!
>> In you Ajax callback method do something like:
>> getSession().setAttribute("someKey", UUID.randomUUID().toString())
>> Does this trigger replication ?
>>
>>
>> >
>> > many thanks
>> >
>> >
>> >
>> >
>> > On Wed, Mar 22, 2017 at 12:34 PM, Martin Grigorov <mgrigo...@apache.org
>> >
>> > wrote:
>> >
>> > > Hi,
>> > >
>> > > "I can stop one of the instances and I'm not logged in"
>> > > This statement says that you don't really have a properly configured
>> > > failover.
>> > > If those two Tomcat instances are in a cluster then the http sessions
>> > > should be replicated and you should stay logged in no matter which
>> one is
>> > > serving the request.
>> > > Wicket will store the used stateful page at the disks for all Tomcats
>> in
>> > > the cluster, if it the replication is actually working!
>> > >
>> > >
>> > > On Wed, Mar 22, 2017 at 1:02 PM, Wayne W <waynemailingli...@gmail.com
>> >
>> > > wrote:
>> > >
>> > > > Hi,
>> > > >
>> > > > We have 2 instances of Tomcat running with Apache sitting in front
>> > > > balancing between the Tomcat instances. I have session replication
>> > setup
>> > > > which seems to work for basic bookmarkable links on the pages. I can
>> > stop
>> > > > one of the instances and I'm not logged in as it failover to the
>> other
>> > > > instance.
>> > > >
>> > > > However for normal Link and ajax links etc I get
>> > > > ComponentNotFoundException  thrown as the new instance cannot find
>> it
>> > in
>> > > > the session it seems.
>> > > >
>> > > > Clearly I'm not understanding how wicket manages the page state or
>> I've
>> > > > configured something wrong.
>> > > >
>> > > > Does wicket support full session failover ?
>> > > >
>> > > > Many thanks
>> > > >
>> > >
>> >
>>
>
>

Re: ComponentNotFoundException and Clustering failover

[Wayne W]

If I put the AbstractDefaultAjaxBehavior back in, it always fails. If I
remove the AbstractDefaultAjaxBehavior most of the time it works, but every
now and then it fails to replicate. Its really inconsistent.

I have no idea how to get to the bottom of this. Any pointers or help is
much appreciated.

On Thu, Mar 23, 2017 at 4:53 PM, Wayne W <waynemailingli...@gmail.com>
wrote:

> So it seems the homepage is not the only page. However removing the
> AbstractDefaultAjaxBehavior makes no difference I still get the same
> issues. Just don;t know where to start with this one. Is there a way I can
> turn on the logging around replication in wicket?
>
> On Thu, Mar 23, 2017 at 4:27 PM, Wayne W <waynemailingli...@gmail.com>
> wrote:
>
>> Hi Martin,
>>
>> no - I still get the ComponentNotFoundException in the new instance. :-/
>>
>> On Thu, Mar 23, 2017 at 3:57 PM, Martin Grigorov <mgrigo...@apache.org>
>> wrote:
>>
>>> Hi,
>>>
>>> On Thu, Mar 23, 2017 at 4:20 PM, Wayne W <waynemailingli...@gmail.com>
>>> wrote:
>>>
>>> > Hi Martin,
>>> >
>>> > that was a typo on my part. I've been doing a lot more testing before I
>>> > replied to make sure things are as I say. This is what I am observing:
>>> >
>>> >
>>> >- I have a 2 node tomcat cluster setup with apache balancing between
>>> >them locally on my machine.
>>> >- Testing with a very simple Wicket app I can see the replication is
>>> >working fine when shutting down either instance.
>>> >- Testing with our very heavy weight wicket app it sometimes work
>>> and
>>> >sometimes does not.
>>> >
>>> > Now the last point above I have narrowed down to our homepage. If I am
>>> not
>>> > on the homepage the replication seems to work ok. However if I am on
>>> the
>>> > homepage I always get a ComponentNotFoundException when failing over
>>> to the
>>> > other instance.
>>> > The homepage has an AbstractDefaultAjaxBehavior which is called once
>>> the
>>> > page is rendered, this in turn adds to the the page a DataView
>>> containing a
>>> > lot of content and links. The user needs to be logged in before they
>>> see
>>> > the homepage, so the session is already setup.
>>> >
>>> > I don't know what it is about this page that breaks the replication. Is
>>> > there anything around the ajax part that could do this? Any pointers
>>> would
>>> > be most welcome as it will be a long long task to break that page down
>>> and
>>> > do rounds and rounds of cluster testing
>>> >
>>>
>>> Let's try something!
>>> In you Ajax callback method do something like:
>>> getSession().setAttribute("someKey", UUID.randomUUID().toString())
>>> Does this trigger replication ?
>>>
>>>
>>> >
>>> > many thanks
>>> >
>>> >
>>> >
>>> >
>>> > On Wed, Mar 22, 2017 at 12:34 PM, Martin Grigorov <
>>> mgrigo...@apache.org>
>>> > wrote:
>>> >
>>> > > Hi,
>>> > >
>>> > > "I can stop one of the instances and I'm not logged in"
>>> > > This statement says that you don't really have a properly configured
>>> > > failover.
>>> > > If those two Tomcat instances are in a cluster then the http sessions
>>> > > should be replicated and you should stay logged in no matter which
>>> one is
>>> > > serving the request.
>>> > > Wicket will store the used stateful page at the disks for all
>>> Tomcats in
>>> > > the cluster, if it the replication is actually working!
>>> > >
>>> > >
>>> > > On Wed, Mar 22, 2017 at 1:02 PM, Wayne W <
>>> waynemailingli...@gmail.com>
>>> > > wrote:
>>> > >
>>> > > > Hi,
>>> > > >
>>> > > > We have 2 instances of Tomcat running with Apache sitting in front
>>> > > > balancing between the Tomcat instances. I have session replication
>>> > setup
>>> > > > which seems to work for basic bookmarkable links on the pages. I
>>> can
>>> > stop
>>> > > > one of the instances and I'm not logged in as it failover to the
>>> other
>>> > > > instance.
>>> > > >
>>> > > > However for normal Link and ajax links etc I get
>>> > > > ComponentNotFoundException  thrown as the new instance cannot find
>>> it
>>> > in
>>> > > > the session it seems.
>>> > > >
>>> > > > Clearly I'm not understanding how wicket manages the page state or
>>> I've
>>> > > > configured something wrong.
>>> > > >
>>> > > > Does wicket support full session failover ?
>>> > > >
>>> > > > Many thanks
>>> > > >
>>> > >
>>> >
>>>
>>
>>
>

Re: ComponentNotFoundException and Clustering failover

[Wayne W]

Hi Martin,

that was a typo on my part. I've been doing a lot more testing before I
replied to make sure things are as I say. This is what I am observing:


   - I have a 2 node tomcat cluster setup with apache balancing between
   them locally on my machine.
   - Testing with a very simple Wicket app I can see the replication is
   working fine when shutting down either instance.
   - Testing with our very heavy weight wicket app it sometimes work and
   sometimes does not.

Now the last point above I have narrowed down to our homepage. If I am not
on the homepage the replication seems to work ok. However if I am on the
homepage I always get a ComponentNotFoundException when failing over to the
other instance.
The homepage has an AbstractDefaultAjaxBehavior which is called once the
page is rendered, this in turn adds to the the page a DataView containing a
lot of content and links. The user needs to be logged in before they see
the homepage, so the session is already setup.

I don't know what it is about this page that breaks the replication. Is
there anything around the ajax part that could do this? Any pointers would
be most welcome as it will be a long long task to break that page down and
do rounds and rounds of cluster testing

many thanks




On Wed, Mar 22, 2017 at 12:34 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> Hi,
>
> "I can stop one of the instances and I'm not logged in"
> This statement says that you don't really have a properly configured
> failover.
> If those two Tomcat instances are in a cluster then the http sessions
> should be replicated and you should stay logged in no matter which one is
> serving the request.
> Wicket will store the used stateful page at the disks for all Tomcats in
> the cluster, if it the replication is actually working!
>
>
> On Wed, Mar 22, 2017 at 1:02 PM, Wayne W <waynemailingli...@gmail.com>
> wrote:
>
> > Hi,
> >
> > We have 2 instances of Tomcat running with Apache sitting in front
> > balancing between the Tomcat instances. I have session replication setup
> > which seems to work for basic bookmarkable links on the pages. I can stop
> > one of the instances and I'm not logged in as it failover to the other
> > instance.
> >
> > However for normal Link and ajax links etc I get
> > ComponentNotFoundException  thrown as the new instance cannot find it in
> > the session it seems.
> >
> > Clearly I'm not understanding how wicket manages the page state or I've
> > configured something wrong.
> >
> > Does wicket support full session failover ?
> >
> > Many thanks
> >
>

Re: ComponentNotFoundException and Clustering failover

[Wayne W]

Hi Martin,

no - I still get the ComponentNotFoundException in the new instance. :-/

On Thu, Mar 23, 2017 at 3:57 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> Hi,
>
> On Thu, Mar 23, 2017 at 4:20 PM, Wayne W <waynemailingli...@gmail.com>
> wrote:
>
> > Hi Martin,
> >
> > that was a typo on my part. I've been doing a lot more testing before I
> > replied to make sure things are as I say. This is what I am observing:
> >
> >
> >- I have a 2 node tomcat cluster setup with apache balancing between
> >them locally on my machine.
> >- Testing with a very simple Wicket app I can see the replication is
> >working fine when shutting down either instance.
> >- Testing with our very heavy weight wicket app it sometimes work and
> >sometimes does not.
> >
> > Now the last point above I have narrowed down to our homepage. If I am
> not
> > on the homepage the replication seems to work ok. However if I am on the
> > homepage I always get a ComponentNotFoundException when failing over to
> the
> > other instance.
> > The homepage has an AbstractDefaultAjaxBehavior which is called once the
> > page is rendered, this in turn adds to the the page a DataView
> containing a
> > lot of content and links. The user needs to be logged in before they see
> > the homepage, so the session is already setup.
> >
> > I don't know what it is about this page that breaks the replication. Is
> > there anything around the ajax part that could do this? Any pointers
> would
> > be most welcome as it will be a long long task to break that page down
> and
> > do rounds and rounds of cluster testing
> >
>
> Let's try something!
> In you Ajax callback method do something like:
> getSession().setAttribute("someKey", UUID.randomUUID().toString())
> Does this trigger replication ?
>
>
> >
> > many thanks
> >
> >
> >
> >
> > On Wed, Mar 22, 2017 at 12:34 PM, Martin Grigorov <mgrigo...@apache.org>
> > wrote:
> >
> > > Hi,
> > >
> > > "I can stop one of the instances and I'm not logged in"
> > > This statement says that you don't really have a properly configured
> > > failover.
> > > If those two Tomcat instances are in a cluster then the http sessions
> > > should be replicated and you should stay logged in no matter which one
> is
> > > serving the request.
> > > Wicket will store the used stateful page at the disks for all Tomcats
> in
> > > the cluster, if it the replication is actually working!
> > >
> > >
> > > On Wed, Mar 22, 2017 at 1:02 PM, Wayne W <waynemailingli...@gmail.com>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > We have 2 instances of Tomcat running with Apache sitting in front
> > > > balancing between the Tomcat instances. I have session replication
> > setup
> > > > which seems to work for basic bookmarkable links on the pages. I can
> > stop
> > > > one of the instances and I'm not logged in as it failover to the
> other
> > > > instance.
> > > >
> > > > However for normal Link and ajax links etc I get
> > > > ComponentNotFoundException  thrown as the new instance cannot find it
> > in
> > > > the session it seems.
> > > >
> > > > Clearly I'm not understanding how wicket manages the page state or
> I've
> > > > configured something wrong.
> > > >
> > > > Does wicket support full session failover ?
> > > >
> > > > Many thanks
> > > >
> > >
> >
>

Web sockets support clarification

[Wayne W]

Hi,

we are currently using Wicket 6.17 and use a version of Atmosphere jar
libraries (not the wicket version). Its never been great and have had lots
of production issues with it. I'm looking to replace it with straight web
sockets as the fall back long polling etc we never could get to work.

Looking at wicket documentation around web sockets am I correct in the
following:

If the servlet container supports JSR356 (ie. tomcat 8) we only need to use
*wicket-native-websocket* which comprises of *wicket-native-websocket-core *
 and *wicket-native-websocket-native?*

If we are on non JSR356 containers we need to use
*wicket-native-websocket-jetty/wicket-native-websocket-tomcat* ?

Is *wicket-native-websocket *production ready?
Is there any compatibility issues with Wicket 6.17?


Finally on a separate note where can I find a 'Whats new in Wicket 7.0' -
specifically new features etc? The change log is not very clear for me.

Many thanks

Re: Web sockets support clarification

[Wayne W]

Many thanks Martin

On Mon, Mar 20, 2017 at 8:45 AM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> Hi,
>
> On Fri, Mar 17, 2017 at 6:00 PM, Wayne W <waynemailingli...@gmail.com>
> wrote:
>
> > Hi,
> >
> > we are currently using Wicket 6.17 and use a version of Atmosphere jar
> > libraries (not the wicket version). Its never been great and have had
> lots
> > of production issues with it. I'm looking to replace it with straight web
> > sockets as the fall back long polling etc we never could get to work.
> >
>
> The integration with Atmosphere has been dropped for Wicket 8.x.
> There were way too many bugs with it.
>
>
> >
> > Looking at wicket documentation around web sockets am I correct in the
> > following:
> >
> > If the servlet container supports JSR356 (ie. tomcat 8) we only need to
> use
> > *wicket-native-websocket* which comprises of
> *wicket-native-websocket-core
> > *
> >  and *wicket-native-websocket-native?*
> >
>
> wicket-native-websocket-native is actually named wicket-native-websocket-
> javax.
>
>
> >
> > If we are on non JSR356 containers we need to use
> > *wicket-native-websocket-jetty/wicket-native-websocket-tomcat* ?
> >
>
> Correct!
>
>
> >
> > Is *wicket-native-websocket *production ready?
> >
>
> Yes, we think so!
> People use it successfully in their applications!
>
>
> > Is there any compatibility issues with Wicket 6.17?
> >
>
> 6.17 is not supported since a long time!
> You are recommended to upgrade to 6.26.0 or even better to 7.6.0.
>
>
> >
> >
> > Finally on a separate note where can I find a 'Whats new in Wicket 7.0' -
> > specifically new features etc? The change log is not very clear for me.
> >
>
> The migration guide has the most full information about the changes and
> improvements in 7.0.0:
> https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+7.0
> Any improvements in the following releases (like 7.1.0, 7.2.0, etc.) are in
> the JIRA release notes.
>
>
> >
> > Many thanks
> >
>

ComponentNotFoundException and Clustering failover

[Wayne W]

Hi,

We have 2 instances of Tomcat running with Apache sitting in front
balancing between the Tomcat instances. I have session replication setup
which seems to work for basic bookmarkable links on the pages. I can stop
one of the instances and I'm not logged in as it failover to the other
instance.

However for normal Link and ajax links etc I get
ComponentNotFoundException  thrown as the new instance cannot find it in
the session it seems.

Clearly I'm not understanding how wicket manages the page state or I've
configured something wrong.

Does wicket support full session failover ?

Many thanks

Re: ComponentNotFoundException and Clustering failover

[Wayne W]

Hi Martin,

Ok I've opened a ticket. I did some more debugging and I've described it to
the best of my understanding. I could try and make a patch but its complex
code and I don't want to mess anything up!! - not very confident with
Wicket.

https://issues.apache.org/jira/browse/WICKET-6356

thanks


On Mon, Apr 3, 2017 at 8:19 AM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> Hi,
>
> On Thu, Mar 30, 2017 at 11:21 PM, Wayne W <waynemailingli...@gmail.com>
> wrote:
>
> > Please ignore my last email I have done a lot more debugging and I
> *think*
> > I understand why replication does not work for us:
> >
> >
> > Whenever a stateful pages is used (touched) the SessionEntry is updated,
> > > i.e. the page is put into it.
> > > The SessionEntry is stored as an attribute in the HTTP Session.
> > > The web container has logic to detect if the HTTP session has been
> > updated
> > > in a request and if it was then it replicates the whole session to the
> > > other nodes.
> > > Once the session is replicated it is deserialized. Here
> > > SessionEntry#readObject() comes to play. It reads the pages from the
> > > SessionEntry and stores them into the disk (via IDiskStore).
> > > So the stateful pages should be available in the disks of all nodes.
> > > Stateless pages are always recreated from scratch, so they are not
> > > replicated.
> >
> >
> > I think this is a little wrong. Yes the SessionEntry in stored as an
> > attribute in the http session and is replicated. However the pages in the
> > SessionEntry cache are not replicated as they are transient.
> >
> > private transient List sessionCache;
> >
>
> This looks like a bug!
> It shouldn't be transient.
> Please open a ticket!
> Could you please provide your Tomcat configuration related to replication
> too ?
> A patch / Pull Request is also very welcome!
>
> Thank you!
>
>
> >
> > private transient List afterReadObject
> >
> > Therefore the pages are *not* deserialised as you say. The only time
> > SessionEntry#readObject()
> > comes to play (at least with Tomcat) is when a node is first brought up
> and
> > the daltamanager replicates ALL sessions across, at this point all the
> > current SessionEntry's in the other nodes http sessions are written
> across.
> > After this is done SessionEntry#readObject() is not called anymore. Any
> new
> > pages/updates on the original instance are not replicated across (only
> the
> > sessionId in the SessionEntry).
> >
> > This means any new pages created on the old instance (after the new
> > instance has started up) are not available in the http session or the
> > second level page store on the new instance.
> > Therefore when the old instance in shut down the user is load balanced to
> > the new instance. At this point the link in the page Wicket is looking
> for
> > does not exist in the SessionEntry cache or the PageStore so it creates
> the
> > page and looks for the component/link.
> >
> > This causes a ComponentNotFoundException for us because the links are
> > either in a DataView which is never rendered so does not exist, or the
> > other links are actually added to the page in an Ajax request and again
> > because the page is not rendered are not there, Wicket then throws the
> > exception and it appears to the user the session is lost.
> >
> > This is at least what I am observing. I can provide a Quick start to
> > demonstrate if needed.
> >
> > many thanks for you time thus far.
> >
> >
> > On Thu, Mar 30, 2017 at 4:29 PM, Wayne W <waynemailingli...@gmail.com>
> > wrote:
> >
> > >
> > >
> > > On Thu, Mar 30, 2017 at 4:09 PM, Martin Grigorov <mgrigo...@apache.org
> >
> > > wrote:
> > >
> > >>
> > >>
> > >> Whenever a stateful pages is used (touched) the SessionEntry is
> updated,
> > >> i.e. the page is put into it.
> > >>
> > >
> > > Yes I can see that happening in PageStoreManager.storeTouchedPages()
> > >
> > >
> > >> The SessionEntry is stored as an attribute in the HTTP Session.
> > >>
> > >
> > > I'm not seeing this. In the wicket.Session class there is line :
> > >
> > > private transient ISessionStore sessionStore;
> > >
> > > Which is loaded from the Application each request. The SessionStore
> > > contains the SessionEntry's no???
> > >
> > >
> > >
> > &g

NPE in org.apache.wicket.request.http.handler.RedirectRequestHandler.respond

[Wayne W]

Hi,

I've got a strange issue I cannot get to the bottom of. Basically we have
our app deployed on jetty 9.2.1 with apache 2.4 in front. If I make calls
to stateless pages its all good. However as soon as I try to make a call to
a stateful page it does a 302 to the login page for our app, but then just
gets stuck in a 302 loop redirection loop. Looking at the server logs its
full of this with no other exception - each track trace corresponds to
another 302 redirect. Each redirect is trying to get to our login page:


2017-07-25 14:40:18,989 ERROR -
org.apache.wicket.DefaultExceptionMapper.internalMap(DefaultExceptionMapper.java:129)
129 DefaultExceptionMapper - Unexpected error occurred
java.lang.NullPointerException
at
org.apache.wicket.request.http.handler.RedirectRequestHandler.respond(RedirectRequestHandler.java:99)
at
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:862)
at
org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
at
org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:93)
at
org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:261)
at
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:218)
at
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289)
at
org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:259)
at
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201)
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:282)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1653)
at
hub.app.servlet.RelativeUrlFilter.doFilter(RelativeUrlFilter.java:54)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1653)
at
com.wideplay.warp.persist.PersistenceFilter$3.run(PersistenceFilter.java:141)
at
com.wideplay.warp.persist.internal.Lifecycles.failEarlyAndLeaveNoOneBehind(Lifecycles.java:29)
at
com.wideplay.warp.persist.PersistenceFilter.doFilter(PersistenceFilter.java:155)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1645)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:564)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:578)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:498)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:183)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1045)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:199)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:109)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:98)
at org.eclipse.jetty.server.Server.handle(Server.java:461)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:284)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
at
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:534)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:607)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:536)
at java.lang.Thread.run(Thread.java:745)
2017-07-25 14:40:19,076 ERROR -
org.apache.wicket.DefaultExceptionMapper.internalMap(DefaultExceptionMapper.java:129)
129 DefaultExceptionMapper - Unexpected error occurred
java.lang.NullPointerException
at
org.apache.wicket.request.http.handler.RedirectRequestHandler.respond(RedirectRequestHandler.java:99)
at
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:862)
at
org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
etc




Does any one have any idea what is causing this? Its fine on my local
machine and fine if I used tomcat behind apache.


My apache cons looks like this:


 ServerName X.com

 RequestHeader set X_FORWARDED_PROTO "https"
 RequestHeader set X-Forwarded-Proto "https"

 ErrorLog /home/wayne/error_log
 CustomLog /home/wayne/access_log combined

 SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH

 SSLEngine On
 SSLCertificateFile  

Re: NPE in org.apache.wicket.request.http.handler.RedirectRequestHandler.respond

[Wayne W]

Thanks Martin,

I've put logging everywhere but still can't track it down. Its just this
jetty instance causing not, not sure why. I'm going to side step the issue
and upgrade to 7.8.10 as I need that replication fix live asap.

Many thanks

On Wed, Jul 26, 2017 at 11:51 AM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> I've added a check for 7.x and 8.x -
> https://git1-us-west.apache.org/repos/asf?p=wicket.git;a=
> commitdiff;h=5f3fc484;hp=3ec2c617f1e27f06df985032e233ca4799097b26
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Wed, Jul 26, 2017 at 1:48 PM, Martin Grigorov <mgrigo...@apache.org>
> wrote:
>
> > https://github.com/apache/wicket/blob/wicket-6.17.0/
> > wicket-request/src/main/java/org/apache/wicket/request/http/handler/
> > RedirectRequestHandler.java#L99 says that getRedirectUrl() returns null.
> > So something calls RedirectRequestHandler's constructor with null url.
> > Wicket doesn't instantiate this class for its needs, so it should be your
> > application.
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >
> > On Wed, Jul 26, 2017 at 10:15 AM, Wayne W <waynemailingli...@gmail.com>
> > wrote:
> >
> >> Still on 6.17.0 Martin. Not had the time/resources to move to 6.18
> which I
> >> want because of that replication fix!!
> >>
> >> On Tue, Jul 25, 2017 at 7:55 PM, Martin Grigorov <mgrigo...@apache.org>
> >> wrote:
> >>
> >> > Which version of Wicket do you use ?
> >> >
> >> > Martin Grigorov
> >> > Wicket Training and Consulting
> >> > https://twitter.com/mtgrigorov
> >> >
> >> > On Tue, Jul 25, 2017 at 5:52 PM, Wayne W <waynemailingli...@gmail.com
> >
> >> > wrote:
> >> >
> >> > > Hi,
> >> > >
> >> > > I've got a strange issue I cannot get to the bottom of. Basically we
> >> have
> >> > > our app deployed on jetty 9.2.1 with apache 2.4 in front. If I make
> >> calls
> >> > > to stateless pages its all good. However as soon as I try to make a
> >> call
> >> > to
> >> > > a stateful page it does a 302 to the login page for our app, but
> then
> >> > just
> >> > > gets stuck in a 302 loop redirection loop. Looking at the server
> logs
> >> its
> >> > > full of this with no other exception - each track trace corresponds
> to
> >> > > another 302 redirect. Each redirect is trying to get to our login
> >> page:
> >> > >
> >> > >
> >> > > 2017-07-25 14:40:18,989 ERROR -
> >> > > org.apache.wicket.DefaultExceptionMapper.internalMap(
> >> > > DefaultExceptionMapper.java:129)
> >> > > 129 DefaultExceptionMapper - Unexpected error occurred
> >> > > java.lang.NullPointerException
> >> > > at
> >> > > org.apache.wicket.request.http.handler.RedirectRequestHandle
> >> r.respond(
> >> > > RedirectRequestHandler.java:99)
> >> > > at
> >> > > org.apache.wicket.request.cycle.RequestCycle$
> HandlerExecutor.respond(
> >> > > RequestCycle.java:862)
> >> > > at
> >> > > org.apache.wicket.request.RequestHandlerStack.execute(
> >> > > RequestHandlerStack.java:64)
> >> > > at
> >> > > org.apache.wicket.request.RequestHandlerStack.execute(
> >> > > RequestHandlerStack.java:93)
> >> > > at
> >> > > org.apache.wicket.request.cycle.RequestCycle.execute(
> >> > > RequestCycle.java:261)
> >> > > at
> >> > > org.apache.wicket.request.cycle.RequestCycle.
> >> > processRequest(RequestCycle.
> >> > > java:218)
> >> > > at
> >> > > org.apache.wicket.request.cycle.RequestCycle.
> processRequestAndDetach(
> >> > > RequestCycle.java:289)
> >> > > at
> >> > > org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(
> >> > > WicketFilter.java:259)
> >> > > at
> >> > > org.apache.wicket.protocol.http.WicketFilter.
> >> > processRequest(WicketFilter.
> >> > > java:201)
> >> > > at
> >> > > org.apache.wicket.protocol.http.WicketFilter.doFilter(
> &

Re: NPE in org.apache.wicket.request.http.handler.RedirectRequestHandler.respond

[Wayne W]

Still on 6.17.0 Martin. Not had the time/resources to move to 6.18 which I
want because of that replication fix!!

On Tue, Jul 25, 2017 at 7:55 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> Which version of Wicket do you use ?
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Tue, Jul 25, 2017 at 5:52 PM, Wayne W <waynemailingli...@gmail.com>
> wrote:
>
> > Hi,
> >
> > I've got a strange issue I cannot get to the bottom of. Basically we have
> > our app deployed on jetty 9.2.1 with apache 2.4 in front. If I make calls
> > to stateless pages its all good. However as soon as I try to make a call
> to
> > a stateful page it does a 302 to the login page for our app, but then
> just
> > gets stuck in a 302 loop redirection loop. Looking at the server logs its
> > full of this with no other exception - each track trace corresponds to
> > another 302 redirect. Each redirect is trying to get to our login page:
> >
> >
> > 2017-07-25 14:40:18,989 ERROR -
> > org.apache.wicket.DefaultExceptionMapper.internalMap(
> > DefaultExceptionMapper.java:129)
> > 129 DefaultExceptionMapper - Unexpected error occurred
> > java.lang.NullPointerException
> > at
> > org.apache.wicket.request.http.handler.RedirectRequestHandler.respond(
> > RedirectRequestHandler.java:99)
> > at
> > org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(
> > RequestCycle.java:862)
> > at
> > org.apache.wicket.request.RequestHandlerStack.execute(
> > RequestHandlerStack.java:64)
> > at
> > org.apache.wicket.request.RequestHandlerStack.execute(
> > RequestHandlerStack.java:93)
> > at
> > org.apache.wicket.request.cycle.RequestCycle.execute(
> > RequestCycle.java:261)
> > at
> > org.apache.wicket.request.cycle.RequestCycle.
> processRequest(RequestCycle.
> > java:218)
> > at
> > org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(
> > RequestCycle.java:289)
> > at
> > org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(
> > WicketFilter.java:259)
> > at
> > org.apache.wicket.protocol.http.WicketFilter.
> processRequest(WicketFilter.
> > java:201)
> > at
> > org.apache.wicket.protocol.http.WicketFilter.doFilter(
> > WicketFilter.java:282)
> > at
> > org.eclipse.jetty.servlet.ServletHandler$CachedChain.
> > doFilter(ServletHandler.java:1653)
> > at
> > hub.app.servlet.RelativeUrlFilter.doFilter(RelativeUrlFilter.java:54)
> > at
> > org.eclipse.jetty.servlet.ServletHandler$CachedChain.
> > doFilter(ServletHandler.java:1653)
> > at
> > com.wideplay.warp.persist.PersistenceFilter$3.run(
> > PersistenceFilter.java:141)
> > at
> > com.wideplay.warp.persist.internal.Lifecycles.
> > failEarlyAndLeaveNoOneBehind(Lifecycles.java:29)
> > at
> > com.wideplay.warp.persist.PersistenceFilter.doFilter(
> > PersistenceFilter.java:155)
> > at
> > org.eclipse.jetty.servlet.ServletHandler$CachedChain.
> > doFilter(ServletHandler.java:1645)
> > at
> > org.eclipse.jetty.servlet.ServletHandler.doHandle(
> ServletHandler.java:564)
> > at
> > org.eclipse.jetty.server.handler.ScopedHandler.handle(
> > ScopedHandler.java:143)
> > at
> > org.eclipse.jetty.security.SecurityHandler.handle(
> > SecurityHandler.java:578)
> > at
> > org.eclipse.jetty.server.session.SessionHandler.
> > doHandle(SessionHandler.java:221)
> > at
> > org.eclipse.jetty.server.handler.ContextHandler.
> > doHandle(ContextHandler.java:)
> > at
> > org.eclipse.jetty.servlet.ServletHandler.doScope(
> ServletHandler.java:498)
> > at
> > org.eclipse.jetty.server.session.SessionHandler.
> > doScope(SessionHandler.java:183)
> > at
> > org.eclipse.jetty.server.handler.ContextHandler.
> > doScope(ContextHandler.java:1045)
> > at
> > org.eclipse.jetty.server.handler.ScopedHandler.handle(
> > ScopedHandler.java:141)
> > at
> > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(
> > ContextHandlerCollection.java:199)
> > at
> > org.eclipse.jetty.server.handler.HandlerCollection.
> > handle(HandlerCollection.java:109)
> > at
> > org.eclipse.jetty.server.handler.HandlerWrapper.handle(
> > HandlerWrapper.j

Re: CsrfPreventionRequestCycleListener or alternative CSRF protection

[Wayne W]

Hi,

does anyone else have an ideas whats I could do here. Is there anyone out
there who's successfully got the CSRF protection up and running in
production?

On Fri, Sep 8, 2017 at 10:31 AM, Wayne W <waynemailingli...@gmail.com>
wrote:

> Thanks Martin,
>
> so I've used this:
>
> setRootRequestMapper(new PostUrlCryptMapper(getRootRequestMapper(), new
> KeyInSessionSunJceCryptFactory()));
>
>
> public class PostUrlCryptMapper extends CryptoMapper {
>
> /**
>
>  * @param wrappedMapper
>
>  * @param cryptFactory
>
>  */
>
> private static Log log = LogFactory.getLog(PostUrlCryptMapper.class);
>
> public PostUrlCryptMapper(IRequestMapper wrappedMapper,
>
>   final KeyInSessionSunJceCryptFactory
> cryptFactory) {
>
> super(wrappedMapper, new IProvider() {
>
> @Override
>
> public ICrypt get() {
>
> return cryptFactory.newCrypt();
>
> }
>
> });
>
> }
>
>
> public Url mapHandler(final IRequestHandler requestHandler)
>
> {
>
> if (isFormListenerInterfaceRequestHandler(requestHandler)) {
>
> return super.mapHandler(requestHandler);
>
> } else {
>
> return getDelegateMapper().mapHandler(requestHandler);
>
> }
>
> }
>
>
> public IRequestHandler mapRequest(final Request request)
>
> {
>
> final IRequestHandler requestHandler = getDelegateMapper().
> mapRequest(request);
>
> if (requestHandler == null) {
>
> return super.mapRequest(request);
>
> }
>
> return requestHandler;
>
> }
>
>
> /**
>
>  * Returns true, whether the attached component to
> ListenerInterfaceRequestHandler is in form container.
>
>  * @param requestHandler
>
>  * @return
>
>  */
>
> private boolean isFormListenerInterfaceRequestHandler(final
> IRequestHandler requestHandler) {
>
> if (requestHandler instanceof ListenerInterfaceRequestHandler) {
>
> ListenerInterfaceRequestHandler
> listenerInterfaceRequestHandler = (ListenerInterfaceRequestHandler)
> requestHandler;
>
> IRequestableComponent c = listenerInterfaceRequestHandler
> .getComponent();
>
> if (c instanceof Form) {
>
> log.info("Form found!");
>
> return true;
>
> }
>
> }
>
> //else  if (requestHandler instanceof
> BookmarkableListenerInterfaceRequestHandler) {
>
> //BookmarkableListenerInterfaceRequestHandler  handler = (
> BookmarkableListenerInterfaceRequestHandler) requestHandler;
>
> //IRequestableComponent c = handler.getComponent();
>
> //if (c instanceof Form) {
>
> //log.info("Form found!");
>
> //return true;
>
> //}
>
> //}
>
>
>
>
>
>
> return false;
>
> }
>
> }
>
>
> However what I am finding is that any form on a stateless/bookmarkable
> page are not being encrypted. I tried to work around this with the section
> of code thats commented out (BookmarkableListenerInterfaceRequestHandler)
> . This then encrypts the form action fine, but then I get 2 bits of odd
> behaviour:
>
>
> - On pages that are bookmarkable, if there is a constructor that has
> PageParameters, the page is just recreated and the submit is ignored (when
> pressing submit).If I remove the PageParameter constructor then it works
> fine.
>
> - On stateless pages , again when submitting the form it just recreates
> the page
>
>
> public class SomeLoginPage extends WebPage {
>
>
> public SomeLoginPage() {
>
> setStatelessHint(true);
>
> add(new FeedbackPanel("feedback"));
>
> add(new SignInForm("signInForm").setOutputMarkupId(false));
>
>
> }
>
>
> public final class SignInForm extends StatelessForm {
>
>
> public SignInForm(final String id) {
>
> super(id, new CompoundPropertyModel(new ValueMap()));
>
>
> add(new TextField("username").setOutputMarkupId(false));
>
> add(new PasswordTextField("password").setOutputMarkupId(false));
>
> }
>
>
> /**
>
> *
>
> * @see org.apache.wicket.markup.html.form.Form#onSubmit()
>
> */
>
>
> public void onSubmit() {
>
> ValueMap values = getModelObject();
>
> String username = values.getString("username");
>
> String password = values.getString("

Re: CsrfPreventionRequestCycleListener or alternative CSRF protection

[Wayne W]

Hi Maxim, what are you using? CsrfPreventionRequestCycleListener?

On Tue, Sep 19, 2017 at 2:23 PM, Maxim Solodovnik <solomax...@gmail.com>
wrote:

> It works for us, but we are not using *CryptMapper's ...
>
> On Tue, Sep 19, 2017 at 7:49 PM, Wayne W <waynemailingli...@gmail.com>
> wrote:
> > Hi,
> >
> > does anyone else have an ideas whats I could do here. Is there anyone out
> > there who's successfully got the CSRF protection up and running in
> > production?
> >
> > On Fri, Sep 8, 2017 at 10:31 AM, Wayne W <waynemailingli...@gmail.com>
> > wrote:
> >
> >> Thanks Martin,
> >>
> >> so I've used this:
> >>
> >> setRootRequestMapper(new PostUrlCryptMapper(getRootRequestMapper(), new
> >> KeyInSessionSunJceCryptFactory()));
> >>
> >>
> >> public class PostUrlCryptMapper extends CryptoMapper {
> >>
> >> /**
> >>
> >>  * @param wrappedMapper
> >>
> >>  * @param cryptFactory
> >>
> >>  */
> >>
> >> private static Log log = LogFactory.getLog(PostUrlCryptMapper.class);
> >>
> >> public PostUrlCryptMapper(IRequestMapper wrappedMapper,
> >>
> >>   final KeyInSessionSunJceCryptFactory
> >> cryptFactory) {
> >>
> >> super(wrappedMapper, new IProvider() {
> >>
> >> @Override
> >>
> >> public ICrypt get() {
> >>
> >> return cryptFactory.newCrypt();
> >>
> >> }
> >>
> >> });
> >>
> >> }
> >>
> >>
> >> public Url mapHandler(final IRequestHandler requestHandler)
> >>
> >> {
> >>
> >> if (isFormListenerInterfaceRequestHandler(requestHandler)) {
> >>
> >> return super.mapHandler(requestHandler);
> >>
> >> } else {
> >>
> >> return getDelegateMapper().mapHandler(requestHandler);
> >>
> >> }
> >>
> >> }
> >>
> >>
> >> public IRequestHandler mapRequest(final Request request)
> >>
> >> {
> >>
> >> final IRequestHandler requestHandler = getDelegateMapper().
> >> mapRequest(request);
> >>
> >> if (requestHandler == null) {
> >>
> >> return super.mapRequest(request);
> >>
> >> }
> >>
> >> return requestHandler;
> >>
> >> }
> >>
> >>
> >> /**
> >>
> >>  * Returns true, whether the attached component to
> >> ListenerInterfaceRequestHandler is in form container.
> >>
> >>  * @param requestHandler
> >>
> >>  * @return
> >>
> >>  */
> >>
> >> private boolean isFormListenerInterfaceRequestHandler(final
> >> IRequestHandler requestHandler) {
> >>
> >> if (requestHandler instanceof ListenerInterfaceRequestHandler)
> {
> >>
> >> ListenerInterfaceRequestHandler
> >> listenerInterfaceRequestHandler = (ListenerInterfaceRequestHandler)
> >> requestHandler;
> >>
> >> IRequestableComponent c = listenerInterfaceRequestHandler
> >> .getComponent();
> >>
> >> if (c instanceof Form) {
> >>
> >> log.info("Form found!");
> >>
> >> return true;
> >>
> >> }
> >>
> >> }
> >>
> >> //else  if (requestHandler instanceof
> >> BookmarkableListenerInterfaceRequestHandler) {
> >>
> >> //BookmarkableListenerInterfaceRequestHandler  handler = (
> >> BookmarkableListenerInterfaceRequestHandler) requestHandler;
> >>
> >> //IRequestableComponent c = handler.getComponent();
> >>
> >> //if (c instanceof Form) {
> >>
> >> //log.info("Form found!");
> >>
> >> //return true;
> >>
> >> //}
> >>
> >> //}
> >>
> >>
> >>
> >>
> >>
> >>
> >> return false;
> >>
> >> }
> >>
> >> }
> >>
> >>
> >> However what I am finding is

Re: CsrfPreventionRequestCycleListener or alternative CSRF protection

[Wayne W]

Thanks Martin,

so I've used this:

setRootRequestMapper(new PostUrlCryptMapper(getRootRequestMapper(), new
KeyInSessionSunJceCryptFactory()));


public class PostUrlCryptMapper extends CryptoMapper {

/**

 * @param wrappedMapper

 * @param cryptFactory

 */

private static Log log = LogFactory.getLog(PostUrlCryptMapper.class);

public PostUrlCryptMapper(IRequestMapper wrappedMapper,

  final KeyInSessionSunJceCryptFactory
cryptFactory) {

super(wrappedMapper, new IProvider() {

@Override

public ICrypt get() {

return cryptFactory.newCrypt();

}

});

}


public Url mapHandler(final IRequestHandler requestHandler)

{

if (isFormListenerInterfaceRequestHandler(requestHandler)) {

return super.mapHandler(requestHandler);

} else {

return getDelegateMapper().mapHandler(requestHandler);

}

}


public IRequestHandler mapRequest(final Request request)

{

final IRequestHandler requestHandler =
getDelegateMapper().mapRequest(request);

if (requestHandler == null) {

return super.mapRequest(request);

}

return requestHandler;

}


/**

 * Returns true, whether the attached component to
ListenerInterfaceRequestHandler is in form container.

 * @param requestHandler

 * @return

 */

private boolean isFormListenerInterfaceRequestHandler(final
IRequestHandler requestHandler) {

if (requestHandler instanceof ListenerInterfaceRequestHandler) {

ListenerInterfaceRequestHandler  listenerInterfaceRequestHandler
= (ListenerInterfaceRequestHandler) requestHandler;

IRequestableComponent c = listenerInterfaceRequestHandler
.getComponent();

if (c instanceof Form) {

log.info("Form found!");

return true;

}

}

//else  if (requestHandler instanceof
BookmarkableListenerInterfaceRequestHandler) {

//BookmarkableListenerInterfaceRequestHandler  handler =
(BookmarkableListenerInterfaceRequestHandler) requestHandler;

//IRequestableComponent c = handler.getComponent();

//if (c instanceof Form) {

//log.info("Form found!");

//return true;

//}

//}






return false;

}

}


However what I am finding is that any form on a stateless/bookmarkable page
are not being encrypted. I tried to work around this with the section of
code thats commented out (BookmarkableListenerInterfaceRequestHandler) .
This then encrypts the form action fine, but then I get 2 bits of odd
behaviour:


- On pages that are bookmarkable, if there is a constructor that has
PageParameters, the page is just recreated and the submit is ignored (when
pressing submit).If I remove the PageParameter constructor then it works
fine.

- On stateless pages , again when submitting the form it just recreates the
page


public class SomeLoginPage extends WebPage {


public SomeLoginPage() {

setStatelessHint(true);

add(new FeedbackPanel("feedback"));

add(new SignInForm("signInForm").setOutputMarkupId(false));


}


public final class SignInForm extends StatelessForm {


public SignInForm(final String id) {

super(id, new CompoundPropertyModel(new ValueMap()));


add(new TextField("username").setOutputMarkupId(false));

add(new PasswordTextField("password").setOutputMarkupId(false));

}


/**

*

* @see org.apache.wicket.markup.html.form.Form#onSubmit()

*/


public void onSubmit() {

ValueMap values = getModelObject();

String username = values.getString("username");

String password = values.getString("password");


if (signIn(username, password)) {

((HubSession) Session.get()).setAdminAthenticated(true);

ContextUtil.get().setUser(null);


setResponsePage(CompanyAdminPage.class);


} else {

// Try the component based localizer first. If not found try the

// application localizer. Else use the default

error(getLocalizer().getString("exception.login", this, "Illegal username
password combo"));

}

}


private boolean signIn(String username, String password) {

// TODO authentication

return false;

}


}


}



Any ideas?



On Thu, Sep 7, 2017 at 11:33 AM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandle
> r#getComponent()
> instanceOf Form
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Thu, Sep 7, 2017 at 11:04 AM, Wayne W <waynemailingli...@gmail.com>
> wrote:
>
> > Thanks Martin,
> >
> > how can I tell for example if the IPageClassRequestHandler or
> > ListenerInterfaceRequestHandler is for a form?
> >
> > On Wed, Sep 6, 2017 at 12:39 PM, Martin Grigorov <mgrig

CsrfPreventionRequestCycleListener or alternative CSRF protection

[Wayne W]

Hi,

I've been trying to use CsrfPreventionRequestCycleListener in production.
However we are seeing in the logs that about 30 times a day we get the
request aborted because the clients browsers are not sending the referrer
header sometimes. Doing some research it seems we cannot rely on the
clients browser to send the referrer and it could be somewhat buggy in
older browsers.

Does anyone else experience this trouble?

Are there any alternatives?

I did try:

getSecuritySettings().setCryptFactory(new KeyInSessionSunJceCryptFactory());

setRootRequestMapper(new CryptoMapper(getRootRequestMapperAsCompound(),
this));

However this encrypts everything (resources, urls, etc). Is there a way of
just encrypting say forms and links or something?

Anyone got a solution that works for them in production?

many thanks

Re: CsrfPreventionRequestCycleListener or alternative CSRF protection

[Wayne W]

Thanks Martin,

how can I tell for example if the IPageClassRequestHandler or
ListenerInterfaceRequestHandler is for a form?

On Wed, Sep 6, 2017 at 12:39 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> Hi,
>
> I don't use any of these so I have no much experience in production with
> them!
>
> On Wed, Sep 6, 2017 at 12:07 PM, Wayne W <waynemailingli...@gmail.com>
> wrote:
>
> > Hi,
> >
> > I've been trying to use CsrfPreventionRequestCycleListener in
> production.
> > However we are seeing in the logs that about 30 times a day we get the
> > request aborted because the clients browsers are not sending the referrer
> > header sometimes. Doing some research it seems we cannot rely on the
> > clients browser to send the referrer and it could be somewhat buggy in
> > older browsers.
> >
> > Does anyone else experience this trouble?
> >
> > Are there any alternatives?
> >
> > I did try:
> >
> > getSecuritySettings().setCryptFactory(new KeyInSessionSunJceCryptFactory
> > ());
> >
> > setRootRequestMapper(new CryptoMapper(getRootRequestMapperAsCompound(),
> > this));
> >
> > However this encrypts everything (resources, urls, etc). Is there a way
> of
> > just encrypting say forms and links or something?
> >
>
> You can override CryptoMapper#mapHandler() and call super.mapHandler() only
> when the IRequestHandler is not an instance of IPageClassRequestHandler or
> only when it is ListenerInterfaceRequestHandler.
>
>
> >
> > Anyone got a solution that works for them in production?
> >
> > many thanks
> >
>

Very slow shutdown at org.apache.wicket.pageStore.AbstractPageStore.destroy

[Wayne W]

Hi,

we've started to experience very slow shutdown of our tomcat instances in
production. Doing a thread dump I see:

"localhost-startStop-2" #14871 daemon prio=5 os_prio=64
tid=0x06700800 nid=0x3a37 runnable [0xfcffcc5fd000]
   java.lang.Thread.State: RUNNABLE
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(FileOutputStream.java:326)
at
java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1877)
at
java.io.ObjectOutputStream$BlockDataOutputStream.write(ObjectOutputStream.java:1841)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1534)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
at java.util.HashMap.internalWriteEntries(HashMap.java:1785)
at java.util.HashMap.writeObject(HashMap.java:1362)
at sun.reflect.GeneratedMethodAccessor299.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:1028)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
at
org.apache.wicket.pageStore.DiskDataStore.saveIndex(DiskDataStore.java:270)
at
org.apache.wicket.pageStore.DiskDataStore.destroy(DiskDataStore.java:106)
at
org.apache.wicket.pageStore.AsynchronousDataStore.destroy(AsynchronousDataStore.java:118)
at
org.apache.wicket.pageStore.AbstractPageStore.destroy(AbstractPageStore.java:53)
at
org.apache.wicket.pageStore.AbstractCachingPageStore.destroy(AbstractCachingPageStore.java:102)
at
org.apache.wicket.page.PageStoreManager.destroy(PageStoreManager.java:464)
at
org.apache.wicket.Application.internalDestroy(Application.java:798)
at
org.apache.wicket.protocol.http.WebApplication.internalDestroy(WebApplication.java:703)
at
org.apache.wicket.protocol.http.WicketFilter.destroy(WicketFilter.java:612)
at
org.apache.catalina.core.ApplicationFilterConfig.release(ApplicationFilterConfig.java:313)
at
org.apache.catalina.core.StandardContext.filterStop(StandardContext.java:4600)
- locked <0x000703c91570> (a java.util.HashMap)
at
org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5362)
- locked <0x000703c91368> (a
org.apache.catalina.core.StandardContext)
at
org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
- locked <0x000703c91368> (a
org.apache.catalina.core.StandardContext)
at
org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1425)
at
org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1414)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)


We do have replication setup, but I'm sure that this has only just started
happening in the last week or so. What could cause this and is there
anything I could do?

Re: Very slow shutdown at org.apache.wicket.pageStore.AbstractPageStore.destroy

[Wayne W]

HI Martin,

no changes which is odd. I can;t be certain 100% when this behaviour
started. Perhaps when we changed to 7.8.0 a while back, but I'm pretty sure
its only be happening the last week or so.
Is this code basically saving all the sessions to disk on shutdown? Is this
necessary given replication is configured as all sessions are replicate
when it starts up?

thanks


On Tue, Sep 26, 2017 at 10:07 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> On Tue, Sep 26, 2017 at 10:35 PM, Wayne W <waynemailingli...@gmail.com>
> wrote:
>
> > Hi,
> >
> > we've started to experience very slow shutdown of our tomcat instances in
> > production. Doing a thread dump I see:
> >
> > "localhost-startStop-2" #14871 daemon prio=5 os_prio=64
> > tid=0x06700800 nid=0x3a37 runnable [0xfcffcc5fd000]
> >java.lang.Thread.State: RUNNABLE
> > at java.io.FileOutputStream.writeBytes(Native Method)
> > at java.io.FileOutputStream.write(FileOutputStream.java:326)
> > at
> > java.io.ObjectOutputStream$BlockDataOutputStream.drain(
> > ObjectOutputStream.java:1877)
> > at
> > java.io.ObjectOutputStream$BlockDataOutputStream.write(
> > ObjectOutputStream.java:1841)
> > at
> > java.io.ObjectOutputStream.defaultWriteFields(
> > ObjectOutputStream.java:1534)
> > at
> > java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> > at
> > java.io.ObjectOutputStream.writeOrdinaryObject(
> > ObjectOutputStream.java:1432)
> > at
> > java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> > at
> > java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> > at java.util.HashMap.internalWriteEntries(HashMap.java:1785)
> > at java.util.HashMap.writeObject(HashMap.java:1362)
> > at sun.reflect.GeneratedMethodAccessor299.invoke(Unknown Source)
> > at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(
> > DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:498)
> > at
> > java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:1028)
> > at
> > java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
> > at
> > java.io.ObjectOutputStream.writeOrdinaryObject(
> > ObjectOutputStream.java:1432)
> > at
> > java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> > at
> > java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> > at
> > org.apache.wicket.pageStore.DiskDataStore.saveIndex(
> > DiskDataStore.java:270)
> > at
> > org.apache.wicket.pageStore.DiskDataStore.destroy(
> DiskDataStore.java:106)
> > at
> > org.apache.wicket.pageStore.AsynchronousDataStore.destroy(
> > AsynchronousDataStore.java:118)
> > at
> > org.apache.wicket.pageStore.AbstractPageStore.destroy(
> > AbstractPageStore.java:53)
> > at
> > org.apache.wicket.pageStore.AbstractCachingPageStore.destroy(
> > AbstractCachingPageStore.java:102)
> > at
> > org.apache.wicket.page.PageStoreManager.destroy(
> PageStoreManager.java:464)
> > at
> > org.apache.wicket.Application.internalDestroy(Application.java:798)
> > at
> > org.apache.wicket.protocol.http.WebApplication.internalDestroy(
> > WebApplication.java:703)
> > at
> > org.apache.wicket.protocol.http.WicketFilter.destroy(
> > WicketFilter.java:612)
> > at
> > org.apache.catalina.core.ApplicationFilterConfig.release(
> > ApplicationFilterConfig.java:313)
> > at
> > org.apache.catalina.core.StandardContext.filterStop(
> > StandardContext.java:4600)
> > - locked <0x000703c91570> (a java.util.HashMap)
> > at
> > org.apache.catalina.core.StandardContext.stopInternal(
> > StandardContext.java:5362)
> > - locked <0x000703c91368> (a
> > org.apache.catalina.core.StandardContext)
> > at
> > org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
> > - locked <0x000703c91368> (a
> > org.apache.catalina.core.StandardContext)
> > at
> > org.apache.catalina.core.ContainerBase$StopChild.call(
> > ContainerBase.java:1425)
> > at
> > org.apache.catalina.core.ContainerBase$StopChild.call(
> > ContainerBase.java:1414)
> > at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> > at
> > java.util.concurrent.ThreadPoolExecutor.runWorker(
> > ThreadPoolExecutor.java:1142)
> > at
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(
> > ThreadPoolExecutor.java:617)
> > at java.lang.Thread.run(Thread.java:745)
> >
> >
> > We do have replication setup, but I'm sure that this has only just
> started
> > happening in the last week or so. What could cause this and is there
> > anything I could do?
> >
>
> Did you change anything in the last week ?
> Did you upgrade Wicket ? To which version ?
>

getOutputStream() has already been called for this response

[Wayne W]

Hi,

we have a lot of these in our production logs:

java.lang.IllegalStateException: getOutputStream() has already been called
for this response
at
org.apache.catalina.connector.Response.getWriter(Response.java:578)
at
org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java:212)
at
javax.servlet.ServletResponseWrapper.getWriter(ServletResponseWrapper.java:109)
at
org.apache.wicket.protocol.http.servlet.ServletWebResponse.write(ServletWebResponse.java:110)
at
org.apache.wicket.protocol.http.HeaderBufferingWebResponse.write(HeaderBufferingWebResponse.java:179)
at
org.apache.wicket.protocol.http.BufferedWebResponse$WriteCharSequenceAction.invoke(BufferedWebResponse.java:171)
at
org.apache.wicket.protocol.http.BufferedWebResponse.writeTo(BufferedWebResponse.java:602)
at
org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:198)
at
org.apache.wicket.core.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:175)
at
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:895)
at
org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
at
org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:314)
at
org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:323)
at
org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:323)
at
org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:323)
at
org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:323)
at
org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:323)
at
org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:323)
at
org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:323)
at
org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:323)
at
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:237)
at
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:293)
at
org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:261)
at
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:203)
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:284)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)


What cab cause these and what should we do?

We also get lots of these (but not as many)

java.lang.IllegalStateException: Cannot call sendRedirect() after the
response has been committed
at
org.apache.catalina.connector.ResponseFacade.sendRedirect(ResponseFacade.java:494)
at
javax.servlet.http.HttpServletResponseWrapper.sendRedirect(HttpServletResponseWrapper.java:138)
at
hub.app.servlet.RelativeUrlFilter$RelativeUrlServletResponseFilter.sendRedirect(RelativeUrlFilter.java:111)
at
org.apache.wicket.protocol.http.servlet.ServletWebResponse.sendRedirect(ServletWebResponse.java:288)
at
org.apache.wicket.protocol.http.HeaderBufferingWebResponse.sendRedirect(HeaderBufferingWebResponse.java:117)
at
org.apache.wicket.request.handler.render.WebPageRenderer.redirectTo(WebPageRenderer.java:161)
at
org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:280)
at
org.apache.wicket.core.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:175)
at
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:895)
at
org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
at
org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:314)
at
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:237)
at
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:293)
at
org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:261)
at
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:203)
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:284)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
at

Re: Possible memory leak with Tomcat?

[Wayne W]

Hello Sven,

the fix you did for WICKET-6564 (
https://git-wip-us.apache.org/repos/asf?p=wicket.git;a=commitdiff;h=7665dc5;hp=3a1602d308a366e00948dbf91dbd96bc40cae167)
doesn't work for us. Its causing lots of issues. We use redisson for
managing our sessions in tomcat, so that we can failover without loosing
user session.

When a session attribute is updated redisson calls setAttribute on the
session. Looking at the code for
org.apache.catalina.session.StandardSession.setAttribute I see:

// Replace or add this attribute

Object unbound = attributes.put(name, value);


// Call the valueUnbound() method if necessary

*if* (notify && (unbound != *null*) && (unbound != value) &&

(unbound *instanceof* HttpSessionBindingListener)) {

*try* {

((HttpSessionBindingListener) unbound).valueUnbound

(*new* HttpSessionBindingEvent(getSession(), name));

} *catch* (Throwable t) {

ExceptionUtils.*handleThrowable*(t);

manager.getContext().getLogger().error

(*sm*.getString("standardSession.bindingEvent"), t);

}

}

The valueUnbound is call to notify the object its no longer in the session.
However looking at the change you did for
PageStoreManager.valueUnbound its actually
removing the session by calling clear()

Doesn't seem correct?? or am I missing something?



On Fri, May 10, 2019 at 1:43 PM Wayne W  wrote:

> Thanks Sven.
>
> On Thu, May 9, 2019 at 8:24 PM Sven Meier  wrote:
>
>> Hi,
>>
>> we've had two fixed related to page stores (WICKET-6457, WICKET-6564) so
>> please upgrade to 7.13.0 first.
>>
>> Have fun
>> Sven
>>
>>
>> Am 09.05.19 um 21:10 schrieb Wayne W:
>> > Hi,
>> >
>> > I've take a memory dump of one of our production instances and I'm
>> seeing
>> > about 500MB of memory consumed just by the DiskDataStore which doesn't
>> seem
>> > correct to me. Here is a screen shot:
>> >
>> https://customerservices.glasscubes.com/share/s/qmvnvrdtm36amme6sdrqg4dp2g
>> >
>> > I've highlighted the item - 524,288 items doesn't seem correct for ~500
>> > http sessions?. It seems to me that removeData(*final* String
>> sessionId) is
>> > probably not being called and clearing up the sessionEntryMap. Looking
>> at
>> > the call hierarchy I can see how Jetty calls it but I cannot see how
>> tomcat
>> > is calling it.
>> >
>> > Any ideas whats happening?
>> > Wicket 7.8.0, Tomcat 8.0.32
>> >
>> > Thanks
>> >
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>

Possible memory leak with Tomcat?

[Wayne W]

Hi,

I've take a memory dump of one of our production instances and I'm seeing
about 500MB of memory consumed just by the DiskDataStore which doesn't seem
correct to me. Here is a screen shot:
https://customerservices.glasscubes.com/share/s/qmvnvrdtm36amme6sdrqg4dp2g

I've highlighted the item - 524,288 items doesn't seem correct for ~500
http sessions?. It seems to me that removeData(*final* String sessionId) is
probably not being called and clearing up the sessionEntryMap. Looking at
the call hierarchy I can see how Jetty calls it but I cannot see how tomcat
is calling it.

Any ideas whats happening?
Wicket 7.8.0, Tomcat 8.0.32

Thanks

7.14.0 release

[Wayne W]

Hi,

Is there timeframe for this release?

Thanks!
Wayne

Re: 7.14.0 release

[Wayne W]

Ok thanks. So soon then hopefully!!

On Wed, May 22, 2019 at 3:37 PM Andrea Del Bene 
wrote:

> yes. 8.5.0 and 7.14.0 go hand in hand together :-)
>
> see
>
> http://apache-wicket.1842946.n4.nabble.com/Wicket-8-5-0-ready-td4682248.html
>
> On Wed, May 22, 2019 at 4:27 PM Wayne W 
> wrote:
>
> > Hi,
> >
> > Is there timeframe for this release?
> >
> > Thanks!
> > Wayne
> >
>
>
> --
> Andrea Del Bene.
> Apache Wicket committer.
>