* Closes#3329.
This implements a new optional `cacheable` parameter for these REST endpoints:
- `/rest/items`
- `/rest/things`
- `/rest/rules`
When this parameter is set, a flat list of all elements excluding
non-cacheable fields (e.g. "state", "transformedState", "stateDescription",
"commandDescription" for items, "statusInfo", "firmwareStatus",
"properties" for things, "status" for rules) will be retrieved along with
a `Last-Modified` HTTP response header. When unknown, the Last-Modified
header will be set to the date of the request.
Also only when this parameter is set, and a `If-Modified-Since` header is
found in the request, that header will be compared to the last known
modified date for the corresponding cacheable list. The last modified date
will be reset when any change is made on the elements of the underlying
registry. If the `If-Modified-Since` date is equal or more recent than the
last modified date, then a 304 Not Modified response with no content will
be served instead of the usual 200 OK, informing the client that its
cache is still valid at the provided date.
All other request parameters will be ignored except for "metadata" in the
`/rest/items` endpoint. When a metadata selector is set, the resulting
item list will be considered like a completely different resource, i.e.
it will have its own last modified date. Regarding metadata, the approach
to invalidating last modified dates is very conservative: when any metadata
is changed, all cacheable lists of items will have their last modified date
reset even if the change was in a metadata namespace that wasn't requested.
This also implements the abovedescribed behavior for the
`/rest/ui/components/{namespace}` endpoint, but no `cacheable` parameter
is necessary. The last modified date is tracked by namespace.
Signed-off-by: Yannick Schaus <github@schaus.net>
This addresses CVE-2022-40151 and CVE-2022-41966, see:
https://x-stream.github.io/changes.html#1.4.20
This version also fixes an issue with closing streams so the workaround in GenerateDefaultTranslationsMojoTest is no longer needed.
Signed-off-by: Wouter Born <github@maindrain.net>
* Sync runtime dependencies with Karaf 4.4.3, most notably:
* Jetty 9.4.50.v20221201
* Pax Logging 2.2.0
* Pax Web 8.0.15
* Use OSGi R8 as compile dependency
* Rework Servlets to use Http Whiteboard annotations in favor of proprietary `org.openhab.core.io.http.servlet` classes
* Resolve itest runbundles
Also-by: Jan N. Klug <github@klug.nrw>
Signed-off-by: Wouter Born <github@maindrain.net>
* Raise source level to Java 17 (except for model classes)
* Remove Nashorn script engine
* Upgrade spotless and add jvm options
See https://github.com/diffplug/spotless/issues/834
* Add suppression for findBugs false positive error
* Upgrade xtext to 2.29.0
* Adjust JNA
* Resolve itests
Signed-off-by: Jan N. Klug <github@klug.nrw>
* Add more null annotations
* Fix mock name
Adds null annotations to most of the tests as well as a few other classes.
Also fixes a few other SAT findings.
Fixes ~300 SAT findings in total.
Signed-off-by: Wouter Born <github@maindrain.net>
It causes unneccessary bundle refreshes whenever add-ons are installed/uninstalled.
As a result the UI does not get properly notified of installation changes.
Fixes#2580
Reverts the Aries JAX-RS Whiteboard upgrade of #2532
Signed-off-by: Wouter Born <github@maindrain.net>
New ItemChannelLinkProviders are added asynchronously to the ItemChannelLinkRegistry, which can cause this test to fail:
TEST org.openhab.core.io.rest.core.internal.link.ItemChannelLinkResourceOSGiTest#shouldReturnLinks() <<< ERROR:
Expected: a collection with size <3>
but: collection size was <0>
java.lang.AssertionError:
Expected: a collection with size <3>
but: collection size was <0>
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
at org.openhab.core.io.rest.core.internal.link.ItemChannelLinkResourceOSGiTest.shouldReturnLinks(ItemChannelLinkResourceOSGiTest.java:109)
Signed-off-by: Wouter Born <github@maindrain.net>
This prevents typos and using the constants makes it easier to find out what other items types are accepted.
It also makes it easier to see that these values are item types and not labels or descriptions.
Signed-off-by: Wouter Born <github@maindrain.net>
