In my most complex XPages app, I've gotten myself into a situation where I start getting "X is incompatible with X" ClassCastExceptions whenever I re-save pretty much any design element, including things like CSS files that aren't even used by any of the XPages themselves and, on a lark, a navigator (!). It happens very reliably and immediately after saving a design element.

I've looked into it a bit and I've gathered that it's a known thing related to the way the classloaders work from several sources:

- http://stackoverflow.com/questions/5352550/meaning-of-java-lang-classcastexception-someclass-incompatible-with-someclass

- http://www.mindoo.com/web/blog.nsf/dx/05.02.2011131456KLEGDD.htm

- http://www-10.lotus.com/ldd/ddwiki.nsf/dx/Creating_a_Java_Control_in_an_NSF#For+problems+in+the+faces-config+file

It sounds like the problem is generally resolved by spinning out the libraries to a filesystem JAR file, but that's something of a drag during active development.

I've mostly resigned myself to the notion that, whenever I save an XPage in this database, I have to re-save faces-config.xml or one of the back-end Java classes, but sometimes it arises on its own, even when I haven't touched the design at all that day. The exception generally deals with one specific bean, but I don't think that's the problem, since, if I remove the part that access that, it simply complains about the next bean I try to access.

I've been wracking my brain trying to figure out what's triggering it. Since it doesn't happen to other apps on the same server and DOES happen to this app on different servers (one 64-bit Windows and one 32-bit Linux), it's clearly something I've done, but it's not clear what. I've tried changing my session- and application-scoped beans to request scope, making everything Serializable, fiddling with the XPages options on the Application Properties document, changing the project Java compiler compatibility from the default 1.5 to 1.6, upgrading to each 8.5.2 fix pack as it comes out, and ensuring that no Domino product objects are stored in the session or application scopes.

Does anybody know of any other tripwires that could be triggering this that I should look out for?