Re: [Wrapper-user] Can't start service error

[Leif M. <le...@ta...>]

Dave,
> # Java Classpath (include wrapper.jar)  Add class path elements as
> #  needed starting from 1
> wrapper.java.classpath.1=../*.jar
>   
This is actually perfectly fine.  Maintaining a full list of jar files 
in the wrapper.conf
makes the wrapper.conf as difficult to maintain as a standard batch 
file.   To help
the user with this, the Wrapper has a feature which allows wildcards in 
this location.
It then expands those wildcards when generating the classpath used to 
launch the
actual JVM.
> # Java Library Path (location of Wrapper.DLL or libwrapper.so)
> wrapper.java.library.path.1=../bin
> wrapper.java.library.path.2=%PATH%
>   
The Wrapper is capable of doing environment variable expansions.  So in that
respect this is correct.  I do have some comments on this however.

By default, if a specific java.library.path is not specified when 
launching a JVM,
Java defaults to using the system PATH to locate its native library DLLs.
This is similar to the way it defaults to the CLASSPATH environment variable
if a classpath is not specified on the java command line.

Both of these methods of locating libraries is considered to be bad 
practice by
much of the java community.   The problem is that you are placing your
application ability to start up in he faith that nobody or no other 
application will
ever modify the system environment in a way that affects your application.

In both the PATH and CLASSPATH cases, they are system wide variables
which can and will be modified by others.  In the case of java, these system
wide variables also do not support the ability to have more than one version
of an application installed at once as both versions would have to be 
located
on the same PATH/CLASSPATH.

In experience, developers have run into many problems where an unrelated
program happens to have a DLL or jar files with the same name that ends
up breaking their program.

In the case of the Wrapper, it requires its own native library, this it must
define a java.library.path to avoid the above problems.  In doing so, it
also prevents Java from looking on the PATH for native libraries as was
done without the Wrapper.   You can get the original behavior back by
doing the following:

wrapper.java.library.path.1=../bin
wrapper.java.library.path.append_system_path=true

See the explanation of this property here:
http://wrapper.tanukisoftware.org/doc/english/prop-java-library-path-append-system-path.html

BUT. If you do this, you will open yourself up to the same problems that I
described above.  A much better way to handle this is to locate the DLL(s)
that your Java application requires and add those specific locations to the
library path directly.  Personally, I like to keep applications as 
compartmentalized
as possible by placing the required native libraries into the lib 
directory with
the wrapper.dll file.

In cases where the native library DLL requires additional DLLs to be loaded,
the nested DLL load is outside the scope of Java.  Such DLLs will still be
located using the PATH on Windows and LD_LIBRARY_PATH on UNIX
systems.   To make that work correctly after all DLLs have been moved to
the lib directory, you also need to set up those environment variables 
correctly
as follows.  These changes are done when the wrapper is launched and are
local to the wrapper and its child process environments. (ie Java).  
This keeps
your system as a whole nice and clean, is easy to maintain and support, and
will help make sure your application runs reliably over time.

set.PATH=..%WRAPPER_FILE_SEPARATOR%lib%WRAPPER_PATH_SEPARATOR%%PATH%
set.LD_LIBRARY_PATH=..%WRAPPER_FILE_SEPARATOR%lib%WRAPPER_PATH_SEPARATOR%%LD_LIBRARY_PATH%
wrapper.java.library.path.1=../bin
wrapper.java.library.path.2=../lib

The WRAPPER_* environment variables below are there to make sure the
same wrapper.conf file can be used as is on both Windows and UNIX
systems.  The java.library.path itself is used within java, so the forward
slashes are always converted correctly before use.


Now on to your original problem:
>> STATUS | wrapper  | 2007/02/16 09:20:16 | Launching a JVM...
>> INFO   | jvm 5    | 2007/02/16 09:20:16 |
>> java.lang.NoClassDefFoundError: Files\Sybase\ASA
>>     
Try setting the following property and then relaunching your JVM.
wrapper.java.command.loglevel=INFO

You will now see the generated java command line in the wrapper.log file 
before
the failure.  From your configuration file, I see only one place that 
could be a
problem.  Your system PATH most likely contains quotes around one or more
of its entries as follows:
PATH=c:\myfirstapp;"C:\Program Files\Sybase\ASA";c:\Mysecondapp.

When the Wrapper builds the command line, it encloses the entire library 
path
in a set of quotes.  This works perfectly in all cases whether the path 
contains
spaces or not.   The problem is that with invalid paths like the one 
above, this
will break as the generated command line goes in and out of the quoted state
at inappropriate times.

I will look at ways to at least warn the user about the this problem to help
make it clearer and easier to avoid.

Cheers,
Leif