[jira] [Commented] (KARAF-2060) Variables cannot be used in org.apache.karaf.features.cfg

2016-06-09 Thread Phillip Rhodes (JIRA) 

[ 
https://issues.apache.org/jira/browse/KARAF-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15323595#comment-15323595
 ] 

Phillip Rhodes commented on KARAF-2060:
---

Any chance of getting any movement on this?  Using ServiceMix, it would be nice 
to be able to specify the path to a feature repository using a variable like 
karaf.base or whatever, instead of having to plugin in the absolute path every 
time.   Also, FWIW, putting a variable in the file for something like a 
repository location not only doesn't work, it breaks something in how the file 
is processed, as even the other (correctly specified) repositories don't load 
(well, at least in ServiceMix 6.1.0. Not sure which version of Karaf that's 
based on).



> Variables cannot be used in org.apache.karaf.features.cfg
> -
>
> Key: KARAF-2060
> URL: https://issues.apache.org/jira/browse/KARAF-2060
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-config
>Affects Versions: 2.3.0
> Environment: Windows 7
> Java 6
>Reporter: Bengt Rodehav
>Priority: Minor
>
> Normally, variables defined in custom.properties can be used in configuration 
> files handled by FileInstall. For some reason this does not seem to work in 
> org.apache.karaf.features.cfg.
> E g, this works:
> {quote}
> - Put the following line in custom.properties:
> logdir=data/log
> - Put the following line in org.ops4j.pax.logging.cfg:
> log4j.appender.info.file=$\{logdir\}/info.log
> {quote}
> But this does NOT work:
> {quote}
> - Put the following line in custom.properties:
> var = 
> mvn:org.apache.karaf.features/standard/3.0.0-SNAPSHOT/xml/features,mvn:org.apache.karaf.features/enterprise/3.0.0-SNAPSHOT/xml/features,mvn:org.apache.karaf.features/spring/3.0.0-SNAPSHOT/xml/features
> - Put the following line in org.apache.karaf.features.cfg:
> featuresRepositories = $\{var\}
> {quote}
> This has been discussed on the Karaf user list:
> http://karaf.922171.n3.nabble.com/Using-variables-in-org-apache-karaf-features-cfg-td4027053.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KARAF-4502) REGRESSION: using OpenJDK on CentOS 7 causes bin/client to fail with "Unable to negotiate key exchange for kex algorithms"

2016-06-09 Thread JIRA 

 [ 
https://issues.apache.org/jira/browse/KARAF-4502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Baptiste Onofré updated KARAF-4502:

Fix Version/s: 4.0.6
   3.0.7
   4.1.0

> REGRESSION: using OpenJDK on CentOS 7 causes bin/client to fail with "Unable 
> to negotiate key exchange for kex algorithms"
> --
>
> Key: KARAF-4502
> URL: https://issues.apache.org/jira/browse/KARAF-4502
> Project: Karaf
>  Issue Type: Bug
>Affects Versions: 4.0.3, 3.0.6, 4.0.4
> Environment: CentOS Linux release 7.0.1406 (Core) 
> openjdk version "1.8.0_77"
>Reporter: Damjan Jovanovic
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.1.0, 3.0.7, 4.0.6
>
>
> On a fresh install of CentOS 7 with OpenJDK 1.8, running karaf container 
> versions > 4.0.2 either with "bin/karaf" or as a service (whether sysvinit or 
> systemd), trying to log in with "bin/client" always fails with an exception.
> Oracle JDK - by comparison - works.
> "git bisect" narrowed down the regression to the following commit:
> 539540cde099aee52fd523a09aca92e36522261c is the first bad commit
> commit 539540cde099aee52fd523a09aca92e36522261c
> Author: Freeman Fang 
> Date:   Wed Oct 14 12:09:09 2015 +0800
> [KARAF-4062]Karaf client does now work after installing BouncyCastle
> :04 04 926f15997510a671ff77db9623f8b65ce4186706 
> da83c22e043de3004a620f1cc88e25ee672bd09d Mclient
> The exception is:
> # bin/client
> Logging in as karaf
> 3771 [sshd-SshClient[593634ad]-nio2-thread-2] WARN 
> org.apache.sshd.client.session.ClientSessionImpl - Exception caught
> java.lang.IllegalStateException: Unable to negotiate key exchange for kex 
> algorithms (client: 
> ecdh-sha2-nistp256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp384,ecdh-sha2-nistp521,ecdh-sha2-nistp521
>  / server: 
> diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1)
>   at 
> org.apache.sshd.common.session.AbstractSession.negotiate(AbstractSession.java:1159)
>   at 
> org.apache.sshd.common.session.AbstractSession.doHandleMessage(AbstractSession.java:388)
>   at 
> org.apache.sshd.common.session.AbstractSession.handleMessage(AbstractSession.java:326)
>   at 
> org.apache.sshd.client.session.ClientSessionImpl.handleMessage(ClientSessionImpl.java:306)
>   at 
> org.apache.sshd.common.session.AbstractSession.decode(AbstractSession.java:780)
>   at 
> org.apache.sshd.common.session.AbstractSession.messageReceived(AbstractSession.java:308)
>   at 
> org.apache.sshd.common.AbstractSessionIoHandler.messageReceived(AbstractSessionIoHandler.java:54)
>   at 
> org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:184)
>   at 
> org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:170)
>   at 
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler$1.run(Nio2CompletionHandler.java:32)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:30)
>   at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126)
>   at sun.nio.ch.Invoker$2.run(Invoker.java:218)
>   at 
> sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> Authentication failed



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (KARAF-4502) REGRESSION: using OpenJDK on CentOS 7 causes bin/client to fail with "Unable to negotiate key exchange for kex algorithms"

2016-06-09 Thread JIRA 

 [ 
https://issues.apache.org/jira/browse/KARAF-4502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Baptiste Onofré reassigned KARAF-4502:
---

Assignee: Jean-Baptiste Onofré

> REGRESSION: using OpenJDK on CentOS 7 causes bin/client to fail with "Unable 
> to negotiate key exchange for kex algorithms"
> --
>
> Key: KARAF-4502
> URL: https://issues.apache.org/jira/browse/KARAF-4502
> Project: Karaf
>  Issue Type: Bug
>Affects Versions: 4.0.3, 3.0.6, 4.0.4
> Environment: CentOS Linux release 7.0.1406 (Core) 
> openjdk version "1.8.0_77"
>Reporter: Damjan Jovanovic
>Assignee: Jean-Baptiste Onofré
>
> On a fresh install of CentOS 7 with OpenJDK 1.8, running karaf container 
> versions > 4.0.2 either with "bin/karaf" or as a service (whether sysvinit or 
> systemd), trying to log in with "bin/client" always fails with an exception.
> Oracle JDK - by comparison - works.
> "git bisect" narrowed down the regression to the following commit:
> 539540cde099aee52fd523a09aca92e36522261c is the first bad commit
> commit 539540cde099aee52fd523a09aca92e36522261c
> Author: Freeman Fang 
> Date:   Wed Oct 14 12:09:09 2015 +0800
> [KARAF-4062]Karaf client does now work after installing BouncyCastle
> :04 04 926f15997510a671ff77db9623f8b65ce4186706 
> da83c22e043de3004a620f1cc88e25ee672bd09d Mclient
> The exception is:
> # bin/client
> Logging in as karaf
> 3771 [sshd-SshClient[593634ad]-nio2-thread-2] WARN 
> org.apache.sshd.client.session.ClientSessionImpl - Exception caught
> java.lang.IllegalStateException: Unable to negotiate key exchange for kex 
> algorithms (client: 
> ecdh-sha2-nistp256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp384,ecdh-sha2-nistp521,ecdh-sha2-nistp521
>  / server: 
> diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1)
>   at 
> org.apache.sshd.common.session.AbstractSession.negotiate(AbstractSession.java:1159)
>   at 
> org.apache.sshd.common.session.AbstractSession.doHandleMessage(AbstractSession.java:388)
>   at 
> org.apache.sshd.common.session.AbstractSession.handleMessage(AbstractSession.java:326)
>   at 
> org.apache.sshd.client.session.ClientSessionImpl.handleMessage(ClientSessionImpl.java:306)
>   at 
> org.apache.sshd.common.session.AbstractSession.decode(AbstractSession.java:780)
>   at 
> org.apache.sshd.common.session.AbstractSession.messageReceived(AbstractSession.java:308)
>   at 
> org.apache.sshd.common.AbstractSessionIoHandler.messageReceived(AbstractSessionIoHandler.java:54)
>   at 
> org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:184)
>   at 
> org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:170)
>   at 
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler$1.run(Nio2CompletionHandler.java:32)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:30)
>   at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126)
>   at sun.nio.ch.Invoker$2.run(Invoker.java:218)
>   at 
> sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> Authentication failed



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KARAF-4564) Can't start karaf using symbolic link

2016-06-09 Thread JIRA 

[ 
https://issues.apache.org/jira/browse/KARAF-4564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15322493#comment-15322493
 ] 

Jean-Baptiste Onofré commented on KARAF-4564:
-

I added a comment in the PR.

>  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.6
>
>
> 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] [Closed] (KARAF-4568) [equinox] Unable to install feature with fragment

2016-06-09 Thread Alexey Markevich (JIRA) 

 [ 
https://issues.apache.org/jira/browse/KARAF-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Markevich closed KARAF-4568.
---
Resolution: Duplicate

> [equinox] Unable to install feature with fragment 
> --
>
> Key: KARAF-4568
> URL: https://issues.apache.org/jira/browse/KARAF-4568
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-feature
>Affects Versions: 4.0.4, 4.0.5
>Reporter: Alexey Markevich
> Attachments: quartz-fragment.kar
>
>
> - update custom.properties
> karaf.framework=equinox
> - copy attached kar to deploy folder: [1]
> Same time each bundle deployed separately via deploy folder works fine
> 1.Unable to install Kar feature quartz-fragment/1.0.0
> org.osgi.service.resolver.ResolutionException: Uses constraint violation. 
> Unable to resolve resource org.quartz-scheduler.quartz 
> [org.quartz-scheduler.quartz/2.2.3] because it exports package 
> 'org.quartz.ee.jta' and is also exposed to it from resource 
> org.quartz-scheduler.quartz [org.quartz-scheduler.quartz/2.2.3] via the 
> following dependency chain:
>   org.quartz-scheduler.quartz [org.quartz-scheduler.quartz/2.2.3]
> import: (osgi.wiring.package=org.quartz.core)
>  |
> export: osgi.wiring.package=org.quartz.core; uses:=org.quartz
>   org.quartz-scheduler.quartz [org.quartz-scheduler.quartz/2.2.3]
> import: (osgi.wiring.package=org.quartz)
>  |
> export: osgi.wiring.package: org.quartz; uses:=org.quartz.ee.jta
> export: osgi.wiring.package=org.quartz.ee.jta
>   org.quartz-scheduler.quartz [org.quartz-scheduler.quartz/2.2.3]
>   at 
> org.apache.felix.resolver.ResolverImpl.checkDynamicPackageSpaceConsistency(ResolverImpl.java:1225)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
>   at 
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1121)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
>   at 
> org.apache.felix.resolver.ResolverImpl.checkDynamicPackageSpaceConsistency(ResolverImpl.java:1449)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
>   at 
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1121)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
>   at 
> org.apache.felix.resolver.ResolverImpl.checkDynamicPackageSpaceConsistency(ResolverImpl.java:1449)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
>   at 
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1121)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
>   at 
> org.apache.felix.resolver.ResolverImpl.checkDynamicPackageSpaceConsistency(ResolverImpl.java:1449)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
>   at 
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1121)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
>   at 
> org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:260)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
>   at 
> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:216)[9:org.apache.karaf.features.core:4.0.4]
>   at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:263)[9:org.apache.karaf.features.core:4.0.4]
>   at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1089)[9:org.apache.karaf.features.core:4.0.4]
>   at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:985)[9:org.apache.karaf.features.core:4.0.4]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_92]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_92]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_92]
>   at java.lang.Thread.run(Thread.java:745)[:1.8.0_92]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KARAF-4566) "karaf" script invokes /bin/sh but requires /bin/bash functions

2016-06-09 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/KARAF-4566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15322476#comment-15322476
 ] 

ASF subversion and git services commented on KARAF-4566:


Commit bad4ba4732bd8991342e38a94ead689d83fa1412 in karaf's branch 
refs/heads/karaf-4.0.x from [~jbonofre]
[ https://git-wip-us.apache.org/repos/asf?p=karaf.git;h=bad4ba4 ]

[KARAF-4566] Cleanup in script. This closes #197


>  "karaf" script invokes /bin/sh but requires /bin/bash functions
> 
>
> Key: KARAF-4566
> URL: https://issues.apache.org/jira/browse/KARAF-4566
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-core
>Affects Versions: 3.0.6
> Environment: 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.6
>
>
> The bin/karaf script uses the "local" command which is a shell builtin of 
> bash and similar shells, but is not required for POSIX-compliance in sh. When 
> I attempt to run karaf on a Solaris system, I see the following output:
> root@solaris:/opendaylight/bin# ./karaf
> ./karaf[172]: local: not found [No such file or directory]
> ./karaf[182]: local: not found [No such file or directory]
> ./karaf[183]: local: not found [No such file or directory]
> Lines 172, 182 and 183 invoke "local" to make local variables to the 
> function. According to "man bash", this is a shell builtin. However, 
> bin/karaf is invoked as:
> #!/bin/sh
> On most flavors of linux, this resolves to bash or dash which probably runs 
> in a restricted environment after checking to see that its $0 is sh. But on 
> Solaris's /bin/sh is actually ksh93 for backwards compatibility.
> Since "local" is not part of a POSIX-compliant /bin/sh, depending on it in a 
> script that is invoked with /bin/sh is a bug.
> (this explaination is borrowed from 
> https://issues.apache.org/jira/browse/MNG-5852)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work started] (KARAF-4564) Can't start karaf using symbolic link

2016-06-09 Thread JIRA 

 [ 
https://issues.apache.org/jira/browse/KARAF-4564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on KARAF-4564 started by 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.6
>
>
> 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] [Resolved] (KARAF-4566) "karaf" script invokes /bin/sh but requires /bin/bash functions

2016-06-09 Thread JIRA 

 [ 
https://issues.apache.org/jira/browse/KARAF-4566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Baptiste Onofré resolved KARAF-4566.
-
Resolution: Fixed

>  "karaf" script invokes /bin/sh but requires /bin/bash functions
> 
>
> Key: KARAF-4566
> URL: https://issues.apache.org/jira/browse/KARAF-4566
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-core
>Affects Versions: 3.0.6
> Environment: 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.6
>
>
> The bin/karaf script uses the "local" command which is a shell builtin of 
> bash and similar shells, but is not required for POSIX-compliance in sh. When 
> I attempt to run karaf on a Solaris system, I see the following output:
> root@solaris:/opendaylight/bin# ./karaf
> ./karaf[172]: local: not found [No such file or directory]
> ./karaf[182]: local: not found [No such file or directory]
> ./karaf[183]: local: not found [No such file or directory]
> Lines 172, 182 and 183 invoke "local" to make local variables to the 
> function. According to "man bash", this is a shell builtin. However, 
> bin/karaf is invoked as:
> #!/bin/sh
> On most flavors of linux, this resolves to bash or dash which probably runs 
> in a restricted environment after checking to see that its $0 is sh. But on 
> Solaris's /bin/sh is actually ksh93 for backwards compatibility.
> Since "local" is not part of a POSIX-compliant /bin/sh, depending on it in a 
> script that is invoked with /bin/sh is a bug.
> (this explaination is borrowed from 
> https://issues.apache.org/jira/browse/MNG-5852)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KARAF-4566) "karaf" script invokes /bin/sh but requires /bin/bash functions

2016-06-09 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/KARAF-4566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15322448#comment-15322448
 ] 

ASF GitHub Bot commented on KARAF-4566:
---

Github user asfgit closed the pull request at:

https://github.com/apache/karaf/pull/197


>  "karaf" script invokes /bin/sh but requires /bin/bash functions
> 
>
> Key: KARAF-4566
> URL: https://issues.apache.org/jira/browse/KARAF-4566
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-core
>Affects Versions: 3.0.6
> Environment: 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.6
>
>
> The bin/karaf script uses the "local" command which is a shell builtin of 
> bash and similar shells, but is not required for POSIX-compliance in sh. When 
> I attempt to run karaf on a Solaris system, I see the following output:
> root@solaris:/opendaylight/bin# ./karaf
> ./karaf[172]: local: not found [No such file or directory]
> ./karaf[182]: local: not found [No such file or directory]
> ./karaf[183]: local: not found [No such file or directory]
> Lines 172, 182 and 183 invoke "local" to make local variables to the 
> function. According to "man bash", this is a shell builtin. However, 
> bin/karaf is invoked as:
> #!/bin/sh
> On most flavors of linux, this resolves to bash or dash which probably runs 
> in a restricted environment after checking to see that its $0 is sh. But on 
> Solaris's /bin/sh is actually ksh93 for backwards compatibility.
> Since "local" is not part of a POSIX-compliant /bin/sh, depending on it in a 
> script that is invoked with /bin/sh is a bug.
> (this explaination is borrowed from 
> https://issues.apache.org/jira/browse/MNG-5852)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KARAF-4566) "karaf" script invokes /bin/sh but requires /bin/bash functions

2016-06-09 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/KARAF-4566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15322447#comment-15322447
 ] 

ASF subversion and git services commented on KARAF-4566:


Commit 948890980848f3b101dda8dcb6d877d7d9ed4f32 in karaf's branch 
refs/heads/master from [~jbonofre]
[ https://git-wip-us.apache.org/repos/asf?p=karaf.git;h=9488909 ]

[KARAF-4566] Cleanup in script. This closes #197


>  "karaf" script invokes /bin/sh but requires /bin/bash functions
> 
>
> Key: KARAF-4566
> URL: https://issues.apache.org/jira/browse/KARAF-4566
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-core
>Affects Versions: 3.0.6
> Environment: 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.6
>
>
> The bin/karaf script uses the "local" command which is a shell builtin of 
> bash and similar shells, but is not required for POSIX-compliance in sh. When 
> I attempt to run karaf on a Solaris system, I see the following output:
> root@solaris:/opendaylight/bin# ./karaf
> ./karaf[172]: local: not found [No such file or directory]
> ./karaf[182]: local: not found [No such file or directory]
> ./karaf[183]: local: not found [No such file or directory]
> Lines 172, 182 and 183 invoke "local" to make local variables to the 
> function. According to "man bash", this is a shell builtin. However, 
> bin/karaf is invoked as:
> #!/bin/sh
> On most flavors of linux, this resolves to bash or dash which probably runs 
> in a restricted environment after checking to see that its $0 is sh. But on 
> Solaris's /bin/sh is actually ksh93 for backwards compatibility.
> Since "local" is not part of a POSIX-compliant /bin/sh, depending on it in a 
> script that is invoked with /bin/sh is a bug.
> (this explaination is borrowed from 
> https://issues.apache.org/jira/browse/MNG-5852)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KARAF-4568) [equinox] Unable to install feature with fragment

2016-06-09 Thread Alexey Markevich (JIRA) 

 [ 
https://issues.apache.org/jira/browse/KARAF-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Markevich updated KARAF-4568:

Affects Version/s: 4.0.5

> [equinox] Unable to install feature with fragment 
> --
>
> Key: KARAF-4568
> URL: https://issues.apache.org/jira/browse/KARAF-4568
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-feature
>Affects Versions: 4.0.4, 4.0.5
>Reporter: Alexey Markevich
> Attachments: quartz-fragment.kar
>
>
> - update custom.properties
> karaf.framework=equinox
> - copy attached kar to deploy folder: [1]
> Same time each bundle deployed separately via deploy folder works fine
> 1.Unable to install Kar feature quartz-fragment/1.0.0
> org.osgi.service.resolver.ResolutionException: Uses constraint violation. 
> Unable to resolve resource org.quartz-scheduler.quartz 
> [org.quartz-scheduler.quartz/2.2.3] because it exports package 
> 'org.quartz.ee.jta' and is also exposed to it from resource 
> org.quartz-scheduler.quartz [org.quartz-scheduler.quartz/2.2.3] via the 
> following dependency chain:
>   org.quartz-scheduler.quartz [org.quartz-scheduler.quartz/2.2.3]
> import: (osgi.wiring.package=org.quartz.core)
>  |
> export: osgi.wiring.package=org.quartz.core; uses:=org.quartz
>   org.quartz-scheduler.quartz [org.quartz-scheduler.quartz/2.2.3]
> import: (osgi.wiring.package=org.quartz)
>  |
> export: osgi.wiring.package: org.quartz; uses:=org.quartz.ee.jta
> export: osgi.wiring.package=org.quartz.ee.jta
>   org.quartz-scheduler.quartz [org.quartz-scheduler.quartz/2.2.3]
>   at 
> org.apache.felix.resolver.ResolverImpl.checkDynamicPackageSpaceConsistency(ResolverImpl.java:1225)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
>   at 
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1121)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
>   at 
> org.apache.felix.resolver.ResolverImpl.checkDynamicPackageSpaceConsistency(ResolverImpl.java:1449)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
>   at 
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1121)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
>   at 
> org.apache.felix.resolver.ResolverImpl.checkDynamicPackageSpaceConsistency(ResolverImpl.java:1449)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
>   at 
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1121)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
>   at 
> org.apache.felix.resolver.ResolverImpl.checkDynamicPackageSpaceConsistency(ResolverImpl.java:1449)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
>   at 
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1121)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
>   at 
> org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:260)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
>   at 
> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:216)[9:org.apache.karaf.features.core:4.0.4]
>   at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:263)[9:org.apache.karaf.features.core:4.0.4]
>   at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1089)[9:org.apache.karaf.features.core:4.0.4]
>   at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:985)[9:org.apache.karaf.features.core:4.0.4]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_92]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_92]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_92]
>   at java.lang.Thread.run(Thread.java:745)[:1.8.0_92]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KARAF-4568) [equinox] Unable to install feature with fragment

2016-06-09 Thread Alexey Markevich (JIRA) 

 [ 
https://issues.apache.org/jira/browse/KARAF-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Markevich updated KARAF-4568:

Attachment: quartz-fragment.kar

> [equinox] Unable to install feature with fragment 
> --
>
> Key: KARAF-4568
> URL: https://issues.apache.org/jira/browse/KARAF-4568
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-feature
>Affects Versions: 4.0.4
>Reporter: Alexey Markevich
> Attachments: quartz-fragment.kar
>
>
> - update custom.properties
> karaf.framework=equinox
> - copy attached kar to deploy folder: [1]
> Same time each bundle deployed separately via deploy folder works fine
> 1.Unable to install Kar feature quartz-fragment/1.0.0
> org.osgi.service.resolver.ResolutionException: Uses constraint violation. 
> Unable to resolve resource org.quartz-scheduler.quartz 
> [org.quartz-scheduler.quartz/2.2.3] because it exports package 
> 'org.quartz.ee.jta' and is also exposed to it from resource 
> org.quartz-scheduler.quartz [org.quartz-scheduler.quartz/2.2.3] via the 
> following dependency chain:
>   org.quartz-scheduler.quartz [org.quartz-scheduler.quartz/2.2.3]
> import: (osgi.wiring.package=org.quartz.core)
>  |
> export: osgi.wiring.package=org.quartz.core; uses:=org.quartz
>   org.quartz-scheduler.quartz [org.quartz-scheduler.quartz/2.2.3]
> import: (osgi.wiring.package=org.quartz)
>  |
> export: osgi.wiring.package: org.quartz; uses:=org.quartz.ee.jta
> export: osgi.wiring.package=org.quartz.ee.jta
>   org.quartz-scheduler.quartz [org.quartz-scheduler.quartz/2.2.3]
>   at 
> org.apache.felix.resolver.ResolverImpl.checkDynamicPackageSpaceConsistency(ResolverImpl.java:1225)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
>   at 
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1121)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
>   at 
> org.apache.felix.resolver.ResolverImpl.checkDynamicPackageSpaceConsistency(ResolverImpl.java:1449)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
>   at 
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1121)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
>   at 
> org.apache.felix.resolver.ResolverImpl.checkDynamicPackageSpaceConsistency(ResolverImpl.java:1449)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
>   at 
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1121)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
>   at 
> org.apache.felix.resolver.ResolverImpl.checkDynamicPackageSpaceConsistency(ResolverImpl.java:1449)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
>   at 
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1121)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
>   at 
> org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:260)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
>   at 
> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:216)[9:org.apache.karaf.features.core:4.0.4]
>   at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:263)[9:org.apache.karaf.features.core:4.0.4]
>   at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1089)[9:org.apache.karaf.features.core:4.0.4]
>   at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:985)[9:org.apache.karaf.features.core:4.0.4]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_92]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_92]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_92]
>   at java.lang.Thread.run(Thread.java:745)[:1.8.0_92]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (KARAF-4568) [equinox] Unable to install feature with fragment

2016-06-09 Thread Alexey Markevich (JIRA) 
Alexey Markevich created KARAF-4568:
---

 Summary: [equinox] Unable to install feature with fragment 
 Key: KARAF-4568
 URL: https://issues.apache.org/jira/browse/KARAF-4568
 Project: Karaf
  Issue Type: Bug
  Components: karaf-feature
Affects Versions: 4.0.4
Reporter: Alexey Markevich


- update custom.properties
karaf.framework=equinox
- copy attached kar to deploy folder: [1]

Same time each bundle deployed separately via deploy folder works fine

1.Unable to install Kar feature quartz-fragment/1.0.0
org.osgi.service.resolver.ResolutionException: Uses constraint violation. 
Unable to resolve resource org.quartz-scheduler.quartz 
[org.quartz-scheduler.quartz/2.2.3] because it exports package 
'org.quartz.ee.jta' and is also exposed to it from resource 
org.quartz-scheduler.quartz [org.quartz-scheduler.quartz/2.2.3] via the 
following dependency chain:

  org.quartz-scheduler.quartz [org.quartz-scheduler.quartz/2.2.3]
import: (osgi.wiring.package=org.quartz.core)
 |
export: osgi.wiring.package=org.quartz.core; uses:=org.quartz
  org.quartz-scheduler.quartz [org.quartz-scheduler.quartz/2.2.3]
import: (osgi.wiring.package=org.quartz)
 |
export: osgi.wiring.package: org.quartz; uses:=org.quartz.ee.jta
export: osgi.wiring.package=org.quartz.ee.jta
  org.quartz-scheduler.quartz [org.quartz-scheduler.quartz/2.2.3]
at 
org.apache.felix.resolver.ResolverImpl.checkDynamicPackageSpaceConsistency(ResolverImpl.java:1225)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
at 
org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1121)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
at 
org.apache.felix.resolver.ResolverImpl.checkDynamicPackageSpaceConsistency(ResolverImpl.java:1449)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
at 
org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1121)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
at 
org.apache.felix.resolver.ResolverImpl.checkDynamicPackageSpaceConsistency(ResolverImpl.java:1449)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
at 
org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1121)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
at 
org.apache.felix.resolver.ResolverImpl.checkDynamicPackageSpaceConsistency(ResolverImpl.java:1449)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
at 
org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1121)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
at 
org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:260)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
at 
org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:216)[9:org.apache.karaf.features.core:4.0.4]
at 
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:263)[9:org.apache.karaf.features.core:4.0.4]
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1089)[9:org.apache.karaf.features.core:4.0.4]
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:985)[9:org.apache.karaf.features.core:4.0.4]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_92]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_92]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_92]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_92]




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KARAF-4566) "karaf" script invokes /bin/sh but requires /bin/bash functions

2016-06-09 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/KARAF-4566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15322398#comment-15322398
 ] 

ASF subversion and git services commented on KARAF-4566:


Commit 8b087d159476f0f5f04dbb5f09f2792da2b56bf5 in karaf's branch 
refs/heads/karaf-3.0.x from [~adetalhouet]
[ https://git-wip-us.apache.org/repos/asf?p=karaf.git;h=8b087d1 ]

KARAF-4566 "karaf" script invokes /bin/sh but requires /bin/bash functions

Signed-off-by: Alexis de Talhouët 


>  "karaf" script invokes /bin/sh but requires /bin/bash functions
> 
>
> Key: KARAF-4566
> URL: https://issues.apache.org/jira/browse/KARAF-4566
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-core
>Affects Versions: 3.0.6
> Environment: 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.6
>
>
> The bin/karaf script uses the "local" command which is a shell builtin of 
> bash and similar shells, but is not required for POSIX-compliance in sh. When 
> I attempt to run karaf on a Solaris system, I see the following output:
> root@solaris:/opendaylight/bin# ./karaf
> ./karaf[172]: local: not found [No such file or directory]
> ./karaf[182]: local: not found [No such file or directory]
> ./karaf[183]: local: not found [No such file or directory]
> Lines 172, 182 and 183 invoke "local" to make local variables to the 
> function. According to "man bash", this is a shell builtin. However, 
> bin/karaf is invoked as:
> #!/bin/sh
> On most flavors of linux, this resolves to bash or dash which probably runs 
> in a restricted environment after checking to see that its $0 is sh. But on 
> Solaris's /bin/sh is actually ksh93 for backwards compatibility.
> Since "local" is not part of a POSIX-compliant /bin/sh, depending on it in a 
> script that is invoked with /bin/sh is a bug.
> (this explaination is borrowed from 
> https://issues.apache.org/jira/browse/MNG-5852)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KARAF-4566) "karaf" script invokes /bin/sh but requires /bin/bash functions

2016-06-09 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/KARAF-4566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15322399#comment-15322399
 ] 

ASF subversion and git services commented on KARAF-4566:


Commit de2fd816c631d84921b6cf3d659c6371a64303db in karaf's branch 
refs/heads/karaf-3.0.x from [~jbonofre]
[ https://git-wip-us.apache.org/repos/asf?p=karaf.git;h=de2fd81 ]

[KARAF-4566] bin/karaf script invokes /bin/sh but requires /bin/bash 
functions\n\nThis close #197


>  "karaf" script invokes /bin/sh but requires /bin/bash functions
> 
>
> Key: KARAF-4566
> URL: https://issues.apache.org/jira/browse/KARAF-4566
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-core
>Affects Versions: 3.0.6
> Environment: 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.6
>
>
> The bin/karaf script uses the "local" command which is a shell builtin of 
> bash and similar shells, but is not required for POSIX-compliance in sh. When 
> I attempt to run karaf on a Solaris system, I see the following output:
> root@solaris:/opendaylight/bin# ./karaf
> ./karaf[172]: local: not found [No such file or directory]
> ./karaf[182]: local: not found [No such file or directory]
> ./karaf[183]: local: not found [No such file or directory]
> Lines 172, 182 and 183 invoke "local" to make local variables to the 
> function. According to "man bash", this is a shell builtin. However, 
> bin/karaf is invoked as:
> #!/bin/sh
> On most flavors of linux, this resolves to bash or dash which probably runs 
> in a restricted environment after checking to see that its $0 is sh. But on 
> Solaris's /bin/sh is actually ksh93 for backwards compatibility.
> Since "local" is not part of a POSIX-compliant /bin/sh, depending on it in a 
> script that is invoked with /bin/sh is a bug.
> (this explaination is borrowed from 
> https://issues.apache.org/jira/browse/MNG-5852)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KARAF-4567) ENC( not working in ConfigAdmin

2016-06-09 Thread Paolo Antinori (JIRA) 

 [ 
https://issues.apache.org/jira/browse/KARAF-4567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paolo Antinori updated KARAF-4567:
--
Description: 
I'm trying to make support for encrypted properties in in ConfigAdmin and I 
cannot make it.

My suspect is that the functionality is not really working and that the unit 
test is indeed not testing the functionality.

The test is 
https://github.com/apache/karaf/blob/master/jaas/blueprint/jasypt/src/test/java/org/apache/karaf/jaas/blueprint/jasypt/handler/EncryptableConfigAdminPropertyPlaceholderTest.java
 and I think it should not assert for the correct value of {{foo}} but it 
should check the correct value of {{encoded}}, coming from 
https://github.com/apache/karaf/blob/master/jaas/blueprint/jasypt/src/test/resources/org/apache/karaf/jaas/blueprint/jasypt/handler/configadmin-test.xml

I'm still on this and I might be wrong, but for what I can see, tokens like 
{{ENC($\{prop})}} fail to be replaced because 
{{org.apache.karaf.jaas.jasypt.handler.EncryptablePropertyPlaceholder}} always 
try to encrypt strings like {{$\{prop\}}} that have not been correctly replaced.

  was:
I'm trying to make support for encrypted properties in in ConfigAdmin and I 
cannot make it.

My suspect is that the functionality is not really working and that the unit 
test is indeed not testing the functionality.

The test is 
https://github.com/apache/karaf/blob/master/jaas/blueprint/jasypt/src/test/java/org/apache/karaf/jaas/blueprint/jasypt/handler/EncryptableConfigAdminPropertyPlaceholderTest.java
 and I think it should not assert for the correct value of {{foo}} but it 
should check the correct value of {{encoded}}, coming from 
https://github.com/apache/karaf/blob/master/jaas/blueprint/jasypt/src/test/resources/org/apache/karaf/jaas/blueprint/jasypt/handler/configadmin-test.xml

I'm still on this and I might be wrong, but for what I can see, tokens like 
{{ENC(${prop})}} fail to be replaced because 
{{org.apache.karaf.jaas.jasypt.handler.EncryptablePropertyPlaceholder}} always 
try to encrypt strings like {{${prop}}} that have not been correctly replaced.


> ENC(  not working in ConfigAdmin
> 
>
> Key: KARAF-4567
> URL: https://issues.apache.org/jira/browse/KARAF-4567
> Project: Karaf
>  Issue Type: Bug
>Affects Versions: 2.4.4, 4.0.5
>Reporter: Paolo Antinori
>
> I'm trying to make support for encrypted properties in in ConfigAdmin and I 
> cannot make it.
> My suspect is that the functionality is not really working and that the unit 
> test is indeed not testing the functionality.
> The test is 
> https://github.com/apache/karaf/blob/master/jaas/blueprint/jasypt/src/test/java/org/apache/karaf/jaas/blueprint/jasypt/handler/EncryptableConfigAdminPropertyPlaceholderTest.java
>  and I think it should not assert for the correct value of {{foo}} but it 
> should check the correct value of {{encoded}}, coming from 
> https://github.com/apache/karaf/blob/master/jaas/blueprint/jasypt/src/test/resources/org/apache/karaf/jaas/blueprint/jasypt/handler/configadmin-test.xml
> I'm still on this and I might be wrong, but for what I can see, tokens like 
> {{ENC($\{prop})}} fail to be replaced because 
> {{org.apache.karaf.jaas.jasypt.handler.EncryptablePropertyPlaceholder}} 
> always try to encrypt strings like {{$\{prop\}}} that have not been correctly 
> replaced.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (KARAF-4567) ENC( not working in ConfigAdmin

2016-06-09 Thread Paolo Antinori (JIRA) 
Paolo Antinori created KARAF-4567:
-

 Summary: ENC(  not working in ConfigAdmin
 Key: KARAF-4567
 URL: https://issues.apache.org/jira/browse/KARAF-4567
 Project: Karaf
  Issue Type: Bug
Affects Versions: 4.0.5, 2.4.4
Reporter: Paolo Antinori


I'm trying to make support for encrypted properties in in ConfigAdmin and I 
cannot make it.

My suspect is that the functionality is not really working and that the unit 
test is indeed not testing the functionality.

The test is 
https://github.com/apache/karaf/blob/master/jaas/blueprint/jasypt/src/test/java/org/apache/karaf/jaas/blueprint/jasypt/handler/EncryptableConfigAdminPropertyPlaceholderTest.java
 and I think it should not assert for the correct value of {{foo}} but it 
should check the correct value of {{encoded}}, coming from 
https://github.com/apache/karaf/blob/master/jaas/blueprint/jasypt/src/test/resources/org/apache/karaf/jaas/blueprint/jasypt/handler/configadmin-test.xml

I'm still on this and I might be wrong, but for what I can see, tokens like 
{{ENC(${prop})}} fail to be replaced because 
{{org.apache.karaf.jaas.jasypt.handler.EncryptablePropertyPlaceholder}} always 
try to encrypt strings like {{${prop}}} that have not been correctly replaced.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KARAF-1149) Karaf MBeanServer is not usable behind firewall

2016-06-09 Thread JIRA 

[ 
https://issues.apache.org/jira/browse/KARAF-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15322215#comment-15322215
 ] 

Jean-Baptiste Onofré commented on KARAF-1149:
-

Re-testing with Docker.

> Karaf MBeanServer is not usable behind firewall
> ---
>
> Key: KARAF-1149
> URL: https://issues.apache.org/jira/browse/KARAF-1149
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-management
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.1.0, 3.0.7, 4.0.6
>
>
> If network administrator opens the network ports to use Karaf MBean server 
> (for instance, by default, 1099 for the RMI Registry and 4 for the RMI 
> server), the JVM open random port for JMX communication.
> It could be helpful to provide a JMX agent or at least to document how to use 
> Karaf MBean server behind firewalls.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KARAF-1149) Karaf MBeanServer is not usable behind firewall

2016-06-09 Thread JIRA 

 [ 
https://issues.apache.org/jira/browse/KARAF-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Baptiste Onofré updated KARAF-1149:

Fix Version/s: 4.0.6
   3.0.7
   4.1.0

> Karaf MBeanServer is not usable behind firewall
> ---
>
> Key: KARAF-1149
> URL: https://issues.apache.org/jira/browse/KARAF-1149
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-management
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.1.0, 3.0.7, 4.0.6
>
>
> If network administrator opens the network ports to use Karaf MBean server 
> (for instance, by default, 1099 for the RMI Registry and 4 for the RMI 
> server), the JVM open random port for JMX communication.
> It could be helpful to provide a JMX agent or at least to document how to use 
> Karaf MBean server behind firewalls.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (KARAF-1149) Karaf MBeanServer is not usable behind firewall

2016-06-09 Thread JIRA 

 [ 
https://issues.apache.org/jira/browse/KARAF-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Baptiste Onofré reopened KARAF-1149:
-
  Assignee: Jean-Baptiste Onofré  (was: Guillaume Nodet)

We have a similar issue with Docker.

I think that we have to use something like:

{code}
-Dcom.sun.management.jmxremote.local.only=false
-Djava.rmi.server.hostname=x.x.x.x
{code}

Right now, we use something like:

{code}
-Djava.rmi.server.hostname=x.x.x.x
-Dcom.sun.management.jmxremote.port=4
-Dcom.sun.management.jmxremote.rmi.port=1099
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.authenticate=false 
-Dcom.sun.management.jmxremote.ssl=false
{code}

Let me check the code in the Karaf MBeanServer.

> Karaf MBeanServer is not usable behind firewall
> ---
>
> Key: KARAF-1149
> URL: https://issues.apache.org/jira/browse/KARAF-1149
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-management
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>
> If network administrator opens the network ports to use Karaf MBean server 
> (for instance, by default, 1099 for the RMI Registry and 4 for the RMI 
> server), the JVM open random port for JMX communication.
> It could be helpful to provide a JMX agent or at least to document how to use 
> Karaf MBean server behind firewalls.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KARAF-1149) Karaf MBeanServer is not usable behind firewall

2016-06-09 Thread JIRA 

 [ 
https://issues.apache.org/jira/browse/KARAF-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Baptiste Onofré updated KARAF-1149:

Component/s: karaf-management

> Karaf MBeanServer is not usable behind firewall
> ---
>
> Key: KARAF-1149
> URL: https://issues.apache.org/jira/browse/KARAF-1149
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-management
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>
> If network administrator opens the network ports to use Karaf MBean server 
> (for instance, by default, 1099 for the RMI Registry and 4 for the RMI 
> server), the JVM open random port for JMX communication.
> It could be helpful to provide a JMX agent or at least to document how to use 
> Karaf MBean server behind firewalls.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work started] (KARAF-4566) "karaf" script invokes /bin/sh but requires /bin/bash functions

2016-06-09 Thread JIRA 

 [ 
https://issues.apache.org/jira/browse/KARAF-4566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on KARAF-4566 started by Jean-Baptiste Onofré.
---
>  "karaf" script invokes /bin/sh but requires /bin/bash functions
> 
>
> Key: KARAF-4566
> URL: https://issues.apache.org/jira/browse/KARAF-4566
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-core
>Affects Versions: 3.0.6
> Environment: 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.6
>
>
> The bin/karaf script uses the "local" command which is a shell builtin of 
> bash and similar shells, but is not required for POSIX-compliance in sh. When 
> I attempt to run karaf on a Solaris system, I see the following output:
> root@solaris:/opendaylight/bin# ./karaf
> ./karaf[172]: local: not found [No such file or directory]
> ./karaf[182]: local: not found [No such file or directory]
> ./karaf[183]: local: not found [No such file or directory]
> Lines 172, 182 and 183 invoke "local" to make local variables to the 
> function. According to "man bash", this is a shell builtin. However, 
> bin/karaf is invoked as:
> #!/bin/sh
> On most flavors of linux, this resolves to bash or dash which probably runs 
> in a restricted environment after checking to see that its $0 is sh. But on 
> Solaris's /bin/sh is actually ksh93 for backwards compatibility.
> Since "local" is not part of a POSIX-compliant /bin/sh, depending on it in a 
> script that is invoked with /bin/sh is a bug.
> (this explaination is borrowed from 
> https://issues.apache.org/jira/browse/MNG-5852)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KARAF-4565) Set ConfigurationPolicy.REQUIRE for decanter appenders and collectors

2016-06-09 Thread Christian Schneider (JIRA) 

[ 
https://issues.apache.org/jira/browse/KARAF-4565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15322101#comment-15322101
 ] 

Christian Schneider commented on KARAF-4565:


It came up with the spring boot support but it is relevant for all deployments 
where you can not change the running bundles at runtime.

As long as we deploy the default configs using the features the behaviour in 
plain karaf should be the same.

> Set ConfigurationPolicy.REQUIRE for decanter appenders and collectors
> -
>
> Key: KARAF-4565
> URL: https://issues.apache.org/jira/browse/KARAF-4565
> Project: Karaf
>  Issue Type: Improvement
>  Components: decanter
>Affects Versions: decanter-1.1.0
>Reporter: Christian Schneider
>Assignee: Christian Schneider
> Fix For: decanter-1.1.1
>
>
> Currently decanter components start with defaults if no config is supplied.
> I would like to change this so the component only starts if a config is 
> supplied. Defaults still apply but the presence of an empty  config can then 
> be used to swtich the component on and off.
> This is especially important for fixed deployments were a set of components 
> is deployed but you want to configure which ones to actually use.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)