Hello
I'm thinking about some differences between servers Pax Web supports
(Jetty, Tomcat, Undertow). I always knew that actual server starts (opens
its listener(s)) only after first "context" is added (first servlet is
registered for example).
However when last servlet/context/webapp/whiteboard element is removed,
server (at least jetty) still listens on its ports... I know we all got
used to it, but maybe we should start EMPTY server initially? Jetty allows
adding e.g., org.eclipse.jetty.servlet.ServletContextHandlers to running
server and I think all containers can do it since the dawn of time.
The other thing is that I see multiplication of interfaces having methods
like "start()", "stop()", "registerXXX()", "addXXX()":
- org.ops4j.pax.web.service.WebContainer#registerServlet()
- org.ops4j.pax.web.service.internal.HttpServiceProxy#registerServlet()
-
org.ops4j.pax.web.service.internal.HttpServiceStarted#registerServlet()
- org.ops4j.pax.web.service.spi.ServerController#addServlet()
-
org.ops4j.pax.web.service.jetty.internal.ServerControllerImpl.State#addServlet()
- org.ops4j.pax.web.service.jetty.internal.JettyServer#addServlet()
Generally there are these abstractions:
- OSGi HttpService itself
- server-agnostic state hidden behind proxy (started, stopped)
- server-specific ServerController
- server-specific state (started, stopped)
- server-specific server abstraction (e.g.,
org.ops4j.pax.web.service.jetty.internal.JettyServer)
- server-specific wrapper (e.g.,
org.ops4j.pax.web.service.jetty.internal.JettyServerWrapper)
- actual server (e.g., org.eclipse.jetty.server.Server)
Orthogonally we have server-agnostic "model" of
server/service/context/servlet/... (SPI packages).
I see there are cases where we had to do some tricks to pass things like
"configuration" or "model" down the abstraction layers of the Http
Service... I'd at least like it to be consistent - for example I don't deny
the fact that there are two kinds of "states":
- "state" of bundle-scoped OSGi HttpService (ready, closed)
- "state" of the actual server itself (unconfigured, configured, started,
stopped)
I think however that some interfaces for the server-specific "states" could
be common...
I've also already added integration tests in module "pax-web-itest-osgi"
which show how to used pax web *without actual server implementation* - the
purpose is to test server-agnostic mechanisms like state and configuration.
Why do I write about this?
- PAXWEB-1235 - ErrorPageServlet registered twice
- PAXWEB-1210 - Websocket registration does not work with Undertow
container
- PAXWEB-1124 - Http Whiteboard: Resolution of ServletContextHelper
- PAXWEB-1123 - Http Whiteboard and selection of the ServletContextHelper
- PAXWEB-1121 - NPe when accessing a Servlet while the responsible bundle
starts
- PAXWEB-1077 - ServletContext becomes unavailable on restart when using
Whiteboard and CustomContexts
- PAXWEB-968 - WebApplication gets removed when mapped servlet is
unregistered
- PAXWEB-934 - Creation of Dynamic Connectors doesn't work as expected
- PAXWEB-819 - Make it easier to control the HttpContext of servlets
registered on the whiteboard
- (mailing list) - org.ops4j.lang.NullArgumentException: Context model is
null
All the above issues are related to some fundamental lifecycle issues and
sometimes some processes are bent when progressing over the abstraction
layers... And now there's R7 to implement...
I don't expect answers, it's just kind of summary email.
regards
Grzegorz Grzybek
--
--
------------------
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
---
You received this message because you are subscribed to the Google Groups
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ops4j+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ops4j/CAAdXmhqe82ARMzHsSen%2B3a6nA1V40Yz9yCoeFr4TYEf8c8kCag%40mail.gmail.com.
