tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <>
Subject Re: ClassNotFoundException: JaccProvider$Factory
Date Mon, 21 Jan 2008 20:32:40 GMT

On Jan 21, 2008, at 7:19 AM, Martin Vysny wrote:

> On Wed, 2008-01-16 at 14:16 -0800, David Blevins wrote:
>> On Jan 16, 2008, at 12:15 PM, Dain Sundstrom wrote:
>>> Caused by:
>>> java
>>> .lang
>>> .ClassNotFoundException:org
>>> $Factory
>>>      at$
>>>      at Method)
>>>      at
>> [...]
>>>      at java.lang.Class.forName(
>>>      at
>>> javax
>>> .security
>>> .jacc
>>> .PolicyConfigurationFactory
>>> .getPolicyConfigurationFactory(
>>>      ... 44 more
>>> But, if you look at our spec code for
>>>, there is no code on
>>> line 131, and after browsing the full history of that file, there
>>> has never been a call to Class.forName on line 247.  Do you have a
>>> second (possibly one from Sun), implementation of the JACC spec in
>>> your lib directory or one of your applications?
>> That's an interesting possibility.  Could be there is another jar in
>> your classpath providing the jacc api and it randomly ends up before
>> ours (and presumably it's blowing up in it's static initializer).
>> Looks like you're in maven2/surefire when this happens.  It should be
>> possible to get a list of the jars in your classpath via the code I
>> posted earlier (surefire's classloader is a subclass of
>> URLClassLoader).  Then you should be able to look in them and see how
>> many copies copy of javax/security/jacc/
>> PolicyConfigurationFactory.class you have.
>> I've got a script for grepping through jars that might be handy:
>> -David
> Hi all,
>  thanks again, you were right! There was javaee-1.4.jar in the
> classpath along with geronimo-jacc implementation. When we removed
> javaee-1.4.jar from classpath, OpenEJB started succesfully.
>  It was quite an interesting bug though, because on computer A it
> worked even with javaee-1.4 on classpath (regardless of whether javaee
> was first or last on the classpath), on computer B it failed. Perhaps
> some classloader caused it - I don't know for sure. However, to fix  
> this
> issue just remove javaee (or other non-OpenEJB/Geronimo JACC
> implementation) from classpath.

Maven doesn't behave consistently from one computer to another in  
terms of the order it processes the dependencies.  I think it must be  
using a HashMap (or similar collection where order is not guaranteed)  
to hold the deps while doing it's include/exclude and other sort of  
processing.  We had a similar issue in our JAXB tree for the ejb- 
jar.xml data.  We were keeping the resulting EnterpriseBean jaxb  
objects in a HashMap and then the order in which they'd be written to  
xml was randomly breaking tests for some people sometimes.  We  
switched it to use TreeMap instead and the problem disappeared.

> When I tried to put it
> into the static {} block the same classloader was reported. This is  
> what
> I expected - if you do some classloader magic while loading JACC, you
> probably restore old classloader in the finally{} statement.

This is good.  It seemed less likely that this was the issue, but you  
never know.  After your report I did add some classloader swap/restore  
around the JACC loading code in the case that the impl is ours -- I  
grab our impl java.lang.Class and set it's classloader before we ask  
JACC to load the factory.  Won't affect your scenario as it was a  
classpath issue, but I figured the problem could still occur if  
someone did swap the thread classloader and didn't swap it back (or  
had a library they called that did that).

Anyway, glad to hear things are working well!


View raw message