JankKeks
(Jank Keks)
December 26, 2024, 8:14pm
1
We’re currently cleaning up a binding and fixing some bugs. Target branch is 5.0.0 exp. We have some problems with the existing implementation of Jetty based websockets.
I wonder if we could use a modern version of Jetty (e.g. 12). OH Dev Guidelines says, that you should use Jetty 9 whats delivered by default (but it’s totally outdated).
So the question is: is it okay to use a modern Jetty version for a new websocket implementation in a binding?
rlkoshak
(Rich Koshak)
December 27, 2024, 4:36pm
2
My understanding is Jetty comes with Karaf and Karaf is moving to a new version for OH 5. My understanding is it comes with a new version of Jetty among others things.
Outside of that, i would guess the maintainers don’t want a bunch of different insurance if the same service running for each binding.
You can track the progress and find specific versions in the GitHub issue and PRs that are open right now.
1 Like
lsiepel
(Leo)
December 28, 2024, 7:11am
3
JankKeks:
Jetty 9
I’m a little bit less optimistic for Jetty 12 in OH5, but we will see. For the time being we are stuck on 9. Hope you can add all user faced function, without too much trouble
wborn
(Wouter Born)
December 28, 2024, 8:30am
4
Yes would be nice to get it updated. It’s tracked in this issue:
https://github.com/openhab/openhab-core/issues/3315
STSC
(STSC)
December 29, 2024, 2:13pm
5
Topic was also discussed here.
openhab:main
← holgerfriedrich:k447
opened 11:23PM - 05 Oct 24 UTC
This is WIP and prepares for next Karaf version 4.4.7 (currently still at SNAPSH… OT level).
Fixes #4283
Fixes CVE in BouncyCastle 1.77
Upgrade Karaf from 4.4.6 to 4.4.7
* Sync runtime dependencies with Karaf 4.4.7, most notably:
* PaxWeb 8.0.29
* Jetty 9.4.56.v20240826
* BouncyCastle 1.78.1
* CXF 3.6.4
* Jackson 2.17.2
* JNA 5.15.0
* JAXB 2.3.9
* commons-io 2.17.0
* commons-lang3 3.17.0
* XBean 4.26
* ASM 9.7.1
* Resolve itest runbundles
Upgrade Xtext/Xtend to 2.37.0
* Upgrade Xtext/Xtend from 2.36.0 to 2.37.0, see release notes:
https://eclipse.dev/Xtext/releasenotes.html#/releasenotes/2024/11/19/version-2-37-0
https://eclipse.dev/Xtext/xtend/releasenotes.html#/releasenotes/2024/11/19/version-2-37-0
* Upgrade dependencies
* ecj from 3.36.0 to 3.37.0
* gson from 2.10.1 to 2.11.0
* classgraph to 4.8.176
* jna from 5.14.0 to 5.15.0
* guava from 3.33.0 to 3.33.1
<!--
Thanks for contributing to the openHAB project!
Please describe the goal and effect of your PR here.
Pay attention to the below notes and to *the guidelines* for this repository.
Feel free to delete any comment sections in the template (starting with "<!--").
ATTENTION: Don't use "git merge" when working with your pull request branch!
This can clutter your Git history and make your PR unusable.
Use "git rebase" instead. See this forum post for further details:
https://community.openhab.org/t/rebase-your-code-or-how-to-fix-your-git-history-before-requesting-a-pull/129358
All PRs should be created using the "main" branch as base.
Important bugfixes are cherry-picked by maintainers to the patch release branch after a PR has been merged.
If your PR's code is not backward compatible with previous releases (which
should be avoided), add a message to the release notes by filing another PR:
https://github.com/openhab/openhab-distro/blob/main/distributions/openhab/src/main/resources/bin/update.lst
# Title
Provide a short summary in the *Title* above. It will show up in the release notes.
For example:
- Introduce metadata for all add-ons
- Fix memory leak in ScriptedRuleProvider
# Description
Please give a few sentences describing the overall goals of the pull request.
Give enough details to make the improvement and changes of the PR understandable
to both developers and tech-savy users.
Please keep the following in mind:
- What is the classification of the PR, e.g. Bugfix, Improvement, Novel Addition, ... ?
- Did you describe the PRs motivation and goal?
- Did you provide a link to any prior discussion, e.g. an issue or community forum thread?
- Did you describe new features for the end user?
- Did you describe any noteworthy changes in usage for the end user?
- Was the documentation updated accordingly, e.g. the Core README?
- Does your contribution follow the coding guidelines:
https://www.openhab.org/docs/developer/guidelines.html
- Did you check for any (relevant) issues from the static code analysis?
- Did you sign-off your work:
https://www.openhab.org/docs/developer/contributing.html#sign-your-work
If your pull request contains a new contribution, it will likely take some time
before it is reviewed and processed by maintainers.
-->