I have this huge legacy code that is built upon Java and C that uses JNI calls etc. It is working fine with JRE 7. I am getting following exception while running on JRE 8.
#INVENTORYTUNER: Finished setting trusted transmitters, added: vw-pun-mar-dv07
#java.lang.NoClassDefFoundError: sun/io/CharToByteConverter
# at com.marimba.tools.util.ByteBuffer.setEncoding(ByteBuffer.java:109)
# at com.marimba.tools.util.ByteBuffer.<init>(ByteBuffer.java:97)
# at com.marimba.tools.logs.LogEntry.<init>(LogEntry.java:21)
# at com.marimba.tools.logs.GenericLog.logData(GenericLog.java:91)
# at com.marimba.tools.logs.GenericLog.log(GenericLog.java:84)
# at com.marimba.tools.logs.LogDispatcher.log(LogDispatcher.java:267)
# at com.marimba.castanet.tuner.Workspace.log(Workspace.java:1112)
# at com.marimba.castanet.tuner.Workspace.log(Workspace.java:1031)
# at com.marimba.castanet.tuner.Workspace.log(Workspace.java:1024)
# at com.marimba.castanet.tuner.Channel.<init>(Channel.java:180)
# at com.marimba.castanet.tuner.Workspace.getChannelCreate(Workspace.java:701)
# at com.marimba.castanet.tuner.Workspace.getChannelCreate(Workspace.java:684)
# at com.marimba.castanet.launch.Launcher$Create.run(Launcher.java:399)
# at com.marimba.tools.util.ThreadPool.runClient(ThreadPool.java:374)
# at com.marimba.tools.util.ThreadPool.run(ThreadPool.java:360)
# at java.lang.Thread.run(Unknown Source)
Internally, we are using this zip to support deprecated methods. How to proceed this ?
Is marbima something you are using as a third party lib or something that you are working on?
As folks in the comments mentioned the CharToByteConverter has been replaced by java.nio.charset
See Java Class chartobyteconverter Type deprecated
If you are using marbima as a third party lib, contact the devs to see if it is certified for JDK 1.8, if you develop it, you need to modify it to remove the deprecated classes.
Related
I'm try to run 2 Spring Boot applications within the same Pod (essentially one is a reverse proxy for the other one - a small implementation of the sidecar pattern) and I've that one of the containers can't start. In fact, it crashes with the following error:
Starting the Java application using /opt/jboss/container/java/run/run-java.sh ...
INFO exec java -javaagent:/usr/share/java/jolokia-jvm-agent/jolokia-jvm.jar=config=/opt/jboss/container/jolokia/etc/jolokia.properties -javaagent:/usr/share/java/prometheus-jmx-exporter/jmx_prometheus_javaagent.jar=9779:/opt/jboss/container/prometheus/etc/jmx-exporter-config.yaml -XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=20 -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -XX:+ExitOnOutOfMemoryError -cp "." -jar /deployments/app-backend-1.0.0-SNAPSHOT.jar
Could not start Jolokia agent: java.lang.IllegalStateException: Cannot open keystore for https communication: java.net.BindException: Address already in use
Exception in thread "main" java.lang.reflect.InvocationTargetException
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:491)
at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:503)
Caused by: java.net.BindException: Address already in use
at java.base/sun.nio.ch.Net.bind0(Native Method)
at java.base/sun.nio.ch.Net.bind(Net.java:555)
at java.base/sun.nio.ch.ServerSocketChannelImpl.netBind(ServerSocketChannelImpl.java:337)
at java.base/sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:294)
at java.base/sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:89)
at jdk.httpserver/sun.net.httpserver.ServerImpl.bind(ServerImpl.java:134)
at jdk.httpserver/sun.net.httpserver.HttpServerImpl.bind(HttpServerImpl.java:54)
at io.prometheus.jmx.shaded.io.prometheus.client.exporter.HTTPServer.<init>(HTTPServer.java:145)
at io.prometheus.jmx.JavaAgent.premain(JavaAgent.java:31)
... 6 more
FATAL ERROR in native method: processing of -javaagent failed, processJavaStart failed
*** java.lang.instrument ASSERTION FAILED ***: "result" with message agent load/premain call failed at src/java.instrument/share/native/libinstrument/JPLISAgent.c line: 422
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f3cf9ef7e91, pid=1, tid=154
#
# JRE version: OpenJDK Runtime Environment 21.9 (17.0.1+12) (build 17.0.1+12-LTS)
# Java VM: OpenJDK 64-Bit Server VM 21.9 (17.0.1+12-LTS, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, serial gc, linux-amd64)
# Problematic frame:
# C [libc.so.6+0x21e91] abort+0x203
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /deployments/hs_err_pid1.log
#
# If you would like to submit a bug report, please visit:
# https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%208&component=java-17-openjdk
#
I've the impression the issue is caused by the way the plugin I'm using builds the final image, but I'm not sure.
I suspect that both the containers use the same port (since the images are built in the same way) for the Jolokia and Prometheus JMX agents, but I didn't find a way to disable them.
Does somebody have some ideas?
when running 2 containers in one pod, the containers recognize the pod as their localhost environment. as a result, if both containers try to bind the same port, they will interfere each other.
try to configure one of the containers to bind another port. this should resolve the error above. :)
edit: I checked the provided link to the github issue you opened for the plugin. jkube and spring boot docs both list several different ways to provide build- and runtime configs. I don't think this is a bug but a configuration issue that can be solved with the options the framework and plugin provides.
I propose you dig the docs further to check how to configure the ports for the processes that are started in both containers via springs application properties, ENVs or something like that. Afterwards, you can check how to provide these values during build/runtime using jkube generated manifests.
docs I've found:
https://www.eclipse.org/jkube/docs/kubernetes-maven-plugin#_configuration
https://docs.spring.io/spring-boot/docs/2.1.1.RELEASE/reference/html/production-ready-jmx.html
https://blog.kubernauts.io/https-blog-kubernauts-io-monitoring-java-spring-boot-applications-with-prometheus-part-2-b883063486b5
In the end it was effectively a bug in JKube. See https://github.com/eclipse/jkube/issues/1294#event-6132755248
If I run JNAerator using the header for my library, the process gobbles processor time and never seems to finish - after first issuing warnings:
adrian$ java -Xmx128m -jar ~/JNAerator/jnaerator/target/jnaerator-0.13-SNAPSHOT-shaded.jar /Users/adrian/DRAMSim2/DRAMSim.h -mode StandaloneJar
Warning: no -library option for file 'DRAMSim.h', using "DRAMSim".
Auto-configuring parser...
Parsing native headers...
/usr/include/sys/cdefs.h:74:25: warning: #warning "Unsupported compiler detected"
/usr/include/_types/_wctype_t.h:30:19: warning: No newline before end of file
So, I have also tried the -ScanSymbols option:
java -Xmx128m -jar ~/JNAerator/jnaerator/target/jnaerator-0.13-SNAPSHOT-shaded.jar -scanSymbols -mode StandaloneJar
Auto-configuring parser...
Parsing native headers...
Normalizing parsed code...
Generating libraries...
Compiling JNAerated files...
[....]
Copying runtime classes...
Generating out.jar
#
# SUCCESS: JNAeration completed !
# Output mode is 'StandaloneJar(JAR with bindings and runtime dependencies)
#
# => '/Users/adrian/groovy/simul/src/simul/./out.jar'
And out.jar has a great many .class files but no .java and I have no idea how to use it.
Using -noComp -noJar as suggested in the wiki generates no output at all ...
adrian$ java -Xmx128m -jar ~/JNAerator/jnaerator/target/jnaerator-0.13-SNAPSHOT-shaded.jar -scanSymbols -noComp -noJar
WARNING: option (?i)-noComp is deprecated and might be removed in future versions.
WARNING: option (?i)-noJar is deprecated and might be removed in future versions.
WARNING: legacy options (?i)-noJar and (?i)-noComp used, defaulting -mode to Directory
Auto-configuring parser...
Parsing native headers...
Normalizing parsed code...
Generating libraries...
#
# SUCCESS: JNAeration completed !
# Output mode is 'Directory(Bindings sources in simple file hierarchy)
#
# => '/Users/adrian/groovy/simul/src/simul/.'
What am I doing wrong? Or is this a hopeless case?
I am trying to implement the example given here: http://benjsicam.me/blog/running-a-java-application-as-a-windows-service-part-1-tutorial/
The code basically turns a Java application into a service. The application outputs Date and Time to the console at specific intervals. The whole project gets exported to a runnable JAR file, with required libraries in a separate folder. All I have to do is modify the wrapper.conf file to run Main.jar (which is the exported JAR) and put the exported libraries in the lib folder.
I have followed everything exactly, but I am getting the following problem: WrapperManager cannot be resolved. I am including the links for snapshots which show the Maven project structure, the contents of POM.xml, and code contents of four Java files. Also included are the required source files in Google Drive.
Java version jdk1.8.0_11
Main.java
Google Drive Link
Error Shown:
Wrapper.conf file (removed most of the comments+top part)
wrapper.java.mainclass=batch_Proc.main_prog.Main
# Java Classpath (include wrapper.jar) Add class path elements as
# needed starting from 1
wrapper.java.classpath.1=../lib/wrapper.jar
wrapper.java.classpath.2=../lib/aopalliance-1.0.jar
wrapper.java.classpath.3=../lib/commons-logging-1.1.1.jar
wrapper.java.classpath.4=../lib/spring-aop-3.2.1.RELEASE.jar
wrapper.java.classpath.5=../lib/spring-beans-3.2.1.RELEASE.jar
wrapper.java.classpath.6=../lib/spring-context-3.2.1.RELEASE.jar
wrapper.java.classpath.7=../lib/spring-context-support-3.2.1.RELEASE.jar
wrapper.java.classpath.8=../lib/spring-core-3.2.1.RELEASE.jar
wrapper.java.classpath.9=../lib/spring-expression-3.2.1.RELEASE.jar
wrapper.java.classpath.10=../lib/spring-web-3.2.1.RELEASE.jar
wrapper.java.classpath.11=../lib/wrappertest.jar
wrapper.java.classpath.12=Main.jar
# Java Library Path (location of Wrapper.DLL or libwrapper.so)
wrapper.java.library.path.1=../lib
# Java Bits. On applicable platforms, tells the JVM to run in 32 or 64-bit mode.
wrapper.java.additional.auto_bits=FALSE
# Java Additional Parameters
wrapper.java.additional.1=
# Initial Java Heap Size (in MB)
#wrapper.java.initmemory=3
# Maximum Java Heap Size (in MB)
#wrapper.java.maxmemory=64
# Application parameters. Add parameters as needed starting from 1
#wrapper.app.parameter.1=
#********************************************************************
# Wrapper Logging Properties
#********************************************************************
# Enables Debug output from the Wrapper.
wrapper.debug=FALSE
# Format of output for the console. (See docs for formats)
wrapper.console.format=PM
# Log Level for console output. (See docs for log levels)
wrapper.console.loglevel=INFO
# Log file to use for wrapper output logging.
wrapper.logfile=../logs/wrapper.log
# Format of output for the log file. (See docs for formats)
wrapper.logfile.format=LPTM
# Log Level for log file output. (See docs for log levels)
wrapper.logfile.loglevel=INFO
# Maximum size that the log file will be allowed to grow to before
# the log is rolled. Size is specified in bytes. The default value
# of 0, disables log rolling. May abbreviate with the 'k' (kb) or
# 'm' (mb) suffix. For example: 10m = 10 megabytes.
wrapper.logfile.maxsize=0
# Maximum number of rolled log files which will be allowed before old
# files are deleted. The default value of 0 implies no limit.
wrapper.logfile.maxfiles=0
# Log Level for sys/event log output. (See docs for log levels)
wrapper.syslog.loglevel=NONE
#********************************************************************
# Wrapper General Properties
#********************************************************************
# Allow for the use of non-contiguous numbered properties
wrapper.ignore_sequence_gaps=TRUE
# Do not start if the pid file already exists.
wrapper.pidfile.strict=TRUE
# Title to use when running as a console
wrapper.console.title=Test Wrapper Sample Application
#********************************************************************
# Wrapper JVM Checks
#********************************************************************
# Detect DeadLocked Threads in the JVM. (Requires Standard Edition)
wrapper.check.deadlock=TRUE
wrapper.check.deadlock.interval=10
wrapper.check.deadlock.action=RESTART
wrapper.check.deadlock.output=FULL
# Out Of Memory detection.
# (Ignore output from dumping the configuration to the console. This is only needed by the TestWrapper sample application.)
wrapper.filter.trigger.999=wrapper.filter.trigger.*java.lang.OutOfMemoryError
wrapper.filter.allow_wildcards.999=TRUE
wrapper.filter.action.999=NONE
# Ignore -verbose:class output to avoid false positives.
wrapper.filter.trigger.1000=[Loaded java.lang.OutOfMemoryError
wrapper.filter.action.1000=NONE
# (Simple match)
wrapper.filter.trigger.1001=java.lang.OutOfMemoryError
# (Only match text in stack traces if -XX:+PrintClassHistogram is being used.)
#wrapper.filter.trigger.1001=Exception in thread "*" java.lang.OutOfMemoryError
#wrapper.filter.allow_wildcards.1001=TRUE
wrapper.filter.action.1001=RESTART
wrapper.filter.message.1001=The JVM has run out of memory.
#********************************************************************
# Wrapper Email Notifications. (Requires Professional Edition)
#********************************************************************
# Common Event Email settings.
#wrapper.event.default.email.debug=TRUE
#wrapper.event.default.email.smtp.host=<SMTP_Host>
#wrapper.event.default.email.smtp.port=25
#wrapper.event.default.email.subject=[%WRAPPER_HOSTNAME%:%WRAPPER_NAME%:%WRAPPER_EVENT_NAME%] Event Notification
#wrapper.event.default.email.sender=<Sender email>
#wrapper.event.default.email.recipient=<Recipient email>
# Configure the log attached to event emails.
#wrapper.event.default.email.attach_log=TRUE
#wrapper.event.default.email.maillog.lines=50
#wrapper.event.default.email.maillog.format=LPTM
#wrapper.event.default.email.maillog.loglevel=INFO
# Enable specific event emails.
#wrapper.event.wrapper_start.email=TRUE
#wrapper.event.jvm_prelaunch.email=TRUE
#wrapper.event.jvm_start.email=TRUE
#wrapper.event.jvm_started.email=TRUE
#wrapper.event.jvm_deadlock.email=TRUE
#wrapper.event.jvm_stop.email=TRUE
#wrapper.event.jvm_stopped.email=TRUE
#wrapper.event.jvm_restart.email=TRUE
#wrapper.event.jvm_failed_invocation.email=TRUE
#wrapper.event.jvm_max_failed_invocations.email=TRUE
#wrapper.event.jvm_kill.email=TRUE
#wrapper.event.jvm_killed.email=TRUE
#wrapper.event.jvm_unexpected_exit.email=TRUE
#wrapper.event.wrapper_stop.email=TRUE
# Specify custom mail content
wrapper.event.jvm_restart.email.body=The JVM was restarted.\n\nPlease check on its status.\n
# Name of the service
wrapper.name=JavaWindowsServiceSample
# Display name of the service
wrapper.displayname=Java Windows Service Sample
# Description of the service
wrapper.description=A sample java windows service application
# Service dependencies. Add dependencies as needed starting from 1
wrapper.ntservice.dependency.1=
# Mode in which the service is installed. AUTO_START, DELAY_START or DEMAND_START
wrapper.ntservice.starttype=AUTO_START
# Allow the service to interact with the desktop.
wrapper.ntservice.interactive=false
I solved this problem! I had made a simple mistake of not making sure the correct dependencies were downloaded in Maven.
The required jars for WrapperManager and WrapperListener were not available which were causing the errors.
I'm working on some code to access HBase and I am writing unit tests that create a MiniDFSCluster as part of the test setup.
(defn test-config [& options]
(let [testing-utility (HBaseTestingUtility.)]
(.startMiniCluster testing-utility 1)
(let [config (.getConfiguration testing-utility)]
(if (not= options nil)
(doseq [[key value] options]
(.set config key value)))
config)))
;; For those who don't read Clojure, lines 2 and 3 cause
;; the failure and are equivalent to the following Java
;;
;; HBaseTestingUtility testingUtility = new HBaseTestingUtility();
;; testingUtility.startMiniCluster(1); // blows up on Linux but not Mac OSX
This runs fine on Mac OSX with Java HotSpot:
$ java -version
java version "1.6.0_51"
Java(TM) SE Runtime Environment (build 1.6.0_51-b11-457-11M4509)
Java HotSpot(TM) 64-Bit Server VM (build 20.51-b01-457, mixed mode)
$ lein test
lein test hbase.config-test
lein test hbase.table-test
2013-07-12 17:44:13.488 java[27384:1203] Unable to load realm info from SCDynamicStore
Starting DataNode 0 with dfs.data.dir: /Users/dwilliams/Desktop/Repos/mobiusinversion/hbase/target/test-data/fe0199fd-0168-48d9-98ce-b4a5e62d3257/dfscluster_bbad1095-58d1-4571-ba12-4d4f1c24203f/dfs/data/data1,/Users/dwilliams/Desktop/Repos/mobiusinversion/hbase/target/test-data/fe0199fd-0168-48d9-98ce-b4a5e62d3257/dfscluster_bbad1095-58d1-4571-ba12-4d4f1c24203f/dfs/data/data2
Cluster is active
Ran 11 tests containing 14 assertions.
0 failures, 0 errors.
But when this is run in a Linux environment, the following error occurs:
ERROR in (create-table) (MiniDFSCluster.java:426)
Uncaught exception, not in assertion.
expected: nil
actual: java.lang.NullPointerException: null
at org.apache.hadoop.hdfs.MiniDFSCluster.startDataNodes (MiniDFSCluster.java:426)
org.apache.hadoop.hdfs.MiniDFSCluster.<init> (MiniDFSCluster.java:284)
org.apache.hadoop.hbase.HBaseTestingUtility.startMiniDFSCluster (HBaseTestingUtility.java:444)
org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster (HBaseTestingUtility.java:612)
org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster (HBaseTestingUtility.java:568)
org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster (HBaseTestingUtility.java:555)
I filed a travis-ci ticket, since this first manifested itself there and I thought it might be due to their environment.
https://github.com/travis-ci/travis-ci/issues/1240
However, after discussion with travis support I was able to reproduce the error on CentOS. I tried both the Sun JDK and the OpenJDK on Linux and both produced the same error. Whats going on here? Is this a trivial configuration problem? Perhaps something not set in the Linux ENV that is set in Mac OSX's ENV?
If you would like to run the tests, please clone the repo
https://github.com/mobiusinversion/hbase
And run lein test. Help is greatly appreciated!
Update:
Filed this HBASE Jira ticket
https://issues.apache.org/jira/browse/HBASE-8944
Short answer: set "umask 022" prior to running the tests.
Long answer: This is a common environmental issue with running MiniDFSCluster from Hadoop 1.x, releases, which HBaseTestingUtility uses internally. It has been effectively fixed in Hadoop 0.22+ (including 2.0+, but not 1.x at the moment).
The underlying problem is https://issues.apache.org/jira/browse/HDFS-2556.
When the MiniDFSCluster starts up, it creates the temporary storage directories to use for the datanode processes (configured as "dfs.data.dir"). These will be created with your currently set umask. When each datanode starts up, it checks that the directories configured in "dfs.data.dir" both exist and that the directory permissions match the expected value (set as "dfs.datanode.data.dir.perm"). If the directories permissions do not match the expected value ("755" by default), then the datanode process exits.
By default, in Hadoop 1.x, this value is set to "755", so if you set your umask to "022", the data directories will wind up with the correct permissions. If however, the permissions do not match the expected value, the datanode will abort and you will see errors like the following in the test log file:
WARN [main] datanode.DataNode(1577): Invalid directory in dfs.data.dir: Incorrect permission for /.../dfs/data/data2, expected: rwxr-xr-x, while actual: rwxrwxr-x
In later versions of Hadoop, the datanode will attempt to change the directory permissions to the expected value if they do not match. Only if this operation fails will the datanode abort. HDFS-2556 proposes backporting this change to the 1.x releases, but has not yet been fixed.
WrapperAppJar
I am wrapping an executable runnable jar file as a window service. Based upon the tutorial on Tanuki software site I export my app from eclipse as an executable jar file and tried wrappig it into a windows service. My app runs smoothly from the CLI when I execute java -jar smpp-portal -port 90. However with the Wrapper service I am getting some errors.
This is my configuration file
#encoding=UTF-8
# Configuration files must begin with a line specifying the encoding
# of the the file.
#********************************************************************
# Wrapper License Properties (Ignored by Community Edition)
#********************************************************************
# Professional and Standard Editions of the Wrapper require a valid
# License Key to start. Licenses can be purchased or a trial license
# requested on the following pages:
# http://wrapper.tanukisoftware.com/purchase
# http://wrapper.tanukisoftware.com/trial
# Include file problems can be debugged by removing the first '#'
# from the following line:
##include.debug
# The Wrapper will look for either of the following optional files for a
# valid License Key. License Key properties can optionally be included
# directly in this configuration file.
#include ../conf/wrapper-license.conf
#include ../conf/wrapper-license-%WRAPPER_HOST_NAME%.conf
# The following property will output information about which License Key(s)
# are being found, and can aid in resolving any licensing problems.
#wrapper.license.debug=TRUE
#********************************************************************
# Wrapper Localization
#********************************************************************
# Specify the locale which the Wrapper should use. By default the system
# locale is used.
wrapper.lang=en_US # en_US or ja_JP
# Specify the location of the Wrapper's language resources. If these are
# missing, the Wrapper will default to the en_US locale.
#wrapper.lang.folder=../lang
#********************************************************************
# Wrapper Java Properties
#********************************************************************
# Java Application
# Locate the java binary on the system PATH:
wrapper.java.command=java
# Specify a specific java binary:
#set.JAVA_HOME=/java/path
#wrapper.java.command=%JAVA_HOME%/bin/java
# Tell the Wrapper to log the full generated Java command line.
wrapper.java.command.loglevel=INFO
# Java Main class. This class must implement the WrapperListener interface
# or guarantee that the WrapperManager class is initialized. Helper
# classes are provided to do this for you. See the Integration section
# of the documentation for details.
wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperJarApp
# Java Classpath (include wrapper.jar) Add class path elements as
# needed starting from 1
wrapper.java.classpath.1=../lib/wrapper.jar
#wrapper.java.classpath.2=../lib/wrapper.jar
# Java Library Path (location of Wrapper.DLL or libwrapper.so)
wrapper.java.library.path.1=../lib
# Java Bits. On applicable platforms, tells the JVM to run in 32 or 64-bit mode.
wrapper.java.additional.auto_bits=TRUE
# Java Additional Parameters
wrapper.java.additional.1=
# Initial Java Heap Size (in MB)
#wrapper.java.initmemory=3
# Maximum Java Heap Size (in MB)
#wrapper.java.maxmemory=64
# Application parameters. Add parameters as needed starting from 1
wrapper.app.parameter.1=../lib/smpp-portal.jar
wrapper.app.parameter.2=-port
#********************************************************************
# Wrapper Logging Properties
#********************************************************************
# Enables Debug output from the Wrapper.
# wrapper.debug=TRUE
# Format of output for the console. (See docs for formats)
wrapper.console.format=PM
# Log Level for console output. (See docs for log levels)
wrapper.console.loglevel=INFO
# Log file to use for wrapper output logging.
wrapper.logfile=../logs/wrapper.log
# Format of output for the log file. (See docs for formats)
wrapper.logfile.format=LPTM
# Log Level for log file output. (See docs for log levels)
wrapper.logfile.loglevel=INFO
# Maximum size that the log file will be allowed to grow to before
# the log is rolled. Size is specified in bytes. The default value
# of 0, disables log rolling. May abbreviate with the 'k' (kb) or
# 'm' (mb) suffix. For example: 10m = 10 megabytes.
wrapper.logfile.maxsize=0
# Maximum number of rolled log files which will be allowed before old
# files are deleted. The default value of 0 implies no limit.
wrapper.logfile.maxfiles=0
# Log Level for sys/event log output. (See docs for log levels)
wrapper.syslog.loglevel=NONE
#********************************************************************
# Wrapper General Properties
#********************************************************************
# Allow for the use of non-contiguous numbered properties
wrapper.ignore_sequence_gaps=TRUE
# Do not start if the pid file already exists.
wrapper.pidfile.strict=TRUE
# Title to use when running as a console
wrapper.console.title=Unity SMPP Server
#********************************************************************
# Wrapper JVM Checks
#********************************************************************
# Detect DeadLocked Threads in the JVM. (Requires Standard Edition)
wrapper.check.deadlock=TRUE
wrapper.check.deadlock.interval=10
wrapper.check.deadlock.action=RESTART
wrapper.check.deadlock.output=FULL
# Out Of Memory detection.
# (Ignore output from dumping the configuration to the console. This is only needed by the TestWrapper sample application.)
wrapper.filter.trigger.999=wrapper.filter.trigger.*java.lang.OutOfMemoryError
wrapper.filter.allow_wildcards.999=TRUE
wrapper.filter.action.999=NONE
# Ignore -verbose:class output to avoid false positives.
wrapper.filter.trigger.1000=[Loaded java.lang.OutOfMemoryError
wrapper.filter.action.1000=NONE
# (Simple match)
wrapper.filter.trigger.1001=java.lang.OutOfMemoryError
# (Only match text in stack traces if -XX:+PrintClassHistogram is being used.)
#wrapper.filter.trigger.1001=Exception in thread "*" java.lang.OutOfMemoryError
#wrapper.filter.allow_wildcards.1001=TRUE
wrapper.filter.action.1001=RESTART
wrapper.filter.message.1001=The JVM has run out of memory.
#********************************************************************
# Wrapper Email Notifications. (Requires Professional Edition)
#********************************************************************
# Common Event Email settings.
#wrapper.event.default.email.debug=TRUE
#wrapper.event.default.email.smtp.host=<SMTP_Host>
#wrapper.event.default.email.smtp.port=25
#wrapper.event.default.email.subject=[%WRAPPER_HOSTNAME%:%WRAPPER_NAME%:%WRAPPER_EVENT_NAME%] Event Notification
#wrapper.event.default.email.sender=<Sender email>
#wrapper.event.default.email.recipient=<Recipient email>
# Configure the log attached to event emails.
#wrapper.event.default.email.attach_log=TRUE
#wrapper.event.default.email.maillog.lines=50
#wrapper.event.default.email.maillog.format=LPTM
#wrapper.event.default.email.maillog.loglevel=INFO
# Enable specific event emails.
#wrapper.event.wrapper_start.email=TRUE
#wrapper.event.jvm_prelaunch.email=TRUE
#wrapper.event.jvm_start.email=TRUE
#wrapper.event.jvm_started.email=TRUE
#wrapper.event.jvm_deadlock.email=TRUE
#wrapper.event.jvm_stop.email=TRUE
#wrapper.event.jvm_stopped.email=TRUE
#wrapper.event.jvm_restart.email=TRUE
#wrapper.event.jvm_failed_invocation.email=TRUE
#wrapper.event.jvm_max_failed_invocations.email=TRUE
#wrapper.event.jvm_kill.email=TRUE
#wrapper.event.jvm_killed.email=TRUE
#wrapper.event.jvm_unexpected_exit.email=TRUE
#wrapper.event.wrapper_stop.email=TRUE
# Specify custom mail content
wrapper.event.jvm_restart.email.body=The JVM was restarted.\n\nPlease check on its status.\n
#********************************************************************
# Wrapper Windows NT/2000/XP Service Properties
#********************************************************************
# WARNING - Do not modify any of these properties when an application
# using this configuration file has been installed as a service.
# Please uninstall the service before modifying this section. The
# service can then be reinstalled.
# Name of the service
wrapper.name=SmppServer
# Display name of the service
wrapper.displayname=Unity SMPP Server
# Description of the service
wrapper.description=Unity SMPP Server
# Service dependencies. Add dependencies as needed starting from 1
wrapper.ntservice.dependency.1=
# Mode in which the service is installed. AUTO_START, DELAY_START or DEMAND_START
wrapper.ntservice.starttype=AUTO_START
# Allow the service to interact with the desktop.
wrapper.ntservice.interactive=false
However I got the following error message:
wrapper | --> Wrapper Started as Console
wrapper | Java Service Wrapper Professional Edition 64-bit 3.5.17
wrapper | Copyright (C) 1999-2012 Tanuki Software, Ltd. All Rights Reserved.
wrapper | http://wrapper.tanukisoftware.com
wrapper |
wrapper | --------------------------------------------------------------------
wrapper | Thank you for your interest in the Java Service Wrapper.
wrapper |
wrapper | You are running with a full featured trial License Key which will
wrapper | allow you to run or restart the Java Service Wrapper as many times
wrapper | as you like. Each invocation of the Wrapper will shutdown
wrapper | automatically after 15 minutes.
wrapper |
wrapper | This limited trial License Key is useful for quick configuration
wrapper | tests on various machines without the need to request a trial
wrapper | license. If more time is required, you can also immediately obtain
wrapper | a one-month Free trial license:
wrapper | http://wrapper.tanukisoftware.com/trial
wrapper |
wrapper | The Java Service Wrapper requires a License Key to activate the
wrapper | software. License Keys can be purchased on the Java Service Wrapper
wrapper | web site:
wrapper | http://wrapper.tanukisoftware.com/purchase
wrapper |
wrapper | This trial License Key in intended for testing and development and
wrapper | should not be used as part of a production environment.
wrapper | --------------------------------------------------------------------
wrapper |
wrapper |
wrapper | Launching a JVM...
wrapper | Command: "C:\Windows\system32\java.exe" -Dfile.encoding=Cp1252 -Duser.language=en -Djava.library.path="../lib" -classpath "../lib/wrapper.jar" -Dwrapper.key="KEggEM-am9F0iQdg0DR2yCJvAaJoF1WU" -Dwrapper.port=32000 -Dwrapper.jvm.port.
min=31000 -Dwrapper.jvm.port.max=31999 -Dwrapper.pid=7856 -Dwrapper.version="3.5.17-pro" -Dwrapper.native_library="wrapper" -Dwrapper.arch="x86" -Dwrapper.cpu.timeout="10" -Dwrapper.jvmid=1 -Dwrapper.lang.domain=wrapper -Dwrapper.lang.folder=.
./lang org.tanukisoftware.wrapper.WrapperJarApp ../lib/smpp-portal.jar -port
jvm 1 | WrapperManager: Initializing...
jvm 1 | Missing attributes for JarRsrcLoader in Manifest (Rsrc-Main-Class, Rsrc-Class-Path)
jvm 1 | WrapperJarApp:
jvm 1 | WrapperJarApp Error: Encountered an error running main:
jvm 1 | WrapperJarApp Error: java.lang.NullPointerException
jvm 1 | WrapperJarApp Error: at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoader.java:46)
jvm 1 | WrapperJarApp Error: at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
jvm 1 | WrapperJarApp Error: at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
jvm 1 | WrapperJarApp Error: at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
jvm 1 | WrapperJarApp Error: at java.lang.reflect.Method.invoke(Unknown Source)
jvm 1 | WrapperJarApp Error: at org.tanukisoftware.wrapper.WrapperJarApp.run(WrapperJarApp.java:394)
jvm 1 | WrapperJarApp Error: at java.lang.Thread.run(Unknown Source)
wrapper | <-- Wrapper Stopped
Press any key to continue . . .
Can someone help me?
Thank you in advance
unhillbilly has a good point. But actually it's not the real reason for the error you are seeing.
Basically the manifest file in your jar file appears incorrect.
When you created the jar file, you were probably exporting your project from eclipse as runnable jar and selected as library handling to package the required jar files into the generated jar...
So by doing this Eclipse is using the class JarRsrcLoader.
This class is in fact the main class of your executable jar and not as you might thought your main class.
JarRsrcLoader requires 2 parameters being set in the manifest file: Rsrc-Main-Class and Rsrc-Class-Path.
Rsrc-Main-Class is the class name of your actual main class.
Rsrc-Class-Path is the class path (with all included jar files in the jar file) to launch your application.
Your manifest file appears to miss those 2 properties.
So you can resolve this by changing the way how you are exporting the jar file, for instance use "extract required libraries in jar".
Another option would be to add the 2 missing properties into your META-INF/manifest.mf file.
Is a value missing for the port option? You say that your jar is run as:
java -jar smpp-portal -port 90
However, the wrapper config doesn't seem to have the port number as an application parameter:
# Application parameters. Add parameters as needed starting from 1
wrapper.app.parameter.1=../lib/smpp-portal.jar
wrapper.app.parameter.2=-port
You can use other executable wrapper
Launch4J - Download
JSmooth - Download
Other options are also available :)