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

[Mikkel D. <mi...@co...>]

Just on more comment.

Be sure to set the env. variables you need your service to be able access
as System Variables, and not User Variables. Because your service is only
able to see the system variables.

/Mikkel.

----- Original Message -----
From: "Joseph Knapka" <joe...@tr...>
To: <wra...@li...>
Sent: Friday, February 07, 2003 5:01 AM
Subject: Re: [Wrapper-user] XP, service, %classpath%, HUH?!?


> Leif,
>
> Thank you very much for your rapid response. Everything
> you wrote below makes perfect sense. You are correct to
> infer that I have not rebooted the machine since setting
> the CLASSPATH env var.
>
> I'll look into ways to avoid using the CLASSPATH env
> var, as you suggest.
>
> Thanks,
>
> -- Joe Knapka
>
> Leif Mortenson wrote:
> > 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 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
>