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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
