Re: [Wrapper-user] XP, service, %classpath%, HUH?!?

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

Joseph,
    There are actually two problems here.  One is my fault and the other 
is with
the way XP handles the setting of environment variables.

    First XP's issue:  When you set an environment variable in the 
System control
panel.  This environment variable is set into the registry.   If you 
then open up a
new command window or start up a regular application, then the new setting
will be immediately visible.   The problem is with the way the Service 
Manager
works.  It appears to load the environment variables when the machine first
boots up.  Any changes to the environment variables are not visible to NT
services until the machine is rebooted.   Bad design.
    I could not tell from your message, but I am assuming that you have not
rebooted your machine since setting the CLASSPATH environment variable.
    I am currently looking into adding an option to force the Wrapper to 
load its
environment variables directly from the registry.   This would work 
around this
problem.

    First, my problem.   The above was causing the classpath to be
"%CLASSPATH%" as the environment variable did not exist and could thus
not be set.   The problem is that the Wrapper was not correctly handling the
strings and the % characters were causing problems.   printf interprets 
the %
as a special character and looks for additional parameters to insert 
into the
string.  I went through the code looking for similar problems and think that
all such problems have now been fixed.  The library path had the same bug.
Problematic code like this:
        sprintf( buffer, var );
has been changed to:
        sprintf( buffer, "%s", var );

    This has been fixed and will be in the 3.0.0 release.  Thanks for 
finding this.

    For your current version, there are a few options.
1) Reboot.  The classpath variable will be available to the service 
manager and
problem goes away.

2) I, along with most Java developers, discourage the use of the CLASSPATH
environment variable.   You will tend to run into all kinds of problems 
when running
more than one application on the same machine.   For this reason, most apps
build up a their own local classpath inside of some kind of a script 
used to launch
an application.  The wrapper bypasses this by having the user set all of the
variables inside of the wrapper.conf file using the classpath 
properties.   The
properties are broken up into individual classpath elements to make it 
possible
for the wrapper to build classpaths for both unix and windows systems 
using the
same conf file.
    If you have large numbers of jar files, it is possible to specify 
wildcards in the
conf file.  In most cases, you can specify an entire classpath with the 
following:
        wrapper.java.classpath.1=../lib/*.jar
    Note that whether the Wrapper is run in console more or as a 
service, the working
directory is always set to the location of the Wrapper binary.  This 
makes it possible
to use relative paths as shown above.

    Let me know if you have any questions about the above.  And thanks 
again for
reporting this.

Cheers,
Leif

Joseph Knapka wrote:

> Hi folks, new subscriber here. Yes, I've read
> the FAQ and the rest of the documentation, and
> I believe I've understood it. So I think the
> following is a bug, but I'm not sure if it's
> a bug in Wrapper.exe or a bug in Windows XP.
>
> Here is my App.conf file (names have been changed to
> protect the innocent):
>
> ----
> wrapper.logfile.loglevel=DEBUG
> wrapper.java.command=C:/Software/j2sdk1.4.0_02/bin/java.exe
> wrapper.java.mainclass=com.transcore.app.TheAppMain
> wrapper.java.library.path=%PATH%
> wrapper.java.classpath.1=%CLASSPATH%
>
> wrapper.ntservice.name=PcTcsExecutive
> wrapper.ntservice.displayname=TCApp
> wrapper.ntservice.description=TCApp NT Service
> wrapper.ntservice.starttype=DEMAND_START
> ----
>
> All I want is for my app to use the system-defined
> CLASSPATH, instead of manually specifying all of
> twenty or so different directories in App.conf.
>
> Now, this all works just dandy when I start my
> application at the command line, using
>
> C:> Wrapper.exe -c App.conf
>
> However, if I install and start it as a service:
>
> C:> Wrapper.exe -i C:\TCApp\App.conf
> C:> net start TCApp
>
> everything goes to hell in a handbasket, because, bizarrely,
> the CLASSPATH environment var is not read properly. In the
> resulting command reported by the wrapper, I see
> either '-classpath "LASSPATH' (in which case the JVM
> can't start because the command line is totally hosed by
> the bare double-quote), or '-classpath "6.579413e"'
> (in which case the JVM exits because, understandably,
> it can't find my App.class file in the mutilated classpath).
>
> At this point, I'm willing to blame XP for this insane
> behavior wrt the environment variable CLASSPATH. But
> Wrapper.exe seems to be going out of its way to make
> it difficult to work around this problem: I've tried
> running with no wrapper.java.classpath in App.conf,
> thinking that the JVM would use the system CLASSPATH
> environment variable in that case. But Wrapper.exe
> supplies an explicit '-classpath .' argument, which is
> just useless. Why does Wrapper.exe do that? Is it a
> security issue, or something?
>
> Any suggestions for a workaround?
>
> Thanks,
>
> -- Joe Knapka
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>