Re: WebSocket concurrent modification

[Martin Grigorov]

On Thu, May 28, 2020 at 9:43 AM fanfy  wrote:

> Hello,I finally found the problem ... It seems that I didn't understood
> very
> well how to use WebSocketMessageBroadcaster from wicket-spring-boot. The
> proper way to broadcast websocket messages from an ajax call is to use
> org.apache.wicket.protocol.ws.api.WebSocketPushBroadcaster with an
> additional configuration of the Executor that must broadcast the messages
> using a separate threadFor example, if using springframework (with wicket
> application as a bean) you must configure the executor:
> java.util.concurrent.Executor executor =
> Executors.newSingleThreadExecutor();
>
> WebSocketSettings.Holder.get(webApplication).setWebSocketPushMessageExecutor(new
> Executor() {@Override
>  public void run(Runnable command) {
> executor.execute(command);  }   });
> To broadcast messages from business code you can use spring events
> (published from your business code) To broadcast from ajax handlers inject
> this bean and call broadcastToAll(event) directly.
> /** *  * @author Elvis Ciocoiu * */@Componentpublic class
> TaskEventWebSocketBroadcaster { private WebSocketPushBroadcaster
> broadcaster;@Autowired private Application application;
>  @PostConstruct
> public void init() {WebSocketSettings webSocketSettings =
> WebSocketSettings.Holder.get(application);
> IWebSocketConnectionRegistry
> webSocketConnectionRegistry = webSocketSettings.getConnectionRegistry();
>
> broadcaster = new WebSocketPushBroadcaster(webSocketConnectionRegistry);
>   }
> @EventListener  public void onTaskEvent(TaskEvent taskEvent) {
> broadcastToAll(taskEvent);  }   public void
> broadcastToAll(TaskEvent
> taskEvent) {broadcaster.broadcastAll(application, new
> TaskEventWebSocketPushMessage(taskEvent));  }   /**
> *   * @author Elvis
> Ciocoiu  *   */ public static class TaskEventWebSocketPushMessage
> implements
> IWebSocketPushMessage { private static final long serialVersionUID
> = 1L;
> private TaskEvent taskEvent;public
> TaskEventWebSocketPushMessage(TaskEvent taskEvent) {
> this.taskEvent =
> taskEvent;  }   public TaskEvent
> getTaskEvent() {   return taskEvent;   }
>}}
> I think these distinct scenarios (broadcast from ajaxhandler and from
> business thread) should be documented a little more in user guide. Sorry to
> waste your time.Thank you
>

https://issues.apache.org/jira/browse/WICKET-6791
https://github.com/apache/wicket/pull/435
Thank you!


>
> --
> Sent from:
> http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: WebSocket concurrent modification

[fanfy]

Updated the sample application  websocket-test.tar
<http://apache-wicket.1842946.n4.nabble.com/file/t375849/websocket-test.tar>  

--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html

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

Re: WebSocket concurrent modification

[fanfy]

Hello,I finally found the problem ... It seems that I didn't understood very
well how to use WebSocketMessageBroadcaster from wicket-spring-boot. The
proper way to broadcast websocket messages from an ajax call is to use
org.apache.wicket.protocol.ws.api.WebSocketPushBroadcaster with an
additional configuration of the Executor that must broadcast the messages
using a separate threadFor example, if using springframework (with wicket
application as a bean) you must configure the executor:
java.util.concurrent.Executor executor =
Executors.newSingleThreadExecutor();
WebSocketSettings.Holder.get(webApplication).setWebSocketPushMessageExecutor(new
Executor() {@Override   
public void run(Runnable command) { 
executor.execute(command);  }   });
To broadcast messages from business code you can use spring events
(published from your business code) To broadcast from ajax handlers inject
this bean and call broadcastToAll(event) directly. 
/** *  * @author Elvis Ciocoiu * */@Componentpublic class
TaskEventWebSocketBroadcaster { private WebSocketPushBroadcaster
broadcaster;@Autowired private Application application; 
@PostConstruct
public void init() {WebSocketSettings webSocketSettings =
WebSocketSettings.Holder.get(application);  
IWebSocketConnectionRegistry
webSocketConnectionRegistry = webSocketSettings.getConnectionRegistry();
broadcaster = new WebSocketPushBroadcaster(webSocketConnectionRegistry);
}   
@EventListener  public void onTaskEvent(TaskEvent taskEvent) {  
broadcastToAll(taskEvent);  }   public void 
broadcastToAll(TaskEvent
taskEvent) {broadcaster.broadcastAll(application, new
TaskEventWebSocketPushMessage(taskEvent));  }   /**  *  
 * @author Elvis
Ciocoiu  *   */ public static class TaskEventWebSocketPushMessage 
implements
IWebSocketPushMessage { private static final long serialVersionUID = 
1L;
private TaskEvent taskEvent;public
TaskEventWebSocketPushMessage(TaskEvent taskEvent) {
this.taskEvent =
taskEvent;  }   public TaskEvent 
getTaskEvent() {   return taskEvent;   }   
}}
I think these distinct scenarios (broadcast from ajaxhandler and from
business thread) should be documented a little more in user guide. Sorry to
waste your time.Thank you

--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html

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

Re: WebSocket concurrent modification

[Sven Meier]

Hi,

I can reproduce the problem, but don't know yet what is causing this.

What I can see is that the page is properly locked when being accessed 
via Ajax or via a web socket push.

Thus a concurrent modification should not occur.

I'll have to investigate further.

Have fun
Sven


On 20.05.20 09:59, fanfy wrote:

Hello,

Maybe you can help me with a problem related to wicket 8.8.0 with websocket.
Sometimes (usually when there are many ajax request in a short time
interval) I encounter ConcurrentModificationException. The page store saving
is synchronous. I created a sample project (attached  websocket-test.tar
<http://apache-wicket.1842946.n4.nabble.com/file/t375849/websocket-test.tar>
)

mvn package
java -jar target/websocket-test-0.0.1-SNAPSHOT.jar
http://localhost:8080/)

If clicking multiple times on 'New message' AjaxLink soon the exception is
thrown. Internally I have a timer that creates messages on 50 milliseconds
frequency (may be changed in src/main/resources/application.properties -
fanfy.messsage-generator-frequency=50)

Below is a sample stacktrace.

Thank you.

2020-05-20 10:43:55.241 ERROR 246999 --- [nio-8080-exec-1]
o.apache.wicket.DefaultExceptionMapper   : Unexpected error occurred

java.util.ConcurrentModificationException: null
at
org.apache.commons.collections4.map.AbstractLinkedMap$LinkIterator.nextEntry(AbstractLinkedMap.java:574)
~[commons-collections4-4.4.jar!/:4.4]
at
org.apache.commons.collections4.map.AbstractLinkedMap$ValuesIterator.next(AbstractLinkedMap.java:506)
~[commons-collections4-4.4.jar!/:4.4]
at
org.apache.wicket.MarkupContainer$1MarkupChildIterator.refreshInternalIteratorIfNeeded(MarkupContainer.java:624)
~[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.MarkupContainer$1MarkupChildIterator.hasNext(MarkupContainer.java:573)
~[wicket-core-8.8.0.jar!/:8.8.0]
at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:134)
~[wicket-util-8.8.0.jar!/:8.8.0]
at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162)
~[wicket-util-8.8.0.jar!/:8.8.0]
at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162)
~[wicket-util-8.8.0.jar!/:8.8.0]
at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162)
~[wicket-util-8.8.0.jar!/:8.8.0]
at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:123)
~[wicket-util-8.8.0.jar!/:8.8.0]
at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:192)
~[wicket-util-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:976)
~[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.ComponentEventSender.breadth(ComponentEventSender.java:160)
~[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.ComponentEventSender.send(ComponentEventSender.java:68)
~[wicket-core-8.8.0.jar!/:8.8.0]
at org.apache.wicket.Component.send(Component.java:4413)
~[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.ajax.AjaxRequestHandler.respond(AjaxRequestHandler.java:349)
~[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:914)
~[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.request.RequestHandlerExecutor.execute(RequestHandlerExecutor.java:65)
~[wicket-request-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:282)
[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:253)
[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:221)
[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.protocol.ws.AbstractUpgradeFilter.processRequestCycle(AbstractUpgradeFilter.java:70)
[wicket-native-websocket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:206)
[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:299)
[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
[tomcat-embed-core-9.0.35.jar!/:9.0.35]
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
[tomcat-embed-core-9.0.35.jar!/:9.0.35]
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202)
[tomcat-embed-core-9.0.35.jar!/:9.0.35]
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
[tomcat-embed-core-9.0.35.jar!/:9.0.35]
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541)
[tomcat-embed-core-9.0.35.jar!/:9.0.35]
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
[tomcat-embed-core-9.0.35.jar!/:

WebSocket concurrent modification

[fanfy]

Hello,

Maybe you can help me with a problem related to wicket 8.8.0 with websocket.
Sometimes (usually when there are many ajax request in a short time
interval) I encounter ConcurrentModificationException. The page store saving
is synchronous. I created a sample project (attached  websocket-test.tar
<http://apache-wicket.1842946.n4.nabble.com/file/t375849/websocket-test.tar> 
)

mvn package
java -jar target/websocket-test-0.0.1-SNAPSHOT.jar
http://localhost:8080/)

If clicking multiple times on 'New message' AjaxLink soon the exception is
thrown. Internally I have a timer that creates messages on 50 milliseconds
frequency (may be changed in src/main/resources/application.properties -
fanfy.messsage-generator-frequency=50)  

Below is a sample stacktrace.

Thank you.

2020-05-20 10:43:55.241 ERROR 246999 --- [nio-8080-exec-1]
o.apache.wicket.DefaultExceptionMapper   : Unexpected error occurred

java.util.ConcurrentModificationException: null
at
org.apache.commons.collections4.map.AbstractLinkedMap$LinkIterator.nextEntry(AbstractLinkedMap.java:574)
~[commons-collections4-4.4.jar!/:4.4]
at
org.apache.commons.collections4.map.AbstractLinkedMap$ValuesIterator.next(AbstractLinkedMap.java:506)
~[commons-collections4-4.4.jar!/:4.4]
at
org.apache.wicket.MarkupContainer$1MarkupChildIterator.refreshInternalIteratorIfNeeded(MarkupContainer.java:624)
~[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.MarkupContainer$1MarkupChildIterator.hasNext(MarkupContainer.java:573)
~[wicket-core-8.8.0.jar!/:8.8.0]
at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:134)
~[wicket-util-8.8.0.jar!/:8.8.0]
at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162)
~[wicket-util-8.8.0.jar!/:8.8.0]
at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162)
~[wicket-util-8.8.0.jar!/:8.8.0]
at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162)
~[wicket-util-8.8.0.jar!/:8.8.0]
at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:123)
~[wicket-util-8.8.0.jar!/:8.8.0]
at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:192)
~[wicket-util-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:976)
~[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.ComponentEventSender.breadth(ComponentEventSender.java:160)
~[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.ComponentEventSender.send(ComponentEventSender.java:68)
~[wicket-core-8.8.0.jar!/:8.8.0]
at org.apache.wicket.Component.send(Component.java:4413)
~[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.ajax.AjaxRequestHandler.respond(AjaxRequestHandler.java:349)
~[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:914)
~[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.request.RequestHandlerExecutor.execute(RequestHandlerExecutor.java:65)
~[wicket-request-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:282)
[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:253)
[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:221)
[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.protocol.ws.AbstractUpgradeFilter.processRequestCycle(AbstractUpgradeFilter.java:70)
[wicket-native-websocket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:206)
[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:299)
[wicket-core-8.8.0.jar!/:8.8.0]
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
[tomcat-embed-core-9.0.35.jar!/:9.0.35]
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
[tomcat-embed-core-9.0.35.jar!/:9.0.35]
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202)
[tomcat-embed-core-9.0.35.jar!/:9.0.35]
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
[tomcat-embed-core-9.0.35.jar!/:9.0.35]
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541)
[tomcat-embed-core-9.0.35.jar!/:9.0.35]
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
[tomcat-embed-core-9.0.35.jar!/:9.0.35]
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
[tomcat-embed-core-9.0.35.jar!/:9.0.35]
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
[tomcat-embed-core-9.0.35.jar!/:

Re: WebSocket onClose/onError/onAbort is not being called

[Maxim Solodovnik]

Thanks Martin!

https://issues.apache.org/jira/browse/WICKET-6782
will create PR in a moment :)

On Wed, 6 May 2020 at 00:22, Martin Grigorov  wrote:

> Hi Maxim,
>
> On Fri, May 1, 2020 at 2:22 PM Maxim Solodovnik 
> wrote:
>
> > On Fri, 1 May 2020 at 18:15, Martin Grigorov 
> wrote:
> >
> > > Hi Maxim,
> > >
> > > On Fri, May 1, 2020 at 1:31 PM Maxim Solodovnik 
> > > wrote:
> > >
> > > > Hello Martin,
> > > >
> > > > WicketEndpoint#onError is being called
> > > >  "*ERROR* 05-01 16:10:21.740 o.a.w.p.w.j.WicketEndpoint:100
> > > > [EventExec-e2-t9] - An error occurred in web socket connection with
> id
> > :
> > > > 10"
> > > >
> > > > The problem WebSocketBehavior#onError is not being called
> > > > So my application doesn't get notified the connection has been closed
> > > 
> > > >
> > >
> > > Then it must be somewhere in Wicket.
> > > Check that [2] is called.
> > >
> >
> > Yes it is called
> >
> >
> > > Then [3], then [4]. From here on it is Wicket Event propagation [5]. It
> > >
> >
> > [3] and [4] are not called
> > As you can see from the log branch at
> >
> >
> https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L299
> > is in effect:
> >
>
> At
>
> https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L223
> we
> check
> whether the connection is still opened or it is a ClosedMessage.
> ClosedMessage is broadcasted exactly for this reason:
>
> https://github.com/apache/wicket/commit/ffa34c6bfbd2ccd8340e23ff1601edd3e0e941d6
> We should simplify this condition to allow ErrorMessage too. Maybe even
> AbortedMessage.
> For the erroneous kind of messages we can even remove the connection from
> the registry at the bottom of this method.
> Please play with it and suggest a change!
>
> Martin
>
>
> > DEBUG 05-01 16:10:21.741 o.a.w.p.w.a.AbstractWebSocketProcessor:299
> > [EventExec-e2-t9] - Either there is no
> >
> >
> connection(org.apache.wicket.protocol.ws.javax.JavaxWebSocketConnection@43539f89
> > )
> > or it is closed.
> >
> >
> >
> >
> > > won't find your behavior if it is not enabled or any of if its
> component
> > > hierarchy is disabled/invisible.
> > >
> > >
> > > 2.
> > >
> > >
> >
> https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L202
> > > 3.
> > >
> > >
> >
> https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L272
> > > 4. *
> > >
> >
> https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/WebSocketMessageBroadcastHandler.java#L69
> > > <
> > >
> >
> https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/WebSocketMessageBroadcastHandler.java#L69
> > > >*
> > > 5.
> > >
> > >
> >
> https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/WebSocketBehavior.java#L86
> > >
> > >
> > > > :(
> > > >
> > > > On Fri, 1 May 2020 at 17:12, Martin Grigorov 
> > > wrote:
> > > >
> > > > > Hi Maxim,
> > > > >
> > > > > If WicketEndpoint#onError() [1] is not called then probably there
> is
> > a
> > > > bug
> > > > > in Tomcat.
> > > > > I suggest you to post this question at Tomcat's users@.
> > > > >
> > > > > 1.
> > > > >
>

Re: WebSocket onClose/onError/onAbort is not being called

[Martin Grigorov]

Hi Maxim,

On Fri, May 1, 2020 at 2:22 PM Maxim Solodovnik 
wrote:

> On Fri, 1 May 2020 at 18:15, Martin Grigorov  wrote:
>
> > Hi Maxim,
> >
> > On Fri, May 1, 2020 at 1:31 PM Maxim Solodovnik 
> > wrote:
> >
> > > Hello Martin,
> > >
> > > WicketEndpoint#onError is being called
> > >  "*ERROR* 05-01 16:10:21.740 o.a.w.p.w.j.WicketEndpoint:100
> > > [EventExec-e2-t9] - An error occurred in web socket connection with id
> :
> > > 10"
> > >
> > > The problem WebSocketBehavior#onError is not being called
> > > So my application doesn't get notified the connection has been closed
> > 
> > >
> >
> > Then it must be somewhere in Wicket.
> > Check that [2] is called.
> >
>
> Yes it is called
>
>
> > Then [3], then [4]. From here on it is Wicket Event propagation [5]. It
> >
>
> [3] and [4] are not called
> As you can see from the log branch at
>
> https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L299
> is in effect:
>

At
https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L223
we
check
whether the connection is still opened or it is a ClosedMessage.
ClosedMessage is broadcasted exactly for this reason:
https://github.com/apache/wicket/commit/ffa34c6bfbd2ccd8340e23ff1601edd3e0e941d6
We should simplify this condition to allow ErrorMessage too. Maybe even
AbortedMessage.
For the erroneous kind of messages we can even remove the connection from
the registry at the bottom of this method.
Please play with it and suggest a change!

Martin


> DEBUG 05-01 16:10:21.741 o.a.w.p.w.a.AbstractWebSocketProcessor:299
> [EventExec-e2-t9] - Either there is no
>
> connection(org.apache.wicket.protocol.ws.javax.JavaxWebSocketConnection@43539f89
> )
> or it is closed.
>
>
>
>
> > won't find your behavior if it is not enabled or any of if its component
> > hierarchy is disabled/invisible.
> >
> >
> > 2.
> >
> >
> https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L202
> > 3.
> >
> >
> https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L272
> > 4. *
> >
> https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/WebSocketMessageBroadcastHandler.java#L69
> > <
> >
> https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/WebSocketMessageBroadcastHandler.java#L69
> > >*
> > 5.
> >
> >
> https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/WebSocketBehavior.java#L86
> >
> >
> > > :(
> > >
> > > On Fri, 1 May 2020 at 17:12, Martin Grigorov 
> > wrote:
> > >
> > > > Hi Maxim,
> > > >
> > > > If WicketEndpoint#onError() [1] is not called then probably there is
> a
> > > bug
> > > > in Tomcat.
> > > > I suggest you to post this question at Tomcat's users@.
> > > >
> > > > 1.
> > > >
> > > >
> > >
> >
> https://github.com/apache/wicket/blob/master/wicket-native-websocket/wicket-native-websocket-javax/src/main/java/org/apache/wicket/protocol/ws/javax/WicketEndpoint.java#L92
> > > >
> > > >
> > > > On Fri, May 1, 2020 at 12:21 PM Maxim Solodovnik <
> solomax...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > I'm having weird situation: WebSocket connection is closed on page
> > > > reload,
> > > > > but none of my onClose/onError/onAbort handlers are being called
> > > > > I have changed wicket version to latest SNAPSHOT and got some debug
> > > logs:
> > > > >
> > 

Re: WebSocket onClose/onError/onAbort is not being called

[Maxim Solodovnik]

Here are some more details on this issue

In our code I'm using IWebSocketConnection.sendMessage(String) method
The call is wrapped with try/catch to correctly handle any exception [1]

The problem is hard to reproduce due to IOException should happen exactly
at time of sendMessage do it's job
(in original report author hammer the page with F5 until error will occur)

As a result my try/catch doesn't play, I got "zombie" IWebSocketConnection
in IWebSocketConnectionRegistry
and incorrect application state due to I'm expecting to get disconnect
from onClose/onError/onAbort of my WebSocketBehavior

I see no other option than create periodic task to check for "zombies"
in IWebSocketConnectionRegistry
and restore application state
Are there any other options?

[1]
https://github.com/apache/openmeetings/blob/master/openmeetings-core/src/main/java/org/apache/openmeetings/core/util/WebSocketHelper.java#L76

On Fri, 1 May 2020 at 18:21, Maxim Solodovnik  wrote:

>
> On Fri, 1 May 2020 at 18:15, Martin Grigorov  wrote:
>
>> Hi Maxim,
>>
>> On Fri, May 1, 2020 at 1:31 PM Maxim Solodovnik 
>> wrote:
>>
>> > Hello Martin,
>> >
>> > WicketEndpoint#onError is being called
>> >  "*ERROR* 05-01 16:10:21.740 o.a.w.p.w.j.WicketEndpoint:100
>> > [EventExec-e2-t9] - An error occurred in web socket connection with id :
>> > 10"
>> >
>> > The problem WebSocketBehavior#onError is not being called
>> > So my application doesn't get notified the connection has been closed
>> 
>> >
>>
>> Then it must be somewhere in Wicket.
>> Check that [2] is called.
>>
>
> Yes it is called
>
>
>> Then [3], then [4]. From here on it is Wicket Event propagation [5]. It
>>
>
> [3] and [4] are not called
> As you can see from the log branch at
>
> https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L299
> is in effect:
>
> DEBUG 05-01 16:10:21.741 o.a.w.p.w.a.AbstractWebSocketProcessor:299 
> [EventExec-e2-t9] - Either there is no 
> connection(org.apache.wicket.protocol.ws.javax.JavaxWebSocketConnection@43539f89)
>  or it is closed.
>
>
>
>
>> won't find your behavior if it is not enabled or any of if its component
>> hierarchy is disabled/invisible.
>>
>>
>> 2.
>>
>> https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L202
>> 3.
>>
>> https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L272
>> 4. *
>> https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/WebSocketMessageBroadcastHandler.java#L69
>> <
>> https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/WebSocketMessageBroadcastHandler.java#L69
>> >*
>> 5.
>>
>> https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/WebSocketBehavior.java#L86
>>
>>
>> > :(
>> >
>> > On Fri, 1 May 2020 at 17:12, Martin Grigorov 
>> wrote:
>> >
>> > > Hi Maxim,
>> > >
>> > > If WicketEndpoint#onError() [1] is not called then probably there is a
>> > bug
>> > > in Tomcat.
>> > > I suggest you to post this question at Tomcat's users@.
>> > >
>> > > 1.
>> > >
>> > >
>> >
>> https://github.com/apache/wicket/blob/master/wicket-native-websocket/wicket-native-websocket-javax/src/main/java/org/apache/wicket/protocol/ws/javax/WicketEndpoint.java#L92
>> > >
>> > >
>> > > On Fri, May 1, 2020 at 12:21 PM Maxim Solodovnik <
>> solomax...@gmail.com>
>> > > wrote:
>> > >
>> > > > Hello,
>> > > >
>> > > > I'm having weird situation: WebSocket connection is closed on page
>> > > reload,
>> > > > but none of my onClose/onError/onAbort handlers are being called
>> > > > I have change

Re: WebSocket onClose/onError/onAbort is not being called

[Maxim Solodovnik]

On Fri, 1 May 2020 at 18:15, Martin Grigorov  wrote:

> Hi Maxim,
>
> On Fri, May 1, 2020 at 1:31 PM Maxim Solodovnik 
> wrote:
>
> > Hello Martin,
> >
> > WicketEndpoint#onError is being called
> >  "*ERROR* 05-01 16:10:21.740 o.a.w.p.w.j.WicketEndpoint:100
> > [EventExec-e2-t9] - An error occurred in web socket connection with id :
> > 10"
> >
> > The problem WebSocketBehavior#onError is not being called
> > So my application doesn't get notified the connection has been closed
> 
> >
>
> Then it must be somewhere in Wicket.
> Check that [2] is called.
>

Yes it is called


> Then [3], then [4]. From here on it is Wicket Event propagation [5]. It
>

[3] and [4] are not called
As you can see from the log branch at
https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L299
is in effect:

DEBUG 05-01 16:10:21.741 o.a.w.p.w.a.AbstractWebSocketProcessor:299
[EventExec-e2-t9] - Either there is no
connection(org.apache.wicket.protocol.ws.javax.JavaxWebSocketConnection@43539f89)
or it is closed.




> won't find your behavior if it is not enabled or any of if its component
> hierarchy is disabled/invisible.
>
>
> 2.
>
> https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L202
> 3.
>
> https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L272
> 4. *
> https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/WebSocketMessageBroadcastHandler.java#L69
> <
> https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/WebSocketMessageBroadcastHandler.java#L69
> >*
> 5.
>
> https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/WebSocketBehavior.java#L86
>
>
> > :(
> >
> > On Fri, 1 May 2020 at 17:12, Martin Grigorov 
> wrote:
> >
> > > Hi Maxim,
> > >
> > > If WicketEndpoint#onError() [1] is not called then probably there is a
> > bug
> > > in Tomcat.
> > > I suggest you to post this question at Tomcat's users@.
> > >
> > > 1.
> > >
> > >
> >
> https://github.com/apache/wicket/blob/master/wicket-native-websocket/wicket-native-websocket-javax/src/main/java/org/apache/wicket/protocol/ws/javax/WicketEndpoint.java#L92
> > >
> > >
> > > On Fri, May 1, 2020 at 12:21 PM Maxim Solodovnik  >
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > I'm having weird situation: WebSocket connection is closed on page
> > > reload,
> > > > but none of my onClose/onError/onAbort handlers are being called
> > > > I have changed wicket version to latest SNAPSHOT and got some debug
> > logs:
> > > >
> > > > *ERROR* 05-01 16:10:21.740 o.a.w.p.w.j.WicketEndpoint:100
> > > > [EventExec-e2-t9] - An error occurred in web socket connection with
> id
> > > > : 10
> > > > java.io.IOException: java.io.IOException: Broken pipe
> > > > at
> > > >
> > >
> >
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:315)
> > > > at
> > > >
> > >
> >
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:258)
> > > > at
> > > >
> > >
> >
> org.apache.tomcat.websocket.WsSession.sendCloseMessage(WsSession.java:612)
> > > > at
> > > > org.apache.tomcat.websocket.WsSession.doClose(WsSession.java:497)
> > > > at
> > > > org.apache.tomcat.websocket.WsSession.doClose(WsSession.java:459)
> > > > at
> > > >
> > >
> >
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:313)
> > > > at
> > > >
> > >
> >
> org.apach

Re: WebSocket onClose/onError/onAbort is not being called

[Martin Grigorov]

Hi Maxim,

On Fri, May 1, 2020 at 1:31 PM Maxim Solodovnik 
wrote:

> Hello Martin,
>
> WicketEndpoint#onError is being called
>  "*ERROR* 05-01 16:10:21.740 o.a.w.p.w.j.WicketEndpoint:100
> [EventExec-e2-t9] - An error occurred in web socket connection with id :
> 10"
>
> The problem WebSocketBehavior#onError is not being called
> So my application doesn't get notified the connection has been closed 
>

Then it must be somewhere in Wicket.
Check that [2] is called.
Then [3], then [4]. From here on it is Wicket Event propagation [5]. It
won't find your behavior if it is not enabled or any of if its component
hierarchy is disabled/invisible.


2.
https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L202
3.
https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L272
4. 
*https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/WebSocketMessageBroadcastHandler.java#L69
<https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/WebSocketMessageBroadcastHandler.java#L69>*
5.
https://github.com/apache/wicket/blob/d43c68c0126306021a12afbfe7876a36612fbbc3/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/WebSocketBehavior.java#L86


> :(
>
> On Fri, 1 May 2020 at 17:12, Martin Grigorov  wrote:
>
> > Hi Maxim,
> >
> > If WicketEndpoint#onError() [1] is not called then probably there is a
> bug
> > in Tomcat.
> > I suggest you to post this question at Tomcat's users@.
> >
> > 1.
> >
> >
> https://github.com/apache/wicket/blob/master/wicket-native-websocket/wicket-native-websocket-javax/src/main/java/org/apache/wicket/protocol/ws/javax/WicketEndpoint.java#L92
> >
> >
> > On Fri, May 1, 2020 at 12:21 PM Maxim Solodovnik 
> > wrote:
> >
> > > Hello,
> > >
> > > I'm having weird situation: WebSocket connection is closed on page
> > reload,
> > > but none of my onClose/onError/onAbort handlers are being called
> > > I have changed wicket version to latest SNAPSHOT and got some debug
> logs:
> > >
> > > *ERROR* 05-01 16:10:21.740 o.a.w.p.w.j.WicketEndpoint:100
> > > [EventExec-e2-t9] - An error occurred in web socket connection with id
> > > : 10
> > > java.io.IOException: java.io.IOException: Broken pipe
> > > at
> > >
> >
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:315)
> > > at
> > >
> >
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:258)
> > > at
> > >
> >
> org.apache.tomcat.websocket.WsSession.sendCloseMessage(WsSession.java:612)
> > > at
> > > org.apache.tomcat.websocket.WsSession.doClose(WsSession.java:497)
> > > at
> > > org.apache.tomcat.websocket.WsSession.doClose(WsSession.java:459)
> > > at
> > >
> >
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:313)
> > > at
> > >
> >
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:250)
> > > at
> > >
> >
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendString(WsRemoteEndpointImplBase.java:191)
> > > at
> > >
> >
> org.apache.tomcat.websocket.WsRemoteEndpointBasic.sendText(WsRemoteEndpointBasic.java:37)
> > > at org.apache.wicket.protocol.ws
> > >
> >
> .javax.JavaxWebSocketConnection.sendMessage(JavaxWebSocketConnection.java:81)
> > > at
> > >
> >
> org.apache.openmeetings.core.util.WebSocketHelper.lambda$sendClient$1(WebSocketHelper.java:75)
> > > at
> > >
> >
> org.apache.openmeetings.core.util.WebSocketHelper.lambda$sendClient$2(WebSocketHelper.java:94)
> > > at org.apache.wicket.protocol.ws
> > > .WebSocketSettings$SameThreadExecutor.run(WebSocketSettings.java:393)
> > > at
> > >

Re: WebSocket onClose/onError/onAbort is not being called

[Maxim Solodovnik]

Hello Martin,

WicketEndpoint#onError is being called
 "*ERROR* 05-01 16:10:21.740 o.a.w.p.w.j.WicketEndpoint:100
[EventExec-e2-t9] - An error occurred in web socket connection with id : 10"

The problem WebSocketBehavior#onError is not being called
So my application doesn't get notified the connection has been closed 
:(

On Fri, 1 May 2020 at 17:12, Martin Grigorov  wrote:

> Hi Maxim,
>
> If WicketEndpoint#onError() [1] is not called then probably there is a bug
> in Tomcat.
> I suggest you to post this question at Tomcat's users@.
>
> 1.
>
> https://github.com/apache/wicket/blob/master/wicket-native-websocket/wicket-native-websocket-javax/src/main/java/org/apache/wicket/protocol/ws/javax/WicketEndpoint.java#L92
>
>
> On Fri, May 1, 2020 at 12:21 PM Maxim Solodovnik 
> wrote:
>
> > Hello,
> >
> > I'm having weird situation: WebSocket connection is closed on page
> reload,
> > but none of my onClose/onError/onAbort handlers are being called
> > I have changed wicket version to latest SNAPSHOT and got some debug logs:
> >
> > *ERROR* 05-01 16:10:21.740 o.a.w.p.w.j.WicketEndpoint:100
> > [EventExec-e2-t9] - An error occurred in web socket connection with id
> > : 10
> > java.io.IOException: java.io.IOException: Broken pipe
> > at
> >
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:315)
> > at
> >
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:258)
> > at
> >
> org.apache.tomcat.websocket.WsSession.sendCloseMessage(WsSession.java:612)
> > at
> > org.apache.tomcat.websocket.WsSession.doClose(WsSession.java:497)
> > at
> > org.apache.tomcat.websocket.WsSession.doClose(WsSession.java:459)
> > at
> >
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:313)
> > at
> >
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:250)
> > at
> >
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendString(WsRemoteEndpointImplBase.java:191)
> > at
> >
> org.apache.tomcat.websocket.WsRemoteEndpointBasic.sendText(WsRemoteEndpointBasic.java:37)
> > at org.apache.wicket.protocol.ws
> >
> .javax.JavaxWebSocketConnection.sendMessage(JavaxWebSocketConnection.java:81)
> > at
> >
> org.apache.openmeetings.core.util.WebSocketHelper.lambda$sendClient$1(WebSocketHelper.java:75)
> > at
> >
> org.apache.openmeetings.core.util.WebSocketHelper.lambda$sendClient$2(WebSocketHelper.java:94)
> > at org.apache.wicket.protocol.ws
> > .WebSocketSettings$SameThreadExecutor.run(WebSocketSettings.java:393)
> > at
> >
> org.apache.openmeetings.core.util.WebSocketHelper.sendClient(WebSocketHelper.java:94)
> > at
> >
> org.apache.openmeetings.core.util.WebSocketHelper.sendClient(WebSocketHelper.java:73)
> > at
> >
> org.apache.openmeetings.core.remote.KurentoHandler.sendClient(KurentoHandler.java:209)
> > at
> >
> org.apache.openmeetings.core.remote.KStream.lambda$createEndpoint$5(KStream.java:224)
> > at
> >
> org.kurento.client.internal.client.RemoteObjectInvocationHandler.propagateEventTo(RemoteObjectInvocationHandler.java:281)
> > at
> >
> org.kurento.client.internal.client.RemoteObjectInvocationHandler$1.onEvent(RemoteObjectInvocationHandler.java:208)
> > at
> >
> org.kurento.client.internal.client.RemoteObject.fireEvent(RemoteObject.java:345)
> > at
> >
> org.kurento.client.internal.client.RomClientObjectManager.processEvent(RomClientObjectManager.java:58)
> > at
> >
> org.kurento.client.internal.transport.jsonrpc.RomClientJsonRpcClient.processEvent(RomClientJsonRpcClient.java:206)
> > at
> >
> org.kurento.client.internal.transport.jsonrpc.RomClientJsonRpcClient.access$000(RomClientJsonRpcClient.java:74)
> > at
> >
> org.kurento.client.internal.transport.jsonrpc.RomClientJsonRpcClient$1.handleRequest(RomClientJsonRpcClient.java:182)
> > at
> >
> org.kurento.jsonrpc.internal.JsonRpcHandlerManager.handleRequest(JsonRpcHandlerManager.java:142)
> > at
> >
> org.kurento.jsonrpc.client.AbstractJsonRpcClientWebSocket$15.run(AbstractJsonRpcClientWebSocket.java:577)
> > at
> >
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> > at
> > java.base/java.ut

Re: WebSocket onClose/onError/onAbort is not being called

[Martin Grigorov]

Hi Maxim,

If WicketEndpoint#onError() [1] is not called then probably there is a bug
in Tomcat.
I suggest you to post this question at Tomcat's users@.

1.
https://github.com/apache/wicket/blob/master/wicket-native-websocket/wicket-native-websocket-javax/src/main/java/org/apache/wicket/protocol/ws/javax/WicketEndpoint.java#L92


On Fri, May 1, 2020 at 12:21 PM Maxim Solodovnik 
wrote:

> Hello,
>
> I'm having weird situation: WebSocket connection is closed on page reload,
> but none of my onClose/onError/onAbort handlers are being called
> I have changed wicket version to latest SNAPSHOT and got some debug logs:
>
> *ERROR* 05-01 16:10:21.740 o.a.w.p.w.j.WicketEndpoint:100
> [EventExec-e2-t9] - An error occurred in web socket connection with id
> : 10
> java.io.IOException: java.io.IOException: Broken pipe
> at
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:315)
> at
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:258)
> at
> org.apache.tomcat.websocket.WsSession.sendCloseMessage(WsSession.java:612)
> at
> org.apache.tomcat.websocket.WsSession.doClose(WsSession.java:497)
> at
> org.apache.tomcat.websocket.WsSession.doClose(WsSession.java:459)
> at
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:313)
> at
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:250)
> at
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendString(WsRemoteEndpointImplBase.java:191)
> at
> org.apache.tomcat.websocket.WsRemoteEndpointBasic.sendText(WsRemoteEndpointBasic.java:37)
> at org.apache.wicket.protocol.ws
> .javax.JavaxWebSocketConnection.sendMessage(JavaxWebSocketConnection.java:81)
> at
> org.apache.openmeetings.core.util.WebSocketHelper.lambda$sendClient$1(WebSocketHelper.java:75)
> at
> org.apache.openmeetings.core.util.WebSocketHelper.lambda$sendClient$2(WebSocketHelper.java:94)
> at org.apache.wicket.protocol.ws
> .WebSocketSettings$SameThreadExecutor.run(WebSocketSettings.java:393)
> at
> org.apache.openmeetings.core.util.WebSocketHelper.sendClient(WebSocketHelper.java:94)
> at
> org.apache.openmeetings.core.util.WebSocketHelper.sendClient(WebSocketHelper.java:73)
> at
> org.apache.openmeetings.core.remote.KurentoHandler.sendClient(KurentoHandler.java:209)
> at
> org.apache.openmeetings.core.remote.KStream.lambda$createEndpoint$5(KStream.java:224)
> at
> org.kurento.client.internal.client.RemoteObjectInvocationHandler.propagateEventTo(RemoteObjectInvocationHandler.java:281)
> at
> org.kurento.client.internal.client.RemoteObjectInvocationHandler$1.onEvent(RemoteObjectInvocationHandler.java:208)
> at
> org.kurento.client.internal.client.RemoteObject.fireEvent(RemoteObject.java:345)
> at
> org.kurento.client.internal.client.RomClientObjectManager.processEvent(RomClientObjectManager.java:58)
> at
> org.kurento.client.internal.transport.jsonrpc.RomClientJsonRpcClient.processEvent(RomClientJsonRpcClient.java:206)
> at
> org.kurento.client.internal.transport.jsonrpc.RomClientJsonRpcClient.access$000(RomClientJsonRpcClient.java:74)
> at
> org.kurento.client.internal.transport.jsonrpc.RomClientJsonRpcClient$1.handleRequest(RomClientJsonRpcClient.java:182)
> at
> org.kurento.jsonrpc.internal.JsonRpcHandlerManager.handleRequest(JsonRpcHandlerManager.java:142)
> at
> org.kurento.jsonrpc.client.AbstractJsonRpcClientWebSocket$15.run(AbstractJsonRpcClientWebSocket.java:577)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.io.IOException: Broken pipe
> at java.base/sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at java.base/sun.nio.ch
> .SocketDispatcher.write(SocketDispatcher.java:47)
> at
> java.base/sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:113)
> at java.base/sun.nio.ch.IOUtil.write(IOUtil.java:79)
> at java.base/sun.nio.ch.IOUtil.write(IOUtil.java:50)
> at java.base/sun.nio.ch
> .SocketChannelImpl.write(SocketChannelImpl.java:466)
> at org.apache.tomcat.util.net
> .SecureNio

WebSocket onClose/onError/onAbort is not being called

[Maxim Solodovnik]

Hello,

I'm having weird situation: WebSocket connection is closed on page reload,
but none of my onClose/onError/onAbort handlers are being called
I have changed wicket version to latest SNAPSHOT and got some debug logs:

*ERROR* 05-01 16:10:21.740 o.a.w.p.w.j.WicketEndpoint:100
[EventExec-e2-t9] - An error occurred in web socket connection with id
: 10
java.io.IOException: java.io.IOException: Broken pipe
at 
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:315)
at 
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:258)
at 
org.apache.tomcat.websocket.WsSession.sendCloseMessage(WsSession.java:612)
at org.apache.tomcat.websocket.WsSession.doClose(WsSession.java:497)
at org.apache.tomcat.websocket.WsSession.doClose(WsSession.java:459)
at 
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:313)
at 
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:250)
at 
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendString(WsRemoteEndpointImplBase.java:191)
at 
org.apache.tomcat.websocket.WsRemoteEndpointBasic.sendText(WsRemoteEndpointBasic.java:37)
at 
org.apache.wicket.protocol.ws.javax.JavaxWebSocketConnection.sendMessage(JavaxWebSocketConnection.java:81)
at 
org.apache.openmeetings.core.util.WebSocketHelper.lambda$sendClient$1(WebSocketHelper.java:75)
at 
org.apache.openmeetings.core.util.WebSocketHelper.lambda$sendClient$2(WebSocketHelper.java:94)
at 
org.apache.wicket.protocol.ws.WebSocketSettings$SameThreadExecutor.run(WebSocketSettings.java:393)
at 
org.apache.openmeetings.core.util.WebSocketHelper.sendClient(WebSocketHelper.java:94)
at 
org.apache.openmeetings.core.util.WebSocketHelper.sendClient(WebSocketHelper.java:73)
at 
org.apache.openmeetings.core.remote.KurentoHandler.sendClient(KurentoHandler.java:209)
at 
org.apache.openmeetings.core.remote.KStream.lambda$createEndpoint$5(KStream.java:224)
at 
org.kurento.client.internal.client.RemoteObjectInvocationHandler.propagateEventTo(RemoteObjectInvocationHandler.java:281)
at 
org.kurento.client.internal.client.RemoteObjectInvocationHandler$1.onEvent(RemoteObjectInvocationHandler.java:208)
at 
org.kurento.client.internal.client.RemoteObject.fireEvent(RemoteObject.java:345)
at 
org.kurento.client.internal.client.RomClientObjectManager.processEvent(RomClientObjectManager.java:58)
at 
org.kurento.client.internal.transport.jsonrpc.RomClientJsonRpcClient.processEvent(RomClientJsonRpcClient.java:206)
at 
org.kurento.client.internal.transport.jsonrpc.RomClientJsonRpcClient.access$000(RomClientJsonRpcClient.java:74)
at 
org.kurento.client.internal.transport.jsonrpc.RomClientJsonRpcClient$1.handleRequest(RomClientJsonRpcClient.java:182)
at 
org.kurento.jsonrpc.internal.JsonRpcHandlerManager.handleRequest(JsonRpcHandlerManager.java:142)
at 
org.kurento.jsonrpc.client.AbstractJsonRpcClientWebSocket$15.run(AbstractJsonRpcClientWebSocket.java:577)
at 
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.io.IOException: Broken pipe
at java.base/sun.nio.ch.FileDispatcherImpl.write0(Native Method)
at java.base/sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
at java.base/sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:113)
at java.base/sun.nio.ch.IOUtil.write(IOUtil.java:79)
at java.base/sun.nio.ch.IOUtil.write(IOUtil.java:50)
at 
java.base/sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:466)
at 
org.apache.tomcat.util.net.SecureNioChannel.flush(SecureNioChannel.java:145)
at 
org.apache.tomcat.util.net.SecureNioChannel.write(SecureNioChannel.java:851)
at 
org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper$NioOperationState.run(NioEndpoint.java:1491)
at 
org.apache.tomcat.util.net.SocketWrapperBase$OperationState.start(SocketWrapperBase.java:1015)
at 
org.apache.tomcat.util.net.SocketWrapperBase.vectoredOperation(SocketWrapperBase.java:1426)
at 
org.apache.tomcat.util.net.SocketWrapperBase.write(SocketWrapperBase.java:1352)
at 
org.apache.tomcat.util.net.SocketWrapperBase.write(SocketWrapperBase.java:1323)
at 
org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.doWrite(WsRemoteEndpointImplServer.java:90

Re: MetaData for websocket connections

[Martin Grigorov]

On Thu, Mar 26, 2020 at 10:59 AM Thomas Heigl  wrote:

> Hi Martin,
>
> It is not really necessary as you pointed out, but an external registry
> forces me to override the default IWebSocketConnectionRegistry so I can
> update the external registry when connections are
> added and removed.
>

I guess you don't want to use WebSocketBehavior's onConnect() and
onClose/onError() callbacks due to the "avoid loading the page if not
necessary" problem.


>
> If connections themselves would support metadata, there would be no need
> for an external registry plus the required glue code for keeping the
> registry up to date.
>
> But if you prefer not to add functionality I can go ahead and implement an
> external solution and see how it goes.
>

Anyone else having an opinion on this?


>
> Best regards,
>
> Thomas
>
> On Wed, Mar 25, 2020 at 7:19 PM Martin Grigorov 
> wrote:
>
> > Hi Thomas,
> >
> > Is this really necessary?
> > You can achieve the same today by using an external registry.
> > E.g. List channels = channelRegistry.get(webSocketConnection);
> > internally the registry can use WebSocketConnection's
> > getApplication().getName(), getSessionId() and getKey() to construct the
> > key.
> >
> > MetaData would do the job as well, but I'd prefer to not add more
> > functionality unless really needed.
> >
> > Regards,
> > Martin
> >
> > On Wed, Mar 25, 2020 at 6:30 PM Thomas Heigl 
> wrote:
> >
> > > Hi all,
> > >
> > > I'd like to add metadata to websocket connections. For instance, which
> > > events or channels a connection is subscribed to.
> > >
> > > What do you think about adding MetaDataEntry[] metaData to
> connections
> > > and setMetaData/getMetaData to IWebSocketConnection?
> > >
> > > Best regards,
> > >
> > > Thomas
> > >
> >
>

Re: MetaData for websocket connections

[Thomas Heigl]

Hi Martin,

It is not really necessary as you pointed out, but an external registry
forces me to override the default IWebSocketConnectionRegistry so I can
update the external registry when connections are
added and removed.

If connections themselves would support metadata, there would be no need
for an external registry plus the required glue code for keeping the
registry up to date.

But if you prefer not to add functionality I can go ahead and implement an
external solution and see how it goes.

Best regards,

Thomas

On Wed, Mar 25, 2020 at 7:19 PM Martin Grigorov 
wrote:

> Hi Thomas,
>
> Is this really necessary?
> You can achieve the same today by using an external registry.
> E.g. List channels = channelRegistry.get(webSocketConnection);
> internally the registry can use WebSocketConnection's
> getApplication().getName(), getSessionId() and getKey() to construct the
> key.
>
> MetaData would do the job as well, but I'd prefer to not add more
> functionality unless really needed.
>
> Regards,
> Martin
>
> On Wed, Mar 25, 2020 at 6:30 PM Thomas Heigl  wrote:
>
> > Hi all,
> >
> > I'd like to add metadata to websocket connections. For instance, which
> > events or channels a connection is subscribed to.
> >
> > What do you think about adding MetaDataEntry[] metaData to connections
> > and setMetaData/getMetaData to IWebSocketConnection?
> >
> > Best regards,
> >
> > Thomas
> >
>

Re: MetaData for websocket connections

[Martin Grigorov]

Hi Thomas,

Is this really necessary?
You can achieve the same today by using an external registry.
E.g. List channels = channelRegistry.get(webSocketConnection);
internally the registry can use WebSocketConnection's
getApplication().getName(), getSessionId() and getKey() to construct the
key.

MetaData would do the job as well, but I'd prefer to not add more
functionality unless really needed.

Regards,
Martin

On Wed, Mar 25, 2020 at 6:30 PM Thomas Heigl  wrote:

> Hi all,
>
> I'd like to add metadata to websocket connections. For instance, which
> events or channels a connection is subscribed to.
>
> What do you think about adding MetaDataEntry[] metaData to connections
> and setMetaData/getMetaData to IWebSocketConnection?
>
> Best regards,
>
> Thomas
>

MetaData for websocket connections

[Thomas Heigl]

Hi all,

I'd like to add metadata to websocket connections. For instance, which
events or channels a connection is subscribed to.

What do you think about adding MetaDataEntry[] metaData to connections
and setMetaData/getMetaData to IWebSocketConnection?

Best regards,

Thomas

Re: After upgrade to Wicket 7.6.0, WebSocket logs Broken pipe

[AlexAchterberg]

This was an Apache Tomcat issue.
Having the same problem with 8.5.16 version it ceased when upgrading to
8.5.50.


--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html

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

Re: WebSocket

[Virginie Garcin]

Hello,
Indeed, it works with Tomcat 9!Thanks a lot for your help.
Virginie
On Tue, 2019-02-19 at 19:39 +0700, Maxim Solodovnik wrote:
> Or maybe with Tomcat-7 you need Wicket-7 and wicket-native-websocket-tomcat 
> 
> On Tue, 19 Feb 2019 at 18:44, Maxim Solodovnik  wrote:
> > Shot in the dark: tomcat 7 is too old ...Does it work with tomcat 8/8.5/9 ?
> > On Tue, Feb 19, 2019, 18:30 Virginie Garcin  > wrote:
> > > Hello,
> > > I'm trying to use WebSocket in Wicket 8.3.0, with Tomcat 7.0.85.
> > > In pom, I have:
> > > org.apache.wicket
> > > wicket-native-websocket-javax
> > > ${wicket.version}
> > > In web.xml, I did change the WicketFilter class name 
> > > with:org.apache.wicket.protocol.ws.javax.JavaxWebSocketFilter
> > > In my page, I have:
> > > @Overrideprotected void onInitialize() {super.onInitialize();
> > > add( new WebSocketBehavior() {@Override   
> > >  protected void onConnect(ConnectedMessage message) { 
> > >super.onConnect( message );
> > > System.out.println( "onConnect" );
> > > WebSocketService.getInstance().addClient( message );} 
> > >}}
> > > When I open the page in the browser, the "onConnect" function is never 
> > > called...(I also noticed that the class WicketEndpoint is never called, I 
> > > feel that it should be called at some point).
> > > Any idea of what I'm missing?
> > > Thanks in advance,Virginie
> > > 

Re: WebSocket

[Maxim Solodovnik]

Or maybe with Tomcat-7 you need Wicket-7 and wicket-native-websocket-tomcat 

On Tue, 19 Feb 2019 at 18:44, Maxim Solodovnik  wrote:
>
> Shot in the dark: tomcat 7 is too old ...
> Does it work with tomcat 8/8.5/9 ?
>
> On Tue, Feb 19, 2019, 18:30 Virginie Garcin  wrote:
>>
>> Hello,
>>
>> I'm trying to use WebSocket in Wicket 8.3.0, with Tomcat 7.0.85.
>>
>> In pom, I have:
>>
>> 
>> org.apache.wicket
>> wicket-native-websocket-javax
>> ${wicket.version}
>> 
>>
>> In web.xml, I did change the WicketFilter class name with:
>> org.apache.wicket.protocol.ws.javax.JavaxWebSocketFilter
>>
>> In my page, I have:
>>
>> @Override
>> protected void onInitialize() {
>> super.onInitialize();
>>
>> add( new WebSocketBehavior() {
>> @Override
>> protected void onConnect(ConnectedMessage message) {
>> super.onConnect( message );
>> System.out.println( "onConnect" );
>> WebSocketService.getInstance().addClient( message );
>> }
>> }
>> }
>>
>> When I open the page in the browser, the "onConnect" function is never 
>> called...
>> (I also noticed that the class WicketEndpoint is never called, I feel that 
>> it should be called at some point).
>>
>> Any idea of what I'm missing?
>>
>> Thanks in advance,
>> Virginie
>>
>>


-- 
WBR
Maxim aka solomax

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

WebSocket

[Virginie Garcin]

Hello,

I'm trying to use WebSocket in Wicket 8.3.0, with Tomcat 7.0.85.

In pom, I have: 


org.apache.wicket
wicket-native-websocket-javax
${wicket.version}


In web.xml, I did change the WicketFilter class name with:
org.apache.wicket.protocol.ws.javax.JavaxWebSocketFilter

In my page, I have:

@Override
protected void onInitialize() {
super.onInitialize();

add( new WebSocketBehavior() {
@Override
protected void onConnect(ConnectedMessage message) {
super.onConnect( message );
System.out.println( "onConnect" );
WebSocketService.getInstance().addClient( message );
}
}
}

When I open the page in the browser, the "onConnect" function is never 
called... 
(I also noticed that the class WicketEndpoint is never called, I feel that it 
should be called at some point).

Any idea of what I'm missing?

Thanks in advance,
Virginie

Re: WebSocket tests fail after migration to Wicket 8

[Manfred Bergmann]

Yes, I can confirm 8.2.0-SNAPSHOT works.


Thank you,
Manfred

--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html

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

Re: WebSocket tests fail after migration to Wicket 8

[Andrea Del Bene]

Hi,

you probably found an issue with we recently fixed : 
https://issues.apache.org/jira/browse/WICKET-6588


Could you test your code using 8.2.0-SNAPSHOT version?

Thank you.


On 29/09/2018 16:58, Manfred Bergmann wrote:


Hi.

I’m using a WebSocket on a component of a page based on WebSocketBehavior.
It’s working fine when running the app.

But the tests of the Panel fail, in contrast to Wicket 7 with:

Caused by: java.lang.NullPointerException
at 
org.apache.wicket.protocol.ws.api.BaseWebSocketBehavior.getSessionId(BaseWebSocketBehavior.java:176)
 ~[wicket-native-websocket-core-8.1.0.jar:8.1.0]
at 
org.apache.wicket.protocol.ws.api.BaseWebSocketBehavior.renderHead(BaseWebSocketBehavior.java:128)
 ~[wicket-native-websocket-core-8.1.0.jar:8.1.0]

Is there something that must change for testing WebSocket behavior in Wicket 8?



Regards,
Manfred





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

WebSocket tests fail after migration to Wicket 8

[Manfred Bergmann]

Hi.

I’m using a WebSocket on a component of a page based on WebSocketBehavior.
It’s working fine when running the app.

But the tests of the Panel fail, in contrast to Wicket 7 with:

Caused by: java.lang.NullPointerException
at 
org.apache.wicket.protocol.ws.api.BaseWebSocketBehavior.getSessionId(BaseWebSocketBehavior.java:176)
 ~[wicket-native-websocket-core-8.1.0.jar:8.1.0]
at 
org.apache.wicket.protocol.ws.api.BaseWebSocketBehavior.renderHead(BaseWebSocketBehavior.java:128)
 ~[wicket-native-websocket-core-8.1.0.jar:8.1.0]

Is there something that must change for testing WebSocket behavior in Wicket 8?



Regards,
Manfred

Re: WebSocket and timeout

[Maxim Solodovnik]

Sorry,
Misread it :(
I actually using both.
Ajax request refreshing HTTP session and binary ping refreshing websocket
connection and being ignored

WBR, Maxim
(from mobile, sorry for the typos)

On Sep 19, 2017 02:49, "Martin Grigorov" <mgrigo...@apache.org> wrote:

> Hi,
>
> @Maxim: the problem Manfred faces is not that the Http Session expires but
> that the WebSocket connection is closed by the web container due to
> inactivity.
>
> @Manfred: I'd use server-side timer that uses the
> IWebSocketConnectionRegistry to send the heartbeat message to all connected
> clients. The clients should ignore this message.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Mon, Sep 18, 2017 at 8:55 AM, Maxim Solodovnik <solomax...@gmail.com>
> wrote:
>
> > Hello Manfred,
> >
> > AFAIK websocket ping messages will not update HTTP session.
> > You can set up AbstractAjaxTimerBehavior or send pure JS HTTP request
> > to refresh the session
> >
> > On Sat, Sep 16, 2017 at 7:34 PM, Manfred Bergmann
> > <m...@software-by-mabe.com> wrote:
> > >
> > > Hi,
> > >
> > > On Sat, Sep 16, 2017 at 1:32 PM, Manfred Bergmann mb@
> > > wrote:
> > >
> > >> Found a different solution.
> > >>
> > >> Followed the advice here:
> > >> https://issues.apache.org/jira/browse/WICKET-5453
> > >>
> > >> Where you can set the default idle timeout on the
> > >> WebSocketServerContainerInitializer.
> > >>
> > >
> > > This is a good start!
> > > But if there is a proxy involved then you will need to do the same
> there
> > > too.
> > > Better send heartbeat messages once in a while, e.g. every minute.
> > >
> > >
> > >
> > > OK. I'm not exactly certain how I would do that.
> > > Do you mean a timer on the server side which sends some message over
> the
> > > websocket,
> > > or some behavior, as suggested by Maxim?
> > >
> > > How do I handle that when the panel got disposed?
> > >
> > >
> > > Manfred
> > >
> > > --
> > > Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-
> > f1842947.html
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > > For additional commands, e-mail: users-h...@wicket.apache.org
> > >
> >
> >
> >
> > --
> > WBR
> > Maxim aka solomax
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
>

Re: WebSocket and timeout

[Martin Grigorov]

Hi,

@Maxim: the problem Manfred faces is not that the Http Session expires but
that the WebSocket connection is closed by the web container due to
inactivity.

@Manfred: I'd use server-side timer that uses the
IWebSocketConnectionRegistry to send the heartbeat message to all connected
clients. The clients should ignore this message.

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

On Mon, Sep 18, 2017 at 8:55 AM, Maxim Solodovnik <solomax...@gmail.com>
wrote:

> Hello Manfred,
>
> AFAIK websocket ping messages will not update HTTP session.
> You can set up AbstractAjaxTimerBehavior or send pure JS HTTP request
> to refresh the session
>
> On Sat, Sep 16, 2017 at 7:34 PM, Manfred Bergmann
> <m...@software-by-mabe.com> wrote:
> >
> > Hi,
> >
> > On Sat, Sep 16, 2017 at 1:32 PM, Manfred Bergmann mb@
> > wrote:
> >
> >> Found a different solution.
> >>
> >> Followed the advice here:
> >> https://issues.apache.org/jira/browse/WICKET-5453
> >>
> >> Where you can set the default idle timeout on the
> >> WebSocketServerContainerInitializer.
> >>
> >
> > This is a good start!
> > But if there is a proxy involved then you will need to do the same there
> > too.
> > Better send heartbeat messages once in a while, e.g. every minute.
> >
> >
> >
> > OK. I'm not exactly certain how I would do that.
> > Do you mean a timer on the server side which sends some message over the
> > websocket,
> > or some behavior, as suggested by Maxim?
> >
> > How do I handle that when the panel got disposed?
> >
> >
> > Manfred
> >
> > --
> > Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-
> f1842947.html
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
>
>
>
> --
> WBR
> Maxim aka solomax
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: WebSocket and timeout

[Maxim Solodovnik]

Hello Manfred,

AFAIK websocket ping messages will not update HTTP session.
You can set up AbstractAjaxTimerBehavior or send pure JS HTTP request
to refresh the session

On Sat, Sep 16, 2017 at 7:34 PM, Manfred Bergmann
<m...@software-by-mabe.com> wrote:
>
> Hi,
>
> On Sat, Sep 16, 2017 at 1:32 PM, Manfred Bergmann mb@
> wrote:
>
>> Found a different solution.
>>
>> Followed the advice here:
>> https://issues.apache.org/jira/browse/WICKET-5453
>>
>> Where you can set the default idle timeout on the
>> WebSocketServerContainerInitializer.
>>
>
> This is a good start!
> But if there is a proxy involved then you will need to do the same there
> too.
> Better send heartbeat messages once in a while, e.g. every minute.
>
>
>
> OK. I'm not exactly certain how I would do that.
> Do you mean a timer on the server side which sends some message over the
> websocket,
> or some behavior, as suggested by Maxim?
>
> How do I handle that when the panel got disposed?
>
>
> Manfred
>
> --
> Sent from: 
> http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>



-- 
WBR
Maxim aka solomax

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

Re: WebSocket and timeout

[Manfred Bergmann]

Hi,

On Sat, Sep 16, 2017 at 1:32 PM, Manfred Bergmann mb@
wrote:

> Found a different solution.
>
> Followed the advice here:
> https://issues.apache.org/jira/browse/WICKET-5453
>
> Where you can set the default idle timeout on the
> WebSocketServerContainerInitializer.
>

This is a good start!
But if there is a proxy involved then you will need to do the same there
too.
Better send heartbeat messages once in a while, e.g. every minute.



OK. I'm not exactly certain how I would do that.
Do you mean a timer on the server side which sends some message over the
websocket,
or some behavior, as suggested by Maxim?

How do I handle that when the panel got disposed?


Manfred

--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html

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

Re: WebSocket and timeout

[Martin Grigorov]

Hi,

On Sat, Sep 16, 2017 at 1:32 PM, Manfred Bergmann 
wrote:

> Found a different solution.
>
> Followed the advice here:
> https://issues.apache.org/jira/browse/WICKET-5453
>
> Where you can set the default idle timeout on the
> WebSocketServerContainerInitializer.
>

This is a good start!
But if there is a proxy involved then you will need to do the same there
too.
Better send heartbeat messages once in a while, e.g. every minute.


>
>
>
> Manfred
>
> --
> Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-
> f1842947.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: WebSocket and timeout

[Manfred Bergmann]

Found a different solution.

Followed the advice here:
https://issues.apache.org/jira/browse/WICKET-5453

Where you can set the default idle timeout on the
WebSocketServerContainerInitializer.



Manfred

--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html

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

Re: WebSocket and timeout

[Maxim Solodovnik]

you can add timeout behavior which will send ajax requests
these requests will refresh session

So far this is the only workaround i can propose

On Fri, Sep 15, 2017 at 11:53 PM, Manfred Bergmann
<m...@software-by-mabe.com> wrote:
> Hi.
>
> I'm not exactly certain how that helps me, except that the not yet released
> version 7.8.1 fixes something regarding WebSockets. But I don't know if it's
> that.
>
> The thing is, that I have a one page application. Meaning the page itself
> doesn't ever refresh. Only panels are reloaded here and there via Ajax.
> One of those panels uses a WebSocket.
> The WebSocket times out even if I move away from this particular panel.
> After the WebSocket has timed out it's only to possible to really reload the
> page to re-activate it.
>
> So, preferably I'd like to WebSocket to not expire before the session
> expired.
>
>
> Manfred
>
> --
> Sent from: 
> http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>



-- 
WBR
Maxim aka solomax

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

Re: WebSocket and timeout

[Manfred Bergmann]

Hi.

I'm not exactly certain how that helps me, except that the not yet released
version 7.8.1 fixes something regarding WebSockets. But I don't know if it's
that.

The thing is, that I have a one page application. Meaning the page itself
doesn't ever refresh. Only panels are reloaded here and there via Ajax.
One of those panels uses a WebSocket.
The WebSocket times out even if I move away from this particular panel.
After the WebSocket has timed out it's only to possible to really reload the
page to re-activate it.

So, preferably I'd like to WebSocket to not expire before the session
expired.


Manfred

--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html

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

Re: WebSocket and timeout

[Maxim Solodovnik]

According to tomcat user list web socket activity does not touch session
You can set timeout ping behavior to touch the session

Here is the thread with my question according this
http://markmail.org/thread/g2ao4a4ytc3322b5

On Fri, Sep 15, 2017 at 10:05 PM, Bergmann Manfred
<m...@software-by-mabe.com> wrote:
> Hi.
>
> I’m having a problem with WebSocket timeouts.
> One panel (currently) of a page uses a WebSocket to push data and re-render 
> something.
> Leaving the browser untouched the WebSocket will timeout after 5 minutes:
> —-
> [ERROR] 2017-09-15 16:57:46.566 [Scheduler-1197176722] 
> org.apa.wic.pro.ws.jav.WicketEndpoint onError - An error occurred in web 
> socket connection with id : 0:0:0:0:0:0:0:1:8080->0:0:0:0:0:0:0:1:55737
> java.net.SocketTimeoutException: Timeout on Read
> at 
> org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.onReadTimeout(AbstractWebSocketConnection.java:592)
>  [websocket-common-9.4.6.v20170531.jar:9.4.6.v20170531]
> at 
> org.eclipse.jetty.io.AbstractConnection.onFillInterestedFailed(AbstractConnection.java:170)
>  [jetty-io-9.4.6.v20170531.jar:9.4.6.v20170531]
> at 
> org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.onFillInterestedFailed(AbstractWebSocketConnection.java:538)
>  [websocket-common-9.4.6.v20170531.jar:9.4.6.v20170531]
> at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.failed(AbstractConnection.java:285)
>  [jetty-io-9.4.6.v20170531.jar:9.4.6.v20170531]
> at org.eclipse.jetty.io.FillInterest.onFail(FillInterest.java:140) 
> [jetty-io-9.4.6.v20170531.jar:9.4.6.v20170531]
> at 
> org.eclipse.jetty.io.AbstractEndPoint.onIdleExpired(AbstractEndPoint.java:398)
>  [jetty-io-9.4.6.v20170531.jar:9.4.6.v20170531]
> at 
> org.eclipse.jetty.io.IdleTimeout.checkIdleTimeout(IdleTimeout.java:166) 
> [jetty-io-9.4.6.v20170531.jar:9.4.6.v20170531]
> —-
>
> Now, what exactly is responsible for this timeout. And how can that be 
> adjusted?
>
>
>
> Regards,
> Manfred
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>



-- 
WBR
Maxim aka solomax

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

WebSocket and timeout

[Bergmann Manfred]

Hi.

I’m having a problem with WebSocket timeouts.
One panel (currently) of a page uses a WebSocket to push data and re-render 
something.
Leaving the browser untouched the WebSocket will timeout after 5 minutes:
—-
[ERROR] 2017-09-15 16:57:46.566 [Scheduler-1197176722] 
org.apa.wic.pro.ws.jav.WicketEndpoint onError - An error occurred in web socket 
connection with id : 0:0:0:0:0:0:0:1:8080->0:0:0:0:0:0:0:1:55737
java.net.SocketTimeoutException: Timeout on Read
at 
org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.onReadTimeout(AbstractWebSocketConnection.java:592)
 [websocket-common-9.4.6.v20170531.jar:9.4.6.v20170531]
at 
org.eclipse.jetty.io.AbstractConnection.onFillInterestedFailed(AbstractConnection.java:170)
 [jetty-io-9.4.6.v20170531.jar:9.4.6.v20170531]
at 
org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.onFillInterestedFailed(AbstractWebSocketConnection.java:538)
 [websocket-common-9.4.6.v20170531.jar:9.4.6.v20170531]
at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.failed(AbstractConnection.java:285)
 [jetty-io-9.4.6.v20170531.jar:9.4.6.v20170531]
at org.eclipse.jetty.io.FillInterest.onFail(FillInterest.java:140) 
[jetty-io-9.4.6.v20170531.jar:9.4.6.v20170531]
at 
org.eclipse.jetty.io.AbstractEndPoint.onIdleExpired(AbstractEndPoint.java:398) 
[jetty-io-9.4.6.v20170531.jar:9.4.6.v20170531]
at 
org.eclipse.jetty.io.IdleTimeout.checkIdleTimeout(IdleTimeout.java:166) 
[jetty-io-9.4.6.v20170531.jar:9.4.6.v20170531]
—-

Now, what exactly is responsible for this timeout. And how can that be adjusted?



Regards,
Manfred


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

Re: Websocket replacing a panel which uses websockets

[Peter Henderson]

Done

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

On 29 August 2017 at 18:29, Martin Grigorov 
wrote:

> Hi,
>
> Please file a ticket!
> It should be easy to implement it.
> Thanks!
>
> On Aug 29, 2017 17:15, "Peter Henderson" 
> wrote:
>
> > Hi All,
> >
> > I've run into a possible bug.
> >
> > I've a page which initially shows a "loading..." animation panel.
> > This panel uses web sockets to trigger background loading.
> > (WebSocketBehavior::onConnected starts the background loading)
> >
> >
> > When the background loading has completed
> > (onEvent => event.getPayload => WebSocketPushPayload => ???)
> > I replace the loading place holder panel with the real data panel.
> >
> >
> >
> > The real data panel may also want to use web sockets, and show a loading
> > animation.
> > (Turtles all the way down)
> >
> > The problem I'm seeing, is that the WebSocketBehavior::onConnected method
> > is not being called on the replaced panel.
> >
> >
> > So my questions:-
> >
> > Am I doing something wrong?
> > Is this the expected behaviour?
> > (or) Is this a Bug?
> >
> >
> >
> >
> > A fairly simple example [1] although it's in Scala.
> >
> > [1] https://github.com/bollinger/WebSocketPanelReplace
> >
> > The interesting class is
> > https://github.com/bollinger/WebSocketPanelReplace/blob/
> > master/src/main/scala/com/starjar/ws/WsLoadingPanel.scala
> >
> > Many thanks
> >
> > Peter.
> >
> >
> >
> > --
> > Peter Henderson
> >
>



-- 
Peter Henderson

Director
Starjar Ltd.
www.starjar.com
0330 088 1662

Re: Websocket replacing a panel which uses websockets

[Martin Grigorov]

Hi,

Please file a ticket!
It should be easy to implement it.
Thanks!

On Aug 29, 2017 17:15, "Peter Henderson" 
wrote:

> Hi All,
>
> I've run into a possible bug.
>
> I've a page which initially shows a "loading..." animation panel.
> This panel uses web sockets to trigger background loading.
> (WebSocketBehavior::onConnected starts the background loading)
>
>
> When the background loading has completed
> (onEvent => event.getPayload => WebSocketPushPayload => ???)
> I replace the loading place holder panel with the real data panel.
>
>
>
> The real data panel may also want to use web sockets, and show a loading
> animation.
> (Turtles all the way down)
>
> The problem I'm seeing, is that the WebSocketBehavior::onConnected method
> is not being called on the replaced panel.
>
>
> So my questions:-
>
> Am I doing something wrong?
> Is this the expected behaviour?
> (or) Is this a Bug?
>
>
>
>
> A fairly simple example [1] although it's in Scala.
>
> [1] https://github.com/bollinger/WebSocketPanelReplace
>
> The interesting class is
> https://github.com/bollinger/WebSocketPanelReplace/blob/
> master/src/main/scala/com/starjar/ws/WsLoadingPanel.scala
>
> Many thanks
>
> Peter.
>
>
>
> --
> Peter Henderson
>

Websocket replacing a panel which uses websockets

[Peter Henderson]

Hi All,

I've run into a possible bug.

I've a page which initially shows a "loading..." animation panel.
This panel uses web sockets to trigger background loading.
(WebSocketBehavior::onConnected starts the background loading)


When the background loading has completed
(onEvent => event.getPayload => WebSocketPushPayload => ???)
I replace the loading place holder panel with the real data panel.



The real data panel may also want to use web sockets, and show a loading
animation.
(Turtles all the way down)

The problem I'm seeing, is that the WebSocketBehavior::onConnected method
is not being called on the replaced panel.


So my questions:-

Am I doing something wrong?
Is this the expected behaviour?
(or) Is this a Bug?




A fairly simple example [1] although it's in Scala.

[1] https://github.com/bollinger/WebSocketPanelReplace

The interesting class is
https://github.com/bollinger/WebSocketPanelReplace/blob/master/src/main/scala/com/starjar/ws/WsLoadingPanel.scala

Many thanks

Peter.



-- 
Peter Henderson

Re: After upgrade to Wicket 7.6.0, WebSocket logs Broken pipe

[ansc]

Could you solve the problem ?


--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/After-upgrade-to-Wicket-7-6-0-WebSocket-logs-Broken-pipe-tp4676630p4678119.html
Sent from the Users forum mailing list archive at Nabble.com.

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

Re: Websocket redirect wrong url

[Martin Grigorov]

On Wed, May 24, 2017 at 12:18 PM, Peter Henderson <
peter.hender...@starjar.com> wrote:

> On 24 May 2017 at 11:05, Peter Henderson 
> wrote:
>
> >
> >
> > On 23 May 2017 at 22:24, Martin Grigorov  wrote:
> >
> >> Hi,
> >>
> >> I'm afraid a quickstart would be needed to be able to tell what goes
> wrong
> >> there.
> >>
> >
> > Thanks for looking, I thought you'd say that.
> > Attached is a quick (ish) start.
> >
> > browse to
> > https://localhost:/redirect/protected/path/pageA/112233
> > Press the button *boom*
> >
> > Removing the WebSocketBehavior on  BasePage makes the page work
> > (Although in a real app I need this behavior)
> >
> > Would it be helpful if I created this on github?
> >
>
>
>
>
> Sorry for the noise.
>
> I've just tried this on Wicket 7.7 and it seems to be fixed already.
> WICKET-6342
>

Sorry for the breakage!
That was indeed a silly mistake!


>
> I don't know what's more embarrassing. Posting a dumb bug report or
> spending days trying to narrow down the bug.
> Now to upgrade my main app *fingers crossed*
>
>
> --
> Peter Henderson
>

Re: Websocket redirect wrong url

[Peter Henderson]

On 24 May 2017 at 11:05, Peter Henderson 
wrote:

>
>
> On 23 May 2017 at 22:24, Martin Grigorov  wrote:
>
>> Hi,
>>
>> I'm afraid a quickstart would be needed to be able to tell what goes wrong
>> there.
>>
>
> Thanks for looking, I thought you'd say that.
> Attached is a quick (ish) start.
>
> browse to
> https://localhost:/redirect/protected/path/pageA/112233
> Press the button *boom*
>
> Removing the WebSocketBehavior on  BasePage makes the page work
> (Although in a real app I need this behavior)
>
> Would it be helpful if I created this on github?
>




Sorry for the noise.

I've just tried this on Wicket 7.7 and it seems to be fixed already.
WICKET-6342

I don't know what's more embarrassing. Posting a dumb bug report or
spending days trying to narrow down the bug.
Now to upgrade my main app *fingers crossed*


-- 
Peter Henderson

Re: Websocket redirect wrong url

[Peter Henderson]

On 23 May 2017 at 22:24, Martin Grigorov <mgrigo...@apache.org> wrote:

> Hi,
>
> I'm afraid a quickstart would be needed to be able to tell what goes wrong
> there.
>

Thanks for looking, I thought you'd say that.
Attached is a quick (ish) start.

browse to
https://localhost:/redirect/protected/path/pageA/112233
Press the button *boom*

Removing the WebSocketBehavior on  BasePage makes the page work
(Although in a real app I need this behavior)

Would it be helpful if I created this on github?


>
> The appearance of /wicket/ in the url looks like either BookmarkableMapper
> (responsible for urls like /wicket/bookmarkable/com.example.Page) or
> PageInstanceMapper (responsible for urls like /wicket/page?123) is used
> instead of MountedMapper (used when the page path is configured with
> WebApplication#mountPage(String, Class) method).
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Tue, May 23, 2017 at 2:46 PM, Peter Henderson <
> peter.hender...@starjar.com> wrote:
>
> > Hi all.
> >
> >
> > I'm seeing a strange redirect problem which leads to a 404
> >
> >
> > Scenario.
> > 1) User is on fat bookmarkable page [1]
> > 2) Ajax onClick redirects to non bookmarkable SendMessagePage
> > 3) SendMessage page uses websockets + background threads.
> > 4) SendMessage page receives a websocket push event which it responds to
> > with [2] or [3]
> >
> > When redirecting back to a really simple DummyPage all is fine.
> > When redirecting back to the fat bookmarkable page I get a 404 on url
> > https://local.starjar.com:25000/Starjar/protected/wicket/35883
> >
> > Both DummyPage and PurchaseOrderPage are mounted the same way.
> >
> >
> >
> > What am I doing which is causing the incorrect redirect path?
> >
> >
> > I'm (still) trying to build a quick start that reproduces this problem.
> >
> >
> > Further testing.
> >
> > I created a new class called Dummy2 which is identical to
> > PurchaseOrderPage. Just a different name and mount point.
> > Redirecting to Dummy2 works fine .
> >
> > It looks like Dummy2 => Dummy2 and PurchaseOrderPage => PurchaseOrderPage
> > both fail with the incorrect relative url.
> >
> >
> >
> >
> > Many thanks
> >
> > Peter.
> >
> >
> >
> >
> >
> > [1]
> > https://local.starjar.com:25000/Starjar/protected/purchaseOrder/35883
> >
> > [2]
> > // This works as expected
> > // https://local.starjar.com:25000/Starjar/protected/dummy/12334
> > val pageCls = classOf[DummyDetailPage]
> > val pp = new PageParameters()
> > pp.set(WicketStarjarApplication.DetailPageIdParameterName, 12334)
> > throw new RestartResponseException(pageCls, pp)
> >
> >
> > [3]
> > // This does not work 404
> > // https://local.starjar.com:25000/Starjar/protected/wicket/35883
> > val pageCls = classOf[PurchaseOrderDetailPage]
> > val pp = new PageParameters()
> > pp.set(WicketStarjarApplication.DetailPageIdParameterName,
> businessId.pk)
> > throw new RestartResponseException(pageCls, pp)
> >
> >
> >
> > --
> > Peter Henderson
> >
>



-- 
Peter Henderson

Director
Starjar Ltd.
www.starjar.com
0330 088 1662


redirect.tar.gz
Description: GNU Zip compressed data

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

Re: Websocket redirect wrong url

[Martin Grigorov]

Hi,

I'm afraid a quickstart would be needed to be able to tell what goes wrong
there.

The appearance of /wicket/ in the url looks like either BookmarkableMapper
(responsible for urls like /wicket/bookmarkable/com.example.Page) or
PageInstanceMapper (responsible for urls like /wicket/page?123) is used
instead of MountedMapper (used when the page path is configured with
WebApplication#mountPage(String, Class) method).

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

On Tue, May 23, 2017 at 2:46 PM, Peter Henderson <
peter.hender...@starjar.com> wrote:

> Hi all.
>
>
> I'm seeing a strange redirect problem which leads to a 404
>
>
> Scenario.
> 1) User is on fat bookmarkable page [1]
> 2) Ajax onClick redirects to non bookmarkable SendMessagePage
> 3) SendMessage page uses websockets + background threads.
> 4) SendMessage page receives a websocket push event which it responds to
> with [2] or [3]
>
> When redirecting back to a really simple DummyPage all is fine.
> When redirecting back to the fat bookmarkable page I get a 404 on url
> https://local.starjar.com:25000/Starjar/protected/wicket/35883
>
> Both DummyPage and PurchaseOrderPage are mounted the same way.
>
>
>
> What am I doing which is causing the incorrect redirect path?
>
>
> I'm (still) trying to build a quick start that reproduces this problem.
>
>
> Further testing.
>
> I created a new class called Dummy2 which is identical to
> PurchaseOrderPage. Just a different name and mount point.
> Redirecting to Dummy2 works fine .
>
> It looks like Dummy2 => Dummy2 and PurchaseOrderPage => PurchaseOrderPage
> both fail with the incorrect relative url.
>
>
>
>
> Many thanks
>
> Peter.
>
>
>
>
>
> [1]
> https://local.starjar.com:25000/Starjar/protected/purchaseOrder/35883
>
> [2]
> // This works as expected
> // https://local.starjar.com:25000/Starjar/protected/dummy/12334
> val pageCls = classOf[DummyDetailPage]
> val pp = new PageParameters()
> pp.set(WicketStarjarApplication.DetailPageIdParameterName, 12334)
> throw new RestartResponseException(pageCls, pp)
>
>
> [3]
> // This does not work 404
> // https://local.starjar.com:25000/Starjar/protected/wicket/35883
> val pageCls = classOf[PurchaseOrderDetailPage]
> val pp = new PageParameters()
> pp.set(WicketStarjarApplication.DetailPageIdParameterName, businessId.pk)
> throw new RestartResponseException(pageCls, pp)
>
>
>
> --
> Peter Henderson
>

Websocket redirect wrong url

[Peter Henderson]

Hi all.


I'm seeing a strange redirect problem which leads to a 404


Scenario.
1) User is on fat bookmarkable page [1]
2) Ajax onClick redirects to non bookmarkable SendMessagePage
3) SendMessage page uses websockets + background threads.
4) SendMessage page receives a websocket push event which it responds to
with [2] or [3]

When redirecting back to a really simple DummyPage all is fine.
When redirecting back to the fat bookmarkable page I get a 404 on url
https://local.starjar.com:25000/Starjar/protected/wicket/35883

Both DummyPage and PurchaseOrderPage are mounted the same way.



What am I doing which is causing the incorrect redirect path?


I'm (still) trying to build a quick start that reproduces this problem.


Further testing.

I created a new class called Dummy2 which is identical to
PurchaseOrderPage. Just a different name and mount point.
Redirecting to Dummy2 works fine .

It looks like Dummy2 => Dummy2 and PurchaseOrderPage => PurchaseOrderPage
both fail with the incorrect relative url.




Many thanks

Peter.





[1]
https://local.starjar.com:25000/Starjar/protected/purchaseOrder/35883

[2]
// This works as expected
// https://local.starjar.com:25000/Starjar/protected/dummy/12334
val pageCls = classOf[DummyDetailPage]
val pp = new PageParameters()
pp.set(WicketStarjarApplication.DetailPageIdParameterName, 12334)
throw new RestartResponseException(pageCls, pp)


[3]
// This does not work 404
// https://local.starjar.com:25000/Starjar/protected/wicket/35883
val pageCls = classOf[PurchaseOrderDetailPage]
val pp = new PageParameters()
pp.set(WicketStarjarApplication.DetailPageIdParameterName, businessId.pk)
throw new RestartResponseException(pageCls, pp)



-- 
Peter Henderson

Re: "/websocket/closed" is not working in IE11

[Maxim Solodovnik]

The issue is not reproducible using simple quick-start :(
The only option seems to be to subscribe to error event as well :(

sorry for the noise

On Mon, Apr 10, 2017 at 3:09 PM, Maxim Solodovnik <solomax...@gmail.com>
wrote:

> Weird enough, quickstart works :(
> Investigation only begins :)
>
> On Mon, Apr 10, 2017 at 2:04 AM, Martin Grigorov <mgrigo...@apache.org>
> wrote:
>
>> On Sat, Apr 8, 2017 at 11:41 AM, Maxim Solodovnik <solomax...@gmail.com>
>> wrote:
>>
>> > Hello All,
>> >
>> > I just have noticed "/websocket/closed" is not working in IE11
>> > handler set via
>> > Wicket.Event.subscribe("/websocket/closed", function() {})
>> > Is not fired
>> >
>> > The following message displayed in console instead:
>> > SCRIPT12030: WebSocket Error: Network Error 12030, The connection with
>> the
>> > server was terminated abnormally
>> >
>> > Wicket: 8.0.0-M5
>> > OS: Win7/Win10
>> > Browser: IE11/Edge
>> >
>> > Should I file JIRA?
>> >
>>
>> Yes, with a quickstart please!
>>
>>
>> >
>> > --
>> > WBR
>> > Maxim aka solomax
>> >
>>
>
>
>
> --
> WBR
> Maxim aka solomax
>



-- 
WBR
Maxim aka solomax

Re: "/websocket/closed" is not working in IE11

[Maxim Solodovnik]

Weird enough, quickstart works :(
Investigation only begins :)

On Mon, Apr 10, 2017 at 2:04 AM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> On Sat, Apr 8, 2017 at 11:41 AM, Maxim Solodovnik <solomax...@gmail.com>
> wrote:
>
> > Hello All,
> >
> > I just have noticed "/websocket/closed" is not working in IE11
> > handler set via
> > Wicket.Event.subscribe("/websocket/closed", function() {})
> > Is not fired
> >
> > The following message displayed in console instead:
> > SCRIPT12030: WebSocket Error: Network Error 12030, The connection with
> the
> > server was terminated abnormally
> >
> > Wicket: 8.0.0-M5
> > OS: Win7/Win10
> > Browser: IE11/Edge
> >
> > Should I file JIRA?
> >
>
> Yes, with a quickstart please!
>
>
> >
> > --
> > WBR
> > Maxim aka solomax
> >
>



-- 
WBR
Maxim aka solomax

Re: "/websocket/closed" is not working in IE11

[Martin Grigorov]

On Sat, Apr 8, 2017 at 11:41 AM, Maxim Solodovnik <solomax...@gmail.com>
wrote:

> Hello All,
>
> I just have noticed "/websocket/closed" is not working in IE11
> handler set via
> Wicket.Event.subscribe("/websocket/closed", function() {})
> Is not fired
>
> The following message displayed in console instead:
> SCRIPT12030: WebSocket Error: Network Error 12030, The connection with the
> server was terminated abnormally
>
> Wicket: 8.0.0-M5
> OS: Win7/Win10
> Browser: IE11/Edge
>
> Should I file JIRA?
>

Yes, with a quickstart please!


>
> --
> WBR
> Maxim aka solomax
>

"/websocket/closed" is not working in IE11

[Maxim Solodovnik]

Hello All,

I just have noticed "/websocket/closed" is not working in IE11
handler set via
Wicket.Event.subscribe("/websocket/closed", function() {})
Is not fired

The following message displayed in console instead:
SCRIPT12030: WebSocket Error: Network Error 12030, The connection with the
server was terminated abnormally

Wicket: 8.0.0-M5
OS: Win7/Win10
Browser: IE11/Edge

Should I file JIRA?

-- 
WBR
Maxim aka solomax

How to add some data to ajax and websocket response?

[Daniel Stoch]

Hi,

I am trying to solve WICKET-5588. I want to add some ordering
information (key-value) to responses for ajax and websocket. This
information then will be read on client side (JS) to handle proper
processing order of responses. But I cannot find a good entry point to
add such generic information (order information should be calculated
in context of page/component).
How to add such information to response in Wicket 6.x?

--
Best regards,
Daniel

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

Re: Wicket Websocket - Exception is logged in WicketEndpoint if the user is closing the browser

[Martin Grigorov]

Hi,

Please try with Tomcat 8.5.11. There were some improvements lately.
What I find strange in the stacktrace is that the server is notified that
the client closed the connection and still it tries to write a close frame
back to it.
I have two recommendations:
1) switch temporarily to English locale so that the error messages are more
clear to non-German people. Google Translate helps but the message doesn't
directly map to any of the error messages I know of in English
2) ask this question in Tomcat forums (us...@tomcat.apache.org)

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

On Sat, Jan 28, 2017 at 8:40 PM, Marc <marcgiff...@web.de> wrote:

> It seems that this exception only occurs in Google Chrome...
>
> --
> View this message in context: http://apache-wicket.1842946.
> n4.nabble.com/Wicket-Websocket-Exception-is-logged-
> in-WicketEndpoint-if-the-user-is-closing-the-browser-
> tp4676886p4676889.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: Wicket Websocket - Exception is logged in WicketEndpoint if the user is closing the browser

[Marc]

It seems that this exception only occurs in Google Chrome...

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Wicket-Websocket-Exception-is-logged-in-WicketEndpoint-if-the-user-is-closing-the-browser-tp4676886p4676889.html
Sent from the Users forum mailing list archive at Nabble.com.

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

Wicket Websocket - Exception is logged in WicketEndpoint if the user is closing the browser

[Marc]

Hi,

I've a page with a WebSocketBehavior. Everything is OK until the user is
closing the browser or tab. An exception is logged in
org.apache.wicket.protocol.ws.javax.WicketEndpoint. 

I don't know if this kind of exception should reach the onError method.
Everything is working fine but the error message is annoying. Is it really
an error which should be logged?

I've created a quickstart attached. websockets.zip
<http://apache-wicket.1842946.n4.nabble.com/file/n4676886/websockets.zip>  

Thanks!

2017-01-27 20:55:44.672 ERROR 18092 --- [nio-8080-exec-2]
o.a.w.protocol.ws.javax.WicketEndpoint   : An error occurred in web socket
connection with id : 1

java.io.IOException: java.io.IOException: Eine bestehende Verbindung wurde
softwaregesteuert
durch den Hostcomputer abgebrochen (an existing connection was forcibly
closed by the remote host)
at
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:315)
~[tomcat-embed-websocket-8.5.6.jar:8.5.6]
at
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:258)
~[tomcat-embed-websocket-8.5.6.jar:8.5.6]
at
org.apache.tomcat.websocket.WsSession.sendCloseMessage(WsSession.java:606)
[tomcat-embed-websocket-8.5.6.jar:8.5.6]
at org.apache.tomcat.websocket.WsSession.onClose(WsSession.java:526)
[tomcat-embed-websocket-8.5.6.jar:8.5.6]
at
org.apache.tomcat.websocket.WsFrameBase.processDataControl(WsFrameBase.java:348)
[tomcat-embed-websocket-8.5.6.jar:8.5.6]
at
org.apache.tomcat.websocket.WsFrameBase.processData(WsFrameBase.java:290)
[tomcat-embed-websocket-8.5.6.jar:8.5.6]
at
org.apache.tomcat.websocket.WsFrameBase.processInputBuffer(WsFrameBase.java:131)
[tomcat-embed-websocket-8.5.6.jar:8.5.6]
at
org.apache.tomcat.websocket.server.WsFrameServer.onDataAvailable(WsFrameServer.java:69)
[tomcat-embed-websocket-8.5.6.jar:8.5.6]
at
org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.upgradeDispatch(WsHttpUpgradeHandler.java:148)
[tomcat-embed-websocket-8.5.6.jar:8.5.6]
at
org.apache.coyote.http11.upgrade.UpgradeProcessorInternal.dispatch(UpgradeProcessorInternal.java:54)
[tomcat-embed-core-8.5.6.jar:8.5.6]
at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:53)
[tomcat-embed-core-8.5.6.jar:8.5.6]
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:802)
[tomcat-embed-core-8.5.6.jar:8.5.6]
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1410)
[tomcat-embed-core-8.5.6.jar:8.5.6]
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
[tomcat-embed-core-8.5.6.jar:8.5.6]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[na:1.8.0_91]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[na:1.8.0_91]
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
[tomcat-embed-core-8.5.6.jar:8.5.6]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
Caused by: java.io.IOException: Eine bestehende Verbindung wurde
softwaregesteuert
durch den Hostcomputer abgebrochen
at sun.nio.ch.SocketDispatcher.write0(Native Method) ~[na:1.8.0_91]
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:51)
~[na:1.8.0_91]
at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) 
~[na:1.8.0_91]
at sun.nio.ch.IOUtil.write(IOUtil.java:65) ~[na:1.8.0_91]
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471)
~[na:1.8.0_91]
at org.apache.tomcat.util.net.NioChannel.write(NioChannel.java:134)
~[tomcat-embed-core-8.5.6.jar:8.5.6]
at
org.apache.tomcat.util.net.NioBlockingSelector.write(NioBlockingSelector.java:101)
~[tomcat-embed-core-8.5.6.jar:8.5.6]
at
org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.java:157)
~[tomcat-embed-core-8.5.6.jar:8.5.6]
at
org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.doWrite(NioEndpoint.java:1221)
~[tomcat-embed-core-8.5.6.jar:8.5.6]
at
org.apache.tomcat.util.net.SocketWrapperBase.flushBlocking(SocketWrapperBase.java:451)
~[tomcat-embed-core-8.5.6.jar:8.5.6]
at
org.apache.tomcat.util.net.SocketWrapperBase.flush(SocketWrapperBase.java:441)
~[tomcat-embed-core-8.5.6.jar:8.5.6]
at
org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.doWrite(WsRemoteEndpointImplServer.java:97)
~[tomcat-embed-websocket-8.5.6.jar:8.5.6]
at
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMessagePart(WsRemoteEndpointImplBase.java:494)
~[tomcat-embed-websocket-8.5.6.jar:8.5.6]
at
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:309)
~[tomcat-embed-websocket-8.5.6.jar:8.5.6]
... 17 common frames omitted

--
View this m

Re: After upgrade to Wicket 7.6.0, WebSocket logs Broken pipe

[Francesco Chicchiriccò]

On 04/01/2017 10:41, Martin Grigorov wrote:

Hi,

My question was: have you updated Tomcat lately?
Maybe you have upgraded from older and working version to latest/broken one.


Ah, I understand: you might be right, then.

It seems that the features connected to web sockets are working fine 
anyway; at first access, no error message; subsequent accesses report 
errors in the logs when switching across pages.


Hence, I guess that the problem occurs because somehow the web socket is 
not closed when going into a new page.


Regards.


On Wed, Jan 4, 2017 at 10:29 AM, Francesco Chicchiriccò <ilgro...@apache.org> 
wrote:


On 04/01/2017 10:14, Martin Grigorov wrote:


Hi,

Have you updated Tomcat version too?
I don't see any reason why changes in Wicket Native WebSocket could lead
to
this.
In the same time there were many improvements in Tomcat WebSocket code,
and
this might led to a regression.


Hi,
this happens both with Tomcat 8.5.9 and 8.0.39, which are the latest
versions available.

I have also tried with Tomcat 8.5.8 and 8.5.6 with same results.


On Wed, Jan 4, 2017 at 10:07 AM, Francesco Chicchiriccò <

ilgro...@apache.org> wrote:


Hi all,
after upgrading to Wicket 7.6.0 [1], this code [2] is causing the
following error in the logs:

10:02:16.300 ERROR org.apache.wicket.protocol.ws.javax.WicketEndpoint -
An error occurred in web socket connection with id : 0
java.io.IOException: Broken pipe
  at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
~[?:1.8.0_111]
  at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
~[?:1.8.0_111]
  at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
~[?:1.8.0_111]
  at sun.nio.ch.IOUtil.write(IOUtil.java:65) ~[?:1.8.0_111]
  at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:47
1)
~[?:1.8.0_111]
  at org.apache.tomcat.util.net.NioChannel.write(NioChannel.java:
124)
~[tomcat-coyote.jar:8.0.39]
  at org.apache.tomcat.util.net.NioSelectorPool.write(NioSelector
Pool.java:183)
~[tomcat-coyote.jar:8.0.39]
  at org.apache.coyote.http11.upgrade.NioServletOutputStream.doWr
iteInternal(NioServletOutputStream.java:94) ~[tomcat-coyote.jar:8.0.39]
  at org.apache.coyote.http11.upgrade.NioServletOutputStream.doWr
ite(NioServletOutputStream.java:61) ~[tomcat-coyote.jar:8.0.39]
  at org.apache.coyote.http11.upgrade.AbstractServletOutputStream
.writeInternal(AbstractServletOutputStream.java:165)
~[tomcat-coyote.jar:8.0.39]
  at org.apache.coyote.http11.upgrade.AbstractServletOutputStream
.write(AbstractServletOutputStream.java:132) ~[tomcat-coyote.jar:8.0.39]
  at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServe
r.onWritePossible(WsRemoteEndpointImplServer.java:98)
~[tomcat-websocket.jar:8.0.39]
  at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServe
r.doWrite(WsRemoteEndpointImplServer.java:79)
~[tomcat-websocket.jar:8.0.39]
  at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMe
ssagePart(WsRemoteEndpointImplBase.java:453)
~[tomcat-websocket.jar:8.0.39]
  at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMe
ssage(WsRemoteEndpointImplBase.java:341) ~[tomcat-websocket.jar:8.0.39]
  at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMe
ssageBlock(WsRemoteEndpointImplBase.java:273)
~[tomcat-websocket.jar:8.0.39]
  at org.apache.tomcat.websocket.WsSession.sendCloseMessage(WsSes
sion.java:600)
~[tomcat-websocket.jar:8.0.39]
  at org.apache.tomcat.websocket.WsSession.onClose(WsSession.java
:522)
~[tomcat-websocket.jar:8.0.39]
  at org.apache.tomcat.websocket.WsFrameBase.processDataControl(W
sFrameBase.java:348)
~[tomcat-websocket.jar:8.0.39]
  at org.apache.tomcat.websocket.WsFrameBase.processData(WsFrameB
ase.java:290)
~[tomcat-websocket.jar:8.0.39]
  at org.apache.tomcat.websocket.WsFrameBase.processInputBuffer(W
sFrameBase.java:131)
~[tomcat-websocket.jar:8.0.39]
  at org.apache.tomcat.websocket.server.WsFrameServer.onDataAvail
able(WsFrameServer.java:71)
~[tomcat-websocket.jar:8.0.39]
  at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsRe
adListener.onDataAvailable(WsHttpUpgradeHandler.java:185)
~[tomcat-websocket.jar:8.0.39]
  at org.apache.coyote.http11.upgrade.AbstractServletInputStream.
onDataAvailable(AbstractServletInputStream.java:198)
~[tomcat-coyote.jar:8.0.39]
  at org.apache.coyote.http11.upgrade.AbstractProcessor.upgradeDi
spatch(AbstractProcessor.java:96) ~[tomcat-coyote.jar:8.0.39]
  at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler
.process(AbstractProtocol.java:661) ~[tomcat-coyote.jar:8.0.39]
  at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
(NioEndpoint.java:1520)
~[tomcat-coyote.jar:8.0.39]
  at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(
NioEndpoint.java:1476)
~[tomcat-coyot

Re: After upgrade to Wicket 7.6.0, WebSocket logs Broken pipe

[Martin Grigorov]

Hi,

My question was: have you updated Tomcat lately?
Maybe you have upgraded from older and working version to latest/broken one.

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

On Wed, Jan 4, 2017 at 10:29 AM, Francesco Chicchiriccò <ilgro...@apache.org
> wrote:

> On 04/01/2017 10:14, Martin Grigorov wrote:
>
>> Hi,
>>
>> Have you updated Tomcat version too?
>> I don't see any reason why changes in Wicket Native WebSocket could lead
>> to
>> this.
>> In the same time there were many improvements in Tomcat WebSocket code,
>> and
>> this might led to a regression.
>>
>
> Hi,
> this happens both with Tomcat 8.5.9 and 8.0.39, which are the latest
> versions available.
>
> I have also tried with Tomcat 8.5.8 and 8.5.6 with same results.
>
>
> On Wed, Jan 4, 2017 at 10:07 AM, Francesco Chicchiriccò <
>> ilgro...@apache.org> wrote:
>>
>>> Hi all,
>>> after upgrading to Wicket 7.6.0 [1], this code [2] is causing the
>>> following error in the logs:
>>>
>>> 10:02:16.300 ERROR org.apache.wicket.protocol.ws.javax.WicketEndpoint -
>>> An error occurred in web socket connection with id : 0
>>> java.io.IOException: Broken pipe
>>>  at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
>>> ~[?:1.8.0_111]
>>>  at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
>>> ~[?:1.8.0_111]
>>>  at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
>>> ~[?:1.8.0_111]
>>>  at sun.nio.ch.IOUtil.write(IOUtil.java:65) ~[?:1.8.0_111]
>>>  at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:47
>>> 1)
>>> ~[?:1.8.0_111]
>>>  at org.apache.tomcat.util.net.NioChannel.write(NioChannel.java:
>>> 124)
>>> ~[tomcat-coyote.jar:8.0.39]
>>>  at org.apache.tomcat.util.net.NioSelectorPool.write(NioSelector
>>> Pool.java:183)
>>> ~[tomcat-coyote.jar:8.0.39]
>>>  at org.apache.coyote.http11.upgrade.NioServletOutputStream.doWr
>>> iteInternal(NioServletOutputStream.java:94) ~[tomcat-coyote.jar:8.0.39]
>>>  at org.apache.coyote.http11.upgrade.NioServletOutputStream.doWr
>>> ite(NioServletOutputStream.java:61) ~[tomcat-coyote.jar:8.0.39]
>>>  at org.apache.coyote.http11.upgrade.AbstractServletOutputStream
>>> .writeInternal(AbstractServletOutputStream.java:165)
>>> ~[tomcat-coyote.jar:8.0.39]
>>>  at org.apache.coyote.http11.upgrade.AbstractServletOutputStream
>>> .write(AbstractServletOutputStream.java:132) ~[tomcat-coyote.jar:8.0.39]
>>>  at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServe
>>> r.onWritePossible(WsRemoteEndpointImplServer.java:98)
>>> ~[tomcat-websocket.jar:8.0.39]
>>>  at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServe
>>> r.doWrite(WsRemoteEndpointImplServer.java:79)
>>> ~[tomcat-websocket.jar:8.0.39]
>>>  at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMe
>>> ssagePart(WsRemoteEndpointImplBase.java:453)
>>> ~[tomcat-websocket.jar:8.0.39]
>>>  at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMe
>>> ssage(WsRemoteEndpointImplBase.java:341) ~[tomcat-websocket.jar:8.0.39]
>>>  at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMe
>>> ssageBlock(WsRemoteEndpointImplBase.java:273)
>>> ~[tomcat-websocket.jar:8.0.39]
>>>  at org.apache.tomcat.websocket.WsSession.sendCloseMessage(WsSes
>>> sion.java:600)
>>> ~[tomcat-websocket.jar:8.0.39]
>>>  at org.apache.tomcat.websocket.WsSession.onClose(WsSession.java
>>> :522)
>>> ~[tomcat-websocket.jar:8.0.39]
>>>  at org.apache.tomcat.websocket.WsFrameBase.processDataControl(W
>>> sFrameBase.java:348)
>>> ~[tomcat-websocket.jar:8.0.39]
>>>  at org.apache.tomcat.websocket.WsFrameBase.processData(WsFrameB
>>> ase.java:290)
>>> ~[tomcat-websocket.jar:8.0.39]
>>>  at org.apache.tomcat.websocket.WsFrameBase.processInputBuffer(W
>>> sFrameBase.java:131)
>>> ~[tomcat-websocket.jar:8.0.39]
>>>  at org.apache.tomcat.websocket.server.WsFrameServer.onDataAvail
>>> able(WsFrameServer.java:71)
>>> ~[tomcat-websocket.jar:8.0.39]
>>>  at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsRe
>>> adListener.onDataAvailable(WsHttpUpgradeHandler.java:185)
>>> ~[tomcat-websocket.jar:8.0.39]
>

Re: After upgrade to Wicket 7.6.0, WebSocket logs Broken pipe

[Francesco Chicchiriccò]

On 04/01/2017 10:29, Francesco Chicchiriccò wrote:

On 04/01/2017 10:14, Martin Grigorov wrote:

Hi,

Have you updated Tomcat version too?
I don't see any reason why changes in Wicket Native WebSocket could 
lead to

this.
In the same time there were many improvements in Tomcat WebSocket 
code, and

this might led to a regression.


Hi,
this happens both with Tomcat 8.5.9 and 8.0.39, which are the latest 
versions available.


I have also tried with Tomcat 8.5.8 and 8.5.6 with same results.


It seems that the features connected to web sockets are working fine 
anyway; at first access, no error message; subsequent accesses report 
errors in the logs when switching across pages.


Hence, I guess that the problem occurs because somehow the web socket is 
not closed when going into a new page.


Regards.

On Wed, Jan 4, 2017 at 10:07 AM, Francesco Chicchiriccò 
<ilgro...@apache.org> wrote:

Hi all,
after upgrading to Wicket 7.6.0 [1], this code [2] is causing the
following error in the logs:

10:02:16.300 ERROR org.apache.wicket.protocol.ws.javax.WicketEndpoint -
An error occurred in web socket connection with id : 0
java.io.IOException: Broken pipe
 at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
~[?:1.8.0_111]
 at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
~[?:1.8.0_111]
 at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
~[?:1.8.0_111]
 at sun.nio.ch.IOUtil.write(IOUtil.java:65) ~[?:1.8.0_111]
 at 
sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471)

~[?:1.8.0_111]
 at 
org.apache.tomcat.util.net.NioChannel.write(NioChannel.java:124)

~[tomcat-coyote.jar:8.0.39]
 at 
org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.java:183)

~[tomcat-coyote.jar:8.0.39]
 at 
org.apache.coyote.http11.upgrade.NioServletOutputStream.doWr

iteInternal(NioServletOutputStream.java:94) ~[tomcat-coyote.jar:8.0.39]
 at 
org.apache.coyote.http11.upgrade.NioServletOutputStream.doWr

ite(NioServletOutputStream.java:61) ~[tomcat-coyote.jar:8.0.39]
 at 
org.apache.coyote.http11.upgrade.AbstractServletOutputStream

.writeInternal(AbstractServletOutputStream.java:165)
~[tomcat-coyote.jar:8.0.39]
 at 
org.apache.coyote.http11.upgrade.AbstractServletOutputStream
.write(AbstractServletOutputStream.java:132) 
~[tomcat-coyote.jar:8.0.39]
 at 
org.apache.tomcat.websocket.server.WsRemoteEndpointImplServe

r.onWritePossible(WsRemoteEndpointImplServer.java:98)
~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.tomcat.websocket.server.WsRemoteEndpointImplServe

r.doWrite(WsRemoteEndpointImplServer.java:79)
~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMe

ssagePart(WsRemoteEndpointImplBase.java:453)
~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMe

ssage(WsRemoteEndpointImplBase.java:341) ~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMe

ssageBlock(WsRemoteEndpointImplBase.java:273)
~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.tomcat.websocket.WsSession.sendCloseMessage(WsSession.java:600)

~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.tomcat.websocket.WsSession.onClose(WsSession.java:522)

~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.tomcat.websocket.WsFrameBase.processDataControl(WsFrameBase.java:348)

~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.tomcat.websocket.WsFrameBase.processData(WsFrameBase.java:290)

~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.tomcat.websocket.WsFrameBase.processInputBuffer(WsFrameBase.java:131)

~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.tomcat.websocket.server.WsFrameServer.onDataAvailable(WsFrameServer.java:71)

~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsRe

adListener.onDataAvailable(WsHttpUpgradeHandler.java:185)
~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.coyote.http11.upgrade.AbstractServletInputStream.

onDataAvailable(AbstractServletInputStream.java:198)
~[tomcat-coyote.jar:8.0.39]
 at 
org.apache.coyote.http11.upgrade.AbstractProcessor.upgradeDi

spatch(AbstractProcessor.java:96) ~[tomcat-coyote.jar:8.0.39]
 at 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler

.process(AbstractProtocol.java:661) ~[tomcat-coyote.jar:8.0.39]
 at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1520)

~[tomcat-coyote.jar:8.0.39]
 at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1476)

~[tomcat-coyote.jar:8.0.39]
 at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

[?:1.8.0_111]
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

[?:1.8

Re: After upgrade to Wicket 7.6.0, WebSocket logs Broken pipe

[Francesco Chicchiriccò]

On 04/01/2017 10:14, Martin Grigorov wrote:

Hi,

Have you updated Tomcat version too?
I don't see any reason why changes in Wicket Native WebSocket could lead to
this.
In the same time there were many improvements in Tomcat WebSocket code, and
this might led to a regression.


Hi,
this happens both with Tomcat 8.5.9 and 8.0.39, which are the latest 
versions available.


I have also tried with Tomcat 8.5.8 and 8.5.6 with same results.


On Wed, Jan 4, 2017 at 10:07 AM, Francesco Chicchiriccò <ilgro...@apache.org> 
wrote:

Hi all,
after upgrading to Wicket 7.6.0 [1], this code [2] is causing the
following error in the logs:

10:02:16.300 ERROR org.apache.wicket.protocol.ws.javax.WicketEndpoint -
An error occurred in web socket connection with id : 0
java.io.IOException: Broken pipe
 at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
~[?:1.8.0_111]
 at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
~[?:1.8.0_111]
 at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
~[?:1.8.0_111]
 at sun.nio.ch.IOUtil.write(IOUtil.java:65) ~[?:1.8.0_111]
 at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471)
~[?:1.8.0_111]
 at org.apache.tomcat.util.net.NioChannel.write(NioChannel.java:124)
~[tomcat-coyote.jar:8.0.39]
 at 
org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.java:183)
~[tomcat-coyote.jar:8.0.39]
 at org.apache.coyote.http11.upgrade.NioServletOutputStream.doWr
iteInternal(NioServletOutputStream.java:94) ~[tomcat-coyote.jar:8.0.39]
 at org.apache.coyote.http11.upgrade.NioServletOutputStream.doWr
ite(NioServletOutputStream.java:61) ~[tomcat-coyote.jar:8.0.39]
 at org.apache.coyote.http11.upgrade.AbstractServletOutputStream
.writeInternal(AbstractServletOutputStream.java:165)
~[tomcat-coyote.jar:8.0.39]
 at org.apache.coyote.http11.upgrade.AbstractServletOutputStream
.write(AbstractServletOutputStream.java:132) ~[tomcat-coyote.jar:8.0.39]
 at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServe
r.onWritePossible(WsRemoteEndpointImplServer.java:98)
~[tomcat-websocket.jar:8.0.39]
 at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServe
r.doWrite(WsRemoteEndpointImplServer.java:79)
~[tomcat-websocket.jar:8.0.39]
 at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMe
ssagePart(WsRemoteEndpointImplBase.java:453)
~[tomcat-websocket.jar:8.0.39]
 at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMe
ssage(WsRemoteEndpointImplBase.java:341) ~[tomcat-websocket.jar:8.0.39]
 at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMe
ssageBlock(WsRemoteEndpointImplBase.java:273)
~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.tomcat.websocket.WsSession.sendCloseMessage(WsSession.java:600)
~[tomcat-websocket.jar:8.0.39]
 at org.apache.tomcat.websocket.WsSession.onClose(WsSession.java:522)
~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.tomcat.websocket.WsFrameBase.processDataControl(WsFrameBase.java:348)
~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.tomcat.websocket.WsFrameBase.processData(WsFrameBase.java:290)
~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.tomcat.websocket.WsFrameBase.processInputBuffer(WsFrameBase.java:131)
~[tomcat-websocket.jar:8.0.39]
 at 
org.apache.tomcat.websocket.server.WsFrameServer.onDataAvailable(WsFrameServer.java:71)
~[tomcat-websocket.jar:8.0.39]
 at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsRe
adListener.onDataAvailable(WsHttpUpgradeHandler.java:185)
~[tomcat-websocket.jar:8.0.39]
 at org.apache.coyote.http11.upgrade.AbstractServletInputStream.
onDataAvailable(AbstractServletInputStream.java:198)
~[tomcat-coyote.jar:8.0.39]
 at org.apache.coyote.http11.upgrade.AbstractProcessor.upgradeDi
spatch(AbstractProcessor.java:96) ~[tomcat-coyote.jar:8.0.39]
 at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler
.process(AbstractProtocol.java:661) ~[tomcat-coyote.jar:8.0.39]
 at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1520)
~[tomcat-coyote.jar:8.0.39]
 at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1476)
~[tomcat-coyote.jar:8.0.39]
 at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[?:1.8.0_111]
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[?:1.8.0_111]
 at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
~[tomcat-util.jar:8.0.39]
 at java.lang.Thread.run(Thread.java:745) [?:1.8.0_111]

The error is repeated for each page, with connection id incremented.

This used to work fine with Wicket 7.4.0; with Wicket 7.5.0 we had to
introduce this backport [3] which seems anyway not affecting the problem
above.

Could you please shade some light? Thanks!
Regard

Re: After upgrade to Wicket 7.6.0, WebSocket logs Broken pipe

[Martin Grigorov]

Hi,

Have you updated Tomcat version too?
I don't see any reason why changes in Wicket Native WebSocket could lead to
this.
In the same time there were many improvements in Tomcat WebSocket code, and
this might led to a regression.

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

On Wed, Jan 4, 2017 at 10:07 AM, Francesco Chicchiriccò <ilgro...@apache.org
> wrote:

> Hi all,
> after upgrading to Wicket 7.6.0 [1], this code [2] is causing the
> following error in the logs:
>
> 10:02:16.300 ERROR org.apache.wicket.protocol.ws.javax.WicketEndpoint -
> An error occurred in web socket connection with id : 0
> java.io.IOException: Broken pipe
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> ~[?:1.8.0_111]
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
> ~[?:1.8.0_111]
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> ~[?:1.8.0_111]
> at sun.nio.ch.IOUtil.write(IOUtil.java:65) ~[?:1.8.0_111]
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471)
> ~[?:1.8.0_111]
> at org.apache.tomcat.util.net.NioChannel.write(NioChannel.java:124)
> ~[tomcat-coyote.jar:8.0.39]
> at 
> org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.java:183)
> ~[tomcat-coyote.jar:8.0.39]
> at org.apache.coyote.http11.upgrade.NioServletOutputStream.doWr
> iteInternal(NioServletOutputStream.java:94) ~[tomcat-coyote.jar:8.0.39]
> at org.apache.coyote.http11.upgrade.NioServletOutputStream.doWr
> ite(NioServletOutputStream.java:61) ~[tomcat-coyote.jar:8.0.39]
> at org.apache.coyote.http11.upgrade.AbstractServletOutputStream
> .writeInternal(AbstractServletOutputStream.java:165)
> ~[tomcat-coyote.jar:8.0.39]
> at org.apache.coyote.http11.upgrade.AbstractServletOutputStream
> .write(AbstractServletOutputStream.java:132) ~[tomcat-coyote.jar:8.0.39]
> at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServe
> r.onWritePossible(WsRemoteEndpointImplServer.java:98)
> ~[tomcat-websocket.jar:8.0.39]
> at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServe
> r.doWrite(WsRemoteEndpointImplServer.java:79)
> ~[tomcat-websocket.jar:8.0.39]
> at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMe
> ssagePart(WsRemoteEndpointImplBase.java:453)
> ~[tomcat-websocket.jar:8.0.39]
> at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMe
> ssage(WsRemoteEndpointImplBase.java:341) ~[tomcat-websocket.jar:8.0.39]
> at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMe
> ssageBlock(WsRemoteEndpointImplBase.java:273)
> ~[tomcat-websocket.jar:8.0.39]
> at 
> org.apache.tomcat.websocket.WsSession.sendCloseMessage(WsSession.java:600)
> ~[tomcat-websocket.jar:8.0.39]
> at org.apache.tomcat.websocket.WsSession.onClose(WsSession.java:522)
> ~[tomcat-websocket.jar:8.0.39]
> at 
> org.apache.tomcat.websocket.WsFrameBase.processDataControl(WsFrameBase.java:348)
> ~[tomcat-websocket.jar:8.0.39]
> at 
> org.apache.tomcat.websocket.WsFrameBase.processData(WsFrameBase.java:290)
> ~[tomcat-websocket.jar:8.0.39]
> at 
> org.apache.tomcat.websocket.WsFrameBase.processInputBuffer(WsFrameBase.java:131)
> ~[tomcat-websocket.jar:8.0.39]
> at 
> org.apache.tomcat.websocket.server.WsFrameServer.onDataAvailable(WsFrameServer.java:71)
> ~[tomcat-websocket.jar:8.0.39]
> at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsRe
> adListener.onDataAvailable(WsHttpUpgradeHandler.java:185)
> ~[tomcat-websocket.jar:8.0.39]
> at org.apache.coyote.http11.upgrade.AbstractServletInputStream.
> onDataAvailable(AbstractServletInputStream.java:198)
> ~[tomcat-coyote.jar:8.0.39]
> at org.apache.coyote.http11.upgrade.AbstractProcessor.upgradeDi
> spatch(AbstractProcessor.java:96) ~[tomcat-coyote.jar:8.0.39]
> at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler
> .process(AbstractProtocol.java:661) ~[tomcat-coyote.jar:8.0.39]
> at 
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1520)
> ~[tomcat-coyote.jar:8.0.39]
> at 
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1476)
> ~[tomcat-coyote.jar:8.0.39]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [?:1.8.0_111]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [?:1.8.0_111]
> at 
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> ~[tomcat-util.jar:8.0.39]
> at java.lang.Thread.run(Thread.java:745) [?:1.8.0_111]
&

After upgrade to Wicket 7.6.0, WebSocket logs Broken pipe

[Francesco Chicchiriccò]

Hi all,
after upgrading to Wicket 7.6.0 [1], this code [2] is causing the 
following error in the logs:


10:02:16.300 ERROR org.apache.wicket.protocol.ws.javax.WicketEndpoint - 
An error occurred in web socket connection with id : 0

java.io.IOException: Broken pipe
at sun.nio.ch.FileDispatcherImpl.write0(Native Method) 
~[?:1.8.0_111]
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) 
~[?:1.8.0_111]
at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) 
~[?:1.8.0_111]

at sun.nio.ch.IOUtil.write(IOUtil.java:65) ~[?:1.8.0_111]
at 
sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471) 
~[?:1.8.0_111]
at 
org.apache.tomcat.util.net.NioChannel.write(NioChannel.java:124) 
~[tomcat-coyote.jar:8.0.39]
at 
org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.java:183) 
~[tomcat-coyote.jar:8.0.39]
at 
org.apache.coyote.http11.upgrade.NioServletOutputStream.doWriteInternal(NioServletOutputStream.java:94) 
~[tomcat-coyote.jar:8.0.39]
at 
org.apache.coyote.http11.upgrade.NioServletOutputStream.doWrite(NioServletOutputStream.java:61) 
~[tomcat-coyote.jar:8.0.39]
at 
org.apache.coyote.http11.upgrade.AbstractServletOutputStream.writeInternal(AbstractServletOutputStream.java:165) 
~[tomcat-coyote.jar:8.0.39]
at 
org.apache.coyote.http11.upgrade.AbstractServletOutputStream.write(AbstractServletOutputStream.java:132) 
~[tomcat-coyote.jar:8.0.39]
at 
org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.onWritePossible(WsRemoteEndpointImplServer.java:98) 
~[tomcat-websocket.jar:8.0.39]
at 
org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.doWrite(WsRemoteEndpointImplServer.java:79) 
~[tomcat-websocket.jar:8.0.39]
at 
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMessagePart(WsRemoteEndpointImplBase.java:453) 
~[tomcat-websocket.jar:8.0.39]
at 
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessage(WsRemoteEndpointImplBase.java:341) 
~[tomcat-websocket.jar:8.0.39]
at 
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessageBlock(WsRemoteEndpointImplBase.java:273) 
~[tomcat-websocket.jar:8.0.39]
at 
org.apache.tomcat.websocket.WsSession.sendCloseMessage(WsSession.java:600) 
~[tomcat-websocket.jar:8.0.39]
at 
org.apache.tomcat.websocket.WsSession.onClose(WsSession.java:522) 
~[tomcat-websocket.jar:8.0.39]
at 
org.apache.tomcat.websocket.WsFrameBase.processDataControl(WsFrameBase.java:348) 
~[tomcat-websocket.jar:8.0.39]
at 
org.apache.tomcat.websocket.WsFrameBase.processData(WsFrameBase.java:290) 
~[tomcat-websocket.jar:8.0.39]
at 
org.apache.tomcat.websocket.WsFrameBase.processInputBuffer(WsFrameBase.java:131) 
~[tomcat-websocket.jar:8.0.39]
at 
org.apache.tomcat.websocket.server.WsFrameServer.onDataAvailable(WsFrameServer.java:71) 
~[tomcat-websocket.jar:8.0.39]
at 
org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsReadListener.onDataAvailable(WsHttpUpgradeHandler.java:185) 
~[tomcat-websocket.jar:8.0.39]
at 
org.apache.coyote.http11.upgrade.AbstractServletInputStream.onDataAvailable(AbstractServletInputStream.java:198) 
~[tomcat-coyote.jar:8.0.39]
at 
org.apache.coyote.http11.upgrade.AbstractProcessor.upgradeDispatch(AbstractProcessor.java:96) 
~[tomcat-coyote.jar:8.0.39]
at 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:661) 
~[tomcat-coyote.jar:8.0.39]
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1520) 
~[tomcat-coyote.jar:8.0.39]
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1476) 
~[tomcat-coyote.jar:8.0.39]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
[?:1.8.0_111]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[?:1.8.0_111]
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) 
~[tomcat-util.jar:8.0.39]

at java.lang.Thread.run(Thread.java:745) [?:1.8.0_111]

The error is repeated for each page, with connection id incremented.

This used to work fine with Wicket 7.4.0; with Wicket 7.5.0 we had to 
introduce this backport [3] which seems anyway not affecting the problem 
above.


Could you please shade some light? Thanks!
Regards.

[1] 
https://github.com/apache/syncope/commit/830fdee246eff396118938fbab61e076fa499678
[2] 
https://github.com/apache/syncope/blob/2_0_X/client/console/src/main/java/org/apache/syncope/client/console/pages/BasePage.java#L91-L110
[3] 
https://github.com/apache/syncope/commit/830fdee246eff396118938fbab61e076fa499678#diff-c8d9c2a6a0a2e892467d2b3ef8c0c925


--
Francesco Chicchiriccò

Tirasa - Open Source Excellence
http://www.tirasa.net/

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, 

Re: WebSocket ConnectedMessage not Serializable

[Peter Henderson]

Ha! You've already fixed it.
Ignore my pull request. (I spent too much time getting my scala -> java
code compiling)

Thanks

Peter.

Re: WebSocket ConnectedMessage not Serializable

[Martin Grigorov]

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

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

On Sat, Nov 19, 2016 at 4:41 PM, Martin Grigorov 
wrote:

> Hi Peter,
>
> I don't see a problem to make all msgs serializable.
> Please create a ticket!
> With a Pull Request/Patch would be awesome!
> Thank you!
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Sat, Nov 19, 2016 at 3:46 PM, Peter Henderson <
> peter.hender...@starjar.com> wrote:
>
>> Hi all.
>>
>> Wicket 7.3.0
>> Native web sockets.
>> Tomcat 8.5.5
>>
>> I am trying to do background processing with results being pushed to a
>> client as they become available.
>>
>> I store the connected message when a web socket connection is made [1].
>> This is used to fire push data to a single client/page [2]
>>
>> A little bit of googling I find [3].
>> Am I incorrectly using the api?
>> The ConnectedMessage is not serializable [4]
>>
>>
>>
>> Thanks
>>
>> Peter.
>>
>>
>>
>>
>> [1]
>> private var connected: ConnectedMessage = _
>>
>> add(new WebSocketBehavior {
>>   override def onConnect(message: ConnectedMessage): Unit = {
>> super.onConnect(message)
>> println("web socket connected.")
>> connected = message
>>   }
>> })
>>
>>
>>
>> [2]
>> private def broadcast(msg: IWebSocketPushMessage): Unit = {
>>   val application = WicketStarjarApplication.get()
>>   val webSocketSettings = WebSocketSettings.Holder.get(application)
>>   val broadcaster = new
>> WebSocketPushBroadcaster(webSocketSettings.getConnectionRegistry())
>>   broadcaster.broadcast(connected, msg)
>> }
>>
>>
>> [3]
>> http://apache-wicket.1842946.n4.nabble.com/WebSockets-IKey-n
>> ot-Serializable-td4666996.html
>> https://issues.apache.org/jira/browse/WICKET-5670
>>
>>
>> [4]
>> org.apache.wicket.core.util.objects.checker.CheckingObjectOu
>> tputStream$ObjectCheckException:
>> The object type is not Serializable!
>> A problem occurred while checking object with type:
>> org.apache.wicket.protocol.ws.api.message.ConnectedMessage
>>
>>
>>
>>
>>
>>
>> --
>> Peter Henderson
>>
>
>

Re: WebSocket ConnectedMessage not Serializable

[Martin Grigorov]

Hi Peter,

I don't see a problem to make all msgs serializable.
Please create a ticket!
With a Pull Request/Patch would be awesome!
Thank you!

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

On Sat, Nov 19, 2016 at 3:46 PM, Peter Henderson <
peter.hender...@starjar.com> wrote:

> Hi all.
>
> Wicket 7.3.0
> Native web sockets.
> Tomcat 8.5.5
>
> I am trying to do background processing with results being pushed to a
> client as they become available.
>
> I store the connected message when a web socket connection is made [1].
> This is used to fire push data to a single client/page [2]
>
> A little bit of googling I find [3].
> Am I incorrectly using the api?
> The ConnectedMessage is not serializable [4]
>
>
>
> Thanks
>
> Peter.
>
>
>
>
> [1]
> private var connected: ConnectedMessage = _
>
> add(new WebSocketBehavior {
>   override def onConnect(message: ConnectedMessage): Unit = {
> super.onConnect(message)
> println("web socket connected.")
> connected = message
>   }
> })
>
>
>
> [2]
> private def broadcast(msg: IWebSocketPushMessage): Unit = {
>   val application = WicketStarjarApplication.get()
>   val webSocketSettings = WebSocketSettings.Holder.get(application)
>   val broadcaster = new
> WebSocketPushBroadcaster(webSocketSettings.getConnectionRegistry())
>   broadcaster.broadcast(connected, msg)
> }
>
>
> [3]
> http://apache-wicket.1842946.n4.nabble.com/WebSockets-IKey-
> not-Serializable-td4666996.html
> https://issues.apache.org/jira/browse/WICKET-5670
>
>
> [4]
> org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream$
> ObjectCheckException:
> The object type is not Serializable!
> A problem occurred while checking object with type:
> org.apache.wicket.protocol.ws.api.message.ConnectedMessage
>
>
>
>
>
>
> --
> Peter Henderson
>

WebSocket ConnectedMessage not Serializable

[Peter Henderson]

Hi all.

Wicket 7.3.0
Native web sockets.
Tomcat 8.5.5

I am trying to do background processing with results being pushed to a
client as they become available.

I store the connected message when a web socket connection is made [1].
This is used to fire push data to a single client/page [2]

A little bit of googling I find [3].
Am I incorrectly using the api?
The ConnectedMessage is not serializable [4]



Thanks

Peter.




[1]
private var connected: ConnectedMessage = _

add(new WebSocketBehavior {
  override def onConnect(message: ConnectedMessage): Unit = {
super.onConnect(message)
println("web socket connected.")
connected = message
  }
})



[2]
private def broadcast(msg: IWebSocketPushMessage): Unit = {
  val application = WicketStarjarApplication.get()
  val webSocketSettings = WebSocketSettings.Holder.get(application)
  val broadcaster = new
WebSocketPushBroadcaster(webSocketSettings.getConnectionRegistry())
  broadcaster.broadcast(connected, msg)
}


[3]
http://apache-wicket.1842946.n4.nabble.com/WebSockets-IKey-not-Serializable-td4666996.html
https://issues.apache.org/jira/browse/WICKET-5670


[4]
org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream$ObjectCheckException:
The object type is not Serializable!
A problem occurred while checking object with type:
org.apache.wicket.protocol.ws.api.message.ConnectedMessage






-- 
Peter Henderson

Re: WebSocket close is being called if AjaxDownloader is used

[Maxim Solodovnik]

Done:
https://github.com/apache/wicket/pull/190
https://github.com/apache/wicket/pull/191

On Wed, Nov 16, 2016 at 5:14 PM, Martin Grigorov <martin.grigo...@gmail.com>
wrote:

> Hi Maxim,
>
> Please do!
>
> Thank you!
>
> On Nov 16, 2016 10:58 AM, "Maxim Solodovnik" <solomax...@gmail.com> wrote:
>
> > I believe all comments are now addressed,
> > Should I create PR to add AjaxDownload to wicket-extensions? both 7.x and
> > 8.x?
> >
> > On Fri, Nov 11, 2016 at 6:11 PM, Sven Meier <s...@meiers.net> wrote:
> >
> > > +1 on putting it into wicket-extensions.
> > >
> > > Sven
> > >
> > >
> > > Am 11.11.2016 um 10:54 schrieb Martin Grigorov:
> > >
> > >> One class + one .js might be too much for a new module but I don't
> want
> > >> all
> > >> the useless stuff in minis in my application too.
> > >> I still prefer this to be in Wicket core.
> > >>
> > >> Martin Grigorov
> > >> Wicket Training and Consulting
> > >> https://twitter.com/mtgrigorov
> > >>
> > >> On Fri, Nov 11, 2016 at 10:28 AM, Sven Meier <s...@meiers.net> wrote:
> > >>
> > >> I don't think this warrants a new module - just add it to
> > >>> wicketstuff-minis.
> > >>>
> > >>> Sven
> > >>>
> > >>>
> > >>>
> > >>> Am 11.11.2016 um 08:42 schrieb Martin Grigorov:
> > >>>
> > >>> Great work, Maxim!
> > >>>>
> > >>>> Let's move it to WicketStuff as a new module.
> > >>>> I'd like to add -examples module with different use cases so we can
> > see
> > >>>> whether the iframes leak or not for example.
> > >>>> Also I'd like to try to add events like beforeDownload/afterDownload
> > so
> > >>>> apps can show indicators that something is happening.
> > >>>>
> > >>>> Martin Grigorov
> > >>>> Wicket Training and Consulting
> > >>>> https://twitter.com/mtgrigorov
> > >>>>
> > >>>> On Wed, Nov 9, 2016 at 9:13 AM, Ernesto Reinaldo Barreiro <
> > >>>> reier...@gmail.com> wrote:
> > >>>>
> > >>>> Thanks for sharing. I just added a couple of comments/
> > >>>>
> > >>>>> On Wed, Nov 9, 2016 at 4:23 AM, Maxim Solodovnik <
> > solomax...@gmail.com
> > >>>>> >
> > >>>>> wrote:
> > >>>>>
> > >>>>> Hello Martin,
> > >>>>>
> > >>>>>> sorry for the delay
> > >>>>>>
> > >>>>>> here is the repo: https://github.com/solomax/wicket-ajax-download
> > >>>>>> here is the commit with the ajax-download-via-iframe
> implementation:
> > >>>>>> https://github.com/solomax/wicket-ajax-download/commit/
> > >>>>>> 407936d6f506aa047d9a12a3ecb7aa6c866eb052
> > >>>>>>
> > >>>>>> Looking forward for your comments :)
> > >>>>>>
> > >>>>>> On Wed, Nov 9, 2016 at 5:02 AM, Martin Grigorov <
> > mgrigo...@apache.org
> > >>>>>> >
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>> Hi Maxim,
> > >>>>>>>
> > >>>>>>> Do you have progress on this ?
> > >>>>>>>
> > >>>>>>> Martin Grigorov
> > >>>>>>> Wicket Training and Consulting
> > >>>>>>> https://twitter.com/mtgrigorov
> > >>>>>>>
> > >>>>>>> On Thu, Nov 3, 2016 at 9:46 AM, Maxim Solodovnik <
> > >>>>>>> solomax...@gmail.com
> > >>>>>>> wrote:
> > >>>>>>>
> > >>>>>>> I was hoping to get answer like: in 7.x you should use .xxx
> > :)))
> > >>>>>>>
> > >>>>>>>> Going to create example on github and will send it for review :)
> > >>>>>>>>
> > >>>>>>>> On Thu, Nov 3, 2016 at 3:43 PM, Martin Grigorov <
> > >>>>>>>> mgrigo...@apache.org
> > >>>>>>>> wr

Re: WebSocket close is being called if AjaxDownloader is used

[Martin Grigorov]

Hi Maxim,

Please do!

Thank you!

On Nov 16, 2016 10:58 AM, "Maxim Solodovnik" <solomax...@gmail.com> wrote:

> I believe all comments are now addressed,
> Should I create PR to add AjaxDownload to wicket-extensions? both 7.x and
> 8.x?
>
> On Fri, Nov 11, 2016 at 6:11 PM, Sven Meier <s...@meiers.net> wrote:
>
> > +1 on putting it into wicket-extensions.
> >
> > Sven
> >
> >
> > Am 11.11.2016 um 10:54 schrieb Martin Grigorov:
> >
> >> One class + one .js might be too much for a new module but I don't want
> >> all
> >> the useless stuff in minis in my application too.
> >> I still prefer this to be in Wicket core.
> >>
> >> Martin Grigorov
> >> Wicket Training and Consulting
> >> https://twitter.com/mtgrigorov
> >>
> >> On Fri, Nov 11, 2016 at 10:28 AM, Sven Meier <s...@meiers.net> wrote:
> >>
> >> I don't think this warrants a new module - just add it to
> >>> wicketstuff-minis.
> >>>
> >>> Sven
> >>>
> >>>
> >>>
> >>> Am 11.11.2016 um 08:42 schrieb Martin Grigorov:
> >>>
> >>> Great work, Maxim!
> >>>>
> >>>> Let's move it to WicketStuff as a new module.
> >>>> I'd like to add -examples module with different use cases so we can
> see
> >>>> whether the iframes leak or not for example.
> >>>> Also I'd like to try to add events like beforeDownload/afterDownload
> so
> >>>> apps can show indicators that something is happening.
> >>>>
> >>>> Martin Grigorov
> >>>> Wicket Training and Consulting
> >>>> https://twitter.com/mtgrigorov
> >>>>
> >>>> On Wed, Nov 9, 2016 at 9:13 AM, Ernesto Reinaldo Barreiro <
> >>>> reier...@gmail.com> wrote:
> >>>>
> >>>> Thanks for sharing. I just added a couple of comments/
> >>>>
> >>>>> On Wed, Nov 9, 2016 at 4:23 AM, Maxim Solodovnik <
> solomax...@gmail.com
> >>>>> >
> >>>>> wrote:
> >>>>>
> >>>>> Hello Martin,
> >>>>>
> >>>>>> sorry for the delay
> >>>>>>
> >>>>>> here is the repo: https://github.com/solomax/wicket-ajax-download
> >>>>>> here is the commit with the ajax-download-via-iframe implementation:
> >>>>>> https://github.com/solomax/wicket-ajax-download/commit/
> >>>>>> 407936d6f506aa047d9a12a3ecb7aa6c866eb052
> >>>>>>
> >>>>>> Looking forward for your comments :)
> >>>>>>
> >>>>>> On Wed, Nov 9, 2016 at 5:02 AM, Martin Grigorov <
> mgrigo...@apache.org
> >>>>>> >
> >>>>>> wrote:
> >>>>>>
> >>>>>> Hi Maxim,
> >>>>>>>
> >>>>>>> Do you have progress on this ?
> >>>>>>>
> >>>>>>> Martin Grigorov
> >>>>>>> Wicket Training and Consulting
> >>>>>>> https://twitter.com/mtgrigorov
> >>>>>>>
> >>>>>>> On Thu, Nov 3, 2016 at 9:46 AM, Maxim Solodovnik <
> >>>>>>> solomax...@gmail.com
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>> I was hoping to get answer like: in 7.x you should use .xxx
> :)))
> >>>>>>>
> >>>>>>>> Going to create example on github and will send it for review :)
> >>>>>>>>
> >>>>>>>> On Thu, Nov 3, 2016 at 3:43 PM, Martin Grigorov <
> >>>>>>>> mgrigo...@apache.org
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> On Thu, Nov 3, 2016 at 9:40 AM, Maxim Solodovnik <
> >>>>>>>> solomax...@gmail.com>
> >>>>>>>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> It seems iframe is the only option :(((
> >>>>>>>>>
> >>>>>>>>>> Why so sad ?
> >>>>>>>>>>
> >>>>>>>>> iframe is a good option
> >>>>>>>>>
> >>>>>>>>>
> 

Re: WebSocket close is being called if AjaxDownloader is used

[Maxim Solodovnik]

I believe all comments are now addressed,
Should I create PR to add AjaxDownload to wicket-extensions? both 7.x and
8.x?

On Fri, Nov 11, 2016 at 6:11 PM, Sven Meier <s...@meiers.net> wrote:

> +1 on putting it into wicket-extensions.
>
> Sven
>
>
> Am 11.11.2016 um 10:54 schrieb Martin Grigorov:
>
>> One class + one .js might be too much for a new module but I don't want
>> all
>> the useless stuff in minis in my application too.
>> I still prefer this to be in Wicket core.
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Fri, Nov 11, 2016 at 10:28 AM, Sven Meier <s...@meiers.net> wrote:
>>
>> I don't think this warrants a new module - just add it to
>>> wicketstuff-minis.
>>>
>>> Sven
>>>
>>>
>>>
>>> Am 11.11.2016 um 08:42 schrieb Martin Grigorov:
>>>
>>> Great work, Maxim!
>>>>
>>>> Let's move it to WicketStuff as a new module.
>>>> I'd like to add -examples module with different use cases so we can see
>>>> whether the iframes leak or not for example.
>>>> Also I'd like to try to add events like beforeDownload/afterDownload so
>>>> apps can show indicators that something is happening.
>>>>
>>>> Martin Grigorov
>>>> Wicket Training and Consulting
>>>> https://twitter.com/mtgrigorov
>>>>
>>>> On Wed, Nov 9, 2016 at 9:13 AM, Ernesto Reinaldo Barreiro <
>>>> reier...@gmail.com> wrote:
>>>>
>>>> Thanks for sharing. I just added a couple of comments/
>>>>
>>>>> On Wed, Nov 9, 2016 at 4:23 AM, Maxim Solodovnik <solomax...@gmail.com
>>>>> >
>>>>> wrote:
>>>>>
>>>>> Hello Martin,
>>>>>
>>>>>> sorry for the delay
>>>>>>
>>>>>> here is the repo: https://github.com/solomax/wicket-ajax-download
>>>>>> here is the commit with the ajax-download-via-iframe implementation:
>>>>>> https://github.com/solomax/wicket-ajax-download/commit/
>>>>>> 407936d6f506aa047d9a12a3ecb7aa6c866eb052
>>>>>>
>>>>>> Looking forward for your comments :)
>>>>>>
>>>>>> On Wed, Nov 9, 2016 at 5:02 AM, Martin Grigorov <mgrigo...@apache.org
>>>>>> >
>>>>>> wrote:
>>>>>>
>>>>>> Hi Maxim,
>>>>>>>
>>>>>>> Do you have progress on this ?
>>>>>>>
>>>>>>> Martin Grigorov
>>>>>>> Wicket Training and Consulting
>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>
>>>>>>> On Thu, Nov 3, 2016 at 9:46 AM, Maxim Solodovnik <
>>>>>>> solomax...@gmail.com
>>>>>>> wrote:
>>>>>>>
>>>>>>> I was hoping to get answer like: in 7.x you should use .xxx :)))
>>>>>>>
>>>>>>>> Going to create example on github and will send it for review :)
>>>>>>>>
>>>>>>>> On Thu, Nov 3, 2016 at 3:43 PM, Martin Grigorov <
>>>>>>>> mgrigo...@apache.org
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On Thu, Nov 3, 2016 at 9:40 AM, Maxim Solodovnik <
>>>>>>>> solomax...@gmail.com>
>>>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> It seems iframe is the only option :(((
>>>>>>>>>
>>>>>>>>>> Why so sad ?
>>>>>>>>>>
>>>>>>>>> iframe is a good option
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> here is the JS plugin wrapping this idea:
>>>>>>>>>
>>>>>>>>>> http://johnculviner.com/jquery-file-download-plugin-
>>>>>>>>>> for-ajax-like-feature-rich-file-downloads/
>>>>>>>>>> going to perform additional search
>>>>>>>>>>
>>>>>>>>>> Thanks for the idea!
>>>>>>>>>>
>>>>>>>>>> On Thu, Nov 3, 2016 at 3:36 PM, Ernesto Reinaldo Barreiro <
>>>>>

Re: WebSocket close is being called if AjaxDownloader is used

[Sven Meier]

+1 on putting it into wicket-extensions.

Sven

Am 11.11.2016 um 10:54 schrieb Martin Grigorov:

One class + one .js might be too much for a new module but I don't want all
the useless stuff in minis in my application too.
I still prefer this to be in Wicket core.

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

On Fri, Nov 11, 2016 at 10:28 AM, Sven Meier <s...@meiers.net> wrote:


I don't think this warrants a new module - just add it to
wicketstuff-minis.

Sven



Am 11.11.2016 um 08:42 schrieb Martin Grigorov:


Great work, Maxim!

Let's move it to WicketStuff as a new module.
I'd like to add -examples module with different use cases so we can see
whether the iframes leak or not for example.
Also I'd like to try to add events like beforeDownload/afterDownload so
apps can show indicators that something is happening.

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

On Wed, Nov 9, 2016 at 9:13 AM, Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:

Thanks for sharing. I just added a couple of comments/

On Wed, Nov 9, 2016 at 4:23 AM, Maxim Solodovnik <solomax...@gmail.com>
wrote:

Hello Martin,

sorry for the delay

here is the repo: https://github.com/solomax/wicket-ajax-download
here is the commit with the ajax-download-via-iframe implementation:
https://github.com/solomax/wicket-ajax-download/commit/
407936d6f506aa047d9a12a3ecb7aa6c866eb052

Looking forward for your comments :)

On Wed, Nov 9, 2016 at 5:02 AM, Martin Grigorov <mgrigo...@apache.org>
wrote:


Hi Maxim,

Do you have progress on this ?

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

On Thu, Nov 3, 2016 at 9:46 AM, Maxim Solodovnik <solomax...@gmail.com
wrote:

I was hoping to get answer like: in 7.x you should use .xxx :)))

Going to create example on github and will send it for review :)

On Thu, Nov 3, 2016 at 3:43 PM, Martin Grigorov <mgrigo...@apache.org
wrote:

On Thu, Nov 3, 2016 at 9:40 AM, Maxim Solodovnik <
solomax...@gmail.com>

wrote:

It seems iframe is the only option :(((

Why so sad ?

iframe is a good option


here is the JS plugin wrapping this idea:

http://johnculviner.com/jquery-file-download-plugin-
for-ajax-like-feature-rich-file-downloads/
going to perform additional search

Thanks for the idea!

On Thu, Nov 3, 2016 at 3:36 PM, Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:

or maybe use a hidden iframe to trigger download...

On Thu, Nov 3, 2016 at 9:28 AM, Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:

I do not know if this is possible but

1- Open a new tab
2- Set location to download URL
3- Close the new tab

That way (maybe) page does not close WebSocket connection. It


would

still

be "AJAX"...


On Thu, Nov 3, 2016 at 9:04 AM, Maxim Solodovnik <


solomax...@gmail.com

wrote:

I'm afraid It would be not really Ajax .

On Thu, Nov 3, 2016 at 3:03 PM, Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:

maybe open a second browser tab and do the download
there...

On Thu, Nov 3, 2016 at 8:51 AM, Maxim Solodovnik <

solomax...@gmail.com>

wrote:

I'll try to create quick-start ASAP

On Thu, Nov 3, 2016 at 2:51 PM, Maxim Solodovnik <


solomax...@gmail.com>
wrote:

AjaxDownload was for wicket 1.5.x (or maybe 6.x)

maybe it can be enhanced to work without unload?

On Thu, Nov 3, 2016 at 2:46 PM, Sven Meier <


s...@meiers.net

wrote:

AjaxDownload changes the window location - the browser

probably

prepares

unloading of the page, before opening the attached

download

in

a


separate

window.

Sven



Am 03.11.2016 um 08:33 schrieb Martin Grigorov:

Hi Maxim,

I don't see any relation between those.
If it is easy to reproduce please create a


quickstart.

Martin Grigorov

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

On Thu, Nov 3, 2016 at 4:16 AM, Maxim Solodovnik <


solomax...@gmail.com

wrote:

Hello,


Recently we found weird behavior of AjaxDownloader


(similar

to

this

[1]

one)

For some reason at the moment download is initiated
WebSocketBehavior::onClose is being called 
What is the reason for this?


https://cwiki.apache.org/confluence/display/WICKET/
AJAX+update+and+file+download+in+one+blow

--
WBR
Maxim aka solomax


--

--

-

To unsubscribe, e-mail: users-unsubscribe@wicket.

apache.org

For additional commands, e-mail:

users-h...@wicket.apache.org
--
WBR
Maxim aka solomax



--
WBR
Maxim aka solomax



--
Regards - Ernesto Reinaldo Barreiro



--
WBR
Maxim aka solomax



--
Regards - Ernesto Reinaldo Barreiro



--
Regards - Ernesto Reinaldo Barreiro



--
WBR
Maxim aka solomax



--
WBR
Maxim aka solomax



--
WBR
Maxim aka solomax

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

Re: WebSocket close is being called if AjaxDownloader is used

[Maxim Solodovnik]

In this case it might be good idea to create "full" wicketstuff
project, then move it to core

On Fri, Nov 11, 2016 at 4:54 PM, Martin Grigorov <mgrigo...@apache.org> wrote:
> One class + one .js might be too much for a new module but I don't want all
> the useless stuff in minis in my application too.
> I still prefer this to be in Wicket core.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Fri, Nov 11, 2016 at 10:28 AM, Sven Meier <s...@meiers.net> wrote:
>
>> I don't think this warrants a new module - just add it to
>> wicketstuff-minis.
>>
>> Sven
>>
>>
>>
>> Am 11.11.2016 um 08:42 schrieb Martin Grigorov:
>>
>>> Great work, Maxim!
>>>
>>> Let's move it to WicketStuff as a new module.
>>> I'd like to add -examples module with different use cases so we can see
>>> whether the iframes leak or not for example.
>>> Also I'd like to try to add events like beforeDownload/afterDownload so
>>> apps can show indicators that something is happening.
>>>
>>> Martin Grigorov
>>> Wicket Training and Consulting
>>> https://twitter.com/mtgrigorov
>>>
>>> On Wed, Nov 9, 2016 at 9:13 AM, Ernesto Reinaldo Barreiro <
>>> reier...@gmail.com> wrote:
>>>
>>> Thanks for sharing. I just added a couple of comments/
>>>>
>>>> On Wed, Nov 9, 2016 at 4:23 AM, Maxim Solodovnik <solomax...@gmail.com>
>>>> wrote:
>>>>
>>>> Hello Martin,
>>>>>
>>>>> sorry for the delay
>>>>>
>>>>> here is the repo: https://github.com/solomax/wicket-ajax-download
>>>>> here is the commit with the ajax-download-via-iframe implementation:
>>>>> https://github.com/solomax/wicket-ajax-download/commit/
>>>>> 407936d6f506aa047d9a12a3ecb7aa6c866eb052
>>>>>
>>>>> Looking forward for your comments :)
>>>>>
>>>>> On Wed, Nov 9, 2016 at 5:02 AM, Martin Grigorov <mgrigo...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> Hi Maxim,
>>>>>>
>>>>>> Do you have progress on this ?
>>>>>>
>>>>>> Martin Grigorov
>>>>>> Wicket Training and Consulting
>>>>>> https://twitter.com/mtgrigorov
>>>>>>
>>>>>> On Thu, Nov 3, 2016 at 9:46 AM, Maxim Solodovnik <solomax...@gmail.com
>>>>>> wrote:
>>>>>>
>>>>>> I was hoping to get answer like: in 7.x you should use .xxx :)))
>>>>>>> Going to create example on github and will send it for review :)
>>>>>>>
>>>>>>> On Thu, Nov 3, 2016 at 3:43 PM, Martin Grigorov <mgrigo...@apache.org
>>>>>>> wrote:
>>>>>>>
>>>>>>> On Thu, Nov 3, 2016 at 9:40 AM, Maxim Solodovnik <
>>>>>>>>
>>>>>>> solomax...@gmail.com>
>>>>>
>>>>>> wrote:
>>>>>>>>
>>>>>>>> It seems iframe is the only option :(((
>>>>>>>>>
>>>>>>>>> Why so sad ?
>>>>>>>> iframe is a good option
>>>>>>>>
>>>>>>>>
>>>>>>>> here is the JS plugin wrapping this idea:
>>>>>>>>> http://johnculviner.com/jquery-file-download-plugin-
>>>>>>>>> for-ajax-like-feature-rich-file-downloads/
>>>>>>>>> going to perform additional search
>>>>>>>>>
>>>>>>>>> Thanks for the idea!
>>>>>>>>>
>>>>>>>>> On Thu, Nov 3, 2016 at 3:36 PM, Ernesto Reinaldo Barreiro <
>>>>>>>>> reier...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> or maybe use a hidden iframe to trigger download...
>>>>>>>>>>
>>>>>>>>>> On Thu, Nov 3, 2016 at 9:28 AM, Ernesto Reinaldo Barreiro <
>>>>>>>>>> reier...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> I do not know if this is possible but
>>>>>>>>>>>
>>>>>>>>>>> 1- Open a new tab
>>>>>>>>>>> 2- Set loc

Re: WebSocket close is being called if AjaxDownloader is used

[Martin Grigorov]

One class + one .js might be too much for a new module but I don't want all
the useless stuff in minis in my application too.
I still prefer this to be in Wicket core.

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

On Fri, Nov 11, 2016 at 10:28 AM, Sven Meier <s...@meiers.net> wrote:

> I don't think this warrants a new module - just add it to
> wicketstuff-minis.
>
> Sven
>
>
>
> Am 11.11.2016 um 08:42 schrieb Martin Grigorov:
>
>> Great work, Maxim!
>>
>> Let's move it to WicketStuff as a new module.
>> I'd like to add -examples module with different use cases so we can see
>> whether the iframes leak or not for example.
>> Also I'd like to try to add events like beforeDownload/afterDownload so
>> apps can show indicators that something is happening.
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Wed, Nov 9, 2016 at 9:13 AM, Ernesto Reinaldo Barreiro <
>> reier...@gmail.com> wrote:
>>
>> Thanks for sharing. I just added a couple of comments/
>>>
>>> On Wed, Nov 9, 2016 at 4:23 AM, Maxim Solodovnik <solomax...@gmail.com>
>>> wrote:
>>>
>>> Hello Martin,
>>>>
>>>> sorry for the delay
>>>>
>>>> here is the repo: https://github.com/solomax/wicket-ajax-download
>>>> here is the commit with the ajax-download-via-iframe implementation:
>>>> https://github.com/solomax/wicket-ajax-download/commit/
>>>> 407936d6f506aa047d9a12a3ecb7aa6c866eb052
>>>>
>>>> Looking forward for your comments :)
>>>>
>>>> On Wed, Nov 9, 2016 at 5:02 AM, Martin Grigorov <mgrigo...@apache.org>
>>>> wrote:
>>>>
>>>>> Hi Maxim,
>>>>>
>>>>> Do you have progress on this ?
>>>>>
>>>>> Martin Grigorov
>>>>> Wicket Training and Consulting
>>>>> https://twitter.com/mtgrigorov
>>>>>
>>>>> On Thu, Nov 3, 2016 at 9:46 AM, Maxim Solodovnik <solomax...@gmail.com
>>>>> wrote:
>>>>>
>>>>> I was hoping to get answer like: in 7.x you should use .xxx :)))
>>>>>> Going to create example on github and will send it for review :)
>>>>>>
>>>>>> On Thu, Nov 3, 2016 at 3:43 PM, Martin Grigorov <mgrigo...@apache.org
>>>>>> wrote:
>>>>>>
>>>>>> On Thu, Nov 3, 2016 at 9:40 AM, Maxim Solodovnik <
>>>>>>>
>>>>>> solomax...@gmail.com>
>>>>
>>>>> wrote:
>>>>>>>
>>>>>>> It seems iframe is the only option :(((
>>>>>>>>
>>>>>>>> Why so sad ?
>>>>>>> iframe is a good option
>>>>>>>
>>>>>>>
>>>>>>> here is the JS plugin wrapping this idea:
>>>>>>>> http://johnculviner.com/jquery-file-download-plugin-
>>>>>>>> for-ajax-like-feature-rich-file-downloads/
>>>>>>>> going to perform additional search
>>>>>>>>
>>>>>>>> Thanks for the idea!
>>>>>>>>
>>>>>>>> On Thu, Nov 3, 2016 at 3:36 PM, Ernesto Reinaldo Barreiro <
>>>>>>>> reier...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> or maybe use a hidden iframe to trigger download...
>>>>>>>>>
>>>>>>>>> On Thu, Nov 3, 2016 at 9:28 AM, Ernesto Reinaldo Barreiro <
>>>>>>>>> reier...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> I do not know if this is possible but
>>>>>>>>>>
>>>>>>>>>> 1- Open a new tab
>>>>>>>>>> 2- Set location to download URL
>>>>>>>>>> 3- Close the new tab
>>>>>>>>>>
>>>>>>>>>> That way (maybe) page does not close WebSocket connection. It
>>>>>>>>>>
>>>>>>>>> would
>>>>
>>>>> still
>>>>>>>>
>>>>>>>>> be "AJAX"...
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Nov 3, 2016 at 9:04 AM, Maxim Solod

Re: WebSocket close is being called if AjaxDownloader is used

[Maxim Solodovnik]

Ok, will try to do it in the beginning of next week
Thanks for the pointer

WBR, Maxim
(from mobile, sorry for the typos)

On Nov 11, 2016 16:28, "Sven Meier" <s...@meiers.net> wrote:

> I don't think this warrants a new module - just add it to
> wicketstuff-minis.
>
> Sven
>
>
> Am 11.11.2016 um 08:42 schrieb Martin Grigorov:
>
>> Great work, Maxim!
>>
>> Let's move it to WicketStuff as a new module.
>> I'd like to add -examples module with different use cases so we can see
>> whether the iframes leak or not for example.
>> Also I'd like to try to add events like beforeDownload/afterDownload so
>> apps can show indicators that something is happening.
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Wed, Nov 9, 2016 at 9:13 AM, Ernesto Reinaldo Barreiro <
>> reier...@gmail.com> wrote:
>>
>> Thanks for sharing. I just added a couple of comments/
>>>
>>> On Wed, Nov 9, 2016 at 4:23 AM, Maxim Solodovnik <solomax...@gmail.com>
>>> wrote:
>>>
>>> Hello Martin,
>>>>
>>>> sorry for the delay
>>>>
>>>> here is the repo: https://github.com/solomax/wicket-ajax-download
>>>> here is the commit with the ajax-download-via-iframe implementation:
>>>> https://github.com/solomax/wicket-ajax-download/commit/
>>>> 407936d6f506aa047d9a12a3ecb7aa6c866eb052
>>>>
>>>> Looking forward for your comments :)
>>>>
>>>> On Wed, Nov 9, 2016 at 5:02 AM, Martin Grigorov <mgrigo...@apache.org>
>>>> wrote:
>>>>
>>>>> Hi Maxim,
>>>>>
>>>>> Do you have progress on this ?
>>>>>
>>>>> Martin Grigorov
>>>>> Wicket Training and Consulting
>>>>> https://twitter.com/mtgrigorov
>>>>>
>>>>> On Thu, Nov 3, 2016 at 9:46 AM, Maxim Solodovnik <solomax...@gmail.com
>>>>> wrote:
>>>>>
>>>>> I was hoping to get answer like: in 7.x you should use .xxx :)))
>>>>>> Going to create example on github and will send it for review :)
>>>>>>
>>>>>> On Thu, Nov 3, 2016 at 3:43 PM, Martin Grigorov <mgrigo...@apache.org
>>>>>> wrote:
>>>>>>
>>>>>> On Thu, Nov 3, 2016 at 9:40 AM, Maxim Solodovnik <
>>>>>>>
>>>>>> solomax...@gmail.com>
>>>>
>>>>> wrote:
>>>>>>>
>>>>>>> It seems iframe is the only option :(((
>>>>>>>>
>>>>>>>> Why so sad ?
>>>>>>> iframe is a good option
>>>>>>>
>>>>>>>
>>>>>>> here is the JS plugin wrapping this idea:
>>>>>>>> http://johnculviner.com/jquery-file-download-plugin-
>>>>>>>> for-ajax-like-feature-rich-file-downloads/
>>>>>>>> going to perform additional search
>>>>>>>>
>>>>>>>> Thanks for the idea!
>>>>>>>>
>>>>>>>> On Thu, Nov 3, 2016 at 3:36 PM, Ernesto Reinaldo Barreiro <
>>>>>>>> reier...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> or maybe use a hidden iframe to trigger download...
>>>>>>>>>
>>>>>>>>> On Thu, Nov 3, 2016 at 9:28 AM, Ernesto Reinaldo Barreiro <
>>>>>>>>> reier...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> I do not know if this is possible but
>>>>>>>>>>
>>>>>>>>>> 1- Open a new tab
>>>>>>>>>> 2- Set location to download URL
>>>>>>>>>> 3- Close the new tab
>>>>>>>>>>
>>>>>>>>>> That way (maybe) page does not close WebSocket connection. It
>>>>>>>>>>
>>>>>>>>> would
>>>>
>>>>> still
>>>>>>>>
>>>>>>>>> be "AJAX"...
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Nov 3, 2016 at 9:04 AM, Maxim Solodovnik <
>>>>>>>>>>
>>>>>>>>> solomax...@gmail.com
>

Re: WebSocket close is being called if AjaxDownloader is used

[Sven Meier]

I don't think this warrants a new module - just add it to wicketstuff-minis.

Sven


Am 11.11.2016 um 08:42 schrieb Martin Grigorov:

Great work, Maxim!

Let's move it to WicketStuff as a new module.
I'd like to add -examples module with different use cases so we can see
whether the iframes leak or not for example.
Also I'd like to try to add events like beforeDownload/afterDownload so
apps can show indicators that something is happening.

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

On Wed, Nov 9, 2016 at 9:13 AM, Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:


Thanks for sharing. I just added a couple of comments/

On Wed, Nov 9, 2016 at 4:23 AM, Maxim Solodovnik <solomax...@gmail.com>
wrote:


Hello Martin,

sorry for the delay

here is the repo: https://github.com/solomax/wicket-ajax-download
here is the commit with the ajax-download-via-iframe implementation:
https://github.com/solomax/wicket-ajax-download/commit/
407936d6f506aa047d9a12a3ecb7aa6c866eb052

Looking forward for your comments :)

On Wed, Nov 9, 2016 at 5:02 AM, Martin Grigorov <mgrigo...@apache.org>
wrote:

Hi Maxim,

Do you have progress on this ?

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

On Thu, Nov 3, 2016 at 9:46 AM, Maxim Solodovnik <solomax...@gmail.com
wrote:


I was hoping to get answer like: in 7.x you should use .xxx :)))
Going to create example on github and will send it for review :)

On Thu, Nov 3, 2016 at 3:43 PM, Martin Grigorov <mgrigo...@apache.org
wrote:


On Thu, Nov 3, 2016 at 9:40 AM, Maxim Solodovnik <

solomax...@gmail.com>

wrote:


It seems iframe is the only option :(((


Why so sad ?
iframe is a good option



here is the JS plugin wrapping this idea:
http://johnculviner.com/jquery-file-download-plugin-
for-ajax-like-feature-rich-file-downloads/
going to perform additional search

Thanks for the idea!

On Thu, Nov 3, 2016 at 3:36 PM, Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:


or maybe use a hidden iframe to trigger download...

On Thu, Nov 3, 2016 at 9:28 AM, Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:


I do not know if this is possible but

1- Open a new tab
2- Set location to download URL
3- Close the new tab

That way (maybe) page does not close WebSocket connection. It

would

still

be "AJAX"...


On Thu, Nov 3, 2016 at 9:04 AM, Maxim Solodovnik <

solomax...@gmail.com

wrote:


I'm afraid It would be not really Ajax .

On Thu, Nov 3, 2016 at 3:03 PM, Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:


maybe open a second browser tab and do the download

there...

On Thu, Nov 3, 2016 at 8:51 AM, Maxim Solodovnik <

solomax...@gmail.com>

wrote:


I'll try to create quick-start ASAP

On Thu, Nov 3, 2016 at 2:51 PM, Maxim Solodovnik <

solomax...@gmail.com>

wrote:


AjaxDownload was for wicket 1.5.x (or maybe 6.x)
maybe it can be enhanced to work without unload?

On Thu, Nov 3, 2016 at 2:46 PM, Sven Meier <

s...@meiers.net

wrote:

AjaxDownload changes the window location - the browser

probably

prepares

unloading of the page, before opening the attached

download

in

a

separate

window.

Sven



Am 03.11.2016 um 08:33 schrieb Martin Grigorov:


Hi Maxim,

I don't see any relation between those.
If it is easy to reproduce please create a

quickstart.

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

On Thu, Nov 3, 2016 at 4:16 AM, Maxim Solodovnik <

solomax...@gmail.com

wrote:

Hello,

Recently we found weird behavior of AjaxDownloader

(similar

to

this

[1]

one)
For some reason at the moment download is initiated
WebSocketBehavior::onClose is being called 
What is the reason for this?


https://cwiki.apache.org/confluence/display/WICKET/
AJAX+update+and+file+download+in+one+blow

--
WBR
Maxim aka solomax



--

--

-

To unsubscribe, e-mail: users-unsubscribe@wicket.

apache.org

For additional commands, e-mail:

users-h...@wicket.apache.org




--
WBR
Maxim aka solomax




--
WBR
Maxim aka solomax




--
Regards - Ernesto Reinaldo Barreiro




--
WBR
Maxim aka solomax




--
Regards - Ernesto Reinaldo Barreiro




--
Regards - Ernesto Reinaldo Barreiro




--
WBR
Maxim aka solomax




--
WBR
Maxim aka solomax




--
WBR
Maxim aka solomax

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




--
Regards - Ernesto Reinaldo Barreiro




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

Re: WebSocket close is being called if AjaxDownloader is used

[Martin Grigorov]

Great work, Maxim!

Let's move it to WicketStuff as a new module.
I'd like to add -examples module with different use cases so we can see
whether the iframes leak or not for example.
Also I'd like to try to add events like beforeDownload/afterDownload so
apps can show indicators that something is happening.

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

On Wed, Nov 9, 2016 at 9:13 AM, Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:

> Thanks for sharing. I just added a couple of comments/
>
> On Wed, Nov 9, 2016 at 4:23 AM, Maxim Solodovnik <solomax...@gmail.com>
> wrote:
>
> > Hello Martin,
> >
> > sorry for the delay
> >
> > here is the repo: https://github.com/solomax/wicket-ajax-download
> > here is the commit with the ajax-download-via-iframe implementation:
> > https://github.com/solomax/wicket-ajax-download/commit/
> > 407936d6f506aa047d9a12a3ecb7aa6c866eb052
> >
> > Looking forward for your comments :)
> >
> > On Wed, Nov 9, 2016 at 5:02 AM, Martin Grigorov <mgrigo...@apache.org>
> > wrote:
> > > Hi Maxim,
> > >
> > > Do you have progress on this ?
> > >
> > > Martin Grigorov
> > > Wicket Training and Consulting
> > > https://twitter.com/mtgrigorov
> > >
> > > On Thu, Nov 3, 2016 at 9:46 AM, Maxim Solodovnik <solomax...@gmail.com
> >
> > > wrote:
> > >
> > >> I was hoping to get answer like: in 7.x you should use .xxx :)))
> > >> Going to create example on github and will send it for review :)
> > >>
> > >> On Thu, Nov 3, 2016 at 3:43 PM, Martin Grigorov <mgrigo...@apache.org
> >
> > >> wrote:
> > >>
> > >> > On Thu, Nov 3, 2016 at 9:40 AM, Maxim Solodovnik <
> > solomax...@gmail.com>
> > >> > wrote:
> > >> >
> > >> > > It seems iframe is the only option :(((
> > >> > >
> > >> >
> > >> > Why so sad ?
> > >> > iframe is a good option
> > >> >
> > >> >
> > >> > > here is the JS plugin wrapping this idea:
> > >> > > http://johnculviner.com/jquery-file-download-plugin-
> > >> > > for-ajax-like-feature-rich-file-downloads/
> > >> > > going to perform additional search
> > >> > >
> > >> > > Thanks for the idea!
> > >> > >
> > >> > > On Thu, Nov 3, 2016 at 3:36 PM, Ernesto Reinaldo Barreiro <
> > >> > > reier...@gmail.com> wrote:
> > >> > >
> > >> > > > or maybe use a hidden iframe to trigger download...
> > >> > > >
> > >> > > > On Thu, Nov 3, 2016 at 9:28 AM, Ernesto Reinaldo Barreiro <
> > >> > > > reier...@gmail.com> wrote:
> > >> > > >
> > >> > > > > I do not know if this is possible but
> > >> > > > >
> > >> > > > > 1- Open a new tab
> > >> > > > > 2- Set location to download URL
> > >> > > > > 3- Close the new tab
> > >> > > > >
> > >> > > > > That way (maybe) page does not close WebSocket connection. It
> > would
> > >> > > still
> > >> > > > > be "AJAX"...
> > >> > > > >
> > >> > > > >
> > >> > > > > On Thu, Nov 3, 2016 at 9:04 AM, Maxim Solodovnik <
> > >> > solomax...@gmail.com
> > >> > > >
> > >> > > > > wrote:
> > >> > > > >
> > >> > > > >> I'm afraid It would be not really Ajax .
> > >> > > > >>
> > >> > > > >> On Thu, Nov 3, 2016 at 3:03 PM, Ernesto Reinaldo Barreiro <
> > >> > > > >> reier...@gmail.com> wrote:
> > >> > > > >>
> > >> > > > >> > maybe open a second browser tab and do the download
> there...
> > >> > > > >> >
> > >> > > > >> > On Thu, Nov 3, 2016 at 8:51 AM, Maxim Solodovnik <
> > >> > > > solomax...@gmail.com>
> > >> > > > >> > wrote:
> > >> > > > >> >
> > >> > > > >> > > I'll try to create quick-start AS

Re: WebSocket close is being called if AjaxDownloader is used

[Ernesto Reinaldo Barreiro]

Thanks for sharing. I just added a couple of comments/

On Wed, Nov 9, 2016 at 4:23 AM, Maxim Solodovnik <solomax...@gmail.com>
wrote:

> Hello Martin,
>
> sorry for the delay
>
> here is the repo: https://github.com/solomax/wicket-ajax-download
> here is the commit with the ajax-download-via-iframe implementation:
> https://github.com/solomax/wicket-ajax-download/commit/
> 407936d6f506aa047d9a12a3ecb7aa6c866eb052
>
> Looking forward for your comments :)
>
> On Wed, Nov 9, 2016 at 5:02 AM, Martin Grigorov <mgrigo...@apache.org>
> wrote:
> > Hi Maxim,
> >
> > Do you have progress on this ?
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >
> > On Thu, Nov 3, 2016 at 9:46 AM, Maxim Solodovnik <solomax...@gmail.com>
> > wrote:
> >
> >> I was hoping to get answer like: in 7.x you should use .xxx :)))
> >> Going to create example on github and will send it for review :)
> >>
> >> On Thu, Nov 3, 2016 at 3:43 PM, Martin Grigorov <mgrigo...@apache.org>
> >> wrote:
> >>
> >> > On Thu, Nov 3, 2016 at 9:40 AM, Maxim Solodovnik <
> solomax...@gmail.com>
> >> > wrote:
> >> >
> >> > > It seems iframe is the only option :(((
> >> > >
> >> >
> >> > Why so sad ?
> >> > iframe is a good option
> >> >
> >> >
> >> > > here is the JS plugin wrapping this idea:
> >> > > http://johnculviner.com/jquery-file-download-plugin-
> >> > > for-ajax-like-feature-rich-file-downloads/
> >> > > going to perform additional search
> >> > >
> >> > > Thanks for the idea!
> >> > >
> >> > > On Thu, Nov 3, 2016 at 3:36 PM, Ernesto Reinaldo Barreiro <
> >> > > reier...@gmail.com> wrote:
> >> > >
> >> > > > or maybe use a hidden iframe to trigger download...
> >> > > >
> >> > > > On Thu, Nov 3, 2016 at 9:28 AM, Ernesto Reinaldo Barreiro <
> >> > > > reier...@gmail.com> wrote:
> >> > > >
> >> > > > > I do not know if this is possible but
> >> > > > >
> >> > > > > 1- Open a new tab
> >> > > > > 2- Set location to download URL
> >> > > > > 3- Close the new tab
> >> > > > >
> >> > > > > That way (maybe) page does not close WebSocket connection. It
> would
> >> > > still
> >> > > > > be "AJAX"...
> >> > > > >
> >> > > > >
> >> > > > > On Thu, Nov 3, 2016 at 9:04 AM, Maxim Solodovnik <
> >> > solomax...@gmail.com
> >> > > >
> >> > > > > wrote:
> >> > > > >
> >> > > > >> I'm afraid It would be not really Ajax .
> >> > > > >>
> >> > > > >> On Thu, Nov 3, 2016 at 3:03 PM, Ernesto Reinaldo Barreiro <
> >> > > > >> reier...@gmail.com> wrote:
> >> > > > >>
> >> > > > >> > maybe open a second browser tab and do the download there...
> >> > > > >> >
> >> > > > >> > On Thu, Nov 3, 2016 at 8:51 AM, Maxim Solodovnik <
> >> > > > solomax...@gmail.com>
> >> > > > >> > wrote:
> >> > > > >> >
> >> > > > >> > > I'll try to create quick-start ASAP
> >> > > > >> > >
> >> > > > >> > > On Thu, Nov 3, 2016 at 2:51 PM, Maxim Solodovnik <
> >> > > > >> solomax...@gmail.com>
> >> > > > >> > > wrote:
> >> > > > >> > >
> >> > > > >> > > > AjaxDownload was for wicket 1.5.x (or maybe 6.x)
> >> > > > >> > > > maybe it can be enhanced to work without unload?
> >> > > > >> > > >
> >> > > > >> > > > On Thu, Nov 3, 2016 at 2:46 PM, Sven Meier <
> s...@meiers.net
> >> >
> >> > > > wrote:
> >> > > > >> > > >
> >> > > > >> > > >> AjaxDownload changes the window location - the browser
> >> > probably
> >> > > > >> > prepare

Re: WebSocket close is being called if AjaxDownloader is used

[Maxim Solodovnik]

Hello Martin,

sorry for the delay

here is the repo: https://github.com/solomax/wicket-ajax-download
here is the commit with the ajax-download-via-iframe implementation:
https://github.com/solomax/wicket-ajax-download/commit/407936d6f506aa047d9a12a3ecb7aa6c866eb052

Looking forward for your comments :)

On Wed, Nov 9, 2016 at 5:02 AM, Martin Grigorov <mgrigo...@apache.org> wrote:
> Hi Maxim,
>
> Do you have progress on this ?
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Thu, Nov 3, 2016 at 9:46 AM, Maxim Solodovnik <solomax...@gmail.com>
> wrote:
>
>> I was hoping to get answer like: in 7.x you should use .xxx :)))
>> Going to create example on github and will send it for review :)
>>
>> On Thu, Nov 3, 2016 at 3:43 PM, Martin Grigorov <mgrigo...@apache.org>
>> wrote:
>>
>> > On Thu, Nov 3, 2016 at 9:40 AM, Maxim Solodovnik <solomax...@gmail.com>
>> > wrote:
>> >
>> > > It seems iframe is the only option :(((
>> > >
>> >
>> > Why so sad ?
>> > iframe is a good option
>> >
>> >
>> > > here is the JS plugin wrapping this idea:
>> > > http://johnculviner.com/jquery-file-download-plugin-
>> > > for-ajax-like-feature-rich-file-downloads/
>> > > going to perform additional search
>> > >
>> > > Thanks for the idea!
>> > >
>> > > On Thu, Nov 3, 2016 at 3:36 PM, Ernesto Reinaldo Barreiro <
>> > > reier...@gmail.com> wrote:
>> > >
>> > > > or maybe use a hidden iframe to trigger download...
>> > > >
>> > > > On Thu, Nov 3, 2016 at 9:28 AM, Ernesto Reinaldo Barreiro <
>> > > > reier...@gmail.com> wrote:
>> > > >
>> > > > > I do not know if this is possible but
>> > > > >
>> > > > > 1- Open a new tab
>> > > > > 2- Set location to download URL
>> > > > > 3- Close the new tab
>> > > > >
>> > > > > That way (maybe) page does not close WebSocket connection. It would
>> > > still
>> > > > > be "AJAX"...
>> > > > >
>> > > > >
>> > > > > On Thu, Nov 3, 2016 at 9:04 AM, Maxim Solodovnik <
>> > solomax...@gmail.com
>> > > >
>> > > > > wrote:
>> > > > >
>> > > > >> I'm afraid It would be not really Ajax .
>> > > > >>
>> > > > >> On Thu, Nov 3, 2016 at 3:03 PM, Ernesto Reinaldo Barreiro <
>> > > > >> reier...@gmail.com> wrote:
>> > > > >>
>> > > > >> > maybe open a second browser tab and do the download there...
>> > > > >> >
>> > > > >> > On Thu, Nov 3, 2016 at 8:51 AM, Maxim Solodovnik <
>> > > > solomax...@gmail.com>
>> > > > >> > wrote:
>> > > > >> >
>> > > > >> > > I'll try to create quick-start ASAP
>> > > > >> > >
>> > > > >> > > On Thu, Nov 3, 2016 at 2:51 PM, Maxim Solodovnik <
>> > > > >> solomax...@gmail.com>
>> > > > >> > > wrote:
>> > > > >> > >
>> > > > >> > > > AjaxDownload was for wicket 1.5.x (or maybe 6.x)
>> > > > >> > > > maybe it can be enhanced to work without unload?
>> > > > >> > > >
>> > > > >> > > > On Thu, Nov 3, 2016 at 2:46 PM, Sven Meier <s...@meiers.net
>> >
>> > > > wrote:
>> > > > >> > > >
>> > > > >> > > >> AjaxDownload changes the window location - the browser
>> > probably
>> > > > >> > prepares
>> > > > >> > > >> unloading of the page, before opening the attached download
>> > in
>> > > a
>> > > > >> > > separate
>> > > > >> > > >> window.
>> > > > >> > > >>
>> > > > >> > > >> Sven
>> > > > >> > > >>
>> > > > >> > > >>
>> > > > >> > > >>
>> > > > 

Re: WebSocket close is being called if AjaxDownloader is used

[Martin Grigorov]

Hi Maxim,

Do you have progress on this ?

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

On Thu, Nov 3, 2016 at 9:46 AM, Maxim Solodovnik <solomax...@gmail.com>
wrote:

> I was hoping to get answer like: in 7.x you should use .xxx :)))
> Going to create example on github and will send it for review :)
>
> On Thu, Nov 3, 2016 at 3:43 PM, Martin Grigorov <mgrigo...@apache.org>
> wrote:
>
> > On Thu, Nov 3, 2016 at 9:40 AM, Maxim Solodovnik <solomax...@gmail.com>
> > wrote:
> >
> > > It seems iframe is the only option :(((
> > >
> >
> > Why so sad ?
> > iframe is a good option
> >
> >
> > > here is the JS plugin wrapping this idea:
> > > http://johnculviner.com/jquery-file-download-plugin-
> > > for-ajax-like-feature-rich-file-downloads/
> > > going to perform additional search
> > >
> > > Thanks for the idea!
> > >
> > > On Thu, Nov 3, 2016 at 3:36 PM, Ernesto Reinaldo Barreiro <
> > > reier...@gmail.com> wrote:
> > >
> > > > or maybe use a hidden iframe to trigger download...
> > > >
> > > > On Thu, Nov 3, 2016 at 9:28 AM, Ernesto Reinaldo Barreiro <
> > > > reier...@gmail.com> wrote:
> > > >
> > > > > I do not know if this is possible but
> > > > >
> > > > > 1- Open a new tab
> > > > > 2- Set location to download URL
> > > > > 3- Close the new tab
> > > > >
> > > > > That way (maybe) page does not close WebSocket connection. It would
> > > still
> > > > > be "AJAX"...
> > > > >
> > > > >
> > > > > On Thu, Nov 3, 2016 at 9:04 AM, Maxim Solodovnik <
> > solomax...@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > >> I'm afraid It would be not really Ajax .
> > > > >>
> > > > >> On Thu, Nov 3, 2016 at 3:03 PM, Ernesto Reinaldo Barreiro <
> > > > >> reier...@gmail.com> wrote:
> > > > >>
> > > > >> > maybe open a second browser tab and do the download there...
> > > > >> >
> > > > >> > On Thu, Nov 3, 2016 at 8:51 AM, Maxim Solodovnik <
> > > > solomax...@gmail.com>
> > > > >> > wrote:
> > > > >> >
> > > > >> > > I'll try to create quick-start ASAP
> > > > >> > >
> > > > >> > > On Thu, Nov 3, 2016 at 2:51 PM, Maxim Solodovnik <
> > > > >> solomax...@gmail.com>
> > > > >> > > wrote:
> > > > >> > >
> > > > >> > > > AjaxDownload was for wicket 1.5.x (or maybe 6.x)
> > > > >> > > > maybe it can be enhanced to work without unload?
> > > > >> > > >
> > > > >> > > > On Thu, Nov 3, 2016 at 2:46 PM, Sven Meier <s...@meiers.net
> >
> > > > wrote:
> > > > >> > > >
> > > > >> > > >> AjaxDownload changes the window location - the browser
> > probably
> > > > >> > prepares
> > > > >> > > >> unloading of the page, before opening the attached download
> > in
> > > a
> > > > >> > > separate
> > > > >> > > >> window.
> > > > >> > > >>
> > > > >> > > >> Sven
> > > > >> > > >>
> > > > >> > > >>
> > > > >> > > >>
> > > > >> > > >> Am 03.11.2016 um 08:33 schrieb Martin Grigorov:
> > > > >> > > >>
> > > > >> > > >>> Hi Maxim,
> > > > >> > > >>>
> > > > >> > > >>> I don't see any relation between those.
> > > > >> > > >>> If it is easy to reproduce please create a quickstart.
> > > > >> > > >>>
> > > > >> > > >>> Martin Grigorov
> > > > >> > > >>> Wicket Training and Consulting
> > > > >> > > >>> https://twitter.com/mtgrigorov
> > > > >> > > >>>
> > > > >> > > >>> On Thu, Nov 3, 2016 at 4

Re: WebSocket close is being called if AjaxDownloader is used

[Ernesto Reinaldo Barreiro]

+1 for wicket-stuff

On Thu, Nov 3, 2016 at 9:50 AM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> On Thu, Nov 3, 2016 at 9:46 AM, Maxim Solodovnik <solomax...@gmail.com>
> wrote:
>
> > I was hoping to get answer like: in 7.x you should use .xxx :)))
> > Going to create example on github and will send it for review :)
> >
>
> Good! Thanks!
> I think we should add AjaxDownload class either to Wicket core or at least
> WicketStuff
> I've seen it being used in many projects
>
>
> >
> > On Thu, Nov 3, 2016 at 3:43 PM, Martin Grigorov <mgrigo...@apache.org>
> > wrote:
> >
> > > On Thu, Nov 3, 2016 at 9:40 AM, Maxim Solodovnik <solomax...@gmail.com
> >
> > > wrote:
> > >
> > > > It seems iframe is the only option :(((
> > > >
> > >
> > > Why so sad ?
> > > iframe is a good option
> > >
> > >
> > > > here is the JS plugin wrapping this idea:
> > > > http://johnculviner.com/jquery-file-download-plugin-
> > > > for-ajax-like-feature-rich-file-downloads/
> > > > going to perform additional search
> > > >
> > > > Thanks for the idea!
> > > >
> > > > On Thu, Nov 3, 2016 at 3:36 PM, Ernesto Reinaldo Barreiro <
> > > > reier...@gmail.com> wrote:
> > > >
> > > > > or maybe use a hidden iframe to trigger download...
> > > > >
> > > > > On Thu, Nov 3, 2016 at 9:28 AM, Ernesto Reinaldo Barreiro <
> > > > > reier...@gmail.com> wrote:
> > > > >
> > > > > > I do not know if this is possible but
> > > > > >
> > > > > > 1- Open a new tab
> > > > > > 2- Set location to download URL
> > > > > > 3- Close the new tab
> > > > > >
> > > > > > That way (maybe) page does not close WebSocket connection. It
> would
> > > > still
> > > > > > be "AJAX"...
> > > > > >
> > > > > >
> > > > > > On Thu, Nov 3, 2016 at 9:04 AM, Maxim Solodovnik <
> > > solomax...@gmail.com
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > >> I'm afraid It would be not really Ajax .
> > > > > >>
> > > > > >> On Thu, Nov 3, 2016 at 3:03 PM, Ernesto Reinaldo Barreiro <
> > > > > >> reier...@gmail.com> wrote:
> > > > > >>
> > > > > >> > maybe open a second browser tab and do the download there...
> > > > > >> >
> > > > > >> > On Thu, Nov 3, 2016 at 8:51 AM, Maxim Solodovnik <
> > > > > solomax...@gmail.com>
> > > > > >> > wrote:
> > > > > >> >
> > > > > >> > > I'll try to create quick-start ASAP
> > > > > >> > >
> > > > > >> > > On Thu, Nov 3, 2016 at 2:51 PM, Maxim Solodovnik <
> > > > > >> solomax...@gmail.com>
> > > > > >> > > wrote:
> > > > > >> > >
> > > > > >> > > > AjaxDownload was for wicket 1.5.x (or maybe 6.x)
> > > > > >> > > > maybe it can be enhanced to work without unload?
> > > > > >> > > >
> > > > > >> > > > On Thu, Nov 3, 2016 at 2:46 PM, Sven Meier <
> s...@meiers.net
> > >
> > > > > wrote:
> > > > > >> > > >
> > > > > >> > > >> AjaxDownload changes the window location - the browser
> > > probably
> > > > > >> > prepares
> > > > > >> > > >> unloading of the page, before opening the attached
> download
> > > in
> > > > a
> > > > > >> > > separate
> > > > > >> > > >> window.
> > > > > >> > > >>
> > > > > >> > > >> Sven
> > > > > >> > > >>
> > > > > >> > > >>
> > > > > >> > > >>
> > > > > >> > > >> Am 03.11.2016 um 08:33 schrieb Martin Grigorov:
> > > > > >> > > >>
> > > > > >> > > >>> Hi 

Re: WebSocket close is being called if AjaxDownloader is used

[Martin Grigorov]

On Thu, Nov 3, 2016 at 9:46 AM, Maxim Solodovnik <solomax...@gmail.com>
wrote:

> I was hoping to get answer like: in 7.x you should use .xxx :)))
> Going to create example on github and will send it for review :)
>

Good! Thanks!
I think we should add AjaxDownload class either to Wicket core or at least
WicketStuff
I've seen it being used in many projects


>
> On Thu, Nov 3, 2016 at 3:43 PM, Martin Grigorov <mgrigo...@apache.org>
> wrote:
>
> > On Thu, Nov 3, 2016 at 9:40 AM, Maxim Solodovnik <solomax...@gmail.com>
> > wrote:
> >
> > > It seems iframe is the only option :(((
> > >
> >
> > Why so sad ?
> > iframe is a good option
> >
> >
> > > here is the JS plugin wrapping this idea:
> > > http://johnculviner.com/jquery-file-download-plugin-
> > > for-ajax-like-feature-rich-file-downloads/
> > > going to perform additional search
> > >
> > > Thanks for the idea!
> > >
> > > On Thu, Nov 3, 2016 at 3:36 PM, Ernesto Reinaldo Barreiro <
> > > reier...@gmail.com> wrote:
> > >
> > > > or maybe use a hidden iframe to trigger download...
> > > >
> > > > On Thu, Nov 3, 2016 at 9:28 AM, Ernesto Reinaldo Barreiro <
> > > > reier...@gmail.com> wrote:
> > > >
> > > > > I do not know if this is possible but
> > > > >
> > > > > 1- Open a new tab
> > > > > 2- Set location to download URL
> > > > > 3- Close the new tab
> > > > >
> > > > > That way (maybe) page does not close WebSocket connection. It would
> > > still
> > > > > be "AJAX"...
> > > > >
> > > > >
> > > > > On Thu, Nov 3, 2016 at 9:04 AM, Maxim Solodovnik <
> > solomax...@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > >> I'm afraid It would be not really Ajax .
> > > > >>
> > > > >> On Thu, Nov 3, 2016 at 3:03 PM, Ernesto Reinaldo Barreiro <
> > > > >> reier...@gmail.com> wrote:
> > > > >>
> > > > >> > maybe open a second browser tab and do the download there...
> > > > >> >
> > > > >> > On Thu, Nov 3, 2016 at 8:51 AM, Maxim Solodovnik <
> > > > solomax...@gmail.com>
> > > > >> > wrote:
> > > > >> >
> > > > >> > > I'll try to create quick-start ASAP
> > > > >> > >
> > > > >> > > On Thu, Nov 3, 2016 at 2:51 PM, Maxim Solodovnik <
> > > > >> solomax...@gmail.com>
> > > > >> > > wrote:
> > > > >> > >
> > > > >> > > > AjaxDownload was for wicket 1.5.x (or maybe 6.x)
> > > > >> > > > maybe it can be enhanced to work without unload?
> > > > >> > > >
> > > > >> > > > On Thu, Nov 3, 2016 at 2:46 PM, Sven Meier <s...@meiers.net
> >
> > > > wrote:
> > > > >> > > >
> > > > >> > > >> AjaxDownload changes the window location - the browser
> > probably
> > > > >> > prepares
> > > > >> > > >> unloading of the page, before opening the attached download
> > in
> > > a
> > > > >> > > separate
> > > > >> > > >> window.
> > > > >> > > >>
> > > > >> > > >> Sven
> > > > >> > > >>
> > > > >> > > >>
> > > > >> > > >>
> > > > >> > > >> Am 03.11.2016 um 08:33 schrieb Martin Grigorov:
> > > > >> > > >>
> > > > >> > > >>> Hi Maxim,
> > > > >> > > >>>
> > > > >> > > >>> I don't see any relation between those.
> > > > >> > > >>> If it is easy to reproduce please create a quickstart.
> > > > >> > > >>>
> > > > >> > > >>> Martin Grigorov
> > > > >> > > >>> Wicket Training and Consulting
> > > > >> > > >>> https://twitter.com/mtgrigorov
> > > > >> > > >>>
> > > > >> > > >>> On Thu, Nov 

Re: WebSocket close is being called if AjaxDownloader is used

[Maxim Solodovnik]

I was hoping to get answer like: in 7.x you should use .xxx :)))
Going to create example on github and will send it for review :)

On Thu, Nov 3, 2016 at 3:43 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> On Thu, Nov 3, 2016 at 9:40 AM, Maxim Solodovnik <solomax...@gmail.com>
> wrote:
>
> > It seems iframe is the only option :(((
> >
>
> Why so sad ?
> iframe is a good option
>
>
> > here is the JS plugin wrapping this idea:
> > http://johnculviner.com/jquery-file-download-plugin-
> > for-ajax-like-feature-rich-file-downloads/
> > going to perform additional search
> >
> > Thanks for the idea!
> >
> > On Thu, Nov 3, 2016 at 3:36 PM, Ernesto Reinaldo Barreiro <
> > reier...@gmail.com> wrote:
> >
> > > or maybe use a hidden iframe to trigger download...
> > >
> > > On Thu, Nov 3, 2016 at 9:28 AM, Ernesto Reinaldo Barreiro <
> > > reier...@gmail.com> wrote:
> > >
> > > > I do not know if this is possible but
> > > >
> > > > 1- Open a new tab
> > > > 2- Set location to download URL
> > > > 3- Close the new tab
> > > >
> > > > That way (maybe) page does not close WebSocket connection. It would
> > still
> > > > be "AJAX"...
> > > >
> > > >
> > > > On Thu, Nov 3, 2016 at 9:04 AM, Maxim Solodovnik <
> solomax...@gmail.com
> > >
> > > > wrote:
> > > >
> > > >> I'm afraid It would be not really Ajax .
> > > >>
> > > >> On Thu, Nov 3, 2016 at 3:03 PM, Ernesto Reinaldo Barreiro <
> > > >> reier...@gmail.com> wrote:
> > > >>
> > > >> > maybe open a second browser tab and do the download there...
> > > >> >
> > > >> > On Thu, Nov 3, 2016 at 8:51 AM, Maxim Solodovnik <
> > > solomax...@gmail.com>
> > > >> > wrote:
> > > >> >
> > > >> > > I'll try to create quick-start ASAP
> > > >> > >
> > > >> > > On Thu, Nov 3, 2016 at 2:51 PM, Maxim Solodovnik <
> > > >> solomax...@gmail.com>
> > > >> > > wrote:
> > > >> > >
> > > >> > > > AjaxDownload was for wicket 1.5.x (or maybe 6.x)
> > > >> > > > maybe it can be enhanced to work without unload?
> > > >> > > >
> > > >> > > > On Thu, Nov 3, 2016 at 2:46 PM, Sven Meier <s...@meiers.net>
> > > wrote:
> > > >> > > >
> > > >> > > >> AjaxDownload changes the window location - the browser
> probably
> > > >> > prepares
> > > >> > > >> unloading of the page, before opening the attached download
> in
> > a
> > > >> > > separate
> > > >> > > >> window.
> > > >> > > >>
> > > >> > > >> Sven
> > > >> > > >>
> > > >> > > >>
> > > >> > > >>
> > > >> > > >> Am 03.11.2016 um 08:33 schrieb Martin Grigorov:
> > > >> > > >>
> > > >> > > >>> Hi Maxim,
> > > >> > > >>>
> > > >> > > >>> I don't see any relation between those.
> > > >> > > >>> If it is easy to reproduce please create a quickstart.
> > > >> > > >>>
> > > >> > > >>> Martin Grigorov
> > > >> > > >>> Wicket Training and Consulting
> > > >> > > >>> https://twitter.com/mtgrigorov
> > > >> > > >>>
> > > >> > > >>> On Thu, Nov 3, 2016 at 4:16 AM, Maxim Solodovnik <
> > > >> > solomax...@gmail.com
> > > >> > > >
> > > >> > > >>> wrote:
> > > >> > > >>>
> > > >> > > >>> Hello,
> > > >> > > >>>>
> > > >> > > >>>> Recently we found weird behavior of AjaxDownloader (similar
> > to
> > > >> this
> > > >> > > [1]
> > > >> > > >>>> one)
> > > >> > > >>>> For some reason at the moment download is initiated
> > > >> > > >>>> WebSocketBehavior::onClose is being called 
> > > >> > > >>>> What is the reason for this?
> > > >> > > >>>>
> > > >> > > >>>>
> > > >> > > >>>> https://cwiki.apache.org/confluence/display/WICKET/
> > > >> > > >>>> AJAX+update+and+file+download+in+one+blow
> > > >> > > >>>>
> > > >> > > >>>> --
> > > >> > > >>>> WBR
> > > >> > > >>>> Maxim aka solomax
> > > >> > > >>>>
> > > >> > > >>>>
> > > >> > > >>
> > > >> > > >> 
> > > >> -
> > > >> > > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > > >> > > >> For additional commands, e-mail:
> users-h...@wicket.apache.org
> > > >> > > >>
> > > >> > > >>
> > > >> > > >
> > > >> > > >
> > > >> > > > --
> > > >> > > > WBR
> > > >> > > > Maxim aka solomax
> > > >> > > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > --
> > > >> > > WBR
> > > >> > > Maxim aka solomax
> > > >> > >
> > > >> >
> > > >> >
> > > >> >
> > > >> > --
> > > >> > Regards - Ernesto Reinaldo Barreiro
> > > >> >
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> WBR
> > > >> Maxim aka solomax
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Regards - Ernesto Reinaldo Barreiro
> > > >
> > >
> > >
> > >
> > > --
> > > Regards - Ernesto Reinaldo Barreiro
> > >
> >
> >
> >
> > --
> > WBR
> > Maxim aka solomax
> >
>



-- 
WBR
Maxim aka solomax

Re: WebSocket close is being called if AjaxDownloader is used

[Martin Grigorov]

On Thu, Nov 3, 2016 at 9:40 AM, Maxim Solodovnik <solomax...@gmail.com>
wrote:

> It seems iframe is the only option :(((
>

Why so sad ?
iframe is a good option


> here is the JS plugin wrapping this idea:
> http://johnculviner.com/jquery-file-download-plugin-
> for-ajax-like-feature-rich-file-downloads/
> going to perform additional search
>
> Thanks for the idea!
>
> On Thu, Nov 3, 2016 at 3:36 PM, Ernesto Reinaldo Barreiro <
> reier...@gmail.com> wrote:
>
> > or maybe use a hidden iframe to trigger download...
> >
> > On Thu, Nov 3, 2016 at 9:28 AM, Ernesto Reinaldo Barreiro <
> > reier...@gmail.com> wrote:
> >
> > > I do not know if this is possible but
> > >
> > > 1- Open a new tab
> > > 2- Set location to download URL
> > > 3- Close the new tab
> > >
> > > That way (maybe) page does not close WebSocket connection. It would
> still
> > > be "AJAX"...
> > >
> > >
> > > On Thu, Nov 3, 2016 at 9:04 AM, Maxim Solodovnik <solomax...@gmail.com
> >
> > > wrote:
> > >
> > >> I'm afraid It would be not really Ajax .
> > >>
> > >> On Thu, Nov 3, 2016 at 3:03 PM, Ernesto Reinaldo Barreiro <
> > >> reier...@gmail.com> wrote:
> > >>
> > >> > maybe open a second browser tab and do the download there...
> > >> >
> > >> > On Thu, Nov 3, 2016 at 8:51 AM, Maxim Solodovnik <
> > solomax...@gmail.com>
> > >> > wrote:
> > >> >
> > >> > > I'll try to create quick-start ASAP
> > >> > >
> > >> > > On Thu, Nov 3, 2016 at 2:51 PM, Maxim Solodovnik <
> > >> solomax...@gmail.com>
> > >> > > wrote:
> > >> > >
> > >> > > > AjaxDownload was for wicket 1.5.x (or maybe 6.x)
> > >> > > > maybe it can be enhanced to work without unload?
> > >> > > >
> > >> > > > On Thu, Nov 3, 2016 at 2:46 PM, Sven Meier <s...@meiers.net>
> > wrote:
> > >> > > >
> > >> > > >> AjaxDownload changes the window location - the browser probably
> > >> > prepares
> > >> > > >> unloading of the page, before opening the attached download in
> a
> > >> > > separate
> > >> > > >> window.
> > >> > > >>
> > >> > > >> Sven
> > >> > > >>
> > >> > > >>
> > >> > > >>
> > >> > > >> Am 03.11.2016 um 08:33 schrieb Martin Grigorov:
> > >> > > >>
> > >> > > >>> Hi Maxim,
> > >> > > >>>
> > >> > > >>> I don't see any relation between those.
> > >> > > >>> If it is easy to reproduce please create a quickstart.
> > >> > > >>>
> > >> > > >>> Martin Grigorov
> > >> > > >>> Wicket Training and Consulting
> > >> > > >>> https://twitter.com/mtgrigorov
> > >> > > >>>
> > >> > > >>> On Thu, Nov 3, 2016 at 4:16 AM, Maxim Solodovnik <
> > >> > solomax...@gmail.com
> > >> > > >
> > >> > > >>> wrote:
> > >> > > >>>
> > >> > > >>> Hello,
> > >> > > >>>>
> > >> > > >>>> Recently we found weird behavior of AjaxDownloader (similar
> to
> > >> this
> > >> > > [1]
> > >> > > >>>> one)
> > >> > > >>>> For some reason at the moment download is initiated
> > >> > > >>>> WebSocketBehavior::onClose is being called 
> > >> > > >>>> What is the reason for this?
> > >> > > >>>>
> > >> > > >>>>
> > >> > > >>>> https://cwiki.apache.org/confluence/display/WICKET/
> > >> > > >>>> AJAX+update+and+file+download+in+one+blow
> > >> > > >>>>
> > >> > > >>>> --
> > >> > > >>>> WBR
> > >> > > >>>> Maxim aka solomax
> > >> > > >>>>
> > >> > > >>>>
> > >> > > >>
> > >> > > >> 
> > >> -
> > >> > > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > >> > > >> For additional commands, e-mail: users-h...@wicket.apache.org
> > >> > > >>
> > >> > > >>
> > >> > > >
> > >> > > >
> > >> > > > --
> > >> > > > WBR
> > >> > > > Maxim aka solomax
> > >> > > >
> > >> > >
> > >> > >
> > >> > >
> > >> > > --
> > >> > > WBR
> > >> > > Maxim aka solomax
> > >> > >
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Regards - Ernesto Reinaldo Barreiro
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> WBR
> > >> Maxim aka solomax
> > >>
> > >
> > >
> > >
> > > --
> > > Regards - Ernesto Reinaldo Barreiro
> > >
> >
> >
> >
> > --
> > Regards - Ernesto Reinaldo Barreiro
> >
>
>
>
> --
> WBR
> Maxim aka solomax
>

Re: WebSocket close is being called if AjaxDownloader is used

[Maxim Solodovnik]

It seems iframe is the only option :(((
here is the JS plugin wrapping this idea:
http://johnculviner.com/jquery-file-download-plugin-for-ajax-like-feature-rich-file-downloads/
going to perform additional search

Thanks for the idea!

On Thu, Nov 3, 2016 at 3:36 PM, Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:

> or maybe use a hidden iframe to trigger download...
>
> On Thu, Nov 3, 2016 at 9:28 AM, Ernesto Reinaldo Barreiro <
> reier...@gmail.com> wrote:
>
> > I do not know if this is possible but
> >
> > 1- Open a new tab
> > 2- Set location to download URL
> > 3- Close the new tab
> >
> > That way (maybe) page does not close WebSocket connection. It would still
> > be "AJAX"...
> >
> >
> > On Thu, Nov 3, 2016 at 9:04 AM, Maxim Solodovnik <solomax...@gmail.com>
> > wrote:
> >
> >> I'm afraid It would be not really Ajax .
> >>
> >> On Thu, Nov 3, 2016 at 3:03 PM, Ernesto Reinaldo Barreiro <
> >> reier...@gmail.com> wrote:
> >>
> >> > maybe open a second browser tab and do the download there...
> >> >
> >> > On Thu, Nov 3, 2016 at 8:51 AM, Maxim Solodovnik <
> solomax...@gmail.com>
> >> > wrote:
> >> >
> >> > > I'll try to create quick-start ASAP
> >> > >
> >> > > On Thu, Nov 3, 2016 at 2:51 PM, Maxim Solodovnik <
> >> solomax...@gmail.com>
> >> > > wrote:
> >> > >
> >> > > > AjaxDownload was for wicket 1.5.x (or maybe 6.x)
> >> > > > maybe it can be enhanced to work without unload?
> >> > > >
> >> > > > On Thu, Nov 3, 2016 at 2:46 PM, Sven Meier <s...@meiers.net>
> wrote:
> >> > > >
> >> > > >> AjaxDownload changes the window location - the browser probably
> >> > prepares
> >> > > >> unloading of the page, before opening the attached download in a
> >> > > separate
> >> > > >> window.
> >> > > >>
> >> > > >> Sven
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >> Am 03.11.2016 um 08:33 schrieb Martin Grigorov:
> >> > > >>
> >> > > >>> Hi Maxim,
> >> > > >>>
> >> > > >>> I don't see any relation between those.
> >> > > >>> If it is easy to reproduce please create a quickstart.
> >> > > >>>
> >> > > >>> Martin Grigorov
> >> > > >>> Wicket Training and Consulting
> >> > > >>> https://twitter.com/mtgrigorov
> >> > > >>>
> >> > > >>> On Thu, Nov 3, 2016 at 4:16 AM, Maxim Solodovnik <
> >> > solomax...@gmail.com
> >> > > >
> >> > > >>> wrote:
> >> > > >>>
> >> > > >>> Hello,
> >> > > >>>>
> >> > > >>>> Recently we found weird behavior of AjaxDownloader (similar to
> >> this
> >> > > [1]
> >> > > >>>> one)
> >> > > >>>> For some reason at the moment download is initiated
> >> > > >>>> WebSocketBehavior::onClose is being called 
> >> > > >>>> What is the reason for this?
> >> > > >>>>
> >> > > >>>>
> >> > > >>>> https://cwiki.apache.org/confluence/display/WICKET/
> >> > > >>>> AJAX+update+and+file+download+in+one+blow
> >> > > >>>>
> >> > > >>>> --
> >> > > >>>> WBR
> >> > > >>>> Maxim aka solomax
> >> > > >>>>
> >> > > >>>>
> >> > > >>
> >> > > >> 
> >> -
> >> > > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> > > >> For additional commands, e-mail: users-h...@wicket.apache.org
> >> > > >>
> >> > > >>
> >> > > >
> >> > > >
> >> > > > --
> >> > > > WBR
> >> > > > Maxim aka solomax
> >> > > >
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > WBR
> >> > > Maxim aka solomax
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Regards - Ernesto Reinaldo Barreiro
> >> >
> >>
> >>
> >>
> >> --
> >> WBR
> >> Maxim aka solomax
> >>
> >
> >
> >
> > --
> > Regards - Ernesto Reinaldo Barreiro
> >
>
>
>
> --
> Regards - Ernesto Reinaldo Barreiro
>



-- 
WBR
Maxim aka solomax

Re: WebSocket close is being called if AjaxDownloader is used

[Martin Grigorov]

On Thu, Nov 3, 2016 at 9:36 AM, Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:

> or maybe use a hidden iframe to trigger download...
>

this should be simpler
with the tabs some blocker may prevent it


>
> On Thu, Nov 3, 2016 at 9:28 AM, Ernesto Reinaldo Barreiro <
> reier...@gmail.com> wrote:
>
> > I do not know if this is possible but
> >
> > 1- Open a new tab
> > 2- Set location to download URL
> > 3- Close the new tab
> >
> > That way (maybe) page does not close WebSocket connection. It would still
> > be "AJAX"...
> >
> >
> > On Thu, Nov 3, 2016 at 9:04 AM, Maxim Solodovnik <solomax...@gmail.com>
> > wrote:
> >
> >> I'm afraid It would be not really Ajax .
> >>
> >> On Thu, Nov 3, 2016 at 3:03 PM, Ernesto Reinaldo Barreiro <
> >> reier...@gmail.com> wrote:
> >>
> >> > maybe open a second browser tab and do the download there...
> >> >
> >> > On Thu, Nov 3, 2016 at 8:51 AM, Maxim Solodovnik <
> solomax...@gmail.com>
> >> > wrote:
> >> >
> >> > > I'll try to create quick-start ASAP
> >> > >
> >> > > On Thu, Nov 3, 2016 at 2:51 PM, Maxim Solodovnik <
> >> solomax...@gmail.com>
> >> > > wrote:
> >> > >
> >> > > > AjaxDownload was for wicket 1.5.x (or maybe 6.x)
> >> > > > maybe it can be enhanced to work without unload?
> >> > > >
> >> > > > On Thu, Nov 3, 2016 at 2:46 PM, Sven Meier <s...@meiers.net>
> wrote:
> >> > > >
> >> > > >> AjaxDownload changes the window location - the browser probably
> >> > prepares
> >> > > >> unloading of the page, before opening the attached download in a
> >> > > separate
> >> > > >> window.
> >> > > >>
> >> > > >> Sven
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >> Am 03.11.2016 um 08:33 schrieb Martin Grigorov:
> >> > > >>
> >> > > >>> Hi Maxim,
> >> > > >>>
> >> > > >>> I don't see any relation between those.
> >> > > >>> If it is easy to reproduce please create a quickstart.
> >> > > >>>
> >> > > >>> Martin Grigorov
> >> > > >>> Wicket Training and Consulting
> >> > > >>> https://twitter.com/mtgrigorov
> >> > > >>>
> >> > > >>> On Thu, Nov 3, 2016 at 4:16 AM, Maxim Solodovnik <
> >> > solomax...@gmail.com
> >> > > >
> >> > > >>> wrote:
> >> > > >>>
> >> > > >>> Hello,
> >> > > >>>>
> >> > > >>>> Recently we found weird behavior of AjaxDownloader (similar to
> >> this
> >> > > [1]
> >> > > >>>> one)
> >> > > >>>> For some reason at the moment download is initiated
> >> > > >>>> WebSocketBehavior::onClose is being called 
> >> > > >>>> What is the reason for this?
> >> > > >>>>
> >> > > >>>>
> >> > > >>>> https://cwiki.apache.org/confluence/display/WICKET/
> >> > > >>>> AJAX+update+and+file+download+in+one+blow
> >> > > >>>>
> >> > > >>>> --
> >> > > >>>> WBR
> >> > > >>>> Maxim aka solomax
> >> > > >>>>
> >> > > >>>>
> >> > > >>
> >> > > >> 
> >> -
> >> > > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> > > >> For additional commands, e-mail: users-h...@wicket.apache.org
> >> > > >>
> >> > > >>
> >> > > >
> >> > > >
> >> > > > --
> >> > > > WBR
> >> > > > Maxim aka solomax
> >> > > >
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > WBR
> >> > > Maxim aka solomax
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Regards - Ernesto Reinaldo Barreiro
> >> >
> >>
> >>
> >>
> >> --
> >> WBR
> >> Maxim aka solomax
> >>
> >
> >
> >
> > --
> > Regards - Ernesto Reinaldo Barreiro
> >
>
>
>
> --
> Regards - Ernesto Reinaldo Barreiro
>

Re: WebSocket close is being called if AjaxDownloader is used

[Ernesto Reinaldo Barreiro]

or maybe use a hidden iframe to trigger download...

On Thu, Nov 3, 2016 at 9:28 AM, Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:

> I do not know if this is possible but
>
> 1- Open a new tab
> 2- Set location to download URL
> 3- Close the new tab
>
> That way (maybe) page does not close WebSocket connection. It would still
> be "AJAX"...
>
>
> On Thu, Nov 3, 2016 at 9:04 AM, Maxim Solodovnik <solomax...@gmail.com>
> wrote:
>
>> I'm afraid It would be not really Ajax .
>>
>> On Thu, Nov 3, 2016 at 3:03 PM, Ernesto Reinaldo Barreiro <
>> reier...@gmail.com> wrote:
>>
>> > maybe open a second browser tab and do the download there...
>> >
>> > On Thu, Nov 3, 2016 at 8:51 AM, Maxim Solodovnik <solomax...@gmail.com>
>> > wrote:
>> >
>> > > I'll try to create quick-start ASAP
>> > >
>> > > On Thu, Nov 3, 2016 at 2:51 PM, Maxim Solodovnik <
>> solomax...@gmail.com>
>> > > wrote:
>> > >
>> > > > AjaxDownload was for wicket 1.5.x (or maybe 6.x)
>> > > > maybe it can be enhanced to work without unload?
>> > > >
>> > > > On Thu, Nov 3, 2016 at 2:46 PM, Sven Meier <s...@meiers.net> wrote:
>> > > >
>> > > >> AjaxDownload changes the window location - the browser probably
>> > prepares
>> > > >> unloading of the page, before opening the attached download in a
>> > > separate
>> > > >> window.
>> > > >>
>> > > >> Sven
>> > > >>
>> > > >>
>> > > >>
>> > > >> Am 03.11.2016 um 08:33 schrieb Martin Grigorov:
>> > > >>
>> > > >>> Hi Maxim,
>> > > >>>
>> > > >>> I don't see any relation between those.
>> > > >>> If it is easy to reproduce please create a quickstart.
>> > > >>>
>> > > >>> Martin Grigorov
>> > > >>> Wicket Training and Consulting
>> > > >>> https://twitter.com/mtgrigorov
>> > > >>>
>> > > >>> On Thu, Nov 3, 2016 at 4:16 AM, Maxim Solodovnik <
>> > solomax...@gmail.com
>> > > >
>> > > >>> wrote:
>> > > >>>
>> > > >>> Hello,
>> > > >>>>
>> > > >>>> Recently we found weird behavior of AjaxDownloader (similar to
>> this
>> > > [1]
>> > > >>>> one)
>> > > >>>> For some reason at the moment download is initiated
>> > > >>>> WebSocketBehavior::onClose is being called 
>> > > >>>> What is the reason for this?
>> > > >>>>
>> > > >>>>
>> > > >>>> https://cwiki.apache.org/confluence/display/WICKET/
>> > > >>>> AJAX+update+and+file+download+in+one+blow
>> > > >>>>
>> > > >>>> --
>> > > >>>> WBR
>> > > >>>> Maxim aka solomax
>> > > >>>>
>> > > >>>>
>> > > >>
>> > > >> 
>> -
>> > > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> > > >> For additional commands, e-mail: users-h...@wicket.apache.org
>> > > >>
>> > > >>
>> > > >
>> > > >
>> > > > --
>> > > > WBR
>> > > > Maxim aka solomax
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > WBR
>> > > Maxim aka solomax
>> > >
>> >
>> >
>> >
>> > --
>> > Regards - Ernesto Reinaldo Barreiro
>> >
>>
>>
>>
>> --
>> WBR
>> Maxim aka solomax
>>
>
>
>
> --
> Regards - Ernesto Reinaldo Barreiro
>



-- 
Regards - Ernesto Reinaldo Barreiro

Re: WebSocket close is being called if AjaxDownloader is used

[Ernesto Reinaldo Barreiro]

I do not know if this is possible but

1- Open a new tab
2- Set location to download URL
3- Close the new tab

That way (maybe) page does not close WebSocket connection. It would still
be "AJAX"...


On Thu, Nov 3, 2016 at 9:04 AM, Maxim Solodovnik <solomax...@gmail.com>
wrote:

> I'm afraid It would be not really Ajax .
>
> On Thu, Nov 3, 2016 at 3:03 PM, Ernesto Reinaldo Barreiro <
> reier...@gmail.com> wrote:
>
> > maybe open a second browser tab and do the download there...
> >
> > On Thu, Nov 3, 2016 at 8:51 AM, Maxim Solodovnik <solomax...@gmail.com>
> > wrote:
> >
> > > I'll try to create quick-start ASAP
> > >
> > > On Thu, Nov 3, 2016 at 2:51 PM, Maxim Solodovnik <solomax...@gmail.com
> >
> > > wrote:
> > >
> > > > AjaxDownload was for wicket 1.5.x (or maybe 6.x)
> > > > maybe it can be enhanced to work without unload?
> > > >
> > > > On Thu, Nov 3, 2016 at 2:46 PM, Sven Meier <s...@meiers.net> wrote:
> > > >
> > > >> AjaxDownload changes the window location - the browser probably
> > prepares
> > > >> unloading of the page, before opening the attached download in a
> > > separate
> > > >> window.
> > > >>
> > > >> Sven
> > > >>
> > > >>
> > > >>
> > > >> Am 03.11.2016 um 08:33 schrieb Martin Grigorov:
> > > >>
> > > >>> Hi Maxim,
> > > >>>
> > > >>> I don't see any relation between those.
> > > >>> If it is easy to reproduce please create a quickstart.
> > > >>>
> > > >>> Martin Grigorov
> > > >>> Wicket Training and Consulting
> > > >>> https://twitter.com/mtgrigorov
> > > >>>
> > > >>> On Thu, Nov 3, 2016 at 4:16 AM, Maxim Solodovnik <
> > solomax...@gmail.com
> > > >
> > > >>> wrote:
> > > >>>
> > > >>> Hello,
> > > >>>>
> > > >>>> Recently we found weird behavior of AjaxDownloader (similar to
> this
> > > [1]
> > > >>>> one)
> > > >>>> For some reason at the moment download is initiated
> > > >>>> WebSocketBehavior::onClose is being called 
> > > >>>> What is the reason for this?
> > > >>>>
> > > >>>>
> > > >>>> https://cwiki.apache.org/confluence/display/WICKET/
> > > >>>> AJAX+update+and+file+download+in+one+blow
> > > >>>>
> > > >>>> --
> > > >>>> WBR
> > > >>>> Maxim aka solomax
> > > >>>>
> > > >>>>
> > > >>
> > > >> 
> -
> > > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > > >> For additional commands, e-mail: users-h...@wicket.apache.org
> > > >>
> > > >>
> > > >
> > > >
> > > > --
> > > > WBR
> > > > Maxim aka solomax
> > > >
> > >
> > >
> > >
> > > --
> > > WBR
> > > Maxim aka solomax
> > >
> >
> >
> >
> > --
> > Regards - Ernesto Reinaldo Barreiro
> >
>
>
>
> --
> WBR
> Maxim aka solomax
>



-- 
Regards - Ernesto Reinaldo Barreiro

Re: WebSocket close is being called if AjaxDownloader is used

[Maxim Solodovnik]

>> Maxim said: websocket.close() triggers the ajax download.
Nope, sorry for my English

I said
   For some reason at the moment download is initiated
   WebSocketBehavior::onClose is being called 

so user clicks "Download", and then, as the result WebSocket#onClose() is
being called
I would really like to work-around this

On Thu, Nov 3, 2016 at 3:04 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> On Thu, Nov 3, 2016 at 8:46 AM, Sven Meier <s...@meiers.net> wrote:
>
> > AjaxDownload changes the window location - the browser probably prepares
> > unloading of the page, before opening the attached download in a separate
> > window.
> >
>
> This could be the reason but it is the other way around of what Maxim
> explained in his first email.
>
> Maxim said: websocket.close() triggers the ajax download.
>
> Sven's explanation is valid when: the user click the download link, the
> browser does 'location.href=...', the browser triggers 'window.unload' and
> this leads to WebSocket.close() on the client side, the last triggers
> WebSocket#onClose() at the server side
>
>
> >
> > Sven
> >
> >
> >
> > Am 03.11.2016 um 08:33 schrieb Martin Grigorov:
> >
> >> Hi Maxim,
> >>
> >> I don't see any relation between those.
> >> If it is easy to reproduce please create a quickstart.
> >>
> >> Martin Grigorov
> >> Wicket Training and Consulting
> >> https://twitter.com/mtgrigorov
> >>
> >> On Thu, Nov 3, 2016 at 4:16 AM, Maxim Solodovnik <solomax...@gmail.com>
> >> wrote:
> >>
> >> Hello,
> >>>
> >>> Recently we found weird behavior of AjaxDownloader (similar to this [1]
> >>> one)
> >>> For some reason at the moment download is initiated
> >>> WebSocketBehavior::onClose is being called 
> >>> What is the reason for this?
> >>>
> >>>
> >>> https://cwiki.apache.org/confluence/display/WICKET/
> >>> AJAX+update+and+file+download+in+one+blow
> >>>
> >>> --
> >>> WBR
> >>> Maxim aka solomax
> >>>
> >>>
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
>



-- 
WBR
Maxim aka solomax

Re: WebSocket close is being called if AjaxDownloader is used

[Martin Grigorov]

On Thu, Nov 3, 2016 at 8:46 AM, Sven Meier <s...@meiers.net> wrote:

> AjaxDownload changes the window location - the browser probably prepares
> unloading of the page, before opening the attached download in a separate
> window.
>

This could be the reason but it is the other way around of what Maxim
explained in his first email.

Maxim said: websocket.close() triggers the ajax download.

Sven's explanation is valid when: the user click the download link, the
browser does 'location.href=...', the browser triggers 'window.unload' and
this leads to WebSocket.close() on the client side, the last triggers
WebSocket#onClose() at the server side


>
> Sven
>
>
>
> Am 03.11.2016 um 08:33 schrieb Martin Grigorov:
>
>> Hi Maxim,
>>
>> I don't see any relation between those.
>> If it is easy to reproduce please create a quickstart.
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Thu, Nov 3, 2016 at 4:16 AM, Maxim Solodovnik <solomax...@gmail.com>
>> wrote:
>>
>> Hello,
>>>
>>> Recently we found weird behavior of AjaxDownloader (similar to this [1]
>>> one)
>>> For some reason at the moment download is initiated
>>> WebSocketBehavior::onClose is being called 
>>> What is the reason for this?
>>>
>>>
>>> https://cwiki.apache.org/confluence/display/WICKET/
>>> AJAX+update+and+file+download+in+one+blow
>>>
>>> --
>>> WBR
>>> Maxim aka solomax
>>>
>>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: WebSocket close is being called if AjaxDownloader is used

[Maxim Solodovnik]

I'm afraid It would be not really Ajax .

On Thu, Nov 3, 2016 at 3:03 PM, Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:

> maybe open a second browser tab and do the download there...
>
> On Thu, Nov 3, 2016 at 8:51 AM, Maxim Solodovnik 
> wrote:
>
> > I'll try to create quick-start ASAP
> >
> > On Thu, Nov 3, 2016 at 2:51 PM, Maxim Solodovnik 
> > wrote:
> >
> > > AjaxDownload was for wicket 1.5.x (or maybe 6.x)
> > > maybe it can be enhanced to work without unload?
> > >
> > > On Thu, Nov 3, 2016 at 2:46 PM, Sven Meier  wrote:
> > >
> > >> AjaxDownload changes the window location - the browser probably
> prepares
> > >> unloading of the page, before opening the attached download in a
> > separate
> > >> window.
> > >>
> > >> Sven
> > >>
> > >>
> > >>
> > >> Am 03.11.2016 um 08:33 schrieb Martin Grigorov:
> > >>
> > >>> Hi Maxim,
> > >>>
> > >>> I don't see any relation between those.
> > >>> If it is easy to reproduce please create a quickstart.
> > >>>
> > >>> Martin Grigorov
> > >>> Wicket Training and Consulting
> > >>> https://twitter.com/mtgrigorov
> > >>>
> > >>> On Thu, Nov 3, 2016 at 4:16 AM, Maxim Solodovnik <
> solomax...@gmail.com
> > >
> > >>> wrote:
> > >>>
> > >>> Hello,
> > 
> >  Recently we found weird behavior of AjaxDownloader (similar to this
> > [1]
> >  one)
> >  For some reason at the moment download is initiated
> >  WebSocketBehavior::onClose is being called 
> >  What is the reason for this?
> > 
> > 
> >  https://cwiki.apache.org/confluence/display/WICKET/
> >  AJAX+update+and+file+download+in+one+blow
> > 
> >  --
> >  WBR
> >  Maxim aka solomax
> > 
> > 
> > >>
> > >> -
> > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > >> For additional commands, e-mail: users-h...@wicket.apache.org
> > >>
> > >>
> > >
> > >
> > > --
> > > WBR
> > > Maxim aka solomax
> > >
> >
> >
> >
> > --
> > WBR
> > Maxim aka solomax
> >
>
>
>
> --
> Regards - Ernesto Reinaldo Barreiro
>



-- 
WBR
Maxim aka solomax

Re: WebSocket close is being called if AjaxDownloader is used

[Ernesto Reinaldo Barreiro]

maybe open a second browser tab and do the download there...

On Thu, Nov 3, 2016 at 8:51 AM, Maxim Solodovnik 
wrote:

> I'll try to create quick-start ASAP
>
> On Thu, Nov 3, 2016 at 2:51 PM, Maxim Solodovnik 
> wrote:
>
> > AjaxDownload was for wicket 1.5.x (or maybe 6.x)
> > maybe it can be enhanced to work without unload?
> >
> > On Thu, Nov 3, 2016 at 2:46 PM, Sven Meier  wrote:
> >
> >> AjaxDownload changes the window location - the browser probably prepares
> >> unloading of the page, before opening the attached download in a
> separate
> >> window.
> >>
> >> Sven
> >>
> >>
> >>
> >> Am 03.11.2016 um 08:33 schrieb Martin Grigorov:
> >>
> >>> Hi Maxim,
> >>>
> >>> I don't see any relation between those.
> >>> If it is easy to reproduce please create a quickstart.
> >>>
> >>> Martin Grigorov
> >>> Wicket Training and Consulting
> >>> https://twitter.com/mtgrigorov
> >>>
> >>> On Thu, Nov 3, 2016 at 4:16 AM, Maxim Solodovnik  >
> >>> wrote:
> >>>
> >>> Hello,
> 
>  Recently we found weird behavior of AjaxDownloader (similar to this
> [1]
>  one)
>  For some reason at the moment download is initiated
>  WebSocketBehavior::onClose is being called 
>  What is the reason for this?
> 
> 
>  https://cwiki.apache.org/confluence/display/WICKET/
>  AJAX+update+and+file+download+in+one+blow
> 
>  --
>  WBR
>  Maxim aka solomax
> 
> 
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >>
> >>
> >
> >
> > --
> > WBR
> > Maxim aka solomax
> >
>
>
>
> --
> WBR
> Maxim aka solomax
>



-- 
Regards - Ernesto Reinaldo Barreiro

Re: WebSocket close is being called if AjaxDownloader is used

[Maxim Solodovnik]

I'll try to create quick-start ASAP

On Thu, Nov 3, 2016 at 2:51 PM, Maxim Solodovnik 
wrote:

> AjaxDownload was for wicket 1.5.x (or maybe 6.x)
> maybe it can be enhanced to work without unload?
>
> On Thu, Nov 3, 2016 at 2:46 PM, Sven Meier  wrote:
>
>> AjaxDownload changes the window location - the browser probably prepares
>> unloading of the page, before opening the attached download in a separate
>> window.
>>
>> Sven
>>
>>
>>
>> Am 03.11.2016 um 08:33 schrieb Martin Grigorov:
>>
>>> Hi Maxim,
>>>
>>> I don't see any relation between those.
>>> If it is easy to reproduce please create a quickstart.
>>>
>>> Martin Grigorov
>>> Wicket Training and Consulting
>>> https://twitter.com/mtgrigorov
>>>
>>> On Thu, Nov 3, 2016 at 4:16 AM, Maxim Solodovnik 
>>> wrote:
>>>
>>> Hello,

 Recently we found weird behavior of AjaxDownloader (similar to this [1]
 one)
 For some reason at the moment download is initiated
 WebSocketBehavior::onClose is being called 
 What is the reason for this?


 https://cwiki.apache.org/confluence/display/WICKET/
 AJAX+update+and+file+download+in+one+blow

 --
 WBR
 Maxim aka solomax


>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
>
> --
> WBR
> Maxim aka solomax
>



-- 
WBR
Maxim aka solomax

Re: WebSocket close is being called if AjaxDownloader is used

[Maxim Solodovnik]

AjaxDownload was for wicket 1.5.x (or maybe 6.x)
maybe it can be enhanced to work without unload?

On Thu, Nov 3, 2016 at 2:46 PM, Sven Meier  wrote:

> AjaxDownload changes the window location - the browser probably prepares
> unloading of the page, before opening the attached download in a separate
> window.
>
> Sven
>
>
>
> Am 03.11.2016 um 08:33 schrieb Martin Grigorov:
>
>> Hi Maxim,
>>
>> I don't see any relation between those.
>> If it is easy to reproduce please create a quickstart.
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Thu, Nov 3, 2016 at 4:16 AM, Maxim Solodovnik 
>> wrote:
>>
>> Hello,
>>>
>>> Recently we found weird behavior of AjaxDownloader (similar to this [1]
>>> one)
>>> For some reason at the moment download is initiated
>>> WebSocketBehavior::onClose is being called 
>>> What is the reason for this?
>>>
>>>
>>> https://cwiki.apache.org/confluence/display/WICKET/
>>> AJAX+update+and+file+download+in+one+blow
>>>
>>> --
>>> WBR
>>> Maxim aka solomax
>>>
>>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


-- 
WBR
Maxim aka solomax

Re: WebSocket close is being called if AjaxDownloader is used

[Sven Meier]

AjaxDownload changes the window location - the browser probably prepares 
unloading of the page, before opening the attached download in a separate 
window.

Sven


Am 03.11.2016 um 08:33 schrieb Martin Grigorov:

Hi Maxim,

I don't see any relation between those.
If it is easy to reproduce please create a quickstart.

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

On Thu, Nov 3, 2016 at 4:16 AM, Maxim Solodovnik 
wrote:


Hello,

Recently we found weird behavior of AjaxDownloader (similar to this [1]
one)
For some reason at the moment download is initiated
WebSocketBehavior::onClose is being called 
What is the reason for this?


https://cwiki.apache.org/confluence/display/WICKET/
AJAX+update+and+file+download+in+one+blow

--
WBR
Maxim aka solomax




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

Re: WebSocket close is being called if AjaxDownloader is used

[Martin Grigorov]

Hi Maxim,

I don't see any relation between those.
If it is easy to reproduce please create a quickstart.

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

On Thu, Nov 3, 2016 at 4:16 AM, Maxim Solodovnik 
wrote:

> Hello,
>
> Recently we found weird behavior of AjaxDownloader (similar to this [1]
> one)
> For some reason at the moment download is initiated
> WebSocketBehavior::onClose is being called 
> What is the reason for this?
>
>
> https://cwiki.apache.org/confluence/display/WICKET/
> AJAX+update+and+file+download+in+one+blow
>
> --
> WBR
> Maxim aka solomax
>

WebSocket close is being called if AjaxDownloader is used

[Maxim Solodovnik]

Hello,

Recently we found weird behavior of AjaxDownloader (similar to this [1] one)
For some reason at the moment download is initiated
WebSocketBehavior::onClose is being called 
What is the reason for this?


https://cwiki.apache.org/confluence/display/WICKET/AJAX+update+and+file+download+in+one+blow

-- 
WBR
Maxim aka solomax

Re: Websocket message from Spring bean

[Maxim Solodovnik]

Finally was able to test it :)
Everything works as expected! Thanks a lot for the hint!

On Tue, Oct 7, 2014 at 5:49 PM, Maxim Solodovnik <solomax...@gmail.com>
wrote:

> Thanks a lot for the tip Martin!
> will give it a try and write back :)
>
> On 7 October 2014 16:39, Martin Grigorov <mgrigo...@apache.org> wrote:
>
>> You use request and session scoped Spring beans in WebSocket request
>> because such requests are not processed by Servlet filters and Spring has
>> no chance to set its proxy objects as request/session attributes.
>>
>> But in Spring bean code you can do:
>> Application app = Application..get("myFilterName");
>> WebSocketSettings wsSettings = WebSocketSettings.Holder.get(app);
>> IWebSocketConnectionRegistry registry =
>> wsSettings.getConnectionRegistry();
>> WebSocketPushBroadcaster broadcaster = new
>> WebSocketPushBroadcaster(registry);
>> broadcaster
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Tue, Oct 7, 2014 at 11:31 AM, Maxim Solodovnik <solomax...@gmail.com>
>> wrote:
>>
>> > To be fair I haven't tried :(
>> > I thought I will have "no session/application bound to current thread"
>> > exceptions :(
>> > I'll test and let you know
>> >
>> > On 7 October 2014 15:21, Martin Grigorov <mgrigo...@apache.org> wrote:
>> >
>> > > Hi,
>> > >
>> > > I think it should work.
>> > > What kind of problems do you face ?
>> > >
>> > > Martin Grigorov
>> > > Wicket Training and Consulting
>> > > https://twitter.com/mtgrigorov
>> > >
>> > > On Fri, Oct 3, 2014 at 4:55 PM, Maxim Solodovnik <
>> solomax...@gmail.com>
>> > > wrote:
>> > >
>> > > > Hello All,
>> > > >
>> > > > I wonder is it possible to send IWebSocketPushMessage from Spring
>> bean?
>> > > (I
>> > > > can access Spring beans from wicket pages, now I need "backward
>> > > > compatibility")
>> > > >
>> > > > Thanks in advance for your help!
>> > > >
>> > > > --
>> > > > WBR
>> > > > Maxim aka solomax
>> > > >
>> > >
>> >
>> >
>> >
>> > --
>> > WBR
>> > Maxim aka solomax
>> >
>>
>
>
>
> --
> WBR
> Maxim aka solomax
>



-- 
WBR
Maxim aka solomax

Re: WebSocket Filter to open a Hibernate Session

[Marco Springer]

Hi Martin,

That's something I figured out as well, the bypassing of the Filters by 
WebSocket requests.

I did as you said and implemented a custom IRquestCycleListener to 
respond on the onBeginRequest & onEndRequest in case there is a 
WebSocketRequest.
This is working correctly now! Thanks for the pointer.

One other question though, since this seems awfully similar to how OSIV 
works.
If I do not filter on WebSocketRequest and allow the Session opening for 
each incoming request, in theory I should not need to apply the 
"OpenSessionInViewFilter" anymore correct?

But then another thing I noticed...
I set a debug point inside the onBeginRequest & onEndRequest to see 
what's is passing through those functions.
Apparently for a single page request the onBeginRequest & onEndRequest 
are called multiple times while I have no Lazy Loading components on that 
page.
My guess would be that those multiple requests are for the resources that 
needed to be loaded, e.g. images/js/css/whatever.
In that respect, it would absolutely not be wise to use that to open & close 
hibernate sessions ;-)

Upon a WebSocket event, the onBeginRequest & onEndRequest are called 
only once, so that's correct.

Again thanks.

Best Regards,
Marco Springer

On Tuesday 15 September 2015 18:06:51 Martin Grigorov wrote:
> Hi,
> 
> Servlet Filters are not used when sending messages in web socket
> connection. This is how Servlets work at the moment.
> 
> You can use Wicket's IRequestCycleListener's 
onBeginRequest/onEndRequest.
> 
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
> 
> On Tue, Sep 15, 2015 at 4:32 PM, Marco Springer <ma...@glitchbox.nl> 
wrote:
> > Hi,
> > 
> > Using normal requests and long-polling ajax timers to update an 
interface
> > works fine with hibernate sessions.
> > Now I'm trying to implement WebSockets to update small parts of a 
web
> > application that come from server side events. I want to get rid of the
> > long
> > polling.
> > 
> > For now I'm only using a @Scheduled annotation to broadcast an 
event to
> > all attached clients. As a simple scenario.
> > 
> > The web application should, in response, update with loading new 
data
> > from a database using Hibernate.
> > 
> > This is where it fails, giving the message:
> > /Caused by: org.hibernate.HibernateException: No Hibernate Session
> > bound to thread, and configuration does not allow creation of non-
> > transactional one here/
> > 
> > I know this fails due to the fact that WebSocket events don't go 
through
> > the normal filters, e.g. OpenSessionInViewFilter that I'm using.
> > 
> > 
> > *My question:*
> > Where can I create a hook where I can start the Hibernate Session 
the
> > same way the OpenSessionInViewFilter does?
> > 
> > If I'm totally off with my thoughts, I'd like to hear that too :)
> > 
> > Used libraries:
> > wicket 6.19.0
> > wicket-sprint 6.19.0
> > wicket-native-websocket-jetty9 6.19.0
> > hibernate 3.6.10-Final
> > springframework 3.2.13-RELEASE
> > (Why the old Hibernate/Spring versions: haven't had time to migrate 
yet,
> > too much to do!)
> > 
> > Thank you very much in advance.
> > 
> > Best regards,
> > Marco Springer

Re: WebSocket Filter to open a Hibernate Session

[Martin Grigorov]

Hi,

Servlet Filters are not used when sending messages in web socket
connection. This is how Servlets work at the moment.

You can use Wicket's IRequestCycleListener's onBeginRequest/onEndRequest.

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

On Tue, Sep 15, 2015 at 4:32 PM, Marco Springer <ma...@glitchbox.nl> wrote:

> Hi,
>
> Using normal requests and long-polling ajax timers to update an interface
> works fine with hibernate sessions.
> Now I'm trying to implement WebSockets to update small parts of a web
> application that come from server side events. I want to get rid of the
> long
> polling.
>
> For now I'm only using a @Scheduled annotation to broadcast an event to
> all attached clients. As a simple scenario.
>
> The web application should, in response, update with loading new data
> from a database using Hibernate.
>
> This is where it fails, giving the message:
> /Caused by: org.hibernate.HibernateException: No Hibernate Session
> bound to thread, and configuration does not allow creation of non-
> transactional one here/
>
> I know this fails due to the fact that WebSocket events don't go through
> the normal filters, e.g. OpenSessionInViewFilter that I'm using.
>
>
> *My question:*
> Where can I create a hook where I can start the Hibernate Session the
> same way the OpenSessionInViewFilter does?
>
> If I'm totally off with my thoughts, I'd like to hear that too :)
>
> Used libraries:
> wicket 6.19.0
> wicket-sprint 6.19.0
> wicket-native-websocket-jetty9 6.19.0
> hibernate 3.6.10-Final
> springframework 3.2.13-RELEASE
> (Why the old Hibernate/Spring versions: haven't had time to migrate yet,
> too much to do!)
>
> Thank you very much in advance.
>
> Best regards,
> Marco Springer
>
>
>

WebSocket Filter to open a Hibernate Session

[Marco Springer]

Hi,

Using normal requests and long-polling ajax timers to update an interface 
works fine with hibernate sessions.
Now I'm trying to implement WebSockets to update small parts of a web 
application that come from server side events. I want to get rid of the long 
polling.

For now I'm only using a @Scheduled annotation to broadcast an event to 
all attached clients. As a simple scenario.

The web application should, in response, update with loading new data 
from a database using Hibernate.

This is where it fails, giving the message:
/Caused by: org.hibernate.HibernateException: No Hibernate Session 
bound to thread, and configuration does not allow creation of non-
transactional one here/

I know this fails due to the fact that WebSocket events don't go through 
the normal filters, e.g. OpenSessionInViewFilter that I'm using.


*My question:*
Where can I create a hook where I can start the Hibernate Session the 
same way the OpenSessionInViewFilter does?

If I'm totally off with my thoughts, I'd like to hear that too :)

Used libraries:
wicket 6.19.0
wicket-sprint 6.19.0
wicket-native-websocket-jetty9 6.19.0
hibernate 3.6.10-Final
springframework 3.2.13-RELEASE
(Why the old Hibernate/Spring versions: haven't had time to migrate yet, 
too much to do!)

Thank you very much in advance.

Best regards,
Marco Springer

Re: Cross-Site Websocket Hijacking question

[Martin Grigorov]

Hi,

Please file a ticket at JIRA.
I think the check should be added
at 
org.apache.wicket.protocol.ws.api.AbstractWebSocketProcessor#AbstractWebSocketProcessor(HttpServletRequest,
WebApplication) so that it is available for all native integrations.
We can also add a setting in WebSocketSettings to switch the check off if
this is needed.

WebSocketBehavior#onConnect() is just a notification to the application
code that there is a connection.

Patch/Pull Request would be very welcome!

Thank you!


Martin Grigorov
Freelancer, available for hire!
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Wed, Mar 18, 2015 at 8:42 AM, Gergely Nagy foge...@gmail.com wrote:

 Hi fellow Wicketers,

 I have a question regarding CSWH. I was reading this article recently:

 http://www.notsosecure.com/blog/2014/11/27/how-cross-site-websocket-hijacking-could-lead-to-full-session-compromise/

 It made me wondering how can I implement my protection against this kind of
 attack? My tests show me that WebSocketBehavior is prone to this kind of
 attack simply out-of-the-box.

 I am using wicket-native-websocket-jetty9 version 7.0.0-M5.

 I was thinking about implementing a custom WebSocketBehavior and overriding
 the onConnect method, so I can get the Origin header and reject the
 connection request if it's not matching the originator host.

 But ConnectedMessage doesn't provide the headers. So does anybody have any
 suggestions how to implement this? Or maybe I miss the point and this
 should be implemented completely differently?

 Thank you,
 Gergely Nagy

Cross-Site Websocket Hijacking question

[Gergely Nagy]

Hi fellow Wicketers,

I have a question regarding CSWH. I was reading this article recently:
http://www.notsosecure.com/blog/2014/11/27/how-cross-site-websocket-hijacking-could-lead-to-full-session-compromise/

It made me wondering how can I implement my protection against this kind of
attack? My tests show me that WebSocketBehavior is prone to this kind of
attack simply out-of-the-box.

I am using wicket-native-websocket-jetty9 version 7.0.0-M5.

I was thinking about implementing a custom WebSocketBehavior and overriding
the onConnect method, so I can get the Origin header and reject the
connection request if it's not matching the originator host.

But ConnectedMessage doesn't provide the headers. So does anybody have any
suggestions how to implement this? Or maybe I miss the point and this
should be implemented completely differently?

Thank you,
Gergely Nagy

Re: JSR356 Websocket with Wicket 6.18

[Martin Grigorov]

Done.
https://github.com/wicketstuff/core/commit/bf312d35d6a3972b1bc625fca117e569daadcc65
It will be part of 6.19.0

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

On Wed, Jan 28, 2015 at 6:16 PM, Martin Grigorov mgrigo...@apache.org
wrote:

 Sorry but this won't be reusable for the community.
 I've suggested to put it in WicketStuff, not in Wicket.
 If I spend time to help you now then next week perhaps another user will
 ask the same. It doesn't scale :-/

 I'll put it in WicketStuff (
 https://github.com/wicketstuff/core/tree/wicket-6.x) when I have some
 time.

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

 On Wed, Jan 28, 2015 at 5:51 PM, Alexander Landsnes Keül 
 alexander.landsnes.k...@visma.com wrote:

 https://github.com/alexanderlk/wicket

 It's under the wicket-6.x branch, same exact structure as the one in
 7.0.0-M4

 Alex

 On Wed, Jan 28, 2015 at 4:25 PM, Martin Grigorov mgrigo...@apache.org
 wrote:

  url to your github repo ?
 
  Martin Grigorov
  Wicket Training and Consulting
  https://twitter.com/mtgrigorov
 
  On Wed, Jan 28, 2015 at 5:02 PM, Alexander Landsnes Keül 
  alexander.landsnes.k...@visma.com wrote:
 
   I forked Wicket to my github repo and took a look at it. Compiling
   wicket-native-websocket-javax with Java 6 and Wicket 6.19.0-SNAPSHOT
 was
  no
   problem at all, my problem popped up when I tried to get the embedded
  jetty
   server to run the test case. It fails with WebSocket connection to
  
  
 
 'ws://localhost:8080/wicket/websocket?pageId=6wicket-ajax-baseurl=behavior%3F6wicket-app-name=jsr356.websockets'
   failed: Error during WebSocket handshake: Unexpected response code:
 404
  
   Setting breakpoints in AbstractUpgradeFilter confirms that requests
 for
   css/html/js files get processed, but it never intercepts the WebSocket
   request and I'll be damned if I can figure out why. This is running
 with
   Jetty 9.2.2 (from Wicket 7.0.0-M4).
  
   I pretty much just copied the -javax project from master, switched to
 the
   wicket-6.x branch and copied it in. Then downgraded dependencies to
  Wicket
   6.19-SNAPSHOT and Java 6 and fixed the 4-5 compilation issues, so no
   witchcraft or wizardry has been attempted. If you do have a few
 pointers
   I'll be happy to see if I can manage to get it running, however
  WebSockets
   are hardly my forte.
  
   Alex
  
   On Tue, Jan 27, 2015 at 1:26 PM, Martin Grigorov 
 mgrigo...@apache.org
   wrote:
  
The needed changes to make -javax module working with Wicket 6.x are
  not
too big.
I think the easiest way to make it available for Wicket 6.x is to
 add
  (a
clone/copy of) the module to WicketStuff project. This way it could
 be
   part
of 6.19.0 too.
Is this something you are interested to help with ?
   
On Tue, Jan 27, 2015 at 2:11 PM, Alexander Landsnes Keül 
alexander.landsnes.k...@visma.com wrote:
   
 I checked out Wicket 6.18 and fiddled a bit with it, but it seems
  there
 are a few minor API breaks. One of the most pervasive ones is
 Application#setMetaData(...), in 6.18.0 it's a void function while
 7.0.0-M4
 returns this for chaining. I'm not sure JSR356 should be listed
 as an
 option for Wicket 6.x. It's certainly possible to fix it without
 too
   much
 effort, but since it changes a few signatures in wicket-core it
   requires
 all the projects checked out and modified. I don't have the time
 for
  it
 right now, and I do quite understand it if no one else feels like
spending
 the time either.

 Naming conventions are the spice of policies. Milestones are
 viewed
  as
 dangerously buggy and unstable, and hence unfit for the hallowed
  halls
   of
 shippable code. I may try to sneak it in nonetheless, since I do
 need
 websocket support and the stable release is weeks away.

 Alex

 -Original Message-
 From: Martin Grigorov [mailto:mgrigo...@apache.org]
 Sent: 27 January 2015 10:30
 To: users@wicket.apache.org
 Subject: Re: JSR356 Websocket with Wicket 6.18

 Hi,

 JSR356 API jar is built with Java 7. This is the main reason why
 this
 module is not part of Wicket 6.x.
 If this single method is the only problem to use
 wicket-native-websocket-javax:7.0.0-M4 with Wicket 6.18.0 then
 please
 create a ticket in JIRA and we will make it public for 6.20.0.

 I think 7.0.0-M5 (currently being in vote) is as stable as 6.19.0
  (also
in
 vote). There were no API breaks since 7.0.0-M4 and hopefully M5
 will
  be
 released as 7.0.0.Final in few weeks. We need your feedback now!
 It
  is
 mite annoying that most users don't want to even try it because
 of
 naming
 conventions :-/

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

 On Tue, Jan 27, 2015 at 11:08 AM, Alexander Landsnes Keül

Re: JSR356 Websocket with Wicket 6.18

[Alexander Landsnes Keül]

I forked Wicket to my github repo and took a look at it. Compiling
wicket-native-websocket-javax with Java 6 and Wicket 6.19.0-SNAPSHOT was no
problem at all, my problem popped up when I tried to get the embedded jetty
server to run the test case. It fails with WebSocket connection to
'ws://localhost:8080/wicket/websocket?pageId=6wicket-ajax-baseurl=behavior%3F6wicket-app-name=jsr356.websockets'
failed: Error during WebSocket handshake: Unexpected response code: 404

Setting breakpoints in AbstractUpgradeFilter confirms that requests for
css/html/js files get processed, but it never intercepts the WebSocket
request and I'll be damned if I can figure out why. This is running with
Jetty 9.2.2 (from Wicket 7.0.0-M4).

I pretty much just copied the -javax project from master, switched to the
wicket-6.x branch and copied it in. Then downgraded dependencies to Wicket
6.19-SNAPSHOT and Java 6 and fixed the 4-5 compilation issues, so no
witchcraft or wizardry has been attempted. If you do have a few pointers
I'll be happy to see if I can manage to get it running, however WebSockets
are hardly my forte.

Alex

On Tue, Jan 27, 2015 at 1:26 PM, Martin Grigorov mgrigo...@apache.org
wrote:

 The needed changes to make -javax module working with Wicket 6.x are not
 too big.
 I think the easiest way to make it available for Wicket 6.x is to add (a
 clone/copy of) the module to WicketStuff project. This way it could be part
 of 6.19.0 too.
 Is this something you are interested to help with ?

 On Tue, Jan 27, 2015 at 2:11 PM, Alexander Landsnes Keül 
 alexander.landsnes.k...@visma.com wrote:

  I checked out Wicket 6.18 and fiddled a bit with it, but it seems there
  are a few minor API breaks. One of the most pervasive ones is
  Application#setMetaData(...), in 6.18.0 it's a void function while
  7.0.0-M4
  returns this for chaining. I'm not sure JSR356 should be listed as an
  option for Wicket 6.x. It's certainly possible to fix it without too much
  effort, but since it changes a few signatures in wicket-core it requires
  all the projects checked out and modified. I don't have the time for it
  right now, and I do quite understand it if no one else feels like
 spending
  the time either.
 
  Naming conventions are the spice of policies. Milestones are viewed as
  dangerously buggy and unstable, and hence unfit for the hallowed halls of
  shippable code. I may try to sneak it in nonetheless, since I do need
  websocket support and the stable release is weeks away.
 
  Alex
 
  -Original Message-
  From: Martin Grigorov [mailto:mgrigo...@apache.org]
  Sent: 27 January 2015 10:30
  To: users@wicket.apache.org
  Subject: Re: JSR356 Websocket with Wicket 6.18
 
  Hi,
 
  JSR356 API jar is built with Java 7. This is the main reason why this
  module is not part of Wicket 6.x.
  If this single method is the only problem to use
  wicket-native-websocket-javax:7.0.0-M4 with Wicket 6.18.0 then please
  create a ticket in JIRA and we will make it public for 6.20.0.
 
  I think 7.0.0-M5 (currently being in vote) is as stable as 6.19.0 (also
 in
  vote). There were no API breaks since 7.0.0-M4 and hopefully M5 will be
  released as 7.0.0.Final in few weeks. We need your feedback now! It is
  mite annoying that most users don't want to even try it because of
  naming
  conventions :-/
 
  Martin Grigorov
  Wicket Training and Consulting
  https://twitter.com/mtgrigorov
 
  On Tue, Jan 27, 2015 at 11:08 AM, Alexander Landsnes Keül 
  alexander.landsnes.k...@visma.com wrote:
 
   Reading the documentation I was under the impression that
   wicket-native-websocket-javax could be used along with Wicket 6.X,
   however that seems to not be the case.
  
   In the constructor of
   org.apache.wicket.protocol.ws.api.AbstractWebSocketProcessor
   line 120 (7.0.0-M4) it accesses WicketFilter#getFilterPath(), which is
   public in Wicket 7 but private in Wicket 6.X.
  
   Is there a way to sort this, or do I simply have to wait until Wicket
   7 is finalized? Upgrading while it's a milestone release isn't an
   option, sadly, but on the other hand we just upgraded to Tomcat 8 and
   not having a functional websocket implementation is a mite annoying.
  
   Alex
  
 

Re: JSR356 Websocket with Wicket 6.18

[Alexander Landsnes Keül]

https://github.com/alexanderlk/wicket

It's under the wicket-6.x branch, same exact structure as the one in
7.0.0-M4

Alex

On Wed, Jan 28, 2015 at 4:25 PM, Martin Grigorov mgrigo...@apache.org
wrote:

 url to your github repo ?

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

 On Wed, Jan 28, 2015 at 5:02 PM, Alexander Landsnes Keül 
 alexander.landsnes.k...@visma.com wrote:

  I forked Wicket to my github repo and took a look at it. Compiling
  wicket-native-websocket-javax with Java 6 and Wicket 6.19.0-SNAPSHOT was
 no
  problem at all, my problem popped up when I tried to get the embedded
 jetty
  server to run the test case. It fails with WebSocket connection to
 
 
 'ws://localhost:8080/wicket/websocket?pageId=6wicket-ajax-baseurl=behavior%3F6wicket-app-name=jsr356.websockets'
  failed: Error during WebSocket handshake: Unexpected response code: 404
 
  Setting breakpoints in AbstractUpgradeFilter confirms that requests for
  css/html/js files get processed, but it never intercepts the WebSocket
  request and I'll be damned if I can figure out why. This is running with
  Jetty 9.2.2 (from Wicket 7.0.0-M4).
 
  I pretty much just copied the -javax project from master, switched to the
  wicket-6.x branch and copied it in. Then downgraded dependencies to
 Wicket
  6.19-SNAPSHOT and Java 6 and fixed the 4-5 compilation issues, so no
  witchcraft or wizardry has been attempted. If you do have a few pointers
  I'll be happy to see if I can manage to get it running, however
 WebSockets
  are hardly my forte.
 
  Alex
 
  On Tue, Jan 27, 2015 at 1:26 PM, Martin Grigorov mgrigo...@apache.org
  wrote:
 
   The needed changes to make -javax module working with Wicket 6.x are
 not
   too big.
   I think the easiest way to make it available for Wicket 6.x is to add
 (a
   clone/copy of) the module to WicketStuff project. This way it could be
  part
   of 6.19.0 too.
   Is this something you are interested to help with ?
  
   On Tue, Jan 27, 2015 at 2:11 PM, Alexander Landsnes Keül 
   alexander.landsnes.k...@visma.com wrote:
  
I checked out Wicket 6.18 and fiddled a bit with it, but it seems
 there
are a few minor API breaks. One of the most pervasive ones is
Application#setMetaData(...), in 6.18.0 it's a void function while
7.0.0-M4
returns this for chaining. I'm not sure JSR356 should be listed as an
option for Wicket 6.x. It's certainly possible to fix it without too
  much
effort, but since it changes a few signatures in wicket-core it
  requires
all the projects checked out and modified. I don't have the time for
 it
right now, and I do quite understand it if no one else feels like
   spending
the time either.
   
Naming conventions are the spice of policies. Milestones are viewed
 as
dangerously buggy and unstable, and hence unfit for the hallowed
 halls
  of
shippable code. I may try to sneak it in nonetheless, since I do need
websocket support and the stable release is weeks away.
   
Alex
   
-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org]
Sent: 27 January 2015 10:30
To: users@wicket.apache.org
Subject: Re: JSR356 Websocket with Wicket 6.18
   
Hi,
   
JSR356 API jar is built with Java 7. This is the main reason why this
module is not part of Wicket 6.x.
If this single method is the only problem to use
wicket-native-websocket-javax:7.0.0-M4 with Wicket 6.18.0 then please
create a ticket in JIRA and we will make it public for 6.20.0.
   
I think 7.0.0-M5 (currently being in vote) is as stable as 6.19.0
 (also
   in
vote). There were no API breaks since 7.0.0-M4 and hopefully M5 will
 be
released as 7.0.0.Final in few weeks. We need your feedback now! It
 is
mite annoying that most users don't want to even try it because of
naming
conventions :-/
   
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
   
On Tue, Jan 27, 2015 at 11:08 AM, Alexander Landsnes Keül 
alexander.landsnes.k...@visma.com wrote:
   
 Reading the documentation I was under the impression that
 wicket-native-websocket-javax could be used along with Wicket 6.X,
 however that seems to not be the case.

 In the constructor of
 org.apache.wicket.protocol.ws.api.AbstractWebSocketProcessor
 line 120 (7.0.0-M4) it accesses WicketFilter#getFilterPath(), which
  is
 public in Wicket 7 but private in Wicket 6.X.

 Is there a way to sort this, or do I simply have to wait until
 Wicket
 7 is finalized? Upgrading while it's a milestone release isn't an
 option, sadly, but on the other hand we just upgraded to Tomcat 8
 and
 not having a functional websocket implementation is a mite
 annoying.

 Alex

   
  
 

Re: JSR356 Websocket with Wicket 6.18

[Martin Grigorov]

url to your github repo ?

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

On Wed, Jan 28, 2015 at 5:02 PM, Alexander Landsnes Keül 
alexander.landsnes.k...@visma.com wrote:

 I forked Wicket to my github repo and took a look at it. Compiling
 wicket-native-websocket-javax with Java 6 and Wicket 6.19.0-SNAPSHOT was no
 problem at all, my problem popped up when I tried to get the embedded jetty
 server to run the test case. It fails with WebSocket connection to

 'ws://localhost:8080/wicket/websocket?pageId=6wicket-ajax-baseurl=behavior%3F6wicket-app-name=jsr356.websockets'
 failed: Error during WebSocket handshake: Unexpected response code: 404

 Setting breakpoints in AbstractUpgradeFilter confirms that requests for
 css/html/js files get processed, but it never intercepts the WebSocket
 request and I'll be damned if I can figure out why. This is running with
 Jetty 9.2.2 (from Wicket 7.0.0-M4).

 I pretty much just copied the -javax project from master, switched to the
 wicket-6.x branch and copied it in. Then downgraded dependencies to Wicket
 6.19-SNAPSHOT and Java 6 and fixed the 4-5 compilation issues, so no
 witchcraft or wizardry has been attempted. If you do have a few pointers
 I'll be happy to see if I can manage to get it running, however WebSockets
 are hardly my forte.

 Alex

 On Tue, Jan 27, 2015 at 1:26 PM, Martin Grigorov mgrigo...@apache.org
 wrote:

  The needed changes to make -javax module working with Wicket 6.x are not
  too big.
  I think the easiest way to make it available for Wicket 6.x is to add (a
  clone/copy of) the module to WicketStuff project. This way it could be
 part
  of 6.19.0 too.
  Is this something you are interested to help with ?
 
  On Tue, Jan 27, 2015 at 2:11 PM, Alexander Landsnes Keül 
  alexander.landsnes.k...@visma.com wrote:
 
   I checked out Wicket 6.18 and fiddled a bit with it, but it seems there
   are a few minor API breaks. One of the most pervasive ones is
   Application#setMetaData(...), in 6.18.0 it's a void function while
   7.0.0-M4
   returns this for chaining. I'm not sure JSR356 should be listed as an
   option for Wicket 6.x. It's certainly possible to fix it without too
 much
   effort, but since it changes a few signatures in wicket-core it
 requires
   all the projects checked out and modified. I don't have the time for it
   right now, and I do quite understand it if no one else feels like
  spending
   the time either.
  
   Naming conventions are the spice of policies. Milestones are viewed as
   dangerously buggy and unstable, and hence unfit for the hallowed halls
 of
   shippable code. I may try to sneak it in nonetheless, since I do need
   websocket support and the stable release is weeks away.
  
   Alex
  
   -Original Message-
   From: Martin Grigorov [mailto:mgrigo...@apache.org]
   Sent: 27 January 2015 10:30
   To: users@wicket.apache.org
   Subject: Re: JSR356 Websocket with Wicket 6.18
  
   Hi,
  
   JSR356 API jar is built with Java 7. This is the main reason why this
   module is not part of Wicket 6.x.
   If this single method is the only problem to use
   wicket-native-websocket-javax:7.0.0-M4 with Wicket 6.18.0 then please
   create a ticket in JIRA and we will make it public for 6.20.0.
  
   I think 7.0.0-M5 (currently being in vote) is as stable as 6.19.0 (also
  in
   vote). There were no API breaks since 7.0.0-M4 and hopefully M5 will be
   released as 7.0.0.Final in few weeks. We need your feedback now! It is
   mite annoying that most users don't want to even try it because of
   naming
   conventions :-/
  
   Martin Grigorov
   Wicket Training and Consulting
   https://twitter.com/mtgrigorov
  
   On Tue, Jan 27, 2015 at 11:08 AM, Alexander Landsnes Keül 
   alexander.landsnes.k...@visma.com wrote:
  
Reading the documentation I was under the impression that
wicket-native-websocket-javax could be used along with Wicket 6.X,
however that seems to not be the case.
   
In the constructor of
org.apache.wicket.protocol.ws.api.AbstractWebSocketProcessor
line 120 (7.0.0-M4) it accesses WicketFilter#getFilterPath(), which
 is
public in Wicket 7 but private in Wicket 6.X.
   
Is there a way to sort this, or do I simply have to wait until Wicket
7 is finalized? Upgrading while it's a milestone release isn't an
option, sadly, but on the other hand we just upgraded to Tomcat 8 and
not having a functional websocket implementation is a mite annoying.
   
Alex