Essas sao algumas solucoes para rodar um servidor Java
como servico do NT:
http://www.sys-con.com/java/archives/0601/nanda/index.html
http://www.eworksmart.com/jnt/
http://www.kcmultimedia.com/javaserv/
http://ise.fdns.net/products.html
Alexandre Rodrigues Gomes wrote:
>
> Para quem perguntou sobre serviços no NT.
> Tive muiiiiiiiitos problemas pra consegui fazer as coisas funcionarem.
>
>
>
>
> Bug Id 4323062
>
> Votes 587
>
> Synopsis Any Windows NT Service embedding Java VM aborts, when user
> logs out from Windows
>
> Category java:runtime
>
> Reported Against kestrel-rc2, kestrel-rc1, kestrel-rc3, 1.2.2, 1.3
>
> Release Fixed
>
> State In progress, bug
>
> Related Bugs 4358808
> <http://developer.java.sun.com/developer/bugParade/bugs/4358808.html>
>
> Submit Date Mar 17, 2000
>
> Description
> IHAC with a NT Service program which starts a Java program. The java
>
> program is a simple program with a server socket waiting to accept socket
>
> connections. The program is installed and everything works fine until the
> user
>
> decides to log off. Since the Java program is installed through the NT
> Service,
>
>
>
> the program should continue to work even when the user logs out of the
>
> system. But on the contrary, the program goes into an unstable state and
> the
>
> program hangs. I have enclosed the stack trace which I managed to capture
> by
>
> making the NT Service interact with the desktop, so we get to see the
> console.
>
>
>
> This problem does not occur with JDK1.1.x. This happens only for JDK1.2 and
>
> greater versions. The Java thread dump and testcase TestNTSvc.tar.Z is
>
> in the attachments.
>
>
>
>
>
> Follow these instructions to reproduce the problems:
>
> SOURCE MODIFICATION
>
>
>
> 1)In the clienttest.java file edit line 16:
>
> s = new Socket("sworks.eng.sun.com",7990);
>
> with your test system's host address. Save and recompile.
>
>
>
>
>
> INSTRUCTIONS FOR INSTALLING SERVICE ON WINDOW NT 4.0
>
>
>
> 1. Extract the contents of the zip file to say C:\
>
> 2. Assuming this, you would now have a directory C:\testntsvc
>
> 3. Create an "System Variable" TEST_ROOT in Environment tab of the System
>
> Properties from the "Control Panel" Settings
>
> and set C:\testntsvc
>
> to
>
> TEST_ROOT.
>
> 4. Append C:\testntsvc to your classpath settings in control panel and also
>
> make sure your CLASSPATH is a "System Variable".
>
> 5. Go to DOS command prompt and go to the directory c:\testntsvc
>
> 6. Type TestNTSvc -install to install the NTService.
>
> 7. Now go to your control panel settings and click on the "Services"
>
> icon to see if the NT Service "TestNTSvc" is installed.
>
> 8. If it has not been installed please contact me at xxxxx@xxxxx
>
> or 650 526 3336.
>
> 9. If it has been installed, then select the "TestNTSvc"
>
> in the services window, click on the button "Startup" and set
>
> the "StartUp Type" to Manual(from Automatic).
>
> Also check the checkbox for "Allow Service to interact with the Desktop".
>
> 10. Now click on OK Button and close the control panel settings.
>
> 11. Now ensure that you have installed JDK1.1.6, JDK1.1.7b and Java2 on your
>
> NT Workstation.
>
> 12. Open the file "cmdscripts.cfg" file in C:\testntsvc, and update your
>
> directory path for the various jre vms. You can comment all the lines
>
> except the line which you intend to invoke a particular JVM, so for example
>
> you intend to run jre1.2.2, then the following would be the text in the
>
> file cmdscripts.cfg file:
>
>
>
>
>
> adm=d:/jdk1.2.2/jre/bin/java -mx256m -DTEST_ROOT=%TEST_ROOT% testserver
>
> #adm=f:/jdk1.1.7b/bin/java -mx256m -classpath %classpath%;f:/testntsvc
>
> -DTEST_ROOT=%TEST_ROOT% testserver
>
> #adm=f:/jdk1.1.7b/bin/jre -mx256m -cp f:/testntsvc -DTEST_ROOT=%TEST_ROOT%
>
> testserver
>
> adm=f:/jdk1.1.6/bin/jre -cp f:/testntsvc -DTEST_ROOT=%TEST_ROOT% testserver
>
> #adm=f:/jdk1.1.6/bin/java -classpath %classpath%;f:/testntsvc
>
> -DTEST_ROOT=%TEST_ROOT% testserver
>
>
>
> 13. Save the file and close it.
>
> 14. Reboot your workstation so that the classpath and the new "System
>
> variables" comes into effect.
>
> 15. After booting go to the control panel.
>
> 16. Go to the services panel in control panel and
>
> start the NT Service "TestNTSvc". You should now see the Java console
>
> for d:/jdk1.2.2/bin/jre with the statement "Getting Connected" being printed
>
> in the console.
>
>
>
> 17. Run the Java test program testclient.java on the command prompt,
>
> by typing in at the command prompt c:\testntsvc>java testclient
>
> 18. The program works and exits normally after printing the statements
>
> "Creating a Socket", "Created the client Socket" on the console. This
>
> is what a remote client system would see when accessing the Server service.
>
>
>
> 19. Now try logging off the NT Workstation and you will see in the Java
> console
>
> that the JVM dumps a Java thread trace and the service hangs
> unresponsive
>
> when you log back in.
>
>
>
>
>
>
>
>
>
>
>
>
>
> java version "1.3.0rc2"
>
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0rc2-Y)
>
> Java HotSpot(TM) Client VM (build 1.3.0rc2-Y, mixed mode)
>
>
>
>
>
> I'm writing NT-service by JDK1.3 (and some C codes).
>
>
>
> 1.NT-service start by manual. (check "System Account")
>
> 2.logoff
>
>
>
> ...then, NT-service(running JVM in service) stop process.
>
>
>
> I hope, cancel shutdown JVM.
>
> (Review ID: 103003)
>
>
>
>
>
>
>
>
>
>
>
> java version "1.3.0rc1"
>
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0rc1-T)
>
> Java HotSpot(TM) Client VM (build 1.3.0rc1-S, mixed mode)
>
>
>
> Using ServiceInstaller 1.1 (http://www.kcmultimedia.com/smaster) install a
>
> simple Java app as a service that outputs some trivial data to a file every
>
> 10 seconds.
>
>
>
> Here's the simple demo service:
>
>
>
> import java.io.*;
>
> import java.util.*;
>
>
>
>
>
> public class Test2
>
> {
>
> public static void main(String[] args)
>
> {
>
>
>
> Date now;
>
> PrintWriter out;
>
>
>
> try{
>
>
>
>
>
>
>
> while(true){
>
>
>
> now = new Date();
>
> out = new PrintWriter(new FileWriter("test2.out",true),
> true);
>
> out.println(now.toString());
>
> out.close();
>
>
>
> Thread.sleep(10000);
>
>
>
> }
>
>
>
> }catch(Exception e){
>
>
>
> System.out.println(e.toString());
>
>
>
> }
>
> }
>
> }
>
>
>
> Start the service from the Control Panel|Services Applet, and check the
>
> contents of the file test2.out, which should append a line showing the
>
> date and time each 10 sec.
>
>
>
> Log off, and log back in.
>
>
>
> Although NT thinks the service is still running, it is not. You will see
>
> that lines are no longer appended to the file.
>
>
>
> This seems to only occur with JDK 1.3 RC1. Under JDK 1.2.2, the test app
>
> keeps running thru the login/logout
>
> (Review ID: 102993)
>
>
>
>
>
> webbug bgiel nostromog
> Workaround
> The workaround is to create a new thread in the parent process to read the
>
> pipe.
>
> In this way, the pipe between the parent and child process will not get
>
> overflowed. The application will not hang any more. Also if the return value
>
> from read is -1, the read thread may be dismissed to retain resources.
>
>
>
> xxxxx@xxxxx 2000-06-02
> Evaluation
> It seems that this is not a bug.
>
>
>
> In 1.1.x, runtime.exec create a new process which is a detached process, so
> the
>
> child process will not accept signals (like ctrl+break) from the console of
> the
>
> parent process. That's why in 1.1.x, there's no thread dump.
>
>
>
> In 1.2.2, runtime.exec create a new attached process, the child process can
>
> still accept the signal from the console of the parent process, it's stderr
> is
>
> linked to the parent's pipe. After it received the signal, it sent out
> thread
>
> dump to stderr which redirects to the pipe, as the pipe has a limited
> capacity,
>
> another thread needs to read from the pipe to keep it going, otherwise,
>
> the child process appears hang.
>
>
>
>
>
> xxxxx@xxxxx 2000-04-18
>
>
>
> ------------------------------------------------------------
>
>
>
> The evaluation above is incorrect; a corrected one follows. A solution
>
> exists for this problem; please see the end of this evaluation for it.
>
>
>
> The problem was caused by the addition of the shutdown hook mechanism
>
> to 1.3. Shutdown hooks, compared to the System.runFinalizersOnExit()
>
> mechanism, have stronger guarantees regarding when they are run; for
>
> example, if the VM is terminated by a Ctrl-C, finalizers will not be
>
> executed via runFinalizersOnExit, but shutdown hooks will be run.
>
>
>
> On Win32, shutdown hooks are implemented by adding a console control
>
> handler (see the documentation for SetConsoleCtrlHandler) which, upon
>
> seeing a condition like a Control-C or a "user logoff event", raises
>
> the termination condition in the VM. This causes the shutdown hooks to
>
> be run.
>
>
>
> Both the shutdown hook mechanism and the Ctrl-Break stack dump require
>
> signal-like information. 1.2 implemented the Ctrl-Break stack dump
>
> using the POSIX "signal" call on Win32. It turns out (as was noted in
>
> the 1.3 VM code by xxxxx@xxxxx that this mechanism translates all
>
> console events except Ctrl-C into SIGBREAK, which is not sufficient
>
> granularity to support both Ctrl-Break and shutdown hooks. This is why
>
> the console control handler was added in 1.3.
>
>
>
> When the VM's console handler receives the CTRL_LOGOFF_EVENT, it
>
> informs the rest of the VM of pending termination (thereby causing
>
> shutdown hooks to be run) and returns TRUE. According to the MSDN
>
> documentation, a return value of TRUE for this event will cause the
>
> popup window for process termination to be displayed. It seems that
>
> this return value was chosen because the VM is still doing work
>
> (running the shutdown hooks asynchronously) after the
>
> CTRL_LOGOFF_EVENT is received, and the author thought that returning
>
> false would cause the VM to be terminated by the OS while doing this
>
> work (as is stated in the MSDN documentation: the system's default
>
> handler terminates the process).
>
>
>
> The MSDN documentation is not specific about the relationship between
>
> services and the CTRL_LOGOFF_EVENT. Conceptually, a service runs in
>
> the background and should not be associated with any particular user's
>
> login session, so one might expect that a service should not be
>
> notified of logoff events. However, Win32 does send these events to
>
> services. Interestingly, the default console handler for services
>
> differs from the default for ordinary console processes; services
>
> continue to run after their default handler executes. This is what
>
> allows ordinary programs (which either do not install a console
>
> handler, or which return FALSE in their console handler for
>
> CTRL_LOGOFF_EVENT) to work with, for example, ServiceInstaller.
>
> However, it does not seem that there is a way for a process to query
>
> whether it is running as a service. If there were, the correct
>
> behavior for the VM upon receiving the CTRL_LOGOFF_EVENT if it were
>
> running as a service would be to skip running the shutdown hooks, not
>
> signal the termination condition to the rest of the VM, and return
>
> FALSE. Otherwise, the two possible workarounds are either to provide
>
> another command line option to java.exe ("running as a service on
>
> Windows NT") or to somehow intercept the CTRL_LOGOFF_EVENTs at the
>
> service wrapper level.
>
>
>
> --
>
>
>
> Since the time this bug was filed, its original submitter (who is the
>
> author of ServiceInstaller) has released a revised piece of software,
>
> called JavaServ, which solves this problem elegantly by using the JNI
>
> Invocation API to create a Java VM and installing a console control
>
> handler afterwards which intercepts the CTRL_LOGOFF_EVENT and prevents
>
> it from being passed to the VM. It also contains other useful features
>
> like allowing pure Java programs to receive service control events.
>
> JavaServ may be downloaded from
>
>
>
> http://www.kcmultimedia.com/javaserv/
>
>
>
> The comments on the JDC also contain the source code to a similar
>
> program.
>
>
>
> xxxxx@xxxxx 2000-08-30
> Your Comments & Work-arounds
> (These are NOT written by Sun!)
> Include a link with my name & email
>
>
>
> Wed Apr 12 04:02:54 PDT 2000
> jsommer <mailto:[EMAIL PROTECTED]>
>
>
> This is a HotSpot problem, not a jdk 1.3 problem - the
>
> problem also occurs with HotSpot-2.0/jdk 1.2.2
>
> Fri Apr 21 00:29:58 PDT 2000
> gageot <mailto:[EMAIL PROTECTED]>
>
> Not a bug ?????
>
> So how do you have a Java server application on NT ?
>
> Fri Apr 21 11:27:23 PDT 2000
> javageorge <mailto:[EMAIL PROTECTED]>
>
> This is a bug!! I can run my Java application as an NT
>
> Service using JDK 1.2.2, but can NOT run it with JDK 1.3
>
> RC3. Nor can I get it to work when running with Java
>
> HotSpot, regardless of which VM I use. My only solution is
>
> to run with JDK 1.2.2 without Hotspot ( too slow.... ).
>
>
>
> I have downloaded several programs that create NT Services
>
> for Java apps, and see the this same behavior, regardless of
>
> which one I use. I also see this behavior when I create the
>
> NT Service using Microsoft's srvany.exe.
>
>
>
> You would think it would be in Sun's best interest to make
>
> it VERY easy to create an NT Service for a Java Application.
>
> Don't they want Java Applications to proliferate on NT?? I
>
> had hoped that Sun would have provided such a tool, but this
>
> is not the case...
>
>
>
> Instead, here's the tools I've tried in addition to srvany:
>
> http://www.kcmultimedia.com/smaster/
>
> http://www.formida.com.au/firedaemon
>
>
>
> This has been a major headache for us and I really hope this
>
> is fixed before JDK 1.3 is officially released!!
>
> Thu May 04 02:06:23 PDT 2000
> nostromog <mailto:[EMAIL PROTECTED]>
>
> It keeps going on with rc3. Using Mike Jennings framework, services
>
> DO WORK with 1.2.2 Hotspot, but they don't work with any 1.3 prerelease.
>
> Tue May 09 11:03:21 PDT 2000
> bryanvv <mailto:[EMAIL PROTECTED]>
>
> Looks like this is still a problem with the released version
>
> of 1.3 on NT. It causes JRun or JWS (or, presumably, any
>
> Java-based web or application server) to crash on logout,
>
> meaning 1.3 is unuseable on the server for us.
>
> Tue May 09 11:36:21 PDT 2000
> mjennings <mailto:[EMAIL PROTECTED]>
>
> The evaluation assumes a separate process is created by
>
> the JVM. This bug occurs when the NT service is a SINGLE
>
> process that uses the JVM.
>
>
>
> Something in the hotspot JVM kills the process when the user
>
> logs out. Other services (like MS personal web server) keep
>
> running when user logs out.
>
>
>
> Either the process using the JVM crashes, or shuts down
>
> nicely when the user logs off.
>
> Sat May 13 15:30:14 PDT 2000
> thobitz <mailto:[EMAIL PROTECTED]>
>
> The reason for this behaviour probably is the setting "Allow Service to
> interact with the Desktop". This is
>
> wrong.
>
>
>
> A service which has this switch set receives the WM_QUERYENDSESSION on which
> each Windows
>
> application is expected to terminate. Furthermore, it can be manipulated by
> the user who logged in.
>
> Mon May 15 19:16:27 PDT 2000
> SF019JP <mailto:[EMAIL PROTECTED]>
>
> JavaVM stops when works as WindowsNT service at the same time that
>
> a user does log-off. I investigated the cause by referring to SCSL.
>
>
>
> JavaVM(JRE1.3) utilizes SetConsoleCtrlHandler() function in Windows
>
> NT and collects some events. When a user does log-off, CTRL_LOGOFF_EVENT
>
> event occurs. As a result JavaVM(JVM.DLL) receives a CTRL_LOGOFF_EVENT
>
> event and has stopped.
>
>
>
> I used JNI and evaded this problem by seizing CTRL_LOGOFF_EVENT event
>
> by force. I pray for this problem being solved formally.
>
> Tue May 16 13:31:49 PDT 2000
> ken_h_chin <mailto:[EMAIL PROTECTED]>
>
> I'm using JDK 1.3 on Windows NT and have experienced the
>
> same problem. Logging off the user also kills rmiregistry,
>
> which I run as a service using ServiceMaster.
>
>
>
> If SUN is serious about supporting server side Java on the
>
> Windows NT platform, this problem has to be fixed. The
>
> performance improvement of 1.3 is great, but we cannot use
>
> it if we can't log off the user without killing our
>
> applications.
>
>
>
> We choose Java on Win NT as our development platform
>
> because it allowed us to have the flexibility to choose
>
> more scalable platforms (ie SUN) in the future, while
>
> taking advantage of the lower start up costs of the PC
>
> platform. Making server side Java unusable on Win NT will
>
> make this a less attractive option.
>
> Tue May 16 14:14:02 PDT 2000
> Tue May 16 14:20:59 PDT 2000
> srinin <mailto:[EMAIL PROTECTED]>
>
> We use ServiceMaster to wrap our Java applications as
>
> services on NT. With JDK1.2.2, the services continued to
>
> work even after the user logged out. In JDK 1.3, the
>
> services stop as soon as the user logs out. This is a huge
>
> problem for us in our production environment, as we want
>
> our server side java applications to restart automatically
>
> after a power failure or reboot.
>
>
>
> We can not migrate to JDK 1.3 until this bug is fixed or a
>
> workaround is provided.
>
> Tue May 16 17:14:34 PDT 2000
> tsugane
>
> same problem happen with java2-sdk1.3.0 on win2000
>
> and winNT4.0.
>
> application is JRUN2.2.3 and Jakarta-tomcat-NT-service1.1.
>
> Tue May 30 06:56:47 PDT 2000
> djcraz_e <mailto:[EMAIL PROTECTED]>
>
> This is a serious bug!!! I cannot advise my company to use the JDK 1.3 if
> this kind of know bug is allowed to
>
> remain! It will seriously hamper our web development process to have to code
> our services around having a
>
> user logged on at all times!
>
> Tue May 30 06:59:16 PDT 2000
> BobW1
>
> This problem needs to be resolved. Our web server was
>
> shutdown about a dozen times (affecting about 8 developers
>
> each time) before we discovered that HotSpot was causing
>
> our web server (IIS) to go down. IIS was going down since
>
> our servlet engine was using 1.3 and was tied into IIS.
>
> We've now gone back to classic JVM 1.2.2 to prevent our web
>
> server from going down.
>
> Fri Jun 02 19:20:49 PDT 2000
> briano <mailto:[EMAIL PROTECTED]>
>
> This is not a bug in the VM, but the service wrapper. The service wrapper
> that I wrote (specifically for
>
> Java2) doesn't have any problem with JDK1.3 when the user logs out. Even for
> JDK1.2 I had to
>
> provide my own handler with SetConsoleCtrlHandler in order to keep the
> service running when logging out.
>
> The key difference may be that I also had to call AllocConsole in order for
> the handler to get properly
>
> registered.
>
> Wed Jun 07 03:29:40 PDT 2000
> huykman <mailto:[EMAIL PROTECTED]>
>
> I would say this is a bug, it doesn't matter in what part
>
> of java it occures. To take java 1.3 seriously on NT, it
>
> should work at least as good as 1.2 versions.
>
> I've tried jdk 1.3 on TomCat 3.1 & Jrun 3.0 and both gave
>
> the same problem.
>
> Mon Jun 12 11:19:32 PDT 2000
> briano <mailto:[EMAIL PROTECTED]>
>
> I've been getting a bunch of questions from people regarding my Java service
> wrapper. Although I developed
>
> it for my company and it is proprietary, I can still offer pointers. I
> developed it last year for JDK1.2, but it
>
> works just fine with JDK1.3 without any modifications. Unlike some other
> service wrappers that spawn off
>
> another process, this one creates a JVM in the same process using the
> invocation API. I install my console
>
> event handler immediately after I've created the JVM, in order for it to be
> called first. Now, I didn't have any
>
> luck at this (under JDK1.2 even) until I added a call to AllocConsole at the
> beginning of the service's start
>
> callback. I think this is the magic step in order to make this work
> reliably. Calling AllocConsole does not
>
> produce a visible console window unless the service is set to interact with
> the desktop. Here's a skeleton
>
> version of my console event handler:
>
>
>
> // Console event handler routine.
>
> BOOL handlerRoutine(DWORD dwCtrlType) {
>
> switch (dwCtrlType) {
>
>
>
> case CTRL_C_EVENT:
>
> case CTRL_CLOSE_EVENT:
>
> case CTRL_SHUTDOWN_EVENT:
>
> // Call method to stop service
>
> ...
>
> return TRUE;
>
>
>
> case CTRL_LOGOFF_EVENT:
>
> // Ignore logoff events.
>
> return TRUE;
>
> }
>
>
>
> // Let parent handler (the VM) take care of anything else.
>
> return FALSE;
>
> }
>
> Tue Jun 13 07:50:05 PDT 2000
> bgiel <mailto:[EMAIL PROTECTED]>
>
> Thanks for posting the above. Unfortunately, the workaround cannot be
> implemented with canned wrappers
>
> like SRVANY and others that generically install services including, but not
> limited to, Java. The problem
>
> persists when JDK 1.3's java.exe is spawned by the service wrapper (rather
> than using JNI invocation.) I
>
> believe this needs to be addressed by JavaSoft so that the JDK 1.3 runtime
> responds to a logoff in the same
>
> manner as JDK 1.2.2.
>
> Tue Jun 13 15:30:32 PDT 2000
> briano <mailto:[EMAIL PROTECTED]>
>
> JDK1.2.2 didn't actually respond correctly to the logoff event or close
> event. Instead of stopping the
>
> process, these would cause a thread dump to be printed to error out just
> like with ctrl-break. If JDK1.3
>
> ignored the logoff event completely, then when a user running a client app
> logs out from windows, the VM
>
> might not shut down gracefully and the Java exit hooks won't get invoked.
> I'm not sure if the VM could tell
>
> whether it was being run as a service or not. If its running as a service,
> the logoff event can be ignored,
>
> but it cannot be ignored otherwise.
>
> Wed Jun 14 05:00:23 PDT 2000
> pillon <mailto:[EMAIL PROTECTED]>
>
> A solution is to write a genric launcher class in java.
>
> The launcher will just overide 'handlerRoutine' with JNI
>
> and then call your main class with the proper parameters.
>
>
>
> To execute 'com.company.server.Main arg1 arg 2' as a sevice
>
> you'll execute 'Launcher com.company.server.Main arg1 arg
>
> 2' instead.
>
>
>
> This can be used with virtually any service wrapper.
>
> Thu Jun 15 02:17:09 PDT 2000
> ArionYu <mailto:[EMAIL PROTECTED]>
>
> I agree that application run by the clients should be stopped after logout,
> if not specified purposely (eg
>
> install as service).
>
>
>
> If JavaSoft can kindly develop a NT service wrapper for Java application, I
> think the problem would be
>
> solved. At least the JavaSoft developers won't need to have JVM support most
> (if not all) wrappers.
>
> Thu Jun 15 18:36:20 PDT 2000
> gdaswani
>
> Anybody know when this will be fixed?
>
> Fri Jun 16 13:20:13 PDT 2000
> nywarrior <mailto:[EMAIL PROTECTED]>
>
> This is a bug!! I had the same problem installing a java
>
> based service with invoker.exe, and had to revert back to
>
> jre1.2.2. This problem seemed to be introduced in jre1.3.
>
> Everything works fine for me using jre1.2.2.
>
> Thu Jun 22 23:57:25 PDT 2000
> pgaston
>
> take a look at
>
> http://www.kcmultimedia.com/javaserv/
>
> for working JNI service wrapper
>
> Mon Jun 26 08:50:17 PDT 2000
> glabelle <mailto:[EMAIL PROTECTED]>
>
> We picked up an excellent NT Service package at
> http://jsrvany.sourceforge.net . It includes C++ source
>
> for the service installer and runtime wrapper, and nice Java classes which
> make it easy to implement
>
> handlers for the NT Service events, including "stop"/"pause"/"continue",
> which was lacking in most of the
>
> other packages we evaluated.
>
>
>
> The jsrvany package doesn't solve the the JDK 1.3 bug, but I think it's an
> excellent base on which to
>
> experiment with briano's SetConsoleCtrlHandler() / AllocConsole() solution.
>
> Mon Jun 26 19:04:13 PDT 2000
> subc <mailto:[EMAIL PROTECTED]>
>
> It's like "Hotel California"... you can check in BUT can't check out. We
> just found
>
> it the hard way... in PRODUCTION... while doing a $3 Billion Dollar Trade in
> Java...
>
> thanks to JavaSoft for making me look like a moron in front of my users!!!
>
> Few more bugs like this... the users will force us back to doing Demo
> programs in JDK 1.1.0!!!
>
> Not even a patch release!!! I got a better idea... why don't you CLOSE this
> bug - like you
>
> do with all other critical ones!!! Mark it un-reproducible with NT Service
> Pack 9.8.7.6.5.4.3.2.1.
>
> Wed Jun 28 22:34:44 PDT 2000
> develcon <mailto:[EMAIL PROTECTED]>
>
> I know it is humiliating to chase MS with the NT/2k Server "service" mess,
> but your customers really need
>
> robust support to provide competitive Java(tm) applications. In my opinion
> if you don't support "service's"
>
> then you don't support Windows.
>
>
>
> Please deliver a complete solution (included with the JDK), and fix this bug
> too.
>
> Fri Jul 07 13:10:20 PDT 2000
> adepue <mailto:[EMAIL PROTECTED]>
>
> In case anyone is interested, I have recently posted a free
>
> utility that allows you to run your Java app as an NT
>
> service. It shields the JVM from the NT logoff event (by
>
> running the JVM in the service process and handling the
>
> related events) AND (optionally) allows you to specify a
>
> method in your Java code to perform graceful shutdowns when
>
> the service is stopped. Check out
>
> http://www.eworksmart.com/jnt
>
> Sat Jul 08 10:33:52 PDT 2000
> dynaware <mailto:[EMAIL PROTECTED]>
>
> I just patched my Java Service Launcher with the above described
> AllocConsole, SetCosnsolCtrlHAndler
>
> approch. It's available at www.roeschter.com.
>
> Moreover I want to point out that there is also a solution for all those
> using off the shelf service launchers.
>
> It's feasable to recompile the java.exe from SUN's sources with a small
> patch which catches the
>
> LOGOFF event.
>
> This can be achieved by installing the ControlHandler after the JVM has been
> initialized but before
>
> the main() method is called.
>
>
>
> For details please contact me at [EMAIL PROTECTED]
>
> or look into for the source of my JSL (specifically java.c)
>
> at www.roeschter.com
>
> Sun Jul 09 04:49:33 PDT 2000
> macpeep
>
> Ok, this bug has enough votes.. They get the point.. Please
>
> vote for this bug instead: (4314208)
>
> http://developer.java.sun.com/developer/bugParade/bugs/43142
>
> 08.html
>
>
>
> That bug is a serious screen distortion for several widgets
>
> on Java 1.3 on Win32 on some hardware setups. It makes 1.3
>
> apps with GUI's totally unfeasible since they won't work on
>
> many very common systems.
>
> Wed Jul 19 08:29:09 PDT 2000
> k30a2e7 <mailto:[EMAIL PROTECTED]>
>
> Why not just add a "-Xservice" command line option that will make the JVM
> not respond to the
>
> CTRL_LOGOFF_EVENT? This should be really easy to implement, and would take
> care of this bug for good...
>
> Sat Jul 22 20:22:34 PDT 2000
> druble
>
> Fix ASAP please!
>
> Wed Jul 26 14:27:35 PDT 2000
> xxh1 <mailto:[EMAIL PROTECTED]>
>
> As of July 25 javaserv doesn't handle this, though it claims to.
>
> I modified javaserv source using jsl source code as a model and
>
> ended up with a working solution. I passed on jsl because it
>
> appeared to rely on the service monitoring a socket. I may
>
> reevaluate my decision. Anyway -- key point is that you'll
>
> just get frustrated if you use javaserv out of the box -- modify
>
> it as per jsl!
>
> Thu Jul 27 14:30:39 PDT 2000
> the_hendrys <mailto:[EMAIL PROTECTED]>
>
> This is a Bug!! Our process works fine using 1.2.2, but when using 1.3, a
> log-out kills the process.
>
> Fri Jul 28 14:54:39 PDT 2000
> b.c
>
> This is indeed a pretty nasty bug.
>
> I hope Sun gets with it and fixes it as there
>
> are a LOT of people who need to be able
>
> to have services running when a user merely logs out.
>
> Fri Jul 28 17:45:39 PDT 2000
> westly <mailto:[EMAIL PROTECTED]>
>
> We use ServiceMaster to wrap our Java applications as
>
> services on NT. With JDK1.2.2, the services continued to
>
> work even after the user logged out. In JDK 1.3, the
>
> services stop as soon as the user logs out. This is a huge
>
> problem for us in our production environment, as we want
>
> our server side java applications to restart automatically
>
> after a power failure or reboot.
>
>
>
> We can not migrate to JDK 1.3 until this bug is fixed or a
>
> workaround is provided.
>
>
>
> Thu Aug 03 05:27:53 PDT 2000
> buiret <mailto:[EMAIL PROTECTED]>
>
> I also say that this is a bug: I use RunExecSvce from WinWinsoft and it
> works well with JRE 1.2 but not
>
> at all with JRE 1.3.
>
> I took me a long time to identify the problem !
>
> Tue Aug 08 11:41:03 PDT 2000
> kenchen <mailto:[EMAIL PROTECTED]>
>
> This is a HotSpot bug! It happens when you use JDK with
>
> HotSpot. JDK 1.3 comes with HotSpot by default. I tried
>
> different combinations with JDK 1.2.2, 1.3 with/without
>
> HotSpot on ServletExec 3.0 and the only combination work is
>
> JDK 1.2.2 Classic. Others kill IIS when a user logs out.
>
> Tue Aug 08 16:53:45 PDT 2000
> kurt <mailto:[EMAIL PROTECTED]>
>
> This problem also manifests itself when the JVM is started
>
> by the JNI Invokation API (JNI_CreateJavaVM()) instead of
>
> the service doing CreateProcess on java.exe. This is with
>
> JDK 1.3 on Windows 2000.
>
>
>
> In this case, a thread is creating the JVM and calling into
>
> a static Java method that is designed to not return. When
>
> the user logs out, that thread is destroyed without
>
> returning from the static Java method.
>
> Tue Aug 29 05:58:09 PDT 2000
> Anja.Niebler <mailto:[EMAIL PROTECTED]>
>
> Here is the complete c code of a NT-Service starter, that
>
> stays, if it got an LOGOFF-Event.
>
> And additionaly a excample of a java class.
>
> The most important part is to LEAVE the main method of the
>
> java-class, so that a CtrlHandler can be installed after
>
> calling the main method of the java-class.
>
> ///////////////////////////////////////////////////////////
>
> // Program, that starts the java virtual machine and
>
> handles console events by itself
>
> // This program can be used for starting an NTService with
>
> JDK 1.3.0
>
>
>
> // includes
>
> #include <jni.h>
>
> #include <windows.h>
>
> #include <string.h>
>
>
>
> // typedefs
>
> typedef jint (*P_JNI_GetDefaultJavaVMInitArgs)(void *args);
>
> typedef jint (*P_JNI_CreateJavaVM)(JavaVM **pvm, JNIEnv **
>
> penv, void *args);
>
>
>
>
>
>
>
> /***********************************************************
>
> *****************
>
> Usage of the program.
>
> ************************************************************
>
> ****************/
>
> void printInfo()
>
> {
>
> printf("no parameter found.\n");
>
> printf("Usage: \n");
>
> printf("Parameters are.\n");
>
> printf("arg[1] : jvm library e.g.
>
> c:\\jdk\\jre\\bin\\classic\\jvm.dll \n");
>
> printf("arg[2] : classpath
>
> e.g. c:\\myclasses\\myproject.jar \n");
>
> printf("arg[3] : lib-path
>
> e.g c:\\mylibs \n");
>
> printf("arg[4] : java-class-file e.g. MyMain
>
> \n");
>
> printf("arg[5]ff: additional parameters for main-
>
> method in MyMain.class\n");
>
> }
>
> /***********************************************************
>
> *****************
>
> static globals.
>
> ************************************************************
>
> ****************/
>
> static HMODULE hLib
>
> = NULL;
>
> static JavaVM *jvm
>
> = NULL;
>
> static JNIEnv *env
>
> = NULL;
>
> static JavaVMInitArgs vm_args;
>
> static jclass clsMain
>
> = NULL;
>
> static jclass clsString
>
> = NULL;
>
> static jmethodID midMain
>
> = 0;
>
> static JavaVMOption options[20];
>
>
>
> /***********************************************************
>
> *****************
>
> Invoke JVM and call of the static main method of the
>
> given javaclass
>
> ************************************************************
>
> ****************/
>
> int __cdecl invokeJVM(int argc, char* argv[])
>
> {
>
> P_JNI_GetDefaultJavaVMInitArgs
>
> pfnGetDefaultJavaVMInitArgs = NULL;
>
> P_JNI_CreateJavaVM
>
> pfnCreateJavaVM =
>
> NULL;
>
> jint
>
> res
>
> = -1;
>
> jstring
>
> jsTemp;
>
> jarray
>
> stringArray;
>
>
>
> char
>
> clsOptions[255];
>
> char
>
> libOptions[255];
>
> char
>
> jvmLibrary[255];
>
> char
>
> czTemp[100];
>
> int
>
> i;
>
>
>
> // Load JVM library (jvm.dll)
>
> strcpy (jvmLibrary, argv[1]);
>
> hLib = LoadLibrary(jvmLibrary);
>
> if(hLib == NULL)
>
> {
>
> printf ("Cannot load library %s",
>
> jvmLibrary);
>
> return 0;
>
> }
>
>
>
> // ClassPath
>
> strcpy (clsOptions, "-Djava.class.path=");
>
> strcat (clsOptions, argv[2]);
>
> // LibPath
>
> strcpy (libOptions, "-Djava.library.path=");
>
> strcat (libOptions, argv[3]);
>
>
>
> // JDK 1.3.0 Options
>
> options[0].optionString = clsOptions;
>
> options[1].optionString = libOptions;
>
>
>
> vm_args.version = JNI_VERSION_1_2;
>
> vm_args.options = options;
>
> vm_args.nOptions = 2;
>
> vm_args.ignoreUnrecognized = TRUE;
>
>
>
> // Create JavaVM
>
> pfnCreateJavaVM = (P_JNI_CreateJavaVM)
>
> GetProcAddress(hLib, "JNI_CreateJavaVM");
>
> if(pfnCreateJavaVM != NULL)
>
> {
>
> res = (*pfnCreateJavaVM)
>
> (&jvm,&env,&vm_args);
>
> if (res < 0)
>
> {
>
> printf("Error! Cannot create Java
>
> VM");
>
> return 0;
>
> }
>
> }
>
> else
>
> {
>
> printf("Error! Cannot create Java VM,
>
> function pointer = null");
>
> return 0;
>
> }
>
>
>
> // FindClass argv[4]
>
> clsMain = (*env)->FindClass(env, argv[4]);
>
> if (clsMain == 0)
>
> {
>
> printf("Cannot find Class %s", argv[4]);
>
> return 0;
>
> }
>
>
>
> // FindClass String
>
> clsString = (*env)->FindClass
>
> (env, "java/lang/String");
>
> if (clsString == 0)
>
> {
>
> printf("Cannot find Class String");
>
> return 0;
>
> }
>
>
>
> // get methodId of Main.main
>
> midMain = (*env)->GetStaticMethodID(env,
>
> clsMain, "main", "([Ljava/lang/String;)V");
>
> if (midMain == 0)
>
> {
>
> printf("Cannot find Method %s.main", argv
>
> [4]);
>
> return 0;
>
> }
>
>
>
> // prepare the StringArray for the main-method of
>
> the java class
>
> strcpy (czTemp, argv[0]);
>
> jsTemp = (*env)->NewStringUTF (env, czTemp);
>
> if (argc>5)
>
> stringArray = (*env)->NewObjectArray(env,
>
> argc-5, clsString, jsTemp);
>
> else
>
> stringArray = (*env)->NewObjectArray(env,
>
> 0, clsString, jsTemp);
>
> if (stringArray == 0)
>
> {
>
> printf("Cannot create String Array");
>
> return 0;
>
> }
>
>
>
> for (i=5; i<argc; i++)
>
> {
>
> strcpy (czTemp, argv[i]);
>
> jsTemp = (*env)->NewStringUTF (env, czTemp);
>
> (*env)->SetObjectArrayElement(env,
>
> stringArray, i-5, jsTemp);
>
> }
>
>
>
> // call Main.main
>
> // remark: Ensure, that the main method of the java-
>
> class returns.
>
> // If the java-class is a server application, the
>
> application should start
>
> // as an own thread.
>
> (*env)->CallStaticVoidMethod(env, clsMain, midMain,
>
> stringArray);
>
>
>
> return 1;
>
> }
>
>
>
> // Console event handler routine.
>
> // returns true, if the event will be handled by this
>
> routine
>
> // returns false, if the parent handler is responsible for
>
> the event
>
> BOOL WINAPI CtrlHandler(DWORD fdwCtrlType)
>
> {
>
> switch (fdwCtrlType)
>
> {
>
> case CTRL_C_EVENT:
>
> {
>
> // for future releases...
>
> // call here a exit methode
>
> of the Java-class
>
> printf("got Ctrl C\n");
>
> return FALSE;
>
> break;
>
> };
>
> case CTRL_CLOSE_EVENT:
>
> {
>
> printf("got CloseEvent\n");
>
> return TRUE;
>
> break;
>
> };
>
> case CTRL_SHUTDOWN_EVENT:
>
> {
>
> printf("got
>
> ShutdownEvent\n");
>
> return TRUE;
>
> break;
>
> };
>
>
>
> // react on this event to install a service
>
> on WinNT-Server with JDK 1.3.0
>
> case CTRL_LOGOFF_EVENT:
>
> {
>
> printf("got
>
> ShutdownEvent\n");
>
> return TRUE;
>
> break;
>
> };
>
> }
>
> return FALSE;
>
> }
>
>
>
> int __cdecl main(int argc, char* argv[])
>
> {
>
> int res=0;
>
> BOOL fSuccess;
>
> HANDLE hServerStopEvent = NULL;
>
>
>
> if (argc<5)
>
> {
>
> printInfo();
>
> return 0;
>
> }
>
>
>
> // Create a Stop Event
>
> hServerStopEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
>
>
>
> // start java virtual machine
>
> printf("Starting VM...");
>
> res = invokeJVM(argc, argv);
>
> if (res!=0)
>
> {
>
> printf("VM started...");
>
> }
>
> else
>
> {
>
> printf("cannot start VM !");
>
> return 0;
>
> }
>
>
>
> // install the CtrlHandler
>
> fSuccess = SetConsoleCtrlHandler((PHANDLER_ROUTINE)
>
> CtrlHandler, TRUE); // add to
>
> list
>
> if (! fSuccess)
>
> {
>
> printf("Could not set control handler");
>
> return 0;
>
> }
>
> else
>
> {
>
> printf("set control handler");
>
> }
>
>
>
> //wait
>
> WaitForSingleObject(hServerStopEvent,INFINITE);
>
> return 0;
>
> }
>
>
>
>
>
> /**
>
> * Class T, excample for starting an NT Service
>
> */
>
> class T
>
> {
>
> public static void main( String[] args )
>
> {
>
> // Most important: start an own thread
>
> Thread t= new Thread()
>
> {
>
> public void run()
>
> {
>
> while (true)
>
> {
>
> System.out.print("in Thread...\n");
>
> try
>
> {
>
> sleep(1000);
>
> }
>
> catch (Exception e)
>
> {
>
> e.printStackTrace();
>
> }
>
> }
>
> }
>
> };
>
> t.start();
>
> System.out.print(args[0]);
>
> // then exit the main method
>
> };
>
> };
>
>
>
> Thu Sep 14 13:49:53 PDT 2000
> ebony_prince2 <mailto:[EMAIL PROTECTED]>
>
> How do I get back my virtual machine?
>
> Mon Sep 18 06:43:30 PDT 2000
> javafarabi <mailto:[EMAIL PROTECTED]>
>
> Problem browsing applet in environment Mac Netscape, you
>
> have have reponse. plis sending your message======>
>
> Message error
>
> 8/25/2000 @ 15:54:53
>
> An exception occurred:
>
> java.lang.ClassNotFoundException: com.hostfront.HFEmulator
>
> at
>
> com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
>
> (JMAppletClassLoaderOld.java)
>
> at
>
> com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
>
> (JMAppletClassLoaderOld.java)
>
> at
>
> com.apple.mrj.JManager.JMAppletClassLoader_ROOT.loadClass
>
> (JMAppletClassLoaderOld.java)
>
> at
>
> com.apple.mrj.JManager.JMAppletViewer_OLD.doLoadCode
>
> (JMAppletViewerOld.java)
>
> at
>
> com.apple.mrj.JManager.JMAppletViewer_OLD.setState
>
> (JMAppletViewerOld.java)
>
> at com.apple.mrj.JManager.JMViewerEvent.post
>
> (JMAppletViewerOld.java)
>
> at com.apple.mrj.JManager.AVDispatcherThread.run
>
> (JMAppletViewerOld.java)
>
> 9/11/2000 @ 13:27:23
>
> An exception occurred:
>
> java.lang.ClassNotFoundException: com.hostfront.HFEmulator
>
> at
>
> com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
>
> (JMAppletClassLoaderOld.java)
>
> at
>
> com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
>
> (JMAppletClassLoaderOld.java)
>
> at
>
> com.apple.mrj.JManager.JMAppletClassLoader_ROOT.loadClass
>
> (JMAppletClassLoaderOld.java)
>
> at
>
> com.apple.mrj.JManager.JMAppletViewer_OLD.doLoadCode
>
> (JMAppletViewerOld.java)
>
> at
>
> com.apple.mrj.JManager.JMAppletViewer_OLD.setState
>
> (JMAppletViewerOld.java)
>
> at com.apple.mrj.JManager.JMViewerEvent.post
>
> (JMAppletViewerOld.java)
>
> at com.apple.mrj.JManager.AVDispatcherThread.run
>
> (JMAppletViewerOld.java)
>
> 9/11/2000 @ 13:28:18
>
> An exception occurred:
>
> java.lang.ClassNotFoundException: com.hostfront.HFEmulator
>
> at
>
> com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
>
> (JMAppletClassLoaderOld.java)
>
> at
>
> com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
>
> (JMAppletClassLoaderOld.java)
>
> at
>
> com.apple.mrj.JManager.JMAppletClassLoader_ROOT.loadClass
>
> (JMAppletClassLoaderOld.java)
>
> at
>
> com.apple.mrj.JManager.JMAppletViewer_OLD.doLoadCode
>
> (JMAppletViewerOld.java)
>
> at
>
> com.apple.mrj.JManager.JMAppletViewer_OLD.setState
>
> (JMAppletViewerOld.java)
>
> at com.apple.mrj.JManager.JMViewerEvent.post
>
> (JMAppletViewerOld.java)
>
> at com.apple.mrj.JManager.AVDispatcherThread.run
>
> (JMAppletViewerOld.java)
>
> 9/12/2000 @ 11:30:45
>
> An exception occurred:
>
> java.lang.ClassNotFoundException: com.hostfront.HFEmulator
>
> at
>
> com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
>
> (JMAppletClassLoaderOld.java)
>
> at
>
> com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
>
> (JMAppletClassLoaderOld.java)
>
> at
>
> com.apple.mrj.JManager.JMAppletClassLoader_ROOT.loadClass
>
> (JMAppletClassLoaderOld.java)
>
> at
>
> com.apple.mrj.JManager.JMAppletViewer_OLD.doLoadCode
>
> (JMAppletViewerOld.java)
>
> at
>
> com.apple.mrj.JManager.JMAppletViewer_OLD.setState
>
> (JMAppletViewerOld.java)
>
> at com.apple.mrj.JManager.JMViewerEvent.post
>
> (JMAppletViewerOld.java)
>
> at com.apple.mrj.JManager.AVDispatcherThread.run
>
> (JMAppletViewerOld.java)
>
>
>
>
>
> [EMAIL PROTECTED]
>
> Mon Sep 18 06:46:45 PDT 2000
> javafarabi <mailto:[EMAIL PROTECTED]>
>
> Problem browsing applet in environment Mac Netscape, you
>
> have have reponse. plis sending your message======>
>
> Message error
>
> 9/16/2000 @ 15:54:53
>
> An exception occurred:
>
> java.lang.ClassNotFoundException: com.hostfront.HFEmulator
>
> at
>
> com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
>
> (JMAppletClassLoaderOld.java)
>
> at
>
> com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
>
> (JMAppletClassLoaderOld.java)
>
> at
>
> com.apple.mrj.JManager.JMAppletClassLoader_ROOT.loadClass
>
> (JMAppletClassLoaderOld.java)
>
> at
>
> com.apple.mrj.JManager.JMAppletViewer_OLD.doLoadCode
>
> (JMAppletViewerOld.java)
>
> at
>
> com.apple.mrj.JManager.JMAppletViewer_OLD.setState
>
> (JMAppletViewerOld.java)
>
> at com.apple.mrj.JManager.JMViewerEvent.post
>
> (JMAppletViewerOld.java)
>
> at com.apple.mrj.JManager.AVDispatcherThread.run
>
> (JMAppletViewerOld.java)
>
> 9/11/2000 @ 13:27:23
>
> An exception occurred:
>
> java.lang.ClassNotFoundException: com.hostfront.HFEmulator
>
> at
>
> com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
>
> (JMAppletClassLoaderOld.java)
>
> at
>
> com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
>
> (JMAppletClassLoaderOld.java)
>
> at
>
> com.apple.mrj.JManager.JMAppletClassLoader_ROOT.loadClass
>
> (JMAppletClassLoaderOld.java)
>
> at
>
> com.apple.mrj.JManager.JMAppletViewer_OLD.doLoadCode
>
> (JMAppletViewerOld.java)
>
> at
>
> com.apple.mrj.JManager.JMAppletViewer_OLD.setState
>
> (JMAppletViewerOld.java)
>
> at com.apple.mrj.JManager.JMViewerEvent.post
>
> (JMAppletViewerOld.java)
>
> at com.apple.mrj.JManager.AVDispatcherThread.run
>
> (JMAppletViewerOld.java)
>
> 9/11/2000 @ 13:28:18
>
> An exception occurred:
>
> java.lang.ClassNotFoundException: com.hostfront.HFEmulator
>
> at
>
> com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
>
> (JMAppletClassLoaderOld.java)
>
> at
>
> com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
>
> (JMAppletClassLoaderOld.java)
>
> at
>
> com.apple.mrj.JManager.JMAppletClassLoader_ROOT.loadClass
>
> (JMAppletClassLoaderOld.java)
>
> at
>
> com.apple.mrj.JManager.JMAppletViewer_OLD.doLoadCode
>
> (JMAppletViewerOld.java)
>
> at
>
> com.apple.mrj.JManager.JMAppletViewer_OLD.setState
>
> (JMAppletViewerOld.java)
>
> at com.apple.mrj.JManager.JMViewerEvent.post
>
> (JMAppletViewerOld.java)
>
> at com.apple.mrj.JManager.AVDispatcherThread.run
>
> (JMAppletViewerOld.java)
>
> 9/12/2000 @ 11:30:45
>
> An exception occurred:
>
> java.lang.ClassNotFoundException: com.hostfront.HFEmulator
>
> at
>
> com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
>
> (JMAppletClassLoaderOld.java)
>
> at
>
> com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
>
> (JMAppletClassLoaderOld.java)
>
> at
>
> com.apple.mrj.JManager.JMAppletClassLoader_ROOT.loadClass
>
> (JMAppletClassLoaderOld.java)
>
> at
>
> com.apple.mrj.JManager.JMAppletViewer_OLD.doLoadCode
>
> (JMAppletViewerOld.java)
>
> at
>
> com.apple.mrj.JManager.JMAppletViewer_OLD.setState
>
> (JMAppletViewerOld.java)
>
> at com.apple.mrj.JManager.JMViewerEvent.post
>
> (JMAppletViewerOld.java)
>
> at com.apple.mrj.JManager.AVDispatcherThread.run
>
> (JMAppletViewerOld.java)
>
>
>
>
>
> [EMAIL PROTECTED]
>
>
>
>
>
> <http://developer.java.sun.com/servlet/PrintPageServlet> Print Button
> [ This page was updated: 21-Sep-2000 ]
> By Alê!
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
> ------------------------------ LISTA SOUJAVA ----------------------------
> http://www.soujava.org.br - Sociedade de Usuários Java da Sucesu-SP
> dúvidas mais comuns: http://www.soujava.org.br/faq.htm
> regras da lista: http://www.soujava.org.br/regras.htm
> para sair da lista: envie email para [EMAIL PROTECTED]
> -------------------------------------------------------------------------
>
> printbutton.gif
>
> Content-Type:
>
> image/gif
> Content-Encoding:
>
> base64
>
>
> ------------------------------------------------------------------------
> attachment.txt
>
> Content-Type:
>
> text/plain
> Content-Encoding:
>
> Quoted-printable
--
Eduardo Issao Ito <[EMAIL PROTECTED]>
Integration Technologies Ltda. <http://www.integrationtech.com.br>
Rua Marina Saddi Haidar, 176
04650-050 / Sao Paulo / SP / Brasil
Phone: +55 11 5522-4848 x311
Fax: +55 11 5524-1125
------------------------------ LISTA SOUJAVA ----------------------------
http://www.soujava.org.br - Sociedade de Usuários Java da Sucesu-SP
dúvidas mais comuns: http://www.soujava.org.br/faq.htm
regras da lista: http://www.soujava.org.br/regras.htm
para sair da lista: envie email para [EMAIL PROTECTED]
-------------------------------------------------------------------------
