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

[Wrapper-user] org.apache.jasper.JasperException: Unable to compile class for JSP?

[Guofeng Z. <guo...@vi...>]

I install my app as a NT service according the instruction of Method 1 =
in Integration Methods.  It works.=20

I stop the service and then re-start it by Services panel in Windows' =
Control setting. Then I use the IE browser to access the app, I get a =
white page, the error message in Jboss's log is Unable to compile class =
for JSP.

The app works fine when it is not installed as a service. I think I =
might not configure the wrapper properly.

Could any one point out what's wrong with the configuration? Thanks.


The Environemnt is:
         Windows 2000 Professional SP3.
         Jboss-3.0.4_Tomcat-4.1.12
         j2sdk1.4.2_01
        Java Service Wrapper 3.0.5

Tthe following is the part of the wrapper.conf:

# Java Application
wrapper.java.command=3D../../j2sdk1.4.2_01/bin/java
wrapper.java.additional.1=3D-Dprogram.name=3Drun.bat
wrapper.java.classpath.1=3D./../lib/wrapper.jar
wrapper.java.classpath.2=3D../../j2sdk1.4.2_01/lib/tools.jar
wrapper.java.classpath.3=3D./run.jar
wrapper.java.library.path.1=3D../lib
wrapper.java.mainclass=3Dorg.tanukisoftware.wrapper.WrapperSimpleApp
wrapper.app.parameter.1=3Dorg.jboss.Main
wrapper.app.parameter.2=3D-c
wrapper.app.parameter.3=3Ddefault

# Java Additional Parameters
wrapper.java.additional.1=3D-server

# Initial Java Heap Size (in MB)
wrapper.java.initmemory=3D256

# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=3D384

Re: [Wrapper-user] mbean nativeRequestThreadDump

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

Richard,
    I tested this on both Linux and Windows using the -Xrs flag.   In 
both cases, the JVM
halts immediately without executing any shutdown hooks when you request 
a thread dump.
That's not good.  But there is nothing I can do about it. I'll add a 
note to the documentation
about it though.

    You were seeing something slightly different, but that may be due to 
the exact JVM you
are using.  Have you had a chance to try this out removing the -Xrs flag?

Cheers,
Leif


Richard Emberson wrote:

> I do launch the java with the flag '-Xrs'; maybe that
> prevents the signal from being seen.
>
> Richard
>
>
> Leif Mortenson wrote:
>
>> Richard,
>>    It sounds like you are doing things correctly.  I retested this 
>> today using JBoss and
>> Java 1.4.2_01 but everything appears to be working correctly.   I 
>> tried the JMX interface
>> while running in both console mode and running as an NT service.
>>    The thread dump will be dumped to both the console and wrapper.log 
>> file at the INFO
>> level.
>>    When running in console mode are you able to invoke a thread dump 
>> using
>> CTRL-BREAK on Windows or CTRL-\ on UNIX.   On unix, you should also be
>> able to invoke a thread dumb executing the wrapper script used to 
>> launch the application
>> with the dump command.
>>    I'll test this out on Linux tonight as that may be what you are 
>> running?
>>
>> Cheers,
>> Leif
>>
>>> So I've got 3.0.5 running with my jboss application. I set
>>> wrapper.debug=true, just to see whats happening.
>>> I get printout that the native library was loaded...
>>>
>>>
>>> INFO   | jvm 1    | 2003/09/16 08:55:12 | Calling native 
>>> initialization method.
>>> INFO   | jvm 1    | 2003/09/16 08:55:12 | Inside native 
>>> WrapperManager initialization method
>>> INFO   | jvm 1    | 2003/09/16 08:55:12 | Java Version   : 1.4.2-b28 
>>> Java HotSpot(TM) Client VM
>>> INFO   | jvm 1    | 2003/09/16 08:55:12 | Java VM Vendor : Sun 
>>> Microsystems Inc.
>>> INFO   | jvm 1    | 2003/09/16 08:55:12 |
>>> INFO   | jvm 1    | 2003/09/16 08:55:12 | Wrapper (Version 3.0.5)
>>> INFO   | jvm 1    | 2003/09/16 08:55:12 |
>>> INFO   | jvm 1    | 2003/09/16 08:55:12 | Open socket to wrapper...
>>> INFO   | jvm 1    | 2003/09/16 08:55:12 | Opened Socket
>>> INFO   | jvm 1    | 2003/09/16 08:55:12 | Send a packet KEY : 
>>> XGuDK_MTRJ8iZjZ3
>>> etc......
>>>
>>> I start getting debug printout:
>>>
>>> DEBUG  | wrapperp | 2003/09/16 08:56:35 | send a packet PING : ping
>>> INFO   | jvm 1    | 2003/09/16 08:56:35 | Received a packet PING : ping
>>> INFO   | jvm 1    | 2003/09/16 08:56:35 | Send a packet PING : ok
>>> DEBUG  | wrapperp | 2003/09/16 08:56:35 | read a packet PING : ok
>>> DEBUG  | wrapper  | 2003/09/16 08:56:35 | Got ping response from JVM
>>> DEBUG  | wrapperp | 2003/09/16 08:56:41 | send a packet PING : ping
>>>
>>> but when I press 'invoke' on the methods requestThreadDump
>>> on the jmx mbean page for the wrapper nothing happens.
>>> Well, I do advance to a followup jboss web page, but there is
>>> no thread dump. Not on the web page or any of the logs. In fact,
>>> the debug information in the native (linux) method
>>> Java_org_tanukisoftware_wrapper_WrapperManager_nativeRequestThreadDump
>>> does not print.
>>>
>>> No errors, no nothing. Where is the thread dump output suppose to
>>> go?
>>>
>>> Thanks.
>>>
>>>
>>> Richard
>>

Re: [Wrapper-user] Sockets and desktop

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

Alex,
    I am not sure that your assumption about not being able to use Sockets
and a GUI in the same service is correct.   The TestWrapper example
that is shipped with version 3.0.5 of the Wrapper does both and works
just fine.

    Edit wrapper.conf and set the following 
wrapper.ntservice.interactive=true
at the bottom of the file.   Then install the TestWrapper as a service 
and start
it.
InstallTestWrapper-NT.bat
net start testwrapper

    Now telnet to the machine on port 9999.  When it connects, type 'R'  
Must
be upper case.  The Wrapper will promptly restart the JVM..  All works fine
both using localhost and from a remote machine.

    The problems you are having with your users is a little more 
difficult.   Unless you
specify an account in the wrapper.conf file, NT services will by default 
always run
as the SYSTEM user.   This is also true for their child processes (Java 
in this case)
So no matter how many times you check, your user is always going to be
SYSTEM.   You are going to need to have an application running in the 
User space
which is launched when the user logs in.  This component could then 
communicate to
the service using any of a number of methods.

    There is not any way that I am aware of for an NT service to tell 
when a user logs
in to the system.   It sounds like it should be possible, but not with 
the current Wrapper.

    Telling when the user logs out is easy.  Windows sends a logout 
signal to all processes
when any user logs out.  The Wrapper intercepts this and prevents the 
Wrapper and its
JVM from exiting.  The WrapperSimpleApp and WrapperStartStopApp classes 
do not
provide a way for your java app to see this signal, but you can see it 
if you use method
3, by implementing the WrapperListener interface directly.  The 
listener's controlEvent
method is called whenever any system signals are received.  This gives 
the app the
opportunity to respond.

    I posted a couple of feature requests around this so I remember to 
look into ways
of making it possible to tell when and who logs in.
http://sourceforge.net/tracker/index.php?func=detail&aid=812174&group_id=39428&atid=425190
http://sourceforge.net/tracker/index.php?func=detail&aid=812175&group_id=39428&atid=425190

Cheers,
Leif



ender wiggin wrote:

>Hello.
>
>First some details:
>I am working on a project involving an instant one way
>messaging on windows. Basically I am writing a
>service(SocketService) that connects with a server
>through a socket and writes to file/(some repository)
>the messages it receives. Another service( 
>DesktopMessageService) reads from the files the
>messages and if it finds a new message for the CURRENT
>user it will open a frame and show it on the screen. 
>The reason I use two services instead of one is
>because I read that a service either does neworking or
>it accesses the desktop or console. 
> The SocketService performs well, it does indeed read
>from a socket(ServerSocket) and when contacted there
>are messages it does store them on file. 
>
>The problems arise with the DesktopMessageService.I
>have yet to find a way to detect the current
>user.Basically when the pc is booted the
>DesktopMesssage starts ,tries to detect the current
>user and print to screen a message.The problem is that
>
>I cannot decect when a user loggs on to the machine.
>The current user for the DesktopService is still 
>System.So if I want to print a message Hi +
>System.getProperty("user.name") , even if there is a
>user logged on it still prints Hi System , not Hi
>"Current User Name".Im also tried to restart the JVm
>periodically but the curent user is still System.
>By the way the service works fine when tested in a
>console .
>
>So my questions are, Is there a way to detect when a
>user loggs on and get his name?
>Also, is there a way to detect when a users logs off?
>
>Thanks, Alex
>  
>

Re: [Wrapper-user] No args wrapper startup

[Jim R. <jr...@er...>]

Leif,

On 2003.09.24 20:12, Leif Mortenson wrote:
>    What is wrong with having your users double click on a batch file?

I think that it's mainly a personal preference.  It's just slicker to 
have the application start from a "real" executable rather than a batch 
file.

We do have all sorts of fun with console windows when starting with a 
batch file.

There are a some things we do (notably wrapping COM servers) that 
require an executable, not a batch file, but we could work around that.

> That is what most Java applications do and what you would have to do 
> if not using the Wrapper.

It's what we have been doing, and we want to get away from it.

> Making the Wrapper work without any command line arguments would 
> require building a custom binary for each application.  That is how 
> some other tools worked which allowed a java app to be run as an NT 
> service.  One of the many goals of the Wrapper was to make the 
> Wrapper usable without requiring the user to even get close to any C 
> code.

The changes I've been making here will make the default startup 
equivelent to:

appname.exe -c appname.wrapper

So you can rename the wrapper.exe to acheive a no-args startup - no C 
coding required.  I seem to be the only person interested in this which 
is OK (and the beauty of OpenSource).  I'd be happy to send back a 
patch, but if it's just for me I'll just fake the args, which is pretty 
much a hack - so you probably wouldn't want to apply it.

> Jim Redman wrote:
> 
>> I'd like to use the wrapper to start a console application.  But I 
>> need a single executable that the user can click on, that is, no 
>> args passed to the application.
>> 
>> Is this possible without modifications to the c source?
>> 
>> If not, is anyone else interested in this?  My idea would be to have 
>> double-clicking on app.exe be the same as "app -c app.conf" if app.
>> conf exists.  Jim
>> 
>> PS Apologies if this is a repeat - I didn't get a copy of the 
>> original and it's not in the archive.
>> 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
-- 

Jim Redman
(505) 662 5156 x85
http://www.ergotech.com

Re: [Wrapper-user] JSP Compiling Error When Starting JBoss Using Wrapper

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

Bin Duan,
    I was not clear from you later posts, but were you able to get this 
working correctly?
As Sal said, these problems are usually caused by the tools.jar file 
missing from your
classpath.   However, I see that you have specified it in the classpath 
in your
wrapper.conf.  Other than verifying the location of the tools.jar file, 
try looking for any
other hints in other log files.

Leif

Bin_Duan/Cla...@cl... wrote:

>We'd like to start JBoss currently hosting our J2EE application using
>Wrapper. I followed the step-by-step instruction from the website to setup
>JBoss wrapper. And the JBoss started up fine, but when I tried to access
>our application, I got an error indicating unable to compile class for JSP
>as follows:
>
>org.apache.jasper.JasperException: Unable to compile class for JSP
>             at
>org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:479)
>
>             at
>org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:184)
>
>             at
>org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
>             at
>org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
>             at
>javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>             at
>org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
>
>             at
>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
>  
>

Re: [Wrapper-user] Wrapping COM Server

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

Jim,
    I'll be honest and claim absolutely no knowledge of Windows COM.  I 
am thus fairly
sure that I am not doing anything intentionally which should be helping 
or hindering your
ability to use COM with the Wrapper.  That said, though, as I am not 
doing anything to
make COM work, it is entirely possible that something is being done to 
unintentionally
break it.   I'll be happy to apply any patches that you come up with to 
get things
working.

Sorry not much help on this question,
Leif

Jim Redman wrote:

> Georg,
>
> We're wrapping an OPC (http://www.opcfoundation.org) server and no OPC 
> client is running.  The iMarshal query is associated (somehow) with 
> the wrapper.
>
> I checked the source to see if I could find anything COM related 
> there, but didn't find anything.  But I could have missed something.
>
> It is also, perhaps, something to do with service managment, but in 
> this case I was running as a console application.
>
> Jim

Re: [Wrapper-user] Fwd: RE: No args wrapper startup [jredman@ergotech.com]

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

Jim,

> Beyond the obvious observation that batch files are ugly, we have at 
> least on sitution where a batch file will not work.  The OPC standard, 
> which we support, mandates that one of the registry keys associated 
> with an application is an executable, not a batch file.
>
> In our case, it is the end users choice whether to install a service 
> or not.  For some customers the applications will not run as a 
> service, the application will grab the executable from the registry 
> and run it and check that the application is still alive.  Others want 
> a service.   Some want a real user interface, etc. etc. Hence the 
> attraction of the wrapper, it does all these things.

When the wrapper is installed as an NT service, it no longer uses the 
batch file.  The Wrapper
installs an entry in the registry which points directly to the 
Wrapper.exe.  The full entry looks
like this:
 c:\fullpath\bin\Wrapper.exe -s ..\conf\wrapper.conf
It sounds to me like if your tool is pulling the exe name out of the 
registry to run in console
mode, you should be able to do something similar by specifying the 
following in the registry
 c:\fullpath\bin\Wrapper.exe -c ..\conf\wrapper.conf

Cheers,
Leif

Re: [Wrapper-user] No args wrapper startup

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

Jim,
    What is wrong with having your users double click on a batch file?  
That is what most
Java applications do and what you would have to do if not using the 
Wrapper.  Making
the Wrapper work without any command line arguments would require 
building a custom
binary for each application.  That is how some other tools worked which 
allowed a java
app to be run as an NT service.  One of the many goals of the Wrapper 
was to make the
Wrapper usable without requiring the user to even get close to any C code.

    Cheers,
    Leif

Jim Redman wrote:

> I'd like to use the wrapper to start a console application.  But I 
> need a single executable that the user can click on, that is, no args 
> passed to the application.
>
> Is this possible without modifications to the c source?
>
> If not, is anyone else interested in this?  My idea would be to have 
> double-clicking on app.exe be the same as "app -c app.conf" if 
> app.conf exists.  Jim
>
> PS Apologies if this is a repeat - I didn't get a copy of the original 
> and it's not in the archive.
>

Re: [Wrapper-user] Regarding the service

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

Sal Ingrilli wrote:

> you don't need the service wrapper.
>  
> just use the windows/unix scheduler to schedule execution of a batch 
> file that runs your program

UNIX has cron jobs, but what exists on Windows.  I had actually looked 
for something a
while back and was only able to locate a few overpriced commercial 
solutions.   I ended
up having the Java program running 24x7, but with its main thread in a 
wait state until the
time that the actual job needed to run.

Doing a google search on "Windows Scheduler" turns up several options 
now.  A couple
have free versions as well.

Leif

RE: [Wrapper-user] Regarding the service

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

you don't need the service wrapper.

just use the windows/unix scheduler to schedule execution of a batch file
that runs your program

  -----Original Message-----
  From: wra...@li...
[mailto:wra...@li...]On Behalf Of Suchetha
Ravishankar
  Sent: Wednesday, September 24, 2003 2:10 PM
  To: wra...@li...
  Subject: [Wrapper-user] Regarding the service


  Hi all,

  I have a Java application which searches for some strings in a log file.I
want to install this as a service and I want to execute this service
everyday at 18.00 hours only once. Is it possible, please help. Thanks in
advance.
  Regards,
  Ravi

[Wrapper-user] Regarding the service

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

Hi all,

I have a Java application which searches for some strings in a log =
file.I want to install this as a service and I want to execute this =
service everyday at 18.00 hours only once. Is it possible, please help. =
Thanks in advance.
Regards,
Ravi

RE: [Wrapper-user] JSP Compiling Error When Starting JBoss Using Wrapper

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

i was talking about 1.3
i should have mentioned it.
thanks for clarifying it.


-----Original Message-----
From: wra...@li...
[mailto:wra...@li...]On Behalf Of Mike
Castle
Sent: Wednesday, September 24, 2003 9:45 AM
To: wra...@li...
Subject: Re: [Wrapper-user] JSP Compiling Error When Starting JBoss
Using Wrapper


In article <014501c38230$ec847290$6502a8c0@fs1>,
Sal Ingrilli <wra...@li...> wrote:
>note that sun's java license prevents you from deploying the jdk to a
>*production* system, and tools.jar is part of the jdk.

I think this is no longer true.  At least from my reading of the 1.4.*
licenses.  I do agree this was true with 1.3.* and earlier, but I am pretty
sure they changed it.

I may have missed it, of course, and if you could point out where in the
current licenses that this is forbidden, I'd appreciate it.

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


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] JSP Compiling Error When Starting JBoss Using Wrapper

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

In article <014501c38230$ec847290$6502a8c0@fs1>,
Sal Ingrilli <wra...@li...> wrote:
>note that sun's java license prevents you from deploying the jdk to a
>*production* system, and tools.jar is part of the jdk.

I think this is no longer true.  At least from my reading of the 1.4.*
licenses.  I do agree this was true with 1.3.* and earlier, but I am pretty
sure they changed it.

I may have missed it, of course, and if you could point out where in the
current licenses that this is forbidden, I'd appreciate it.

Cheers,
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] Sockets and desktop

[ender w. <end...@ya...>]

Hello.

First some details:
I am working on a project involving an instant one way
messaging on windows. Basically I am writing a
service(SocketService) that connects with a server
through a socket and writes to file/(some repository)
the messages it receives. Another service( 
DesktopMessageService) reads from the files the
messages and if it finds a new message for the CURRENT
user it will open a frame and show it on the screen. 
The reason I use two services instead of one is
because I read that a service either does neworking or
it accesses the desktop or console. 
 The SocketService performs well, it does indeed read
from a socket(ServerSocket) and when contacted there
are messages it does store them on file. 

The problems arise with the DesktopMessageService.I
have yet to find a way to detect the current
user.Basically when the pc is booted the
DesktopMesssage starts ,tries to detect the current
user and print to screen a message.The problem is that

I cannot decect when a user loggs on to the machine.
The current user for the DesktopService is still 
System.So if I want to print a message Hi +
System.getProperty("user.name") , even if there is a
user logged on it still prints Hi System , not Hi
"Current User Name".Im also tried to restart the JVm
periodically but the curent user is still System.
By the way the service works fine when tested in a
console .

So my questions are, Is there a way to detect when a
user loggs on and get his name?
Also, is there a way to detect when a users logs off?

Thanks, Alex






=====


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

RE: [Wrapper-user] JSP Compiling Error When Starting JBoss Using Wrapper

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

sounds like you're missing tools.jar from your path.

# Java Classpath (include wrapper.jar)  Add class path elements as
#  needed starting from 1
wrapper.java.classpath.1=../lib/*.jar
wrapper.java.classpath.2=../bin/run.jar
wrapper.java.classpath.3=%JAVA_HOME%/lib/tools.jar

note that sun's java license prevents you from deploying the jdk to a
*production* system, and tools.jar is part of the jdk.
indirectly this means you can't deploy non-precompiled jsps.

-----Original Message-----
From: wra...@li...
[mailto:wra...@li...]On Behalf Of
Bin_Duan/Cla...@cl...
Sent: Tuesday, September 23, 2003 11:34 AM
To: wra...@li...
Subject: [Wrapper-user] JSP Compiling Error When Starting JBoss Using
Wrapper


We'd like to start JBoss currently hosting our J2EE application using
Wrapper. I followed the step-by-step instruction from the website to setup
JBoss wrapper. And the JBoss started up fine, but when I tried to access
our application, I got an error indicating unable to compile class for JSP
as follows:

org.apache.jasper.JasperException: Unable to compile class for JSP
             at
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:4
79)

             at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:1
84)

             at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
             at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
             at
javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
             at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:247)

             at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:193)


Looks like I missed some classpath setup, but I did follow exactly from the
instruction on Wrapper website. Anyone has any idea what I missed? Thanks.

The following is the copy of my wrapper.conf file

#********************************************************************
# Wrapper Properties
#********************************************************************
# Java Application
wrapper.java.command=java

# Java Main class.  This class must implement the WrapperListener interface
#  or guarantee that the WrapperManager class is initialized.  Helper
#  classes are provided to do this for you.  See the Integration section
#  of the documentation for details.
wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp

# Java Classpath (include wrapper.jar)  Add class path elements as
#  needed starting from 1
wrapper.java.classpath.1=../lib/wrapper.jar
wrapper.java.classpath.2=../lib/wrappertest.jar
wrapper.java.classpath.3=c:/java/jdk1.3/lib/tools.jar
wrapper.java.classpath.4=C:/JBoss/jboss-3.0.4/bin/run.jar

# Java Library Path (location of Wrapper.DLL or libwrapper.so)
wrapper.java.library.path.1=../lib

# Java Additional Parameters
wrapper.java.additional.1=-Dprogram.name=run.bat

# Initial Java Heap Size (in MB)
wrapper.java.initmemory=256

# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=256

# Application parameters.  Add parameters as needed starting from 1
wrapper.app.parameter.1=org.jboss.Main
wrapper.app.parameter.2=-c
wrapper.app.parameter.3=mms

#********************************************************************
# Wrapper Logging Properties
#********************************************************************
# Format of output for the console.  (See docs for formats)
wrapper.console.format=PM

# Log Level for console output.  (See docs for log levels)
wrapper.console.loglevel=INFO

# Log file to use for wrapper output logging.
wrapper.logfile=../logs/wrapper.log

# Format of output for the log file.  (See docs for formats)
wrapper.logfile.format=LPTM

# Log Level for log file output.  (See docs for log levels)
wrapper.logfile.loglevel=INFO

# Maximum size that the log file will be allowed to grow to before
#  the log is rolled. Size is specified in bytes.  The default value
#  of 0, disables log rolling.  May abbreviate with the 'k' (kb) or
#  'm' (mb) suffix.  For example: 10m = 10 megabytes.
wrapper.logfile.maxsize=0

# Maximum number of rolled log files which will be allowed before old
#  files are deleted.  The default value of 0 implies no limit.
wrapper.logfile.maxfiles=0

# Log Level for sys/event log output.  (See docs for log levels)
wrapper.syslog.loglevel=NONE

#********************************************************************
# Wrapper NT Service Properties
#********************************************************************
# WARNING - Do not modify any of these properties when an application
#  using this configuration file has been installed as a service.
#  Please uninstall the service before modifying this section.  The
#  service can then be reinstalled.

# Name of the service
wrapper.ntservice.name=MMS

# Display name of the service
wrapper.ntservice.displayname=MMS

# Description of the service
wrapper.ntservice.description=MMS

# Service dependencies.  Add dependencies as needed starting from 1
wrapper.ntservice.dependency.1=

# Mode in which the service is installed.  AUTO_START or DEMAND_START
wrapper.ntservice.starttype=AUTO_START

# Allow the service to interact with the desktop.
wrapper.ntservice.interactive=false



Bin Duan






-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

[Wrapper-user] JSP Compiling Error When Starting JBoss Using Wrapper

[Bin_Duan/<Cla...@cl...>]

We'd like to start JBoss currently hosting our J2EE application using
Wrapper. I followed the step-by-step instruction from the website to setup
JBoss wrapper. And the JBoss started up fine, but when I tried to access
our application, I got an error indicating unable to compile class for JSP
as follows:

org.apache.jasper.JasperException: Unable to compile class for JSP
             at
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:479)

             at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:184)

             at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
             at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
             at
javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
             at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)

             at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)


Looks like I missed some classpath setup, but I did follow exactly from the
instruction on Wrapper website. Anyone has any idea what I missed? Thanks.

The following is the copy of my wrapper.conf file

#********************************************************************
# Wrapper Properties
#********************************************************************
# Java Application
wrapper.java.command=java

# Java Main class.  This class must implement the WrapperListener interface
#  or guarantee that the WrapperManager class is initialized.  Helper
#  classes are provided to do this for you.  See the Integration section
#  of the documentation for details.
wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp

# Java Classpath (include wrapper.jar)  Add class path elements as
#  needed starting from 1
wrapper.java.classpath.1=../lib/wrapper.jar
wrapper.java.classpath.2=../lib/wrappertest.jar
wrapper.java.classpath.3=c:/java/jdk1.3/lib/tools.jar
wrapper.java.classpath.4=C:/JBoss/jboss-3.0.4/bin/run.jar

# Java Library Path (location of Wrapper.DLL or libwrapper.so)
wrapper.java.library.path.1=../lib

# Java Additional Parameters
wrapper.java.additional.1=-Dprogram.name=run.bat

# Initial Java Heap Size (in MB)
wrapper.java.initmemory=256

# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=256

# Application parameters.  Add parameters as needed starting from 1
wrapper.app.parameter.1=org.jboss.Main
wrapper.app.parameter.2=-c
wrapper.app.parameter.3=mms

#********************************************************************
# Wrapper Logging Properties
#********************************************************************
# Format of output for the console.  (See docs for formats)
wrapper.console.format=PM

# Log Level for console output.  (See docs for log levels)
wrapper.console.loglevel=INFO

# Log file to use for wrapper output logging.
wrapper.logfile=../logs/wrapper.log

# Format of output for the log file.  (See docs for formats)
wrapper.logfile.format=LPTM

# Log Level for log file output.  (See docs for log levels)
wrapper.logfile.loglevel=INFO

# Maximum size that the log file will be allowed to grow to before
#  the log is rolled. Size is specified in bytes.  The default value
#  of 0, disables log rolling.  May abbreviate with the 'k' (kb) or
#  'm' (mb) suffix.  For example: 10m = 10 megabytes.
wrapper.logfile.maxsize=0

# Maximum number of rolled log files which will be allowed before old
#  files are deleted.  The default value of 0 implies no limit.
wrapper.logfile.maxfiles=0

# Log Level for sys/event log output.  (See docs for log levels)
wrapper.syslog.loglevel=NONE

#********************************************************************
# Wrapper NT Service Properties
#********************************************************************
# WARNING - Do not modify any of these properties when an application
#  using this configuration file has been installed as a service.
#  Please uninstall the service before modifying this section.  The
#  service can then be reinstalled.

# Name of the service
wrapper.ntservice.name=MMS

# Display name of the service
wrapper.ntservice.displayname=MMS

# Description of the service
wrapper.ntservice.description=MMS

# Service dependencies.  Add dependencies as needed starting from 1
wrapper.ntservice.dependency.1=

# Mode in which the service is installed.  AUTO_START or DEMAND_START
wrapper.ntservice.starttype=AUTO_START

# Allow the service to interact with the desktop.
wrapper.ntservice.interactive=false



Bin Duan

Re: [Wrapper-user] Wrapping COM Server

[Jim R. <jr...@er...>]

Georg,

We're wrapping an OPC (http://www.opcfoundation.org) server and no OPC 
client is running.  The iMarshal query is associated (somehow) with the 
wrapper.

I checked the source to see if I could find anything COM related there, 
but didn't find anything.  But I could have missed something.

It is also, perhaps, something to do with service managment, but in 
this case I was running as a console application.

Jim


On 2003.09.23 01:22, Georg Schmid wrote:
> Jim,
> 
> just guessing: for some reason, when running from the batch file, 
> both server and client run inside the same COM compartment, but when 
> using the wrapper, they run in different compartments and therefore 
> calls from the client to the server need to be marshalled.
> 
> Georg
> 
> Jim Redman wrote:
> 
>> I have a problem wrapping a COM server.  Wrapping COM clients seems 
>> to
>> work fine also.  The COM Server is implemented as a JNI.  The server 
>> works
>> fine from a batch file.
>> 
>> Running the code from the batch file, I see all the expected startup
>> messages.  I see the same thing from the wrapper (console mode), but 
>> this
>> is immediately followed by a "QueryInterface" with a ID of 
>> iMarshal.  This
>> fails (which is OK) this request is then followed by an IUnknown 
>> request
>> (which succeeds).  HOWEVER after this, the COM client does not work.
>> 
>> With the batch file I see the "CreateInstance" followed by lots of 
>> COM
>> requests.  With the wrapper, I see none of these.  Attempts to 
>> access the
>> interface fails.
>> 
>> Anyone have any thoughts or suggestions?  Where do the COM calls 
>> come from
>> in the wrapper - I couldn't find any?
>> 
>> Jim
>> 
>> 
>> 
> 
>-- 
> --
> Georg Schmid
> Special Applications Section Manager   mailto:geo...@ti...
> Freising Wafer Fab (FFAB) Make IT      phone: +49 8161 804595
> Texas Instruments Deutschland GmbH     fax: +49 8161 803350
>              
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
-- 

Jim Redman
(505) 662 5156 x85
http://www.ergotech.com

Re: [Wrapper-user] Wrapping COM Server

[Georg S. <geo...@ti...>]

Jim,

just guessing: for some reason, when running from the batch file, both 
server and client run inside the same COM compartment, but when using 
the wrapper, they run in different compartments and therefore calls from 
the client to the server need to be marshalled.

Georg

Jim Redman wrote:

>I have a problem wrapping a COM server.  Wrapping COM clients seems to
>work fine also.  The COM Server is implemented as a JNI.  The server works
>fine from a batch file.
>
>Running the code from the batch file, I see all the expected startup
>messages.  I see the same thing from the wrapper (console mode), but this
>is immediately followed by a "QueryInterface" with a ID of iMarshal.  This
>fails (which is OK) this request is then followed by an IUnknown request
>(which succeeds).  HOWEVER after this, the COM client does not work.
>
>With the batch file I see the "CreateInstance" followed by lots of COM
>requests.  With the wrapper, I see none of these.  Attempts to access the
>interface fails.
>
>Anyone have any thoughts or suggestions?  Where do the COM calls come from
>in the wrapper - I couldn't find any?
>
>Jim
>
>
>  
>

-- 
--
Georg Schmid
Special Applications Section Manager   mailto:geo...@ti...
Freising Wafer Fab (FFAB) Make IT      phone: +49 8161 804595
Texas Instruments Deutschland GmbH     fax: +49 8161 803350
              

[Wrapper-user] Wrapping COM Server

[Jim R. <jr...@er...>]

I have a problem wrapping a COM server.  Wrapping COM clients seems to
work fine also.  The COM Server is implemented as a JNI.  The server works
fine from a batch file.

Running the code from the batch file, I see all the expected startup
messages.  I see the same thing from the wrapper (console mode), but this
is immediately followed by a "QueryInterface" with a ID of iMarshal.  This
fails (which is OK) this request is then followed by an IUnknown request
(which succeeds).  HOWEVER after this, the COM client does not work.

With the batch file I see the "CreateInstance" followed by lots of COM
requests.  With the wrapper, I see none of these.  Attempts to access the
interface fails.

Anyone have any thoughts or suggestions?  Where do the COM calls come from
in the wrapper - I couldn't find any?

Jim


-- 
Jim Redman
ErgoTech Systems, Inc.
+1 505 662 5156

[Wrapper-user] what wrapper version am i running?

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

i would find it useful to know the wrapper version by running
"wrapper -version" (like "java -version") or similar

however i can get around it by restarting the app & looking in wrapper.log

ciao

Re: [Wrapper-user] mbean nativeRequestThreadDump

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

I do launch the java with the flag '-Xrs'; maybe that
prevents the signal from being seen.

Richard


Leif Mortenson wrote:
> Richard,
>    It sounds like you are doing things correctly.  I retested this today 
> using JBoss and
> Java 1.4.2_01 but everything appears to be working correctly.   I tried 
> the JMX interface
> while running in both console mode and running as an NT service.
>    The thread dump will be dumped to both the console and wrapper.log 
> file at the INFO
> level.
>    When running in console mode are you able to invoke a thread dump using
> CTRL-BREAK on Windows or CTRL-\ on UNIX.   On unix, you should also be
> able to invoke a thread dumb executing the wrapper script used to launch 
> the application
> with the dump command.
>    I'll test this out on Linux tonight as that may be what you are running?
> 
> Cheers,
> Leif
> 
>> So I've got 3.0.5 running with my jboss application. I set
>> wrapper.debug=true, just to see whats happening.
>> I get printout that the native library was loaded...
>>
>>
>> INFO   | jvm 1    | 2003/09/16 08:55:12 | Calling native 
>> initialization method.
>> INFO   | jvm 1    | 2003/09/16 08:55:12 | Inside native WrapperManager 
>> initialization method
>> INFO   | jvm 1    | 2003/09/16 08:55:12 | Java Version   : 1.4.2-b28 
>> Java HotSpot(TM) Client VM
>> INFO   | jvm 1    | 2003/09/16 08:55:12 | Java VM Vendor : Sun 
>> Microsystems Inc.
>> INFO   | jvm 1    | 2003/09/16 08:55:12 |
>> INFO   | jvm 1    | 2003/09/16 08:55:12 | Wrapper (Version 3.0.5)
>> INFO   | jvm 1    | 2003/09/16 08:55:12 |
>> INFO   | jvm 1    | 2003/09/16 08:55:12 | Open socket to wrapper...
>> INFO   | jvm 1    | 2003/09/16 08:55:12 | Opened Socket
>> INFO   | jvm 1    | 2003/09/16 08:55:12 | Send a packet KEY : 
>> XGuDK_MTRJ8iZjZ3
>> etc......
>>
>> I start getting debug printout:
>>
>> DEBUG  | wrapperp | 2003/09/16 08:56:35 | send a packet PING : ping
>> INFO   | jvm 1    | 2003/09/16 08:56:35 | Received a packet PING : ping
>> INFO   | jvm 1    | 2003/09/16 08:56:35 | Send a packet PING : ok
>> DEBUG  | wrapperp | 2003/09/16 08:56:35 | read a packet PING : ok
>> DEBUG  | wrapper  | 2003/09/16 08:56:35 | Got ping response from JVM
>> DEBUG  | wrapperp | 2003/09/16 08:56:41 | send a packet PING : ping
>>
>> but when I press 'invoke' on the methods requestThreadDump
>> on the jmx mbean page for the wrapper nothing happens.
>> Well, I do advance to a followup jboss web page, but there is
>> no thread dump. Not on the web page or any of the logs. In fact,
>> the debug information in the native (linux) method
>> Java_org_tanukisoftware_wrapper_WrapperManager_nativeRequestThreadDump
>> does not print.
>>
>> No errors, no nothing. Where is the thread dump output suppose to
>> go?
>>
>> Thanks.
>>
>>
>> Richard
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
> 

Re: [Wrapper-user] mbean nativeRequestThreadDump

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

Richard,
    It sounds like you are doing things correctly.  I retested this 
today using JBoss and
Java 1.4.2_01 but everything appears to be working correctly.   I tried 
the JMX interface
while running in both console mode and running as an NT service.
    The thread dump will be dumped to both the console and wrapper.log 
file at the INFO
level.
    When running in console mode are you able to invoke a thread dump using
CTRL-BREAK on Windows or CTRL-\ on UNIX.   On unix, you should also be
able to invoke a thread dumb executing the wrapper script used to launch 
the application
with the dump command.
    I'll test this out on Linux tonight as that may be what you are running?

Cheers,
Leif

> So I've got 3.0.5 running with my jboss application. I set
> wrapper.debug=true, just to see whats happening.
> I get printout that the native library was loaded...
>
>
> INFO   | jvm 1    | 2003/09/16 08:55:12 | Calling native 
> initialization method.
> INFO   | jvm 1    | 2003/09/16 08:55:12 | Inside native WrapperManager 
> initialization method
> INFO   | jvm 1    | 2003/09/16 08:55:12 | Java Version   : 1.4.2-b28 
> Java HotSpot(TM) Client VM
> INFO   | jvm 1    | 2003/09/16 08:55:12 | Java VM Vendor : Sun 
> Microsystems Inc.
> INFO   | jvm 1    | 2003/09/16 08:55:12 |
> INFO   | jvm 1    | 2003/09/16 08:55:12 | Wrapper (Version 3.0.5)
> INFO   | jvm 1    | 2003/09/16 08:55:12 |
> INFO   | jvm 1    | 2003/09/16 08:55:12 | Open socket to wrapper...
> INFO   | jvm 1    | 2003/09/16 08:55:12 | Opened Socket
> INFO   | jvm 1    | 2003/09/16 08:55:12 | Send a packet KEY : 
> XGuDK_MTRJ8iZjZ3
> etc......
>
> I start getting debug printout:
>
> DEBUG  | wrapperp | 2003/09/16 08:56:35 | send a packet PING : ping
> INFO   | jvm 1    | 2003/09/16 08:56:35 | Received a packet PING : ping
> INFO   | jvm 1    | 2003/09/16 08:56:35 | Send a packet PING : ok
> DEBUG  | wrapperp | 2003/09/16 08:56:35 | read a packet PING : ok
> DEBUG  | wrapper  | 2003/09/16 08:56:35 | Got ping response from JVM
> DEBUG  | wrapperp | 2003/09/16 08:56:41 | send a packet PING : ping
>
> but when I press 'invoke' on the methods requestThreadDump
> on the jmx mbean page for the wrapper nothing happens.
> Well, I do advance to a followup jboss web page, but there is
> no thread dump. Not on the web page or any of the logs. In fact,
> the debug information in the native (linux) method
> Java_org_tanukisoftware_wrapper_WrapperManager_nativeRequestThreadDump
> does not print.
>
> No errors, no nothing. Where is the thread dump output suppose to
> go?
>
> Thanks.
>
>
> Richard

[Wrapper-user] mbean nativeRequestThreadDump

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

So I've got 3.0.5 running with my jboss application. I set
wrapper.debug=true, just to see whats happening.
I get printout that the native library was loaded...


INFO   | jvm 1    | 2003/09/16 08:55:12 | Calling native initialization 
method.
INFO   | jvm 1    | 2003/09/16 08:55:12 | Inside native WrapperManager 
initialization method
INFO   | jvm 1    | 2003/09/16 08:55:12 | Java Version   : 1.4.2-b28 
Java HotSpot(TM) Client VM
INFO   | jvm 1    | 2003/09/16 08:55:12 | Java VM Vendor : Sun 
Microsystems Inc.
INFO   | jvm 1    | 2003/09/16 08:55:12 |
INFO   | jvm 1    | 2003/09/16 08:55:12 | Wrapper (Version 3.0.5)
INFO   | jvm 1    | 2003/09/16 08:55:12 |
INFO   | jvm 1    | 2003/09/16 08:55:12 | Open socket to wrapper...
INFO   | jvm 1    | 2003/09/16 08:55:12 | Opened Socket
INFO   | jvm 1    | 2003/09/16 08:55:12 | Send a packet KEY : 
XGuDK_MTRJ8iZjZ3
etc......

I start getting debug printout:

DEBUG  | wrapperp | 2003/09/16 08:56:35 | send a packet PING : ping
INFO   | jvm 1    | 2003/09/16 08:56:35 | Received a packet PING : ping
INFO   | jvm 1    | 2003/09/16 08:56:35 | Send a packet PING : ok
DEBUG  | wrapperp | 2003/09/16 08:56:35 | read a packet PING : ok
DEBUG  | wrapper  | 2003/09/16 08:56:35 | Got ping response from JVM
DEBUG  | wrapperp | 2003/09/16 08:56:41 | send a packet PING : ping

but when I press 'invoke' on the methods requestThreadDump
on the jmx mbean page for the wrapper nothing happens.
Well, I do advance to a followup jboss web page, but there is
no thread dump. Not on the web page or any of the logs. In fact,
the debug information in the native (linux) method
Java_org_tanukisoftware_wrapper_WrapperManager_nativeRequestThreadDump
does not print.

No errors, no nothing. Where is the thread dump output suppose to
go?

Thanks.


Richard

[Wrapper-user] Fwd: RE: No args wrapper startup [jredman@ergotech.com]

[Jim R. <ji...@er...>]

Sal,

Beyond the obvious observation that batch files are ugly, we have at 
least on sitution where a batch file will not work.  The OPC standard, 
which we support, mandates that one of the registry keys associated 
with an application is an executable, not a batch file.

In our case, it is the end users choice whether to install a service or 
not.  For some customers the applications will not run as a service, 
the application will grab the executable from the registry and run it 
and check that the application is still alive.  Others want a 
service.   Some want a real user interface, etc. etc. Hence the 
attraction of the wrapper, it does all these things.

> From: Sal Ingrilli <sal@sy...>
> RE: No args wrapper startup
> 2003-09-11 10:26

> i would definitely use the default "wrapper.conf" file name and 
> location if its "../conf/wrapper.conf" and it is relative to wrapper.
> exe.

In this case, you could only have one application per directory.  Might 
not be a restriction in your case, but are you sure you want to impose 
it upon everyone?
> i disagree with you on the default argument because the wrapper is a 
> service wrapper. i think that the default option should be to install 
> and start the service, as in "wrapper -it" i think that if you 
> wantthe default option to be "-c" you should create yourself a batch 
> filetorun your app.

If there's no interest, I'm going to hack this for myself.  If there's 
interest then I don't mind making a more general solution.  For 
example, double-clicking app.exe could read app.conf and find out what 
it's suppose to do next (install as service, run in console, etc.).  
That is, the default command line options could be encoded in the 
configuration file.

However it seems that there's _almost_ a mechanism similar to this in 
the build scripts, and I would want to re-invent something that already 
has a good solution.

Jim
PS There seems to be some disagreement between my mailer (Balsa) and 
the list server as to who I am, so my apologies for the ugly formatting.

> -----Original Message-----
> From: wrapper-user-admin@li...
> [mailto:wrapper-user-admin@li...]On Behalf Of Jim Redman
> Sent: Thursday, September 11, 2003 6:52 AM
> To: wrapper-user@li...
> Subject: [Wrapper-user] No args wrapper startup
> 
> I'd like to use the wrapper to start a console application.  But 
> Ineed a single executable that the user can click on, that is, no 
> argspassed to the application.
> 
> Is this possible without modifications to the c source?
> 
> If not, is anyone else interested in this?  My idea would be to have
> double-clicking on app.exe be the same as "app -c app.conf" if app.
> conf exists.

-- 

Jim Redman
(505) 662 5156 x85
http://www.ergotech.com

Re: [Wrapper-user] Single wrapper release possible?

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

Mike,
That is actually exactly how I have been waning to eventually do this. I
have
gotten support checked into CVS for naming the native library based on the
platform and architecture.

On Windows, the file can be named any of the following:
wrapper-windows-x86.dll
wrapper-windows.dll
wrapper.dll

On Linux, the following:
libwrapper-linux-i386.so
libwrapper-linux.so
libwrapper.so

On Solaris, the following:
libwrapper-sunos-sparc.so
libwrapper-sunos.so
libwrapper.so

I need to get the possible names for the other supported platforms resolved
by working with the volunteers who help with those builds.

The next step is to come up with a shell script which is capable of
doing the
same thing with the wrapper binary. Once that is done then a full cross
platform release will be possible.

Cheers,
Leif

Mike Castle wrote:

>In article <106...@we...>,
>Fredrik Israelsson  <wra...@li...> wrote:
>  
>
>>I don't question writing the wrapper in C. My question is more like why one 
>>cannot make one wrapper release with binaries needed for all platforms. I mean, 
>>storage space for the few MB:s needed is not a problem theese days.
>>    
>>
>
>I'm of two minds about this myself.
>
>After all, the JRE doesn't come with only one package; you have to download
>a different package for each arch.  Ok, well, Sun's is like that; I have no
>experience with any others, so maybe they do.
>
>But on the other hand, personally I package my app separately with all
>wrapper stuff appropriate for supports platforms, and distribute all addons
>(JDK, 3rd party libs, etc) as a second package, which is platform specific.
>
>Now, currently we only support Linux and Win32, so there are no conflicts
>with wrapper and wrapper.exe and wrapper.dll and libwrapper.so.
>
>But, what if I want to package another unix like platform that also uses
>.so?  Then it becomes a bit trickier.
>
>Sure, I could have wrapper.Linux and wrapper.FreeBSD and modify wrapper.sh
>to call wrapper.`uname -s` or something.  But that doesn't solve the
>dynamically loaded library issue.
>
>I think a nice enhancement would be if the call to System.loadLibrary()
>first tried "wrapper" and if that didn't work, try "wrapper.arch" or
>something.  I'm no Java expert, but it looks like the java property os.name
>might be appropriate?  Actually, may be a good idea to use os.name +
>os.arch to correctly support same OS on multiple platforms.  Linux and
>FreeBSD, for example, both work on non-i386 arch.  And if you're supporting
>FreeBSD, which has to build their own java from Sun's source anyway, might
>as well support them compiling it on a myriad of platforms.
>
>One reason this really concerns me is that the developers here like to run
>the same compiled code on two machines to test communications.  Sometimes
>those two machines are different OSes.  We're lucky now that Linux and
>Win32 can coexist.  But if we start supporting other platforms, it becomes
>more of an issue.
>
>Anyway, just my thoughts on the matter.
>
>Cheers,
>mrc
>  
>