> ## `java.security.AccessControlException` thrown when applet calls `java.beans.Introspector.setBeanInfoSearchPath()`

> ###
> Symptoms

> > When running an applet in a browser using the Sun JRE, an `AccessControlException` is thrown in the execution of `Introspector.setBeanInfoSearchPath()`:

> > > `java.security.AccessControlException: access denied (java.util.PropertyPermission * read,write)
> > > at java.security.AccessControlContext.checkPermission(Unknown Source)
> > > at java.security.AccessController.checkPermission(Unknown Source)
> > > at java.lang.SecurityManager.checkPermission(Unknown Source)
> > > at java.lang.SecurityManager.checkPropertiesAccess(Unknown Source)
> > > at java.beans.Introspector.setBeanInfoSearchPath(Unknown Source)
> > > at ....`

> > The same applet runs under the Microsoft VM.

> ### Cause

> > The `Introspector.setBeanInfoSearchPath()` method call can change the list of package names used for finding `BeanInfo` classes. If more than one applet is running in the VM, an untrusted applet could call this method to redirect other applets to look up `BeanInfo` in unexpected packages. This is a security hole.

> > A security check for `java.util.PropertyPermission` was added to this method in the JRE to address the security concern. If the applet is unsigned and it calls into this method, an `AccessControlException` will be thrown.

> ### Resolution

> > The workaround is to either:

> > 1. Sign the applet using the JDK `jarsigner` tool, so that the applet runs as a trusted applet and has permissions to call the `Introspector.setBeanInfoSearchPath()` method.
> > 2. Rearchitect the applet code to avoid the call to `Introspector.setBeanInfoSearchPath()`. For example, instead of relying on the `BeanInfo` search path, use a fully qualified package name for looking up the `BeanInfo`.

> ### Related Information

> See jarsigner - JAR Signing and Verification Tool.