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
>
>

Reply via email to