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

Re:[Wrapper-user] RMI services being killed on user logout

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

Hi,
well I am running an RMI Programm using the wrapper with no problem.
I think that your problem is that you are starting the Registry via
System.exec()
I am using java.rmi.registry.LocateRegistry.createRegistry(1099);

Hope that helps,
FReAK

----------------------------------------------
Original Message
From: "Palmer, David"<Dav...@ph...>
Subject: [Wrapper-user] RMI services being killed on user logout
Date: Wed, 26 Mar 2003 15:41:59 -0500

>Hello all...
>have a question. Trying to implement this tool to create services out of a
>RMI application we are forced to use.
>
>The problem is...that when the user loggs off the Win2k machine, the
wrapper
>properly ignores this action (as I can see in the wrapper.log) but still,
>the rmiregistry and rmi server itself dies... and yet the service is still
>running.
>
>We are running on Win2k
>Using JDK1.3.1_07 when logging out, the wrapper.log has these entries:
>INFO   | wrapper  | 2003/03/25 16:32:10 | User logged out.  Ignored.
>INFO   | wrapper  | 2003/03/25 16:32:11 | User logged out.  Ignored.
>INFO   | jvm 1    | 2003/03/25 16:32:11 | java.rmi.UnmarshalException:
Error
>unmarshaling return header; nested exception is: 
>INFO   | jvm 1    | 2003/03/25 16:32:11 | 	java.net.SocketException:
>Connection reset by peer: JVM_recv in socket input stream read
>INFO   | jvm 1    | 2003/03/25 16:32:11 | java.net.SocketException:
>Connection reset by peer: JVM_recv in socket input stream read
><snipped>
>
>When using JDK1.4.1 We got:
>INFO   | wrapper  | 2003/03/26 11:13:46 | User logged out.  Ignored.
>INFO   | wrapper  | 2003/03/26 11:13:57 | User logged out.  Ignored.
>(no exceptions... but the rmi services were indeed killed).
>
>The problem, in a nutshell, is that even though the "user logging out"
>action is intercepted by the wrapper... our RMI stuff still dies upon a
user
>logging out.
>
>It should also be noted that, in the actual implementation of the RMI
>Server, we have the starting up of the rmi registry:
>
>try {
>    Runtime.getRuntime().exec("rmiregistry "+port+" 
>	-J-Dsun.rmi.loader.logLevel=verbose
>-J-Djava.rmi.server.codebase="+sCodebase+" 
>	-J-Djava.rmi.server.hostname="+host);
>} catch (IOException e) {
>    System.out.println("An error occured setting the CODEBASE system
>property");
>	e.printStackTrace();
>	return;
>}
>
>Everything else is just normal RMI server stuff... nothing exotic.
>
>I've been through the documentation, done numerous google searches to try
to
>get to the bottom of this, but haven't found much of anything.
>
>I sure hope someone here can shed some light. Thanks!
>
>Regards,
>Dave Palmer
>
>
>"The sender believes that this E-mail and any attachments were free of any
>harmful and malicious code or defects when sent.  This message and its
>attachments could have been infected during transmission.  By reading the
>message and opening any attachments, the recipient accepts full
>responsibility for taking protective and remedial action regarding the code
>or such defects.  The sender is not liable for any loss or damage arising
in
>any way from this message or its attachments."
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by:
>The Definitive IT and Networking Event. Be There!
>NetWorld+Interop Las Vegas 2003 -- Register today!
>http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
>_______________________________________________
>Wrapper-user mailing list
>Wra...@li...
>https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

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

[Wrapper-user] RMI services being killed on user logout

[Palmer, D. <Dav...@ph...>]

Hello all...
have a question. Trying to implement this tool to create services out of a
RMI application we are forced to use.

The problem is...that when the user loggs off the Win2k machine, the wrapper
properly ignores this action (as I can see in the wrapper.log) but still,
the rmiregistry and rmi server itself dies... and yet the service is still
running.

We are running on Win2k
Using JDK1.3.1_07 when logging out, the wrapper.log has these entries:
INFO   | wrapper  | 2003/03/25 16:32:10 | User logged out.  Ignored.
INFO   | wrapper  | 2003/03/25 16:32:11 | User logged out.  Ignored.
INFO   | jvm 1    | 2003/03/25 16:32:11 | java.rmi.UnmarshalException: Error
unmarshaling return header; nested exception is: 
INFO   | jvm 1    | 2003/03/25 16:32:11 | 	java.net.SocketException:
Connection reset by peer: JVM_recv in socket input stream read
INFO   | jvm 1    | 2003/03/25 16:32:11 | java.net.SocketException:
Connection reset by peer: JVM_recv in socket input stream read
<snipped>

When using JDK1.4.1 We got:
INFO   | wrapper  | 2003/03/26 11:13:46 | User logged out.  Ignored.
INFO   | wrapper  | 2003/03/26 11:13:57 | User logged out.  Ignored.
(no exceptions... but the rmi services were indeed killed).

The problem, in a nutshell, is that even though the "user logging out"
action is intercepted by the wrapper... our RMI stuff still dies upon a user
logging out.

It should also be noted that, in the actual implementation of the RMI
Server, we have the starting up of the rmi registry:

try {
    Runtime.getRuntime().exec("rmiregistry "+port+" 
	-J-Dsun.rmi.loader.logLevel=verbose
-J-Djava.rmi.server.codebase="+sCodebase+" 
	-J-Djava.rmi.server.hostname="+host);
} catch (IOException e) {
    System.out.println("An error occured setting the CODEBASE system
property");
	e.printStackTrace();
	return;
}

Everything else is just normal RMI server stuff... nothing exotic.

I've been through the documentation, done numerous google searches to try to
get to the bottom of this, but haven't found much of anything.

I sure hope someone here can shed some light. Thanks!

Regards,
Dave Palmer


"The sender believes that this E-mail and any attachments were free of any
harmful and malicious code or defects when sent.  This message and its
attachments could have been infected during transmission.  By reading the
message and opening any attachments, the recipient accepts full
responsibility for taking protective and remedial action regarding the code
or such defects.  The sender is not liable for any loss or damage arising in
any way from this message or its attachments."

RE: [Wrapper-user] Regarding Windows NT service problem

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

-----Original Message-----
From: wra...@li...
[mailto:wra...@li...]On Behalf Of Leif
Mortenson
Sent: Sunday, March 23, 2003 3:28 PM
To: wra...@li...
Subject: Re: [Wrapper-user] Regarding Windows NT service problem


Ravi,
    The problem is that the WrapperManager class is never being loaded 
on the Java
side.  Please read the documentation on how to integrate your 
application with the
Wrapper.  Most likely the best integration solution for you will be to 
use the
WrapperSimpleApp helper class.
http://wrapper.tanukisoftware.org/doc/english/integrate-simple-win.html

    You should read over the following page which covers the benefits of
all 3 integration methods to make sure that the WrapperSimpleApp is
really best for you.
http://wrapper.tanukisoftware.org/doc/english/integrate.html

    AFTER reading the documentation so you understand, try making the
following changes:

wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
wrapper.app.parameter.1=com.elixirtech.report.server.ElixirReportServer

That should then work.

All please let me know how I could improve the documentation to have helped
you to figure this out on your own.  This is a common user mistake.

Cheers,
Leif





-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] Regarding Windows NT service problem

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

Ravi,
    The problem is that the WrapperManager class is never being loaded 
on the Java
side.  Please read the documentation on how to integrate your 
application with the
Wrapper.  Most likely the best integration solution for you will be to 
use the
WrapperSimpleApp helper class.
http://wrapper.tanukisoftware.org/doc/english/integrate-simple-win.html

    You should read over the following page which covers the benefits of
all 3 integration methods to make sure that the WrapperSimpleApp is
really best for you.
http://wrapper.tanukisoftware.org/doc/english/integrate.html

    AFTER reading the documentation so you understand, try making the
following changes:

wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
wrapper.app.parameter.1=com.elixirtech.report.server.ElixirReportServer

That should then work.

All please let me know how I could improve the documentation to have helped
you to figure this out on your own.  This is a common user mistake.

Cheers,
Leif

Re: [Wrapper-user] Regarding NT Windows 2000 problem

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

Ravi,
    Well, I can not help you either unless you send me the wrapper.log 
file with
DEBUG output enabled, along with your wrapper.conf file!

Leif

Ravi Shankar wrote:

> Hi,
>  
> I am facing the same problem to run as Windows NT service when 
> executing from stand alone too.
>  
> Thanks and regards,
> Ravi

[Wrapper-user] Regarding NT Windows 2000 problem

[Ravi S. <ra...@el...>]

Hi,

I am facing the same problem to run as Windows NT service when executing =
from stand alone too.

Thanks and regards,
Ravi

Re: [Wrapper-user] To install a service in WIndows 2000

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

I can't really help you with what you sent.  Can you please enable DEBUG
output to the log file using the following setting in the wrapper.conf file.

wrapper.logfile.loglevel=DEBUG

then post the resulting log file when you try to run it as a service.
Most likely there is some kind of a path problem and the Wrapper is
repeatedly trying to launch your application and failing.  That is why it
is taking so long.  Usually if you look at the debug output, the problem
will be obvious.

Cheers,
Leif


Suchetha Ravishankar wrote:

> Hi,
>  I am working with a Report Server which I want to start as a Windows 
> service. I have written the correct configuration file and it is 
> working perfectly as a stand alone app.When I run it as a service, the 
> Windows Management console takes lot of time and finally comes up with 
> a message telling" service cannot be started in a timely fashion". Why 
> so? Please reply soon, thanks in advance,
> Ravi Shankar

[Wrapper-user] To install a service in WIndows 2000

[Suchetha R. <suj...@pa...>]

Hi,
 I am working with a Report Server which I want to start as a Windows =
service. I have written the correct configuration file and it is working =
perfectly as a stand alone app.When I run it as a service, the Windows =
Management console takes lot of time and finally comes up with a message =
telling" service cannot be started in a timely fashion". Why so? Please =
reply soon, thanks in advance,
Ravi Shankar

Re: [Wrapper-user] Wrapper on HP-UX Problem

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

Leif Mortenson wrote:

> Stefan,
>    HP-UX support was graciously donated by one of our users.   I have
> never actually touched one of these machines, so hopefully any other
> HP-UX out there will post if they have any ideas on this :-)
>
>    There should be no reason why the script requires root access as it
> is failing.  The wrapper will try to write a pid file to /var/run.   
> But I don't
> think you would get the error you are seeing if you don't have access to
> write to that directory.
>
> Here are a couple things that you could check:
>
> 1) It sounds obvious, but has happened before.  :-)  Are you sure you
> are using the HP-UX version of the Wrapper.  Releases are platform
> dependent.
>
> 2) What happens if you go into the WRapper bin directory and manually
> execute:
> ./wrapper
> If it is working, you should get a usage message.  How about:
> ./realpath
> Once again, you should get a usage message.
>
> 3) You might want to try downloading the source release and running the
> build.sh script for you particular machine.   Not being familiar with 
> HP-UX,
> I'm not sure if this is an issue, but the release we provide may not be
> compatible with your particular hardware??  If this true, I would want to
> know about it.  But doing a build on your machine would fix that problem.
>
> Obviously, I am shooting in the dark, but let me know about the above.
> I'll give it some more thought as well.
>
> Cheers,
> Leif
>
> Stefan Gatz wrote:
>
>> Hi there,
>>
>> im trying to run the wrapper 3.0.0 on HP-UX 11. When i run the shell 
>> script
>> i get an error "./wrapper: Execution permission denied".
>>
>> I have set the execute-flag on the "wrapper" file. All needed files 
>> including lib....so, realpath etc. are in the same
>> directory
>> and have also the execution flag set.
>>
>> I have no root rights on the machine. Do i need root rights to use 
>> wrapper
>> on HP-UX ?
>>
>> Thanks in advance.
>>
>> STefan
>>  
>>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Tablet PC.  Does your code think in 
> ink? You could win a Tablet PC. Get a free Tablet PC hat just for 
> playing. What are you waiting for? 
> http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user

The binaries were built on HP-UX  B.11.11.  Did you use these binaries 
or built from the wrapper source?

When I try to execute I get the following message:
Usage: ./wrapper <file> [config properties] [...]
<file> is the application config file.

[config properties] are configuration name-value pairs which override values
  in wrapper.conf.  For example:
  wrapper.debug=true

Options:  --help

Dont know why it doesnt work for you.

Hope this helps.

Ashish Gawarikar

Re: [Wrapper-user] Wrapper on HP-UX Problem

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

Stefan,
    HP-UX support was graciously donated by one of our users.   I have
never actually touched one of these machines, so hopefully any other
HP-UX out there will post if they have any ideas on this :-)

    There should be no reason why the script requires root access as it
is failing.  The wrapper will try to write a pid file to /var/run.   But 
I don't
think you would get the error you are seeing if you don't have access to
write to that directory.

Here are a couple things that you could check:

1) It sounds obvious, but has happened before.  :-)  Are you sure you
are using the HP-UX version of the Wrapper.  Releases are platform
dependent.

2) What happens if you go into the WRapper bin directory and manually
execute:
./wrapper
If it is working, you should get a usage message.  How about:
./realpath
Once again, you should get a usage message.

3) You might want to try downloading the source release and running the
build.sh script for you particular machine.   Not being familiar with HP-UX,
I'm not sure if this is an issue, but the release we provide may not be
compatible with your particular hardware??  If this true, I would want to
know about it.  But doing a build on your machine would fix that problem.

Obviously, I am shooting in the dark, but let me know about the above.
I'll give it some more thought as well.

Cheers,
Leif

Stefan Gatz wrote:

>Hi there,
>
>im trying to run the wrapper 3.0.0 on HP-UX 11. When i run the shell script
>i get an error "./wrapper: Execution permission denied".
>
>I have set the execute-flag on the "wrapper" file. 
>All needed files including lib....so, realpath etc. are in the same
>directory
>and have also the execution flag set.
>
>I have no root rights on the machine. Do i need root rights to use wrapper
>on HP-UX ?
>
>Thanks in advance.
>
>STefan
>  
>

[Wrapper-user] Wrapper on HP-UX Problem

[Stefan G. <ste...@da...>]

Hi there,

im trying to run the wrapper 3.0.0 on HP-UX 11. When i run the shell script
i get an error "./wrapper: Execution permission denied".

I have set the execute-flag on the "wrapper" file. 
All needed files including lib....so, realpath etc. are in the same
directory
and have also the execution flag set.

I have no root rights on the machine. Do i need root rights to use wrapper
on HP-UX ?

Thanks in advance.

STefan

Re: [Wrapper-user] How do I wrap a jar file instead of a class?

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

Fred Toth wrote:

> Hi again,
>
> Sorry, my first post to the list and I ended up figuring things out 5 
> minutes
> later. The trick is to dig into the jar file and find the main class, 
> include the
> jar file in your class path and everything else works the same way.
>
> So, it works fine. Is this the best way to go? 

As I just posted. :-)  Yes, that is the way to do it.  Glad you got 
things working.

I made a note to add some documentation on this.  Let me know if there is
anything that doesn't click right away.  Always trying to improve the docs.

Cheers,
Leif

Re: [Wrapper-user] How do I wrap a jar file instead of a class?

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

Fred,
    The Wrapper does not directly support the running of Jar files.  But 
that said, you
can still easily use the wrapper to run you application.  When Java runs 
a jar file, it
does so by looking up the main class using the Manifest file of the Jar. 
 It then
executes that normally.

    So to get your application running with the Wrapper, you will need 
to extract the
contents of the jar file into a temp directory and open the 
META-INF/MANIFEST.MF
If you are using WinZip or something, you may be able to just open the 
jar file as if
it was a Zip file and fire the file from within the jar.
    You should see a line like the following:
Main-Class: {classname}
    Once you have this main class, delete the extracted jar files and 
use the jar as
usual.

    Following the directions on the integration page, you can then use 
this class
as the main class of your application and integrate the app as usual.

    Let me know if you have any problems getting this working.  Probably 
need
to add a note about this in the docs.

Cheers,
Leif

Fred Toth wrote:

> Hi all,
>
> I've just found my way to wrapper and I've got WrapperSimpleApp working
> fine when I am running a class, but what about "java -jar"? I couldn't 
> find
> anything in the examples or doc that addressed this, and I can't quite
> figure out how the java -jar model maps into the config file.
>
> Can anyone point me?
>
> For reference, here's the command I'm trying to wrap (broken into lines
> for viewing). This is Sun's JavaSpaces stuff:
>
> java
> -jar
> -Djava.security.policy=\\server\web_d\javalib\jini\policy\policy.all
> -Djava.rmi.server.codebase=http://192.168.7.106:8080/outrigger-dl.jar
> -Dcom.sun.jini.outrigger.spaceName=djobs
> \\server\web_d\javalib\jini\transient-outrigger.jar
> public
>
> The next to last line is the catch. WrapperSimpleApp expects a class
> and I don't have one!
>
> Any help would be greatly appreciated.
>
> Thanks,
>
> Fred Toth
> ft...@sy...
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:Crypto Challenge is now open! Get 
> cracking and register here for some mind boggling fun and the chance 
> of winning an Apple iPod:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

Re: [Wrapper-user] How do I wrap a jar file instead of a class?

[Fred T. <ft...@sy...>]

Hi again,

Sorry, my first post to the list and I ended up figuring things out 5 minutes
later. The trick is to dig into the jar file and find the main class, 
include the
jar file in your class path and everything else works the same way.

So, it works fine. Is this the best way to go?

Thanks,

Fred Toth

At 09:27 PM 3/13/03 -0500, you wrote:
>Hi all,
>
>I've just found my way to wrapper and I've got WrapperSimpleApp working
>fine when I am running a class, but what about "java -jar"? I couldn't find
>anything in the examples or doc that addressed this, and I can't quite
>figure out how the java -jar model maps into the config file.
>
>Can anyone point me?
>
>For reference, here's the command I'm trying to wrap (broken into lines
>for viewing). This is Sun's JavaSpaces stuff:
>
>java
>-jar
>-Djava.security.policy=\\server\web_d\javalib\jini\policy\policy.all
>-Djava.rmi.server.codebase=http://192.168.7.106:8080/outrigger-dl.jar
>-Dcom.sun.jini.outrigger.spaceName=djobs
>\\server\web_d\javalib\jini\transient-outrigger.jar
>public
>
>The next to last line is the catch. WrapperSimpleApp expects a class
>and I don't have one!
>
>Any help would be greatly appreciated.
>
>Thanks,
>
>Fred Toth
>ft...@sy...
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by:Crypto Challenge is now open! Get 
>cracking and register here for some mind boggling fun and the chance of 
>winning an Apple iPod:
>http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
>_______________________________________________
>Wrapper-user mailing list
>Wra...@li...
>https://lists.sourceforge.net/lists/listinfo/wrapper-user

[Wrapper-user] How do I wrap a jar file instead of a class?

[Fred T. <ft...@sy...>]

Hi all,

I've just found my way to wrapper and I've got WrapperSimpleApp working
fine when I am running a class, but what about "java -jar"? I couldn't find
anything in the examples or doc that addressed this, and I can't quite
figure out how the java -jar model maps into the config file.

Can anyone point me?

For reference, here's the command I'm trying to wrap (broken into lines
for viewing). This is Sun's JavaSpaces stuff:

java
-jar
-Djava.security.policy=\\server\web_d\javalib\jini\policy\policy.all
-Djava.rmi.server.codebase=http://192.168.7.106:8080/outrigger-dl.jar
-Dcom.sun.jini.outrigger.spaceName=djobs
\\server\web_d\javalib\jini\transient-outrigger.jar
public

The next to last line is the catch. WrapperSimpleApp expects a class
and I don't have one!

Any help would be greatly appreciated.

Thanks,

Fred Toth
ft...@sy...

Re: [Wrapper-user] conf question: referencing defined properties

[Mike C. <da...@ix...>]

On Fri, Mar 14, 2003 at 01:00:21AM +0900, Leif Mortenson wrote:
> This is all checked into CVS and lightly tested on both Linux and
> Windows. So
> feel free to check it out and give it a try.


Cool.  Works well.  Least, the simple tests I did under NT.

Hmmm... I don't have MS compilers laying around, so.... I ported this stuff
to MinGW.  Now, since your code uses the MS extentions __try/__catch, and
gcc doesn't support that (instead, a couple of hack defines to allow it
build only), I wouldn't recommend this process for production stuff (unless
you change the code :-).  But, it works well for kicking the tires.

Anyway, I'll attach the patch and the Makefile.mingw I created.  If nothing
else, it's entertaining.  Though, it did point out a few unused variables
and some mis-casts (most likely the API changed out from under you).  So
building against MinGW occasionally isn't necessarily a bad idea.

This should only require MinGW installed, not MSYS.

Do you think you'll be able to release an official version any time soon?
I'd like to switch our product over to it, and would like to use an
official build, if possible.

Some comments on the patch.  no __min/__max in MinGW, and it's not listed
on MSDN, so I moved those around a bit.  It doesn't look like _CRTAPI1 is
needed anymore for services.  At least the current examples on MSDN doesn't
use them, and again, not in MinGW.  I don't think it's necessary.  MSDN
references _flushall(), but not flushall(), so that should be an acceptable
change as well.

Cheers!
mrc [gone till Wednesday]
-- 
     Mike Castle      da...@ix...      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

Re: [Wrapper-user] conf question: referencing defined properties

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

Mike Castle wrote:

>1) Not all .jar files are in the same directory.
>2) Not every .jar file in a directory should be in the startup classpath.
>
>I'm a firm believer in explicitly enumerating everything.
>
You convinced me. I went ahead and got this implemented. Thanks for your
patch. I
did things a little differently do keep the property code simple.

Here is the text from the new documentation:
---
Environment Variable Definition

The Wrapper supports the ability to define environment variables
from within the wrapper.conf file or from the command line. Once
defined, the environment variable can be referenced like any other
environment variable. This includes use in variable expansion as
described above.

Environment variables are defined by using special property names
which begin with "set." followed by the name of the environment
variable. The value of the property will be the value of the new
environment variable.

set.EXTERN_APP=C:/ExternAppHome

The ability to define environment variables make it possible to easily
modify values that may be used throughout a configuration file. The
example below shows how an environment variable can be used to specify
the location of an external application.

set.EXTERN_APP=C:/ExternAppHome
wrapper.java.classpath.1=../lib/wrapper.jar
wrapper.java.classpath.2=%EXTERN_APP%/lib/jar1.jar
wrapper.java.classpath.3=%EXTERN_APP%/lib/jar2.jar
wrapper.java.classpath.4=%EXTERN_APP%/lib/ext/jar3.jar
wrapper.java.classpath.5=%EXTERN_APP%/lib/ext/jar4.jar

The use of environment variables definitions can be very powerful if you
understand how and when their values are set. Environment variables which
were set before the Wrapper is launched can of course be used as usual.
If the same variable name is specified in the configuration file then
the value in the configuration file will override the existing value.

Environment variables defined from the command line work a little
differently. These values will override any values from either the system
or those set in the configuration file. This makes it possible to define
default environment variables within the wrapper.conf file and then
override that value from the command line.

Windows:
Wrapper.exe -c ..\conf\wrapper.conf "set.EXTERN_APP=C:\Program
Files\ExternAppHome"

Unix:
wrapper ../conf/wrapper.conf set.EXTERN_APP=/usr/lib/externapphome

Notice that like all properties set from the command line, properties
which include spaces can be defined by including the entire property name,
value pair in quotes.
---

>>:startup
>>"%_APP_HOME%\bin\Wrapper.exe" -c %_WRAPPER_CONF%
>>wrapper.java.classpath.2=%_MYAPP_HOME%/lib/*.jar
>>    
>>
>Took me a while to figure out that had gotten word wrapped.  :-/
>
Sorry about that. :-)

This is all checked into CVS and lightly tested on both Linux and
Windows. So
feel free to check it out and give it a try.

Cheers,
Leif

Re: [Wrapper-user] conf question: referencing defined properties

[Mike C. <da...@ix...>]

On Wed, Mar 12, 2003 at 11:42:10AM -0800, Mike Castle wrote:
> If you like this approach I can probably whip up a patch later today.

Well, here it is attached.

It's a bit bigger than I'd like, but the wrapper_win32.c is a bit of a mess
and resulted in a lot of re-indentation.

Anyway, this adds the ability to use %foo% style stuff for anything.
Precedence is command line options, environment variables, then file
contents.  I'm not convinced that an enviroment variable should take
precedence of a value specified in .conf, but a simple rearrangement in the
enum will fix that.  I suppose if you're really masochistic, you could
change the references to PP_ENV and PP_FILE to something like:

getBooleanProperty(properties, "wrapper.property.env.first", TRUE)?PP_ENV:PP_FILE
and
getBooleanProperty(properties, "wrapper.property.env.first", FALSE)?PP_ENV:PP_FILE

Anyway, this patch also gives you the ability to set enviroment variables
from the .conf file.

FOO=This is foo
wrapper.env.export.1=FOO

You can even get fancy:

FOO=This is foo
BAR=This is bar
BAZ=FOO
wrapper.env.export.1=%BAZ%

With the current implementation, set FOO to something like "This is foo
from the environment" and use the above, and that will be exported again.
Or more likely, export BAZ=BAR and observe the output.

I didn't build the win32 stuff, no MS compiler.  Sorry if it doesn't
compile.  But I did try to keep it logically similar to the unix side.

Useful?
mrc
-- 
     Mike Castle      da...@ix...      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

Re: [Wrapper-user] conf question: referencing defined properties

[<da...@ix...>]

In article <3E6...@ta...>,
Leif Mortenson  <wra...@li...> wrote:
>Mike,
>I think you can solve your current problem by doing the following:
>
>1) As I said in my previous post. Define all of the elements of your
>classpath into a
>single property like this:
>---
>wrapper.java.classpath.2=C:/installation1/lib/*.jar

1) Not all .jar files are in the same directory.
2) Not every .jar file in a directory should be in the startup classpath.

I'm a firm believer in explicitly enumerating everything.

>:startup
>"%_APP_HOME%\bin\Wrapper.exe" -c %_WRAPPER_CONF%
>wrapper.java.classpath.2=%_MYAPP_HOME%/lib/*.jar

Took me a while to figure out that had gotten word wrapped.  :-/

>The only way to make this work is to pass through the command line
>properties twice. Once before the conf file is loaded and once after.
>The environment variables would be handled on the first pass and all
>others would be handled on the second. Not very pretty, but unless
>I can think of another way to do this without breaking the conf files
>of existing users, it is the way it would have to be done.

Priority queues/heaps/heirarchial properties.

Have two classes of properties:  those set by CLI, those set by FILE.
Within a class, the last value always takes precedence.  However, when
reading a value, check CLI first, and if none exists, use FILE.

Actually, you could do three classes: ENV, CLI, FILE.

First, load all envvar into class ENV.  Then load all command line
parameters into class CLI.  Load properties from .conf into FILE as they
are encountered.

Whenever you use a property, first check class CLI, then FILE, then ENV.
And have the %foo% syntax reference a property instead of only an
environment variable.  Well, ok always CLI first, but I could see arguments
for going either way on FILE vs ENV next.

Hmmm.   Looking at the code, this shouldn't be too hard (I've done this
type of thing before :-).  Looks like the only things that would need to be
changed would be getInnerProperty(), evaluateEnvironmentVariables(),
setInnerProperty(), addProperty(), addPropertyPair().  Then add a bit of
code to walk the envvar list and add those, move the command line loading
further up in the program, and done.  Well, modulo any bugs of course.

Ack!  Why are you casting malloc?  You're not using a C++ compiler are you?
For shame!

Hmmm.  One could even somewhat easily add in support for exporting
environment variables.  Something like wrapper.env.export.N=envvarname

So one could do something like:

app_home=something_of_interest

wrapper.java.classpath.X=%app_home%/lib/foo.jar

wrapper.env.export.Y=app_home

That support could pretty easily be added to
wrapperBuildJavaCommandArrayInner(), though making it it's own function
would be nicer (no since making a really long function longer).

Hmmm... it doesn't look like all properties are automatically passed to the
java process.  Is that correct?  (Again, I'm thinking about ant where that
is an option, and making sure I'm not getting confused about my
applications).

If you like this approach I can probably whip up a patch later today.

mrc
-- 
     Mike Castle      da...@ix...      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

Re: [Wrapper-user] conf question: referencing defined properties

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

Mike,
I think you can solve your current problem by doing the following:

1) As I said in my previous post. Define all of the elements of your
classpath into a
single property like this:
---
wrapper.java.classpath.2=C:/installation1/lib/*.jar
---
This by itself will reduce the number of places that must be changed
down to one.

2) You can further clean things up as follows:
Change the above classpath entry to the following as a note:
---
# The following is defined from the command line:
#wrapper.java.classpath.2=%MYAPP_HOME%/lib/*.jar
---
Then modify the InstallApp-NT.bat and App.bat scripts as follows:
---
@echo off
rem
rem Find the application home.
rem
if "%OS%"=="Windows_NT" goto nt

echo This is not NT, so please edit this script and set _APP_HOME manually
set _APP_HOME=..

goto conf

:nt
rem %~dp0 is name of current script under NT
set _APP_HOME=%~dp0
rem : operator works similar to make : operator
set _APP_HOME=%_APP_HOME:\bin\=%


rem
rem Verify MYAPP_HOME
rem
:conf
set _WRAPPER_CONF="%_APP_HOME%\conf\wrapper.conf"

set _MYAPP_HOME="%~f1"
if not %_MYAPP_HOME%=="" goto startup

echo Usage:
echo App.bat {Application home}
goto end


rem
rem Run the application.
rem At runtime, the current directory will be that of Wrapper.exe
rem
:startup
"%_APP_HOME%\bin\Wrapper.exe" -c %_WRAPPER_CONF%
wrapper.java.classpath.2=%_MYAPP_HOME%/lib/*.jar
if not errorlevel 1 goto end
pause

:end
set _APP_HOME=
set _WRAPPER_CONF=
set _MYAPP_HOME=
---
You can no longer specify the conf file from the command line, but it
should work
for you.

Will this work? or do you still feel that the ability to set environment
variables
are needed? There have been a few people who requested the ability to set
environment variables in the past, but there have always been other ways to
do what they want.

I have avoided doing it up until now because of problems that arise with the
setting of properties from the command line. Let me know if the above solves
your problem, and either way, I will give this some more thought.

My current thinking is to do something like:
set_env.APP_HOME=/usr/lib/apphome
Where APP_HOME is created with the value of /usr/lib/apphome
This would then become an actual environment variable so a new syntax
for their expansion in other properties would not be needed.

The problem is how to handle this on the command line. Currently, properties
take the last value set. So the command line properties are set last. In the
case of the environment variables, they would need to be set first. My
first
thought was to make the property values sticky so that their first value
would
be maintained, then set the command line properties first. But the
problem with
that is that it would break things for existing users, especially those
using include
files to override defaults set elsewhere in the conf file.

The only way to make this work is to pass through the command line
properties twice. Once before the conf file is loaded and once after.
The environment variables would be handled on the first pass and all
others would be handled on the second. Not very pretty, but unless
I can think of another way to do this without breaking the conf files
of existing users, it is the way it would have to be done.

Cheers,
Leif

Mike Castle wrote:

>In article <3E6...@ta...>,
>Leif Mortenson  <wra...@li...> wrote:
>  
>
>>I am not sure I am grasping what it is you want to do. At what point do
>>you want the
>>replacements to happen? At run time? If so, what is the difference
>>between what you
>>are asking for and an environment variable?
>>    
>>
>
>At run time.
>
>Ok, lets say I am distributing a product that has a file that has
>something like this:
>
>wrapper.java.classpath.1=../lib/wrapper.jar
>wrapper.java.classpath.2=%MYAPP_LIB%/Utils.jar
>wrapper.java.classpath.3=%MYAPP_LIB%/Engine.jar
>...
>wrapper.java.classpath.25=%MYAPP_LIB%/Help.jar
>
>Now, let's say the user has 3 different installations in different
>directories doing different things.
>
>Well, I have to go into the conf files and search and replace MYAPP_LIB
>with MYAPP_LIB_1, and MYAPP_LIB_2.  I might as well not bother with
>environment variables then.
>
>But, instead, if I could do something like:
>
>MYAPP_LIB=C:\installation1\....\lib
>
>wrapper.java.classpath.1=../lib/wrapper.jar
>wrapper.java.classpath.2=${MYAPP_LIB}/Utils.jar
>wrapper.java.classpath.3=${MYAPP_LIB}/Engine.jar
>...
>wrapper.java.classpath.25=${MYAPP_LIB}/Help.jar
>
>Then I only have to modify one line in each file.  This is less prone to
>error, could even be constrained to a #include <location.conf> type of
>file, that would limit what a user has to modify down to one file that has
>just a couple of lines.
>
>In a unix implementation, I could just do something like have the init
>script set up different environment variables for each installtion (well, I
>think, I've not actually used wrapper there, yet).  But I don't have that
>option with NT services.  I'd like to keep the .conf files that I
>distribute as pristine as possible, only having to change a couple of lines
>(or, as I pointed out, an include file would be better).
>
>I'm certainly not set on the ant-like syntax, I just figured it was something
>common enough to be a good example.
>
>mrc
>  
>

[Wrapper-user] Re: Apache Launcher and Java Service Wrapper

[<da...@ix...>]

In article <3E6...@ou...>,
Richard Emberson  <wra...@li...> wrote:
>The launcher is basically and Ant task that knows how to launch
>a Java JVM subprocess allowing for the setting of system properties,
>class paths, arguments, etc.

I'm already doing this in one case by having wrapper launch ant which
launches an app (We're not done integrating everything yet, so need a 20
second or so start up delay which ant provides with it's <sleep/> task).

>With the launcher, the wrapper.conf "template" file is always the same,
>it simply calls on the launcher code passing in the name of the
>launcher.xml file. This file name is all that needs to change to
>call a different Java application (so it is parameterized - see
>include example).

Still, I'd rather avoid the extra layer if possible.

Still, I guess I should take the Unix tenet of "do one thing and do it
well" a bit more to heart.

>Java Service Wrapper is best at managing a Java application.
>Apache commons-launcher is best a launching a Java application.

>The next step for Java Service Wrapper is the registering of the
>wrapper on unix system so that on reboot the Java application
>starts.

Well, in theory, on systems that use SysV style init scripts, you should be
able to get away with linking results of sh.script.in into the appropriate
run level.  Of course, I believe that some systems, (AIX?) completely
rebuild those directories from scratch upon boot using a database.  And of
course, how to register is HIGHLY system dependent.  Heck, even among the
Linux distributions, init scripts don't end up in the same directory, or
use the same style!  I do think that this is more in the realm of a system
specific package tool.

mrc
-- 
     Mike Castle      da...@ix...      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

Re: [Wrapper-user] conf question: referencing defined properties

[<da...@ix...>]

In article <3E6...@ta...>,
Leif Mortenson  <wra...@li...> wrote:
>I am not sure I am grasping what it is you want to do. At what point do
>you want the
>replacements to happen? At run time? If so, what is the difference
>between what you
>are asking for and an environment variable?

At run time.

Ok, lets say I am distributing a product that has a file that has
something like this:

wrapper.java.classpath.1=../lib/wrapper.jar
wrapper.java.classpath.2=%MYAPP_LIB%/Utils.jar
wrapper.java.classpath.3=%MYAPP_LIB%/Engine.jar
...
wrapper.java.classpath.25=%MYAPP_LIB%/Help.jar

Now, let's say the user has 3 different installations in different
directories doing different things.

Well, I have to go into the conf files and search and replace MYAPP_LIB
with MYAPP_LIB_1, and MYAPP_LIB_2.  I might as well not bother with
environment variables then.

But, instead, if I could do something like:

MYAPP_LIB=C:\installation1\....\lib

wrapper.java.classpath.1=../lib/wrapper.jar
wrapper.java.classpath.2=${MYAPP_LIB}/Utils.jar
wrapper.java.classpath.3=${MYAPP_LIB}/Engine.jar
...
wrapper.java.classpath.25=${MYAPP_LIB}/Help.jar

Then I only have to modify one line in each file.  This is less prone to
error, could even be constrained to a #include <location.conf> type of
file, that would limit what a user has to modify down to one file that has
just a couple of lines.

In a unix implementation, I could just do something like have the init
script set up different environment variables for each installtion (well, I
think, I've not actually used wrapper there, yet).  But I don't have that
option with NT services.  I'd like to keep the .conf files that I
distribute as pristine as possible, only having to change a couple of lines
(or, as I pointed out, an include file would be better).

I'm certainly not set on the ant-like syntax, I just figured it was something
common enough to be a good example.

mrc
-- 
     Mike Castle      da...@ix...      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

[Wrapper-user] Apache Launcher and Java Service Wrapper

[Richard E. <rem...@ou...>]

I believe that a technology the is complementary to Java
Service Wrapper is the Apache commons-launcher code:

http://jakarta.apache.org/builds/jakarta-commons/release/commons-launcher/

The launcher is basically and Ant task that knows how to launch
a Java JVM subprocess allowing for the setting of system properties,
class paths, arguments, etc.

With the launcher, the wrapper.conf "template" file is always the same,
it simply calls on the launcher code passing in the name of the
launcher.xml file. This file name is all that needs to change to
call a different Java application (so it is parameterized - see
include example).

Java Service Wrapper is best at managing a Java application.
Apache commons-launcher is best a launching a Java application.

The next step for Java Service Wrapper is the registering of the
wrapper on unix system so that on reboot the Java application
starts.

Richard

Re: [Wrapper-user] conf question: referencing defined properties

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

I am not sure I am grasping what it is you want to do. At what point do
you want the
replacements to happen? At run time? If so, what is the difference
between what you
are asking for and an environment variable?

If you are talking about at build time, then you can easily do the
replacements as part
of the ant build. Simply use the syntax "@java.home@" and then apply
filters to the file
when you copy it. I usually have a src/conf/wrapper.conf.in file which I
use as a source
for this purpose.

As for the exact case of your classpath, the Wrapper will expand wild
cards at run time
so you should not have to list up every single jar in the wrapper.conf
file. Do something
like this:

wrapper.java.classpath.1=c:/myapp/lib/*.jar

That still has a fixed path however, to clean things up further, try
using relative paths.
Assuming that the wrapper.exe is located in a c:/myapp/bin directory,
the above can
be changed to:

wrapper.java.classpath.1=../lib/*.jar

This will now work at install location, and on any platform.

Let me know if I missed what you were asking for.

Cheers,
Leif

Mike Castle wrote:

>Ala ant, would it be possible to support arbitrary properties in the .conf
>files.  For example:
>
>java.home=C:\path\to\jre
>wrapper.java.command=${java.home}/bin/java.exe
>
>The reason is, I'd like to be able to parameterize some things quite
>easily in the config file with OUT having to use environment variables,
>because I may have multiple installations of the same app, with different
>application level config files, but I'd like to have to not modifiy
>the wrapper .conf files any more than necessary.  In my case, I have
>something like 25 jars in the classpath.  And I'd like to make the top
>level directories a parameter that I can edit on one line, rather than
>having to use search/replace in an editor to change all 25.
>
>Is this scheme possible in a future version?
>
>I've not yet looked at the code myself to see if I could add it easily
>enough, figure I'd ask the expert first.  ;->
>
>mrc
>  
>

[Wrapper-user] conf question: referencing defined properties

[<da...@ix...>]

Ala ant, would it be possible to support arbitrary properties in the .conf
files.  For example:

java.home=C:\path\to\jre
wrapper.java.command=${java.home}/bin/java.exe

The reason is, I'd like to be able to parameterize some things quite
easily in the config file with OUT having to use environment variables,
because I may have multiple installations of the same app, with different
application level config files, but I'd like to have to not modifiy
the wrapper .conf files any more than necessary.  In my case, I have
something like 25 jars in the classpath.  And I'd like to make the top
level directories a parameter that I can edit on one line, rather than
having to use search/replace in an editor to change all 25.

Is this scheme possible in a future version?

I've not yet looked at the code myself to see if I could add it easily
enough, figure I'd ask the expert first.  ;->

mrc
-- 
     Mike Castle      da...@ix...      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc