Hi again, I played a bit with JDK's source and researched a bit and I think I was able to nail down the problem.
1.) The URL which refers to my image is redirected, the redirection-logic is in URLImageSource.getDecoder The original URL is: http://juibrowser.sf.net/imgs/1.png The redirected URL is: http://juibrowser.sourceforge.net/imgs/1.png 2.) The ImageConsumerQueue associated with my Image/ImageRepresentation does not have a securityContext set. 3.) When calling InputStreamImageSource.setDecoder, it loops over all consumers in that queue calling checkSecurity. If the image-url is not redirected this call does nothing, because there's a check in URLImageSource.checkSecurity wether the URL was redirected. (It only needs to be checked twice when the original URL was redirected to another one). Thats why it works for not-redirected images. For redirected images this calls SecurityManager.checkConnect with context=null, which accordingly to Securitymanager's source immediatly leads to a SecurityException. So there are two possible solutions/problems: 1.) Modify the call to checkConnect in checkSecurity, to not specify a Security-Context if context=null. I don't know wether this could lead to security problems. I guess it would use the default context instead a specified one - could this be problematic? URLImageSource.checkSecurity: SecurityManager security = System.getSecurityManager(); if (security != null) { if(context != null) { security.checkConnect(actualHost, actualPort, context); }else { security.checkConnect(actualHost, actualPort); } } 2.) Check why the context of the ImageConsumerQueue is null - is that a valid configuration? It would be great if somebody could loose some words about how this is expected to work and wether solution 1.) could cause problems. lg Clemens PS: Another potential "problem" I found is: When the URL is redirected, the new port and the new hostname is queried. However if somebody does not specify a port in the URL the call to URL.getPort() returns -1, although the user ment port 80. However later in checkSecurity the port-value is passed to the SecurityManager - and its still -1 instead of 80. Worse the SecurityManager handle's ports with -1 with a special case accordin to javadoc: > This method calls checkPermission with the > SocketPermission(host+":"+port,"connect") permission if the port is not equal > to -1. > If the port is equal to -1, then it calls checkPermission with the > SocketPermission(host,"resolve") permission. At least as far as I can see the code does not anymore do for whats intended. Could that be a problem?
