wrapper-user — User issues for Wrapper. (Support questions, etc.)

[Wrapper-user] Can't read files - security exception

[FReAK La M. <fre...@qu...>]

Hi there,
I am new to the wrapper and new to this list, so I have to say hello
everybody.

Now there's my problem.

I wanted to thest the wrapper using a small RMI application. I have a
server program that reads names from a properties file and the clients can
ask the server for names.

Wehn I run the program without the wrapper, everything is fine, but when I
run it using the wrapper, I get following messages.

>Wrapper.exe -c conf\wrapper.conf
wrapper  | --> Wrapper Started as Console
wrapper  | Launching a JVM...
jvm 1    | Wrapper (Version 2.2.9)
jvm 1    |
jvm 1    | reading names.properties
jvm 1    | ERROR while reading names.properties
jvm 1    | java.security.AccessControlException: access denied
(java.io.FilePerm
ission .\names.properties read)
wrapper  | <-- Wrapper Stopped

I have following policyfile
grant {
    permission java.security.AllPermission;
	permission java.io.FilePermission "<<ALL FILES>>", "read, write, delete,
execute";
    permission java.net.SocketPermission "*:1024-65535","connect,accept";
    permission java.net.SocketPermission "*:80", "connect";
};
that should grant allPermission and more :-)

My config file looks that way:
wrapper.java.command=java
wrapper.java.mainclass=com.silveregg.wrapper.WrapperSimpleApp
wrapper.java.classpath.1=./lib/wrapper.jar
wrapper.java.classpath.2=./
wrapper.java.library.path.1=./lib/
wrapper.java.additional.1=-Djava.security.policy=RMI.policy
wrapper.java.initmemory=16
wrapper.java.maxmemory=64
wrapper.app.parameter.1=Server
wrapper.port=1777


for starting the program on the console I have to type "java
-Djava.security.policy=RMI.policy Server"

Hope someone can help and thank you for reading,
FReAK

Oh, last but not least, that is my Server program

import java.io.*;
import java.rmi.Naming;
import java.rmi.RMISecurityManager;
import java.rmi.RemoteException;
import java.rmi.server.UnicastRemoteObject;
import java.util.*;

public class Server extends UnicastRemoteObject implements
RMIPropertiesReader 
{
    Properties names;
    
    public Server() throws RemoteException
    {
        readNames();
    }
    
    private void readNames()
    {
        System.out.println("reading names.properties");
        names = new Properties();
        try
        {
            FileInputStream namesFile = new
FileInputStream("./names.properties");
            names.load(namesFile);
        }
        catch (Exception e)
        { 
            System.out.println("ERROR while reading names.properties\n"+e);
            System.exit(1);
        }
        System.out.println("done reading names.properties");
    }
    
    public String getName(String id) throws RemoteException
    {
        return names.getProperty(id);
    }

    public static void main(String[] args)
    {
        if (System.getSecurityManager() == null) {
            System.setSecurityManager(new RMISecurityManager());
        }
        String name = "//10.0.0.11/RMIPropertiesReader";
        try
        {
            RMIPropertiesReader reader = new Server();
            Naming.rebind(name, reader);
            System.out.println("RMIPropertiesReader bound");
            //System.out.println(reader.getName("sample.name.1"));
        }
        catch(Exception e)
        {
            System.err.println("ComputeEngine exception: " +
e.getMessage());
            e.printStackTrace();
        }
    }
}


_____________________________________________
Free email with personality! Over 200 domains!
http://www.MyOwnEmail.com
Looking for friendships,romance and more?
http://www.MyOwnFriends.com

Re: [Wrapper-user] wrapper performance problem

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

Marcel,
    I wonder what is causing that.  I always use the Wrapper with very 
I/O intensive
applications and have never experienced any problems with performance.  The
I/O between the Wrapper and the JVM is very light weight.  I can't 
imagine that
would be the problem.

    Could you try a few things out for me?

1) What Wrapper version, JVM version, and platform are you running?

2)  Is it possible that your application is not using the JVM that you 
are expecting
when running under the Wrapper?   You can verify this by enabling DEBUG 
output.
Towards the top of the log output, you will see something like the 
following:
---
Initializing WrapperManager native library.
Java Executable: D:\Sun\j2sdk1.4.0_03\bin\java.exe
Java Version   : 1.4.0_03-b04 Java HotSpot(TM) Client VM
Java VM Vendor : Sun Microsystems Inc.
---
I have seen cases where the Wrapper is finding the Microsoft JVM on the 
path.

3) From the debug output above, you will also see the command that the 
wrapper
uses to launch the JVM.   Please copy that into a batch file and remove the
-Dwrapper.key="xxxxxxx" parameter.   You should then be able to run your
application with the exact same JVM parameters as with the Wrapper, while at
the same time, taking the wrapper out of the loop.
Carefully compare the command line with the command line that you used 
without
the wrapper and make sure that they are the same.

Can you also post your wrapper.conf along with the first 100 or so lines 
of debug
output?

Cheers,
Leif

[Wrapper-user] wrapper performance problem

[Kool, M (Marcel) <M....@rf...>]

Hi,

I've created a Java service that takes requests from a client and
communicates with MQSeries for each request. I've tried running it with
the
Java Service Wrapper and although it works, it works really slow. I've
run
it on the JNT.exe wrapper and got about ten times the throughput I got
from
the Java Service Wrapper. It seems that the wrapper halts execution
about
every second for, the throughput seems to "stutter". I suspect it has
something to do with I/O between the wrapper and the JVM. All logging
had
been turned off so that can't be the problem. I hope someone can point
me in
the right direction here because I would really like to use the Java
Service
Wrapper instead of JNT.exe. The configuration and monitoring options are
so
much better!

Thanks in advance,

Marcel Kool




================================================
De informatie opgenomen in dit bericht kan vertrouwelijk zijn en 
is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht 
onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en 
de afzender direct te informeren door het bericht te retourneren. 
================================================
The information contained in this message may be confidential 
and is intended to be exclusively for the addressee. Should you 
receive this message unintentionally, please do not use the contents 
herein and notify the sender immediately by return e-mail.

[Wrapper-user] RE: Cascading Configuration Files

[Christian B. <kr...@di...>]

Leif:

BBgun - I like :) - seriously: I hadn't thought of option 1 (reversing
the include order) - that would solve my current problem. cool.

as to option 2) - this is basically going back to the original idea (I
guess you probably will use the normal commandline property sensing
code?!) - at this point, since I can't find anything to complain about
in 1) anymore, I don't think I care too much. in the end, having the
addtl flexibility is nice - it's your call whether you want to add the
addtl complexity :) -- probably other users have an opinion on this as
well?!

thanks,


chr.




>>>

Christian,
 
 >Pro: the nesting might be cool -- for my actual use case it's actually
 >not really that important.
 >
 I actually did not have any use case for this, but it came for free
with 
 the way I had
 implemented it.
 
 >Con: the missing ability to specify the includes on the command line
 >(well, I will need to look at the 3.0 beta sources to see if this is
 >actually true) -- if I can't specify the includes on the command line,
 >my use case falls apart, pretty much. here is the problem that I am
 >trying to solve: On AIX, I use the IBM VM, on all other platforms the
 >Sun VM. The Sun VM wants its -server switch (plus additional tuning
for
 >the GC) -- however, these switches make the IBM VM barf (it doesn't
just
 >ignore them, unfortunately). so here is what I'm doing: I have a base
 >config, and a platform specific config. the platform specifc config
 >provides the values for wrapper.java.additional.x (.1=-server for Sun,
 >.1=-Dsomething=else for IBM). in my launch.sh script, I simple decide
 >based on `uname`, then invoke either 
 >
 >"wrapper wrapper.config include.1=wrapper.config.sun
 >include.2=wrapper.config.user" 
 >
 >or 
 >
 >"wrapper wrapper.config include.1=wrapper.config.aix
 >include.2=wrapper.config.user"
 >
 >and so on (I hope having two includes doesn't qualify for being shot
in
 >backyard ;)))
 >
 Maybe just with a BBgun :-)
 No what you want to do is fair.  I want to get this implemented in a
way 
 that will be
 useful for users.
 
 There are two possible solutions for this:
 1) Means no code changes.   You would simply create 3 config files.
 wrapper.sun.conf, wrapper.aix.conf, and wrapper.conf
 In addition to the platform specific settings, the sun and aix conf 
 files would
 do nothing other than include the wrapper.conf file.   You would then
modify
 the commands used to launch the wrapper as follows:
 Sun:
   wrapper wrapper.sun.conf
 Aix:
   wrapper wrapper.aix.conf
 Other:
   wrapper wrapper.conf
 I think this is the cleanest solution and you should be able to do 
 everything
 you want?
 
 2) In addition to leaving things as is, I could add the ability to 
 specify include
 files on the command line using an include=<file> format.  The include
files
 would always be loaded as if the had been included at the very end of
the
 main config file.   Everything in option 1) would still work.
 
 Please let me know your thoughts on each of the above.
 
 As a site note, I also realized this morning that environment variable
 expansion in include statements are not currently implemented.  I'll
 take care of that before a release.
 
 >now without being able to specify the includes on the commandline, I
am
 >pretty much dead in the water here. my first use case (having to
include
 >install/user specific stuff) will still work based on your propasal,
but
 >the second one (platform specific includes) could only be achieved by
 >playing tricks with filenames -- which I'd rather not do.
 >
 Dead in the water is no good, we'll get a solution that will keep you 
 working.
 
 Cheers,
 Leif

Re: [Wrapper-user] Cascading Configuration Files

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

Christian,

>Pro: the nesting might be cool -- for my actual use case it's actually
>not really that important.
>
I actually did not have any use case for this, but it came for free with 
the way I had
implemented it.

>Con: the missing ability to specify the includes on the command line
>(well, I will need to look at the 3.0 beta sources to see if this is
>actually true) -- if I can't specify the includes on the command line,
>my use case falls apart, pretty much. here is the problem that I am
>trying to solve: On AIX, I use the IBM VM, on all other platforms the
>Sun VM. The Sun VM wants its -server switch (plus additional tuning for
>the GC) -- however, these switches make the IBM VM barf (it doesn't just
>ignore them, unfortunately). so here is what I'm doing: I have a base
>config, and a platform specific config. the platform specifc config
>provides the values for wrapper.java.additional.x (.1=-server for Sun,
>.1=-Dsomething=else for IBM). in my launch.sh script, I simple decide
>based on `uname`, then invoke either 
>
>"wrapper wrapper.config include.1=wrapper.config.sun
>include.2=wrapper.config.user" 
>
>or 
>
>"wrapper wrapper.config include.1=wrapper.config.aix
>include.2=wrapper.config.user"
>
>and so on (I hope having two includes doesn't qualify for being shot in
>backyard ;)))
>
Maybe just with a BBgun :-)
No what you want to do is fair.  I want to get this implemented in a way 
that will be
useful for users.

There are two possible solutions for this:
1) Means no code changes.   You would simply create 3 config files.
wrapper.sun.conf, wrapper.aix.conf, and wrapper.conf
In addition to the platform specific settings, the sun and aix conf 
files would
do nothing other than include the wrapper.conf file.   You would then modify
the commands used to launch the wrapper as follows:
Sun:
  wrapper wrapper.sun.conf
Aix:
  wrapper wrapper.aix.conf
Other:
  wrapper wrapper.conf
I think this is the cleanest solution and you should be able to do 
everything
you want?

2) In addition to leaving things as is, I could add the ability to 
specify include
files on the command line using an include=<file> format.  The include files
would always be loaded as if the had been included at the very end of the
main config file.   Everything in option 1) would still work.

Please let me know your thoughts on each of the above.

As a site note, I also realized this morning that environment variable
expansion in include statements are not currently implemented.  I'll
take care of that before a release.

>now without being able to specify the includes on the commandline, I am
>pretty much dead in the water here. my first use case (having to include
>install/user specific stuff) will still work based on your propasal, but
>the second one (platform specific includes) could only be achieved by
>playing tricks with filenames -- which I'd rather not do.
>
Dead in the water is no good, we'll get a solution that will keep you 
working.

Cheers,
Leif

Re: [Wrapper-user] Cascading Configuration Files

[Christian B. <kr...@di...>]

Leif:

thanks a bunch for reacting so quickly and favorably to this feature
request. 

I see one pro, one con here:

Pro: the nesting might be cool -- for my actual use case it's actually
not really that important.

Con: the missing ability to specify the includes on the command line
(well, I will need to look at the 3.0 beta sources to see if this is
actually true) -- if I can't specify the includes on the command line,
my use case falls apart, pretty much. here is the problem that I am
trying to solve: On AIX, I use the IBM VM, on all other platforms the
Sun VM. The Sun VM wants its -server switch (plus additional tuning for
the GC) -- however, these switches make the IBM VM barf (it doesn't just
ignore them, unfortunately). so here is what I'm doing: I have a base
config, and a platform specific config. the platform specifc config
provides the values for wrapper.java.additional.x (.1=-server for Sun,
.1=-Dsomething=else for IBM). in my launch.sh script, I simple decide
based on `uname`, then invoke either 

"wrapper wrapper.config include.1=wrapper.config.sun
include.2=wrapper.config.user" 

or 

"wrapper wrapper.config include.1=wrapper.config.aix
include.2=wrapper.config.user"

and so on (I hope having two includes doesn't qualify for being shot in
backyard ;)))

now without being able to specify the includes on the commandline, I am
pretty much dead in the water here. my first use case (having to include
install/user specific stuff) will still work based on your propasal, but
the second one (platform specific includes) could only be achieved by
playing tricks with filenames -- which I'd rather not do.

thanks,


chr.



> Message: 2
> Date: Sun, 09 Feb 2003 00:59:46 +0900
> From: Leif Mortenson <le...@ta...>
> To:  wra...@li...
> Subject: Re: [Wrapper-user] Cascading Configuration Files
> Reply-To: wra...@li...
> 
> Christian,
>     I changed my mind a little bit about how to implement the 
> cascading 
> configuration files.
> It is all implemented and in CVS, so this will be in the next release.
> 
>     Rather than using property names for include files, I 
> decided to do 
> it on a lower level.
> The property code now has the ability to recognize "#include <file>" 
> lines in the config
> file.  These include files will be processed at the point they are 
> included in the file so
> their contents will override values set earlier and be overridden by 
> values set later.
> By doing it this way, it is possible to nest include files as 
> well.  The 
> nesting level is limited
> to 10 deep as an easy way to avoid include loops.  If anyone 
> thinks they 
> need more
> than 10 levels, they should probably be taken out back and shot for 
> their own good.
> 
>     The files specified are optional, so there will be no 
> errors thrown 
> if an include file can
> not be found or accessed.
> 
>     Here is an example:
> 
> wrapper.conf:
> ---
> #include ../conf/inc1.conf
> wrapper.java.command=java
> wrapper.java.initmemory=16
> wrapper.java.maxmemory=64
> #include ../conf/inc2.conf
> ---
> 
> inc1.conf
> ---
> wrapper.java.initmemory=32
> ---
> 
> inc2.conf
> ---
> wrapper.java.maxmemory=128
> ---
> 
> This will result in the following values being used by the wrapper.
> ---
> wrapper.java.command=java
> wrapper.java.initmemory=16
> wrapper.java.maxmemory=128
> ---
> 
> Let me know how this will work for you or if you have any questions.
> 
> Cheers,
> Leif
> 
> > Christian Beedgen wrote:
> >
> >> here is how this works in my implementation:
> >>
> >> ./wrapper ../conf/wrapper.conf include.1=../user.conf.1
> >> include.2=../user.conf.2
> >> and so on. the order that additional configuration properties are
> >> applied is (of course) include.1, include.2, ...
> >

RE: [Wrapper-user] Almost ready for a 3.0.0 release

[Sal I. <sal...@sy...>]

Leif, wrapper users:

I verified the JVM initial memory change.
For my app it has gone down from 8Mb to 2031616 bytes, just like in Leif's
test app.

Thank you Leif,
Sal.

-----Original Message-----
From: wra...@li...
[mailto:wra...@li...]On Behalf Of Leif Mortenson
Sent: Saturday, February 08, 2003 9:40 AM
To: Wrapper User List
Subject: [Wrapper-user] Almost ready for a 3.0.0 release


Hi all,
There have been a huge number of changes for this next release. I have
tried to go
through and test it all out, but any extra eyes looking it over would be
a great help.

I have placed a prerelease version 3..0.0b up on the server for those
without CVS access:
http://wrapper.tanukisoftware.org/releases/

I am planning to do some work on the docs before the release but the latest
can be found at the following as well as in the releases.
http://wrapper.tanukisoftware.org/doc/english/index.html

For those helping out, please make sure and take a look at the release
notes:
http://wrapper.tanukisoftware.org/doc/english/release-notes.html

Cheers,
Leif



-------------------------------------------------------
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

[Wrapper-user] Almost ready for a 3.0.0 release

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

Hi all,
There have been a huge number of changes for this next release. I have
tried to go
through and test it all out, but any extra eyes looking it over would be
a great help.

I have placed a prerelease version 3..0.0b up on the server for those
without CVS access:
http://wrapper.tanukisoftware.org/releases/

I am planning to do some work on the docs before the release but the latest
can be found at the following as well as in the releases.
http://wrapper.tanukisoftware.org/doc/english/index.html

For those helping out, please make sure and take a look at the release
notes:
http://wrapper.tanukisoftware.org/doc/english/release-notes.html

Cheers,
Leif

Re: [Wrapper-user] High initial JVM memory

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

Sal,
I ran a few tests with the following class:
---
public class Memory
{
    public static void main(String[] args)
    {
        Runtime runtime = Runtime.getRuntime();
        System.out.println( "Total Memory: " + runtime.totalMemory() );
        System.out.println( "Memory: " + ( runtime.totalMemory() - 
runtime.freeMemory() ) );
    }
}
---

As a standalone java app, I get the following output:
Total Memory: 2031616
Memory: 252440
So the JVM allocates 2MB but is only using 252Kb

Running from with the wrapper using the WrapperSimpleApp and an initial
memory setting of 1MB, I get the following:
Total Memory: 8323072
Memory: 549272

Looking at the debug output of the JVM being launched, I saw that the 
initial memory
was still set to 8MB even though it was set to 1MB in the config file.  

I am not sure why I had set the minimum to 8MB, but it is now changed to 
1MB.
This will be in the next release.

Note that the values returned above are actually smaller than what is 
actually allocated
by the system.  Running with the Wrapper is still a few hundred KB 
larger than without.
This is most likely due to the extra jars, classes, native library and 
the socket resources
used to communicate with the Wrapper.   I is much better than before though.

Thanks for catching this.

Cheers,
Leif


Sal Ingrilli wrote:

>I run my program with the following configurations, and here is what
>Runtime.freeMemory ()/totalMemory () return:
>Stand-alone: 1Mb/2Mb
>Wrapper w/WrapperSimpleApp: 15Mb/16Mb
>Wrapper w/WrapperSimpleApp & wrapper.java.initmemory=2: 7Mb/8Mb
>
>Any suggestions on how to get back a memory footprint as small as my
>standalone version?
>
>
>
>-------------------------------------------------------
>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
>
>  
>

Re: [Wrapper-user] Cascading Configuration Files

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

Christian,
    I changed my mind a little bit about how to implement the cascading 
configuration files.
It is all implemented and in CVS, so this will be in the next release.

    Rather than using property names for include files, I decided to do 
it on a lower level.
The property code now has the ability to recognize "#include <file>" 
lines in the config
file.  These include files will be processed at the point they are 
included in the file so
their contents will override values set earlier and be overridden by 
values set later.
By doing it this way, it is possible to nest include files as well.  The 
nesting level is limited
to 10 deep as an easy way to avoid include loops.  If anyone thinks they 
need more
than 10 levels, they should probably be taken out back and shot for 
their own good.

    The files specified are optional, so there will be no errors thrown 
if an include file can
not be found or accessed.

    Here is an example:

wrapper.conf:
---
#include ../conf/inc1.conf
wrapper.java.command=java
wrapper.java.initmemory=16
wrapper.java.maxmemory=64
#include ../conf/inc2.conf
---

inc1.conf
---
wrapper.java.initmemory=32
---

inc2.conf
---
wrapper.java.maxmemory=128
---

This will result in the following values being used by the wrapper.
---
wrapper.java.command=java
wrapper.java.initmemory=16
wrapper.java.maxmemory=128
---

Let me know how this will work for you or if you have any questions.

Cheers,
Leif

> Christian Beedgen wrote:
>
>> here is how this works in my implementation:
>>
>> ./wrapper ../conf/wrapper.conf include.1=../user.conf.1
>> include.2=../user.conf.2
>> and so on. the order that additional configuration properties are
>> applied is (of course) include.1, include.2, ...
>

Re: [Wrapper-user] Re: Defining enviroment variable on the command line.

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

Mikkel, Rich,
    Ok, The CVS version of the Wrapper will now update all environment
variables set in the registry immediately after the Wrapper is started as
an NT Service.   I thought about this a lot and decided to make this the
default and only behavior.  The problem is that there is not any clean way
to provide a property in the conf file to control this as the decision 
whether
or not to use the registry needs to be decided before the config file is
loaded.
    I couldn't think of any reason why a user would not want to have this
functionality while running as a service anyway, so as it is currently
implemented.  Values are always read from the registry when the
Wrapper is run as a service.  Can anyone think of a case where this
could cause problems.
    When the Wrapper is run in console, service install or service remove
modes environment variables are read from the environment as was done
in previous versions.  This is necessary because the variables could be
changed from their defaults by the script used to launch the wrapper.

    Currently, there are no API or configuration changes related to this 
feature.
The only non-code change is a mention of the functionality in the docs.

Cheers,
Leif

Re: [Wrapper-user] Out of memory error

[Ashish G. <as...@se...>]

Leif Mortenson wrote:

> Ashish,
>    I got this all implemented and it will be in the 3.0.0 release.
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=676599&group_id=39428&atid=425190
>
> Cheers,
> Leif
>
Thank you very much Leif!

Regards,

Ashish

Re: [Wrapper-user] Problems to wrap jboss

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

Mark Striebeck wrote:

> what is the difference between the WrapperSimpleApp and the 
> WrapperStartStopApp class? I am using the SimpleApp and everything 
> seems to work. I tried the WrapperStartStop class, but couldn't really 
> figure out what the settings for the wrapper.app.parameter.* are 
> (Andrew, I checked your .conf file, but I still don't know what the 
> settings mean) 

The WrapperSimpleApp is used to launch any Java application via its main
method.  This is the best choice for wrapping most applications.

The WrapperStartStopApp is used to control applications which use one
java app to launch an application and then a second one to shut it down
cleanly.  Often, the first app will open up a server socket and 
listening for
a connection.
A shutdown app then connects to the application using a socket and tells
it to shutdown.
When using the Wrapper, the entire lifecycle is controlled by the Wrapper.
The WrapperStartStopApp requires that two classes and their parameters
to be specified.  One for the main method of the application.  And the
second for the main method of the shutdown class.  When the Wrapper
launches a JVM, it calls the first class's main method to launch the
application.  Then when it is time to shutdown the application, it calls the
second classes main method.

They are both explained along with examples on:
http://wrapper.sourceforge.net/doc/english/api-overview.html
Let me know if there are any areas of the description which could be 
cleared up.

I hope that helps.
Cheers,
Leif

Re: [Wrapper-user] Out of memory error

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

Ashish,
    I got this all implemented and it will be in the 3.0.0 release.

http://sourceforge.net/tracker/index.php?func=detail&aid=676599&group_id=39428&atid=425190

Cheers,
Leif

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
>

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

[Joseph K. <joe...@tr...>]

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 );

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
>

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

[Joseph K. <joe...@tr...>]

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

[Wrapper-user] RE: Wrapper-user digest, Vol 1 #45 - 7 msgs

[Christian B. <kr...@di...>]

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Leif: thanks for responding so quickly; sorry my turnaround time is a
bit higher right now.

> This is a good idea, but I would like to avoid adding complexity to
> the command line.  How would you feel about adding a section like
> the following to the primary wrapper.conf  

not sure I'm following; actually, I really didn't touch the
commandline at all, but instead I do take the include.1, ...
parameters from the main wrapper.conf. so basically I am already
doing what you propose (I didn't want to touch the commandline
parsing, trust me ;) -- and if you want to rename the parameters to
wrapper.include.x, that's perfectly fine with me.

let me know if I didn't understand this correctly,


thanks,


chr.

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4

iQA/AwUBPkIH/Us9sU6X9koVEQLwwQCguESA2PE6Co9NSAUo4wBZQJZ6tdMAnjE9
oBBUb/x77m0lfk29lrUbJlbp
=UNB+
-----END PGP SIGNATURE-----

Re: [Wrapper-user] Problems to wrap jboss

[Mark S. <mst...@va...>]

Thanks everyone for the feedback. After comparing the command line from 
the call in jboss/bin/run.bat and the one from the wrapper, I found the 
problem: I used some environment variables in the .conf file. After 
replacing them with the real values, it works.

I have one more question:

what is the difference between the WrapperSimpleApp and the 
WrapperStartStopApp class? I am using the SimpleApp and everything seems 
to work. I tried the WrapperStartStop class, but couldn't really figure 
out what the settings for the wrapper.app.parameter.* are (Andrew, I 
checked your .conf file, but I still don't know what the settings mean)

Thanks
    MarkS

Mark Striebeck wrote:

> Hi,
>
> I was trying to use the Java Service Wrapper for Jboss. But for some 
> reasons I don't seem to be able to get the .conf file correct. It 
> seems to be a problem with the wrapper.app.parameter settings.
>
> If someone has a .conf file, can he/she please post it.
>
> Or where can I get some more information about the 
> wrapper.app.parameter settings? The docu has tomcat as an example, but 
> I can't use that for jboss.
>
> Thanks!!!!!
>
>     MarkS
>
>
>
> -------------------------------------------------------
> 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

Re: [Wrapper-user] Re: Defining enviroment variable on the commandline.

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

SHGetValue:

DWORD SHGetValue(          HKEY hkey,
    LPCTSTR pszSubKey,
    LPCTSTR pszValue,
    LPDWORD pdwType,
    LPVOID pvData,
    LPDWORD pcbData
);

Search msdn.microsoft.com for shgetvalue.

>>> le...@ta... 02/04/03 03:53am >>>
That sounds like it would work nicely.  Is there an api for that which I =
am
unaware of or do you have to loop over the registry items at
/HKEY_LOCAL_MACHINES\SYSTEM\CurrentControlSet\Control\Session=20
Manager\Environment
That seems to be where the system wide environment variables are set.
I suppose that I could then call setenv on each entry.  Once that is=20
done, the
rest of the code should work as is...

My system also has settings in the following two registry folders:
/HKEY_LOCAL_MACHINES\SYSTEM\ControlSet001
/HKEY_LOCAL_MACHINES\SYSTEM\ControlSet002

But I assume that the CurrentControlSet is the one we would want...

Leif

Rich Taylor wrote:

>I ran into a similar situation with environment variables.
>
>I am setting the APP_HOME environment variable the installshield=20
>script, then installing the wrapper service with the following line in =
my=20
>wrapper.conf:
>wrapper.java.classpath.1=3D%APP_HOME%\lib\*.jar
>
>Because of the way the NT service manager doesn't reload environment
>variables this doesn't work until after the machine is rebooted(as you
>discussed earlier).
>
>Currently we are just working around this, but I think it should be
>possible to add a configuration options like:
>wrapper.ntservice.envFromRegistry=3Dtrue
>
>When this property is set, the wrapper would query the windows registry
>directly.
>
>I don't know if this would work for you Mikkel, but it was a thought I
>had.  I just need to find the time to go implement it.
>
>Rich
>
>On Sun, 2 Feb 2003, Mikkel Damsgaard wrote:
>
> =20
>
>>Date: Sun, 2 Feb 2003 10:09:02 +0100
>>From: Mikkel Damsgaard <mi...@co...>
>>To: wra...@li...=20
>>Reply-To: wra...@li...=20
>>Subject: Re: [Wrapper-user] Re: Defining enviroment variable on the =
command
>>   =20
>>
>    line.
> =20
>
>>Sender: wra...@li...=20
>>
>>   =20
>>
>>>Couldn't you modify the script which installs the service so that the
>>>replacement is done
>>>within the script rather than in the conf file.  I have always done it
>>>as follows:  If you place
>>>this in your script:
>>>
>>>---
>>>set APP_HOME=3DC:\app
>>>set JAVA_HOME=3DC:\jdk1.3
>>>wrapper -i %APP_HOME%\wrapper.conf
>>>     =20
>>>
>>wrapper.java.command=3D%JAVA_HOME%\bin\java
>>   =20
>>
>>>---
>>>
>>>Then the replacements all happen in the script so the parameters passed
>>>to the wrapper
>>>are all replaced.  The full command that is then stored in the registry
>>>looks like this:
>>>---
>>>wrapper -s C:\app\wrapper.conf wrapper.java.command=3DC:\jdk1.3\bin\java=

>>>---
>>>At run time no environment variables are used so things work correctly.
>>> This should give
>>>you the exact same functionality as you are requesting?
>>>
>>>     =20
>>>
>>I could, but I wont be able to use %APP_HOME% in the .conf file, and I =
will
>>have to specify everything
>>depending on %APP_HOME% on the comand line. In my case about 10-15
>>variables, such as
>>java.classpath stuff. Besides when changing the classpath, you I will =
have
>>to reinstall the service
>>for it to take effect.
>>
>>/Mikkel
>>
>>   =20
>>
>>>Cheers,
>>>Leif
>>>
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.NET email is sponsored by:
>>>SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 See!
>>>http://www.vasoftware.com=20
>>>_______________________________________________
>>>Wrapper-user mailing list
>>>Wra...@li...=20
>>>https://lists.sourceforge.net/lists/listinfo/wrapper-user=20
>>>
>>>     =20
>>>
>>
>>-------------------------------------------------------
>>This SF.NET email is sponsored by:
>>SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 See!
>>http://www.vasoftware.com=20
>>_______________________________________________
>>Wrapper-user mailing list
>>Wra...@li...=20
>>https://lists.sourceforge.net/lists/listinfo/wrapper-user=20
>>
>>   =20
>>
>
>
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by:
>SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 See!
>http://www.vasoftware.com=20
>_______________________________________________
>Wrapper-user mailing list
>Wra...@li...=20
>https://lists.sourceforge.net/lists/listinfo/wrapper-user=20
>
> =20
>




-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 See!
http://www.vasoftware.com=20
_______________________________________________
Wrapper-user mailing list
Wra...@li...=20
https://lists.sourceforge.net/lists/listinfo/wrapper-user

[Wrapper-user] High initial JVM memory

[Sal I. <sal...@sy...>]

I run my program with the following configurations, and here is what
Runtime.freeMemory ()/totalMemory () return:
Stand-alone: 1Mb/2Mb
Wrapper w/WrapperSimpleApp: 15Mb/16Mb
Wrapper w/WrapperSimpleApp & wrapper.java.initmemory=2: 7Mb/8Mb

Any suggestions on how to get back a memory footprint as small as my
standalone version?

Re: [Wrapper-user] Re: Defining enviroment variable on the command line.

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

That sounds like it would work nicely.  Is there an api for that which I am
unaware of or do you have to loop over the registry items at
/HKEY_LOCAL_MACHINES\SYSTEM\CurrentControlSet\Control\Session 
Manager\Environment
That seems to be where the system wide environment variables are set.
I suppose that I could then call setenv on each entry.  Once that is 
done, the
rest of the code should work as is...

My system also has settings in the following two registry folders:
/HKEY_LOCAL_MACHINES\SYSTEM\ControlSet001
/HKEY_LOCAL_MACHINES\SYSTEM\ControlSet002

But I assume that the CurrentControlSet is the one we would want...

Leif

Rich Taylor wrote:

>I ran into a similar situation with environment variables.
>
>I am setting the APP_HOME environment variable the installshield 
>script, then installing the wrapper service with the following line in my 
>wrapper.conf:
>wrapper.java.classpath.1=%APP_HOME%\lib\*.jar
>
>Because of the way the NT service manager doesn't reload environment
>variables this doesn't work until after the machine is rebooted(as you
>discussed earlier).
>
>Currently we are just working around this, but I think it should be
>possible to add a configuration options like:
>wrapper.ntservice.envFromRegistry=true
>
>When this property is set, the wrapper would query the windows registry
>directly.
>
>I don't know if this would work for you Mikkel, but it was a thought I
>had.  I just need to find the time to go implement it.
>
>Rich
>
>On Sun, 2 Feb 2003, Mikkel Damsgaard wrote:
>
>  
>
>>Date: Sun, 2 Feb 2003 10:09:02 +0100
>>From: Mikkel Damsgaard <mi...@co...>
>>To: wra...@li...
>>Reply-To: wra...@li...
>>Subject: Re: [Wrapper-user] Re: Defining enviroment variable on the command
>>    
>>
>    line.
>  
>
>>Sender: wra...@li...
>>
>>    
>>
>>>Couldn't you modify the script which installs the service so that the
>>>replacement is done
>>>within the script rather than in the conf file.  I have always done it
>>>as follows:  If you place
>>>this in your script:
>>>
>>>---
>>>set APP_HOME=C:\app
>>>set JAVA_HOME=C:\jdk1.3
>>>wrapper -i %APP_HOME%\wrapper.conf
>>>      
>>>
>>wrapper.java.command=%JAVA_HOME%\bin\java
>>    
>>
>>>---
>>>
>>>Then the replacements all happen in the script so the parameters passed
>>>to the wrapper
>>>are all replaced.  The full command that is then stored in the registry
>>>looks like this:
>>>---
>>>wrapper -s C:\app\wrapper.conf wrapper.java.command=C:\jdk1.3\bin\java
>>>---
>>>At run time no environment variables are used so things work correctly.
>>> This should give
>>>you the exact same functionality as you are requesting?
>>>
>>>      
>>>
>>I could, but I wont be able to use %APP_HOME% in the .conf file, and I will
>>have to specify everything
>>depending on %APP_HOME% on the comand line. In my case about 10-15
>>variables, such as
>>java.classpath stuff. Besides when changing the classpath, you I will have
>>to reinstall the service
>>for it to take effect.
>>
>>/Mikkel
>>
>>    
>>
>>>Cheers,
>>>Leif
>>>
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>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
>>>
>>>      
>>>
>>
>>-------------------------------------------------------
>>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
>>
>>    
>>
>
>
>
>
>-------------------------------------------------------
>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
>
>  
>

Re: [Wrapper-user] Re: Defining enviroment variable on the command line.

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

Yepp. That would definitely work, and would be a very good solution.
Since the problem is only present in the windows environment your solution
is
very nice.

----- Original Message -----
From: "Rich Taylor" <ric...@po...>
To: <wra...@li...>
Sent: Monday, February 03, 2003 8:09 PM
Subject: [Wrapper-user] Re: Defining enviroment variable on the command
line.


> I ran into a similar situation with environment variables.
>
> I am setting the APP_HOME environment variable the installshield
> script, then installing the wrapper service with the following line in my
> wrapper.conf:
> wrapper.java.classpath.1=%APP_HOME%\lib\*.jar
>
> Because of the way the NT service manager doesn't reload environment
> variables this doesn't work until after the machine is rebooted(as you
> discussed earlier).
>
> Currently we are just working around this, but I think it should be
> possible to add a configuration options like:
> wrapper.ntservice.envFromRegistry=true
>
> When this property is set, the wrapper would query the windows registry
> directly.
>
> I don't know if this would work for you Mikkel, but it was a thought I
> had.  I just need to find the time to go implement it.
>
> Rich
>
> On Sun, 2 Feb 2003, Mikkel Damsgaard wrote:
>
> > Date: Sun, 2 Feb 2003 10:09:02 +0100
> > From: Mikkel Damsgaard <mi...@co...>
> > To: wra...@li...
> > Reply-To: wra...@li...
> > Subject: Re: [Wrapper-user] Re: Defining enviroment variable on the
command
>     line.
> > Sender: wra...@li...
> >
> > > Couldn't you modify the script which installs the service so that the
> > > replacement is done
> > > within the script rather than in the conf file.  I have always done it
> > > as follows:  If you place
> > > this in your script:
> > >
> > > ---
> > > set APP_HOME=C:\app
> > > set JAVA_HOME=C:\jdk1.3
> > > wrapper -i %APP_HOME%\wrapper.conf
> > wrapper.java.command=%JAVA_HOME%\bin\java
> > > ---
> > >
> > > Then the replacements all happen in the script so the parameters
passed
> > > to the wrapper
> > > are all replaced.  The full command that is then stored in the
registry
> > > looks like this:
> > > ---
> > > wrapper -s C:\app\wrapper.conf wrapper.java.command=C:\jdk1.3\bin\java
> > > ---
> > > At run time no environment variables are used so things work
correctly.
> > >  This should give
> > > you the exact same functionality as you are requesting?
> > >
> >
> > I could, but I wont be able to use %APP_HOME% in the .conf file, and I
will
> > have to specify everything
> > depending on %APP_HOME% on the comand line. In my case about 10-15
> > variables, such as
> > java.classpath stuff. Besides when changing the classpath, you I will
have
> > to reinstall the service
> > for it to take effect.
> >
> > /Mikkel
> >
> > > Cheers,
> > > Leif
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > 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
> > >
> >
> >
> >
> > -------------------------------------------------------
> > 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
> >
>
>
>
>
> -------------------------------------------------------
> 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
>

[Wrapper-user] Re: Defining enviroment variable on the command line.

[Rich T. <ric...@po...>]

I ran into a similar situation with environment variables.

I am setting the APP_HOME environment variable the installshield 
script, then installing the wrapper service with the following line in my 
wrapper.conf:
wrapper.java.classpath.1=%APP_HOME%\lib\*.jar

Because of the way the NT service manager doesn't reload environment
variables this doesn't work until after the machine is rebooted(as you
discussed earlier).

Currently we are just working around this, but I think it should be
possible to add a configuration options like:
wrapper.ntservice.envFromRegistry=true

When this property is set, the wrapper would query the windows registry
directly.

I don't know if this would work for you Mikkel, but it was a thought I
had.  I just need to find the time to go implement it.

Rich

On Sun, 2 Feb 2003, Mikkel Damsgaard wrote:

> Date: Sun, 2 Feb 2003 10:09:02 +0100
> From: Mikkel Damsgaard <mi...@co...>
> To: wra...@li...
> Reply-To: wra...@li...
> Subject: Re: [Wrapper-user] Re: Defining enviroment variable on the command
    line.
> Sender: wra...@li...
> 
> > Couldn't you modify the script which installs the service so that the
> > replacement is done
> > within the script rather than in the conf file.  I have always done it
> > as follows:  If you place
> > this in your script:
> >
> > ---
> > set APP_HOME=C:\app
> > set JAVA_HOME=C:\jdk1.3
> > wrapper -i %APP_HOME%\wrapper.conf
> wrapper.java.command=%JAVA_HOME%\bin\java
> > ---
> >
> > Then the replacements all happen in the script so the parameters passed
> > to the wrapper
> > are all replaced.  The full command that is then stored in the registry
> > looks like this:
> > ---
> > wrapper -s C:\app\wrapper.conf wrapper.java.command=C:\jdk1.3\bin\java
> > ---
> > At run time no environment variables are used so things work correctly.
> >  This should give
> > you the exact same functionality as you are requesting?
> >
> 
> I could, but I wont be able to use %APP_HOME% in the .conf file, and I will
> have to specify everything
> depending on %APP_HOME% on the comand line. In my case about 10-15
> variables, such as
> java.classpath stuff. Besides when changing the classpath, you I will have
> to reinstall the service
> for it to take effect.
> 
> /Mikkel
> 
> > Cheers,
> > Leif
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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
> >
> 
> 
> 
> -------------------------------------------------------
> 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
>