Missing Addon Configuration for kar file based deployments

[HolgerHees]

If I install the default pythonscripting binding, everything is fine. I can see and use the related web configuration.

The marketplace version “Python Scripting Next” has just a prefixed “next-” feature name. But if I install these binding, I can see the menu entry, but the page itself is empty.

And if I install the kar file directly inside the addon folder, nothing is visible.

Some details about the setup.

• default pythonscripting binding is a official one.
  • it has the id pythonscripting in addon.xml
  • and a <config-description-ref uri="automation:pythonscripting"/>
  • the config.xml has the uri <config-description uri="automation:pythonscripting">
• the marketplace version is exactly the same. Means it is using the same id's and uris.
  • only the feature.xml is prefixt with "next-" like
    <feature name="next-automation-pythonscripting"
  • everything else is the same

The prefixed feature ID was necessary to avoid conflics with official the addon. If I was using the same feature id like the official one, the AddonInstaller was always uninstalling my binding

---- UPDATE 1 ----

I checked via Java Code (I got AddonInfoRegistry & ConfigDescriptionRegistry by @reference before)

AddonInfo info = AddonInfoRegistry.getAddonInfo("automation-pythonscripting");
logger.info("URI {}", info.getConfigDescriptionURI());

I got “URI automation:pythonscripting”

But if I ask

ConfigDescription desc = ConfigDescriptionRegistry.getConfigDescription("automation:pythonscripting");

I got null

So for some reason the Add-on is not registering the config.xml

---- UPDATE 2 ----

it looks like that the related config.xml is never parsed for kar file based deployments.

I was also not able to find a addon kar file on marketplace where this ever worked.

All addons which provide their own configuration page are all jar files.

---- FORUM THREAD ----

The issues is based on a thread on our forum

https://community.openhab.org/t/missing-addon-configuration-for-kar-file-based-deployments/165171

[Nadahar]

I've looked at this before. Sadly, I don't remember all the details now, but in short, there are multiple problems with how add-on configurations are handled.

From the little I remember, there are JarFileAddonService, KarafAddonService, EclipseAddonService, CommunityMarketplaceAddonService and JsonAddonService. Some of these handle installation and uninstallation, while JarFileAddonService and EclipseAddonService are "passive" - these add-ons must be installed using other methods.

AddonInfo instances are registered with the AddonInfoRegistry. These are supplied by AddonInfoProviders that don't have any idea what "kind of" add-on it is. We have AddonInfoAddonsXmlProvider and XmlAddonInfoProvider (naming isn't great). The former parses runtime/etc/addons.xml while the latter parses any addon.xml files that are embedded in bundles.

Herein lies the problem. The logical structure doesn't really reflect reality. So, it all goes kind of wrong when it comes to which AddonInfo "belong to" which AddonService. To achieve this, the bundle location is used. So, when a marketplace bundle is installed, the location is manipulated so that it's possible to "reattach" this AddonInfo to the marketplace add-on. It sort of works, but it's a hack. But, that's not an option for other bundles that aren't installed by the AddonService. Thus, every bundle with a Location that starts with mvn: is "acquired" by KarafAddonService (but this has nothing to do with whether it's a KAR, but what URI was used when installing the bundle). Everything that starts with file: is acquired by both JarFileAddonService and EclipseAddonService (which is why most add-ons are shown twice in Eclipse).

KarafAddonService doesn't "do" what it promises, either. It doesn't handle KAR files, it handles features that start with openhab- - aka only the official add-ons.

When you acquire a bundle from OSGi, there is no information available about what "feature" it belongs to. Neither are there any information about what "feature(s)" that belong to a certain KAR file. So, there's no way to sort this out and make the correct coupling between the bundles and the AddonInfo instances.

I've been trying to find a way to sort all this out, but have been stuck so far. Touching this at all has a high likelihood of breaking something, and there simply are too many places where too little information is available to make the right decisions, and my experience is that even if I managed to figure it out, nobody would probably dare to merge it anyway. So, why keep banging my head against the wall when it's probably pointless anyway?

The closes I've come to a "solution" is that a lot must be restructured, and there must be some "entity" that keeps tracks of what bundles "belong to" what "package"/"feature"/"add-on". The other components would then have to talk to this to get their information, so that the whole thing was coordinated. It is possible to list what bundles are in a certain feature, but I don't remember finding anything similar for KAR files.

There are other problems as well: A KAR file can contain several bundles with several addon.xml files. Also, there's not even a guarantee that the bundles from the KAR file will be used, when the "feature" definition in the KAR is read, it might very well be that the system figured that it should fetch some of the bundles from an online source instead of using those in the same KAR. How do you then decide which addon.xml information that belongs to a certain "add-on", if the KAR file represents that add-on, even if you could figure out what did and didn't come from said KAR file?

So, as I see it, the KAR system is "lacking" as a source for "complete packages", and the tracking of the components is terrible.

To sum it up, there is really nothing that is responsible or able to handle KAR files. The files themselves are "imported" as long as they are dumped in the appropriate folder by Karaf, so the bundles will be installed and started. But, apart from that, nothing much is handled.

That's as much as I remember, there might be errors or missing information, but anyone wanting to look at this should at least have something to start with.