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