On Jun 16, 2011, at 1:35 PM, Jonathan Gallimore wrote:
> No problem. I've been able to reproduce it - just using the security policy
> you provided with our simple-stateless example was enough. I don't have a
> fix yet, but I'll post back when I've debugged it a bit further.
I'm not sure it is "fixable". At least not easily.
Any secure operation has to be surrounded with a doPrivillaged call. Getting a
system property is a "secure" operation and all related code would have to look
like this:
String lineSeparator = java.security.AccessController.doPrivileged(
new java.security.PrivilegedAction<String>() {
public String run() {
return System.getProperty("line.separator");
}
}
);
Setting Thread classloader, using reflection and a bunch of other things would
all need to be done like that. Not just in our code but in every 3rd party
library like OpenJPA, CXF, ActiveMQ, etc.
I don't recall if there is a way to exclude libraries from security
requirements. If there is, that would work for the OpenEJB libraries and all
the 3rd party libraries. If not, I think it's simply impossible.
-David
>
> On Thu, Jun 16, 2011 at 8:16 AM, mclu <[email protected]> wrote:
>
>> Thx Jonathan!
>>
>> Plz tell me at least if you can reproduce it or not.
>> I can also try to create a small example zip if needed.
>>
>> I invested again a lot of hours and debug into jdk and openejb sources but
>> I
>> could not find the problem.
>>
>> Greets
>> Markus Lutum
>>
>> --
>> View this message in context:
>> http://openejb.979440.n4.nabble.com/java-lang-RuntimePermission-setContextClassLoader-if-using-java-security-tp3599454p3601707.html
>> Sent from the OpenEJB Dev mailing list archive at Nabble.com.
>>
