Redeployed Application Can Still Access Old Object Instances when Using Application Class Loaders (Doc ID 1389725.1)

Last updated on NOVEMBER 05, 2016

Applies to:

Oracle GlassFish Server - Version 2.1 to 3.1.1 [Release 2.1 to 3.1]
Information in this document applies to any platform.
***Checked for relevance on 08-Jul-2013***

Symptoms

On GlassFish Server 2.x and 3.x, when attempting to invoke an EJB business method, the following error might occur:

[#|2011-12-15T15:21:23.730+0800|INFO|oracle-glassfish3.1.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=19;_ThreadName=Thread-2;|java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at ejb.FacadeControllerBean.call(FacadeControllerBean.java:37)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(E
JBSecurityManager.java:1052)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
,,,
Caused by: javax.ejb.EJBException: Attempt to invoke when container is in Undeployed
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1995)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1990)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:222)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at $Proxy261.load(Unknown Source)
... 46 more
|#]


This issue can be reproduced at will with the following steps:

  1. Deploy a sample standalone EJB module:
    % asadmin deploy --libraries /pathto/utility.jar standalone-ejb.jar

    The EJB module contains two stateless EJBs (SLSB) which use an external utility.jar file.  The structure of the module is as follows:
    standalone-ejb.jar
    +- ejb/FrontBean
    +- ejb/DependentBean

    The utility.jar has the following contents:
    utility.jar
    +- ejb/FrontBeanRemote
    +- utility/CacheServiceLocator

    The FrontBean SLSB uses a singleton class called utility.CacheServiceLocator which is used to look up and cache the reference to the dependent SLSB in a HashTable.

  2. The standalone EJB is invoked by an appclient.  This looks up the FrontBean which then looks up the DependentBean which is cached inside the CacheServiceLocator.

  3. Next the standalone EJB module is undeployed:

    % asadmin undeploy standalone-ejb.jar
  4. So at this point the EJB is no longer accessible.

  5. Redeploy the EJB module.

  6. When the appclient is run this time the above exception is reported, indicating that the old EJB reference is still present in the CacheServiceLocator singleton.

Cause

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms