openjnlp-devel Mailing List for OpenJNLP (Page 2)
Brought to you by:
kherr
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(9) |
Dec
(9) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(2) |
Feb
(7) |
Mar
(6) |
Apr
(9) |
May
(29) |
Jun
(13) |
Jul
(10) |
Aug
|
Sep
(2) |
Oct
|
Nov
(7) |
Dec
(1) |
2003 |
Jan
|
Feb
(3) |
Mar
(1) |
Apr
(4) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2005 |
Jan
|
Feb
|
Mar
(7) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Nathan M. <nm...@vi...> - 2002-11-19 12:23:30
|
Hello OpenJNLP Community, I'm a new user of OpenJNLP. It solves an important problem for me - thanks for a valuable contribution to the JNLP world! I'm using OpenJNLP 0.7 in an environment it's never encountered before: running an application launched with an URL containing query fields. For example: http://myhost/myapp?foo=bar&baz=foo My environment exposed some OpenJNLP bugs - I've attached some patches to address them. Here's a brief explanation of the problems and patches: - IconFactory.java contains an extraneous semicolon that causes compilation to fail with some compilers; it creates an "unreachable statement". - JNLPContentHandler fails to set the resource properties when it builds an ApplicationDescriptor. - FileCacheEntry does not properly deal with resource names such as my example URL, above - it creates badly formed XML documents that do not parse. I've added logic to transform the strings stored in "entry.xml" into a form safe to use in an attribute field or as element text: the dangerous characters <>'"& are replaced with character entity codes that will be properly recognized and parsed by XML compilers such as NanoXML. There's one more change I'd like to make. I might not get to it very quickly, but here's the remaining problem I'd like to fix: the library should *not* apply the same caching logic to .jnlp files that it applies to resources specified in the .jnlp files; it should just fetch the URL once and then use it. As is, it's issuing something like four queries (GET and HEAD) against the same URL - in my case causing the server to perform a lot of wasted work. If/when I'm able to fix this one, I'll send more patches. Thanks again for the great work! Nathan Meyers nm...@vi... Index: src/org/nanode/app/openjnlp/desktop/IconFactory.java =================================================================== retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- src/org/nanode/app/openjnlp/desktop/IconFactory.java 18 Nov 2002 12:04:16 -0000 1.1.1.1 +++ src/org/nanode/app/openjnlp/desktop/IconFactory.java 18 Nov 2002 13:30:21 -0000 1.2 @@ -150,7 +150,7 @@ * @see #getIcon(Descriptor, String, int) */ public static ImageIcon getIcon(Descriptor des, int size) { - return getIcon(des, Information.ICON_DEFAULT, size);; + return getIcon(des, Information.ICON_DEFAULT, size); } /** Index: src/org/nanode/jnlp/JNLPContentHandler.java =================================================================== retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- src/org/nanode/jnlp/JNLPContentHandler.java 18 Nov 2002 12:04:17 -0000 1.1.1.1 +++ src/org/nanode/jnlp/JNLPContentHandler.java 18 Nov 2002 21:52:01 -0000 1.2 @@ -533,6 +533,10 @@ for (Iterator iter = nativelibSet.iterator(); iter.hasNext();) { resources.addReference((Reference) iter.next()); } + + if (props != null) { + resources.setProperties(props); + } descriptor.setContext(jnlpSpec); descriptor.setInformation(information); Index: src/org/nanode/launcher/cache/FileCacheEntry.java =================================================================== retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- src/org/nanode/launcher/cache/FileCacheEntry.java 18 Nov 2002 12:04:19 -0000 1.1.1.1 +++ src/org/nanode/launcher/cache/FileCacheEntry.java 18 Nov 2002 18:51:51 -0000 1.2 @@ -510,7 +510,7 @@ fw.write(" <meta name=\""); fw.write(key); fw.write("\">"); - fw.write(entryMeta.getProperty(key)); + fw.write(xmlEncode(entryMeta.getProperty(key))); fw.write("</meta>\n"); } @@ -524,7 +524,7 @@ fw.write(" <resource href=\""); } - fw.write(rsrc[i].getReference().getURL().toString()); + fw.write(xmlEncode(rsrc[i].getReference().getURL().toString())); fw.write("\" modtime=\""); fw.write(Long.toString(rsrc[i].getLastModified())); fw.write("\" />\n"); @@ -539,6 +539,27 @@ } catch (Exception e) { System.err.println(e); } + } + + /** + * Render a string safe for use in an attribute or element text + * in an XML document. The result should be fully parsable by + * an XML parser. + */ + public static String xmlEncode(String xml) { + StringBuffer result = new StringBuffer(); + for (int i = 0; i < xml.length(); i++) { + char ch = xml.charAt(i); + switch (ch) { + case '<': result.append("<"); break; + case '>': result.append(">"); break; + case '"': result.append("""); break; + case '\'': result.append("'"); break; + case '&': result.append("&"); break; + default: result.append(ch); break; + } + } + return result.toString(); } /** |
From: Jim B. <ji...@fl...> - 2002-09-26 01:35:20
|
Forgive my newbie question, but here goes. If I want to control where the cache directory lives, do I specify it in this file? I can't find any docs pertaining to it. I have written my own little AppHanlder and would like slightly more control about how things are done. Jim |
From: Samuel L G. <sga...@br...> - 2002-09-03 23:27:51
|
Hi All, I have been trying to find any documentation that explains how to automatically associate a mime type with some helper application on IE and Mac, but I couldn't find anything, I will appreciate any directions, or where I can look in the source code to find out how to do this? Thanks in Advance Sam Gabriel |
From: Kevin H. <ke...@na...> - 2002-07-14 16:06:39
|
I finally merged the ver-0-7 branch into the trunk, so all source is synchronized. Nobody should be doing any work on the ver-0-7 branch. Reminder: if you're not sure if you're on the ver-0-7 branch, just do a "cvs update -A ." in the devel directory to get back on the trunk. |
From: Hanasaki J. <han...@ha...> - 2002-07-03 01:00:57
|
There is a single WAR file being deployed under tomcat 4+. The WAR contains several .jar files as resources The .jar files contain code and images The WAR contains subdirectories with images I am looking for a method that will load .gif images from any/all of the above locations. class.getResource is returning URL's of null. Please provide help if you can. Thank you. |
From: Hanasaki J. <han...@ha...> - 2002-07-02 20:05:02
|
Its Linux. Scott Kovatch wrote: > Is this on Mac OS X or Windows? On Mac OS X just set your proxy > information in the Network pref panel and the VM will pick them up. > > Scott > > On Tuesday, July 2, 2002, at 03:38 PM, Kevin Herrboldt wrote: > >> On Tuesday, July 2, 2002, at 01:56 PM, Hanasaki JiJi wrote: >> >>> Modifying the PROPS in the startup script got the proxy config going. >>> >>> HOwever! The application will not run. SwingSet2, from Sun, >>> downloads fine. When it is run, there is a msg that there are no >>> security settings. I clicked "continue" and SwingSet2 did not run. >>> No error was given. Help!??? >> >> >> Is that the OpenJNLP security warning dialog? That is normal. >> SwingSet2 should run fine. (I just tested it on my machine). Do you >> see any messages in the OpenJNLP console window? >> >> One possible reason it might not work is if SwingSet2 tries to >> retrieve network resources. The proxy settings won't be set properly >> for SwingSet2 because it is running in a separate JVM which is not >> invoked using the shell script. >> >> For testing try Cicerone at >> <http://www.puppethead.com/java/apps/Cicerone.jnlp>. It will show you >> what properties are set in the JVM of a launched app. And it's a very >> simple app so if it doesn't work there is something strange going on. >> >> Maybe the OpenJNLP external launcher could be changed to carry forward >> any proxy setting properties. Hmm... >> > > ------------------ > Scott Kovatch > Apple Computer > Java Runtime Classes > Cleveland Hts, OH > sko...@ap... > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Openjnlp-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjnlp-devel > |
From: Scott K. <sko...@ap...> - 2002-07-02 19:50:35
|
Is this on Mac OS X or Windows? On Mac OS X just set your proxy information in the Network pref panel and the VM will pick them up. Scott On Tuesday, July 2, 2002, at 03:38 PM, Kevin Herrboldt wrote: > On Tuesday, July 2, 2002, at 01:56 PM, Hanasaki JiJi wrote: > >> Modifying the PROPS in the startup script got the proxy config going. >> >> HOwever! The application will not run. SwingSet2, from Sun, >> downloads fine. When it is run, there is a msg that there are no >> security settings. I clicked "continue" and SwingSet2 did not run. >> No error was given. Help!??? > > Is that the OpenJNLP security warning dialog? That is normal. > SwingSet2 should run fine. (I just tested it on my machine). Do you > see any messages in the OpenJNLP console window? > > One possible reason it might not work is if SwingSet2 tries to > retrieve network resources. The proxy settings won't be set properly > for SwingSet2 because it is running in a separate JVM which is not > invoked using the shell script. > > For testing try Cicerone at > <http://www.puppethead.com/java/apps/Cicerone.jnlp>. It will show you > what properties are set in the JVM of a launched app. And it's a very > simple app so if it doesn't work there is something strange going on. > > Maybe the OpenJNLP external launcher could be changed to carry forward > any proxy setting properties. Hmm... > ------------------ Scott Kovatch Apple Computer Java Runtime Classes Cleveland Hts, OH sko...@ap... |
From: Kevin H. <ke...@na...> - 2002-07-02 19:38:32
|
On Tuesday, July 2, 2002, at 01:56 PM, Hanasaki JiJi wrote: > Modifying the PROPS in the startup script got the proxy config going. > > HOwever! The application will not run. SwingSet2, from Sun, downloads > fine. When it is run, there is a msg that there are no security > settings. I clicked "continue" and SwingSet2 did not run. No error > was given. Help!??? Is that the OpenJNLP security warning dialog? That is normal. SwingSet2 should run fine. (I just tested it on my machine). Do you see any messages in the OpenJNLP console window? One possible reason it might not work is if SwingSet2 tries to retrieve network resources. The proxy settings won't be set properly for SwingSet2 because it is running in a separate JVM which is not invoked using the shell script. For testing try Cicerone at <http://www.puppethead.com/java/apps/Cicerone.jnlp>. It will show you what properties are set in the JVM of a launched app. And it's a very simple app so if it doesn't work there is something strange going on. Maybe the OpenJNLP external launcher could be changed to carry forward any proxy setting properties. Hmm... |
From: Hanasaki J. <han...@ha...> - 2002-07-02 18:56:04
|
Modifying the PROPS in the startup script got the proxy config going. HOwever! The application will not run. SwingSet2, from Sun, downloads fine. When it is run, there is a msg that there are no security settings. I clicked "continue" and SwingSet2 did not run. No error was given. Help!??? Kevin Herrboldt wrote: > On Tuesday, July 2, 2002, at 12:17 PM, Hanasaki JiJi wrote: > >> Does OpenJNLP work throgh http proxied firewalls? If so, how is it >> configured? > > > Unfortunately OpenJNLP has not had any proxy logic added to it. That > being said, there might be a way to get it to work: > >> I have tried the Java Env settings of: >> # JAVA PROXY SETTINGS >> export proxySet=true >> export proxyHost=firewall >> export proxyPort=8080 > > > Since OpenJNLP uses the built-in HTTP protocol handler, this should be > the right approach. There could be issues with the environment variables > not being picked up, so I'd recommend try setting the proxy values as > java properties. > > You should be able to modify the openjnlp.sh script and add these > properties by changing the PROPS line: > > PROPS="-DproxySet=true -DproxyHost=firewall -DproxyPort=8080" > > > I have no proxy to test against, but that should actually set the Java > System properties for proxying every time OpenJNLP starts up. > > Note: Unfortunately that won't change the behavior of the launcher, so > once an app is launched by OpenJNLP I'm afraid the proxy settings will > not be set for the app. > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Openjnlp-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjnlp-devel > |
From: Kevin H. <ke...@na...> - 2002-07-02 18:47:28
|
On Tuesday, July 2, 2002, at 12:21 PM, Hanasaki JiJi wrote: > I am having some trouble launching an application in OpenJNLP. Are > applications supported or just applets? If applications are supported, > could someone point me to a link on any special Applications are the only type of app supported currently. Do you have a specific error you can post to help with this? There is nothing special you should need to do with tomcat, OpenJNLP works with simple HTTP requests using the "Last-Modified:" header. If you are trying to use tomcat does that mean you are trying version-based resources and the JNLP servlet? OpenJNLP does not currently support that. |
From: Kevin H. <ke...@na...> - 2002-07-02 18:44:12
|
On Tuesday, July 2, 2002, at 12:17 PM, Hanasaki JiJi wrote: > Does OpenJNLP work throgh http proxied firewalls? If so, how is it > configured? Unfortunately OpenJNLP has not had any proxy logic added to it. That being said, there might be a way to get it to work: > I have tried the Java Env settings of: > # JAVA PROXY SETTINGS > export proxySet=true > export proxyHost=firewall > export proxyPort=8080 Since OpenJNLP uses the built-in HTTP protocol handler, this should be the right approach. There could be issues with the environment variables not being picked up, so I'd recommend try setting the proxy values as java properties. You should be able to modify the openjnlp.sh script and add these properties by changing the PROPS line: PROPS="-DproxySet=true -DproxyHost=firewall -DproxyPort=8080" I have no proxy to test against, but that should actually set the Java System properties for proxying every time OpenJNLP starts up. Note: Unfortunately that won't change the behavior of the launcher, so once an app is launched by OpenJNLP I'm afraid the proxy settings will not be set for the app. |
From: Hanasaki J. <han...@ha...> - 2002-07-02 17:21:22
|
I am having some trouble launching an application in OpenJNLP. Are applications supported or just applets? If applications are supported, could someone point me to a link on any special configurations for Tomcat? Tomcat 4.0+, Linux and JDK1.4 are being used. Thank you. |
From: Hanasaki J. <han...@ha...> - 2002-07-02 17:16:57
|
Does OpenJNLP work throgh http proxied firewalls? If so, how is it configured? I have tried the Java Env settings of: # JAVA PROXY SETTINGS export proxySet=true export proxyHost=firewall export proxyPort=8080 without success. These are the right settings for my firewall/proxy. Thank you, |
From: Kevin H. <ke...@na...> - 2002-06-25 22:25:01
|
After playing around on non-Mac OS X platforms (and being gently prodded by Chris Heiny) I now have a good feel for the period of no feedback during the launch process that makes one wonder if something's happening and if the launch is going to work. It is particularly disconcerting from a shell because the external JVM is invoked and the current one immediately exits. No feedback until the app pops up. Yet another reason why Mac OS X's dock is so excellent, heheh. Here are some of my ideas for appropriate feedback: -Launcher needs a dialog that explains "updating launcher", "starting up", etc. This is shown by the launching JVM, not the new one. This will then give feedback about the new JVM being started. -When the OpenJNLP internal launcher is invoked, it should spit something recognizable to stdout (e.g., "OpenJNLP Launcher v0.7") or somesuch, which the invoking JVM can then capture as an indication that the external launch is finished and the dialog can come down. -Mac OS X seems to key off of uncaught exceptions in the main thread as an indicator of application death. OpenJNLP could use this to know that the app has blown up and trigger the appropriate feedback about a failed launch. The key with all of this how to implement a feedback system that works both from the command line and from a GUI-based app. One of the goals of the openjnlp-lib is to avoid anything that brings up any GUI stuff. This is all post-0.7 stuff and probably needs more thought/discussion. |
From: Kevin H. <ke...@na...> - 2002-06-25 22:12:07
|
On Thursday, June 6, 2002, at 12:29 AM, Christopher Heiny wrote: > OK, I can't figure it. Why does this command: > openjnlp http://www.jGoodies.com/download/jdiskreport/jdiskreport.jnlp > work fine, but this one: > openjnlp http://www.jGoodies.com/download/jpathreport/jpathreport.jnlp > produce result in a ClassNotFoundException? I've tested jPathReport on Mac OS X and linux using Java 1.4. It works fine on linux and has a bunch of bugs in it that causes issues on Mac OS X. It makes some assumptions about UIDelegates that cause it to get stuck during the license dialog. I was able to get past that and verify that it (mostly) ran. The problems were certainly not caused by OpenJNLP. I did my tests with the ver-0-7 branch of OpenJNLP, which is almost done and will be merged back into the trunk any minute now. Really. |
From: Kevin H. <ke...@na...> - 2002-06-17 22:28:21
|
OpenJNLP has finally branched for the next release. The code on the branch will become OpenJNLP 0.7 when it is finally released. I deviated slightly from my previous message about tag names: bp_ver-0-7 is the non-branch tag where the branch was made ver-0-7 is the name of the branch rel_ver-0-7 will be the name of the 0.7 release, it will be on the ver-0-7 branch mp_ver-0-7 will be the non-branch tag on the trunk where the branch is merged back What does this mean for development? For adding new stuff, nothing changes. All bleeding-edge development stays on the trunk. If you want to fix bugs for the release, you need to switch to the branch with a command like "cvs update -r ver-0-7". Since branch tags are sticky, everything you do from that point on will be on the "ver-0-7" branch. To get back to the trunk you just do "cvs update -A". |
From: Kevin H. <ke...@na...> - 2002-06-14 22:00:30
|
On Friday, June 14, 2002, at 04:38 PM, Christopher Heiny wrote: > On Friday 14 June 2002 11:53 am, Kevin Herrboldt wrote: [...] > Sounds like a practical plan to me. I'll follow this next time I'm > folding > in new functionality (for example, Elvis or (possibly) System.err > handling). Oh no, I think I wasn't clear. When doing new stuff, keep doing it on the main trunk. When it's time to feature freeze for a release, the frozen code will go on a new branch. I don't want releases to interfere with adding new features and it really reduces headaches for developers if they can keep working on the main trunk. > Do you have any preferred branch naming convention? I'm planning to document the CVS structure and maybe even include a visual aid. My plan now is to stick with the naming convention for releases ("ver-0-6" for example). Releases will most likely go like this (using "ver-0-7" as an example release): bp_ver-0-7 on the trunk as a tag to denote where the branch point is branch_ver-0-7 branch created from the "bp_ver-0-7" point ver-0-7 on the branch as a tag for the release actually released mp_ver-0-7 on the trunk as a tag to denote where the branch was merged back (merge point) If there's a bug fix for a specific release it will be done on the branch for that version and then released as a minor point release. So "ver-0-7-1" would be a tag on "branch_ver-0-7" and there would be a "mp_ver-0-7-1" merge point on the main trunk to roll the fixes back into the main code base. |
From: Christopher H. <he...@ez...> - 2002-06-14 21:38:43
|
On Friday 14 June 2002 11:53 am, Kevin Herrboldt wrote: [snip] > My thinking is that instead of > stopping work on the main cvs trunk releases should now be branches. > This will allow work to continue on new features without interrupting > the release code base. When changes are made on the release branch they > can be merged back into the main trunk. [snip] Sounds like a practical plan to me. I'll follow this next time I'm folding in new functionality (for example, Elvis or (possibly) System.err handling). Do you have any preferred branch naming convention? Chris |
From: Christopher H. <he...@ez...> - 2002-06-14 21:36:16
|
On Friday 14 June 2002 11:43 am, you wrote: > On Thursday, June 6, 2002, at 12:46 AM, Christopher Heiny wrote: > > I've noticed we tend to lose a lot of information written to System.err > > (and > > in some cases to System.out). System.err is especially important, since > > Are messages really being lost? My testing shows all messages. On Mac OS > X they go to the system console until the GUI comes up, and then into > the Console window. If I run from the command line the messages show up > in my terminal window. The CLI interface works the same for Linux. The GUI is another matter - the messages are lost until you open the OpenJNLP Console (they are not appearing on my system console under KDE - potentially this is my configuration, which is something to look into). > > right now loading and/or applications can fail silently, leaving the > > user (or > > even the developer :-) ) to wonder what the heck happened, and probably > > abandoning OpenJNLP abandoning for other solutions. > > This is a really tough problem to address, I've run into this before on > other projects that launch Java apps. There is no way to tell if a Java > app "fails" other than the obvious like not finding the main class. Once > it starts running the class loader may fail to find a class but that > doesn't necessarily mean the app failed. True. We're trying to address a similar issue with our .jnlp deployed applications here. We don't have a complete solution, but it is important to minimize this problem's impact. (see following) [snip suggestion to redirect System.err to pop-up in GUI mode] > > I'd have to disagree with this. This would get annoying very quickly. > The whole point of the console is to provide the capability to see > diagnostic messages but in a non-obtrusive manner. It is impossible to > tell which messages are "alert" messages and which are normal output by > the app that's being run. Because the messages go into the console even > when it's not visible, a user can always see what's happening or has > happened. Well, things written to System.err are by definition alerts and not normal output, right? That's what System.err is for. System.out is for normal output, and I'm suggesting no change in its handling. My personal feeling is that any application that writes normal messages to System.err needs to have its head examined. :-) If you're writing to System.err, it's because you want to call attention to something that has probably not gone as the user expected it to. Under Linux, most users are unlikely to have a system console open. This is even more likely under Solaris. In the case of an app failing to launch (for example) under the current handling of System.err, this results a silent and mysterious failure. This is a >big< user dissatisfier, and because OpenJNLP is the primary interface, it is receiving the blame (around here we're using OpenJNLP to deploy some of our internal tools, and of course people have discovered that there are other cool .jnlps out there on the internet, and when those don't work, it's not the application's fault...). > Have you tried Java Web Start to see how it behaves? I've noticed that > you can launch an app with its own console open which has its advantages > but doesn't give the user a feeling of centralized management. I'll try to characterize JWS's behavior. Chris |
From: Kevin H. <ke...@na...> - 2002-06-14 18:54:01
|
OpenJNLP has gone too long without a release. More importantly, there are major improvements to OpenJNLP that should have been released already (e.g., applet support and the new launcher). I don't think the current code base is quite ready for a release, but I want to do a feature freeze on it. My thinking is that instead of stopping work on the main cvs trunk releases should now be branches. This will allow work to continue on new features without interrupting the release code base. When changes are made on the release branch they can be merged back into the main trunk. This approach is based on my (vast?) cvs experience over the years and the good advice from the very good book, "Open Source Development with CVS". It happens to be (mostly) free at <http://cvsbook.red-bean.com/>. Definately worth a read. The free chapters are the ones that cover the mechanics of using CVS. |
From: Kevin H. <ke...@na...> - 2002-06-14 18:43:08
|
On Thursday, June 6, 2002, at 12:46 AM, Christopher Heiny wrote: > I've noticed we tend to lose a lot of information written to System.err > (and > in some cases to System.out). System.err is especially important, since Are messages really being lost? My testing shows all messages. On Mac OS X they go to the system console until the GUI comes up, and then into the Console window. If I run from the command line the messages show up in my terminal window. > right now loading and/or applications can fail silently, leaving the > user (or > even the developer :-) ) to wonder what the heck happened, and probably > abandoning OpenJNLP abandoning for other solutions. This is a really tough problem to address, I've run into this before on other projects that launch Java apps. There is no way to tell if a Java app "fails" other than the obvious like not finding the main class. Once it starts running the class loader may fail to find a class but that doesn't necessarily mean the app failed. > Here's what I propose to do as a solution: > 1) when running from CLI, redirect application System.err/System.out > to [...] > 2) when running from the GUI, instead of copying System.err to the > console > or bitbucket, we should be displaying all messages immediately. I > suggest > popping up a JOptionPane that displays the System.err stream for that > source > in a scrollable JTextArea. The user can then examine the message, and > close > the pane or leave it open. If left open, it will receive any further > messages (although if new messages arrive after some period of > quiesence, the > pane should be flashed, beeped, brought to the top or otherwise > highlighted); > if closed, it will be reopened on the next message. I'd have to disagree with this. This would get annoying very quickly. The whole point of the console is to provide the capability to see diagnostic messages but in a non-obtrusive manner. It is impossible to tell which messages are "alert" messages and which are normal output by the app that's being run. Because the messages go into the console even when it's not visible, a user can always see what's happening or has happened. Have you tried Java Web Start to see how it behaves? I've noticed that you can launch an app with its own console open which has its advantages but doesn't give the user a feeling of centralized management. |
From: Kevin H. <ke...@na...> - 2002-06-14 18:32:02
|
On Tuesday, June 4, 2002, at 02:26 AM, Christopher Heiny wrote: > Hokay, I've checked in the following: > - fix the Unix shell script to use the preferred JVM and pass args > - check for null pointers that result if there are no lazy jars/libs > - handle URL from command line > - try to position the console window so it doesn't squish the main > window Most excellent! I did just tweak the URL from the command-line to try every argument as a URL instead of making assumptions about which argument looks like a URL. If creating the URL fails then it tries to open it as a file. I figure it's better to let the JVM handle the decision than to restrict possible URL types. |
From: Christopher H. <he...@ez...> - 2002-06-06 05:47:57
|
I've noticed we tend to lose a lot of information written to System.err (and in some cases to System.out). System.err is especially important, since right now loading and/or applications can fail silently, leaving the user (or even the developer :-) ) to wonder what the heck happened, and probably abandoning OpenJNLP abandoning for other solutions. Here's what I propose to do as a solution: 1) when running from CLI, redirect application System.err/System.out to OpenJNLP's System.err/System.out. Preface the messages with "[appname]" as is currently done with the GUI console. 2) when running from the GUI, instead of copying System.err to the console or bitbucket, we should be displaying all messages immediately. I suggest popping up a JOptionPane that displays the System.err stream for that source in a scrollable JTextArea. The user can then examine the message, and close the pane or leave it open. If left open, it will receive any further messages (although if new messages arrive after some period of quiesence, the pane should be flashed, beeped, brought to the top or otherwise highlighted); if closed, it will be reopened on the next message. Anyway, does this sound like an acceptable solution? If so, I'll start on it shortly. Chris |
From: Christopher H. <he...@ez...> - 2002-06-06 05:31:16
|
OK, I can't figure it. Why does this command: openjnlp http://www.jGoodies.com/download/jdiskreport/jdiskreport.jnlp work fine, but this one: openjnlp http://www.jGoodies.com/download/jpathreport/jpathreport.jnlp produce result in a ClassNotFoundException? At first I thought it was something I'd done, but that doesn't appear to be the case. The two .jnlp files (attached) don't appear to be significantly different, and nothing is obviously wrong in the jars (at least to my untrained eye). You'll need to download my latest CVS checkin to run this from the command line in Unix (though you might have to run from the GUI with the console open to see the error message (see next message)). I think you'll need to run it from the GUI in MacOS. I haven't tried it in Windows. This has been bugging me for a couple of weeks now. Is this an OpenJNLP problem, or a problem with the jpathreport jar? Chris |
From: Christopher H. <he...@ez...> - 2002-06-04 07:27:43
|
Hokay, I've checked in the following: - fix the Unix shell script to use the preferred JVM and pass args - check for null pointers that result if there are no lazy jars/libs - handle URL from command line - try to position the console window so it doesn't squish the main window I've given this a slight workout on JDK 1.4.0 on Mandrake 8.2. Haven't tried other JVMs or OS'es yet, though, and would like to exercise it more on this system as well. Chris |