I'm embedding Lobo in a Java app that is launched through WebStart. My app calls initExtensions, which calls PlatformManager.getApplicationDirectory, which tries to open a URL that is not a file URL. This generates the exception below. Can someone tell me how I can fix this? I don't mind making a temporary private workaround in the lobo source. Thanks! --Jon
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.javaws.Launcher.executeApplication(Unknown Source)
at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ExceptionInInitializerError
... 9 more
Caused by: java.lang.IllegalArgumentException: URI scheme is not "file"
at java.io.File.<init>(Unknown Source)
... 11 more
It appears to be failing when it tries to get the application directory. To do this, it looks at the location of the lobo.jar JAR file. However, it expects it to be a file location. You probably need to modify PlatformManager.getApplicationDirectory() to accept web locations for lobo.jar. If you do fix it, it would be great if you can submit a patch for it.
Thanks for your prompt reply. I've been looking over the code, and this is what I think is the least invasive approach:
I would modify the Extensions class by adding an additional constructor that takes a URL (instead of File) parameter. I'd factor out as much common code between the two constructors as I could.
The ExtensionsManager class would also be modified to read the System property "ext.urls" (as it now reads "ext.dirs" and "ext.files") and invoke the new constructor for each token in that String.
What do you think?
I think that probably works. The ext.dirs and ext.files properties are currently only used when you run from Eclipse so that you can have extensions load from a directory that is not "ext" and not necessarily from JAR files. Certainly, on the web we cannot normally read the contents of a directory, so it makes sense that you would need ext.urls to load primary.jar, cobra-no-commons.jar and its other dependencies.
This approach isn't going to work for WebStart-ed apps, I think. It seems that the jar files cannot be loaded with a simple URL connection, because a WebStart servlet is serving them (doing versioning, etc.)
The next approach I plan to explore is just loading extensions using the lobo-extension properties in the ext jar files (no details figured out yet), and letting libraries get loaded by WebStart like any other app resource. One difference in this approach from the standard way is that there is only one class loader (WebStart's). Is it important for each extension to have its own class loader?
No, it shouldn't be necessary for each extension to have a separate class loader. In terms of security that makes sense, but functionally it's not required. As long as the implementations of the NavigatorExtension interface are found, that's fine.
Here, in overview, is what I finally got working:
Added constructor to Extensions that takes a resource name that refers to a "lobo-extensions" properties file (although the name does not have to be that). The constructor uses getClass().getResourceAsStream() to get an input stream, from which the properties are read. Added a private boolean field "isLoadedFromProperties" which is used in a few places like the initClassLoader method, which, if isLoadedFromProperties is true, sets the class loader to the parent class loader.
Changed ExtensionsManager class to read the System property "ext.propfiles", which is a comma-separated list of property-file names, as resource names. Made changes to support this like adding a "addExtension" method that takes a String resource-name parameter, which will call the Extensions constructor above.
To make this work, the embedder has to:
1. List all jars resources in the JNLP file.
2. Set the "ext.dirs" property in JNLP file to "" (empty string), to prevent Lobo from trying to load from ext directory.
3. Set the "ext.propfiles" property in JNLP file to a list of lobo-extension property files like "/loboext/primary.properties,/loboext/myextension.properties".
It's that simple!
Do you want these mods to Extension and ExtensionManager in the Lobo codebase? If so, I'll have to study the patching process. If you want some adjustments first, I'm happy to make them. Or let me know if you want to see the files first.
Sounds like great work. I assume this doesn't affect Lobo running as a standalone application? If you are up to it, sure, go ahead and submit a patch. If you had Eclipse check out the code from CVS, it's very easy to get a patch. There's a section in the source code page that explains how to do it.
BTW, you didn't have any trouble with security? I'm guessing it's a signed JNLP app?
Yeah, the app jar and all it's resource jars must be signed. Makes the debug cycle very long. So far it's only an in-house app so I use a self-signed certificate and the JDK's jarsigner tool.
I find WebStart a real pain, but its automatic update feature makes it worth the trouble.
Ok, I'll try the patch. Yes, Lobo still runs as standalone app. What I tried to do was add another extension path, and not touch the existing paths. I gotta believe someone who really knows WebStart could find a better way than the way I took, but it does work.
Many thanks for your quick answers on this.
I just stated using this lobo browser and trying to launch from Web start. But it throwing errors for pulgin jar files ( error : Application code source apparently not a local JAR file) . is "jonmunson" patch included? if yes, what i need to configure here? any help would be greatly appreciated.
Could I get some more details of the changes that jonmunson made so that I can make lobo work using JWS. ie the changes to ExtensionsManager and Extensions classes. PLEASE!!!!!
Log in to post a comment.