Re: Wicket with some servlet container on Android?
Guten Tag Martin Grigorov, am Sonntag, 21. Juni 2015 um 23:09 schrieben Sie: Netty doesn't support server side http sessions[...] When running in Android there will be just one client so it could be simplified. Exactly, one might even argue that using a session as cache only for performance related things may be unnecessary as well, because there's no server with high load and local flash storage is getting faster as well and such. But I guess that wouldn't simply things much because Wicket simply relies on a session, right? @Thorsten: please tell me that i-jetty works fine and let me enjoy the summer :-) I would love to, I hope I can give it a try in the next two weeks. Thank you guys for the very interesting details! Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket with some servlet container on Android?
Hi Sven, On Sun, Jun 21, 2015 at 4:06 PM, Sven Meier s...@meiers.net wrote: Hi Martin, It shouldn't be hard to introduce some abstractions but Wicket is not quite ready for non-Servlet usage at the moment. yeah, time to improve that :). If anyone provided patches and/or pull requests to remove those dependencies, I'd be willing to support these changes. Do you see a big benefit in doing this? Except better abstractions than now and because we can. I might have time to work on this soon but I'll need a good technical reason to do it first. Regards Sven On 21.06.2015 13:49, Martin Grigorov wrote: Hi On Sun, Jun 21, 2015 at 1:06 PM, Sven Meier s...@meiers.net wrote: Hi, And why would that be interesting or preferable or whatever? because Wicket doesn't need servlets actually: Without the JEE baggage you can keep your App smaller. mean that the frontend needs adoption for both different environments All JEE related APIs are hidden behind Wicket specific classes and interfaces (e.g. WebResponse), so there should be nothing to adapt in the application itself. Few years ago I've tried to replace Servlet impl with one based on Netty. There are many places in Wicket core where we use/cast to Servlet APIs. For example Form.java does it. Some classes use Cookie. Some internal classes use event listeners (PageStoreManager.java). I've stopped working on due to lack of time and interest. It shouldn't be hard to introduce some abstractions but Wicket is not quite ready for non-Servlet usage at the moment. Martin Grigorov Freelancer. Available for hire! Wicket Training and Consulting https://twitter.com/mtgrigorov Have fun Sven On 21.06.2015 11:06, Thorsten Schöning wrote: Guten Tag Sven Meier, am Samstag, 20. Juni 2015 um 20:18 schrieben Sie: there seem to be different solutions already, why do you think they are not promising? https://github.com/jetty-project/i-jetty The commit history doesn't look very active to me and I've read that Tomcat and newer versions of Jetty rely on JMX, which shall be a no go on Android. On SO where some unanswered questions about Tomcat on Android as well. But I'm just at the start of my research and didn't try anything myself yet. Actually it would be interesting to just skip all servlet stuff and just use an HTTP server: https://github.com/NanoHttpd/nanohttpd And why would that be interesting or preferable or whatever? Besides the fact that it might be the only working solution at all, of course. ;-) I guess it might be faster and such, but would mean that the frontend needs adoption for both different environments, executing within a servlet container or not. That's exactly what I would like to avoid as much as possible. Mit freundlichen Grüßen, Thorsten Schöning - 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: Wicket with some servlet container on Android?
Hi Martin, It shouldn't be hard to introduce some abstractions but Wicket is not quite ready for non-Servlet usage at the moment. yeah, time to improve that :). If anyone provided patches and/or pull requests to remove those dependencies, I'd be willing to support these changes. Regards Sven On 21.06.2015 13:49, Martin Grigorov wrote: Hi On Sun, Jun 21, 2015 at 1:06 PM, Sven Meier s...@meiers.net wrote: Hi, And why would that be interesting or preferable or whatever? because Wicket doesn't need servlets actually: Without the JEE baggage you can keep your App smaller. mean that the frontend needs adoption for both different environments All JEE related APIs are hidden behind Wicket specific classes and interfaces (e.g. WebResponse), so there should be nothing to adapt in the application itself. Few years ago I've tried to replace Servlet impl with one based on Netty. There are many places in Wicket core where we use/cast to Servlet APIs. For example Form.java does it. Some classes use Cookie. Some internal classes use event listeners (PageStoreManager.java). I've stopped working on due to lack of time and interest. It shouldn't be hard to introduce some abstractions but Wicket is not quite ready for non-Servlet usage at the moment. Martin Grigorov Freelancer. Available for hire! Wicket Training and Consulting https://twitter.com/mtgrigorov Have fun Sven On 21.06.2015 11:06, Thorsten Schöning wrote: Guten Tag Sven Meier, am Samstag, 20. Juni 2015 um 20:18 schrieben Sie: there seem to be different solutions already, why do you think they are not promising? https://github.com/jetty-project/i-jetty The commit history doesn't look very active to me and I've read that Tomcat and newer versions of Jetty rely on JMX, which shall be a no go on Android. On SO where some unanswered questions about Tomcat on Android as well. But I'm just at the start of my research and didn't try anything myself yet. Actually it would be interesting to just skip all servlet stuff and just use an HTTP server: https://github.com/NanoHttpd/nanohttpd And why would that be interesting or preferable or whatever? Besides the fact that it might be the only working solution at all, of course. ;-) I guess it might be faster and such, but would mean that the frontend needs adoption for both different environments, executing within a servlet container or not. That's exactly what I would like to avoid as much as possible. Mit freundlichen Grüßen, Thorsten Schöning - 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: Wicket with some servlet container on Android?
Hi On Sun, Jun 21, 2015 at 1:06 PM, Sven Meier s...@meiers.net wrote: Hi, And why would that be interesting or preferable or whatever? because Wicket doesn't need servlets actually: Without the JEE baggage you can keep your App smaller. mean that the frontend needs adoption for both different environments All JEE related APIs are hidden behind Wicket specific classes and interfaces (e.g. WebResponse), so there should be nothing to adapt in the application itself. Few years ago I've tried to replace Servlet impl with one based on Netty. There are many places in Wicket core where we use/cast to Servlet APIs. For example Form.java does it. Some classes use Cookie. Some internal classes use event listeners (PageStoreManager.java). I've stopped working on due to lack of time and interest. It shouldn't be hard to introduce some abstractions but Wicket is not quite ready for non-Servlet usage at the moment. Martin Grigorov Freelancer. Available for hire! Wicket Training and Consulting https://twitter.com/mtgrigorov Have fun Sven On 21.06.2015 11:06, Thorsten Schöning wrote: Guten Tag Sven Meier, am Samstag, 20. Juni 2015 um 20:18 schrieben Sie: there seem to be different solutions already, why do you think they are not promising? https://github.com/jetty-project/i-jetty The commit history doesn't look very active to me and I've read that Tomcat and newer versions of Jetty rely on JMX, which shall be a no go on Android. On SO where some unanswered questions about Tomcat on Android as well. But I'm just at the start of my research and didn't try anything myself yet. Actually it would be interesting to just skip all servlet stuff and just use an HTTP server: https://github.com/NanoHttpd/nanohttpd And why would that be interesting or preferable or whatever? Besides the fact that it might be the only working solution at all, of course. ;-) I guess it might be faster and such, but would mean that the frontend needs adoption for both different environments, executing within a servlet container or not. That's exactly what I would like to avoid as much as possible. Mit freundlichen Grüßen, Thorsten Schöning - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket with some servlet container on Android?
Hi, AFAICS i-jetty is the most promising one. But Netty project claims to support Android as an environment! [1], [2]. Netty doesn't support server side http sessions, so we should either implement custom ISessionStore ourselves (Apache CFX already has such impl, using Servlet APIs [3]) or use something like Hazelcast, Redis or Memcached. When running in Android there will be just one client so it could be simplified. @Thorsten: please tell me that i-jetty works fine and let me enjoy the summer :-) 1. http://netty.io/wiki/new-and-noteworthy-in-4.1.html 2. https://github.com/netty/netty/issues/2330 3. http://grepcode.com/file/repo1.maven.org/maven2/org.apache.cxf/cxf-rt-transports-http-netty-server/3.0.0/org/apache/cxf/transport/http/netty/server/servlet/NettyHttpSession.java#NettyHttpSession Martin Grigorov Freelancer. Available for hire! Wicket Training and Consulting https://twitter.com/mtgrigorov On Sun, Jun 21, 2015 at 11:24 PM, Sven Meier s...@meiers.net wrote: Hi Martin, if there's a workable servlet container for Android, I'd just use that. Except because we can I have to admit, that's the main reason for my suggestion :P. Have fun Sven On 21.06.2015 15:19, Martin Grigorov wrote: Hi Sven, On Sun, Jun 21, 2015 at 4:06 PM, Sven Meier s...@meiers.net wrote: Hi Martin, It shouldn't be hard to introduce some abstractions but Wicket is not quite ready for non-Servlet usage at the moment. yeah, time to improve that :). If anyone provided patches and/or pull requests to remove those dependencies, I'd be willing to support these changes. Do you see a big benefit in doing this? Except better abstractions than now and because we can. I might have time to work on this soon but I'll need a good technical reason to do it first. Regards Sven On 21.06.2015 13:49, Martin Grigorov wrote: Hi On Sun, Jun 21, 2015 at 1:06 PM, Sven Meier s...@meiers.net wrote: Hi, And why would that be interesting or preferable or whatever? because Wicket doesn't need servlets actually: Without the JEE baggage you can keep your App smaller. mean that the frontend needs adoption for both different environments All JEE related APIs are hidden behind Wicket specific classes and interfaces (e.g. WebResponse), so there should be nothing to adapt in the application itself. Few years ago I've tried to replace Servlet impl with one based on Netty. There are many places in Wicket core where we use/cast to Servlet APIs. For example Form.java does it. Some classes use Cookie. Some internal classes use event listeners (PageStoreManager.java). I've stopped working on due to lack of time and interest. It shouldn't be hard to introduce some abstractions but Wicket is not quite ready for non-Servlet usage at the moment. Martin Grigorov Freelancer. Available for hire! Wicket Training and Consulting https://twitter.com/mtgrigorov Have fun Sven On 21.06.2015 11:06, Thorsten Schöning wrote: Guten Tag Sven Meier, am Samstag, 20. Juni 2015 um 20:18 schrieben Sie: there seem to be different solutions already, why do you think they are not promising? https://github.com/jetty-project/i-jetty The commit history doesn't look very active to me and I've read that Tomcat and newer versions of Jetty rely on JMX, which shall be a no go on Android. On SO where some unanswered questions about Tomcat on Android as well. But I'm just at the start of my research and didn't try anything myself yet. Actually it would be interesting to just skip all servlet stuff and just use an HTTP server: https://github.com/NanoHttpd/nanohttpd And why would that be interesting or preferable or whatever? Besides the fact that it might be the only working solution at all, of course. ;-) I guess it might be faster and such, but would mean that the frontend needs adoption for both different environments, executing within a servlet container or not. That's exactly what I would like to avoid as much as possible. Mit freundlichen Grüßen, Thorsten Schöning - 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: Wicket with some servlet container on Android?
Hi Martin, if there's a workable servlet container for Android, I'd just use that. Except because we can I have to admit, that's the main reason for my suggestion :P. Have fun Sven On 21.06.2015 15:19, Martin Grigorov wrote: Hi Sven, On Sun, Jun 21, 2015 at 4:06 PM, Sven Meier s...@meiers.net wrote: Hi Martin, It shouldn't be hard to introduce some abstractions but Wicket is not quite ready for non-Servlet usage at the moment. yeah, time to improve that :). If anyone provided patches and/or pull requests to remove those dependencies, I'd be willing to support these changes. Do you see a big benefit in doing this? Except better abstractions than now and because we can. I might have time to work on this soon but I'll need a good technical reason to do it first. Regards Sven On 21.06.2015 13:49, Martin Grigorov wrote: Hi On Sun, Jun 21, 2015 at 1:06 PM, Sven Meier s...@meiers.net wrote: Hi, And why would that be interesting or preferable or whatever? because Wicket doesn't need servlets actually: Without the JEE baggage you can keep your App smaller. mean that the frontend needs adoption for both different environments All JEE related APIs are hidden behind Wicket specific classes and interfaces (e.g. WebResponse), so there should be nothing to adapt in the application itself. Few years ago I've tried to replace Servlet impl with one based on Netty. There are many places in Wicket core where we use/cast to Servlet APIs. For example Form.java does it. Some classes use Cookie. Some internal classes use event listeners (PageStoreManager.java). I've stopped working on due to lack of time and interest. It shouldn't be hard to introduce some abstractions but Wicket is not quite ready for non-Servlet usage at the moment. Martin Grigorov Freelancer. Available for hire! Wicket Training and Consulting https://twitter.com/mtgrigorov Have fun Sven On 21.06.2015 11:06, Thorsten Schöning wrote: Guten Tag Sven Meier, am Samstag, 20. Juni 2015 um 20:18 schrieben Sie: there seem to be different solutions already, why do you think they are not promising? https://github.com/jetty-project/i-jetty The commit history doesn't look very active to me and I've read that Tomcat and newer versions of Jetty rely on JMX, which shall be a no go on Android. On SO where some unanswered questions about Tomcat on Android as well. But I'm just at the start of my research and didn't try anything myself yet. Actually it would be interesting to just skip all servlet stuff and just use an HTTP server: https://github.com/NanoHttpd/nanohttpd And why would that be interesting or preferable or whatever? Besides the fact that it might be the only working solution at all, of course. ;-) I guess it might be faster and such, but would mean that the frontend needs adoption for both different environments, executing within a servlet container or not. That's exactly what I would like to avoid as much as possible. Mit freundlichen Grüßen, Thorsten Schöning - 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: Wicket with some servlet container on Android?
Guten Tag Sven Meier, am Samstag, 20. Juni 2015 um 20:18 schrieben Sie: there seem to be different solutions already, why do you think they are not promising? https://github.com/jetty-project/i-jetty The commit history doesn't look very active to me and I've read that Tomcat and newer versions of Jetty rely on JMX, which shall be a no go on Android. On SO where some unanswered questions about Tomcat on Android as well. But I'm just at the start of my research and didn't try anything myself yet. Actually it would be interesting to just skip all servlet stuff and just use an HTTP server: https://github.com/NanoHttpd/nanohttpd And why would that be interesting or preferable or whatever? Besides the fact that it might be the only working solution at all, of course. ;-) I guess it might be faster and such, but would mean that the frontend needs adoption for both different environments, executing within a servlet container or not. That's exactly what I would like to avoid as much as possible. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket with some servlet container on Android?
Hi, And why would that be interesting or preferable or whatever? because Wicket doesn't need servlets actually: Without the JEE baggage you can keep your App smaller. mean that the frontend needs adoption for both different environments All JEE related APIs are hidden behind Wicket specific classes and interfaces (e.g. WebResponse), so there should be nothing to adapt in the application itself. Have fun Sven On 21.06.2015 11:06, Thorsten Schöning wrote: Guten Tag Sven Meier, am Samstag, 20. Juni 2015 um 20:18 schrieben Sie: there seem to be different solutions already, why do you think they are not promising? https://github.com/jetty-project/i-jetty The commit history doesn't look very active to me and I've read that Tomcat and newer versions of Jetty rely on JMX, which shall be a no go on Android. On SO where some unanswered questions about Tomcat on Android as well. But I'm just at the start of my research and didn't try anything myself yet. Actually it would be interesting to just skip all servlet stuff and just use an HTTP server: https://github.com/NanoHttpd/nanohttpd And why would that be interesting or preferable or whatever? Besides the fact that it might be the only working solution at all, of course. ;-) I guess it might be faster and such, but would mean that the frontend needs adoption for both different environments, executing within a servlet container or not. That's exactly what I would like to avoid as much as possible. Mit freundlichen Grüßen, Thorsten Schöning - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket with some servlet container on Android?
Hi, I've found some posts about Jetty and Tomcat regarding this, which don't look very promising. there seem to be different solutions already, why do you think they are not promising? https://github.com/jetty-project/i-jetty Actually it would be interesting to just skip all servlet stuff and just use an HTTP server: https://github.com/NanoHttpd/nanohttpd An extension could close the gap between HTTP and Wicket's request and response classes, skipping WicketFilter alltogether. Have fun Sven On 20.06.2015 10:30, Thorsten Schöning wrote: Hi all, we have a web app based on Wicket, Tomcat 7 etc. and one of our customers has a native Windows only app which is about to be replaced now to 1. support Android as well, 2. add some missing features and 3. provide some more modern GUI and such. The two most interesting things for that replacement from my point of view are that the new app needs to be able to work totally offline and that its current and some of the new features contains things the customer already asked for the Wicket-web app we've created as well. Working offline is a hard requirement, so we can't just use the Wicket web app as it is. But because features are clearly overlapping we don't want to maintain a very comparable feature set with two different technologies for years to come. Our customer totally agrees with that and sees the functional overlapping as well. So, is there already any experience or suggestions about or down votes of an approach were one would embed some servlet container in an Android app and provide the frontend using Wicket, HTML, JS and CSS? This shouldn't be too much of a problem with Windows desktops, but a completely different thing for Android. I've found some posts about Jetty and Tomcat regarding this, which don't look very promising. But how about Wicket itself? Maybe someone already tried or knows it's impossible because of the Android API or Dalvik or such. Any thoughts welcome, thanks! Mit freundlichen Grüßen, Thorsten Schöning - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
