I would say so but will take a look.
An example might be:
<bean name="BadBean" class="java.lang.Object"> <constructor factoryMethod="halt" factoryClass="java.lang.System"/> </bean>
A somewhat related issue is the current testsuite usage of a global security policy for the testsuite codebase. I had to hack this to add runtime permissions for the class loader creation needed by the mock vfs class loaders. It would be good if a fine grained security context could be specified for certain testsuite classes without having to package them in a seperate directory/jar in order to be able to assign a codebase for permissions. I wonder if a package based permission scheme would be possible.
I wonder if a package based permission scheme would be possible.
We'd need to play around with junit's classloading such that the packages have
different protection domains/code bases.
P.S. I already fixed the problem on this thread.
Yes, I saw the change to handle the context, but I mentioned this issue here as it could be possible to decorate the context with an identity to perform security checks based on who rather than from where the code comes. I'm not a fan of URL based permissions in an app server as it generally imposes an unnecessary seperation of code.