org.hibernate.hql.ast.HqlLexer can cause a ClassNotFound exception in an OSGi environment with a stacktrace like
The HqlLexer class has antlr.CharScanner as a superclass, as evidenced by the stacktrace. The contents of the method are:
It passes the name of the HqlToken class as a string to CharScanner, which then ultimately attempts to find HqlToken via antlr.Utils. The tokenObjectClass is a protected field. The code can be simplified by simply setting the field directly to HqlToken.class which is obviously already available to the HqlLexer class.
The reason this causes the exception in an OSGi environment is that the context class loader available to ANTLR is limited to what is explicitly declared in the ANTLR bundle. Since ANTLR cannot (and should not) have to know about all the classes that it may be passed, it does not declare an import on the org.hibernate.hql.ast package. By passing the class directly, the lookup is avoided from within the ANTLR package.
At least from 3.3.2 on, and at least on Postgres and Derby
I like your patch but I did mine differently in HHH-6536. One question that I have about your patch, can it be made to use an antlr api instead of referencing a protected variable directly? Is the protected tokenObjectClass documented as being safe to change (in terms of future releases of antlr including the same variable)?
In my patch, I set the thread context classloader to HqlToken.class.getClassLoader(). Would that work for your case also?
Scott, this patch might not work with OSGi class loading. I'm not sure if the runtime classloading will like it. Keep it on the radar.
Marking out-of-date. Will be addressed in HHH-7991.