| The AppContext is a table referenced by ThreadGroup which stores
application service instances. (If you are not writing an application
service, or don't know what one is, please do not use this class.)
The AppContext allows applet access to what would otherwise be
potentially dangerous services, such as the ability to peek at
EventQueues or change the look-and-feel of a Swing application.
Most application services use a singleton object to provide their
services, either as a default (such as getSystemEventQueue or
getDefaultToolkit) or as static methods with class data (System).
The AppContext works with the former method by extending the concept
of "default" to be ThreadGroup-specific. Application services
lookup their singleton in the AppContext.
For example, here we have a Foo service, with its pre-AppContext
code:
public class Foo {
private static Foo defaultFoo = new Foo();
public static Foo getDefaultFoo() {
return defaultFoo;
}
... Foo service methods
}
The problem with the above is that the Foo service is global in scope,
so that applets and other untrusted code can execute methods on the
single, shared Foo instance. The Foo service therefore either needs
to block its use by untrusted code using a SecurityManager test, or
restrict its capabilities so that it doesn't matter if untrusted code
executes it.
Here's the Foo class written to use the AppContext:
public class Foo {
public static Foo getDefaultFoo() {
Foo foo = (Foo)AppContext.getAppContext().get(Foo.class);
if (foo == null) {
foo = new Foo();
getAppContext().put(Foo.class, foo);
}
return foo;
}
... Foo service methods
}
Since a separate AppContext can exist for each ThreadGroup, trusted
and untrusted code have access to different Foo instances. This allows
untrusted code access to "system-wide" services -- the service remains
within the AppContext "sandbox". For example, say a malicious applet
wants to peek all of the key events on the EventQueue to listen for
passwords; if separate EventQueues are used for each ThreadGroup
using AppContexts, the only key events that applet will be able to
listen to are its own. A more reasonable applet request would be to
change the Swing default look-and-feel; with that default stored in
an AppContext, the applet's look-and-feel will change without
disrupting other applets or potentially the browser itself.
Because the AppContext is a facility for safely extending application
service support to applets, none of its methods may be blocked by a
a SecurityManager check in a valid Java implementation. Applets may
therefore safely invoke any of its methods without worry of being
blocked.
Note: If a SecurityManager is installed which derives from
sun.awt.AWTSecurityManager, it may override the
AWTSecurityManager.getAppContext() method to return the proper
AppContext based on the execution context, in the case where
the default ThreadGroup-based AppContext indexing would return
the main "system" AppContext. For example, in an applet situation,
if a system thread calls into an applet, rather than returning the
main "system" AppContext (the one corresponding to the system thread),
an installed AWTSecurityManager may return the applet's AppContext
based on the execution context.
author:
Thomas Ball
author:
Fred Ecks
version:
1.35 10/10/06 | 