> Opened new Issue to update setuid -
> https://github.com/eclipse/jetty.project/issues/10279
Muchos gracias if it's not a big lift.
-- Scott
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit
> It was never updated for Jetty 10/11, doesn't work with Jetty 10/11
> properly, and we've had zero complaints about that too.
It works fine for me with 10 and 11, at least it seems to. Since it has
continued to ship with the software, there was no reason for me to ever ask
about it being
Before I spend too much time debugging, is the setuid module still
supported/intended to work in 12?
I can't find the source so far, though the module/jar's there, but the startup
throws a ClassNotFound on something making me think the jar is not ported up:
13:21:43.860 - WARN
> Can you share the mod + xml's that shibboleth uses? Is it this one?
More or less, I'm sure, we have various examples on different Jetty versions
but they all do the same things.
> Perhaps we can make this error more clear/meaningful? Like pointing
> out the paths of the KeyStore that failed
> Im not using dry-run but the JVM does get forked.
I'd suggest verifying that it's not showing up in some manipulated form as a
property on the command line of the child process. Just to be sure.
-- Scott
___
jetty-users mailing list
It's pretty likely that your startup approach is mucking with the password.
From my own experience, using --dry-run for example botched the "escaping" of
the settings that get extracted and passed to the new process command as of a
recent 10.x patch, something I raised in github.
I don't know
I reviewed that newer issue...
It could be that your xargs solution is actually stripping back out the quotes,
but if that's the case, it seems suboptimal that they're there in the first
place. If nothing else maybe having an option not to do this (i.e., "I don't
use crazy properties, so
> What specific OS are you using?
CentOS 7.
I can only infer that the problem is with the quoted property names. Possibly
if the values along were quoted that might still work, but everything I'm
seeing suggests that when the code goes to look for property foo, it's not
seeing 'foo'. The
I think this commit between 10.0.14 and 10.0.15 is breaking my init script,
which I know is quite non-optimal, but for debugging purposes...could I ask
what the purpose of [1] is and what its functional impact is supposed to be?
What I think is happening is that it's single-quoting all my
On 11/10/22, 5:45 PM, "jetty-users on behalf of Greg Wilkins"
wrote:
>To my knowledge that cannot happen at least not with normal
> threads. Perhaps in future with virtual threads, then threadlocals might
> be more of a problem, but their usage will be optional in Jetty.
Virtual
>Problems start to occur when a request/response is wrapped in
> another object that abstracts away from the request response paradigm
> and just looks like some dataful object (which just happens to be backed
> by data a request). Such objects can easily be put into persistent data
>
>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
>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
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 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
>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
>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
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
On 12/22/21, 3:02 PM, "jetty-users on behalf of Joakim Erdfelt"
wrote:
>Our usage is slf4j-api, but we internally don't use the slf4j-api 2.0
> specific API features.
>That means you can manually downgrade to slf4j-api 1.x if you so desire,
> and use that old implementation,
> across
Is there a particular reason why Jetty 10 is including non-production versions
of logging libraries? Needless to say, that's a bit offputting in light of
recent events.
I realize it doesn't preclude applications using the stable versions, but I
imagine the actual Jetty support for slf4j is
On 10/14/21, 10:03 AM, "Padraic Renaghan via jetty-users"
wrote:
>So is the normal setup with Apache using an add-on for SAML SSO, any
>recommendations on which are best?
I don't really pretend to claim "normal", I'm just opinionated, and inherently
biased because I wrote a good
On 10/13/21, 6:00 PM, "jetty-users on behalf of Padraic Renaghan via
jetty-users" wrote:
>Anyway, looking for pointers on setting up SAML SSO Single Sign-On with
>Jetty.
The best option is Apache in front because that allows the use of more
compliant and properly designed SAML SPs.
On 10/29/20, 4:54 PM, "jetty-users-boun...@eclipse.org on behalf of Joakim
Erdfelt"
wrote:
>Your Example 2:
>If-Match: W/"ab3>5ef1bc78", W/"5be73a9c523"
>
> This is a field of name "If-Match".
> It has 2 values, both of which are in violation of the spec.
On 10/29/20, 3:14 PM, "jetty-users-boun...@eclipse.org on behalf of Nils
Kilden-Pedersen" wrote:
>I disagree. The quotes are part of the value and are significant.
I agree.
I was curious about this and followed the thread because I make use of the
etags feature in the DefaultServlet. It
On 5/26/20, 4:34 PM, "jetty-users-boun...@eclipse.org on behalf of David C
Fuhs" wrote:
> What I really want is quite simple: a series of commands that will take as
> input a private key, a new SSL certificate, and a
> series of intermediate/CA certificates and create a PKCS12 keystore that
>
> thanks for this heads up. 26 did include a fix for a TLS timeout issue in
> https://github.com/eclipse/jetty.project/pull/4446
Yes, that's really one of only two obviously implicated commits I saw in the
diff. I don't have the insight to gauge whether either of them could have
plugged a
This is more of an FYI, but I thought it was worth pointing out. I've observed
a pretty massive native memory leak in 9.4.x since a fairly early version of
that branch. This is running natively, exclusively HTTPS, directly exposed to
clients, and it leaked a native buffer somewhere frequently
30 matches
Mail list logo
