Community
Participate
Working Groups
When I used cflow pointcut for my applet, I couldn't launch the Applet. java.lang.ExceptionInInitializerError at SandAspect.ajc$preClinit(SandAspect.aj) at SandAspect.<clinit>(SandAspect.aj) at SandApplet.init(SandApplet.java) at sun.applet.AppletPanel.run(AppletPanel.java:353) at java.lang.Thread.run(Thread.java:534) Caused by: java.security.AccessControlException: access denied (java.util.Proper tyPermission aspectj.runtime.cflowstack.usethreadlocal read) at java.security.AccessControlContext.checkPermission(AccessControlConte xt.java:269) at java.security.AccessController.checkPermission(AccessController.java: 401) at java.lang.SecurityManager.checkPermission(SecurityManager.java:524) at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:12 76) at java.lang.System.getProperty(System.java:612) at org.aspectj.runtime.internal.CFlowStack.selectFactoryForVMVersion(CFl owStack.java:124) at org.aspectj.runtime.internal.CFlowStack.<clinit>(CFlowStack.java:59) ... 5 more It because CFlowStack uses System.getProperty method with no try..catch block. Applet doesn't have permission to read system property: "aspectj.runtime.cflowstack.usethreadlocal". workaround: modify CFlowStack.java(1.5) line 123,124 like this ----- private static String getSystemPropertyWithNoSecurityException( String aPropertyName, String aDefaultValue){ try{ return System.getProperty(aPropertyName, aDefaultValue); } catch(java.lang.SecurityException e){ return aDefaultValue; } } private static void selectFactoryForVMVersion() { String override = getSystemPropertyWithNoSecurityException( "aspectj.runtime.cflowstack.usethreadlocal" , "unspecified" ); ----- I think defining getSystemPropertyWithNoSecurityException(or more simple name :-)) method in some utility class and using it where you call System.getProperty are better way.
Assigning to Matthew. The proposed solution looks good. See related bug 71527. In that bug the raiser wanted a way to switch off the use of threadlocal - but after reading this bug I think what they really meant in bug 71527 was they wanted a way to use cflow and not hit the security exception.
In the runtime we use 2 other access controlled APIs but do so safely: - Class.forName(): use of String argument version and avoid use of "null" class loader (see comment in SigantureImpl.makeClass()). - Class.getClassLoader(): use on self or class defining static join point object (which must be defined by a classloader at or below that used by the runtime which is OK). Should explore option to enclose calls to System.getProperty() in privileged blocks so that full function is availble when correct permissions granted. However must first explore implications for J2ME (which is the reason for the property query in the first place).
Created attachment 14938 [details] Suggested fix and Ant-based test The java.class.version property is not protected so only the first getProperty call is replaced. The test can be replaced with a harness-based version when "fork" is supported.
Fix checked in. I've added Charles Zhang to the CC list as he was having problems with this same bit of property checking code failing on J2ME. Catching the security exception will now allow the code to proceed, it will be interesting whether it enables Charles' code to now run successfully on J2ME. I know ThreadLocal isn't available there but the cflow stuff in aspectjrt.jar should be able to cope with that and fall back on the old non-threadlocal implementation. Matthew do you want to migrate your test into the new forking harness? waiting for build ....
Build available: BUILD COMPLETE - build.383 Date of build: 10/18/2004 23:39:49 Time to build: 113 minutes 41 seconds Last changed: 10/18/2004 13:04:09 Latest good AspectJ jar available at: download.eclipse.org/technology/ajdt/dev/aspectj-DEVELOPMENT.jar
Fix released as part of AspectJ 1.2.1
