[jira] [Created] (KARAF-5693) Incomplete config.properties file in built assemblies
Greg Logan created KARAF-5693: - Summary: Incomplete config.properties file in built assemblies Key: KARAF-5693 URL: https://issues.apache.org/jira/browse/KARAF-5693 Project: Karaf Issue Type: Bug Affects Versions: 4.0.10 Reporter: Greg Logan Attachments: broken.log, broken.properties, working.log, working.properties Over at the Opencast project (https://github.com/opencast/opencast) we rarely (1/20 or so) have assemblies seem to build correctly, but a number of libraries required for the assembly to boot with all installed modules will be missing from config.properties. A repackage of the same codebase and built artifacts resolves the issue, so this seems to be related to the assembly itself rather than the underlying modules. This also seems to be independent of our branches, and versions - we've been observing this off-and-on for more than a year but I've just never gotten around to filing this. Things attached: * working and broken.log: full build outputs (including component compilation) of the working and failing builds, respectively * working and broken.properties: the config.properties generated in the working, and failing builds, respectively. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KARAF-5693) Incomplete config.properties file in built assemblies
[ https://issues.apache.org/jira/browse/KARAF-5693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16431436#comment-16431436 ] Greg Logan commented on KARAF-5693: --- Per discussion on the mailing list, this also appears to be independent of the assembly itself as well - we've noticed it in all of them but it's mainly the allinone that gets noticed because it is used for testing. > Incomplete config.properties file in built assemblies > - > > Key: KARAF-5693 > URL: https://issues.apache.org/jira/browse/KARAF-5693 > Project: Karaf > Issue Type: Bug >Affects Versions: 4.0.10 >Reporter: Greg Logan >Priority: Major > Attachments: broken.log, broken.properties, working.log, > working.properties > > > Over at the Opencast project (https://github.com/opencast/opencast) we rarely > (1/20 or so) have assemblies seem to build correctly, but a number of > libraries required for the assembly to boot with all installed modules will > be missing from config.properties. A repackage of the same codebase and > built artifacts resolves the issue, so this seems to be related to the > assembly itself rather than the underlying modules. This also seems to be > independent of our branches, and versions - we've been observing this > off-and-on for more than a year but I've just never gotten around to filing > this. > > Things attached: > * working and broken.log: full build outputs (including component > compilation) of the working and failing builds, respectively > * working and broken.properties: the config.properties generated in the > working, and failing builds, respectively. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (KARAF-7424) Read only logging config prevents log:tail
Greg Logan created KARAF-7424:
-
Summary: Read only logging config prevents log:tail
Key: KARAF-7424
URL: https://issues.apache.org/jira/browse/KARAF-7424
Project: Karaf
Issue Type: Bug
Reporter: Greg Logan
First noticed during an upgrade to Karaf 3.4.6[1]. Upon execution of log:tail
in a Karaf console where the logging config file is read-only, the command
fails with the following stack trace
{noformat}
2022-03-24T23:52:44,003 | ERROR | (ShellUtil:152) - Exception caught while
executing command
org.osgi.service.cm.ReadOnlyConfigurationException: Configuration
org.ops4j.pax.logging is read-only
at
org.apache.felix.cm.impl.ConfigurationAdapter.checkLocked(ConfigurationAdapter.java:370)
~[?:?]
at
org.apache.felix.cm.impl.ConfigurationAdapter.update(ConfigurationAdapter.java:144)
~[?:?]
at
org.apache.karaf.log.core.internal.LogServiceImpl.setLevel(LogServiceImpl.java:109)
~[?:?]
at
org.apache.karaf.log.command.LogTail$LogServiceTracker.addingService(LogTail.java:95)
~[?:?]
at
org.apache.karaf.log.command.LogTail$LogServiceTracker.addingService(LogTail.java:76)
~[?:?]
at
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
~[osgi.core-6.0.0.jar:?]
at
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
~[osgi.core-6.0.0.jar:?]
at
org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
~[osgi.core-6.0.0.jar:?]
at
org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:183)
~[osgi.core-6.0.0.jar:?]
at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:318)
~[osgi.core-6.0.0.jar:?]
at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:261)
~[osgi.core-6.0.0.jar:?]
at org.apache.karaf.log.command.LogTail.execute(LogTail.java:54) ~[?:?]
at
org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:84)
~[?:?]
at
org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:68)
~[?:?]
at
org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:86)
~[?:?]
at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:599) ~[?:?]
at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:526)
~[?:?]
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:415) ~[?:?]
at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:416) ~[?:?]
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229) ~[?:?]
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
~[?:?]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
~[?:?]
at java.lang.Thread.run(Thread.java:829) [?:?]{noformat}
Operations are otherwise unimpeded, but it makes debugging harder :)
1: https://github.com/opencast/opencast/pull/3542
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
