[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)
[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-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] [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-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] [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] [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] [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-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] [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] [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] [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] [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] [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] [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] [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)