@OrderBy causes java.lang.ClassCastException: antlr.CommonToken cannot be cast to antlr.Token [duplicate]

本小妞迷上赌 提交于 2019-12-01 18:12:47
FilMiOs

I am not sure if this is similar to your case but I had similar problem while using WebLogic with it's feature called deployment plan. Solution can be found in Utils.class inside of antlr itself. They use method getContextClassLoader:

Fortunately there is a switch in this class which let us to disable it:

You have to add to JAVA_OPTS of application server: -DANTLR_USE_DIRECT_CLASS_LOADING=true And problem should be gone.

Alepac

There are a lot of question regarding this issue (e.g. this one) and the error, as you supposed, seems caused by an automatically inserted dependency, antlr.

Try to exclude the dependency as suggested in the question above, so in your pom add:

<dependency>
   ...

   <exclusions>
      <exclusion>
         <groupId>antlr</groupId>
         <artifactId>antlr</artifactId>
      </exclusion>
   </exclusions>
</dependency>
M.Liang

The fix is using system property as @FilMiOs said (I would have comment on his reply if had enough points).

Anyway, the root cause is thread classloader and normal classloader are pointing to different locations. As explained here: Difference between thread's context class loader and normal classloader

It happens to me in a tomcat instance where multiple applications share a common thread pool. The thread classloader is whichever app started the thread. But when the thread reused by another application, the thread classloader stay the same. Hence the difference.

To confirm, set a break point and watch the following two results, see if they are the same.

Thread.currentThread().getContextClassLoader()

this.getClass().getClassLoader()
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!