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: 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ò  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? 

Re: [ANNOUNCE] CVE-2016-6793 Apache Wicket deserialization vulnerability

[Martin Grigorov]

The site has been updated to use 1.5.17.
Thanks for letting us know!

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

On Tue, Jan 3, 2017 at 10:24 PM, durairaj t  wrote:

> Thank you!
>
> On Tue, Jan 3, 2017 at 4:11 PM, Tobias Soloschenko <
> tobiassolosche...@googlemail.com> wrote:
>
> > Hi,
> >
> > but it is released. See here: https://mvnrepository.com/arti
> > fact/org.apache.wicket/wicket-core/1.5.17
> >
> > kind regards
> >
> > Tobias
> >
> > Am 03.01.17 um 21:25 schrieb durairaj t:
> >
> >> I can see the Wicket 1.5.16 but not 1.5.17 in "
> >> https://wicket.apache.org/start/wicket-1.5.x.html#download;.
> >>
> >>
> >>
> >> On Sat, Dec 31, 2016 at 2:21 AM, Pedro Santos  wrote:
> >>
> >> CVE-2016-6793: Apache Wicket deserialization vulnerability
> >>>
> >>> Severity: Low
> >>>
> >>> Vendor: The Apache Software Foundation
> >>>
> >>> Versions Affected: Apache Wicket 6.x and 1.5.x
> >>>
> >>> Description: Depending on the ISerializer set in the Wicket
> application,
> >>> it's possible that a Wicket's object deserialized from an untrusted
> >>> source
> >>> and utilized by the application to causes the code to enter in an
> >>> infinite loop. Specifically, Wicket's DiskFileItem class, serialized by
> >>> Kryo, allows an attacker to hack its serialized form to put a client on
> >>> an
> >>> infinite loop if the client attempts to write on the
> >>> DeferredFileOutputStream attribute.
> >>>
> >>> Mitigation: Upgrade to Apache Wicket 6.25.0 or 1.5.17
> >>>
> >>> Credit: This issue was discovered by Jacob Baines, Tenable Network
> >>> Security and
> >>> Pedro Santos
> >>>
> >>> References: https://wicket.apache.org/news
> >>>
> >>>
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
>

Question/Suggestion about updating a component in aw existing page (Wicket 6.x)

[christophe]

Hello dear readers
I am working on a web application that is very very AJAX-oriented. In other
words any "displayed" page gets updated many times as a consequence of
events such as (html) blur, mouse click.
By updating I mean
One or more fields become visible or invisible
One or more fields become enabled or disabled
Their content (for example a drop down list) changes
Many more

To actually "change" a markup component I
1) create a new one and replace the existing one  or udpate the Component
(for example to enable it)
2) Add this component to the AjaxRequestTarget

I must do both because if I do 
1 only: the change is not reflected in the web page.
2 only the component is not in the right "state" and I get all sorts of
exceptions when it receives a message

So I was wondering
1) AM i doing this right or amm I missing the obvious
2) If I am not doing anything wrong would it be possible to "enhance" Wicket
so that any replace or "state", content update gets added "automatically" to
the Request Target?

I sincerely hope to hear from someone.
Christophe

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Question-Suggestion-about-updating-a-component-in-aw-existing-page-Wicket-6-x-tp4676637.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: Question/Suggestion about updating a component in aw existing page (Wicket 6.x)

[Martin Grigorov]

Hello dear writer :-)

On Wed, Jan 4, 2017 at 2:14 PM, christophe 
wrote:

> Hello dear readers
> I am working on a web application that is very very AJAX-oriented. In other
> words any "displayed" page gets updated many times as a consequence of
> events such as (html) blur, mouse click.
> By updating I mean
> One or more fields become visible or invisible
> One or more fields become enabled or disabled
> Their content (for example a drop down list) changes
> Many more
>
> To actually "change" a markup component I
> 1) create a new one and replace the existing one  or udpate the Component
> (for example to enable it)
> 2) Add this component to the AjaxRequestTarget
>
> I must do both because if I do
> 1 only: the change is not reflected in the web page.
> 2 only the component is not in the right "state" and I get all sorts of
> exceptions when it receives a message
>
> So I was wondering
> 1) AM i doing this right or amm I missing the obvious
>

If you replace ComponentA with ComponentB then it is perfectly fine
If you replace ComponentA with a new instance of ComponentA then maybe you
should use a dynamic model, as Bas suggestedthe


> 2) If I am not doing anything wrong would it be possible to "enhance"
> Wicket
> so that any replace or "state", content update gets added "automatically"
> to
> the Request Target?
>

Most probably not!
1) because we (Wicket developers and users) don't like magic
2) it is hard for the framework to decide whether a Component has been
changed or not. If it is only an updated model object then Wicket is
notified, but a Component can have its own state (member fields) and
without using bytecode modification of all your classes it is impossible to
know whether something has changed. And bytecode modification is a big
magic!

In the past I have implemented such auto-added FeedbackPanel. By using
AjaxRequestTarget.IListener and FeedbackCollector#collect() I've decided
whether to add MyBasePage.getFeedbackPanel() to the target.
It worked fine but here I knew the exact rules when and what to add to the
target.


>
> I sincerely hope to hear from someone.
> Christophe
>
> --
> View this message in context: http://apache-wicket.1842946.
> n4.nabble.com/Question-Suggestion-about-updating-a-
> component-in-aw-existing-page-Wicket-6-x-tp4676637.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: Question/Suggestion about updating a component in aw existing page (Wicket 6.x)

[Bas Gooren]

Hi Christophe!

Regarding (1): it sounds like you are not using models properly; Models are 
what makes a component “dynamic” - they pull data from a source (which could be 
a static string).
Can you show us some code?

Regarding (2): Can you show us the exceptions you get?
In any case you should be aware that you cannot re-render a hidden component, 
unless you set its setOutputMarkupPlaceholderTag(true) method, ensuring that 
there is always a HTML element to replace.
Another common solution is to re-render a container element which is always 
present in the HTML.

Met vriendelijke groet,
Kind regards,

Bas Gooren

Op 4 januari 2017 bij 14:33:34, christophe (madeleine.christo...@wanadoo.fr) 
schreef:

Hello dear readers  
I am working on a web application that is very very AJAX-oriented. In other  
words any "displayed" page gets updated many times as a consequence of  
events such as (html) blur, mouse click.  
By updating I mean  
One or more fields become visible or invisible  
One or more fields become enabled or disabled  
Their content (for example a drop down list) changes  
Many more  

To actually "change" a markup component I  
1) create a new one and replace the existing one or udpate the Component  
(for example to enable it)  
2) Add this component to the AjaxRequestTarget  

I must do both because if I do  
1 only: the change is not reflected in the web page.  
2 only the component is not in the right "state" and I get all sorts of  
exceptions when it receives a message  

So I was wondering  
1) AM i doing this right or amm I missing the obvious  
2) If I am not doing anything wrong would it be possible to "enhance" Wicket  
so that any replace or "state", content update gets added "automatically" to  
the Request Target?  

I sincerely hope to hear from someone.  
Christophe  

--  
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Question-Suggestion-about-updating-a-component-in-aw-existing-page-Wicket-6-x-tp4676637.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: Question/Suggestion about updating a component in aw existing page (Wicket 6.x)

[christophe]

Hello Sebastian

Thanks for your confirmation (it must be “manual”).. So I was not doing the 
wrong thing.
I will  “extend” the components to  issue to do  both updates “automatically”. 
As to the getSession().. It is misleading as it refers to an “application 
session” It does not have anything to do with the http session... But I will 
rename it anyway as I understand that the name is very misleading.

Wicket is brillant.. Congratulations

Thank you
Christophe

From: Sebastian [via Apache Wicket] 
Sent: Wednesday, January 04, 2017 3:10 PM
To: christophe 
Subject: Re: Question/Suggestion about updating a component in aw existing page 
(Wicket 6.x)

Hi! 

Yes, wicket does not automatically add changed components to the ajax response. 
That would be a lot of magic, which does not fit with the way the rest of the 
framework works (for as far as I know). 
I quite like how it currently works, as it’s very clear what happens. 

Looking at your code, I have some tips: 

Don’t store the AjaxRequestTarget (ART) in the session. The session can exist 
across requests, so this is not something you want to mix. 
You can always get the current ART from inside a component in case you don’t 
have a reference to it: 

getRequest().find(AjaxRequestTarget.class) 

Making things more “automatic” for your specific application: 
There is a number of ways to do this; 
One example would be to create a custom component which does what you want, 
which either extends existing wicket components or wraps them (e.g. a Panel). 
Another example would be to broadcast a wicket event from every component once 
it’s been updated (storing a component reference in the event); You can then 
listen for these events in your “parent”/owning component and add the component 
to the ART. 

Met vriendelijke groet, 
Kind regards, 

Bas Gooren 

Op 4 januari 2017 bij 15:10:46, christophe ([hidden email]) schreef: 

Hello Sebastian   

That was a fast feedback!! I am impressed!!!   

For 2) I would have to go and modify the code to get you the exact error.   
What I was trying to point out was simply that if Ido not BOTH replace or 
update the component (its state, its content) AND add to to The 
AjaxRequestTarget ( target.add(myComponent) I get all sorts of malfunction.   
So the question was really is this how it mut be done or am I missing something 
important (after several years of Wicket programming, there would not be much 
to be proud about!!)   

This is an example (simplifed) to update the content of a text input field   

public void setValue(String value) {   
// Some business logic   
//Then   
model = new Model(value);   
field.setModel(model);// Does not add the field to the output stream   
if (getSession().getTarget() ) // If an Ajax event is being processed the 
Target it came with is stored for the duration of said “process”   
getSession().getTarget().add(field); //If I dont do this the content does not 
get updated on the browser   
}   

So my understanding is that, in the context of an event (intercepted by a 
behavior) that comes “bundled” with an AjaxRequestTarget updating the component 
(and possibly replacing it) is not enough for said component to be added to the 
output stream. I must manuall do it via AjaxRequestTarget#add(Component).   

Hence my 2 questions:   
I am right?   
What about mking this “automatic”?   

If I am wrong please let me know   

Regards   
Christopeh   

From: Sebastian [via Apache Wicket]   
Sent: Wednesday, January 04, 2017 2:28 PM   
To: christophe   
Subject: Re: Question/Suggestion about updating a component in aw existing page 
(Wicket 6.x)   

Hi Christophe!   

Regarding (1): it sounds like you are not using models properly; Models are 
what makes a component “dynamic” - they pull data from a source (which could be 
a static string).   
Can you show us some code?   

Regarding (2): Can you show us the exceptions you get?   
In any case you should be aware that you cannot re-render a hidden component, 
unless you set its setOutputMarkupPlaceholderTag(true) method, ensuring that 
there is always a HTML element to replace.   
Another common solution is to re-render a container element which is always 
present in the HTML.   

Met vriendelijke groet,   
Kind regards,   

Bas Gooren   

Op 4 januari 2017 bij 14:33:34, christophe ([hidden email]) schreef:   

Hello dear readers   
I am working on a web application that is very very AJAX-oriented. In other   
words any "displayed" page gets updated many times as a consequence of   
events such as (html) blur, mouse click.   
By updating I mean   
One or more fields become visible or invisible   
One or more fields become enabled or disabled   
Their content (for example a drop down list) changes   
Many more   

To actually "change" a markup component I   
1) create a new one and replace the existing one or udpate the Component   
(for example to enable it)   
2) Add this component to the AjaxRequestTarget   

I must do both because if I do   
1 

Re: Question/Suggestion about updating a component in aw existing page (Wicket 6.x)

[Bas Gooren]

Hi!

Yes, wicket does not automatically add changed components to the ajax response.
That would be a lot of magic, which does not fit with the way the rest of the 
framework works (for as far as I know).
I quite like how it currently works, as it’s very clear what happens.

Looking at your code, I have some tips:

Don’t store the AjaxRequestTarget (ART) in the session. The session can exist 
across requests, so this is not something you want to mix.
You can always get the current ART from inside a component in case you don’t 
have a reference to it:

getRequest().find(AjaxRequestTarget.class)

Making things more “automatic” for your specific application:
There is a number of ways to do this;
One example would be to create a custom component which does what you want, 
which either extends existing wicket components or wraps them (e.g. a Panel).
Another example would be to broadcast a wicket event from every component once 
it’s been updated (storing a component reference in the event); You can then 
listen for these events in your “parent”/owning component and add the component 
to the ART.

Met vriendelijke groet,
Kind regards,

Bas Gooren

Op 4 januari 2017 bij 15:10:46, christophe (madeleine.christo...@wanadoo.fr) 
schreef:

Hello Sebastian  

That was a fast feedback!! I am impressed!!!  

For 2) I would have to go and modify the code to get you the exact error.  
What I was trying to point out was simply that if Ido not BOTH replace or 
update the component (its state, its content) AND add to to The 
AjaxRequestTarget ( target.add(myComponent) I get all sorts of malfunction.  
So the question was really is this how it mut be done or am I missing something 
important (after several years of Wicket programming, there would not be much 
to be proud about!!)  

This is an example (simplifed) to update the content of a text input field  

public void setValue(String value) {  
// Some business logic  
//Then  
model = new Model(value);  
field.setModel(model);// Does not add the field to the output stream  
if (getSession().getTarget() ) // If an Ajax event is being processed the 
Target it came with is stored for the duration of said “process”  
getSession().getTarget().add(field); //If I dont do this the content does not 
get updated on the browser  
}  

So my understanding is that, in the context of an event (intercepted by a 
behavior) that comes “bundled” with an AjaxRequestTarget updating the component 
(and possibly replacing it) is not enough for said component to be added to the 
output stream. I must manuall do it via AjaxRequestTarget#add(Component).  

Hence my 2 questions:  
I am right?  
What about mking this “automatic”?  

If I am wrong please let me know  

Regards  
Christopeh  

From: Sebastian [via Apache Wicket]  
Sent: Wednesday, January 04, 2017 2:28 PM  
To: christophe  
Subject: Re: Question/Suggestion about updating a component in aw existing page 
(Wicket 6.x)  

Hi Christophe!  

Regarding (1): it sounds like you are not using models properly; Models are 
what makes a component “dynamic” - they pull data from a source (which could be 
a static string).  
Can you show us some code?  

Regarding (2): Can you show us the exceptions you get?  
In any case you should be aware that you cannot re-render a hidden component, 
unless you set its setOutputMarkupPlaceholderTag(true) method, ensuring that 
there is always a HTML element to replace.  
Another common solution is to re-render a container element which is always 
present in the HTML.  

Met vriendelijke groet,  
Kind regards,  

Bas Gooren  

Op 4 januari 2017 bij 14:33:34, christophe ([hidden email]) schreef:  

Hello dear readers  
I am working on a web application that is very very AJAX-oriented. In other  
words any "displayed" page gets updated many times as a consequence of  
events such as (html) blur, mouse click.  
By updating I mean  
One or more fields become visible or invisible  
One or more fields become enabled or disabled  
Their content (for example a drop down list) changes  
Many more  

To actually "change" a markup component I  
1) create a new one and replace the existing one or udpate the Component  
(for example to enable it)  
2) Add this component to the AjaxRequestTarget  

I must do both because if I do  
1 only: the change is not reflected in the web page.  
2 only the component is not in the right "state" and I get all sorts of  
exceptions when it receives a message  

So I was wondering  
1) AM i doing this right or amm I missing the obvious  
2) If I am not doing anything wrong would it be possible to "enhance" Wicket  
so that any replace or "state", content update gets added "automatically" to  
the Request Target?  

I sincerely hope to hear from someone.  
Christophe  

--  
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Question-Suggestion-about-updating-a-component-in-aw-existing-page-Wicket-6-x-tp4676637.html
  
Sent from the Users forum mailing list archive at 

Re: Question/Suggestion about updating a component in aw existing page (Wicket 6.x)

[christophe]

Hello Sebastian

That was a fast feedback!! I am impressed!!!

For 2) I would have to go and modify the code to get you the exact error.
What I was trying to point out was simply that if Ido not BOTH replace or 
update the component (its state, its content) AND add to to The 
AjaxRequestTarget ( target.add(myComponent) I get all sorts of malfunction. 
So the question was really is this how it mut be done or am I missing something 
important (after several years of Wicket programming, there would not be much 
to be proud about!!)

This is an example (simplifed) to update the content of a text input field

public void setValue(String value) {
// Some business logic
   //Then
model = new Model(value);
field.setModel(model);// Does not add the field to the output stream
if (getSession().getTarget() ) // If an Ajax event is being 
processed the Target it came with is stored for the duration of said “process”
getSession().getTarget().add(field); //If I dont do this the 
content does not get updated on the browser
}

So my understanding is that, in the context of an event (intercepted by a 
behavior) that comes “bundled” with an AjaxRequestTarget updating the component 
(and possibly replacing it) is not enough for said component to be added to the 
output stream. I must manuall do it via AjaxRequestTarget#add(Component). 

Hence my 2 questions:
I am right?
What about mking this “automatic”?

If I am wrong please let me know 

Regards
Christopeh

From: Sebastian [via Apache Wicket] 
Sent: Wednesday, January 04, 2017 2:28 PM
To: christophe 
Subject: Re: Question/Suggestion about updating a component in aw existing page 
(Wicket 6.x)

Hi Christophe! 

Regarding (1): it sounds like you are not using models properly; Models are 
what makes a component “dynamic” - they pull data from a source (which could be 
a static string). 
Can you show us some code? 

Regarding (2): Can you show us the exceptions you get? 
In any case you should be aware that you cannot re-render a hidden component, 
unless you set its setOutputMarkupPlaceholderTag(true) method, ensuring that 
there is always a HTML element to replace. 
Another common solution is to re-render a container element which is always 
present in the HTML. 

Met vriendelijke groet, 
Kind regards, 

Bas Gooren 

Op 4 januari 2017 bij 14:33:34, christophe ([hidden email]) schreef: 

Hello dear readers   
I am working on a web application that is very very AJAX-oriented. In other   
words any "displayed" page gets updated many times as a consequence of   
events such as (html) blur, mouse click.   
By updating I mean   
One or more fields become visible or invisible   
One or more fields become enabled or disabled   
Their content (for example a drop down list) changes   
Many more   

To actually "change" a markup component I   
1) create a new one and replace the existing one or udpate the Component   
(for example to enable it)   
2) Add this component to the AjaxRequestTarget   

I must do both because if I do   
1 only: the change is not reflected in the web page.   
2 only the component is not in the right "state" and I get all sorts of   
exceptions when it receives a message   

So I was wondering   
1) AM i doing this right or amm I missing the obvious   
2) If I am not doing anything wrong would it be possible to "enhance" Wicket   
so that any replace or "state", content update gets added "automatically" to   
the Request Target?   

I sincerely hope to hear from someone.   
Christophe   

--   
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Question-Suggestion-about-updating-a-component-in-aw-existing-page-Wicket-6-x-tp4676637.html
  
Sent from the Users forum mailing list archive at Nabble.com.   

-   
To unsubscribe, e-mail: [hidden email]   
For additional commands, e-mail: [hidden email]   






If you reply to this email, your message will be added to the discussion below:
http://apache-wicket.1842946.n4.nabble.com/Question-Suggestion-about-updating-a-component-in-aw-existing-page-Wicket-6-x-tp4676637p4676638.html
 
To unsubscribe from Question/Suggestion about updating a component in aw 
existing page (Wicket 6.x), click here.
NAML

wlEmoticon-smile[1].png (1K) 



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Question-Suggestion-about-updating-a-component-in-aw-existing-page-Wicket-6-x-tp4676637p4676639.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: Question/Suggestion about updating a component in aw existing page (Wicket 6.x)

[Martin Grigorov]

Small correction:

getRequest().find(AjaxRequestTarget.class)

should be

getRequestCycle().find(AjaxRequestTarget.class)

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

On Wed, Jan 4, 2017 at 3:26 PM, Bas Gooren  wrote:

> Hi!
>
> Yes, wicket does not automatically add changed components to the ajax
> response.
> That would be a lot of magic, which does not fit with the way the rest of
> the framework works (for as far as I know).
> I quite like how it currently works, as it’s very clear what happens.
>
> Looking at your code, I have some tips:
>
> Don’t store the AjaxRequestTarget (ART) in the session. The session can
> exist across requests, so this is not something you want to mix.
> You can always get the current ART from inside a component in case you
> don’t have a reference to it:
>
> getRequest().find(AjaxRequestTarget.class)
>
> Making things more “automatic” for your specific application:
> There is a number of ways to do this;
> One example would be to create a custom component which does what you
> want, which either extends existing wicket components or wraps them (e.g. a
> Panel).
> Another example would be to broadcast a wicket event from every component
> once it’s been updated (storing a component reference in the event); You
> can then listen for these events in your “parent”/owning component and add
> the component to the ART.
>
> Met vriendelijke groet,
> Kind regards,
>
> Bas Gooren
>
> Op 4 januari 2017 bij 15:10:46, christophe (madeleine.christophe@wanadoo.
> fr) schreef:
>
> Hello Sebastian
>
> That was a fast feedback!! I am impressed!!!
>
> For 2) I would have to go and modify the code to get you the exact error.
> What I was trying to point out was simply that if Ido not BOTH replace or
> update the component (its state, its content) AND add to to The
> AjaxRequestTarget ( target.add(myComponent) I get all sorts of malfunction.
> So the question was really is this how it mut be done or am I missing
> something important (after several years of Wicket programming, there would
> not be much to be proud about!!)
>
> This is an example (simplifed) to update the content of a text input field
>
> public void setValue(String value) {
> // Some business logic
> //Then
> model = new Model(value);
> field.setModel(model);// Does not add the field to the output stream
> if (getSession().getTarget() ) // If an Ajax event is being processed the
> Target it came with is stored for the duration of said “process”
> getSession().getTarget().add(field); //If I dont do this the content does
> not get updated on the browser
> }
>
> So my understanding is that, in the context of an event (intercepted by a
> behavior) that comes “bundled” with an AjaxRequestTarget updating the
> component (and possibly replacing it) is not enough for said component to
> be added to the output stream. I must manuall do it via
> AjaxRequestTarget#add(Component).
>
> Hence my 2 questions:
> I am right?
> What about mking this “automatic”?
>
> If I am wrong please let me know
>
> Regards
> Christopeh
>
> From: Sebastian [via Apache Wicket]
> Sent: Wednesday, January 04, 2017 2:28 PM
> To: christophe
> Subject: Re: Question/Suggestion about updating a component in aw existing
> page (Wicket 6.x)
>
> Hi Christophe!
>
> Regarding (1): it sounds like you are not using models properly; Models
> are what makes a component “dynamic” - they pull data from a source (which
> could be a static string).
> Can you show us some code?
>
> Regarding (2): Can you show us the exceptions you get?
> In any case you should be aware that you cannot re-render a hidden
> component, unless you set its setOutputMarkupPlaceholderTag(true) method,
> ensuring that there is always a HTML element to replace.
> Another common solution is to re-render a container element which is
> always present in the HTML.
>
> Met vriendelijke groet,
> Kind regards,
>
> Bas Gooren
>
> Op 4 januari 2017 bij 14:33:34, christophe ([hidden email]) schreef:
>
> Hello dear readers
> I am working on a web application that is very very AJAX-oriented. In other
> words any "displayed" page gets updated many times as a consequence of
> events such as (html) blur, mouse click.
> By updating I mean
> One or more fields become visible or invisible
> One or more fields become enabled or disabled
> Their content (for example a drop down list) changes
> Many more
>
> To actually "change" a markup component I
> 1) create a new one and replace the existing one or udpate the Component
> (for example to enable it)
> 2) Add this component to the AjaxRequestTarget
>
> I must do both because if I do
> 1 only: the change is not reflected in the web page.
> 2 only the component is not in the right "state" and I get all sorts of
> exceptions when it receives a message
>
> So I was wondering
> 1) AM i doing this right or amm I missing the obvious
> 2) If I am not doing anything wrong would it be possible to "enhance"
> Wicket
> so that any replace 

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ò 
 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 

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ò  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-coyote.jar:8.0.39]
>>>  

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ò  
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!
Regards.

[1] 

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ò  
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-coyote.jar:8.0.39]
  at 

Re: [ANNOUNCE] WicketStuff 6.26.0 is released

[Andrea Del Bene]

Hi Martin,

I've just merged the huge PR for "WICKET-6287 Switch from json.org to 
open-json". I've relized that this might be a problem for WicketStuff 
8.0.0-M3 if you use the current master branch against Wicket 8.0.0-M3. 
Sorry for the inconvenience :-(.


Andrea


On 04/01/2017 20:42, Martin Grigorov wrote:

Hi,

WicketStuff core 6.26.0 based on Apache Wicket 6.26.0 is released and
available at Maven Central.

Konstantinos Karavitis (2):
   [portlets] Merge pull request #562 from kkaravitis/wicket-6.x
   [portlets] Update pom.xml

Martin Tzvetanov Grigorov (2):
   Build against Wicket 6.26.0-SNAPSHOT
   Release 6.26.0

Maxim Solodovnik (1):
   json:json library is replaced with openjson; examples are fixed

Miguel Payet (1):
   [editablegrid] Fix the save action in an EditableGrid when there are
more than 1 editable grids on the page (#558)

Sven Meier (1):
   [lambda-model] issue #534: destroy the factory

kkaravitis (1):
   [portlets] synchronize wicket-6.x branch with the latest fixes on
wicket-7.x branch


The WicketStuff team!




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

[ANNOUNCE] WicketStuff 6.26.0 is released

[Martin Grigorov]

Hi,

WicketStuff core 6.26.0 based on Apache Wicket 6.26.0 is released and
available at Maven Central.

Konstantinos Karavitis (2):
  [portlets] Merge pull request #562 from kkaravitis/wicket-6.x
  [portlets] Update pom.xml

Martin Tzvetanov Grigorov (2):
  Build against Wicket 6.26.0-SNAPSHOT
  Release 6.26.0

Maxim Solodovnik (1):
  json:json library is replaced with openjson; examples are fixed

Miguel Payet (1):
  [editablegrid] Fix the save action in an EditableGrid when there are
more than 1 editable grids on the page (#558)

Sven Meier (1):
  [lambda-model] issue #534: destroy the factory

kkaravitis (1):
  [portlets] synchronize wicket-6.x branch with the latest fixes on
wicket-7.x branch


The WicketStuff team!

[ANNOUNCE] WicketStuff 7.6.0 Released

[Martin Grigorov]

WicketStuff core 7.6.0 based on Apache Wicket 7.6.0 is released and available
at Maven Central.

The changelog since 7.5.0 is:


Martin Tzvetanov Grigorov (14):
  [gmap3] Fix the name of an author
  Build against Wicket 7.6.0-SNAPSHOT
  [clipboard.js] Initial commit of integration with Clipboard.js
  [clipboard.js] Add support for setting the target by CSS selector.
  [pdf.js] Initial import
  [pdf.js] Use PackageTextTemplate to load the setup script for PDF.JS
  [pdf.js] Add support to set the url to pdf.worker.js and the initial
page number
  [pdf.js] Add support for setting the initial scale
  [pdf.js] Use Wicket-JQuery-Selectors to initialize WicketStuff-PDF
with JSON config
  [pdf.js] Show how to load PDF document as bytes
  [pdf.js] Update README. Add module to the project
  [pdf.js] Add support for several panels in the same page. Each
navigation bar controls its pdf viewer
  [pdfjs] Change the namespace to WicketStuff.PDFJS
  Release 7.6.0

Maxim Solodovnik (5):
  Select2 version is updated to 4.0.3
  Code clean-up: serialVersionUID is added
  Ajax query param is made configurable
  json:json library is replaced with openjson; examples are fixed
  issue #470: dropdownParent setting is added

Andrea Del Bene (2):
  Porting of solution to check for unbound behavior
  Module wicketstuff-stateless has been deprecated as Wicket 7 has now
support for stateless behaviors and components

Konstantinos Karavitis (2):
  Merge pull request #560 from kkaravitis/wicket-7.x
  Update pom.xml

Miguel Payet (1):
  Fix the save action in an EditableGrid when there are more than 1
editable grids on the page (#558)

Sven Meier (1):
  issue #534: destroy the factory

kkaravitis (1):
  fix for issue #559


The WicketStuff team

Re: [ANNOUNCE] WicketStuff 6.26.0 is released

[Martin Grigorov]

Hi Andrea,

Does this affect 6.26.0 anyhow ?

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

On Wed, Jan 4, 2017 at 9:47 PM, Andrea Del Bene 
wrote:

> Hi Martin,
>
> I've just merged the huge PR for "WICKET-6287 Switch from json.org to
> open-json". I've relized that this might be a problem for WicketStuff
> 8.0.0-M3 if you use the current master branch against Wicket 8.0.0-M3.
> Sorry for the inconvenience :-(.
>
> Andrea
>
>
>
> On 04/01/2017 20:42, Martin Grigorov wrote:
>
>> Hi,
>>
>> WicketStuff core 6.26.0 based on Apache Wicket 6.26.0 is released and
>> available at Maven Central.
>>
>> Konstantinos Karavitis (2):
>>[portlets] Merge pull request #562 from kkaravitis/wicket-6.x
>>[portlets] Update pom.xml
>>
>> Martin Tzvetanov Grigorov (2):
>>Build against Wicket 6.26.0-SNAPSHOT
>>Release 6.26.0
>>
>> Maxim Solodovnik (1):
>>json:json library is replaced with openjson; examples are fixed
>>
>> Miguel Payet (1):
>>[editablegrid] Fix the save action in an EditableGrid when there
>> are
>> more than 1 editable grids on the page (#558)
>>
>> Sven Meier (1):
>>[lambda-model] issue #534: destroy the factory
>>
>> kkaravitis (1):
>>[portlets] synchronize wicket-6.x branch with the latest fixes on
>> wicket-7.x branch
>>
>>
>> The WicketStuff team!
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: [ANNOUNCE] WicketStuff 6.26.0 is released

[Andrea Del Bene]

no no. just the incoming  (l guess) 8.0.0-M3

On 4 Jan 2017 22:22, "Martin Grigorov"  wrote:

> Hi Andrea,
>
> Does this affect 6.26.0 anyhow ?
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Wed, Jan 4, 2017 at 9:47 PM, Andrea Del Bene 
> wrote:
>
> > Hi Martin,
> >
> > I've just merged the huge PR for "WICKET-6287 Switch from json.org to
> > open-json". I've relized that this might be a problem for WicketStuff
> > 8.0.0-M3 if you use the current master branch against Wicket 8.0.0-M3.
> > Sorry for the inconvenience :-(.
> >
> > Andrea
> >
> >
> >
> > On 04/01/2017 20:42, Martin Grigorov wrote:
> >
> >> Hi,
> >>
> >> WicketStuff core 6.26.0 based on Apache Wicket 6.26.0 is released and
> >> available at Maven Central.
> >>
> >> Konstantinos Karavitis (2):
> >>[portlets] Merge pull request #562 from kkaravitis/wicket-6.x
> >>[portlets] Update pom.xml
> >>
> >> Martin Tzvetanov Grigorov (2):
> >>Build against Wicket 6.26.0-SNAPSHOT
> >>Release 6.26.0
> >>
> >> Maxim Solodovnik (1):
> >>json:json library is replaced with openjson; examples are fixed
> >>
> >> Miguel Payet (1):
> >>[editablegrid] Fix the save action in an EditableGrid when there
> >> are
> >> more than 1 editable grids on the page (#558)
> >>
> >> Sven Meier (1):
> >>[lambda-model] issue #534: destroy the factory
> >>
> >> kkaravitis (1):
> >>[portlets] synchronize wicket-6.x branch with the latest fixes on
> >> wicket-7.x branch
> >>
> >>
> >> The WicketStuff team!
> >>
> >>
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
>