tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Luby <patrick.l...@sun.com>
Subject Re: [5] launcher/deamon
Date Tue, 06 Aug 2002 15:35:08 GMT
Scott,

All of your suggestions make sense (I actually used javaw.exe in 
commons-launcher to run background processes). The real problem that I 
keep running into is getting the application classes into the classpath 
when the %0 problem is encountered on Windows 95, 98, ME, and sometimes 
2000.

When that happens, you cannot construct a classpath of jars relative to 
%0 because %0 contains no path. This is a really annoying bug in DOS. 
So, how do you find JPython's jars when this situation occurs?

The workaround I found was to not bother creating a classpath in script 
and, instead, merely invoke a bootstrap class that is in the same 
directory as the script. Then, even with the %0 problem, I could always 
find the bootstrap class using the following classpath argument:

   %0\..;"%PATH%"

This works because the %0 problem only occurs when Windows searches your 
%PATH% to find the script. So, we can be assured that if %0\.. resolves 
to nothing meaningful, we will fall back to the same search mechanism 
for the bootstrap class file that Windows used to find the script.

Of course, there is one catch. All of the classpath and other path 
related stuff that was in the script needs to be moved into the 
bootstrap class. For example, the setting of the application's classpath 
is done in the bootstrap class using a classloader and paths to jars or 
other application resources are calculated relative to the path that the 
bootstrap class was loaded from.

Moving this from the script to the bootstrap class is not a bad thing, 
however. This is because the bootstrap class handles all of the stuff in 
the scripts in a platform independent manner which means less maintenance.

In other words, the scripts get really simple.

Patrick

Scott Stirling wrote:
> I thought WSH (Windows Scripting Host) was standard on most Windows.
> Yeah, maybe not Win9x.  And 5.6, the latest, is not on NT 4 or Win2K by
> default -- you have to upgrade.  Painless process, but adds a step.
> 
> What about beanshell for a small scripting environment?  Or Jython?
> Check out this article:
> 
> Java scripting languages: Which is right for you?
> http://www.javaworld.com/javaworld/jw-04-2002/jw-0405-scripts.html
> 
> Sun and IBM JDK's come with a javaw.exe for starting windowless Java
> applications.
> 
> Redirecting stderr and stdout can be done from Java, right?  Doesn't
> have to be done in the shell script.
> 
> Scott Stirling
> 
> 
>>-----Original Message-----
>>From: Patrick Luby [mailto:patrick.luby@sun.com] 
>>
>>Kevin,
>>
>>Kevin Jones wrote:
>>
>>>Just a FYI
>>>
>>>
>>>
>>>>1. Make Tomcat 5 startup reliably on Windows (Windows batch
>>>>scripts are
>>>>   notoriously flaky).
>>>
>>>
>>>So don't use the (crap) .bat/.cmd syntax. Remember that Windows 
>>>supports 'real' scripting languages for the shell. You could use 
>>>JScript of vbscript and use the Windows scripting host (I'm pretty 
>>>sure there's even a Perl version available although that's not 
>>>installed by default).
>>>
>>
>>I think that is an idea worth explorer. VBScript would be 
>>nice but it is 
>>not installed on all Windows versions. As for others, I would lean 
>>towards finding a shell that is very small in footprint that we could 
>>ship with an application. Perl is redistributable but fairly 
>>large but 
>>maybe a very minimal version can be compiled.
>>
>>The other idea is to use Costin's idea of a C executable that 
>>replaces 
>>the very litle bit of scripting that is left in the *.bat files. The 
>>only downside is that the build would require native compilation.
>>
>>
>>>
>>>>2. Emulate the Unix startup on Windows (Windows has no "&" 
>>>
>>background
>>
>>>>   operator like Unix and you cannot redirect stderr to an
>>>>output file)
>>>
>>>
>>>Doesn't 'start' do this, oh and you can redirect stderr (2> 
>>
>>or 2>> I 
>>
>>>think is what you want)
>>>
>>
>>"start" just creates another DOS window which means your GUI 
>>or server 
>>application is still bound to a DOS window. As for 2>, I don't think 
>>that this works in DOS. AFAIK, 2> on works in sh and bash 
>>shells. Even 
>>if stderr can be redirected, you still get an empty DOS 
>>window hanging 
>>around that the process is attached to.
>>
>>
>>>>3. Run background applications (like Tomcat 5 or GUI applications)
>>>>   without a DOS shell on Windows.
>>>
>>>
>>>See above
>>
>>My goal was to get rid of unnecessary DOS windows for non-console 
>>applications. "start" does not do this.
>>
>>
>>>
>>>>4. Eliminate maintainance of 2 sets of scripts (one set for
>>>>Windows and
>>>>   one set for Unix).
>>>
> 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>

-- 
________________________________________________________________
Patrick Luby                     Email: patrick.luby@sun.com
Sun Microsystems                         Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
________________________________________________________________


--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message