We Keep Coding

Apache James Spring distribution not starting

Trying out the Apache James mail server at the moment. After I downloaded the current binary distribution 3.4.0 ("for Spring wiring"), I got the following behaviour when I ran:
bin\james.bat
Log (formatted for readability):
wrapper | --> Wrapper Started as Console
wrapper | Launching a JVM...
jvm 1 | Wrapper (Version 3.2.3) http://wrapper.tanukisoftware.org
jvm 1 | Copyright 1999-2006 Tanuki Software, Inc. All Rights Reserved.
(...)
jvm 1 | ERROR 21:30:39,649 |
org.apache.james.mailetcontainer.lib.AbstractStateMailetProcessor
Unable to init mailet WithPriority
jvm 1 | org.apache.mailet.MailetException:
Could not load mailet (WithPriority) (java.lang.IllegalArgumentException:
'priority' init parameter is compulsory)
(...)
What's up?

Nevermind, I found the answer - try this:
I will raise the issue up to the project meanwhile a quick fix to make that mailet
work:
in the James app folder, open the file conf/mailetcontainer.xml
find the mailet with class WithPriority
replace the xml tag <value>8</value> by <priority>8</priority>
try to run james server again
Looks like this in conf/mailetcontainer.xml:
(...)
<mailetcontainer enableJmx="true">
<processors>
<processor state="root" enableJmx="true">
<mailet match="All" class="PostmasterAlias"/>
<mailet match="RelayLimit=30" class="Null"/>
<mailet matcher="All" class="WithPriority">
<priority>8</priority>
</mailet>
(...)

Channel closed when running simple example with TLS

I'm trying to run the official "Hello, World" example with TLS, provided by the gRPC team (code on GitHub).
I've cloned the official repo and checked out tag v1.15.0.
I've run the installation script as follows (as shown in the documentation):
./gradlew installDist
I've edited the launch scripts for hello-world-server and hello-world-client to run the classes io.grpc.examples.helloworldtls.HelloWorldServerTls and io.grpc.examples.helloworldtls.HelloWorldClientTls respectively.
I've created the certificates needed for the TLS authentication to happen using the script provided as part of the documentation and stored them in a directory I named cert.
Finally, I've run the server as follows:
./build/install/examples/bin/hello-world-server localhost 50440 cert/server.crt cert/server.pem
The server starts correctly and outputs the following:
Oct 08, 2018 9:15:10 AM io.grpc.examples.helloworldtls.HelloWorldServerTls start
INFO: Server started, listening on 50440
Finally, I try to start the client on another shell with the following command:
./build/install/examples/bin/hello-world-client localhost 50440 cert/ca.crt
Unfortunately, the client fails with the following output:
Oct 08, 2018 9:25:22 AM io.grpc.examples.helloworldtls.HelloWorldClientTls greet
INFO: Will try to greet localhost ...
Oct 08, 2018 9:25:22 AM io.grpc.examples.helloworldtls.HelloWorldClientTls greet
WARNING: RPC failed: Status{code=UNKNOWN, description=channel closed, cause=java.nio.channels.ClosedChannelException
at io.grpc.netty.Utils.statusFromThrowable(Utils.java:169)
at io.grpc.netty.NettyClientTransport$5.operationComplete(NettyClientTransport.java:260)
at io.grpc.netty.NettyClientTransport$5.operationComplete(NettyClientTransport.java:254)
at io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:511)
at io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:485)
at io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:424)
at io.netty.util.concurrent.DefaultPromise.setFailure(DefaultPromise.java:112)
at io.netty.channel.DefaultChannelPromise.setFailure(DefaultChannelPromise.java:89)
at io.grpc.netty.ProtocolNegotiators$AbstractBufferingHandler.fail(ProtocolNegotiators.java:564)
at io.grpc.netty.ProtocolNegotiators$BufferUntilTlsNegotiatedHandler.userEventTriggered(ProtocolNegotiators.java:661)
at io.netty.channel.AbstractChannelHandlerContext.invokeUserEventTriggered(AbstractChannelHandlerContext.java:329)
at io.netty.channel.AbstractChannelHandlerContext.invokeUserEventTriggered(AbstractChannelHandlerContext.java:315)
at io.netty.channel.AbstractChannelHandlerContext.fireUserEventTriggered(AbstractChannelHandlerContext.java:307)
at io.netty.handler.ssl.SslUtils.handleHandshakeFailure(SslUtils.java:318)
at io.netty.handler.ssl.SslHandler.setHandshakeFailure(SslHandler.java:1551)
at io.netty.handler.ssl.SslHandler.channelInactive(SslHandler.java:1023)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:245)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:231)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:224)
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelInactive(DefaultChannelPipeline.java:1429)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:245)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:231)
at io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:947)
at io.netty.channel.AbstractChannel$AbstractUnsafe$8.run(AbstractChannel.java:822)
at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163)
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:404)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:464)
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:884)
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: java.nio.channels.ClosedChannelException
at io.netty.handler.ssl.SslHandler.channelInactive(...)(Unknown Source)
}
The error occurs with mutual authentication as well.
I'm not sure what's going wrong or how to find the root cause of this, do you have any pointers?

As it turns out, I was using incompatible versions of gRPC and BoringSSL.
The "Troubleshooting" section of this document contains a table with known compatible versions of the library.
The following is a table with known compatible versions as of October 2018:
grpc-netty version | netty-handler version | netty-tcnative-boringssl-static version
------------------ | --------------------- | ---------------------------------------
1.0.0-1.0.1 | 4.1.3.Final | 1.1.33.Fork19
1.0.2-1.0.3 | 4.1.6.Final | 1.1.33.Fork23
1.1.x-1.3.x | 4.1.8.Final | 1.1.33.Fork26
1.4.x | 4.1.11.Final | 2.0.1.Final
1.5.x | 4.1.12.Final | 2.0.5.Final
1.6.x | 4.1.14.Final | 2.0.5.Final
1.7.x-1.8.x | 4.1.16.Final | 2.0.6.Final
1.9.x-1.10.x | 4.1.17.Final | 2.0.7.Final
1.11.x-1.12.x | 4.1.22.Final | 2.0.7.Final
1.13.x | 4.1.25.Final | 2.0.8.Final
1.14.x- | 4.1.27.Final | 2.0.12.Final

Fitnesse: Slim server fails to start; using Eclipse

I'm trying to get a very basic Fitnesse test to run; using Fitnesse / Slim; Java in Eclipse.
Test runs, or at least starts, but doesn't finish; get this error:
Unable to start test system 'slim': fitnesse.slim.SlimError: Error SLiM server died before a connection could be established. JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [debugInit.c:750]
Fitnesse test is:
!define TEST_SYSTEM {slim}
!path: C:\Users\<my folder>\EclipseWorkspace\CalculatorProject
| import | packageCalculator |
| TestCalculator |
| operand | result? |
| 4 | 8 |
| 2 | 4 |
| 7 | 14 |
| 2 | 4 |
This is a similar issue: Fitnesse: SLiM server died before a connection could be established; suggests this might be a regression bug; but I tried earlier versions of fitnesse, which made no difference
And it's not this one either: https://github.com/unclebob/fitnesse/issues/726; there is no space in the classpath
Help!!!

Fuse ESB mysteriously hangs - "JVM appears hung: Timed out waiting for signal from JVM."

My Fuse ESB application suddenly stopped, with no clues in fuseesb.log and the following weird log items in wrapper.log:
ERROR | wrapper | 2014/02/12 02:36:59 | JVM appears hung: Timed out waiting for signal from JVM.
ERROR | wrapper | 2014/02/12 02:36:59 | JVM did not exit on request, terminated
STATUS | wrapper | 2014/02/12 02:37:02 | JVM exited in response to signal SIGKILL (9).
ERROR | wrapper | 2014/02/12 02:37:02 | Unable to start a JVM
STATUS | wrapper | 2014/02/12 02:37:02 | <-- Wrapper Stopped
We are using Nagios to monitor the system.
System info: FuseESBEnterprise-7.1.0 / linux-gnu (x86_64).
For various reasons we need to sick with Fuse ESB (not possible to migrate to JBoss Fuse...)

This was a system issue - the vm hung.
You can catch this kind of condition in one of two ways:
monitor the java jvm process
monitor the wrapper.log file for errors

java service wrapper, very basic step by step setup with startup failure

I have simply donwloaded JSW community edition, unwrapped into a directory:
c:\servicetest
So here i have a bin, conf, lib and log subdirs, among others.
From now on this will be (root).
I referenced the (root)/lib/wrapper.jar into my ide (netbeans) and create a very simple service (remember the class name is Main):
public class Main extends WrapperSimpleApp {
public Main(String[] args) {
super(args);
}
#Override
public void run() {
while(true) {
Logger.getLogger(Main.class.getName()).log(Level.INFO, "I'm alive");
try
{ Thread.sleep(2000); }
catch (InterruptedException ex)
{ return; }
}
}
}
As you see, it basically does nothing but logging a message. But actually it neither starts.
I compiled the project (MyProject.jar), copied the jar into the (root) directory and modified the (root)/config/wrapper.conf adding:
wrapper.java.classpath.3=../MyProject.jar
and
wrapper.java.mainclass=textappender.Main
Then i've installed the service in command line, with:
C:\servicetest\bin>wrapper -i ../conf/wrapper.conf
then i've started the service, either via services.msc control panel or via
C:\servicetest\bin>wrapper -t ../conf/wrapper.conf
In logs/wrapper.log i get:
ERROR | wrapper | 2012/05/21 21:35:11 | JVM exited while loading the application.
UPDATE 1
Following Tanuki Software advice, i've set in my (root)/config/wrapper.conf (well, uncommented since it already was):
wrapper.debug=TRUE
And now i get this:
INFO | jvm 1 | 2012/05/22 10:46:37 | WrapperManager Debug: WrapperManager.stop(1) called by thread: main
INFO | jvm 1 | 2012/05/22 10:46:37 | WrapperManager Debug: Backend not connected, not sending packet STOP : 1
INFO | jvm 1 | 2012/05/22 10:46:37 | WrapperManager Debug: Stopped checking for control events.
DEBUG | wrapper | 2012/05/22 10:46:37 | Pause reading child process output to share cycles.
INFO | jvm 1 | 2012/05/22 10:46:37 | WrapperManager Debug: Thread, main, handling the shutdown process.
INFO | jvm 1 | 2012/05/22 10:46:37 | WrapperManager Debug: shutdownJVM(1) Thread: main
INFO | jvm 1 | 2012/05/22 10:46:38 | WrapperManager Debug: wait for 0 shutdown locks to be released.
INFO | jvm 1 | 2012/05/22 10:46:38 | WrapperManager Debug: Backend not connected, not sending packet STOPPED : 1
INFO | jvm 1 | 2012/05/22 10:46:38 | WrapperManager Debug: calling System.exit(1)
DEBUG | wrapper | 2012/05/22 10:46:38 | JVM process exited with a code of 1, setting the wrapper exit code to 1.
But given my very simple implementation, i cannot guess what is going wrong.

rather than extending WrapperSimpleApp, your main class should implement the org.tanukisoftware.wrapper.WrapperListener interface.
You can find a very detailed description about implementing the interface on our website:
http://wrapper.tanukisoftware.com/doc/english/integrate-listener.html
Please let me know if you have any further questions about the implementation and/or the configuration properties in your conf file.
Another advise which comes in handy for me sometimes, is rather than running your application immediately as service, I find it easier to do the integration by running first as console application, because you can see the output directly on your console. Once everything seems working, I go ahead and install/run as service.
To run as console application, you would run for example:
C:\servicetest\bin>wrapper -c ../conf/wrapper.conf
You can also turn on debug output for the Wrapper by setting
wrapper.debug=true
in your conf file.
Edit due to the comment:
if your application is actually as simple as you describe, then just write your application as normal Java application without any Wrapper API parts.
You can use the WrapperSimpleApp to run your application out of the box with codeless integration into the Wrapper.
All you need to do is set the following properties in your conf file:
wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
wrapper.app.parameter.1=textappender.Main
wrapper.java.classpath.1=../lib/wrapper.jar
wrapper.java.classpath.2=../MyProject.jar
With this configuration, the Wrapper will be able to run your application as windows service.
UPDATE2
I'm not sure what your code exactly looks like, but it seems you are calling WrapperManager.stop() in your main class...
Following the initial example class, I have modified the class, so it is not using any Wrapper-API (which for an simple application is not necessary):
public class Main {
public static void main(String[] args) {
while(true) {
Logger.getLogger(Main.class.getName()).log(Level.INFO, "I'm alive");
try
{ Thread.sleep(2000); }
catch (java.lang.InterruptedException ex)
{ return; }
}
}
}
After compile and creating the jar, the necessary properties in the conf file are:
wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
wrapper.app.parameter.1=textappender.Main
wrapper.java.classpath.1=../lib/wrapper.jar
wrapper.java.classpath.2=../MyProject.jar
cheers,