Hello Chris, scripting: I have updated the bug report with a further comment:
Further comment to my previous comment: It seems that the thing with setting the security manager two times to get it removed is intentional; there is a note to that effect at the top of FreeMindSecurityManager class. The key thing is that, after the recent bug fix, the security manager is being removed twice (as it should not): once in the method "evaluate", and once before the line "System.setOut(oldOut)". It seems that it should suffice that the line "securityManager.setFinalSecurityManager(scriptingSecurityManager);" before "System.setOut(oldOut)" is commented out. http://sourceforge.net/tracker/index.php?func=detail&aid=2789907&group_id=7118&atid=107118 Best regards, Dan On Wed, Dec 1, 2010 at 12:24 AM, Dan Polansky <[email protected]> wrote: > Hello Chris, > > I have had a look at the scripting bug, and have proposed a bug fix, > one that you need to review, though. I have posted the fix to the bug > report: > > Scripts do not work if file operations are not permitted > http://sourceforge.net/tracker/index.php?func=detail&aid=2789907&group_id=7118&atid=107118 > > The last comment to the bug report, for your convenience: > > I get the undesirable behavior described with 0.9.0 RC11 removed by > performing the following change in ScriptingEngine.executeScript method: > > // setting the same security manager the second time causes it to be > // removed. > //securityManager.setFinalSecurityManager(scriptingSecurityManager); // > Commented out. --Dan > securityManager.setFinalSecurityManager(null); // Inserted: be explicit > about setting it to null. --Dan > > At that location, the security manager should be disabled; if it is not, > it causes problems with loading of some classes later. Setting an object > two times to disable something seems like a bug-prone idea. I am setting > the final security manager as null, as that is the intended effect. I am > not the author of the code, so I am not sure whether it matches the > intention. > > As regards the method securityManager.setFinalSecurityManager, I do not > understand why it is implemented the way it is: > > public void setFinalSecurityManager(SecurityManager > pFinalSecurityManager) { > if(pFinalSecurityManager == mFinalSecurityManager) { > mFinalSecurityManager = null; > return; > } > if(mFinalSecurityManager != null) { > throw new SecurityException("There is a SecurityManager installed > already."); > } > mFinalSecurityManager = pFinalSecurityManager; > } > > I would implement the method as follows: > > public void setFinalSecurityManager(SecurityManager pFinalSecurityManager) > { > mFinalSecurityManager = pFinalSecurityManager; > } > > The method should not worry about whether there is already a security > manager set. When the caller wants to get the security manager removed, the > caller should be very explicit about it, by passing "null". > > --Dan > ------------------------------------------------------------------------------ Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev _______________________________________________ Freemind-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freemind-developer
