[jira] [Commented] (KARAF-4985) Karaf does not start with JDK 9 in Windows
[
https://issues.apache.org/jira/browse/KARAF-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16103785#comment-16103785
]
Guillaume Nodet commented on KARAF-4985:
See KARAF-3518 for additional informations about JDK 9.
> Karaf does not start with JDK 9 in Windows
> ---
>
> Key: KARAF-4985
> URL: https://issues.apache.org/jira/browse/KARAF-4985
> Project: Karaf
> Issue Type: Bug
> Components: karaf-os-integration
>Affects Versions: 4.1.0
> Environment: Windows 7, Java 9 (JDK and JRE 9 - ea+156)
>Reporter: Lijun Liao
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.2.0, 4.1.2
>
>
> Under JDK / JRE 9 (tested with ea+156) in Windows 7, karaf does not start
> Steps to reproduce the problem:
> 1. Start karaf {code}bin/karaf{code} and you will get the following error
> {code}
> -Djava.endorsed.dir=C:\Program Files\Java\jdk-9\jre\lib\endorsed:C:\Program
> Files\Java\jdk-9\lib\endorsed:D:\apache-karaf-4.1.0\bin\..\lib\endorsed is
> not supported. Endorsed standards and standalone APIs
> in modular form will be supported via the concept of upgradeable modules.
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (KARAF-5275) Add systemd journal logging support
[ https://issues.apache.org/jira/browse/KARAF-5275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16103530#comment-16103530 ] Michael Vorburger edited comment on KARAF-5275 at 7/27/17 5:22 PM: --- Started looking at the Pax Logging side of things.. https://groups.google.com/d/msg/ops4j/wFC_C36T-hM/v3cBKJFABQAJ ... was (Author: vorburger): Started looked at the Pax Logging side of things.. https://groups.google.com/d/msg/ops4j/wFC_C36T-hM/v3cBKJFABQAJ ... > Add systemd journal logging support > --- > > Key: KARAF-5275 > URL: https://issues.apache.org/jira/browse/KARAF-5275 > Project: Karaf > Issue Type: New Feature > Components: karaf-os-integration >Affects Versions: 4.0.9 >Reporter: Michael Vorburger > > KARAF-3858 introduced systemd support in the wrapper. > But (unless I'm missing something), Karaf cannot yet log to the systemd > journal, out of the box? > https://github.com/bwaldvogel/log4j-systemd-journal-appender is a project > which seems to make this easy. Would a contribution to Karaf to include this > external library in the distribution and have an example configuration in > etc/org.ops4j.pax.logging.cfg be welcome? > Or am I getting this all wrong, and this needs to go into OPS4j's PAX > Logging, first? Duh... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KARAF-5275) Add systemd journal logging support
[ https://issues.apache.org/jira/browse/KARAF-5275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16103530#comment-16103530 ] Michael Vorburger commented on KARAF-5275: -- Started looked at the Pax Logging side of things.. https://groups.google.com/d/msg/ops4j/wFC_C36T-hM/v3cBKJFABQAJ ... > Add systemd journal logging support > --- > > Key: KARAF-5275 > URL: https://issues.apache.org/jira/browse/KARAF-5275 > Project: Karaf > Issue Type: New Feature > Components: karaf-os-integration >Affects Versions: 4.0.9 >Reporter: Michael Vorburger > > KARAF-3858 introduced systemd support in the wrapper. > But (unless I'm missing something), Karaf cannot yet log to the systemd > journal, out of the box? > https://github.com/bwaldvogel/log4j-systemd-journal-appender is a project > which seems to make this easy. Would a contribution to Karaf to include this > external library in the distribution and have an example configuration in > etc/org.ops4j.pax.logging.cfg be welcome? > Or am I getting this all wrong, and this needs to go into OPS4j's PAX > Logging, first? Duh... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KARAF-3858) Add systemd support in the wrapper
[ https://issues.apache.org/jira/browse/KARAF-3858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16103464#comment-16103464 ] Michael Vorburger commented on KARAF-3858: -- New issue KARAF-5275 opened for vaguely related topic of systemd journal logging support. > Add systemd support in the wrapper > -- > > Key: KARAF-3858 > URL: https://issues.apache.org/jira/browse/KARAF-3858 > Project: Karaf > Issue Type: Improvement > Components: karaf-os-integration >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré > Fix For: 3.0.5, 4.0.2 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (KARAF-5275) Add systemd journal logging support
Michael Vorburger created KARAF-5275: Summary: Add systemd journal logging support Key: KARAF-5275 URL: https://issues.apache.org/jira/browse/KARAF-5275 Project: Karaf Issue Type: New Feature Components: karaf-os-integration Affects Versions: 4.0.9 Reporter: Michael Vorburger KARAF-3858 introduced systemd support in the wrapper. But (unless I'm missing something), Karaf cannot yet log to the systemd journal, out of the box? https://github.com/bwaldvogel/log4j-systemd-journal-appender is a project which seems to make this easy. Would a contribution to Karaf to include this external library in the distribution and have an example configuration in etc/org.ops4j.pax.logging.cfg be welcome? Or am I getting this all wrong, and this needs to go into OPS4j's PAX Logging, first? Duh... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KARAF-5274) update bundle list status for fragments attached vs not attached
[ https://issues.apache.org/jira/browse/KARAF-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16103253#comment-16103253 ] Steven Spungin commented on KARAF-5274: --- The only issue I see in using a different 'word' is for code that may use the output of bundle:list. For example, I wrote some scripts in the past to ssh into karaf and loop until all bundles were active. But then again, those scripts had to special case the fragments... > update bundle list status for fragments attached vs not attached > > > Key: KARAF-5274 > URL: https://issues.apache.org/jira/browse/KARAF-5274 > Project: Karaf > Issue Type: Question > Components: karaf-shell >Reporter: Steven Spungin >Priority: Minor > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > I have a container with over 1000 bundles. There are about 25 fragments as > well. I understand that a fragment never has an active state. > When I list my bundles, I scan to see if there are any issues. I find it > annoying that the fragments are listed as Resolved. I would rather see > something like 'Attached'. This way I could grep the search results by > resolved to find issues without having to see the fragments mixed in. Of > course, if they are not attached to anything, I am OK with 'Resolved'. > I am not suggesting to change the OSGi status, just word used in the list. > Another solution would be to add a boolean column that displayed an 'X' on > not active bundles and unattached fragments. > I look forward to your feedback on this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KARAF-5274) update bundle list status for fragments attached vs not attached
[ https://issues.apache.org/jira/browse/KARAF-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16103244#comment-16103244 ] Steven Spungin commented on KARAF-5274: --- Exactly. Basically a way to differentiate a bundle that is 'doing something' verses 'not doing something'. I feel fragments that are attached and bundles that are active are the same category, and everything else is in another. I understand why OSGi does not use active states on bundles, but it makes the bundle:list a bit confusing. > update bundle list status for fragments attached vs not attached > > > Key: KARAF-5274 > URL: https://issues.apache.org/jira/browse/KARAF-5274 > Project: Karaf > Issue Type: Question > Components: karaf-shell >Reporter: Steven Spungin >Priority: Minor > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > I have a container with over 1000 bundles. There are about 25 fragments as > well. I understand that a fragment never has an active state. > When I list my bundles, I scan to see if there are any issues. I find it > annoying that the fragments are listed as Resolved. I would rather see > something like 'Attached'. This way I could grep the search results by > resolved to find issues without having to see the fragments mixed in. Of > course, if they are not attached to anything, I am OK with 'Resolved'. > I am not suggesting to change the OSGi status, just word used in the list. > Another solution would be to add a boolean column that displayed an 'X' on > not active bundles and unattached fragments. > I look forward to your feedback on this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KARAF-5274) update bundle list status for fragments attached vs not attached
[
https://issues.apache.org/jira/browse/KARAF-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16103184#comment-16103184
]
Jean-Baptiste Onofré commented on KARAF-5274:
-
So, basically, in {{bundle:list}} command, you are proposing to display
{{Attached}} for the fragments actually link to a host, and keep resolved for
the "isolated" fragments (same in the BundleMBean) ?
> update bundle list status for fragments attached vs not attached
>
>
> Key: KARAF-5274
> URL: https://issues.apache.org/jira/browse/KARAF-5274
> Project: Karaf
> Issue Type: Question
> Components: karaf-shell
>Reporter: Steven Spungin
>Priority: Minor
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> I have a container with over 1000 bundles. There are about 25 fragments as
> well. I understand that a fragment never has an active state.
> When I list my bundles, I scan to see if there are any issues. I find it
> annoying that the fragments are listed as Resolved. I would rather see
> something like 'Attached'. This way I could grep the search results by
> resolved to find issues without having to see the fragments mixed in. Of
> course, if they are not attached to anything, I am OK with 'Resolved'.
> I am not suggesting to change the OSGi status, just word used in the list.
> Another solution would be to add a boolean column that displayed an 'X' on
> not active bundles and unattached fragments.
> I look forward to your feedback on this.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (KARAF-5274) update bundle list status for fragments attached vs not attached
[ https://issues.apache.org/jira/browse/KARAF-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-5274: Issue Type: Question (was: Bug) > update bundle list status for fragments attached vs not attached > > > Key: KARAF-5274 > URL: https://issues.apache.org/jira/browse/KARAF-5274 > Project: Karaf > Issue Type: Question > Components: karaf-shell >Reporter: Steven Spungin >Priority: Minor > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > I have a container with over 1000 bundles. There are about 25 fragments as > well. I understand that a fragment never has an active state. > When I list my bundles, I scan to see if there are any issues. I find it > annoying that the fragments are listed as Resolved. I would rather see > something like 'Attached'. This way I could grep the search results by > resolved to find issues without having to see the fragments mixed in. Of > course, if they are not attached to anything, I am OK with 'Resolved'. > I am not suggesting to change the OSGi status, just word used in the list. > Another solution would be to add a boolean column that displayed an 'X' on > not active bundles and unattached fragments. > I look forward to your feedback on this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (KARAF-5274) update bundle list status for fragments attached vs not attached
[ https://issues.apache.org/jira/browse/KARAF-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-5274: Component/s: karaf-shell > update bundle list status for fragments attached vs not attached > > > Key: KARAF-5274 > URL: https://issues.apache.org/jira/browse/KARAF-5274 > Project: Karaf > Issue Type: Question > Components: karaf-shell >Reporter: Steven Spungin >Priority: Minor > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > I have a container with over 1000 bundles. There are about 25 fragments as > well. I understand that a fragment never has an active state. > When I list my bundles, I scan to see if there are any issues. I find it > annoying that the fragments are listed as Resolved. I would rather see > something like 'Attached'. This way I could grep the search results by > resolved to find issues without having to see the fragments mixed in. Of > course, if they are not attached to anything, I am OK with 'Resolved'. > I am not suggesting to change the OSGi status, just word used in the list. > Another solution would be to add a boolean column that displayed an 'X' on > not active bundles and unattached fragments. > I look forward to your feedback on this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KARAF-4985) Karaf does not start with JDK 9 in Windows
[
https://issues.apache.org/jira/browse/KARAF-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16103179#comment-16103179
]
Jean-Baptiste Onofré commented on KARAF-4985:
-
In the Unix {{karaf}} script, we test the JDK version and use different command
line argument for Java 9 and previous version:
{code}
if [ "${VERSION}" -gt "80" ]; then
${KARAF_EXEC} "${JAVA}" ${JAVA_OPTS} \
--add-opens java.base/java.security=ALL-UNNAMED \
--add-opens java.base/java.net=ALL-UNNAMED \
--add-opens java.base/java.lang=ALL-UNNAMED \
--add-opens java.base/java.util=ALL-UNNAMED \
--add-exports=java.base/sun.net.www.protocol.http=ALL-UNNAMED \
--add-exports=java.base/sun.net.www.protocol.https=ALL-UNNAMED \
--add-exports=java.base/sun.net.www.protocol.jar=ALL-UNNAMED \
--add-exports=java.xml.bind/com.sun.xml.internal.bind.v2.runtime=ALL-UNNAMED \
--add-exports=jdk.xml.dom/org.w3c.dom.html=ALL-UNNAMED \
--add-exports=jdk.naming.rmi/com.sun.jndi.url.rmi=ALL-UNNAMED \
--add-modules
java.xml.ws.annotation,java.corba,java.transaction,java.xml.bind,java.xml.ws \
-Dkaraf.instances="${KARAF_HOME}/instances" \
-Dkaraf.home="${KARAF_HOME}" \
-Dkaraf.base="${KARAF_BASE}" \
-Dkaraf.data="${KARAF_DATA}" \
-Dkaraf.etc="${KARAF_ETC}" \
-Dkaraf.restart.jvm.supported=true \
-Djava.io.tmpdir="${KARAF_DATA}/tmp" \
-Djava.util.logging.config.file="${KARAF_BASE}/etc/java.util.logging.properties"
\
${KARAF_SYSTEM_OPTS} \
${KARAF_OPTS} \
${OPTS} \
-classpath "${CLASSPATH}" \
${MAIN} "$@"
else
${KARAF_EXEC} "${JAVA}" ${JAVA_OPTS} \
-Djava.endorsed.dirs="${JAVA_ENDORSED_DIRS}" \
-Djava.ext.dirs="${JAVA_EXT_DIRS}" \
-Dkaraf.instances="${KARAF_HOME}/instances" \
-Dkaraf.home="${KARAF_HOME}" \
-Dkaraf.base="${KARAF_BASE}" \
-Dkaraf.data="${KARAF_DATA}" \
-Dkaraf.etc="${KARAF_ETC}" \
-Dkaraf.restart.jvm.supported=true \
-Djava.io.tmpdir="${KARAF_DATA}/tmp" \
-Djava.util.logging.config.file="${KARAF_BASE}/etc/java.util.logging.properties"
\
${KARAF_SYSTEM_OPTS} \
${KARAF_OPTS} \
${OPTS} \
-classpath "${CLASSPATH}" \
${MAIN} "$@"
fi
{code}
Unfortunately, it has not been apply to {{karaf.bat}} script.
I'm fixing.
> Karaf does not start with JDK 9 in Windows
> ---
>
> Key: KARAF-4985
> URL: https://issues.apache.org/jira/browse/KARAF-4985
> Project: Karaf
> Issue Type: Bug
> Components: karaf-os-integration
>Affects Versions: 4.1.0
> Environment: Windows 7, Java 9 (JDK and JRE 9 - ea+156)
>Reporter: Lijun Liao
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.2.0, 4.1.2
>
>
> Under JDK / JRE 9 (tested with ea+156) in Windows 7, karaf does not start
> Steps to reproduce the problem:
> 1. Start karaf {code}bin/karaf{code} and you will get the following error
> {code}
> -Djava.endorsed.dir=C:\Program Files\Java\jdk-9\jre\lib\endorsed:C:\Program
> Files\Java\jdk-9\lib\endorsed:D:\apache-karaf-4.1.0\bin\..\lib\endorsed is
> not supported. Endorsed standards and standalone APIs
> in modular form will be supported via the concept of upgradeable modules.
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (KARAF-5054) Default rmiRegistryPort 1099 is used always besides different configuration
[
https://issues.apache.org/jira/browse/KARAF-5054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16102939#comment-16102939
]
Jean-Baptiste Onofré commented on KARAF-5054:
-
It sounds like a race condition where the configuration is loaded after the
activator start. Let me try to reproduce.
> Default rmiRegistryPort 1099 is used always besides different configuration
> ---
>
> Key: KARAF-5054
> URL: https://issues.apache.org/jira/browse/KARAF-5054
> Project: Karaf
> Issue Type: Bug
> Components: karaf-management
>Affects Versions: 4.1.0
> Environment: Windows 7 64bit, karaf 4.1.0 binary distribution, java
> 1.8.0_121, clean start
>Reporter: Jens Vagts
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.1.2
>
>
> When starting a _clean_ karaf instance (either very first first start or with
> {{clean}} command line parameter) the karaf management feature always tries
> to open the default port {{1099}} before opening the configured port
> resulting in a confusing exception in the {{karaf.log}}:
> {noformat}
> 2017-03-22T08:08:51,523 | WARN | pool-23-thread-1 | Activator
> | 38 - org.apache.karaf.management.server - 4.1.0 | Error starting
> activator
> java.rmi.server.ExportException: Port already in use: 1099; nested exception
> is:
> java.net.BindException: Address already in use: JVM_Bind
> at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:341)
> [?:?]
> at
> sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:249) [?:?]
> at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:411)
> [?:?]
> at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147) [?:?]
> at
> sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:234) [?:?]
> at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:195) [?:?]
> at sun.rmi.registry.RegistryImpl.(RegistryImpl.java:180) [?:?]
> at
> java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:203) [?:?]
> at
> org.apache.karaf.management.RmiRegistryFactory.init(RmiRegistryFactory.java:128)
> [38:org.apache.karaf.management.server:4.1.0]
> at
> org.apache.karaf.management.internal.Activator.doStart(Activator.java:104)
> [38:org.apache.karaf.management.server:4.1.0]
> at
> org.apache.karaf.util.tracker.BaseActivator.run(BaseActivator.java:242)
> [38:org.apache.karaf.management.server:4.1.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
> 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) [?:?]
> Caused by: java.net.BindException: Address already in use: JVM_Bind
> at java.net.DualStackPlainSocketImpl.bind0(Native Method) ~[?:?]
> at
> java.net.DualStackPlainSocketImpl.socketBind(DualStackPlainSocketImpl.java:106)
> ~[?:?]
> at
> java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387) ~[?:?]
> at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:190) ~[?:?]
> at java.net.ServerSocket.bind(ServerSocket.java:375) ~[?:?]
> at java.net.ServerSocket.(ServerSocket.java:237) ~[?:?]
> at java.net.ServerSocket.(ServerSocket.java:128) ~[?:?]
> at
> sun.rmi.transport.proxy.RMIDirectSocketFactory.createServerSocket(RMIDirectSocketFactory.java:45)
> ~[?:?]
> at
> sun.rmi.transport.proxy.RMIMasterSocketFactory.createServerSocket(RMIMasterSocketFactory.java:345)
> ~[?:?]
> at
> sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:666) ~[?:?]
> at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:330)
> ~[?:?]
> ... 15 more
> {noformat}
> if the port is already used by another process (e.g. another karaf instance).
> The configured port {{rmiRegistryPort = 1100}} in the config file
> {{org.apache.karaf.management.cfg}} will be nevertheless applied afterwards.
> This can easily reproduced by creating two instances of the standard karaf
> {{4.1.0}} binary distributions and applying above configuration to the second
> instance.
> This occurs on _Windows_ (7 64 bit tested) only, and can *not* be reproduced
> on _Linux_ OS!
> The same behavior (of using the default port before the differently
> configured one) has been observed for other ports as of: rmi server port
> ({{rmiServerPort}} in {{org.apache.karaf.management.cfg}}) and ssh
> ({{sshPort}} in {{org.apache.karaf.shell.cfg}}. Depending on the logging
> configuration the
[jira] [Work started] (KARAF-5054) Default rmiRegistryPort 1099 is used always besides different configuration
[
https://issues.apache.org/jira/browse/KARAF-5054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on KARAF-5054 started by Jean-Baptiste Onofré.
---
> Default rmiRegistryPort 1099 is used always besides different configuration
> ---
>
> Key: KARAF-5054
> URL: https://issues.apache.org/jira/browse/KARAF-5054
> Project: Karaf
> Issue Type: Bug
> Components: karaf-management
>Affects Versions: 4.1.0
> Environment: Windows 7 64bit, karaf 4.1.0 binary distribution, java
> 1.8.0_121, clean start
>Reporter: Jens Vagts
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.1.2
>
>
> When starting a _clean_ karaf instance (either very first first start or with
> {{clean}} command line parameter) the karaf management feature always tries
> to open the default port {{1099}} before opening the configured port
> resulting in a confusing exception in the {{karaf.log}}:
> {noformat}
> 2017-03-22T08:08:51,523 | WARN | pool-23-thread-1 | Activator
> | 38 - org.apache.karaf.management.server - 4.1.0 | Error starting
> activator
> java.rmi.server.ExportException: Port already in use: 1099; nested exception
> is:
> java.net.BindException: Address already in use: JVM_Bind
> at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:341)
> [?:?]
> at
> sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:249) [?:?]
> at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:411)
> [?:?]
> at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147) [?:?]
> at
> sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:234) [?:?]
> at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:195) [?:?]
> at sun.rmi.registry.RegistryImpl.(RegistryImpl.java:180) [?:?]
> at
> java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:203) [?:?]
> at
> org.apache.karaf.management.RmiRegistryFactory.init(RmiRegistryFactory.java:128)
> [38:org.apache.karaf.management.server:4.1.0]
> at
> org.apache.karaf.management.internal.Activator.doStart(Activator.java:104)
> [38:org.apache.karaf.management.server:4.1.0]
> at
> org.apache.karaf.util.tracker.BaseActivator.run(BaseActivator.java:242)
> [38:org.apache.karaf.management.server:4.1.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
> 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) [?:?]
> Caused by: java.net.BindException: Address already in use: JVM_Bind
> at java.net.DualStackPlainSocketImpl.bind0(Native Method) ~[?:?]
> at
> java.net.DualStackPlainSocketImpl.socketBind(DualStackPlainSocketImpl.java:106)
> ~[?:?]
> at
> java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387) ~[?:?]
> at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:190) ~[?:?]
> at java.net.ServerSocket.bind(ServerSocket.java:375) ~[?:?]
> at java.net.ServerSocket.(ServerSocket.java:237) ~[?:?]
> at java.net.ServerSocket.(ServerSocket.java:128) ~[?:?]
> at
> sun.rmi.transport.proxy.RMIDirectSocketFactory.createServerSocket(RMIDirectSocketFactory.java:45)
> ~[?:?]
> at
> sun.rmi.transport.proxy.RMIMasterSocketFactory.createServerSocket(RMIMasterSocketFactory.java:345)
> ~[?:?]
> at
> sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:666) ~[?:?]
> at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:330)
> ~[?:?]
> ... 15 more
> {noformat}
> if the port is already used by another process (e.g. another karaf instance).
> The configured port {{rmiRegistryPort = 1100}} in the config file
> {{org.apache.karaf.management.cfg}} will be nevertheless applied afterwards.
> This can easily reproduced by creating two instances of the standard karaf
> {{4.1.0}} binary distributions and applying above configuration to the second
> instance.
> This occurs on _Windows_ (7 64 bit tested) only, and can *not* be reproduced
> on _Linux_ OS!
> The same behavior (of using the default port before the differently
> configured one) has been observed for other ports as of: rmi server port
> ({{rmiServerPort}} in {{org.apache.karaf.management.cfg}}) and ssh
> ({{sshPort}} in {{org.apache.karaf.shell.cfg}}. Depending on the logging
> configuration the failing usage of the default ports can be seen before the
> configured ports are taken into account.
> Re-configuring the ports at runtime via
[jira] [Updated] (KARAF-4336) Add support for ordering of CLI scripts and commands in karaf-maven-plugin
[
https://issues.apache.org/jira/browse/KARAF-4336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated KARAF-4336:
Fix Version/s: (was: 4.1.2)
4.1.3
4.2.0
> Add support for ordering of CLI scripts and commands in karaf-maven-plugin
> --
>
> Key: KARAF-4336
> URL: https://issues.apache.org/jira/browse/KARAF-4336
> Project: Karaf
> Issue Type: Improvement
> Components: karaf-tooling
>Affects Versions: 4.0.4
>Reporter: Martin Basovník
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.2.0, 4.0.10, 4.1.3
>
>
> {code:xml}
>
>
> setup1.cli
> setup2.cli
>
>
> feature:repo-add camel ${version.camel}
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (KARAF-4336) Add support for ordering of CLI scripts and commands in karaf-maven-plugin
[
https://issues.apache.org/jira/browse/KARAF-4336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15739455#comment-15739455
]
Jean-Baptiste Onofré edited comment on KARAF-4336 at 7/27/17 8:39 AM:
--
I guess {{karaf:client}}.
was (Author: jbonofre):
I guess {{karaf:run}} and {{karaf:client}}.
> Add support for ordering of CLI scripts and commands in karaf-maven-plugin
> --
>
> Key: KARAF-4336
> URL: https://issues.apache.org/jira/browse/KARAF-4336
> Project: Karaf
> Issue Type: Improvement
> Components: karaf-tooling
>Affects Versions: 4.0.4
>Reporter: Martin Basovník
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.1.2, 4.0.10
>
>
> {code:xml}
>
>
> setup1.cli
> setup2.cli
>
>
> feature:repo-add camel ${version.camel}
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (KARAF-5217) client.bat not working when passwords are encrypted
[
https://issues.apache.org/jira/browse/KARAF-5217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marko Herchet closed KARAF-5217.
> client.bat not working when passwords are encrypted
> ---
>
> Key: KARAF-5217
> URL: https://issues.apache.org/jira/browse/KARAF-5217
> Project: Karaf
> Issue Type: Bug
> Components: karaf-shell
>Affects Versions: 4.1.1
>Reporter: Marko Herchet
>Assignee: Jean-Baptiste Onofré
>
> When using the bin\client.bat without specifying a user,
> org.apache.karaf.client.ClientConfig determines username + password by
> parsing the etc\users.properties and using the first user + pw.
> When I set "encryption.enabled = false" in org.apache.karaf.jaas.cfg, my
> users.properties looks like this:
> {code}
> karafuser = anypw,admin
> {code}
> it works and the shell opens.
> When I set "encryption.enabled = true" in org.apache.karaf.jaas.cfg, my
> users.properties looks like this:
> {code}
> karafuser =
> {CRYPT}8FEF7493AC1C5A5EC2D1C051576DEF6B32E1D834302DC46C396F325C82214DF3{CRYPT},admin
> {code}
> I get the following LogEntry and it prompts for password
> 1094 [sshd-SshClient[1afa04c]-nio2-thread-4] TRACE
> org.apache.sshd.client.session.ClientSessionImpl -
> doHandleMessage(ClientSessionImpl[karafuser@localhost/127.0.0.1:8101])
> process SSH_MSG_USERAUTH_FAILURE
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (KARAF-5217) client.bat not working when passwords are encrypted
[
https://issues.apache.org/jira/browse/KARAF-5217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16102891#comment-16102891
]
Marko Herchet commented on KARAF-5217:
--
I think its a bit strange cause in my case the client and the karaf I want to
connect to are from the same instance and theoretically have access to
everything required.
Thanks for the feedback.
Think I will try auth by certificate
> client.bat not working when passwords are encrypted
> ---
>
> Key: KARAF-5217
> URL: https://issues.apache.org/jira/browse/KARAF-5217
> Project: Karaf
> Issue Type: Bug
> Components: karaf-shell
>Affects Versions: 4.1.1
>Reporter: Marko Herchet
>Assignee: Jean-Baptiste Onofré
>
> When using the bin\client.bat without specifying a user,
> org.apache.karaf.client.ClientConfig determines username + password by
> parsing the etc\users.properties and using the first user + pw.
> When I set "encryption.enabled = false" in org.apache.karaf.jaas.cfg, my
> users.properties looks like this:
> {code}
> karafuser = anypw,admin
> {code}
> it works and the shell opens.
> When I set "encryption.enabled = true" in org.apache.karaf.jaas.cfg, my
> users.properties looks like this:
> {code}
> karafuser =
> {CRYPT}8FEF7493AC1C5A5EC2D1C051576DEF6B32E1D834302DC46C396F325C82214DF3{CRYPT},admin
> {code}
> I get the following LogEntry and it prompts for password
> 1094 [sshd-SshClient[1afa04c]-nio2-thread-4] TRACE
> org.apache.sshd.client.session.ClientSessionImpl -
> doHandleMessage(ClientSessionImpl[karafuser@localhost/127.0.0.1:8101])
> process SSH_MSG_USERAUTH_FAILURE
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (KARAF-5273) karaf-maven-plugin assembly should take feature wildcards
[ https://issues.apache.org/jira/browse/KARAF-5273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré reassigned KARAF-5273: --- Assignee: Jean-Baptiste Onofré > karaf-maven-plugin assembly should take feature wildcards > - > > Key: KARAF-5273 > URL: https://issues.apache.org/jira/browse/KARAF-5273 > Project: Karaf > Issue Type: Improvement >Reporter: Fabian Lange >Assignee: Jean-Baptiste Onofré > > As per discussion in: > http://karaf.922171.n3.nabble.com/Building-custom-dist-including-all-features-of-a-repository-td4051100.html > it would be great if the assembly part of the karaf-maven-plugin would > respect wildcards for startup/boot/installed feature names. currently it only > performs an equals check, requiring dist builders to explicitly list all the > features they want. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (KARAF-5273) karaf-maven-plugin assembly should take feature wildcards
Fabian Lange created KARAF-5273: --- Summary: karaf-maven-plugin assembly should take feature wildcards Key: KARAF-5273 URL: https://issues.apache.org/jira/browse/KARAF-5273 Project: Karaf Issue Type: Improvement Reporter: Fabian Lange As per discussion in: http://karaf.922171.n3.nabble.com/Building-custom-dist-including-all-features-of-a-repository-td4051100.html it would be great if the assembly part of the karaf-maven-plugin would respect wildcards for startup/boot/installed feature names. currently it only performs an equals check, requiring dist builders to explicitly list all the features they want. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (KARAF-5217) client.bat not working when passwords are encrypted
[
https://issues.apache.org/jira/browse/KARAF-5217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré resolved KARAF-5217.
-
Resolution: Not A Problem
IMHO, it works as expected: encryption is one way, so the client can get the
password if encrypted and so it prompts for the password.
An alternative is to use authentication by certificate instead of
username/password.
> client.bat not working when passwords are encrypted
> ---
>
> Key: KARAF-5217
> URL: https://issues.apache.org/jira/browse/KARAF-5217
> Project: Karaf
> Issue Type: Bug
> Components: karaf-shell
>Affects Versions: 4.1.1
>Reporter: Marko Herchet
>Assignee: Jean-Baptiste Onofré
>
> When using the bin\client.bat without specifying a user,
> org.apache.karaf.client.ClientConfig determines username + password by
> parsing the etc\users.properties and using the first user + pw.
> When I set "encryption.enabled = false" in org.apache.karaf.jaas.cfg, my
> users.properties looks like this:
> {code}
> karafuser = anypw,admin
> {code}
> it works and the shell opens.
> When I set "encryption.enabled = true" in org.apache.karaf.jaas.cfg, my
> users.properties looks like this:
> {code}
> karafuser =
> {CRYPT}8FEF7493AC1C5A5EC2D1C051576DEF6B32E1D834302DC46C396F325C82214DF3{CRYPT},admin
> {code}
> I get the following LogEntry and it prompts for password
> 1094 [sshd-SshClient[1afa04c]-nio2-thread-4] TRACE
> org.apache.sshd.client.session.ClientSessionImpl -
> doHandleMessage(ClientSessionImpl[karafuser@localhost/127.0.0.1:8101])
> process SSH_MSG_USERAUTH_FAILURE
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (KARAF-5217) client.bat not working when passwords are encrypted
[
https://issues.apache.org/jira/browse/KARAF-5217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated KARAF-5217:
Fix Version/s: (was: 4.1.2)
> client.bat not working when passwords are encrypted
> ---
>
> Key: KARAF-5217
> URL: https://issues.apache.org/jira/browse/KARAF-5217
> Project: Karaf
> Issue Type: Bug
> Components: karaf-shell
>Affects Versions: 4.1.1
>Reporter: Marko Herchet
>Assignee: Jean-Baptiste Onofré
>
> When using the bin\client.bat without specifying a user,
> org.apache.karaf.client.ClientConfig determines username + password by
> parsing the etc\users.properties and using the first user + pw.
> When I set "encryption.enabled = false" in org.apache.karaf.jaas.cfg, my
> users.properties looks like this:
> {code}
> karafuser = anypw,admin
> {code}
> it works and the shell opens.
> When I set "encryption.enabled = true" in org.apache.karaf.jaas.cfg, my
> users.properties looks like this:
> {code}
> karafuser =
> {CRYPT}8FEF7493AC1C5A5EC2D1C051576DEF6B32E1D834302DC46C396F325C82214DF3{CRYPT},admin
> {code}
> I get the following LogEntry and it prompts for password
> 1094 [sshd-SshClient[1afa04c]-nio2-thread-4] TRACE
> org.apache.sshd.client.session.ClientSessionImpl -
> doHandleMessage(ClientSessionImpl[karafuser@localhost/127.0.0.1:8101])
> process SSH_MSG_USERAUTH_FAILURE
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (KARAF-5217) client.bat not working when passwords are encrypted
[
https://issues.apache.org/jira/browse/KARAF-5217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16102877#comment-16102877
]
Jean-Baptiste Onofré commented on KARAF-5217:
-
It's expected: when password is encrypted it's not possible for the client to
know and decrypt the password. So, with encryption enabled, prompting the
password is expected.
> client.bat not working when passwords are encrypted
> ---
>
> Key: KARAF-5217
> URL: https://issues.apache.org/jira/browse/KARAF-5217
> Project: Karaf
> Issue Type: Bug
> Components: karaf-shell
>Affects Versions: 4.1.1
>Reporter: Marko Herchet
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.1.2
>
>
> When using the bin\client.bat without specifying a user,
> org.apache.karaf.client.ClientConfig determines username + password by
> parsing the etc\users.properties and using the first user + pw.
> When I set "encryption.enabled = false" in org.apache.karaf.jaas.cfg, my
> users.properties looks like this:
> {code}
> karafuser = anypw,admin
> {code}
> it works and the shell opens.
> When I set "encryption.enabled = true" in org.apache.karaf.jaas.cfg, my
> users.properties looks like this:
> {code}
> karafuser =
> {CRYPT}8FEF7493AC1C5A5EC2D1C051576DEF6B32E1D834302DC46C396F325C82214DF3{CRYPT},admin
> {code}
> I get the following LogEntry and it prompts for password
> 1094 [sshd-SshClient[1afa04c]-nio2-thread-4] TRACE
> org.apache.sshd.client.session.ClientSessionImpl -
> doHandleMessage(ClientSessionImpl[karafuser@localhost/127.0.0.1:8101])
> process SSH_MSG_USERAUTH_FAILURE
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (KARAF-5217) client.bat not working when passwords are encrypted
[
https://issues.apache.org/jira/browse/KARAF-5217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16102868#comment-16102868
]
Marko Herchet commented on KARAF-5217:
--
{code}
It works fine on 4.2.0-SNAPSHOT as the password is prompted
{code}
I don't think it is the intended behavior that the password is prompted. It
only does when the password is encrypted.
When I use the client.bat with -v and -l 4 parameters I see the LogEntry.
> client.bat not working when passwords are encrypted
> ---
>
> Key: KARAF-5217
> URL: https://issues.apache.org/jira/browse/KARAF-5217
> Project: Karaf
> Issue Type: Bug
> Components: karaf-shell
>Affects Versions: 4.1.1
>Reporter: Marko Herchet
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.1.2
>
>
> When using the bin\client.bat without specifying a user,
> org.apache.karaf.client.ClientConfig determines username + password by
> parsing the etc\users.properties and using the first user + pw.
> When I set "encryption.enabled = false" in org.apache.karaf.jaas.cfg, my
> users.properties looks like this:
> {code}
> karafuser = anypw,admin
> {code}
> it works and the shell opens.
> When I set "encryption.enabled = true" in org.apache.karaf.jaas.cfg, my
> users.properties looks like this:
> {code}
> karafuser =
> {CRYPT}8FEF7493AC1C5A5EC2D1C051576DEF6B32E1D834302DC46C396F325C82214DF3{CRYPT},admin
> {code}
> I get the following LogEntry and it prompts for password
> 1094 [sshd-SshClient[1afa04c]-nio2-thread-4] TRACE
> org.apache.sshd.client.session.ClientSessionImpl -
> doHandleMessage(ClientSessionImpl[karafuser@localhost/127.0.0.1:8101])
> process SSH_MSG_USERAUTH_FAILURE
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (KARAF-5217) client.bat not working when passwords are encrypted
[
https://issues.apache.org/jira/browse/KARAF-5217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16102864#comment-16102864
]
Jean-Baptiste Onofré commented on KARAF-5217:
-
Hmm, it works fine with 4.1.1 (at least on Linux). Let me try on Windows.
> client.bat not working when passwords are encrypted
> ---
>
> Key: KARAF-5217
> URL: https://issues.apache.org/jira/browse/KARAF-5217
> Project: Karaf
> Issue Type: Bug
> Components: karaf-shell
>Affects Versions: 4.1.1
>Reporter: Marko Herchet
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.1.2
>
>
> When using the bin\client.bat without specifying a user,
> org.apache.karaf.client.ClientConfig determines username + password by
> parsing the etc\users.properties and using the first user + pw.
> When I set "encryption.enabled = false" in org.apache.karaf.jaas.cfg, my
> users.properties looks like this:
> {code}
> karafuser = anypw,admin
> {code}
> it works and the shell opens.
> When I set "encryption.enabled = true" in org.apache.karaf.jaas.cfg, my
> users.properties looks like this:
> {code}
> karafuser =
> {CRYPT}8FEF7493AC1C5A5EC2D1C051576DEF6B32E1D834302DC46C396F325C82214DF3{CRYPT},admin
> {code}
> I get the following LogEntry and it prompts for password
> 1094 [sshd-SshClient[1afa04c]-nio2-thread-4] TRACE
> org.apache.sshd.client.session.ClientSessionImpl -
> doHandleMessage(ClientSessionImpl[karafuser@localhost/127.0.0.1:8101])
> process SSH_MSG_USERAUTH_FAILURE
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (KARAF-5217) client.bat not working when passwords are encrypted
[
https://issues.apache.org/jira/browse/KARAF-5217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16102846#comment-16102846
]
Jean-Baptiste Onofré commented on KARAF-5217:
-
It works fine with 4.1.2-SNAPSHOT as well. I'm trying to reproduce with 4.1.1.
> client.bat not working when passwords are encrypted
> ---
>
> Key: KARAF-5217
> URL: https://issues.apache.org/jira/browse/KARAF-5217
> Project: Karaf
> Issue Type: Bug
> Components: karaf-shell
>Affects Versions: 4.1.1
>Reporter: Marko Herchet
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.1.2
>
>
> When using the bin\client.bat without specifying a user,
> org.apache.karaf.client.ClientConfig determines username + password by
> parsing the etc\users.properties and using the first user + pw.
> When I set "encryption.enabled = false" in org.apache.karaf.jaas.cfg, my
> users.properties looks like this:
> {code}
> karafuser = anypw,admin
> {code}
> it works and the shell opens.
> When I set "encryption.enabled = true" in org.apache.karaf.jaas.cfg, my
> users.properties looks like this:
> {code}
> karafuser =
> {CRYPT}8FEF7493AC1C5A5EC2D1C051576DEF6B32E1D834302DC46C396F325C82214DF3{CRYPT},admin
> {code}
> I get the following LogEntry and it prompts for password
> 1094 [sshd-SshClient[1afa04c]-nio2-thread-4] TRACE
> org.apache.sshd.client.session.ClientSessionImpl -
> doHandleMessage(ClientSessionImpl[karafuser@localhost/127.0.0.1:8101])
> process SSH_MSG_USERAUTH_FAILURE
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Work started] (KARAF-5217) client.bat not working when passwords are encrypted
[
https://issues.apache.org/jira/browse/KARAF-5217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on KARAF-5217 started by Jean-Baptiste Onofré.
---
> client.bat not working when passwords are encrypted
> ---
>
> Key: KARAF-5217
> URL: https://issues.apache.org/jira/browse/KARAF-5217
> Project: Karaf
> Issue Type: Bug
> Components: karaf-shell
>Affects Versions: 4.1.1
>Reporter: Marko Herchet
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.1.2
>
>
> When using the bin\client.bat without specifying a user,
> org.apache.karaf.client.ClientConfig determines username + password by
> parsing the etc\users.properties and using the first user + pw.
> When I set "encryption.enabled = false" in org.apache.karaf.jaas.cfg, my
> users.properties looks like this:
> {code}
> karafuser = anypw,admin
> {code}
> it works and the shell opens.
> When I set "encryption.enabled = true" in org.apache.karaf.jaas.cfg, my
> users.properties looks like this:
> {code}
> karafuser =
> {CRYPT}8FEF7493AC1C5A5EC2D1C051576DEF6B32E1D834302DC46C396F325C82214DF3{CRYPT},admin
> {code}
> I get the following LogEntry and it prompts for password
> 1094 [sshd-SshClient[1afa04c]-nio2-thread-4] TRACE
> org.apache.sshd.client.session.ClientSessionImpl -
> doHandleMessage(ClientSessionImpl[karafuser@localhost/127.0.0.1:8101])
> process SSH_MSG_USERAUTH_FAILURE
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (KARAF-5217) client.bat not working when passwords are encrypted
[
https://issues.apache.org/jira/browse/KARAF-5217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated KARAF-5217:
Fix Version/s: (was: 4.2.0)
> client.bat not working when passwords are encrypted
> ---
>
> Key: KARAF-5217
> URL: https://issues.apache.org/jira/browse/KARAF-5217
> Project: Karaf
> Issue Type: Bug
> Components: karaf-shell
>Affects Versions: 4.1.1
>Reporter: Marko Herchet
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.1.2
>
>
> When using the bin\client.bat without specifying a user,
> org.apache.karaf.client.ClientConfig determines username + password by
> parsing the etc\users.properties and using the first user + pw.
> When I set "encryption.enabled = false" in org.apache.karaf.jaas.cfg, my
> users.properties looks like this:
> {code}
> karafuser = anypw,admin
> {code}
> it works and the shell opens.
> When I set "encryption.enabled = true" in org.apache.karaf.jaas.cfg, my
> users.properties looks like this:
> {code}
> karafuser =
> {CRYPT}8FEF7493AC1C5A5EC2D1C051576DEF6B32E1D834302DC46C396F325C82214DF3{CRYPT},admin
> {code}
> I get the following LogEntry and it prompts for password
> 1094 [sshd-SshClient[1afa04c]-nio2-thread-4] TRACE
> org.apache.sshd.client.session.ClientSessionImpl -
> doHandleMessage(ClientSessionImpl[karafuser@localhost/127.0.0.1:8101])
> process SSH_MSG_USERAUTH_FAILURE
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (KARAF-5217) client.bat not working when passwords are encrypted
[
https://issues.apache.org/jira/browse/KARAF-5217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16102827#comment-16102827
]
Jean-Baptiste Onofré commented on KARAF-5217:
-
It works fine on 4.2.0-SNAPSHOT as the password is prompted. Trying on
4.1.2-SNAPSHOT.
> client.bat not working when passwords are encrypted
> ---
>
> Key: KARAF-5217
> URL: https://issues.apache.org/jira/browse/KARAF-5217
> Project: Karaf
> Issue Type: Bug
> Components: karaf-shell
>Affects Versions: 4.1.1
>Reporter: Marko Herchet
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.1.2
>
>
> When using the bin\client.bat without specifying a user,
> org.apache.karaf.client.ClientConfig determines username + password by
> parsing the etc\users.properties and using the first user + pw.
> When I set "encryption.enabled = false" in org.apache.karaf.jaas.cfg, my
> users.properties looks like this:
> {code}
> karafuser = anypw,admin
> {code}
> it works and the shell opens.
> When I set "encryption.enabled = true" in org.apache.karaf.jaas.cfg, my
> users.properties looks like this:
> {code}
> karafuser =
> {CRYPT}8FEF7493AC1C5A5EC2D1C051576DEF6B32E1D834302DC46C396F325C82214DF3{CRYPT},admin
> {code}
> I get the following LogEntry and it prompts for password
> 1094 [sshd-SshClient[1afa04c]-nio2-thread-4] TRACE
> org.apache.sshd.client.session.ClientSessionImpl -
> doHandleMessage(ClientSessionImpl[karafuser@localhost/127.0.0.1:8101])
> process SSH_MSG_USERAUTH_FAILURE
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (KARAF-5217) client.bat not working when passwords are encrypted
[
https://issues.apache.org/jira/browse/KARAF-5217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16102823#comment-16102823
]
Jean-Baptiste Onofré commented on KARAF-5217:
-
I think all environment (Linux/Windows) should be affected. Let me try.
> client.bat not working when passwords are encrypted
> ---
>
> Key: KARAF-5217
> URL: https://issues.apache.org/jira/browse/KARAF-5217
> Project: Karaf
> Issue Type: Bug
> Components: karaf-shell
>Affects Versions: 4.1.1
>Reporter: Marko Herchet
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.2.0, 4.1.2
>
>
> When using the bin\client.bat without specifying a user,
> org.apache.karaf.client.ClientConfig determines username + password by
> parsing the etc\users.properties and using the first user + pw.
> When I set "encryption.enabled = false" in org.apache.karaf.jaas.cfg, my
> users.properties looks like this:
> {code}
> karafuser = anypw,admin
> {code}
> it works and the shell opens.
> When I set "encryption.enabled = true" in org.apache.karaf.jaas.cfg, my
> users.properties looks like this:
> {code}
> karafuser =
> {CRYPT}8FEF7493AC1C5A5EC2D1C051576DEF6B32E1D834302DC46C396F325C82214DF3{CRYPT},admin
> {code}
> I get the following LogEntry and it prompts for password
> 1094 [sshd-SshClient[1afa04c]-nio2-thread-4] TRACE
> org.apache.sshd.client.session.ClientSessionImpl -
> doHandleMessage(ClientSessionImpl[karafuser@localhost/127.0.0.1:8101])
> process SSH_MSG_USERAUTH_FAILURE
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (KARAF-5217) client.bat not working when passwords are encrypted
[
https://issues.apache.org/jira/browse/KARAF-5217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated KARAF-5217:
Description:
When using the bin\client.bat without specifying a user,
org.apache.karaf.client.ClientConfig determines username + password by parsing
the etc\users.properties and using the first user + pw.
When I set "encryption.enabled = false" in org.apache.karaf.jaas.cfg, my
users.properties looks like this:
{code}
karafuser = anypw,admin
{code}
it works and the shell opens.
When I set "encryption.enabled = true" in org.apache.karaf.jaas.cfg, my
users.properties looks like this:
{code}
karafuser =
{CRYPT}8FEF7493AC1C5A5EC2D1C051576DEF6B32E1D834302DC46C396F325C82214DF3{CRYPT},admin
{code}
I get the following LogEntry and it prompts for password
1094 [sshd-SshClient[1afa04c]-nio2-thread-4] TRACE
org.apache.sshd.client.session.ClientSessionImpl -
doHandleMessage(ClientSessionImpl[karafuser@localhost/127.0.0.1:8101]) process
SSH_MSG_USERAUTH_FAILURE
was:
When using the bin\client.bat without specifying a user,
org.apache.karaf.client.ClientConfig determines username + password by parsing
the etc\users.properties and using the first user + pw.
When I set "encryption.enabled = false" in org.apache.karaf.jaas.cfg, my
users.properties looks like this:
{code}
karafuser = anypw,admin
{code}
it works and the shell opens.
When I set "encryption.enabled = false" in org.apache.karaf.jaas.cfg, my
users.properties looks like this:
{code}
karafuser =
{CRYPT}8FEF7493AC1C5A5EC2D1C051576DEF6B32E1D834302DC46C396F325C82214DF3{CRYPT},admin
{code}
I get the following LogEntry and it prompts for password
1094 [sshd-SshClient[1afa04c]-nio2-thread-4] TRACE
org.apache.sshd.client.session.ClientSessionImpl -
doHandleMessage(ClientSessionImpl[karafuser@localhost/127.0.0.1:8101]) process
SSH_MSG_USERAUTH_FAILURE
> client.bat not working when passwords are encrypted
> ---
>
> Key: KARAF-5217
> URL: https://issues.apache.org/jira/browse/KARAF-5217
> Project: Karaf
> Issue Type: Bug
> Components: karaf-shell
>Affects Versions: 4.1.1
>Reporter: Marko Herchet
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.2.0, 4.1.2
>
>
> When using the bin\client.bat without specifying a user,
> org.apache.karaf.client.ClientConfig determines username + password by
> parsing the etc\users.properties and using the first user + pw.
> When I set "encryption.enabled = false" in org.apache.karaf.jaas.cfg, my
> users.properties looks like this:
> {code}
> karafuser = anypw,admin
> {code}
> it works and the shell opens.
> When I set "encryption.enabled = true" in org.apache.karaf.jaas.cfg, my
> users.properties looks like this:
> {code}
> karafuser =
> {CRYPT}8FEF7493AC1C5A5EC2D1C051576DEF6B32E1D834302DC46C396F325C82214DF3{CRYPT},admin
> {code}
> I get the following LogEntry and it prompts for password
> 1094 [sshd-SshClient[1afa04c]-nio2-thread-4] TRACE
> org.apache.sshd.client.session.ClientSessionImpl -
> doHandleMessage(ClientSessionImpl[karafuser@localhost/127.0.0.1:8101])
> process SSH_MSG_USERAUTH_FAILURE
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (KARAF-5051) Command "shell wrapper:install" fails
[
https://issues.apache.org/jira/browse/KARAF-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated KARAF-5051:
Fix Version/s: 4.2.0
> Command "shell wrapper:install" fails
> -
>
> Key: KARAF-5051
> URL: https://issues.apache.org/jira/browse/KARAF-5051
> Project: Karaf
> Issue Type: Bug
> Components: karaf-shell
>Affects Versions: 4.1.1
>Reporter: Jens Offenbach
>Assignee: Jean-Baptiste Onofré
> Labels: jline, karaf-shell
> Fix For: 4.2.0, 4.1.2
>
>
> I am currently using {{apache-karaf-4.1.1-20170320.164246-38.tar.gz}} on
> Ubuntu 16.04 LTS and the following command fails:
> {code}
> $ shell wrapper:install --start-type DEMAND_START
> [org.apache.karaf.shell.support.ShellUtil] : Command exception (Undefined
> option, ...)
> org.apache.karaf.shell.support.CommandException: Too many arguments specified
> at
> org.apache.karaf.shell.impl.action.command.DefaultActionPreparator.prepare(DefaultActionPreparator.java:160)
> at
> org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:83)
> at
> org.apache.karaf.shell.impl.console.CommandWrapper.execute(CommandWrapper.java:53)
> at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:560)
> at
> org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:486)
> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:375)
> at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:417)
> at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229)
> at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> Error executing command wrapper:install: too many arguments specified
> {code}
> May someone please have a look.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (KARAF-4255) karaf-maven-plugin does include unused feature conditional dependencies in assembly
[
https://issues.apache.org/jira/browse/KARAF-4255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated KARAF-4255:
Fix Version/s: (was: 4.1.2)
4.1.3
> karaf-maven-plugin does include unused feature conditional dependencies in
> assembly
> ---
>
> Key: KARAF-4255
> URL: https://issues.apache.org/jira/browse/KARAF-4255
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.0.3
>Reporter: Fabian Lange
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.0.10, 4.1.3
>
>
> I am using karaf-maven-plugin to make a custom assembly.
> I do include SCR, but I do not include webconsole.
> When I look into the system folder of my generated assembly, I can see:
> {code}
> target/assembly/system/org/apache/felix/org.apache.felix.webconsole.plugins.ds/2.0.2/org.apache.felix.webconsole.plugins.ds-2.0.2.jar
> {code}
> this correlates to the maven output:
> {code}
> [INFO] Feature scr is defined as a boot feature
> [INFO] == Installing artifact
> mvn:org.apache.karaf.scr/org.apache.karaf.scr.command/4.0.3
> [INFO] == Installing artifact mvn:org.apache.felix/org.apache.felix.scr/2.0.2
> [INFO] == Installing artifact
> mvn:org.apache.felix/org.apache.felix.scr.compat/1.0.2
> [INFO] == Installing artifact
> mvn:org.apache.felix/org.apache.felix.webconsole.plugins.ds/2.0.2
> [INFO] == Installing artifact
> mvn:org.apache.felix/org.apache.felix.metatype/1.1.2
> [INFO] == Installing artifact
> mvn:org.apache.karaf.scr/org.apache.karaf.scr.management/4.0.3
> {code}
> however looking at:
> https://github.com/apache/karaf/blob/master/assemblies/features/standard/src/main/feature/feature.xml#L524
> you can see that this is an conditional dependency only.
> This is caused by the fact that assembly does not check if the conditional
> had been met:
> https://github.com/apache/karaf/blob/master/profile/src/main/java/org/apache/karaf/profile/assembly/Builder.java#L822
> I believe we need a check for the conditionals wether the condition is
> actually met.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
