[jboss-dev] JBAS-7650 - jboss-cl 2.2.x upgrade WAS Re: Planning to revert

[Brian Stansberry]

On 02/01/2010 09:21 AM, Adrian Brock wrote:
> On Mon, 2010-02-01 at 13:36 +0100, Adrian Brock wrote:
>> Obviously, I still need to figure out why it is failing with
>> useLoadClassForParent=false
>> That's just an optimization to avoid locking the
>> bootstrap classloader too much. It should have the same
>> semantics.
>> https://jira.jboss.org/jira/browse/JBCL-142
>
> It took me a while to figure this out because it occurs
> while the logging is getting reconfigured, meaning it was
> difficult to get information about what was happening. :-)
>
> I'm not really sure how to fix it?
>

Perhaps have jboss-stdio ensure all actions that require permissions are 
completed before stdio is captured? That's likely to be quite ugly and 
fragile though.

> The problem only occurs when you have a security manager
> installed and you are logging access control requests.
>
> What is happening is that stdio has just captured
> System.out/err. At the next access control logging
> stdio tries to write this to the logging framework.
>
> It needs java.lang.Math to do this - see write():
> http://viewvc.jboss.org/cgi-bin/viewvc.cgi/common/jboss-stdio/trunk/src/main/java/org/jboss/stdio/WriterOutputStream.java?revision=3915&view=markup
> Its the first such event, so it needs to load the class.
>
> But while it is loading the class, jboss-cl does a
> getResource("java/lang/Math.class") which also
> does some access control logging
> which will again get intercepted by stdio.
>
> It then of course goes through write()
> java.lang.Math is not yet loaded so it repeats.
>
> Its reported as a ClassCircularityError
> as Brian said, but its really a recursion problem.
>
> If you use loadClass() directly, there is no
> logging of resource access so you don't get the problem.
>


-- 
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat