Re: JSR356 Websocket with Wicket 6.18
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 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 >> 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=6&wicket-ajax-baseurl=behavior%3F6&wicket-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 >> > >
Re: JSR356 Websocket with Wicket 6.18
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 > 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=6&wicket-ajax-baseurl=behavior%3F6&wicket-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 > > > > 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] > > > > >
Re: JSR356 Websocket with Wicket 6.18
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 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=6&wicket-ajax-baseurl=behavior%3F6&wicket-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 > > 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 > >
Re: JSR356 Websocket with Wicket 6.18
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=6&wicket-ajax-baseurl=behavior%3F6&wicket-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 > 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
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=6&wicket-ajax-baseurl=behavior%3F6&wicket-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 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
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
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
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 >
JSR356 Websocket with Wicket 6.18
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
