Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Jetty 12: org.eclipse.jetty.http.MultiPart.Part does not extend Servlet 6 jakarta.servlet.http.Part
Is there a servlet 6 version of HTTP2ServerConnectionFactory, ALPNServerConnectionFactory, SslConnectionFactory?  This is the Jetty HTTP2 configuration I was hoping to use with a jakarta.servlet.http.HttpServlet:

    val server = Server()
    server.isDumpAfterStart = true
    server.setAttribute("module", "session-cache-hash")
    server.errorHandler = HoshinErrorHandler

    // https://github.com/fstab/http2-examples/blob/master/jetty-http2-server-example/src/main/java/de/consol/labs/h2c/examples/server/Http2Server.java
    // HTTP/2 Connection Factory
    val h2 = HTTP2ServerConnectionFactory(httpConfig)
    val alpn = ALPNServerConnectionFactory()

    // SSL Connection Factory
    val ssl = SslConnectionFactory(sslContextFactory, alpn.protocol)

    // HTTP/2 Connector
    val http2Connector = ServerConnector(server, ssl, alpn, h2, HttpConnectionFactory(httpConfig))
    http2Connector.port = 8443
    server.addConnector(http2Connector)

    val handlers = ContextHandlerCollection()
    handlers.addHandler(SecuredRedirectHandler())
    handlers.addHandler(HoshinHandler)
    server.handler = handlers

    server.start()

On Sun, Oct 13, 2024 at 8:31 PM Greg Wilkins <gregw@xxxxxxxxxxx> wrote:

Glen,

You can use jetty in many different ways:
  • core jetty configured in java programmatically using jetty APIs for app and configuration
  • core jetty configured in jetty XML using jetty APIs for app and configuration
  • servlet APIs for the application configured java programmatically (See various ServletHandler and/or ServletContextHandler classes)
  • servlet APIs for the application configured with a mix of java programmatically and standard xml ( see various WebAppContext classes)
  • servlet APIs for the application configured with jetty xml (See various ServletHandler and/or ServletContextHandler classes)
  • servlet APIs for the application configured with a mix of jetty xml and standard xml ( see various WebAppContext classes)
 
You don't need to write your own custom wrappers of core request to servlet request.   We have wrappers bothways (if you just want minimal API, but not the actual servlet behaviours) or use a ServletHandler if you want both the servlet API and the servlet behaviours.    All can be configured programmatically.

cheers



On Sat, 12 Oct 2024 at 02:41, Glen Peterson via jetty-users <jetty-users@xxxxxxxxxxx> wrote:
Huh.  Can I still get code-based configuration and use the Servlet HttpRequest/Response?  I think not?

val handlers = ContextHandlerCollection()
handlers.addHandler(SecuredRedirectHandler())
handlers.addHandler(MyHandler) // <== ERROR
server.handler = handlers

I guess I could write my own jetty.Request -> servlet.HttpRequest wrapper?

On Fri, Oct 11, 2024 at 11:20 AM Glen Peterson <glen.k.peterson@xxxxxxxxx> wrote:
Thank you, that's very helpful!

I was just skimming the JSP spec about XML configuration.  Ugh.  Those were not the "good old days".

I love configuring Jetty in Java (Kotlin actually) and don't want that to go away.  It's great to have just the one language (two with legacy Java), treat configuration as code, and get feedback from my IDE about what's going to work with a new version.  I know XML schemas are supposed to allow that in theory.  In practice, Java/Kotlin's type system provides tighter and more appropriate controls.

In terms of the Servlet spec, I just have some tools that expect HttpRequest/Response and related things like Part.  Those 2 interfaces and a few supporting ones are the only ones I want to stick with the Servlet spec for.  It makes me feel like I could port my code to another web server.  Like no lock-in.  I say that, even though I might use something like AWS lambdas to handle requests if I were to ever move away from Jetty.  It might be that cozy feeling Simone referred to and not a strong intellectual reason.  IDK.

On Fri, Oct 11, 2024 at 10:36 AM Joakim Erdfelt <joakim.erdfelt@xxxxxxxxx> wrote:
Jetty isn't handling the spec in any different way.

Servlet is just an API.
The Servlet API, in Jetty, is implemented on top of the Jetty internal features.

It just happens that the Servlet spec handling for `multipart/form-data` is a simple blocking API.
The Jetty implementation is fully 100% async.

The features you were using are Jetty core API (namely the org.eclipse.jetty.http.MultiPart.Part and MultiPartFormData classes), but you were not using the Servlet API when you were using those classes.

If you want a simple API, use the Servlet spec.
If you want a performant API, use Jetty.
If you want a flexible API, use a 3rd party library on top of the Servlet spec (like commons-fileupload, or commons-mime), which doesn't use the Servlet spec handling of multipart/form-data, but does the reading / parsing itself using the Servlet inputstream (in some cases even using the Servlet AsyncContext).

- Joakim

On Fri, Oct 11, 2024 at 9:10 AM Glen Peterson via jetty-users <jetty-users@xxxxxxxxxxx> wrote:
If Jakarta Servlet 6 (and presumably future versions) and Jetty are Eclipse Foundation technologies and some of the same members work on the Servlet Spec and on Jetty, why is Jetty doing something different from the spec?  If there's a need for change, shouldn't the spec be changed to meet that need too?

_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users


--

Back to the top