Exception ' java.lang.IllegalArgumentException: Not an managed type' upon a tomcat context reload [DATACMNS-412]

[spring-projects-issues]

Nick Weedon opened DATACMNS-412 and commented

Exception ' java.lang.IllegalArgumentException: Not an managed type' upon a tomcat context reload when cached 'RepositoryInformation' (change added in DATACMNS-395) is returned by the 'RepositoryFactorySupport' class.

The 'Environment' field of this Jira issue contains details on my setup (emdedded tomcat 7).

The attached file 'tomcat-log.txt' contains the full trace of the exception and context reload.

If I modify RepositoryFactorySupport#getRepositoryInformation and have it always return new RepositoryInformation (i.e. effectively the old behaviour prior to the DATACMNS-395 change) then this exception does not occur.

Attached ("RepositoryInformationCmp.txt") is a dump of the cached version of RepositoryInformation vs a newly created instance (I used ReflectionToStringBuilder with a recursive 'ToStringStyle' strategey to produce the dump). The 'diff' utility reveals that the content of both instances is identical.
Note however that the recursion stops at java.lang classes and so does not include the contents of the 'Class' classes which is where I believe the difference lies.

My theory on the cause of this problem is that a new class loader is instantiated when the Tomcat context is reloaded, thereby somehow invalidating existing 'Class' meta-information.

Interestingly, the first comment I saw upon navigating to the Spring Data Commons Jira site, by Seppel Hardt read with words to the effect that he encountered a similar problem and had reached a similar conclusion.

By anecdotal observation of stack overflow posts, I see there appears to numerous other users facing this issue also.

---

Affects: 1.7 M1 (Codd), 1.6.3 (Babbage SR2)

Attachments:

• RepositoryInformationCmp.txt (3.67 kB)
• server.xml (6.28 kB)
• tomcat-log.txt (12.24 kB)

Issue Links:

• DATACMNS-395 RepositoryFactorySupport should cache RepositoryInformation instances

Backported to: 1.6.4 (Babbage SR3)

[spring-projects-issues]

Thomas Darimont commented

We could try to detect whether the classloader / classloading infrastracture has changed (servlet context-reload) and invalidate the cached RepositoryInformation, create a new one, cache it and return that newly cached instance.
We probably have to do this kind of cache invalidation for EntityInformation as well

[spring-projects-issues]

Thomas Darimont commented

Would you mind providing a small example that reproduces this issue?

[spring-projects-issues]

Nick Weedon commented

No problem. It will be a bit of an undertaking to reproduce since it is a slightly elaborate scenario. I will aim to provide an example project as soon as possible but probably no earlier than tomorrow (it is 8:00PM here)

[spring-projects-issues]

Oliver Drotbohm commented

I pushed a potential fix to the master branch. Feel free to give it a spin. I effectively turned a static cache (which might survive the redeployment as it keeps references to classes) into a non static one so that it should be garbage collected on ApplicationContext shutdown.

If you can verify it to solve the issue I'm happy to port it back to the bugfix branch

[spring-projects-issues]

Nick Weedon commented

I have tested your fix against my project by swapping between 1.7.0M1 and the build that contains your fix. When retesting against the 1.7.0M1 build I can see that the problem still occurs (as expected). When I switch to the build that contains your fix I can see that the problem no longer occurs. I can therefore definitely confirm that your fix resolves the issue.

Thanks for fixing this so quickly. Last night I had just started putting together a 'throw-away' sample spring project to reproduce the issue. The fact that you have now fixed this already saves me a lot of time as I no long need to complete that project.

Cheers, much appreciated