It's always annoying when something outside my control changes, and breaks my code. I received an e-mail the other day from my former coworker at the library reporting that one of the little tools I wrote stopped working on some machines. I suggested a few things to try, but I assumed that something ridiculous happened at the library, and they would fix it up. By the end of the day they let me know that web start with the new java 6 update 24 threw a SecurityException when launching my tool.
I at first could not reproduce the problem running a copy of the library tools, but that was just because I was running a pre-update version of java. My Windows 7 laptop has 3 java installs - a 64 bit jre, a 64 bit jdk, and a 32 bit jre - only the 32 bit jre has update 24. My netbeans developer environment and powershell command line both point at the pre-update jdk, but Chrome's java plugin runs the 32 bit jre with update 24. I was already annoyed at this point. Ugh.
Google helped me narrow the problem down to web-start's interaction with the Apache felix OSGi implementation that I use. I wrote up a little test case (below), and submited a ticket to Oracle's java team.
package littleware.demo;
import java.io.PrintWriter;
import java.io.StringWriter;
import java.net.URL;
import java.net.URLClassLoader;
import java.sql.Connection;
import java.util.HashMap;
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.swing.JFrame;
import javax.swing.JOptionPane;
import javax.swing.JScrollPane;
import javax.swing.JTextArea;
import javax.swing.SwingUtilities;
import javax.swing.WindowConstants;
import org.apache.felix.framework.Felix;
public class JavaToy {
private static final Logger log = Logger.getLogger( JavaToy.class.getName() );
public static class AppRunner implements Runnable {
public void run() {
final StringWriter swriter = new StringWriter();
final PrintWriter pwriter = new PrintWriter( swriter );
pwriter.append( "Class path: " ).append(
System.getProperty( "java.class.path" )
).append( "\n\n-------------------------\n" );
final ClassLoader classLoader = this.getClass().getClassLoader(); //Thread.currentThread().getContextClassLoader();
if ( classLoader instanceof URLClassLoader ) {
pwriter.append( "URLClassLoader:\n" );
for ( URL url : ((URLClassLoader) classLoader).getURLs() ) {
pwriter.append( url.toString() ).append( "\n" );
}
pwriter.append( "\n--------------------------------\n" );
}
try {
Class.forName( "bogus.DoesNotExist" );
pwriter.append( "No exception thrown on bogus class load\n" );
} catch ( Exception ex ) {
pwriter.append( "Caught exception loading bogus class: " ).append( ex.toString() ).append( "\n" );
ex.printStackTrace(pwriter);
}
pwriter.flush();
final JFrame jframe = new JFrame( "Webstart test" );
final JTextArea jtext = new JTextArea( swriter.toString(), 20, 40 );
jframe.add( new JScrollPane( jtext ) );
jframe.pack();
jframe.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
jframe.setVisible(true);
}
}
public static void main( String[] args ) {
try {
log.log( Level.INFO, "Launching felix!" );
(new Felix(new HashMap<String, Object>())).start();
Thread.sleep( 2000 );
} catch (Exception ex) {
log.log(Level.SEVERE, "Caught exception", ex);
System.exit(0);
}
SwingUtilities.invokeLater( new AppRunner() );
}
}
Web-start with a pre-update-24 jre throws the expected
ClassNotFoundException
and yields this result:
Class path: C:\Program Files\Java\jre6\lib\deploy.jar
-------------------------
URLClassLoader:
file:/C:/Users/pasquini/Documents/Code/JavaToy/dist/JavaToy.jar
file:/C:/Users/pasquini/Documents/Code/JavaToy/dist/lib/felix-2.0.4.jar
http://felix.extensions:9/
--------------------------------
Caught exception loading bogus class: java.lang.ClassNotFoundException: bogus.DoesNotExist
java.lang.ClassNotFoundException: bogus.DoesNotExist
...
An update-24 jre throws a troublesome
SecurityException
with this result:
Class path: C:\\Program Files (x86)\\Java\\jre6\\lib\\deploy.jar
-------------------------
URLClassLoader:
file:/C:/Users/pasquini/Documents/Code/JavaToy/dist/JavaToy.jar
file:/C:/Users/pasquini/Documents/Code/JavaToy/dist/lib/felix-2.0.4.jar
http://felix.extensions:9/
--------------------------------
Caught exception loading bogus class: java.lang.SecurityException: Permission denied: http://felix.extensions:9/bogus/DoesNotExist.class
java.lang.SecurityException: Permission denied: http://felix.extensions:9/bogus/DoesNotExist.class
...
The bug robot sent me a nice response for my trouble.
Dear Java Developer,
Thank you for your interest in improving the quality of Java Technology.
Your report has been assigned an internal review ID of 1990127, which is NOT visible on the Sun Developer Network (SDN).
Please be aware that the large volume of reports we receive sometimes prevents us from responding individually to each message.
If the information is determined to be a new Bug or RFE, or a duplicate of a known Bug or RFE, you will receive a followup email containing a seven digit bug number. You may search for, view, or vote for this bug in the Bug Database at http://bugs.sun.com/.
If you just reported an issue that could have a major impact on your project and require a timely response, please consider purchasing one of the support offerings described at http://developers.sun.com/services/.
Bla bla bla ...
Fortunately, the felix user mailing list had a thread on the issue, and some cool Karl Pauls guy pointed me in the right direction to throw together a little patch (see below) that got me back in business.
Hurray for open source! Of course now its 3 days of head banging, trying random hacks, and considering dropping felix or web-start later. I'm too relieved to be bitter!
Oracle actually closed a related ticket as "Not a bug", because the http://... URL in the ClassLoader path violates the web-start single-origin policy - now more strictly enforced in update 24. That looks like some lazy Oracle developer dodging work to me, because a signed web-start app granted all-permissions can do almost anything (open network ports, erase the disk, write and launch a program, whatever), so what's the deal with the SecurityException scanning the class path ?
Re: Java 6 Update 24 breaks Felix
Reuben Pasquini
Thu, 03 Mar 2011 10:00:46 -0800
Here's an ExtensionManager patch that got me back in business with webstart
(don't know what's up with the sun.org.moz... import in Felix.java):
---------------------
C:\Users\pasquini\Documents\Code\felix-framework
> svn diff -x -w
Index: src/main/java/org/apache/felix/framework/Felix.java
===================================================================
--- src/main/java/org/apache/felix/framework/Felix.java (revision 1076687)
+++ src/main/java/org/apache/felix/framework/Felix.java (working copy)
@@ -75,8 +75,8 @@
import org.osgi.framework.hooks.service.ListenerHook;
import org.osgi.service.packageadmin.ExportedPackage;
import org.osgi.service.startlevel.StartLevel;
-import sun.org.mozilla.javascript.internal.UintMap;
+
public class Felix extends BundleImpl implements Framework
{
// The secure action used to do privileged calls
Index: src/main/java/org/apache/felix/framework/ExtensionManager.java
===================================================================
--- src/main/java/org/apache/felix/framework/ExtensionManager.java
(revision 1076687)
+++ src/main/java/org/apache/felix/framework/ExtensionManager.java
(working copy)
@@ -87,6 +87,10 @@
static
{
+ // Allow system-property based disable of ExtensionManager.
+ // Adding http://felix.extension:9 to the class path causes
problems
+ // in webstart which enforces a "single origin" policy as of jre 6
update 24.
+ if( System.getProperty( "felix.extensions.enabled", "true"
).equalsIgnoreCase( "true" ) ) {
// pre-init the url sub-system as otherwise we don't work on
gnu/classpath
ExtensionManager extensionManager = new ExtensionManager();
try
@@ -113,7 +117,10 @@
extensionManager = null;
}
m_extensionManager = extensionManager;
+ } else {
+ m_extensionManager = null;
}
+ }
private final Logger m_logger;
private final Map m_headerMap = new StringMap(false);
---------------------------
Then add
<property name="felix.extensions.enabled" value="false" />
in the .jnlp <resources> block, and I'm back in business.
Thanks for pointing me in the right direction.
Hope something like this makes it into the next release ... ?
Cheers,
Reuben
On Thu, Mar 3, 2011 at 10:52 AM, Reuben Pasquini <reu...@frickjack.com>wrote:
> I agree it sounds like an Oracle bug, but a workaround would be great.
>
> A config parameter that disables extension bundles works for me too.
>
> I embed felix in a very limitted way to manage the startup/shutdown
> lifecycle
>
> via BundleActivators, so I don't think my apps will miss the extension
> bundles.
>
> Let me know when you have a patch checked in, and I'll give it a try ...
>
> or if you think it's a small change, then point me at the right part of the
> felix
>
> repo, and I'll try to throw together a patch for you.
>
> Thanks for the help!
>
>
>
> Cheers,
>
> Reuben
>
> On Thu, Mar 3, 2011 at 3:16 AM, Karl Pauls <karlpa...@gmail.com> wrote:
>
>> On Thu, Mar 3, 2011 at 10:08 AM, Bauersachs Ingo
>> <ingo.bauersa...@fhnw.ch> wrote:
>> >> Problem is this doesn't make sense to me as the app has allpermission
>> >> (or sets the security manager to null even). Why enforce this then? It
>> >> sounds like a bug (and there are several at oracle by now). Lets see
>> >> what they do
>> >
>> > Indeed, this makes no sense.
>> >
>> >> I'll try to find a workaround on the weekend and if
>> >> not, I'll probably add a property to disable extension bundles (which
>> >> would make the url go away - only extension bundles will not work).
>> >
>> > 6u24 is out and I needed a workaround fast. Changing the extension url
>> from http to file seems to satisfy the same origin policy. If my change
>> doesn't cause other side-effects it might even be a permanent solution. (I
>> have far to less experience with OSGi/Felix to really comment on this)
>>
>> If it works for you it is ok for now - it is not the permanent
>> solution as there will be other issues (there is a reason we do what
>> we do there - related to extension bundles). But if i can't find
>> something better the solution will be close (i.e., provide a way to
>> disable extension bundles -> don't register this url at all).
>>
>> regards,
>>
>> Karl
>>
>>
>> > Regards,
>> > Ingo
