2

I have a web application that is developed by Java 8.0 and deployed on Tomcat 8.0. In some scenarios, I've got an error with a string with which I'm not familiar. For example, I have an error same as below in one of my scenarios:

Caused by: java.lang.IllegalArgumentException
    at sun.reflect.GeneratedMethodAccessor6555.invoke(Unknown Source) ~[?:?]
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_102]
    at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_102]
    at org.hibernate.property.access.spi.SetterMethodImpl.set(SetterMethodImpl.java:44) ~[hibernate-core-5.2.17.Final.jar:5.2.17.Final]
    at org.hibernate.tuple.entity.AbstractEntityTuplizer.setPropertyValues(AbstractEntityTuplizer.java:649) ~[hibernate-core-5.2.17.Final.jar:5.2.17.Final]
    at org.hibernate.tuple.entity.PojoEntityTuplizer.setPropertyValues(PojoEntityTuplizer.java:205) ~[hibernate-core-5.2.17.Final.jar:5.2.17.Final]
    at org.hibernate.persister.entity.AbstractEntityPersister.setPropertyValues(AbstractEntityPersister.java:4745) ~[hibernate-core-5.2.17.Final.jar:5.2.17.Final]
    at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:189) ~[hibernate-core-5.2.17.Final.jar:5.2.17.Final]
    at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:128) ~[hibernate-core-5.2.17.Final.jar:5.2.17.Final]
    at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1152) ~[hibernate-core-5.2.17.Final.jar:5.2.17.Final]
    at org.hibernate.loader.Loader.processResultSet(Loader.java:1011) ~[hibernate-core-5.2.17.Final.jar:5.2.17.Final]
    at org.hibernate.loader.Loader.doQuery(Loader.java:949) ~[hibernate-core-5.2.17.Final.jar:5.2.17.Final]
    at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:341) ~[hibernate-core-5.2.17.Final.jar:5.2.17.Final]
    at org.hibernate.loader.Loader.doList(Loader.java:2692) ~[hibernate-core-5.2.17.Final.jar:5.2.17.Final]
    at org.hibernate.loader.Loader.doList(Loader.java:2675) ~[hibernate-core-5.2.17.Final.jar:5.2.17.Final]
    at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2507) ~[hibernate-core-5.2.17.Final.jar:5.2.17.Final]
    at org.hibernate.loader.Loader.list(Loader.java:2502) ~[hibernate-core-5.2.17.Final.jar:5.2.17.Final]
    at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:502) ~[hibernate-core-5.2.17.Final.jar:5.2.17.Final]
    at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:392) ~[hibernate-core-5.2.17.Final.jar:5.2.17.Final]
    at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216) ~[hibernate-core-5.2.17.Final.jar:5.2.17.Final]
    at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1490) ~[hibernate-core-5.2.17.Final.jar:5.2.17.Final]
    at org.hibernate.query.internal.AbstractProducedQuery.doList(AbstractProducedQuery.java:1445) ~[hibernate-core-5.2.17.Final.jar:5.2.17.Final]
    at org.hibernate.query.internal.AbstractProducedQuery.list(AbstractProducedQuery.java:1414) ~[hibernate-core-5.2.17.Final.jar:5.2.17.Final]
    at sun.reflect.GeneratedMethodAccessor8215.invoke(Unknown Source) ~[?:?]
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_102]
    at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_102]
    ... 64 more

I've reinstalled Java and Tomcat, but I've been still getting this error. Does anyone have any idea or suggestion?

Ehsan
  • 33
  • 6

1 Answers1

2

This is not normal behavior for off-the-shelf Java. So we must conclude that these stacktraces are not being generated by your code calling Throwable::printStacktrace()

After doing a bit of digging, one possible cause is that you are using Logback for your logging, and in particular using %xThrowable rather %throwable in a PatternLayout pattern. This includes extra packing information in the stacktrace with the syntax that you are seeing. You should refer to the Logback documentation for more details, because there are many variations possible in the pattern language.

The documentation also says:

Please note that given its potential cost, computation of packaging data is disabled by default. When computation of packaging data is enabled, PatternLayout will automatically assume the %xThrowable suffix instead of %throwable suffix at the end of the pattern string.

So the suffixes could be a side-effect of doing this:

 <configuration packagingData="true">
    ...
 </configuration>

in the Logback config.


UPDATE: You said that you are using Log4j2 rather than Logback.

Log4j2 has an equivalent pattern-based logging layout with %xThrowable support; see https://logging.apache.org/log4j/2.x/manual/layouts.html

Please consider that this string appears in some stack-traces, not in all of that.

That can be explained if your application or some 3rd-party libraries that you are using are calling Throwable::printStacktrace or similar directly in some circumstances, and generating the stacktraces via the logger in others.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • Thanks for your answer. But, we aren't using Logback for our logging and there isn't any dependency on Logback (also transitive dependency). – Ehsan Jun 23 '19 at 06:25
  • @StephanC - We are using Log4j-2.0 – Ehsan Jun 23 '19 at 06:47
  • @StephanC - Please consider that this string appears in some stack-traces, not in all of that. – Ehsan Jun 23 '19 at 06:50