Conflicting CLASS files

Question

In our production environment we encounter Error 500 with some XPage - using Java bean. I have traced the problem to this: when application is built/clean by one of our developers, we get this conflict in classes:

RESViewBean$Kocka(985FB00AF0EEE24BC1258028004C47FE).class
RESViewBean$Kocka.class
RESViewBean$Resource(34A92B0BA75D7267C1258028004C47FC).class
RESViewBean$Resource.class

Build/clean by other developers (including me) removes these conflicting two classes. My thought - something with source control. But said developer did not set it up, and removing application from his list of applications in Designer client (what would break such link) does not help.

What intrigues me the most is the fact, it has no influence on development server and test application on production server (in different path). But production copy of the application will result in this exception:

17.2.2017 9:38: Exception Thrown
javax.servlet.ServletException: java.lang.NoClassDefFoundError: sk/posam/iis/mrp/xsp/RESViewBean$Resource
    at com.ibm.xsp.webapp.FacesServlet.handleError(FacesServlet.java:653)
    at com.ibm.xsp.webapp.FacesServlet.renderErrorPage(FacesServlet.java:482)
    at com.ibm.xsp.webapp.FacesServlet.service(FacesServlet.java:183)
    at com.ibm.xsp.webapp.FacesServletEx.service(FacesServletEx.java:138)
    at com.ibm.xsp.webapp.DesignerFacesServlet.service(DesignerFacesServlet.java:103)
    at com.ibm.designer.runtime.domino.adapter.ComponentModule.invokeServlet(ComponentModule.java:588)
    at com.ibm.domino.xsp.module.nsf.NSFComponentModule.invokeServlet(NSFComponentModule.java:1335)
    at com.ibm.designer.runtime.domino.adapter.ComponentModule$AdapterInvoker.invokeServlet(ComponentModule.java:865)
    at com.ibm.designer.runtime.domino.adapter.ComponentModule$ServletInvoker.doService(ComponentModule.java:808)
    at com.ibm.designer.runtime.domino.adapter.ComponentModule.doService(ComponentModule.java:577)
    at com.ibm.domino.xsp.module.nsf.NSFComponentModule.doService(NSFComponentModule.java:1319)
    at com.ibm.domino.xsp.module.nsf.NSFService.doServiceInternal(NSFService.java:662)
    at com.ibm.domino.xsp.module.nsf.NSFService.doService(NSFService.java:482)
    at com.ibm.designer.runtime.domino.adapter.LCDEnvironment.doService(LCDEnvironment.java:357)
    at com.ibm.designer.runtime.domino.adapter.LCDEnvironment.service(LCDEnvironment.java:313)
    at com.ibm.domino.xsp.bridge.http.engine.XspCmdManager.service(XspCmdManager.java:272)
Caused by: java.lang.NoClassDefFoundError: sk/posam/iis/mrp/xsp/RESViewBean$Resource
    at sk.posam.iis.mrp.xsp.RESViewBean.updateResources(RESViewBean.java:69)
    at sk.posam.iis.mrp.xsp.RESViewBean.<init>(RESViewBean.java:28)
    at java.lang.J9VMInternals.newInstanceImpl(Native Method)
    at java.lang.Class.newInstance(Class.java:1688)
    at java.beans.Beans.instantiate(Beans.java:189)
    at java.beans.Beans.instantiate(Beans.java:80)
    at com.sun.faces.config.ManagedBeanFactory$1.run(ManagedBeanFactory.java:222)
    at java.security.AccessController.doPrivileged(AccessController.java:413)
    at com.sun.faces.config.ManagedBeanFactory.newInstance(ManagedBeanFactory.java:216)
    at com.sun.faces.application.ApplicationAssociate.createAndMaybeStoreManagedBeans(ApplicationAssociate.java:291)
    at com.sun.faces.el.VariableResolverImpl.resolveVariable(VariableResolverImpl.java:135)

What can possibly create those duplicate class files?

Answer 1

Just a rough guess: We had a similar issue with custom controls and Xpages. One of our developers was working from a remote location, and it turned out that multiplication of XSP elements (Xpages and custom controls but also their localised language properties) happened during replication. The tricky part in our case was, that those multiple versions where only visible in Package Explorer view.

We never really found the real cause but I tend to believe that this had to do with him having to sign elements before doing a local preview. Then during replication of any re-signed element a duplication occurred. Something like a replication conflict.

We stopped that by making our colleague transmit his design elements independent from our development dB (via mail or be replication of a separate db). Then one of us internal developers would copy the elements into our main db. Also we decided that no one in the team would work directly on the server but on a local replica instead.

A bit tedious but from then on there was no more duplication.