Hi Grzegorz,
I struggeled with that long time ago also and it was the reason to move
away from pax-web and using the directly the jetty-OSGI-integration
directly, from my point of view, pax-web is to much centric about
"internal convers" aka making it work for the white-boardextender, but
from a users (or mayb its just me?) perspektive its overhelwing complex
and fragile to use.
Ia fully agree with you that service-lifecycle should clearly be
separated from server life-cycle, but not sure about "only open port
when one context is available" as the OSGi-Spec has a default context
that (imo) should always be available.
If I rember right especially that Context-Handling of pax-web is a
little bit confing the "Server-Context" and the "Osgi-HttpContext" when
I last talked to the jetty-guys.
To summarize: if you use ONLY the white-board extender and do not
restart/reload, most things work acceptable, if you start trying to use
(or even interact) with different modules the night-mare begins.
Am 31.01.20 um 09:30 schrieb Grzegorz Grzybek:
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
