How to obtain a reference to the BayeuxServer in the SpringBoot CometdApplication about cometd HOT 11 CLOSED

First point, I think it's a Spring Boot quirk, and I'm not that knowledgeable on that either, and you have not posted the error details, so I'm not sure I can help.
Have you tried asking to the Spring Boot project?

Second point, it's still not clear to me what problem you are trying to solve?
There are a million cases of network failures, to which you want to react differently, but they look the same.
For example, a user refreshes the page on the browser.
The WebSocket connection is closed and another is opened immediately, so on the server you want to behave as if nothing happened.
On the other hand, if the client closes the browser, the WebSocket connection is closed, but you cannot tell the difference with the previous case on the server.

CometD helps you to abstract away these details.

I suggest you try plain CometD, and if you really have a problem of not being notified quickly enough you can detail it better -- in other words don't put the cart before the horse 😄

from cometd.

As shown in the documentation, you also register one or more CometD services:

        cometdServlet.setInitParameter("services", EchoService.class.getName());

The EchoService class is just an example, and it can be annotated with CometD annotations to inject a BayeuxServer instance, see https://docs.cometd.org/current/reference/#_java_server_services_annotated_server_side.

from cometd.

Thanks a lot Simone for your promptness.
Indeed, this way I could get access to the BayuexServer. I wrote a simple service logging all the messages on any /meta/* channel hoping to intercept WebSocket failures as well, but perhaps that's not the proper place/way?

I still get (voluntarily induced):

2023-03-22 11:31:24,626 [Connector-Scheduler-3a320ade-1] INFO  o.c.s.w.j.WebSocketEndPoint$Delegate - WebSocket failure, address /xx.yy.ww.zz:ppppp on Delegate@356ad50c[JakartaWebSocketSession@68d479b8[SERVER,JakartaWebSocketFrameHandler@34917a65[endpoint=org.cometd.server.websocket.javax.WebSocketTransport$EndPoint]]]
org.eclipse.jetty.websocket.core.exception.WebSocketTimeoutException: Connection Idle Timeout

but don't know where I can intercept them to promptly make subsequent actions on detecting the WS failure (or similar issues). The Service above seems to receive no clue of that. What would be the proper way? A Service ? An Extension ? Anything else/elsewhere?

Also, back to the original question, if for the above purpose I wanted to enable the ActivityExtension like shown:

bayeuxServer.addExtension(new ActivityExtension(ActivityExtension.Activity.CLIENT, 15 * 60 * 1000L));

where is the proper place to obtain the bauyexServer reference to invoke the addExtension(...) in the above case of the SpringBoot application ? Still in a custom Service (e.g. in the init() of the Service) or somewhere else?

from cometd.

What version of CometD and what version of Spring Boot?

from cometd.

Thanks again,

CometD 7.0.9, Spring Boot v3.0.0-M5, Spring v6.0.0-M6, jetty-11.0.12

from cometd.

Let me update the project with the right versions of Spring and SpringBoot and I'll come back to you.

from cometd.

I have updated CometD 7 with Spring 6.0.7 and Spring Boot 3.0.5 and the tests pass fine.

I wrote a simple service logging all the messages on any /meta/* channel hoping to intercept WebSocket failures as well, but perhaps that's not the proper place/way?

CometD is above the transport layer, so listening to CometD /meta/* messages for HTTP or WebSocket is not the right way.
I'm not sure what you want to do, even if you detect a WebSocket failure?

from cometd.

Thanks a lot for your attention Simone.

About the tests passing fine, could you please help understanding how can I exploit this new information to obtain the bayuex server reference in the Spring Boot app scenario?

As for the why I'd like to intercept as early as possible the WebSocket failure, I'm pondering about acting as a middleware that registers itself as a CometD client towards a 3rd party cometD server, and once I understand anything happened to my connection to this latter, I have the responsibility to alert a consumer of my services a.s.a.p., so that's why the idea of using WebSocket to connect to the CometD server in order to not being dependent on the polling timeouts of the long-polling transport.

from cometd.

could you please help understanding how can I exploit this new information to obtain the bayuex server reference in the Spring Boot app scenario?

In the same way as before. Register a CometD service and it will be injected.
See https://github.com/cometd/cometd/blob/7.0.x/cometd-java/cometd-java-examples/cometd-java-examples-springboot/src/main/java/org/cometd/examples/spring/boot/CometDApplication.java

As for the why I'd like to intercept as early as possible the WebSocket failure, I'm pondering about acting as a middleware that registers itself as a CometD client towards a 3rd party cometD server, and once I understand anything happened to my connection to this latter, I have the responsibility to alert a consumer of my services a.s.a.p., so that's why the idea of using WebSocket to connect to the CometD server in order to not being dependent on the polling timeouts of the long-polling transport.

This is already done by CometD via its heartbeat, there is no point in you re-doing all the work.
Register a /meta/connect listener and you will get notified of transport failures.

from cometd.

Thanks Simone,

as for the first point, expanding on the idea of injecting the BayeuxServer in a CometD Service I got stuck on a problem which is growing as I put work on it: it seems that I have no way of moving my @nAmed, @singleton CometD Service class anywhere else but along the SpringBootApplication class.
Say this latter is in:

package it.acme.myproject

As long as the CometD Service class is in the same package, the injection of the BayeuxServer bean:

@jakarta.inject.Inject
private BayeuxServer bayeux;

will work. Soon as I move the CometD Service class into, say:

package it.acme.myproject.services

The injection will fail at boot. No matter I annotate my SpringBootApplication also with

@ComponentScan({"it.acme.myproject.*"})

which should even not be needed after all, but I've also tried forcing to:

@ComponentScan({"it.acme.myproject.*", "org.cometd.*"})

with no luck (but after all, the BayeuxServer bean is correctly scanned when the consumer @service is in the same package). I admit I'm not too strong on SpringBoot, yet other custom-beans injection (and Autowiring) seems to be working in the project as expected.

Apart from this problem, I'm experiencing another similar one: any custom Spring component (e.g. a JPA repository or a Spring @service) I try to inject into my CometD Service will apparently work (meaning, the injection won't fail at boot as with the BayeuxServer above), but I get null beans when I try to access and use them (while the same Spring Components used everywhere else in the various Spring @Services, @controllers, etc works fine).

I should note anyway that the CometD Service is apparently correctly structured and it responds fine to services' invocation as well as the RPC through the @RemoteCall annotation I'm experimenting with as well. It works, it's just that I can expand it exploiting other beans.

As for the second point, I'll of course take your advice. I'll add a listener and exploit the sessionAdded() and sessionRemoved() methods to intercept the relevant events and do some business logic. Yet I will need to enhance my comprehension of the advantages/disadvantages of the various transport type. My initial understanding was that by going with the WebSocket I would gain an immediate notice of the socket failure (as opposed to a polling/hearbeat mechanism as with the long-polling). Yet I I correctly understand, the WebSocket transport would obey to the heartbeat/polling paradigm too in this case?

from cometd.

Thanks again Simone for your attention.

Concerning the first point, I'll try to have yet a deeper look/understanding at Spring Boot side of the issue.

Concerning the second point, the more I dig into CometD and experiment with its tools and mechanism, the more I understand it works as intended and it's a way better approach to rely on what has been envisioned in it to handle transport and communication issues.

from cometd.