On Thu, 10 Nov 2022 at 12:29, Cantor, Scott wrote:
> >The proper way is to use the request / response objects as passed to
> > you, and not hold onto them.
>
> That would imply that one has to immediate extract every possible bit from
> them and construct a new façade for the data before
>The assumption that you'll be passed a HttpServletRequest and/or
> HttpServletResponse to these actions isn't 100% true.
Ok, I can see that.
>Take for example the Async I/O events.
Which we will never, ever call/use/allow.
>There are similar things elsewhere in the spec.
Most of
> Is it fair to assume that the only way a request could possibly cross
threads like that is if there's also an actually explicit entry point into
one's application logic by which the container is actually invoking a
standard interface that is defined to accept the
HttpServletRequest/Response?
>It's a general anti-pattern to hold onto, use, reference a
> HttpServletRequest or HttpServletResponse object outside of the
> dispatch from the container.
One more question about this I guess...
Is it fair to assume that the only way a request could possibly cross threads
like
>It's a general anti-pattern to hold onto, use, reference a
> HttpServletRequest or HttpServletResponse object outside of the
> dispatch from the container.
Unfortunately it's likely to be borderline impossible for us to avoid it in any
practical way given the layering involved, but we will
> Our undersatanding has been that a given request is still thread-locked
from start to finish even though there are changes to the model in how
requests are dispatched, as long as one didn't call out to some kind of
asynchronous API or something that could suspend the processing of the
request.
Note that our understanding of the SingleThreadedModel is NOT that it changes
how a given request is handled, just that it means a servlet is forced to allow
for multiple requests at once.
That is not an issue for our code, we're fully thread-safe/aware and that
doesn't break thread-local
>You cannot use thread-local reliably starting in Jakarta Servlet 5.
Our undersatanding has been that a given request is still thread-locked from
start to finish even though there are changes to the model in how requests are
dispatched, as long as one didn't call out to some kind of
> The only practical way to inject the per-request interfaces into various
objects is to use thread-local storage to capture and stash the current
Servlet request/response and then inject a façade that pulls the
thread-local copy out and delegates the method calls to it.
Jakarta Servlet 5
>The best advice I can offer is that your Servlet 5 facade should not
> implement a facade for any API that is deprecated.
Our early attempts at that failed, but we're not done bottoming out what we
might be able to get to work. I appreciate the suggestions, though. We really
weren't after
>Scott, I'm not understanding how your facades work or why exactly
> they are needed? Can you give some examples?
We have a deeply modular Spring-based system, where beans very "high" up need
access to request/response state. The only practical way to inject the
per-request interfaces into
> There are, though, two incompatible jakarta-namespaced APIs, Servlet 5
and 6. That's where we're having issues because we implement facades for
the APIs that can't load on both at once.
>
> We can implement separate ones for 5 and 6 (and thus Jetty 11 and 12)
but we're not sure how we'll manage
Scott,
I'm not understanding how your facades work or why exactly they are
needed? Can you give some examples?
Why can you not just deploy old javax.* code to one context and new
jakarta.* code to a different one.
cheers
On Thu, 10 Nov 2022 at 07:58, Cantor, Scott wrote:
> >jetty-12 is
>jetty-12 is dependent on neither namespace, but can deploy contexts
> that are dependent on javax.* or jakarta.*
There are, though, two incompatible jakarta-namespaced APIs, Servlet 5 and 6.
That's where we're having issues because we implement facades for the APIs that
can't load on both
On Thu, 10 Nov 2022 at 07:08, Cantor, Scott wrote:
>
> I'm refering specifically to the fact that Servlet 5.0 and 6.0, in the
> Jakarta namespace, are not compatible because they've removed some
> deprecated methods and interfaces and added others. Implementing both in
> some system is
>If you are asking about supporting jakarta. * servlets, that is Jetty 11.
Nope. That was our plan but we have facades that implement the servlet
interfaces by delegating to the container's, and that doesn't work because...
> Jetty 12 will support multiple servlet versions.
I'm refering
If you are asking about supporting jakarta.* servlets, that is Jetty 11.
Jetty 12 will support multiple servlet versions.
cheers,
Jesse
--
jesse mcconnell
jesse.mcconn...@gmail.com
On Wed, Nov 9, 2022 at 2:00 PM Joakim Erdfelt wrote:
> Jetty 12 already has Alpha quality releases out that you
Jetty 12 already has Alpha quality releases out that you can use to start
experimenting with.
We should be going to Betas (or Release candidates) in the next few weeks.
Joakim Erdfelt / joa...@webtide.com
On Wed, Nov 9, 2022 at 12:30 PM Cantor, Scott wrote:
> Please forgive this, as I
Please forgive this, as I despise "when's it done?" questions, but we just
realized there are breaking changes in Servlet 6 vs 5 and we have expsoure to
that so it's starting to become a possibility we'll have to move to 6 or do a
lot of ugly stuff.
Given Tomcat's already moved, we're just
19 matches
Mail list logo
