PropertyValidator sets Required flag too late
Hello,
I am writing a simple stateless form with validation based on annotations in
Wicket 7.0.0-SNAPSHOT. When the model's field is annotated @NotNull and
PropertyValidator is added to its form component, the validation error is not
generated if user's input is empty. It seems to me that the Required flag is
set too late, because while debugging I noticed that isRequired is called at
least once before PropertyValidator's onConfigure. In the end the component has
the flag set but without effect. As a workaround I have created descendants of
CheckBox, TextArea and TextField with isRequired overriden as follows:
@Override
public boolean isRequired() {
if (!isRequiredRecurse) {
isRequiredRecurse = true;
configure(); //this should let PropertyValidator call setRequired
isRequiredRecurse = false;
}
return super.isRequired();
}
This fixes the problem, so it seems I configured everything correctly and also
@Pattern works fine which leads me to think it's a bug, right? This may be
related to issue WICKET-5329 Required flag initialized too early in
PropertyValidator, which is the only ticket I found that could have any
connection to this.
Sorry if this question has been already asked and answered.
Thanks!
Adam
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Fetching google calender details in wicket
Hello, thank you for responding, I have already implemented the calender using Wicket-JQuery-UI, now I need to fetch the details of a user from his Google calender which I could display in the user's account calender in my application also. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Fetching-google-calender-details-in-wicket-tp4669104p4669158.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: PropertyValidator sets Required flag too late
Hi,
Yes. It is a bug. Please create a ticket.
The problem comes from the fact that you use stateless form. The required
flag is set for the form component on the rendered page, but later when the
form is submitted a new page with a new form (and components) is created
and the flag is gone.
Since there is no Behavior#onInitialize() we can only use #onBind() but as
WICKET-5329 says at this time the parent may be not yet available and the
logic breaks whenCompoundPropertyModel is used.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Wed, Jan 28, 2015 at 12:22 PM, Adam Huječek huj...@seznam.cz wrote:
Hello,
I am writing a simple stateless form with validation based on annotations
in Wicket 7.0.0-SNAPSHOT. When the model's field is annotated @NotNull and
PropertyValidator is added to its form component, the validation error is
not generated if user's input is empty. It seems to me that the Required
flag is set too late, because while debugging I noticed that isRequired is
called at least once before PropertyValidator's onConfigure. In the end the
component has the flag set but without effect. As a workaround I have
created descendants of CheckBox, TextArea and TextField with isRequired
overriden as follows:
@Override
public boolean isRequired() {
if (!isRequiredRecurse) {
isRequiredRecurse = true;
configure(); //this should let PropertyValidator call
setRequired
isRequiredRecurse = false;
}
return super.isRequired();
}
This fixes the problem, so it seems I configured everything correctly and
also @Pattern works fine which leads me to think it's a bug, right? This
may be related to issue WICKET-5329 Required flag initialized too early
in PropertyValidator, which is the only ticket I found that could have any
connection to this.
Sorry if this question has been already asked and answered.
Thanks!
Adam
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: PropertyValidator sets Required flag too late
Ticket created, thank you for your time and explanation!
Adam
-- Původní zpráva --
Od: Martin Grigorov mgrigo...@apache.org
Komu: users@wicket.apache.org users@wicket.apache.org
Datum: 28. 1. 2015 12:36:21
Předmět: Re: PropertyValidator sets Required flag too late
Hi,
Yes. It is a bug. Please create a ticket.
The problem comes from the fact that you use stateless form. The required
flag is set for the form component on the rendered page, but later when the
form is submitted a new page with a new form (and components) is created
and the flag is gone.
Since there is no Behavior#onInitialize() we can only use #onBind() but as
WICKET-5329 says at this time the parent may be not yet available and the
logic breaks whenCompoundPropertyModel is used.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Wed, Jan 28, 2015 at 12:22 PM, Adam Huječek huj...@seznam.cz wrote:
Hello,
I am writing a simple stateless form with validation based on annotations
in Wicket 7.0.0-SNAPSHOT. When the model's field is annotated @NotNull and
PropertyValidator is added to its form component, the validation error is
not generated if user's input is empty. It seems to me that the Required
flag is set too late, because while debugging I noticed that isRequired is
called at least once before PropertyValidator's onConfigure. In the end
the
component has the flag set but without effect. As a workaround I have
created descendants of CheckBox, TextArea and TextField with isRequired
overriden as follows:
@Override
public boolean isRequired() {
if (!isRequiredRecurse) {
isRequiredRecurse = true;
configure(); //this should let PropertyValidator call
setRequired
isRequiredRecurse = false;
}
return super.isRequired();
}
This fixes the problem, so it seems I configured everything correctly and
also @Pattern works fine which leads me to think it's a bug, right? This
may be related to issue WICKET-5329 Required flag initialized too early
in PropertyValidator, which is the only ticket I found that could have any
connection to this.
Sorry if this question has been already asked and answered.
Thanks!
Adam
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Fetching google calender details in wicket
For this you will have to consult with http://fullcalendar.io/docs/google_calendar/ and the provided integration in Wicket JQuery UI project. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Wed, Jan 28, 2015 at 12:39 PM, jayeshps jayeshpsars...@gmail.com wrote: Hello, thank you for responding, I have already implemented the calender using Wicket-JQuery-UI, now I need to fetch the details of a user from his Google calender which I could display in the user's account calender in my application also. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Fetching-google-calender-details-in-wicket-tp4669104p4669158.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: 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
Wicketstuff Restannotations AbortWithHttpErrorCodeException always results in 500 Internal Server Error
Hi, We use the great rest-annotation from wicketstuff. One thing that bothers is if the AbortWithHttpErrorCodeException with a specific code (404, 402, etc) is thrown by the mapped method, those error codes do not make it to the calling client. The client always seems to get a 500. I debugged through the request/response and found this in AbstractRestResource: http://pastebin.com/NKNmNHv6 Is there any way of getting the correct error codes to the client? If not, how are other people handling this? I would be glad to invest some time and apply a patch if necessary -- Thanks and Cheers, Hans - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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: Wicketstuff Restannotations AbortWithHttpErrorCodeException always results in 500 Internal Server Error
Hans, I handle all exceptions and set status codes in my mapped method with AbstractRestResource#setResponseStatusCode(…). I don’t ever throw any exceptions from there. Setting a status code is the only thing that is really happening in AbstractRestResource#invokeMappedMethod(…) when an exception is caught anyway. Just spare the throwing of an exception and set the status code in your mapped method. throw new AbortWithHttpErrorCodeException(“500”, “Ouch”); versus setResponseStatusCode(“500”); Also, I believe AbortWithHttpErrorCodeException is part of Wicket core, not something meant to be used in rest-annotations. Hope this helps, Warren Bell On Jan 28, 2015, at 7:58 AM, Hans Lesmeister hans.lesmeis...@lessy-software.de wrote: Hi, We use the great rest-annotation from wicketstuff. One thing that bothers is if the AbortWithHttpErrorCodeException with a specific code (404, 402, etc) is thrown by the mapped method, those error codes do not make it to the calling client. The client always seems to get a 500. I debugged through the request/response and found this in AbstractRestResource: http://pastebin.com/NKNmNHv6 Is there any way of getting the correct error codes to the client? If not, how are other people handling this? I would be glad to invest some time and apply a patch if necessary -- Thanks and Cheers, Hans - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
AW: Wicketstuff Restannotations AbortWithHttpErrorCodeException always results in 500 Internal Server Error
Hi Warren, life can be so easy sometimes. Thanks :-) -- Cheers, Hans -Ursprüngliche Nachricht- Von: Warren Bell [mailto:warrenbe...@gmail.com] Gesendet: Donnerstag, 29. Januar 2015 05:53 An: users@wicket.apache.org Betreff: Re: Wicketstuff Restannotations AbortWithHttpErrorCodeException always results in 500 Internal Server Error Hans, I handle all exceptions and set status codes in my mapped method with AbstractRestResource#setResponseStatusCode(…). I don’t ever throw any exceptions from there. Setting a status code is the only thing that is really happening in AbstractRestResource#invokeMappedMethod(…) when an exception is caught anyway. Just spare the throwing of an exception and set the status code in your mapped method. throw new AbortWithHttpErrorCodeException(“500”, “Ouch”); versus setResponseStatusCode(“500”); Also, I believe AbortWithHttpErrorCodeException is part of Wicket core, not something meant to be used in rest-annotations. Hope this helps, Warren Bell On Jan 28, 2015, at 7:58 AM, Hans Lesmeister hans.lesmeis...@lessy-software.de wrote: Hi, We use the great rest-annotation from wicketstuff. One thing that bothers is if the AbortWithHttpErrorCodeException with a specific code (404, 402, etc) is thrown by the mapped method, those error codes do not make it to the calling client. The client always seems to get a 500. I debugged through the request/response and found this in AbstractRestResource: http://pastebin.com/NKNmNHv6 Is there any way of getting the correct error codes to the client? If not, how are other people handling this? I would be glad to invest some time and apply a patch if necessary -- Thanks and Cheers, Hans - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: 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 of
