openHAB 3.1 Milestone discussion

ohb1138 · May 30, 2021, 7:38pm

Hi,
I tested 3.1 Milestone 4 yesterday for a very short time before heard that Milestone 5 will be today and hence I jumped today directly from M3 to Milestone 5.
I recognized that with M4 as well as with M5 the colored output in the karaf log has gone (INFO=cyan, ERROR=red, DEBUG=black, WARNING=magenta). Any idea how to get this back?

Bruce_Osborne · May 30, 2021, 7:44pm

Between M3 & M4 there was an update to OSGi &, I believe, karaf. Perhaps that explains the change.

ohb1138 · May 30, 2021, 7:54pm

Thanks Bruce for this quick response!!! Ok, so the reason seems to be clear
… The question is where and how to ask if this can be turned back

Bruce_Osborne · May 30, 2021, 8:25pm

If karaf was updated perhaps an apache karaf forum may have the answer.

Kai · May 30, 2021, 8:53pm

Good question. I have found https://issues.apache.org/jira/browse/KARAF-7029, which seems to hint that the userdata/etc/org.apache.karaf.log.cfg file needs to be changed for the Karaf 4.2 to 4.3 upgrade.

The Karaf distro now contains:

color.fatal = "bright red"
color.error = "bright red"
color.warn = "bright yellow"
color.info = "bright green"
color.debug = "cyan"
color.trace = "cyan"
pattern = "\u001b[90m%d{HH:mm:ss.SSS}\u001b[0m %h{%p}{FATAL=${color.fatal}, ERROR=${color.error}, WARN=${color.warn}, INFO=${color.info}, DEBUG=${color.debug}, TRACE=${color.trace}} \u001b[90m[%t]\u001b[0m %m%n"

I couldn’t figure out, how to update our version of the file so that it keeps the same formatting, but re-adds the colors… Maybe you are more lucky and can come up with the correct update? (fyi @wborn)

ohb1138 · May 31, 2021, 9:37am

Hi @Kai,
taking these settings 1:1 seems not to work very well:

But it is a good hint where to start redefining the settings to get the previous output format

EDIT I found this in Kais Link:

The problem comes from the org.apache.karaf.log.cfg. Our distribution still had the same configuration we used in 4.2:

pattern = %d{HH:mm:ss.SSS} | %-5.5p | %-16.16t | %-32.32c | %20.20X{bundle.name}:%X{bundle.version} | %m%n

Reverting this to what's shipped with 4.3.0 shows colors again.

Question is … “What is the default shipped with 4.3?”

ohb1138 · May 31, 2021, 9:54am

This also did not bring the colors back

It also seems that the log:DiSPLAY has now the “tail” option per default as I only get the last few lines when running the command???

ohb1138 · May 31, 2021, 10:10am

@Kai, @wborn,

I found this in the same thread that you have mentioned above:

> The karaf console => log:tail is no longer colored, but all white. I checked 
> my org.apache.karaf.log.cfg file and there is no '--no-color' property there. 
> So i debugged a bit 
> org.apache.karaf.log.core.internal.LogEventFormatterImpl.getColor(PaxLoggingEvent,
>  boolean) and found an issue there.
> return level2Color.get(event.getLevel());
> the map key is of type org.osgi.service.log.LogLevel, while event.getLevel() 
> is of type org.ops4j.pax.logging.spi.PaxLevel (incompatible). So for testing 
> purposes i changed to return level2Color.get(event.getLevel().toLevel()); 
> (which is the proper LogLevel type)
> and the console was colored again.
> I file this as minor although for me it is at least normal, i got very used 
> to the color-coded log levels... :)

especially this part:

>  ... So for testing 
> purposes i changed to return level2Color.get(event.getLevel().toLevel()); 
> (which is the proper LogLevel type)
> and the console was colored again.

Does it make sense to fix this manually as a workaround until it is fixed in karaf?
I don’t where level2Color.get() is located Every hint is appreciated.

Kai · May 31, 2021, 10:14am

Would you want to create an issue at openhab-distro so that we can move the discussion there?

ohb1138 · May 31, 2021, 10:51am

Of course. This is directly on Github, right? Sorry, I am not so used to do this but I find my way to it … I am currently not at home. I will do when I get back!

Thanks for rating this as a valid issue!

ohb1138 · May 31, 2021, 12:33pm

Issue submitted:

github.com/openhab/openhab-distro

Karaf Log is missing coloured output since OH 3.1 Milestone 3

opened 12:32PM - 31 May 21 UTC

closed 07:36AM - 07 Jun 21 UTC

doc1138

Hi there, as described in in post [#166](https://community.openhab.org/t/openha…b-3-1-milestone-discussion/116025/166?u=ohb1138) of the community topic ["openHAB 3.1 MIlestone discussion"](https://community.openhab.org/t/openhab-3-1-milestone-discussion/116025) there is no more coloured output in karaf log. All entries (INFO, ERROR, WARNING, DEBUG, TRACE) are black. First hints have been found: > I have found [https://issues.apache.org/jira/browse/KARAF-7029](https://issues.apache.org/jira/browse/KARAF-7029), which seems to hint that the userdata/etc/org.apache.karaf.log.cfg file needs to be changed for the Karaf 4.2 to 4.3 upgrade. > > The Karaf distro now contains: > > color.fatal = "bright red" > color.error = "bright red" > color.warn = "bright yellow" > color.info = "bright green" > color.debug = "cyan" > color.trace = "cyan" > > pattern = "\u001b[90m%d{HH:mm:ss.SSS}\u001b[0m %h{%p}{FATAL=${color.fatal}, ERROR=${color.error}, WARN=${color.warn}, INFO=${color.info}, DEBUG=${color.debug}, TRACE=${color.trace}} \u001b[90m[%t]\u001b[0m %m%n" I couldn’t figure out, how to update our version of the file so that it keeps the same formatting, but re-adds the colors… Maybe you are more lucky and can come up with the correct update? And further down in this thread: > The karaf console => log:tail is no longer colored, but all white. I checked > my org.apache.karaf.log.cfg file and there is no '--no-color' property there. > So i debugged a bit > org.apache.karaf.log.core.internal.LogEventFormatterImpl.getColor(PaxLoggingEvent, > boolean) and found an issue there. > return level2Color.get(event.getLevel()); > the map key is of type org.osgi.service.log.LogLevel, while event.getLevel() > is of type org.ops4j.pax.logging.spi.PaxLevel (incompatible). So for testing > purposes i changed to return level2Color.get(event.getLevel().toLevel()); > (which is the proper LogLevel type) > and the console was colored again. > I file this as minor although for me it is at least normal, i got very used > to the color-coded log levels... :) As requested by Kai Kreutzer I am opening this issue to solve this problem!

JustinG · May 31, 2021, 4:31pm

@Kai with regards to rooting out regressions before the release of 3.1, it looks like the regression that appeared in M3 that impacts users with apache reverse proxies hasn’t been addressed yet: github issue & forum discussion

milo · June 1, 2021, 12:20pm

Hello all since M5 build of openhab 3.1 i get this error

2021-06-01 14:08:07.859 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle:

file:/usr/share/openhab/addons/org.openhab.binding.weatherflowsmartweather-3.1.0-SNAPSHOT.jar

org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.weatherflowsmartweather [313]

  Unresolved requirement: Import-Package: javax.measure; version="[1.0.0,2.0.0)"

	at org.eclipse.osgi.container.Module.start(Module.java:463) ~[org.eclipse.osgi-3.16.200.jar:?]

	at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:440) ~[org.eclipse.osgi-3.16.200.jar:?]

	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.6.8]

	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.6.8]

	at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [bundleFile:3.6.8]

	at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.6.8]

	at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.6.8]

Lukie · June 1, 2021, 12:35pm

I get this as well now after upgrading from 3.1M2 - 3.1M5 for a binding (opensprinkler) which I have dropped into the addons folder

milo · June 1, 2021, 12:38pm

Why is the yioremote binding not working from the official repository but if i local add it to the addon folder it’s running fine?

wborn · June 1, 2021, 1:01pm

When you see this error, the add-on needs to be recompiled because the UoM dependencies got a major update with openhab-core#2319.

sascha777 · June 2, 2021, 10:21am

Hi all, since M5 I don’t see my manually defined items (from itemsfile) linked to channels (in the thing web interface) anymore. This looks specific to the LuxtronikHeatpump binding. All other manual items look to be linked properly.
These manually defined items doesn’t get any updates from the binding whereas new items defined within the interface do get updates.
Might that be due to M5 changes? Or would that be binding-specific?

rossko57 · June 2, 2021, 10:29am

Make sure Item types and channel types match, in case quantities (with units) are involved.

sascha777 · June 2, 2021, 10:34am

Thanks for the hint.
Got it, the channel ids where just updated. I didn’t see that as my VSCode extension still showed to old ids.

fifo · June 14, 2021, 3:59am

Like JustinG mentioned, a few folks having this issue with apache reverse proxy no longer working after M2. This seems to have broken on upgrade from M2 to M3 if I recall correctly. M4 didn’t address the issue either.

If there is anything I can do to help testing let me know.