apupier commented on PR #21234:
URL: https://github.com/apache/camel/pull/21234#issuecomment-3842189471
so seems that it is real bug and we should not just adjust the test.
The difference is coming from
org.atmosphere.cpr.AtmosphereFramework.loadWebSocketFromPath(ClassLoader,
String)
With Java 17, `(new File("")).exists()` is returning false
With Java 25, `(new File("")).exists()` uis return true
both returns `/home/apupier/git/camel/components/camel-atmosphere-websocket`
when trying to call .getAbsolutePath()
because of this difference, with Java 25, the subdirectories are searched
for .class ad potential sublcasses of WebSocketProtocol. it founds 2 of them,
and it initialize the AtmosphereFramework with the last one, in our case,
always the WebsocketStreamHandler. And then when initializing the websocket
with org.atmosphere.cpr.AtmosphereFramework.initWebSocket(), the configuration
provided as init parameter is ignored as the webSocketProtocol was already set.
Several points to note:
* I think that the search on the subclasses on classpath can work only in
dev mode as it is looking to regular File and not handle resource inside jars;
SO this should not affect runtime. Sounds like a not working functionality of
atmosphere.
* there are parameters in constructors to avoid to search for auto detection
of websocket handler BUT, this is not accessible as a parameter (and it is also
used for AtmosphereHandler so this migt hinterfere with it
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
