Community
Participate
Working Groups
Enhancement request in aspectjrt.jar: I am trying to use AspectJ to weave an aspect that uses a cflow pointcut into an applet. But the Sun Java Plug-In version 1.4.2_04 throws a security violation if an applet tries to construct a ThreadLocal. So I'd like to be able to use the old cflow stack implementation. I get this exception: Caused by: java.security.AccessControlException: access denied (java.util.PropertyPermission aspectj.runtime.cflowstack.usethreadlocal read) 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.checkPropertyAccess(Unknown Source) at java.lang.System.getProperty(Unknown Source) at org.aspectj.runtime.internal.CFlowStack.selectFactoryForVMVersion(CFlowStack.java:124) at org.aspectj.runtime.internal.CFlowStack.<clinit>(CFlowStack.java:59) ... 33 more I can work around this problem by using aspectjrt.jar from AspectJ 1.1.1, but think there ought to be some runtime flag to not use ThreadLocals...
changed severity to 'enhancement'.....
Andy - doesn't your autodetect logic catch this case? If not we should either improve the detection or if that's impossible, give a compiler option...
Hmmmmmmmmmmmmm The logic has been in place for a while to ensure the security exception isn't surfaced when attempting to read the system property. I'm just a little unsure if it will behave exactly how you want. If the system property cannot be read then we check the version number of the class file - 46 or higher and we assume ThreadLocal is available. So, if the security exception is now hidden and yet it still attempts to utilise threadlocal, try compiling -target 1.1 to generate version 45 class files. that should cause it to avoid doing anything with ThreadLocal. I've tried to recreate the problem here just using appletviewer but can't seem to get the security policy right, whatever I try it successfully accesses the system property. If you happen to know how to set my local policy such that an applet can't access sys props then I'll look into it a little further...
I think the support is there but can't test it. If you can't try it soon Ron, I'll close this.
Do you not see this issue in running an applet on a standard Java Plug-In? I didn't do anything to configure it... However, this issue came up on a project that I'm not working on any more, so I don't have the environment to test it with myself.
I couldnt seem to recreate with a standard applet - it is possible the 'detect' logic was enhanced after you originally hit the problem and before I attempted to recreate.
Sounds plausible. Let's mark it as resolved and let someone reopen it if they find the issue again.
Thanks Ron - gets my numbers down ;) I'm happy to work on this if it raises its head again.
