I'm not sure of the details, but I've tracked it to at least this symptom:

bimage is causing a NullPointerException on the line "Integer hi =
(Integer) getHeightMethod.invoke(bimage, (Object[]) null);" in
loadImageIO(String filename) of the file PApplet.java

the circumstances:
* it only causes a problem when the applet is hosted remotely.
* the applet is signed.
* the image is aquired via drag and drop code similar to what is in
Editor.java as suggested <a
href='http://processing.org/discourse/yabb_beta/YaBB.cgi?board=Integrate;action=display;num=1136283692'>here</a>
* I can read the file using a BufferedReader, I just can't display the image

specifically, i invoke the loadImage in this section of code - called in
the handling of a drop event of DropTarget:

public void dropImageFile(File file) {
final File file2 = file;
final PApplet thisApp = this;
AccessController.doPrivileged(new PrivilegedAction() {
public Object run() {
PImage p = thisApp.loadImage(file2.getAbsolutePath());
if( p == null) { System.out.println("here"); return null; }
FloatingImage fi = new FloatingImage(thisApp, p);
images.add(fi);
return p;
}
});

*** Bug 361 has been marked as a duplicate of this bug. ***

does an openStream() work to read from that location? or a loadBytes()
call? just trying to figure out whether it's the image loading or the
stream loading that's causing the trouble.

also, does this work in previous releases?

So... switching out loadimage in favor of loadStrings(filename) produces an
"... is missing or inaccessible, make sure it's been added to you
sketch..." error ....

However, loadStrings(File) seems to work fine, as does loadBytes

I can InputStream istr = openStream(file); System.out.println(istr); with
no problems at that point as well.


The problem is in openstream(String filename) when the signed applet is
hosted on a remote machine. I hacked together a workaround (a
loadImage(File f)) that I can use in the meanwhile.

I don't think i've seen thise work, I have been working on this off and on
for a long while, and never had any success on the remotely hosted version,
though it worked on the locally hosted end.

what do you mean that it's on a remote machine? what does the path that
you're passing in look like?

by remotly hosted, i mean the applet has been exported. The files are then
on a machine that is not the machine I am logged in on. I am then running
the applet that i downloaded to my browser to access files that are on my
local machine.

The path that I pass in is taken from the "File" object that i was passed
in from the drop event. Specifically it's aquired from the
getAbsolutePath() of the File object -> printing it out shown that it is a
correct path that begins at root.

hm, that sounds like openStream() isn't recognizing that it's a proper
path, and it's giving up to early.

actually, it's probably because it's not made for signed applets--that it's
not gonna try to make File objects when not online (iirc how i wrote it...)
because it doesn't want to throw the security ex.. althoo that's in a
try/catch.. i'll have to check.

nothing in openStream jumps out as a problem tho.. you might try copying
the code for openStream into your sketch and adding more debug info to it
to see where it's dying out. it's a bit hairy because of the type of cases
we have to support (i.e. yours) so we might be triggering something in a
way that was not anticipated.

The difference begins in openStream at the line:
stream = cl.getResourceAsStream("data/" + filename);

When working entirely locally, stream is null after this statement.
However, in the remotely hosted signed applet case, cl.getResourceAsStream
returns a non null stream for something with the path
"data//Users/username/Desktop/image.jpg"

oh yech.. why would it return a non-null stream if it doesn't exist. that's
annoying. problem is, that's gonna be the default case for things so i
don't want to go checking files first and getting a security exception
(even if it's handled) since 99% of the time getResource is the way to go..
maybe there's some way to see if the stream is legit.

Specifically it is returning something that is a
sun.plugin.cache.EmptyInputStream .... I've not found much for
documentation on it yet though... So i assume its just some kind of default
stream for the case where it doesn't exist. A quick check could probably
be done via instanceof.... unless you rely on EmptyInputStreams for some
other case.

k, so that turns up this bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5086089

so i'll change it to see if the returned stream is non-null, and if so, do
a getClass.getName and make sure it's not that empty feller.. i can't use
instanceof otherwise that'll hose other VMs that might not have that
specific sun.* class. so this is the changed part of openStream if you
wanna give that a shot:

ClassLoader cl = getClass().getClassLoader();
stream = cl.getResourceAsStream("data/" + filename);
if (stream != null) {
String cn = stream.getClass().getName();
// http://dev.processing.org/bugs/show_bug.cgi?id=359
if (!cn.equals("sun.plugin.cache.EmptyInputStream")) {
return stream;
}
}