[jira] [Resolved] (KARAF-4882) keystore.jks update in karaf requires force restart
[ https://issues.apache.org/jira/browse/KARAF-4882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Achim Nierbeck resolved KARAF-4882. --- Resolution: Won't Fix Is not an issue of Karaf itself. Pax Web doesn't monitor the key file. If you want to have an update without restart, just restart the pax-web-runtime bundle, that should take care of it. > keystore.jks update in karaf requires force restart > --- > > Key: KARAF-4882 > URL: https://issues.apache.org/jira/browse/KARAF-4882 > Project: Karaf > Issue Type: Bug > Components: karaf-core >Affects Versions: 4.0.5 > Environment: Cent OS 7.2, RHEL 7.2 >Reporter: Suresh Perumal >Priority: Blocker > > We are using Karaf 4.0.5, 4.0.6. > We are using self signed certificate for https support. > There are some scenarios where the certificate will get expired where we need > to regenerate the certificate again. > During this scenario, newly generated keystore.jks getting stored in Karaf. > ,KARAF_HOME/etc folder. > But looks like it is not picking up the latest keystore.jks and it requires > restart of karaf server. > To some extent we will not be able to restart the karaf server which might > not be correct approach. > I would like to know the approach to force update of certificates without > restarts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KARAF-4878) Cellar Hazelcast unresponsive when ETH Down
[
https://issues.apache.org/jira/browse/KARAF-4878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15727960#comment-15727960
]
Jean-Baptiste Onofré commented on KARAF-4878:
-
I'm trying in {{etc/hazelcast.xml}} first.
> 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] [Commented] (KARAF-4878) Cellar Hazelcast unresponsive when ETH Down
[
https://issues.apache.org/jira/browse/KARAF-4878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15727946#comment-15727946
]
Suresh Perumal commented on KARAF-4878:
---
Can we below two attributes and get reduce the wait time?
hazelcast.max.no.heartbeat.seconds
hazelcast.max.no.master.confirmation.seconds
Will there be any issues if we change the above said attributes.
Below are changes tried out in our environment
As part of KARAF CONTAINER
KARAF_HOME/bin/setenv file
export EXTRA_JAVA_OPTS="-Dhazelcast.max.no.heartbeat.seconds=60
-Dhazelcast.max.no.master.confirmation.seconds=60"
http://docs.hazelcast.org/docs/2.2/manual/html/ch12s06.html
> 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
[jira] [Commented] (KARAF-4882) keystore.jks update in karaf requires force restart
[ https://issues.apache.org/jira/browse/KARAF-4882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15727781#comment-15727781 ] Suresh Perumal commented on KARAF-4882: --- At runtime we just wanted to update the keystore.jks. But still it works only when karaf got restarted. It is able to pickup the new keystore.jks only when Karaf gets stopped and restarted. > keystore.jks update in karaf requires force restart > --- > > Key: KARAF-4882 > URL: https://issues.apache.org/jira/browse/KARAF-4882 > Project: Karaf > Issue Type: Bug > Components: karaf-core >Affects Versions: 4.0.5 > Environment: Cent OS 7.2, RHEL 7.2 >Reporter: Suresh Perumal >Priority: Blocker > > We are using Karaf 4.0.5, 4.0.6. > We are using self signed certificate for https support. > There are some scenarios where the certificate will get expired where we need > to regenerate the certificate again. > During this scenario, newly generated keystore.jks getting stored in Karaf. > ,KARAF_HOME/etc folder. > But looks like it is not picking up the latest keystore.jks and it requires > restart of karaf server. > To some extent we will not be able to restart the karaf server which might > not be correct approach. > I would like to know the approach to force update of certificates without > restarts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KARAF-4882) keystore.jks update in karaf requires force restart
[ https://issues.apache.org/jira/browse/KARAF-4882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15727776#comment-15727776 ] Suresh Perumal commented on KARAF-4882: --- Below is the content used in pax-web. We are creating keystore.jks with java keytool command We use this key - self signed certificate during https acess. org.ops4j.pax.web.cfg org.osgi.service.http.port=8181 org.osgi.service.http.port.secure=8443 org.osgi.service.http.secure.enabled=true org.ops4j.pax.web.ssl.keystore=/opt/vira/fpm4.1/karaf/etc/keystores/keystore.jks org.ops4j.pax.web.ssl.password=password org.ops4j.pax.web.ssl.keypassword=password org.ops4j.pax.web.config.file=/opt/vira/fpm4.1/karaf/etc/jetty.xml > keystore.jks update in karaf requires force restart > --- > > Key: KARAF-4882 > URL: https://issues.apache.org/jira/browse/KARAF-4882 > Project: Karaf > Issue Type: Bug > Components: karaf-core >Affects Versions: 4.0.5 > Environment: Cent OS 7.2, RHEL 7.2 >Reporter: Suresh Perumal >Priority: Blocker > > We are using Karaf 4.0.5, 4.0.6. > We are using self signed certificate for https support. > There are some scenarios where the certificate will get expired where we need > to regenerate the certificate again. > During this scenario, newly generated keystore.jks getting stored in Karaf. > ,KARAF_HOME/etc folder. > But looks like it is not picking up the latest keystore.jks and it requires > restart of karaf server. > To some extent we will not be able to restart the karaf server which might > not be correct approach. > I would like to know the approach to force update of certificates without > restarts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (KARAF-4882) keystore.jks update in karaf requires force restart
Suresh Perumal created KARAF-4882: - Summary: keystore.jks update in karaf requires force restart Key: KARAF-4882 URL: https://issues.apache.org/jira/browse/KARAF-4882 Project: Karaf Issue Type: Bug Components: karaf-core Affects Versions: 4.0.5 Environment: Cent OS 7.2, RHEL 7.2 Reporter: Suresh Perumal Priority: Blocker We are using Karaf 4.0.5, 4.0.6. We are using self signed certificate for https support. There are some scenarios where the certificate will get expired where we need to regenerate the certificate again. During this scenario, newly generated keystore.jks getting stored in Karaf. ,KARAF_HOME/etc folder. But looks like it is not picking up the latest keystore.jks and it requires restart of karaf server. To some extent we will not be able to restart the karaf server which might not be correct approach. I would like to know the approach to force update of certificates without restarts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KARAF-4852) Minor issues with start script
[ https://issues.apache.org/jira/browse/KARAF-4852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15727145#comment-15727145 ] Lars Kiesow commented on KARAF-4852: @gnodet, is there a specific reason to switch to /bin/sh? There are some things in this script not defined in a POSIX shell but ensured to work with bash. For example, in POSIX sh, ulimit -n is undefined. For more details try ShellCheck. > 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] [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=15727068#comment-15727068
]
ASF subversion and git services commented on KARAF-4564:
Commit b1fda013db9827502aff0b5a9a31c34110f66423 in karaf's branch
refs/heads/master from [~gnt]
[ https://git-wip-us.apache.org/repos/asf?p=karaf.git;h=b1fda01 ]
[KARAF-4564] [KARAF-4852] [KARAF-4865] Improve the main karaf script
* use /bin/sh
* do not rely on readlink, but use 'ls -l'
* check exit code when changing directory
* verify ulimit availability
* use 'command -v' instead of 'type'
* support spaces in the JAVA path
* do not use {} expansion for file names
* fix endorsed/ext dirs on cygwin/mingw
> 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-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:comment-tabpanel=15727071#comment-15727071
]
ASF subversion and git services commented on KARAF-4865:
Commit b1fda013db9827502aff0b5a9a31c34110f66423 in karaf's branch
refs/heads/master from [~gnt]
[ https://git-wip-us.apache.org/repos/asf?p=karaf.git;h=b1fda01 ]
[KARAF-4564] [KARAF-4852] [KARAF-4865] Improve the main karaf script
* use /bin/sh
* do not rely on readlink, but use 'ls -l'
* check exit code when changing directory
* verify ulimit availability
* use 'command -v' instead of 'type'
* support spaces in the JAVA path
* do not use {} expansion for file names
* fix endorsed/ext dirs on cygwin/mingw
> 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] [Commented] (KARAF-4852) Minor issues with start script
[
https://issues.apache.org/jira/browse/KARAF-4852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15727069#comment-15727069
]
ASF subversion and git services commented on KARAF-4852:
Commit b1fda013db9827502aff0b5a9a31c34110f66423 in karaf's branch
refs/heads/master from [~gnt]
[ https://git-wip-us.apache.org/repos/asf?p=karaf.git;h=b1fda01 ]
[KARAF-4564] [KARAF-4852] [KARAF-4865] Improve the main karaf script
* use /bin/sh
* do not rely on readlink, but use 'ls -l'
* check exit code when changing directory
* verify ulimit availability
* use 'command -v' instead of 'type'
* support spaces in the JAVA path
* do not use {} expansion for file names
* fix endorsed/ext dirs on cygwin/mingw
> 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] [Commented] (KARAF-4806) Some shell scripts include bashisms but use a /bin/sh shebang
[ https://issues.apache.org/jira/browse/KARAF-4806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15726759#comment-15726759 ] ASF GitHub Bot commented on KARAF-4806: --- Github user skitt closed the pull request at: https://github.com/apache/karaf/pull/256 > Some shell scripts include bashisms but use a /bin/sh shebang > - > > Key: KARAF-4806 > URL: https://issues.apache.org/jira/browse/KARAF-4806 > Project: Karaf > Issue Type: Bug >Affects Versions: 3.0.8, 4.0.7 >Reporter: Stephen Kitt >Assignee: Jean-Baptiste Onofré > > The client, instance and shell scripts use ulimit and type, but these are > bashisms. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (KARAF-4881) Deleting the only user from a group deletes the group in users.properties
Paul McCulloch created KARAF-4881: - Summary: Deleting the only user from a group deletes the group in users.properties Key: KARAF-4881 URL: https://issues.apache.org/jira/browse/KARAF-4881 Project: Karaf Issue Type: Bug Components: karaf-security Affects Versions: 4.0.7 Reporter: Paul McCulloch In a fresh Karaf issue: >jaas:realm-manage --realm karaf --module >org.apache.karaf.jaas.modules.properties.PropertiesLoginModule >jaas:user-delete karaf >jaas:update users.properties is now essentially empty & the group definition for admingroup is gone. My use case is setting the karaf user password by deleting and re-adding the karaf user. The workaround is to add a temporary user to the admin group before deleting the karaf user. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KARAF-4878) Cellar Hazelcast unresponsive when ETH Down
[
https://issues.apache.org/jira/browse/KARAF-4878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15726065#comment-15726065
]
Jean-Baptiste Onofré commented on KARAF-4878:
-
I'm working on it.
> 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] [Commented] (KARAF-4878) Cellar Hazelcast unresponsive when ETH Down
[
https://issues.apache.org/jira/browse/KARAF-4878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15726044#comment-15726044
]
Suresh Perumal commented on KARAF-4878:
---
Any update on this issue?
> 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] [Commented] (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:comment-tabpanel=15725903#comment-15725903
]
ASF subversion and git services commented on KARAF-4850:
Commit 8333068f0624f7c9e2e85fc5f6f5f82da75e83e4 in karaf-decanter's branch
refs/heads/master from [~jbonofre]
[ https://git-wip-us.apache.org/repos/asf?p=karaf-decanter.git;h=8333068 ]
[KARAF-4850] This closes #17
> 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] [Commented] (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:comment-tabpanel=15725902#comment-15725902
]
ASF subversion and git services commented on KARAF-4850:
Commit 605904a6f09b98c92c7462d06baf968cddbd3ef7 in karaf-decanter's branch
refs/heads/master from [~vzurczak]
[ https://git-wip-us.apache.org/repos/asf?p=karaf-decanter.git;h=605904a ]
[KARAF-4850] Be able to specify several object names for the JMX collector
> 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] [Resolved] (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é resolved KARAF-4850.
-
Resolution: Fixed
> 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-4836) Incorrect behaviour of the auto-completion of file path in command export-bundles
[
https://issues.apache.org/jira/browse/KARAF-4836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned KARAF-4836:
--
Assignee: Guillaume Nodet
> Incorrect behaviour of the auto-completion of file path in command
> export-bundles
> -
>
> Key: KARAF-4836
> URL: https://issues.apache.org/jira/browse/KARAF-4836
> Project: Karaf
> Issue Type: Bug
> Components: karaf-shell
>Affects Versions: 4.1.0
>Reporter: Lijun Liao
>Assignee: Guillaume Nodet
> Fix For: 4.1.0
>
>
> 1. The auto-completation converts relative path to absolute path.
> To reproduce start karaf and type
> {code}
> export-bundles jdbc dat
> {code}
> You will get
> {code}
> export-bundles jdbc
> /Users/lliao/Documents/source/t/apache-karaf-4.1.0-SNAPSHOT/./data/
> {code}
> However the following should be expected
> {code}
> export-bundles jdbc data
> {code}
> or
> {code}
> export-bundles jdbc ./data
> {code}
> 2. The auto-completation cannot handle '~' for home directory of current user.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (KARAF-4860) Upgrade to Felix WebConsole 4.2.16
[ https://issues.apache.org/jira/browse/KARAF-4860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved KARAF-4860. Resolution: Fixed Assignee: Guillaume Nodet (was: Jean-Baptiste Onofré) > Upgrade to Felix WebConsole 4.2.16 > -- > > Key: KARAF-4860 > URL: https://issues.apache.org/jira/browse/KARAF-4860 > Project: Karaf > Issue Type: Dependency upgrade > Components: karaf-webconsole >Reporter: Jean-Baptiste Onofré >Assignee: Guillaume Nodet > Fix For: 4.1.0, 4.0.8 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KARAF-4860) Upgrade to Felix WebConsole 4.2.16
[ https://issues.apache.org/jira/browse/KARAF-4860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15725436#comment-15725436 ] ASF subversion and git services commented on KARAF-4860: Commit 8dbc8595516b1068076b4d4ee606d2ba3ff078ad in karaf's branch refs/heads/karaf-4.0.x from [~gnt] [ https://git-wip-us.apache.org/repos/asf?p=karaf.git;h=8dbc859 ] [KARAF-4860] Upgrade to Felix WebConsole 4.2.16 > Upgrade to Felix WebConsole 4.2.16 > -- > > Key: KARAF-4860 > URL: https://issues.apache.org/jira/browse/KARAF-4860 > Project: Karaf > Issue Type: Dependency upgrade > Components: karaf-webconsole >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré > Fix For: 4.1.0, 4.0.8 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KARAF-4860) Upgrade to Felix WebConsole 4.2.16
[ https://issues.apache.org/jira/browse/KARAF-4860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15725434#comment-15725434 ] ASF subversion and git services commented on KARAF-4860: Commit 760fa3f31a8b8d19c3ebcb0eab63e901bc0aad71 in karaf's branch refs/heads/master from [~gnt] [ https://git-wip-us.apache.org/repos/asf?p=karaf.git;h=760fa3f ] [KARAF-4860] Upgrade to Felix WebConsole 4.2.16 > Upgrade to Felix WebConsole 4.2.16 > -- > > Key: KARAF-4860 > URL: https://issues.apache.org/jira/browse/KARAF-4860 > Project: Karaf > Issue Type: Dependency upgrade > Components: karaf-webconsole >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré > Fix For: 4.1.0, 4.0.8 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (KARAF-4873) keystore.jks update in karaf requires force restart
[ https://issues.apache.org/jira/browse/KARAF-4873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed KARAF-4873. -- Resolution: Won't Fix Assignee: Guillaume Nodet Note that you can simply restart the pax-web bundles and not the full karaf. You should raise an issue against the PAX-WEB project, as the fix would belong there. So I'm closing this issue. > keystore.jks update in karaf requires force restart > --- > > Key: KARAF-4873 > URL: https://issues.apache.org/jira/browse/KARAF-4873 > Project: Karaf > Issue Type: Bug > Components: cellar-http >Affects Versions: 4.0.5 > Environment: karaf 4.0.5/4.0.6 on Linux CentOS, RHEL Platform >Reporter: Suresh Perumal >Assignee: Guillaume Nodet > > We are using Karaf 4.0.5, 4.0.6. > We are using self signed certificate for https support. > There are some scenarios where the certificate will get expired where we need > to regenerate the certificate again. > During this scenario, newly generated keystore.jks getting stored in Karaf. > ,KARAF_HOME/etc folder. > But looks like it is not picking up the latest keystore.jks and it requires > restart of karaf server. > To some extent we will not be able to restart the karaf server which might > not be correct approach. > I would like to know the approach to force update of certificates without > restarts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KARAF-4873) keystore.jks update in karaf requires force restart
[ https://issues.apache.org/jira/browse/KARAF-4873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated KARAF-4873: --- Priority: Major (was: Blocker) > keystore.jks update in karaf requires force restart > --- > > Key: KARAF-4873 > URL: https://issues.apache.org/jira/browse/KARAF-4873 > Project: Karaf > Issue Type: Bug > Components: cellar-http >Affects Versions: 4.0.5 > Environment: karaf 4.0.5/4.0.6 on Linux CentOS, RHEL Platform >Reporter: Suresh Perumal > > We are using Karaf 4.0.5, 4.0.6. > We are using self signed certificate for https support. > There are some scenarios where the certificate will get expired where we need > to regenerate the certificate again. > During this scenario, newly generated keystore.jks getting stored in Karaf. > ,KARAF_HOME/etc folder. > But looks like it is not picking up the latest keystore.jks and it requires > restart of karaf server. > To some extent we will not be able to restart the karaf server which might > not be correct approach. > I would like to know the approach to force update of certificates without > restarts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (KARAF-4847) Cannot start feature pax-jetty with JDK 9
[
https://issues.apache.org/jira/browse/KARAF-4847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved KARAF-4847.
Resolution: Fixed
> Cannot start feature pax-jetty with JDK 9
> -
>
> Key: KARAF-4847
> URL: https://issues.apache.org/jira/browse/KARAF-4847
> Project: Karaf
> Issue Type: Bug
> Components: karaf-feature
>Affects Versions: 4.1.0
> Environment: Ubuntu
> JDK Early Access Releases 9 Build 146
>Reporter: Lijun Liao
>Assignee: Guillaume Nodet
>Priority: Critical
> Labels: java9
> Fix For: 4.1.0
>
> Attachments: karaf.log
>
>
> Steps to reproduce the error:
> 1. Start a terminal
> 2. Start karaf (bin/karaf)
> 3. Install feature pax-jetty (feature:install pax-jetty)
> Karaf shows the following message immediately
> {code}
> karaf@root()> feature:install pax-jetty xx:xx:xx
> Error executing command: java.lang.InterruptedException
> gogo: InterruptedException: null
> {code}
> After a while or being cancelled by CTRL + C, karaf ends up.
--
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 ] Guillaume Nodet updated KARAF-4849: --- Fix Version/s: (was: 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 >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 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-4824) Add Option to bundle:update which doesn't rewrite MANIFEST file
[ https://issues.apache.org/jira/browse/KARAF-4824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15725060#comment-15725060 ] ASF subversion and git services commented on KARAF-4824: Commit 856e734aa3d5c37a756ed82ef713521b9b45a8c1 in karaf's branch refs/heads/master from [~gnt] [ https://git-wip-us.apache.org/repos/asf?p=karaf.git;h=856e734 ] [KARAF-4824] Add Option to bundle:update which doesn't rewrite MANIFEST file > Add Option to bundle:update which doesn't rewrite MANIFEST file > --- > > Key: KARAF-4824 > URL: https://issues.apache.org/jira/browse/KARAF-4824 > Project: Karaf > Issue Type: New Feature > Components: karaf-shell >Affects Versions: 4.0.7 >Reporter: Markus Eckert >Assignee: Guillaume Nodet > Labels: bundle, shell, update > Fix For: 4.1.0 > > > Using the Karaf shell, if someone updates a bundle using the *bundle:update* > command, the command unzips the .jar file and manipulates the MANIFEST > without questioning it. > *BundleUtils.fixBundleWithUpdateLocation* is responsible for this. > This is a severe issue when using JAR files with signature (JRE jarsigner) > and signature checking. If a bundle is only allowed to start with a valid > signature this will break it and the bundle won't activate again. > Update of the bundles was done using: > *update file:/* > The only workaround is to uninstall the bundle and install it again. > An option to tell update if it should update the MANIFEST or not would be a > nice feature to have. > Maybe there is another CLI command to achieve this? Updating the bundle using > the Karaf Webconsole doesn't have this issue at all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (KARAF-4832) Cannot enter karaf command over multi lines
[
https://issues.apache.org/jira/browse/KARAF-4832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned KARAF-4832:
--
Assignee: Guillaume Nodet
> Cannot enter karaf command over multi lines
> ---
>
> Key: KARAF-4832
> URL: https://issues.apache.org/jira/browse/KARAF-4832
> Project: Karaf
> Issue Type: Bug
> Components: karaf-shell
>Affects Versions: 4.1.0
>Reporter: Lijun Liao
>Assignee: Guillaume Nodet
> Fix For: 4.1.0
>
>
> Steps to reproduce the problem:
> 1. In karaf shell, enter "echo \", then enter
> 2. In the new line, enter any text, then enter
> You should get the following error text:
> {code}
> karaf@root()> echo \ xx:xx:xx
> > demo-text
> gogo: CommandNotFoundException: Command not found: demo-text
> Command not found: demo-text
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (KARAF-4832) Cannot enter karaf command over multi lines
[
https://issues.apache.org/jira/browse/KARAF-4832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved KARAF-4832.
Resolution: Fixed
Fixed with the upgrade to jline 3.1.1
> Cannot enter karaf command over multi lines
> ---
>
> Key: KARAF-4832
> URL: https://issues.apache.org/jira/browse/KARAF-4832
> Project: Karaf
> Issue Type: Bug
> Components: karaf-shell
>Affects Versions: 4.1.0
>Reporter: Lijun Liao
>Assignee: Guillaume Nodet
> Fix For: 4.1.0
>
>
> Steps to reproduce the problem:
> 1. In karaf shell, enter "echo \", then enter
> 2. In the new line, enter any text, then enter
> You should get the following error text:
> {code}
> karaf@root()> echo \ xx:xx:xx
> > demo-text
> gogo: CommandNotFoundException: Command not found: demo-text
> Command not found: demo-text
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (KARAF-4824) Add Option to bundle:update which doesn't rewrite MANIFEST file
[ https://issues.apache.org/jira/browse/KARAF-4824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved KARAF-4824. Resolution: Fixed > Add Option to bundle:update which doesn't rewrite MANIFEST file > --- > > Key: KARAF-4824 > URL: https://issues.apache.org/jira/browse/KARAF-4824 > Project: Karaf > Issue Type: New Feature > Components: karaf-shell >Affects Versions: 4.0.7 >Reporter: Markus Eckert >Assignee: Guillaume Nodet > Labels: bundle, shell, update > Fix For: 4.1.0 > > > Using the Karaf shell, if someone updates a bundle using the *bundle:update* > command, the command unzips the .jar file and manipulates the MANIFEST > without questioning it. > *BundleUtils.fixBundleWithUpdateLocation* is responsible for this. > This is a severe issue when using JAR files with signature (JRE jarsigner) > and signature checking. If a bundle is only allowed to start with a valid > signature this will break it and the bundle won't activate again. > Update of the bundles was done using: > *update file:/* > The only workaround is to uninstall the bundle and install it again. > An option to tell update if it should update the MANIFEST or not would be a > nice feature to have. > Maybe there is another CLI command to achieve this? Updating the bundle using > the Karaf Webconsole doesn't have this issue at all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (KARAF-4880) Can't use Client from a script when passwords are encrypted
Paul McCulloch created KARAF-4880: - Summary: Can't use Client from a script when passwords are encrypted Key: KARAF-4880 URL: https://issues.apache.org/jira/browse/KARAF-4880 Project: Karaf Issue Type: Bug Affects Versions: 4.0.7 Reporter: Paul McCulloch Without the old -p option there is no straightforward way to use the client to connect to a karaf using encrypted password authentication. With clear text passwords client reads the passwords from users.properties. My use case is an (izpack) installer which uses the client to add features & apply configurations. The installer prompts the user for admin account details & should pass these to the client. Using SSH keys is problematic I believe. I would need the user (or the installer) to keep a copy of the key generated on initial installation for use in subsequent upgrades. My installer is cross platform, so relying on open SSH etc. as a workaround is problematic. The -p option was removed from client as part of KARAF-1475 (https://github.com/apache/karaf/commit/d6838dd5a12a13b99c534981273abdbbee5b7f22) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KARAF-4849) Corrupt EventAdmin file in etc
[ https://issues.apache.org/jira/browse/KARAF-4849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15725120#comment-15725120 ] Guillaume Nodet commented on KARAF-4849: The problem is not present in Karaf 4.1 distributions > 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.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] [Resolved] (KARAF-4838) The shell:source command does not forward Ctrl+C to the command being executed
[ https://issues.apache.org/jira/browse/KARAF-4838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved KARAF-4838. Resolution: Fixed > The shell:source command does not forward Ctrl+C to the command being executed > -- > > Key: KARAF-4838 > URL: https://issues.apache.org/jira/browse/KARAF-4838 > Project: Karaf > Issue Type: Bug > Components: karaf-shell >Affects Versions: 4.1.0 >Reporter: Lijun Liao >Assignee: Guillaume Nodet > Fix For: 4.1.0 > > > In karaf 4.0.7, the InterruptedException (triggered by CTRL + C) is forwarded > by the karaf shell to the commands executed via source. This forwarding is > useful since the application can then decide whether it should cancel the > action. However this forwarding has been deactivated in karaf 4.1.0. > Steps to reproduce the problem in Linux: > 1. Create a file demo.script that contains the line >"sleep 10" > 2. In karaf shell, execute the commands via > "source demo.scipt" > 3. In karaf shell, enter CTRL + C, you will see > "gogo: InterruptedException: null" instead of the expected "sleep: > interrupted" > Additionally, if you enter CTRL + D after step 3 to exit karaf, the > OS-terminal will be in invalid state. You cannot see what you enter in the > OS-terminal. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (KARAF-4824) Add Option to bundle:update which doesn't rewrite MANIFEST file
[ https://issues.apache.org/jira/browse/KARAF-4824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned KARAF-4824: -- Assignee: Guillaume Nodet > Add Option to bundle:update which doesn't rewrite MANIFEST file > --- > > Key: KARAF-4824 > URL: https://issues.apache.org/jira/browse/KARAF-4824 > Project: Karaf > Issue Type: New Feature > Components: karaf-shell >Affects Versions: 4.0.7 >Reporter: Markus Eckert >Assignee: Guillaume Nodet > Labels: bundle, shell, update > Fix For: 4.1.0 > > > Using the Karaf shell, if someone updates a bundle using the *bundle:update* > command, the command unzips the .jar file and manipulates the MANIFEST > without questioning it. > *BundleUtils.fixBundleWithUpdateLocation* is responsible for this. > This is a severe issue when using JAR files with signature (JRE jarsigner) > and signature checking. If a bundle is only allowed to start with a valid > signature this will break it and the bundle won't activate again. > Update of the bundles was done using: > *update file:/* > The only workaround is to uninstall the bundle and install it again. > An option to tell update if it should update the MANIFEST or not would be a > nice feature to have. > Maybe there is another CLI command to achieve this? Updating the bundle using > the Karaf Webconsole doesn't have this issue at all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KARAF-4824) Add Option to bundle:update which doesn't rewrite MANIFEST file
[
https://issues.apache.org/jira/browse/KARAF-4824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15724810#comment-15724810
]
Guillaume Nodet commented on KARAF-4824:
If you have the bundle id, you can easily do the following:
{code}
do-update = {
bnd = (($.context getService ($.context getServiceReference
org.apache.karaf.bundle.core.BundleService)) getBundle $1)
$bnd update ((new java.net.URL $2) openStream)
}
{code}
Then call the function:
{code}
do-update org.apache.sshd.core mvn:org.apache.sshd/sshd-core/1.2.0
{code}
That said, I agree we could provide an option to the {{bundle:update}} command.
> Add Option to bundle:update which doesn't rewrite MANIFEST file
> ---
>
> Key: KARAF-4824
> URL: https://issues.apache.org/jira/browse/KARAF-4824
> Project: Karaf
> Issue Type: New Feature
> Components: karaf-shell
>Affects Versions: 4.0.7
>Reporter: Markus Eckert
> Labels: bundle, shell, update
> Fix For: 4.1.0
>
>
> Using the Karaf shell, if someone updates a bundle using the *bundle:update*
> command, the command unzips the .jar file and manipulates the MANIFEST
> without questioning it.
> *BundleUtils.fixBundleWithUpdateLocation* is responsible for this.
> This is a severe issue when using JAR files with signature (JRE jarsigner)
> and signature checking. If a bundle is only allowed to start with a valid
> signature this will break it and the bundle won't activate again.
> Update of the bundles was done using:
> *update file:/*
> The only workaround is to uninstall the bundle and install it again.
> An option to tell update if it should update the MANIFEST or not would be a
> nice feature to have.
> Maybe there is another CLI command to achieve this? Updating the bundle using
> the Karaf Webconsole doesn't have this issue at all.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (KARAF-4824) Add Option to bundle:update which doesn't rewrite MANIFEST file
[ https://issues.apache.org/jira/browse/KARAF-4824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated KARAF-4824: --- Fix Version/s: 4.1.0 > Add Option to bundle:update which doesn't rewrite MANIFEST file > --- > > Key: KARAF-4824 > URL: https://issues.apache.org/jira/browse/KARAF-4824 > Project: Karaf > Issue Type: New Feature > Components: karaf-shell >Affects Versions: 4.0.7 >Reporter: Markus Eckert > Labels: bundle, shell, update > Fix For: 4.1.0 > > > Using the Karaf shell, if someone updates a bundle using the *bundle:update* > command, the command unzips the .jar file and manipulates the MANIFEST > without questioning it. > *BundleUtils.fixBundleWithUpdateLocation* is responsible for this. > This is a severe issue when using JAR files with signature (JRE jarsigner) > and signature checking. If a bundle is only allowed to start with a valid > signature this will break it and the bundle won't activate again. > Update of the bundles was done using: > *update file:/* > The only workaround is to uninstall the bundle and install it again. > An option to tell update if it should update the MANIFEST or not would be a > nice feature to have. > Maybe there is another CLI command to achieve this? Updating the bundle using > the Karaf Webconsole doesn't have this issue at all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (KARAF-4833) Incorrect behaviour of executing commands over multi lines via source
[
https://issues.apache.org/jira/browse/KARAF-4833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved KARAF-4833.
Resolution: Fixed
Assignee: Guillaume Nodet
Fixed by upgrading to jline 3.1.1.
https://github.com/apache/karaf/commit/0cf806b53565f3c2fa9812e46475adfe6430cefa
> Incorrect behaviour of executing commands over multi lines via source
> -
>
> Key: KARAF-4833
> URL: https://issues.apache.org/jira/browse/KARAF-4833
> Project: Karaf
> Issue Type: Bug
> Components: karaf-shell
>Affects Versions: 4.1.0
>Reporter: Lijun Liao
>Assignee: Guillaume Nodet
> Fix For: 4.1.0
>
>
> Steps to reproduce the error:
> 1. Create a file demo.script with following text
> {code}
> feature:install \
> "invalid-feature-name"
> {code}
> 2. In karaf shell, enter source demo.script
> You will get the following message:
> {code}
> karaf@root()> source tmp/demo.script
>xx:xx:xx
> gogo: IllegalArgumentException: No matching features for
> invalid-feature-name/0.0.0
> gogo: IllegalArgumentException: No matching features for
> invalid-feature-name/0.0.0
> Error executing command: No matching features for invalid-feature-name/0.0.0
> {code}
> Since the given feature does not exist, an IllegalArgumentException will be
> thrown. The expected behavour is that the throw exception will be outputted
> once.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (KARAF-4879) The log:get command should display all loggers by default
[
https://issues.apache.org/jira/browse/KARAF-4879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved KARAF-4879.
Resolution: Fixed
Fix Version/s: 4.1.0
> The log:get command should display all loggers by default
> -
>
> Key: KARAF-4879
> URL: https://issues.apache.org/jira/browse/KARAF-4879
> Project: Karaf
> Issue Type: Improvement
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: 4.1.0
>
>
> A more intuitive way would be the following:
> {code}
> karaf@root()> log:get
> Logger │ Level
> ┼──
> ROOT│ TRACE
> org.apache.aries.spifly │ WARN
> org.apache.karaf.jaas.modules.audit │ INFO
> org.apache.karaf.shell │ OFF
> karaf@root()> log:get org.apache.karaf.shell
> OFF
> karaf@root()>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (KARAF-4828) Support OFF log level in log:set console command
[ https://issues.apache.org/jira/browse/KARAF-4828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15724759#comment-15724759 ] ASF subversion and git services commented on KARAF-4828: Commit 1ff5aa1aa008538e0de18328c7e032a2683833ec in karaf's branch refs/heads/master from [~gnt] [ https://git-wip-us.apache.org/repos/asf?p=karaf.git;h=1ff5aa1 ] [KARAF-4879] The log:get command should display all loggers by default [KARAF-4828] Support OFF log level in log:set console command > Support OFF log level in log:set console command > > > Key: KARAF-4828 > URL: https://issues.apache.org/jira/browse/KARAF-4828 > Project: Karaf > Issue Type: Improvement > Components: karaf-core >Affects Versions: 3.0.8, 4.0.7 >Reporter: Dmitry Konstantinov >Assignee: Guillaume Nodet > Fix For: 4.1.0 > > > It is not possible to switch off logging for a logger using Karaf console > command. > The following levels are supported at this moment: "TRACE", "DEBUG", "INFO", > "WARN", "ERROR", "DEFAULT" > (https://github.com/apache/karaf/blob/master/log/src/main/java/org/apache/karaf/log/command/SetLogLevel.java) > It would be nice to add OFF level (it exits in log4j and logj4 2 levels) to > the supported list. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (KARAF-4828) Support OFF log level in log:set console command
[ https://issues.apache.org/jira/browse/KARAF-4828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved KARAF-4828. Resolution: Fixed Fix Version/s: 4.1.0 > Support OFF log level in log:set console command > > > Key: KARAF-4828 > URL: https://issues.apache.org/jira/browse/KARAF-4828 > Project: Karaf > Issue Type: Improvement > Components: karaf-core >Affects Versions: 3.0.8, 4.0.7 >Reporter: Dmitry Konstantinov >Assignee: Guillaume Nodet > Fix For: 4.1.0 > > > It is not possible to switch off logging for a logger using Karaf console > command. > The following levels are supported at this moment: "TRACE", "DEBUG", "INFO", > "WARN", "ERROR", "DEFAULT" > (https://github.com/apache/karaf/blob/master/log/src/main/java/org/apache/karaf/log/command/SetLogLevel.java) > It would be nice to add OFF level (it exits in log4j and logj4 2 levels) to > the supported list. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KARAF-4879) The log:get command should display all loggers by default
[
https://issues.apache.org/jira/browse/KARAF-4879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15724758#comment-15724758
]
ASF subversion and git services commented on KARAF-4879:
Commit 1ff5aa1aa008538e0de18328c7e032a2683833ec in karaf's branch
refs/heads/master from [~gnt]
[ https://git-wip-us.apache.org/repos/asf?p=karaf.git;h=1ff5aa1 ]
[KARAF-4879] The log:get command should display all loggers by default
[KARAF-4828] Support OFF log level in log:set console command
> The log:get command should display all loggers by default
> -
>
> Key: KARAF-4879
> URL: https://issues.apache.org/jira/browse/KARAF-4879
> Project: Karaf
> Issue Type: Improvement
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: 4.1.0
>
>
> A more intuitive way would be the following:
> {code}
> karaf@root()> log:get
> Logger │ Level
> ┼──
> ROOT│ TRACE
> org.apache.aries.spifly │ WARN
> org.apache.karaf.jaas.modules.audit │ INFO
> org.apache.karaf.shell │ OFF
> karaf@root()> log:get org.apache.karaf.shell
> OFF
> karaf@root()>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (KARAF-4879) The log:get command should display all loggers by default
Guillaume Nodet created KARAF-4879:
--
Summary: The log:get command should display all loggers by default
Key: KARAF-4879
URL: https://issues.apache.org/jira/browse/KARAF-4879
Project: Karaf
Issue Type: Improvement
Reporter: Guillaume Nodet
Assignee: Guillaume Nodet
A more intuitive way would be the following:
{code}
karaf@root()> log:get
Logger │ Level
┼──
ROOT│ TRACE
org.apache.aries.spifly │ WARN
org.apache.karaf.jaas.modules.audit │ INFO
org.apache.karaf.shell │ OFF
karaf@root()> log:get org.apache.karaf.shell
OFF
karaf@root()>
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
