Re: [jetty-users] Jetty 12: org.eclipse.jetty.http.MultiPart.Part does n

[Jan Bartel <janb@xxxxxxxxxxx>]

Glen,

Being able to configure Jetty in code, and using the core or servlet apis are orthogonal issues. You can do either. You can look at any of the hundreds of unit tests that we have to see examples of both programmatically configuring jetty with core api only, or also using one of the eeX servlet apis.

You would need to provide more information on the error message you received, and the nature of your `MyHandler` to receive any further diagnosis.

regards

Jan

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

--

Jan Bartel <janb@xxxxxxxxxxx>

www.webtide.com
Expert assistance from the creators of Jetty and CometD