[jira] [Commented] (KARAF-2466) make it easy to access environment variables inside karaf configuration properties files - via ${ENV.foo}?
[
https://issues.apache.org/jira/browse/KARAF-2466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15721707#comment-15721707
]
Michael Prieß commented on KARAF-2466:
--
I miss the part of using system properties and enviroment variables in the
documentation.
> make it easy to access environment variables inside karaf configuration
> properties files - via ${ENV.foo}?
> --
>
> Key: KARAF-2466
> URL: https://issues.apache.org/jira/browse/KARAF-2466
> Project: Karaf
> Issue Type: Improvement
> Components: karaf-core
>Reporter: james strachan
>Assignee: Jean-Baptiste Onofré
>
> when using karaf in clouds & PaaS infrastructures like OpenShift, Docker,
> OpenStack et al; its common to use environment variables to pass in
> environment specific values; then keep a single disk image. It would be nice
> if there was an easy way to reference environment variables similar to the
> ${foo.bar} syntax for accessing system properties.
> Maybe karaf should support some kind of environment variable expansion like
> {code}
> # define a property based on an env var
> foo = ${ENV.nameOfEnvVar}
> # e.g. here's the host name
> host = ${ENV.HOSTNAME}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (KARAF-4874) Distributed log service no order of messages, no serialization
[ https://issues.apache.org/jira/browse/KARAF-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré reassigned KARAF-4874: --- Assignee: Jean-Baptiste Onofré > Distributed log service no order of messages, no serialization > -- > > Key: KARAF-4874 > URL: https://issues.apache.org/jira/browse/KARAF-4874 > Project: Karaf > Issue Type: Bug > Components: cellar-core >Affects Versions: cellar-4.0.2 >Reporter: Branislav Kalas >Assignee: Jean-Baptiste Onofré > > Cluster log writes records to hazelcast map with ClusterLogRecord instances > as keys. > cluster:log-display then just iterates through keyset of this map and outputs > records to console. > Result is log messages with no ordering (no relation to order of putting > records to map) which i think is useless. > When map reaches its max allowed size, there is LRU eviction strategy > defined, which is also incorrect (cause if you use cluster:display you use > records withoud any order) and record is just deleted, there is no > persistence. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (KARAF-4865) Karaf startup no longer works on platforms without "readlink"
[ https://issues.apache.org/jira/browse/KARAF-4865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré reassigned KARAF-4865: --- Assignee: Jean-Baptiste Onofré > Karaf startup no longer works on platforms without "readlink" > - > > Key: KARAF-4865 > URL: https://issues.apache.org/jira/browse/KARAF-4865 > Project: Karaf > Issue Type: Bug > Components: karaf-core >Reporter: Fabian Lange >Assignee: Jean-Baptiste Onofré > Fix For: 4.1.0, 4.0.8 > > > With KARAF-4564 we used "readlink" to resolve some symlink issues. but this > broke karaf now for platforms which do not support "readlink". we should make > it optional. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KARAF-4865) Karaf startup no longer works on platforms without "readlink"
[ https://issues.apache.org/jira/browse/KARAF-4865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-4865: Component/s: karaf-core > Karaf startup no longer works on platforms without "readlink" > - > > Key: KARAF-4865 > URL: https://issues.apache.org/jira/browse/KARAF-4865 > Project: Karaf > Issue Type: Bug > Components: karaf-core >Reporter: Fabian Lange >Assignee: Jean-Baptiste Onofré > Fix For: 4.1.0, 4.0.8 > > > With KARAF-4564 we used "readlink" to resolve some symlink issues. but this > broke karaf now for platforms which do not support "readlink". we should make > it optional. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KARAF-4865) Karaf startup no longer works on platforms without "readlink"
[ https://issues.apache.org/jira/browse/KARAF-4865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-4865: Fix Version/s: 4.0.8 4.1.0 > Karaf startup no longer works on platforms without "readlink" > - > > Key: KARAF-4865 > URL: https://issues.apache.org/jira/browse/KARAF-4865 > Project: Karaf > Issue Type: Bug > Components: karaf-core >Reporter: Fabian Lange > Fix For: 4.1.0, 4.0.8 > > > With KARAF-4564 we used "readlink" to resolve some symlink issues. but this > broke karaf now for platforms which do not support "readlink". we should make > it optional. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (KARAF-4878) Cellar Hazelcast unresponsive when ETH Down
[
https://issues.apache.org/jira/browse/KARAF-4878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré reassigned KARAF-4878:
---
Assignee: Jean-Baptiste Onofré
> Cellar Hazelcast unresponsive when ETH Down
> ---
>
> Key: KARAF-4878
> URL: https://issues.apache.org/jira/browse/KARAF-4878
> Project: Karaf
> Issue Type: Bug
> Components: cellar-hazelcast
>Affects Versions: 4.0.5
> Environment: Redhat Linux 7.2, CentOS 7.2
>Reporter: Suresh Perumal
>Assignee: Jean-Baptiste Onofré
>Priority: Blocker
>
> Cluster is configured with 2 Nodes. They are up and running.
> As part of fail-over scenario simulation. We are trying to test "ETHERNET
> down scenario" by running "/etc/sysconfig/network-scripts/ifdown eth0"
> command on the first node.
> During this scenario we are shutting down the first node where the ETH is
> down by using monitoring scripts(in-house scripts). The second node(Among
> those two nodes) is kept alive.
> Second Node's Hazelcast is not accessible for more than 15 minutes. We are
> getting bellow exception and no operation related to Hazelcast is working.
> Applications whichever uses hazelcast kept frozen.
> Invocation | 52 - com.hazelcast - 3.5.2 |
> [10.249.50.80]:5701 [cellar] [3.5.2] While asking 'is-executing': Invocation{
> serviceName='hz:impl:mapService', op=PutOperation{unacknowledged-alarm},
> partitionId=165, replicaIndex=0, tryCount=250, tryPauseMillis=500,
> invokeCount=1, callTimeout=6, target=Address[10.249.50.79]:5701,
> backupsExpected=0, backupsCompleted=0}
> java.util.concurrent.TimeoutException: Call Invocation{
> serviceName='hz:impl:mapService',
> op=com.hazelcast.spi.impl.operationservice.impl.operations.IsStillExecutingOperation{serviceName='hz:impl:mapService',
> partitionId=-1, callId=2114, invocationTime=1480511190143, waitTimeout=-1,
> callTimeout=5000}, partitionId=-1, replicaIndex=0, tryCount=0,
> tryPauseMillis=0, invokeCount=1, callTimeout=5000,
> target=Address[10.249.50.79]:5701, backupsExpected=0, backupsCompleted=0}
> encountered a timeout
> at
> com.hazelcast.spi.impl.operationservice.impl.InvocationFuture.resolveApplicationResponse(InvocationFuture.java:366)[52:com.hazelcast:3.5.2]
> at
> com.hazelcast.spi.impl.operationservice.impl.InvocationFuture.resolveApplicationResponseOrThrowException(InvocationFuture.java:334)[52:com.hazelcast:3.5.2]
> at
> com.hazelcast.spi.impl.operationservice.impl.InvocationFuture.get(InvocationFuture.java:225)[52:com.hazelcast:3.5.2]
> at
> com.hazelcast.spi.impl.operationservice.impl.IsStillRunningService.isOperationExecuting(IsStillRunningService.java:85)[52:com.hazelcast:3.5.2]
> at
> com.hazelcast.spi.impl.operationservice.impl.InvocationFuture.waitForResponse(InvocationFuture.java:275)[52:com.hazelcast:3.5.2]
> at
> com.hazelcast.spi.impl.operationservice.impl.InvocationFuture.get(InvocationFuture.java:224)[52:com.hazelcast:3.5.2]
> at
> com.hazelcast.spi.impl.operationservice.impl.InvocationFuture.get(InvocationFuture.java:204)[52:com.hazelcast:3.5.2]
> at
> com.hazelcast.map.impl.proxy.MapProxySupport.invokeOperation(MapProxySupport.java:456)[52:com.hazelcast:3.5.2]
> at
> com.hazelcast.map.impl.proxy.MapProxySupport.putInternal(MapProxySupport.java:417)[52:com.hazelcast:3.5.2]
> at
> com.hazelcast.map.impl.proxy.MapProxyImpl.put(MapProxyImpl.java:97)[52:com.hazelcast:3.5.2]
> at
> com.hazelcast.map.impl.proxy.MapProxyImpl.put(MapProxyImpl.java:87)[52:com.hazelcast:3.5.2]
> at
> com.fujitsu.fnc.emf.fpmplatform.cachemanager.HazelcastCacheManagerMapServiceImpl.addToMap(HazelcastCacheManagerMapServiceImpl.java:87)[209:FPMHazelcastCache:4.1.0.SNAPSHOT]
> at Proxy1897a82c_c032_4a5c_9839_e71cb2af452a.addToMap(Unknown
> Source)[:]
> at
> com.fujitsu.fnc.ngemf.fm.server.impl.FpmConsumerTask.prepareJSON(FpmConsumerTask.java:151)[235:com.fujitsu.fnc.ngemf.fm.server.impl:4.1.0.SNAPSHOT]
> at
> com.fujitsu.fnc.ngemf.fm.server.impl.FpmConsumerTask.run(FpmConsumerTask.java:244)[235:com.fujitsu.fnc.ngemf.fm.server.impl:4.1.0.SNAPSHOT]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_66]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_66]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_66]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745)[:1.8.0_66]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (KARAF-4564) Can't start karaf using symbolic link
[ https://issues.apache.org/jira/browse/KARAF-4564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré reassigned KARAF-4564: --- Assignee: Jean-Baptiste Onofré > Can't start karaf using symbolic link > -- > > Key: KARAF-4564 > URL: https://issues.apache.org/jira/browse/KARAF-4564 > Project: Karaf > Issue Type: Bug >Affects Versions: 3.0.6 > Environment: Ubuntu (Linux vagrant 3.19.0-25-generic > #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015 x86_64 x86_64 x86_64 > GNU/Linux) > OSX (Darwin inocybe.local 14.5.0 Darwin Kernel Version 14.5.0: Tue Sep 1 > 21:23:09 PDT 2015; root:xnu-2782.50.1~1/RELEASE_X86_64 x86_64) > Solaris (SunOS solaris11.3 5.11 11.3 i86pc i386 i86pc) >Reporter: Alexis de Talhouët >Assignee: Jean-Baptiste Onofré > Fix For: 4.1.0, 3.0.7, 4.0.8 > > > When using a symbolic link to use the scripts defined here: > https://github.com/apache/karaf/tree/karaf-3.0.6/assemblies/features/framework/src/main/filtered-resources/resources/bin > e.g. karaf or client and so on, it's failing to start the container and show > this error: > Error: Could not find or load main class org.apache.karaf.main.Main > This issue is related to the DIRNAME variable and the way it is setup. > This bug has been found in OpenDaylight, here is the ticket with more > information https://bugs.opendaylight.org/show_bug.cgi?id=6027 > I have also propose a candidate fix in ODL: > https://git.opendaylight.org/gerrit/#/c/39982/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KARAF-4564) Can't start karaf using symbolic link
[ https://issues.apache.org/jira/browse/KARAF-4564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-4564: Fix Version/s: (was: 4.0.6) 4.0.8 > Can't start karaf using symbolic link > -- > > Key: KARAF-4564 > URL: https://issues.apache.org/jira/browse/KARAF-4564 > Project: Karaf > Issue Type: Bug >Affects Versions: 3.0.6 > Environment: Ubuntu (Linux vagrant 3.19.0-25-generic > #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015 x86_64 x86_64 x86_64 > GNU/Linux) > OSX (Darwin inocybe.local 14.5.0 Darwin Kernel Version 14.5.0: Tue Sep 1 > 21:23:09 PDT 2015; root:xnu-2782.50.1~1/RELEASE_X86_64 x86_64) > Solaris (SunOS solaris11.3 5.11 11.3 i86pc i386 i86pc) >Reporter: Alexis de Talhouët > Fix For: 4.1.0, 3.0.7, 4.0.8 > > > When using a symbolic link to use the scripts defined here: > https://github.com/apache/karaf/tree/karaf-3.0.6/assemblies/features/framework/src/main/filtered-resources/resources/bin > e.g. karaf or client and so on, it's failing to start the container and show > this error: > Error: Could not find or load main class org.apache.karaf.main.Main > This issue is related to the DIRNAME variable and the way it is setup. > This bug has been found in OpenDaylight, here is the ticket with more > information https://bugs.opendaylight.org/show_bug.cgi?id=6027 > I have also propose a candidate fix in ODL: > https://git.opendaylight.org/gerrit/#/c/39982/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (KARAF-4850) Be able to specify several object names for the JMX collector
[
https://issues.apache.org/jira/browse/KARAF-4850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré reassigned KARAF-4850:
---
Assignee: Jean-Baptiste Onofré
> Be able to specify several object names for the JMX collector
> -
>
> Key: KARAF-4850
> URL: https://issues.apache.org/jira/browse/KARAF-4850
> Project: Karaf
> Issue Type: Improvement
> Components: decanter
>Affects Versions: decanter-1.2.0, decanter-1.3.0
>Reporter: Vincent Zurczak
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
> Fix For: decanter-1.4.0
>
>
> When using the JMX collector, there is a property called *object.name*, which
> can be a query for MBeans. However, the syntax of ObjectName is too poor IMO.
> And gathering all the MBeans information can result in sending too much data
> to the appender (e.g. ElasticSearch).
> It would be very convenient if one could customize which MBeans are retrieved
> exactly, as a list, in the same configuration file.
> Example:
> {quote}
> object.name = \
> java.lang:type=Memory,name=HeapMemoryUsage |\
> java.lang:type=Memory,name=NonHeapMemoryUsage |\
> java.lang:type=OperatingSystem,name=SystemLoadAverage |\
> java.lang:type=OperatingSystem,name=SystemCpuLoad |\
> java.lang:type=OperatingSystem,name=ProcessCpuLoad |\
> java.lang:type=OperatingSystem,name=FreePhysicalMemorySize |\
> java.lang:type=Threading,name=ThreadCount
> {quote}
> I suggest to use the pipe character as a separator.
> Or, we could use the base property as a prefix.
> {quote}
> object.name.1=java.lang:type=Memory,name=HeapMemoryUsage
> object.name.2=java.lang:type=Memory,name=NonHeapMemoryUsage
> object.name.3=java.lang:type=OperatingSystem,name=SystemLoadAverage
> object.name.4=java.lang:type=OperatingSystem,name=SystemCpuLoad
> object.name.5=java.lang:type=OperatingSystem,name=ProcessCpuLoad
> object.name.6=java.lang:type=OperatingSystem,name=FreePhysicalMemorySize
> object.name.7=java.lang:type=Threading,name=ThreadCount
> {quote}
> In terms of performance, it should not have a major impact with respect to
> the current implementation. We need to parse the list of values and iterate
> over it to fullfill the set of ObjectNames. Obviously, this could be achieved
> by creating several CFG files. But you would have to copy the JMX settings
> over and over again. IMO, it is better to have one configuration file per JMX
> configuration.
> I could work on it and submit a patch if necessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (KARAF-4852) Minor issues with start script
[ https://issues.apache.org/jira/browse/KARAF-4852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-4852: Fix Version/s: 4.1.0 > Minor issues with start script > -- > > Key: KARAF-4852 > URL: https://issues.apache.org/jira/browse/KARAF-4852 > Project: Karaf > Issue Type: Bug >Affects Versions: 4.0.7 >Reporter: Lars Kiesow >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 4.1.0, 4.0.8 > > > If a cd command fails in the start script the following behavior is undefined > and could potentially cause problems. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KARAF-4849) Corrupt EventAdmin file in etc
[ https://issues.apache.org/jira/browse/KARAF-4849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-4849: Fix Version/s: 4.1.0 > Corrupt EventAdmin file in etc > -- > > Key: KARAF-4849 > URL: https://issues.apache.org/jira/browse/KARAF-4849 > Project: Karaf > Issue Type: Bug > Components: karaf-core >Affects Versions: 4.0.7 >Reporter: Kai Kreuzer >Priority: Minor > Fix For: 4.1.0, 4.0.8 > > > In the Karaf 4.0.7 distro, there is a file > org.apache.felix.eventadmin.impl.EventAdmin > with the content: > " > org.apache.felix.eventadmin.AddTimestamp=true > org.apache.felix.eventadmin.AddSubject=true > " > I'd assume it should have a .cfg suffix and no tabs in front of its entries. > See > http://karaf.922171.n3.nabble.com/Corrupt-EventAdmin-file-in-etc-tt4048586.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KARAF-4849) Corrupt EventAdmin file in etc
[ https://issues.apache.org/jira/browse/KARAF-4849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-4849: Component/s: karaf-core > Corrupt EventAdmin file in etc > -- > > Key: KARAF-4849 > URL: https://issues.apache.org/jira/browse/KARAF-4849 > Project: Karaf > Issue Type: Bug > Components: karaf-core >Affects Versions: 4.0.7 >Reporter: Kai Kreuzer >Priority: Minor > Fix For: 4.1.0, 4.0.8 > > > In the Karaf 4.0.7 distro, there is a file > org.apache.felix.eventadmin.impl.EventAdmin > with the content: > " > org.apache.felix.eventadmin.AddTimestamp=true > org.apache.felix.eventadmin.AddSubject=true > " > I'd assume it should have a .cfg suffix and no tabs in front of its entries. > See > http://karaf.922171.n3.nabble.com/Corrupt-EventAdmin-file-in-etc-tt4048586.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KARAF-4850) Be able to specify several object names for the JMX collector
[
https://issues.apache.org/jira/browse/KARAF-4850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated KARAF-4850:
Fix Version/s: decanter-1.4.0
> Be able to specify several object names for the JMX collector
> -
>
> Key: KARAF-4850
> URL: https://issues.apache.org/jira/browse/KARAF-4850
> Project: Karaf
> Issue Type: Improvement
> Components: decanter
>Affects Versions: decanter-1.2.0, decanter-1.3.0
>Reporter: Vincent Zurczak
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
> Fix For: decanter-1.4.0
>
>
> When using the JMX collector, there is a property called *object.name*, which
> can be a query for MBeans. However, the syntax of ObjectName is too poor IMO.
> And gathering all the MBeans information can result in sending too much data
> to the appender (e.g. ElasticSearch).
> It would be very convenient if one could customize which MBeans are retrieved
> exactly, as a list, in the same configuration file.
> Example:
> {quote}
> object.name = \
> java.lang:type=Memory,name=HeapMemoryUsage |\
> java.lang:type=Memory,name=NonHeapMemoryUsage |\
> java.lang:type=OperatingSystem,name=SystemLoadAverage |\
> java.lang:type=OperatingSystem,name=SystemCpuLoad |\
> java.lang:type=OperatingSystem,name=ProcessCpuLoad |\
> java.lang:type=OperatingSystem,name=FreePhysicalMemorySize |\
> java.lang:type=Threading,name=ThreadCount
> {quote}
> I suggest to use the pipe character as a separator.
> Or, we could use the base property as a prefix.
> {quote}
> object.name.1=java.lang:type=Memory,name=HeapMemoryUsage
> object.name.2=java.lang:type=Memory,name=NonHeapMemoryUsage
> object.name.3=java.lang:type=OperatingSystem,name=SystemLoadAverage
> object.name.4=java.lang:type=OperatingSystem,name=SystemCpuLoad
> object.name.5=java.lang:type=OperatingSystem,name=ProcessCpuLoad
> object.name.6=java.lang:type=OperatingSystem,name=FreePhysicalMemorySize
> object.name.7=java.lang:type=Threading,name=ThreadCount
> {quote}
> In terms of performance, it should not have a major impact with respect to
> the current implementation. We need to parse the list of values and iterate
> over it to fullfill the set of ObjectNames. Obviously, this could be achieved
> by creating several CFG files. But you would have to copy the JMX settings
> over and over again. IMO, it is better to have one configuration file per JMX
> configuration.
> I could work on it and submit a patch if necessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (KARAF-4849) Corrupt EventAdmin file in etc
[ https://issues.apache.org/jira/browse/KARAF-4849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré reassigned KARAF-4849: --- Assignee: Jean-Baptiste Onofré > Corrupt EventAdmin file in etc > -- > > Key: KARAF-4849 > URL: https://issues.apache.org/jira/browse/KARAF-4849 > Project: Karaf > Issue Type: Bug > Components: karaf-core >Affects Versions: 4.0.7 >Reporter: Kai Kreuzer >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 4.1.0, 4.0.8 > > > In the Karaf 4.0.7 distro, there is a file > org.apache.felix.eventadmin.impl.EventAdmin > with the content: > " > org.apache.felix.eventadmin.AddTimestamp=true > org.apache.felix.eventadmin.AddSubject=true > " > I'd assume it should have a .cfg suffix and no tabs in front of its entries. > See > http://karaf.922171.n3.nabble.com/Corrupt-EventAdmin-file-in-etc-tt4048586.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KARAF-4564) Can't start karaf using symbolic link
[
https://issues.apache.org/jira/browse/KARAF-4564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15722768#comment-15722768
]
Guillaume Nodet commented on KARAF-4564:
Fwiw, I'd rather stick with {{/bin/sh}} instead of {{/bin/bash}} which is not
available by default on FreeBSD.
> Can't start karaf using symbolic link
> --
>
> Key: KARAF-4564
> URL: https://issues.apache.org/jira/browse/KARAF-4564
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 3.0.6
> Environment: Ubuntu (Linux vagrant 3.19.0-25-generic
> #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015 x86_64 x86_64 x86_64
> GNU/Linux)
> OSX (Darwin inocybe.local 14.5.0 Darwin Kernel Version 14.5.0: Tue Sep 1
> 21:23:09 PDT 2015; root:xnu-2782.50.1~1/RELEASE_X86_64 x86_64)
> Solaris (SunOS solaris11.3 5.11 11.3 i86pc i386 i86pc)
>Reporter: Alexis de Talhouët
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.1.0, 3.0.7, 4.0.8
>
>
> When using a symbolic link to use the scripts defined here:
> https://github.com/apache/karaf/tree/karaf-3.0.6/assemblies/features/framework/src/main/filtered-resources/resources/bin
> e.g. karaf or client and so on, it's failing to start the container and show
> this error:
> Error: Could not find or load main class org.apache.karaf.main.Main
> This issue is related to the DIRNAME variable and the way it is setup.
> This bug has been found in OpenDaylight, here is the ticket with more
> information https://bugs.opendaylight.org/show_bug.cgi?id=6027
> I have also propose a candidate fix in ODL:
> https://git.opendaylight.org/gerrit/#/c/39982/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (KARAF-4564) Can't start karaf using symbolic link
[ https://issues.apache.org/jira/browse/KARAF-4564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15722772#comment-15722772 ] Jean-Baptiste Onofré commented on KARAF-4564: - Yes agree. I'm cleaning up the scripts. > Can't start karaf using symbolic link > -- > > Key: KARAF-4564 > URL: https://issues.apache.org/jira/browse/KARAF-4564 > Project: Karaf > Issue Type: Bug >Affects Versions: 3.0.6 > Environment: Ubuntu (Linux vagrant 3.19.0-25-generic > #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015 x86_64 x86_64 x86_64 > GNU/Linux) > OSX (Darwin inocybe.local 14.5.0 Darwin Kernel Version 14.5.0: Tue Sep 1 > 21:23:09 PDT 2015; root:xnu-2782.50.1~1/RELEASE_X86_64 x86_64) > Solaris (SunOS solaris11.3 5.11 11.3 i86pc i386 i86pc) >Reporter: Alexis de Talhouët >Assignee: Jean-Baptiste Onofré > Fix For: 4.1.0, 3.0.7, 4.0.8 > > > When using a symbolic link to use the scripts defined here: > https://github.com/apache/karaf/tree/karaf-3.0.6/assemblies/features/framework/src/main/filtered-resources/resources/bin > e.g. karaf or client and so on, it's failing to start the container and show > this error: > Error: Could not find or load main class org.apache.karaf.main.Main > This issue is related to the DIRNAME variable and the way it is setup. > This bug has been found in OpenDaylight, here is the ticket with more > information https://bugs.opendaylight.org/show_bug.cgi?id=6027 > I have also propose a candidate fix in ODL: > https://git.opendaylight.org/gerrit/#/c/39982/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KARAF-4680) Karaf shell console (jline 3) leaves the terminal in "bad" state
[
https://issues.apache.org/jira/browse/KARAF-4680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15723383#comment-15723383
]
ASF subversion and git services commented on KARAF-4680:
Commit 0cf806b53565f3c2fa9812e46475adfe6430cefa in karaf's branch
refs/heads/master from [~gnt]
[ https://git-wip-us.apache.org/repos/asf?p=karaf.git;h=0cf806b ]
[KARAF-4680] Karaf shell console (jline 3) leaves the terminal in "bad" state
Upgrade to JLine 3.1.1
> Karaf shell console (jline 3) leaves the terminal in "bad" state
>
>
> Key: KARAF-4680
> URL: https://issues.apache.org/jira/browse/KARAF-4680
> Project: Karaf
> Issue Type: Bug
> Components: karaf-shell
>Affects Versions: 4.1.0
>Reporter: Jean-Baptiste Onofré
>Assignee: Guillaume Nodet
> Fix For: 4.1.0
>
>
> Karaf 4.1.x is now using JLine 3. The Karaf shell works pretty well.
> However, when stopping Karaf 4.1.x (using CTRL-D), the Linux terminal is left
> in a bad state (input and output stream are "lost").
> We have to do a {{reset}} to have a terminal back to "normal".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (KARAF-4680) Karaf shell console (jline 3) leaves the terminal in "bad" state
[
https://issues.apache.org/jira/browse/KARAF-4680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved KARAF-4680.
Resolution: Fixed
> Karaf shell console (jline 3) leaves the terminal in "bad" state
>
>
> Key: KARAF-4680
> URL: https://issues.apache.org/jira/browse/KARAF-4680
> Project: Karaf
> Issue Type: Bug
> Components: karaf-shell
>Affects Versions: 4.1.0
>Reporter: Jean-Baptiste Onofré
>Assignee: Guillaume Nodet
> Fix For: 4.1.0
>
>
> Karaf 4.1.x is now using JLine 3. The Karaf shell works pretty well.
> However, when stopping Karaf 4.1.x (using CTRL-D), the Linux terminal is left
> in a bad state (input and output stream are "lost").
> We have to do a {{reset}} to have a terminal back to "normal".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (KARAF-4620) ACL default configuration for feature:start/stop missing
[ https://issues.apache.org/jira/browse/KARAF-4620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15724225#comment-15724225 ] Xilai Dai commented on KARAF-4620: -- It's only fixed on master, but not backport to karaf-4.0.x branch. > ACL default configuration for feature:start/stop missing > > > Key: KARAF-4620 > URL: https://issues.apache.org/jira/browse/KARAF-4620 > Project: Karaf > Issue Type: Bug > Components: karaf-security, karaf-shell >Affects Versions: 4.0.3 >Reporter: Christian Schmülling >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 4.1.0, 4.0.6 > > > The ACL default configuration down't cover the commands feature:start > feature:stop in org.apache.karaf.command.acl.feature.cfg. > Each user who is able to login is able to start and stop features. > FIX: Add these two lines: > start = admin > stop = admin > HOTFIX at a running system: > config:edit org.apache.karaf.command.acl.feature > config:property-set start admin > config:property-set stop admin > config:update -- This message was sent by Atlassian JIRA (v6.3.4#6332)
