[jira] [Commented] (KARAF-816) Wrapper feature doesn't load security libraries

["Daniel Evans (JIRA)" <ji...@apache.org>]

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

Daniel Evans commented on KARAF-816:
------------------------------------

This is a problem with JAVA_HOME not being present. The wrapper scripts/objects aren't as forgiving as bin/karaf when they can't find JAVA_HOME. The service start issues the the java command with the string %JAVA_HOME% unsubstituted, i.e.:

-Djava.endorsed.dirs="%JAVA_HOME%/jre/lib/endorsed:

Unless I'm mistaken this is windows batch file syntax, but I assume it was never intended to be exposed (substitution was to occur internally). Failing hard when JAVA_HOME isn't present would probably be preferable, working the same magic as bin/karaf is another solution.

Best workaround I can see at the moment is just to include "export JAVA_HOME=/usr/lib/jvm/java-6-openjdk/jre" at the top of the service script (put in your own JDK path). I'm not a linux expert so I'm not actually sure how to provide JAVA_HOME to init.d scripts on startup. 

> Wrapper feature doesn't load security libraries
> -----------------------------------------------
>
>                 Key: KARAF-816
>                 URL: https://issues.apache.org/jira/browse/KARAF-816
>             Project: Karaf
>          Issue Type: Bug
>          Components: karaf-os-integration
>    Affects Versions: 2.2.2
>         Environment: Ubunutu 10.04 LTS
> OpenJDK, HotSpot
>            Reporter: Sam Hendley
>
> Using the wrapper feature to create an init.d script on ubunutu with either Java version appears to be broken in the current karaf distribution. When we try to use the generated script karaf starts correctly but none of the security packages are loaded. This manifests in a number of ways when trying to use any SSL. The easiest manifestation of this bug is that the SSH server doesn't have access to any ciphers for login. I see the following error in the log.
> AbstractSession  253 | 16 - sshd-core - 0.5.0 | Exception caught
> java.lang.IllegalStateException: Unable to negociate key exchange for item 2
>         at org.apache.sshd.common.session.AbstractSession.negociate(AbstractSession.java:886)
>         at org.apache.sshd.server.session.ServerSession.handleMessage(ServerSession.java:151)
>         at org.apache.sshd.common.session.AbstractSession.decode(AbstractSession.java:522)
>         at org.apache.sshd.common.session.AbstractSession.messageReceived(AbstractSession.java:225)
> This (misspelled) function appears to be catching and suppressing the root cause exception which is a lack of the cipher suites, I get the full set of errors when running trying to connect to an AMQP broker using SSL. The cause of these errors is that the cipher suites are not on the classpath. The libraries in question are in JAVA_HOME/jre/ext/lib, which both the regular ./bin/karaf scripts and the wrapper code appear to be configured to put on the classpath. However there must be some misconfiguration or expected system variable for the wrapper generation or script because it doesn't work.
> The simplest reproduction case I can come up with is:
> - download and untar karaf 2.2.2
> - start with ./bin/karaf
>   - features:install wrapper
>   - wrapper:install -s AUTO_START -n Test
>   - logout
> - start with ./bin/start
> - verify we can connect with ./bin/client
> - stop server with ./bin/stop
> - now try using wrapper script (still in same shell with same user): ./bin/Test-service start
> - try connecting using ./bin/client, should see "error to negotatie errors on both sides"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira