| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
If there is a SOCKS proxy specified, use it for https, http,
and ftp protocols too (as a fallback).
'sameProxy' now affects the https, http and ftp protocols,
but not the socket protocol.
|
|
|
|
|
|
|
|
|
|
| |
This contains one functional change:
- String host = uri.getSchemeSpecificPart().split(":")[0];
+ String host = uri.getHost();
Given the URI of "socket://example.org", the first line
evaluates to "//example.org", while the second one (correctly)
evaluates to "example.org".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Treat jnlp.packEnabled and jnlp.versionEnabled just like other
properties that can be set in one resource element and
inherited/filtered in others.
2013-09-09 Omair Majid <[email protected]>
* netx/net/sourceforge/jnlp/JNLPFile.java
(getDownloadOptionsForJar): Rename to ...
(getDownloadOptions): New method. Look up jnlp.packEnabled and
jnlp.versionEnabled in any resources element.
* netx/net/sourceforge/jnlp/PluginBridge.java
(getDownloadOptionsForJar): Rename to ...
(getDownloadOptions): New method.
* netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java
(initializeResources): Invoke file.getDownloadResources.
(getDownloadOptionsForJar): Remove.
* tests/netx/unit/net/sourceforge/jnlp/JNLPFileTest.java
(testDownloadOptionsAppliedEverywhere): New method.
(testDownloadOptionsFilteredOut): New method.
|
|
|
|
| |
applet tags
|
|
|
|
| |
elsewhere which handled this
|
|
|
|
| |
(RH982558)
|
| |
|
| |
|
|
|
|
| |
of PR1473
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Another fix can be addition of buttons like always/never
|
| |
|
|
|
|
| |
desktop icon should be created. False otherwise.
|
|
|
|
| |
(shouldCreateShortcut) added handling of xtrustall during asking for desktop icon creation
|
| |
|
|
|
|
|
| |
Copy deployment configration read into system properties so it is
visibile to target programs.
|
| |
|
|
|
|
|
|
| |
This is a long-planned rework of JarCertVerifier, allowing it to handle
multiple certificates. The algorithms used to verify jars with multiple
certificates vary between JNLPs and Applets.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is possible for the ClassLoader to encounter a ClassCircularityError.
This can happen when the ClassLoader detects that checking if a class
'A' has been loaded triggers another check of whether 'A' has been
loaded before the first check has completed. This can happen easily when
trying to load Policy or Permission classes, which lie in our code path
that checks whether a class has been loaded.
One possible fix is to ensure these classes are not in the path of code
that gets executed when we are trying to check for a class. This can be
done by removing the call to getAccessControlContextForClassLoading. The
javadocs for ClassLoader.findLoadedClass do not mention any
permissions required to call the method nor do they mention that the
method can throw a SecurityException. The native code that implements
findLoadedClass does not have any security checks either. The
doProvileged block is probably not needed here and removing it breaks
the circularity.
|
| |
|
|
|
|
| |
outside jar
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* netx/net/sourceforge/jnlp/NullJnlpFileException.java: new class to
distinguish plain NPE from null jnlp file.
* netx/net/sourceforge/jnlp/SecurityDesc.java: (getSandBoxPermissions)
added throw of NullJnlpFileException in case of null jnlp file.
* netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java: (findClass)
added Override annotation, add catch of NullJnlpFileException and
re-throw of CNF exception.
* tests/netx/unit/net/sourceforge/jnlp/runtime/CodeBaseClassLoaderTest.java:
(testResourceLoadSuccessCaching) (testResourceLoadFailureCaching)
(testParentClassLoaderIsAskedForClasses) - internal JNLPFile's
(getSecurity) null in SecurityDesc constructorrepalced by this.
(testNullFileSecurityDesc) new test to ensure NPE in null JNLPFile case.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
icedtea-web now skips over any jars that are corrupt or not actually jars.
This is how the proprietary plugin treats this situation.
|
|
|
|
| |
extensions
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The bug manifests when the following sequence of steps happen:
1. An applet with both a codebase and a jar (archive) is loaded
2. A class Foo is loaded using the codebase classloader
3. The Foo class tries to load a class Bar that is specified in the jar
archive. The Bar class is not found.
The following applet reproduces the problem:
http://javadjvu.foxtrottechnologies.com/cgi-bin/djvuapplet.pl/examples/deer.djvu?zoom=page
The fix addresses the problem by ensuring that the codebase classloader
asks the classloader that knows about the jar archive to resolve
classes too.
|
|
|
|
|
| |
Previously folders in the archive tag were treated as jars.
They are now correctly treated as resource folders.
|
| |
|
| |
|
|
|
|
| |
hosting server
|