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]
