Class cast exception when deserializing in Spring

[danomatic]

When using @Cacheable in a ThreadPoolExecutor, the deserialize is failing. It looks like this:

java.lang.ClassCastException: com.company.SomeBean cannot be cast to com.company.SomeBean
	at com.company.services.SomeService$$EnhancerBySpringCGLIB$$a724921e.getData(<generated>)
	at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
	at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:720)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
	at org.springframework.aop.interceptor.AsyncExecutionInterceptor$1.call(AsyncExecutionInterceptor.java:115)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

If I write a unit test that just calls the method outside of a thread pool, it seems to work. Do you have any idea why this would happen? Can this library use a custom serializer?

[dnlprplt]

Can you please give us the signature of the method you put the @Cacheable on? As well as the params of the @Cacheable you used?

And if you can give us a unit test we can run, it would be even better.

[aymhce]

hello, i have the same issue

java.lang.ClassCastException: fr.***.digital.domain.***UserDetails cannot be cast to fr.***.digital.domain.***UserDetails
	at fr.***.digital.client.***ConnectClient$$EnhancerBySpringCGLIB$$63ecbbdb.getUserDetails(<generated>)
	at fr.***.digital.security.jwt.TokenProvider.getAuthentication***Connect(TokenProvider.java:112)
	at fr.***.digital.security.jwt.JWTFilter.doFilter(JWTFilter.java:47)
	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
	at org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:121)
	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
	at org.springframework.security.web.header.HeaderWriterFilter.doFilterInternal(HeaderWriterFilter.java:66)

This is my method :

    @Cacheable(value = "getUserInfo", key = "#key")
    public ***UserDetails getUserDetails(OAuth2AccessToken token, String key) {

And my spring boot config

spring:
    cache:
        mongo:
            caches:
                -
                  # TTL (in seconds).
                  ttl: 600
                  # MongoDB collection name.
                  collectionName: userInfoCache
                  # Cache name for the @Cacheable annotation.
                  cacheName: getUserInfo
                  # Value that indicates if the collection must be flushed when the application starts.
                  flushOnBoot: true

[aymhce]

For information, I have this problem when I use Spring Boot DevTools on my eclipse or when I do ./gradlew bootRun. There is no problem when my application is running on production environment.

[dnlprplt]

Thanks for your input.

Considering my current workload, I won't be able to look into it immediately. But we welcome PRs.

[sake92]

Hi @danielprplt! I have some questions regarding serialization:

1. Why does the CacheDocument have id as a String? Spring docs say that DefaultKeyGenerator generates a hashCode of all paremeters (returns Object). So, it should be an Object instance (Mongo has no problem to deal with that)?

2. Same class, different field: String element. Serialized here to base64 here. Why was this necessary? Forcing us to implement Serializable?

That's all, I'll send a PR if you agree this should be fixed. 😄

[dnlprplt]

Hello @sake92,

1. Mongo can store objects fine, but we need to consider how to effectively retrieve the cached value based on the key. If the key is a random object, how can we query mongo effectively? Therefore, we chose to use a String, on which we can create an index in mongo. Also, using hashcode as a key, you can end up with collisions.

2. We chose to use the standard serialization mechanism of Java simply because its the standard. There was a plan to support "Mongo serialization" as well. There is now a PR to allow customization of the serialization mechanisms: support for custom serializer #2

[weaamhafez]

Hi @aymhce

did you find a solution on this issue while using eclipse please?

[aymhce]

Sorry, i'm no longer work on the project that needed to use spring-cache-mongodb. However, thank you for issue fixing :)

[itoche]

@danielprplt @cyrilschumacher do you plan to merge the mentioned pull request ?