Hibernate Lazy Loading Proxy - GORM Static Api'

Question

This question is an exact duplicate of:

• Javassist Enhancement Fails on Deployment 1 answer

I am refactoring legacy code of an existing System in groovy/grails. Instead of using .class.name to check for a class type, I want to use the proxy safe and more concise .instanceOf (although the long term goal is to get rid of those type checks entirely).

EDIT 2014/10/07: The shift to the static instanceOf method is not only for more concise code; this is about not having to worry about the hibernate proxies that result from the lazily loaded instances. The service method below may receive a domain class instance or a hibernate proxy as argument.

Mostly the check for the class name is used when iterating through lists of objects that share a superclass. This is a simplified example:

class PartnerContract{
    Partner partner
    String serialCode
    Date startDate
    Date endDate
}

class ServiceContract extends PartnerContract{
    BigDecimal payRate
}

class SpecialOrderContract extends PartnerContract
    BigDecimal wage
}

A common operation is to find all customer contracts (not specified in domain example) that fit to a certain partner contract.

In the service method, it is implemented similar to that:

    ...
    def pc = []
    partnerContracts.each{pv ->
      (getCustomerContracts(pv).collect(pc){it}
    }    
    ...

def getCustomerContracts(PartnerContract partnerContractInstance){
    def customerContracts = []

    if(partnerContractInstance.instanceOf(ServiceContract)){    
        //find contracts and add to customerContracts
    }
    else if(partnerContractInstance.instanceOf(SpecialOrderContract)){
        //find contracts and add to customerContracts
    }
    customerContracts
}

In my local environment, everything works as expected. (EDIT 2014/10/07: run-war, test run-war and prod run-war work just fine.) This was not the kind of change where I was expecting any issues at all, since it seemed rather trivial. But, weirdly, when deploying a WAR file to the server, the following exception is thrown:

Following exception is thrown:

com.itf.propart.PartnerContract_$$_javassist_157 cannot be cast to com.itf.propart.ServiceContract

In my opinion, no matter what I have done wrong using instanceOf, it is very misleading that it works in a local environment but not when building a WAR file. I don't understand why it should work under any circumstances if it is not correct. Feels quite buggy.

EDIT 2014/10/07: I found something that might be related in the server.log. This exception is thrown for most (or maybe even all) domain classes. DienstleistungsVertragTM is the ServiceContract:

    [#|2014-10-07T13:03:50.348+0200|INFO|glassfish3.0.1|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=34;_ThreadName=Thread-1;|2014-10-07 13:03:50,348 [http-thread-pool-9048-(19)] ERROR pojo.BasicLazyInitializer  - Javassist Enhancement failed: com.itf.propart.DienstleistungsVertragTM
java.lang.NoSuchMethodError: javassist.util.proxy.ProxyFactory.setUseCache(Z)V
    at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:535)
    at com.sun.enterprise.web.WebModule.start(WebModule.java:499)
    at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1947)
    at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1619)
    at com.sun.enterprise.web.WebApplication.start(WebApplication.java:90)
    at org.glassfish.internal.data.EngineRef.start(EngineRef.java:126)
    at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:241)
    at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:236)
    at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:339)
    at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:183)
    at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:272)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:305)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:320)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1176)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$900(CommandRunnerImpl.java:83)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1224)
    at org.glassfish.admingui.common.util.LocalDeploymentFacility$LocalDFCommandRunner.run(LocalDeploymentFacility.java:138)
    at org.glassfish.deployment.client.AbstractDeploymentFacility.deploy(AbstractDeploymentFacility.java:350)
    at org.glassfish.admingui.common.util.DeployUtil.invokeDeploymentFacility(DeployUtil.java:89)
    at org.glassfish.admingui.common.util.DeployUtil.deploy(DeployUtil.java:66)
    at org.glassfish.admingui.common.handlers.DeploymentHandler.deploy(DeploymentHandler.java:186)
    at com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
    at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
    at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
    at com.sun.jsftemplating.layout.event.CommandActionListener.invokeCommandHandlers(CommandActionListener.java:150)
    at com.sun.jsftemplating.layout.event.CommandActionListener.processAction(CommandActionListener.java:98)
    at javax.faces.event.ActionEvent.processListener(ActionEvent.java:88)
    at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:772)
    at javax.faces.component.UICommand.broadcast(UICommand.java:300)
    at com.sun.webui.jsf.component.WebuiCommand.broadcast(WebuiCommand.java:166)
    at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:775)
    at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1267)
    at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:82)
    at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
    at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
    at javax.faces.webapp.FacesServlet.service(FacesServlet.java:312)
    at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:223)
    at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
    at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:85)
    at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:239)
    at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
    at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
    at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
    at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
    at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
    at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
    at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
    at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
    at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
    at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
    at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
    at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
    at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
    at java.lang.Thread.run(Thread.java:619)

Answer 1

The issue described in my question is just one consequence of another issue that occurs on deployment.