Bundle:Update Xstream location

Rpi4 2GB on OH3.1, but using a OH3.2 snapshot Zwave binding to capture database updates. Usually this works, but ran into an old karaf error message about the Xstream default security. Exploring Github an earlier fix to this error was removed because it was depreciated with Xstream 1.14.18, but I am still on 1.14.17. Anyway I solved this for myself for now by putting the one line back and recompiling my local Zwave .jar. I’d like to stick with 3.1 until 3.2 is finalized by the end of the year.

I have limited experience with the bundle:update process, but was going to try to update Xstream, but do not know the “location”. Also the one other time I did a bundle update, it did not persist after a reboot, so I was wondering what the command is for that? In summary;

bundle:update ID (237 in my case) Location?

Bob

You can update it by using a Maven Central URL like this:

bundle:update xstream https://repo1.maven.org/maven2/com/thoughtworks/xstream/xstream/1.4.18/xstream-1.4.18.jar

Using the bundle symbolic name (xstream) it will work regardless of what ID it has.
You can find the symbolic name using: bundle:list -s

1 Like

Eventually you can use this artifact using the way Wouter mentioned. This JAR is coming from Apache ServiceMix Bundles: https://mvnrepository.com/artifact/org.apache.servicemix.bundles/org.apache.servicemix.bundles.xstream, which is guaranteed to have working OSGi metadata. Not sure how well vanilla xstream works with OSGi, if it fails try SMX wrapper.

Just in case, if you can’t get most recent version of XStream through SMX bundles then you can go with wrap:http://.... The wrap protocol might not be installed by default so you can enable it by doing feature:install wrap. Wrap does what the build tool do (bnd) but on the fly. There is a way to append more headers wrap:<location>$Import-Package=com.foo*,bar,*;resolution:=optional. In most recent releases of pax url wrap it is also possible to re-generate manifest of existing bundle if one of its entries is odd.

Last way, if you work with offline setups - you can use file:... URI which will always work, even if your internet went off. One note, the file location is evaluated relatively to installation dir and some internal locations. You will get most reliable results by using full paths.

If you seek for more docs on supported URIs and their behavior: https://ops4j1.jira.com/wiki/spaces/paxurl/pages/12058914/Documentation.

Enjoy!
Łukasz

1 Like

Thanks all.

Bob

1 Like

Very good, we’ve been using it since OH3. :wink:

As a denouement;

  1. good thing I just used Xstream because I had the number off.
    XstreamScreenshot 2021-11-02 193456
  2. A slight complaint: I do not know when the best time to make a change such as this, but the Zwave database changes about twice a week as new devices are added or old ones are changed, but I’m sure I’m not going to be the only one with an OH3.1 system and a 3.2 z-wave snapshot over the next couple of months. If I had a vote, I would have left the depreciated line in the binding for a while (maybe until 3.2 stable). Anyway do not want to distract from the help and solution you have offered. Just a comment.

Bob

I don’t think that’s the best approach. While I understand your point, what you’re saying is that we should not make such changes until the stable release is made. That means that testing can’t be performed until the release is made which makes it more likely that bugs will creep in to untested code. The version was updated, so I think that’s the right time to make changes.

IMHO, the best approach to your problem is to provide 3.1.x builds with “important updates” - such as bug fixes and potentially database updates. I don’t think that there are such patch versions being produced at the moment (@wborn ?) but if they are then I could probably arrange for the database updates to go into them.

Good points.

I know there are a few, but not sure how many folks are in the situation like me to make it worth it, as it sounds like a lot of extra work. Maybe something along the line of a communication that there was a change that will cause Zwave snapshots not to work on the last stable version of OH without a bundle update or whatever. Basically it was not a problem for 4 months. I recall maybe two issues in the 1H21 (with 3.1 snapshots on 3.0), so maybe three times a year. I had seen the Xstream warning in January, so I knew where to look, but sometimes it is not obvious.

Anyway, I good now and I tried to label this topic in the forum, so others can find it if they need it.

Bob

There are currently no patch releases for 3.1.x. @Kai previously managed these and all the infrastructure is there to build them. Maybe we currently don’t have these because there is not enough storage available to host all these patch releases on JFrog?

So this is a bit off the headline topic, but here is a “pointy haired boss” idea I thought of last night. If any two people could pull this off, it would be you two.

The Zwave binding splits cleanly between Java and Resources folders. Create a separate Resources folder with the device DB updates and create a framework in OH while loading Zwave to merge/overwrite that file into Zwave .jar during installation. I’m thinking along the lines of:

jar -uf org.openhab.binding.zwave.jar ./main/Resources
(Caveats 1) I know that can be used on a file, but don’t know about a folder? 2) Resources folder would likely need to be compressed, could the framework decompress before merging? 3) Would resources folder need a self-executing wrapper? 4) Can this go in the Addons directory or something new?)

The idea is the Resources folder (no java code, mostly .XML) could be updated in the binding without affecting the Java side. The Zwave java side changes very little and could probably align with the monthly Milestones, while the Resources folder (from the device DB) could continue to change as often as necessary. Folks could stay on their Zwave java binding version. Anyway, don’t spank too hard :wink: I’m just tossing it out there to be eaten.

Bob

IMHO this would just be a workaround that does not address the main issue: more timely patch releases. :wink:

Starting with OH 3.2, developers can also choose to distribute features and fixes outside regular openHAB releases whenever they want using the Marketplace.

Ok, knew it was a long shot.

Bob

This has been discussed a number of times on the forum…

Firstly, it’s not easy to implement. OH expects the thing definitions to be included in the binding - this is part of the way that the core works. To change this would either require the core to be changed, or for the binding to implement a load more code to perform this itself.

Also, while you are correct that the Java side doesn’t change too much, by splitting the thing definitions from the code, we will end up in a situation where some devices don’t work if you use new thing definitions with old Java implementation. This is inevitable - as you said, it may not happen often, but it will happen, and this is likely to lead to confusion (and a different set of complaints).

So, I do think that on balance, how it is implemented now, with a consistent set of thing definitions and implementation is probably the right approach.

Patch releases per definition are only for bug fixes and we usually only take on the additional work, if there are critical and or security fixes necessary - which luckily so far wasn’t the case for 3.1.
For everyone who is looking into regular updates, we have the monthly milestones which are pretty stable and a good choice.

Yeah I thought of that problem after I posted. I saw you recently did a string Color PR. That kind of thing would not be available on earlier versions.

I’m okay as is, I can see a lot of work on the OH side to get this done, plus the transition from the current way to the new way would be messy to say the least. As they say around here, “It is what it is”.

Bob