I have an applet packaged with a third part dll (from JTwain). My applet scans documents from the TWAIN compatible default printer. The applet fails on a paper jam and won't recover. The user navigates away from the page and the applet is destroyed. When returning to the page it fails again. Closing the browser (which kills java.exe process on the pc), and then returning to the page clears the problem and everything works.
I want to restart everything without requiring users to close down the browser. I've added a GUID query string to the URL's from which the applets resources are loaded - so I know nothing is being cached. I've checked in the windows task manager and there is no process created by the dll, it's all happening within the main java.exe process. I tried wrapping the scanning process in a thread so I could interrupt it in the stop or destroy methods (just in case the applets thread weren't stopped when the applet was destroyed), but that didn't work.
Any suggest would be greatly appreciated. Ideally I'd like some way to restart java when the applet unloads (but I doubt that's possible).
UPDATE
I've spent a couple of days trying to identify what causes the applet to fail. I still don't know :(
When the paper jam occurs something (not my code), is producing a couple of popups. The first alerts the user of the jam, and can be closed by clicking the OK button. The second says 'reading from device' and hangs. It cannot be close with the red, close window, icon in the top corner - I kill it from the task manager and windows asks to send a report regarding the 'non-responsive program'. I assume these popups are produced by the dll. And given that the second hangs, my assumption is that a thread started by the dll has hung while retaining a lock on some component of the TWAIN application. I get
com.asprise.util.jtwain.JTwainException: Failed to open the specified data source:
Source: TW-Brother MFC-9970CDW LAN Thrown
..when I try to access the scanner.
I'm at a bit of a loss as to how I can get more information. I'm testing my applet on a windows virtual pc (so as to use ie7), and don't have a method for step debugging in this environment. (And it's crashing on third party code for which I have no source anyway)
I see only two practical options here:
Use an API that handles paper jam without problems. Of course, that is easy to say (get robust API), harder to find.
Launch the app. free floating using Java Web Start. If it freezes up, the user can kill it and click the link for another instance in a new JVM. Or the applet might also call BasicService.showDocument(URLof.jnlp) if it can detect a problem with the DLL and is not itself frozen.
Of course, you should also report the bug to the ..Asprise(?) developers. The optimal solution would be to have the problem fixed at its source. Anything we do here is a 'workaround'.
Related
I'm trying to build a report-building tool (which has a UI written in JavaFX) that has the following features:
When the system (re-)boots, it should auto-start in the background (without showing the UI)
It should have an icon in the system tray
The UI should only show when the user clicks on the system tray icon
A report should be generated either once a day/week/month, at a specific time, automatically
It should "snooze/sleep" in the interim period and use minimal resources while it awaits the next trigger time
It should show a toast pop-up / Windows notification / whatever when a new report has been generated
(The bold ones are the real problems, the italics are maybe solvable--given some resources I found--and the un-formatted one I have a work-around for, namely to place it on in the Startup folder in the AppData folder of the users' machine.)
But the clincher is the following: due to my company's policies, I'm NOT allowed to build register it as a Windows service. Also, converting it into a web service, placing it on a server, and using Control-M (or a cron expression) are also off the table. (That's a long story for another day.) I'm not sure how to implement it and I've been stuck on this for a bit.
I've taken a look at Quartz, this other StackOverflow question, and some other resources on how to run the Java app in the background, but most resources tell me to add it as a Windows service and I keep hitting a brick wall. Also, I don't know how much of an effect the application would have on the users' machines if I ran the application in the background with the solutions mentioned in the other StackOverflow answer. I need to have a minimal processing footprint in the interim period.
I'm also unsure of how to package the application as an EXE. For now, I'm going to turn it into an executable JAR. (Any help on this would also be welcome.)
I'm open to any suggestions and ideas and even other resources to look at for further reading. Anything to help me out here is welcome.
While running a java Applet in browser, a process java.exe starts and a java console appears if enabled. As long as the process is alive, the console is visible indicating the same.
This process doesn't exit if I to other page or even close the browser. It terminates automatically after some random time. Is there a way to control that time duration?
I've a functionality that starts with an applet , then navigate to some other page for completion. To use it again I return to applet page and here the applet initializes again if the process is already terminated which takes some time. I'd like to extend this time if possible so that applet doesn't initialize again.
Is there a way to control that time duration?
No. (Unless you wrote the browser.)
But your question indicates you have the entire wrong view of what an applet is and should be. That question indicates you think the applet/JVM should be 'in command' of the web pages/browser, whereas it is really just a guest in the web page. The browser/page controls the applet/JVM, not the other way around.
We had to write a Java application which runs on a windows 8 tablet (not RT).
I would much rather have written it using C#, but we really didn't have a choice.
Basically, we use launch4j to wrap our installer executable JAR in an EXE which then installs the appropriate application files and creates shortcuts on the desktop and in the start menu programs folder to ensure that the user sees the icons on the metro start screen.
The Problem
When the application starts up, it checks if any updates are available via a server, if they are available they are downloaded.
The issue that we've seen is that if the application is downloading the updates, and then we turn off the screen and leave it off for at least 30 seconds, once we turn the screen back on, the application is frozen and does not progress.
We then have to kill the app and start it again.
Providing the screen is not turned off again, the downloads finish and the application works fine.
Is there a way to either keep the screen on, keep our process running or detect when the screen comes back on and execute some code when that occurs?
Any help would be greatly appreciated.
Well, I'm on a project that uses rxtxSerial.dll (very buggy by the way).
Anyway, I made a modification on the GUI to make it more user-friendly, initially the program shows up the main window and it's possible to open some other frames where the user can monitor certain devices designed by the company I work for. So when the user wanted to close the hole program and any windows where openend it showed up a dialog asking for the user close the oppened windows himself and then close the program, that was really ugly so I thought: let's make it better; and that's what I made:
when JDialogs that use serial communication are opened I just save a reference for it for future use if the user prompt to close the program than before exit, the program performs the following code to ensure that the respective listeners are called like stop reading from the serial port:
for (Window w : openedWindows)
{
w.getToolkit().getSystemEventQueue().postEvent(
new WindowEvent(w, WindowEvent.WINDOW_CLOSING));
}
The program doesn't crash when the dialogs are closed by the user so there is no problem on the WindowListeners that are responsible for shuting the communication down, and sometimes it crashes when prompt to close while online windows are oppened (in serial communication aspect), actually the crash itself is not visible for the user (just if he look into program's folder the hs_err_pid.log files) and happens about 20% of the closes with online windows. The crash in hs_err are like: siginfo: ExceptionCode=0xc0000005, writing address 0x17adfa88 so what I suppose it's happening is that the dll tries to write to java's memory after it was already closed so the jvm crashes (correct me if I'm wrong).
What I want is a way to not generate those error log files, it can be made fixing the problem or just a way to hide those files, if possible that I thing the answer is not.
One of the possible fixes I thought possible is to force unload the dll before shutting down the jvm itself or "ask for" unload the dll and wait until it's unloaded.
Any ideas?
Thanks in advance.
Solved my problem migrating from rxtx to jSSC: http://code.google.com/p/java-simple-serial-connector/
Now everything is working smooth! Integrated dlls into .jar for Windows, linux, mac and solaris with system auto-detection.
saved my a lot of work!
Still have no clear reason for those crashes.
I have a simple java applet that retrieves an image from a server and prints it out. The only problem is that I get the following java security warning:
Researching on this site and all over the web, some people suggest that I sign the applet (I tried that to no avail) and others suggest that I Modify a local java security setting but that isn't feasible for my clients.
Not only do I get this warning at the start of my applet, but seemingly any time the code attempts to interact with the printer, the dialog re-appears. Also, note that there is no checkbox next to 'Always allow this applet to access the printer'. These symptoms show on any browser.
How do I get java to respect the users choice to allow it to send jobs to the printer?
You might use the JNLP API services in a sand-boxed applet in a plug-in 2 JRE. They will still prompt the user each first time they go to print, but should also put an 'always allow' check-box on the dialog (though it really only applies for that run). See a demo. of the PrintService.
See also the applet info. page that includes a link on the Next Generation in Applet Java Plug-in Technology which "..brings new abilities to applets: such as .. allowing embedded applets to gain full access to the services of Java Web Start."