This is correct, onWebSocketClose will always be called.
This may be called for various reasons though
1. a close frame is received but one has not been sent you may send a close
frame from this method.
2. otherwise you may have already initiated the close handshake and you are
receiving the
seeing connection failed. Do I need
> to add websocket-jetty related configuration in jetty.xml configuration
> file?
>
>
>
> Can some please share a snippet of the configuration to be added ?
>
>
>
> Thanks,
>
> Yash Sharma
>
>
>
> *From:* Lachlan Roberts
&
These two lines do exactly the same thing btw, so might want to remove one
factory.register(MySocket.class);
factory.addMapping("/", (req,res)->new MySocket());
Can you look at the HTTP response to the websocket upgrade request.
You also can enable Jetty debug logging for websocket and see
Hi James,
The `OnWebSocketClose` will always be called for a WebSocket connection.
However there are two reasons could be called and this determines whether
`OnWebSocketError` is called before or after `OnWebSocketClose`.
1. You have just received a CLOSE frame and may now send a close response
t; onWebSocketText
> onWebSocketBinary
> onWebSocketClose
> onWebSocketError
>
> but not
>
> onWebSocketPartialText
>
>
>
> On 14-08-2023 09:10, Lachlan Roberts wrote:
>
> Silvio,
>
> Are you overriding both onWebSocketText and onWebSocketPartialText from the
>
Silvio,
Are you overriding both onWebSocketText and onWebSocketPartialText from the
Session.Listener?
These cannot be used together for a particular message type (TEXT/BINARY).
cheers,
Lachlan
On Fri, Aug 11, 2023 at 7:15 PM Silvio Bierman via jetty-users <
jetty-users@eclipse.org> wrote:
>
Hi,
I suggest reading the javadoc for CustomRequestLog.
https://eclipse.dev/jetty/javadoc/jetty-11/org/eclipse/jetty/server/CustomRequestLog.html
You can customize the logs generated by the request log with the format
string supplied in the constructor.
The extended NCSA format is the string
:
> Thanks for that information, any idea how to list all connections (and
> count them)?
>
> Vào Th 4, 12 thg 10, 2022 vào lúc 10:50 Lachlan Roberts <
> lach...@webtide.com> đã viết:
>
>> You should be able to use sendError(-1) which will immediately abor
You should be able to use sendError(-1) which will immediately abort the
HttpChannel and close the connection/stream.
see
https://www.eclipse.org/jetty/javadoc/jetty-10/org/eclipse/jetty/server/Response.html#sendError(int,java.lang.String)
On Wed, Oct 12, 2022 at 12:13 PM Dung Nguyen wrote:
>
I think there should be a getConfiguration() method on the WebSocketUpgrade
handler, but it looks like it is missing.
You can also set configuration like IdleTimeout from the
WebSocketNegotiator, or from the CoreSession once the websocket connection
is opened.
```
ore application in
> the meantime I may decide to add the ApproveAliases and move to 10.0.7.
> Anyway I will be looking forward to 10.0.8.
>
> Thanks for the help,
>
> Kind regards,
>
> Silvio
>
>
> On 11/29/21 03:02, Lachlan Roberts wrote:
>
> Silvio,
>
>
mbolic links in paths to be transparent to the
> application.
>
> Kind regards,
>
> Silvio
>
>
> On 11/29/21 00:53, Lachlan Roberts wrote:
>
> Hi Silvio,
>
> Do you have any symlink in the path to these static resources? If so, this
> could be related to the AliasChe
Hi Silvio,
Do you have any symlink in the path to these static resources? If so, this
could be related to the AliasChecker changes. You can test if this is
related to the AliasCheckers by adding the `ContextHandler.ApproveAliases`
to the `ContextHandler` and see if you still get the 404's. But
Hi,
You can configure the WebSocketContainer with the Jetty HttpClient which
you can set the CookieStore on.
see
https://www.eclipse.org/jetty/documentation/jetty-10/programming-guide/index.html#pg-client-http-cookie
You can use the static method
Alexander,
You should only need to change your line with `JSON.toString(root)` to `new
JSON().toJSON(root)`.
As for the deprecated header() method, it says in the javadoc to use the
`headers(Consumer)` method instead.
So would look something like this:
HttpClient httpClient = new HttpClient();
,
Lachlan
On Mon, May 3, 2021 at 11:50 AM Aniruddha Tekade via jetty-users <
jetty-users@eclipse.org> wrote:
> Hi Lachlan,
>
> Would this replace previous handlers from the server?
>
> Best,
> Aniruddha
>
>
> ᐧ
>
> On Sun, May 2, 2021 at 6:47 PM L
Aniruddha,
You should not be setting the ServletContextHandler as the handler for the
server, but instead just add it to the ContextHandlerCollection.
Try replacing the line
server.setHandler(ctx); with
contexts.addHandler(ctx);
Cheers,
Lachlan
On Mon, May 3, 2021 at 9:22 AM Aniruddha Tekade
p code. All non-websocket related tests have been successful
> so I expect we will start migrating to Jetty 10 shortly.
>
> Thank you very much again!
>
> Kind regards,
>
> Silvio
>
> On 3/17/21 1:42 AM, Lachlan Roberts wrote:
> > JettyWebSocketServletConta
Hi Silvio,
You do not need to start any of the components manually or call
ensureContainer.
The `JettyWebSocketServletContainerIntializer` is what sets up the various
websocket components for Jetty to use.
If you are using the jetty-home you can enable the Jetty WebSocket module:
$ java -jar
ate locally embedded
> websocket objects with their own methods to handle the socket events. Since
> request routing is done from inside the above service method we need the
> Jetty API. All our end user (web-)applications are implemented in the form
> of such scripts.
>
> Cheers,
>
nificant improvements as a result and
> have been waiting for the major release to make such a breaking change.
>
> We definitely will continue to support our API going forward, due to
> deficiencies and complications of the JSR API. So if your use-case is not
> already supp
Alexander,
I think the ConcurrentHashMap data structure is fine. However it doesn't
necessarily need to be static. You could store it as a field in your
WebSocketServlet and pass it in when you create your WebSocketListener.
In your code I would only expect oldSession to be non-null when you
Silvio,
There are no plans to phase out the Jetty WebSocket API. There have been
recent improvements to the Jetty WebSocket API in the recently released
Jetty10 and Jetty11 versions. It has many advantages over using the
javax.websocket API so there is no reason to phase it out.
Cheers,
Lachlan
v20201020]
>
> at
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:375)
> [jetty-util-9.4.33.v20201020.jar:9.4.33.v20201020]
>
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(Queu
Yes 9.4.33.v20201020 has already been tested and released. Not sure why
this was never announced on the mailing list.
On Tue, Nov 3, 2020 at 5:25 AM John Gardiner Myers
wrote:
> 9.4.33.v20201020 is listed on the downloads page, but is not mentioned
> on the jetty-announce mailing list. Has this
Hi Manpreet,
If we remove IIS in front of Jetty 9.4.24 it works as well.
If we upgrade Jetty to latest version 9.4.31 it doesn’t work.
Does it also work on 9.4.31 when not using IIS in front of jetty?
Firstly it would be useful to see what the HTTP websocket upgrade request
looks like when it
HI Jeroen,
I have set up a basic project which works with HTTPS and with your
keystore. You can look at this to get some idea why yours isn't working.
https://github.com/lachlan-roberts/jetty-maven-plugin-https-example
Cheers,
Lachlan
On Thu, Aug 20, 2020 at 10:43 PM Jeroen Hoek wrote
Hi Phil,
Firstly I would suggest you update to the latest version of Jetty (version
9.4.30). The version you are on is subject to various security
vulnerabilities, and there has been numerous other improvements and updates
since 9.4.15.
I'm not sure your resourcePath is correct, maybe try using
Hi Ryan,
Firstly I don't think you need the initial ServletHandler you are using,
you could instead add the ServletContextHandler onto the server directly.
ServletContextHandler contextHandler = new ServletContextHandler();
contextHandler.setContextPath("/");
server.setHandler(contextHandler);
>
> I suspect it's because I didn't set any roles in the second case, and thus
> an empty role cannot be matched to "**". I tried to add a role in
> getUserInfo but it doesn't work.
The role name "**" should match any authenticated user independent of role
so I don't think this is your problem.
There is now a fix for this in the 9.4.x branch and will be in a 9.4.23
release.
For a workaround you should be able to use the RewriteHandler to default
the charset to utf-8.
On Thu, Oct 24, 2019 at 2:25 AM Brian Reichert wrote:
> On Wed, Oct 23, 2019 at 04:51:57AM +, Gary Kopff wrote:
>
Hi,
This looks like a bug in jetty. I have opened an issue and PR for this.
https://github.com/eclipse/jetty.project/pull/4241
On Wed, Oct 23, 2019 at 3:52 PM Gary Kopff wrote:
> jetty-distribution-9.4.21.v20190926
> jre1.8.0_231
>
> Create a HTML form using the POST method :-
>
>
Hi,
I can't see any behavioural changes to LoginAuthenticator and
SecurityHandler since 9.4.13 which could cause this.
How are you expecting to get a LoginService? do you add it as a bean on the
server, set it directly on SecurityHandler, etc..
On Wed, Oct 9, 2019 at 7:59 PM Sai Sankar Challa <
Hi,
Looking at "unsuccessful connection.pcapng" it seems that the sequence of
events is like this.
1. The upgrade request is sent by the client.
2. The client sends the first websocket text frame before waiting for the
upgrade response.
3. The server is accepting the upgrade request sends back a
34 matches
Mail list logo
