Restricting the applet classloader?

[Filip Larsen]

I have a client-server setup where the client is distributed as an
applet in a single jar file containing all class files and resource
bundle files needed by the applet. However, during initialization of
the many resource bundles used by the applet, the classloader sends
great many requests to the server for non-existing resource bundle
files.

Previously, in an unrelated project, I fixed this problem by simply
providing "empty" resource bundle class files with the client jar, but
in this case that solution would require a great number of such dummy
files.

So, I was wondering if a more elegant solution perhaps was possible
using a "restricted" class loader during the load of the resource
bundles. Persuing this I quickly bang my head on a SecurityException
from the security manager (since the applet is and should be
unsigned).

Anyone know of another solution to stop the applet from making all
those futile server requests?


Regards,

 

[Thomas Weidenfeller]

So, I was wondering if a more elegant solution perhaps was possible
using a "restricted" class loader during the load of the resource
bundles. Persuing this I quickly bang my head on a SecurityException
from the security manager (since the applet is and should be
unsigned).

It looks as if this is not a classloader problem at all, but the
getBundle() method just does what it is supposed to do, and looks up a
bundle under a lot of different names. So, if you don't want this, don't
use getBundle(), but implement something on your own, which uses the
searchs strategy you like.

When you do so, the getResource[AsStream]() methods of the classloader
might be very handy.

/Thomas

 

[sammyk]

So, I was wondering if a more elegant solution perhaps was possible
using a "restricted" class loader during the load of the resource
bundles. Persuing this I quickly bang my head on a SecurityException
from the security manager (since the applet is and should be
unsigned).

It looks as if this is not a classloader problem at all, but the
getBundle() method just does what it is supposed to do, and looks up a
bundle under a lot of different names. So, if you don't want this, don't
use getBundle(), but implement something on your own, which uses the
searchs strategy you like.

When you do so, the getResource[AsStream]() methods of the classloader
might be very handy.

/Thomas

can you please state what you mean by saying "implement something on
your own" when reffering to getBundle()?