[GLASSFISH-4021] Resouce Injection does not work in HandlerChain due to EJB initialization order (non-deterministic) Created: 21/Jan/08  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: ejb_container, web_services
Affects Version/s: V3
Fix Version/s: 4.1.1

Type: Bug Priority: Critical
Reporter: gfuser9999 Assignee: Lukas Jungmann
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: All
Platform: All

Issuezilla Id: 4,021
Tags: 3_1-exclude, 4_0-release-notes, 4_0-release-notes-completed, 4_0-release-notes-drafted


1. Resource injections fails when using HandlerChain that have a
EJB/Resource injected that is an EJB/JNDI. And one gets
"Handler xxxxx instance injection failed : Exception attempting to inject
Resolved Ejb-Ref xxxx/bean@jndi: - > xxxxx]

The issues is that assuming we have 2 EJB and we want to have

  • EJB B exposed as Webservice and handle a HandlerChain handler
    So we have
    @HandlerChain(file = "handle.xml")
    public void EJBBBean { ... }
  • We do not care above EJB A
  • Note that the handler is
    public class handler implements SOAPHanlder { @EJB EJBBBean bean; .... }
  • Now when one deploy this depending on the ordering
    of initialization of EJB, sometimes
    EJBA, EJBB and this works but if sometimes it is
    EJBB, EJBA then resource injection fails
  • The issues is that the following happens where it seems when
    a EJB is exposed as WebService and have a handler,
    a) The EJB is created and the handler is created
    b) The handler will be injected but then the issue is
    that THERE is IT may be possible that at the time
    the dependency is not met (since EJBA is not loaded or initialized
    nor registered to the JNDI even)

com.sun.enterprise.InjectionException: Exception attempting to inject Resolved
Ejb-Ref org.test.ws.FailInjectionHandler/bean@jndi: - > b5Bean into class

  • Now, this problem does not seems to be that the system does not resolve ordering
    Since writing more EJB seems to say that the GF system tends to order the EJB
    However, there seems to be some race or data structure ordering issue since
    that the EJB module loading sequence on every stop/start is different and
    it is possible to get a EJB processing order that does not work.

Testcase and details
1. Get the attached NB6 ejbdeptest.zip and deploy
This testcase have many a few EJB modules to make this easier to hit this
Deploy ejbdeptest.ear

2. Stop/Start (asadmin stop-domain/start-domain)
and look for the injection failure. (REPEAT until failure is SEEN)
(grep SEVERE)

3. [Unpredictable and repeat (2) until SEVERE happens like below]

org.test.ws.FailInjectionHandler instance injection failed : Exception
attempting to inject Resolved Ejb-Ref
org.test.ws.FailInjectionHandler/bean@jndi: - > b5Bean into class

3. Note some tracing does indicate that Bean processing via getEjbDescriptors()
varies sometimes and below is a failure sequence. (It is unknown
why the behaviour on the EJB processed changes sometimes)

re.classloading|_ThreadID=10;_ThreadName=main;|[DEBUG] AbstractLoader org.test.s
lsb.e0Bean org.test.slsb.b6Bean org.test.slsb.b3Bean org.test.slsb.b2Bean or
g.test.slsb.b4Bean org.test.slsb.b1Bean org.test.slsb.b5Bean org.test.slsb.b0
Bean org.test.slsb.e1Bean org.test.slsb.zfailBean org.test.slsb.z0Bean org.t
est.slsb.z1Bean org.test.slsb.e2Bean |#]

Comment by Hong Zhang [ 22/Jan/08 ]

Assign to Mahesh for initial investigation. Also addding Bhakti to the Cc.

Attaching CWeng's suggested solutions below:
And so i suppose plain common-sense must be used (which would then indicate the
system should be able to tell that a Handler class is used by WebserviceX and
the Handler class need Y, so Y must be initialized by X.

Even if there is no LOAD order, one may presume that creation of ALL EJB should
be done first and then on 2nd part the creation of all Webservices that those
EJB expose is done.
At this point the EJB and Webservice step for a EJB is coupled together....

Comment by Mahesh Kannan [ 14/Feb/08 ]

The problem is that the handlers are created probably way too early.

The Container calls
WebServiceEjbEndpointRegistry.registerEjbWebServiceEndpoint() during container
initialization time which causes the handlers to be instantiated (which inturn
causes injection). We need to delay the instantiation of the handlers till the
dependent EJBs are processed.

One way to do that is to provide two methods:
1. One to register the the EjbService endpoint which WILL NOT call

2. The other method (say createConfiguredHandlers()) can create and call

Once the above methods are in place the StatelessContainer can call the second
method from doAfterApplicationDeployed().

I am assigning this to Bhakti to implement the above two methods.

Comment by Bhakti Mehta [ 15/Feb/08 ]

Looking into it

Comment by harpreet [ 09/Apr/08 ]

Based on input from Bhakti, assigning issue to next release

Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by ramapulavarthi [ 01/Dec/10 ]

I have n't run any tests but seeing the code in v3.1, we should run into the same problem.
Can't forward port the patches CR6653050 and CR6750245 as the code in v3 is little different from v2.1.
The fix needs to go into EJB container code to change the way we intialize and load the ejb web services.

Comment by Bhakti Mehta [ 08/Dec/10 ]

Reassigning to Rama since he has already looked into this issue . My inclination is to exclude this for this release but will wait for Rama's input

Comment by ramapulavarthi [ 21/Dec/10 ]

This requires changes in EJB Container to change the way EJB ws are loaded and needs coordination with EJB team. Adding V3.1 excludes as this is risky to make this change now.

Comment by Nazrul [ 23/Dec/10 ]

This bug has been around for few releases now. Based on inputs from Bill, I am setting target for 3.2 release with P2 priority so that it gets fixed. If we do not want to fix this bug, please close it.

Comment by 8086 [ 25/Mar/12 ]

We have been waiting for a fix for three years now. As of now, our application needs to be redeployed until it works. This might take anywhere from 1 redeploy to 15 redeploys to get it working.

If you are not fixing it, is there a way to work around it in our code that can remove the pain of innumerous redeploys?

Comment by kumara [ 26/Mar/12 ]

-> Martin Grebac for evaluation.

Comment by Gail Risdal [ 31/May/13 ]

Added the following to the release notes:

Resource Injection does not work in HandlerChain due to EJB initialization order (non-deterministic) (4021)

EJB module deployment may fail when an EJB that is exposed as a web service, and which has a handler, is initialized before an EJB on which it has dependencies. This is caused by the way the EJB container initializes and loads EJB web services.

EJB initialization usually happens in alphabetical order. Rename the EJBs so that the EJB exposed as a web service is initialized after the EJB on which it has dependencies.

In the following example, B is initialized first together with handler X, which expects C to be available but it is not, and deployment fails. The workaround is to rename B to D (for example), so lexicographically it follows C, in which case C should be initialized first and be available for injection to X.

EJB module sth:

@Stateless public class C

@Stateless @WebService @HandlerChain(file = "handlers.xml") public class B {...}


<?xml version="1.0" encoding="UTF-8"?>
<jws:handler-chains ...>


@EJB private C;

Comment by Gail Risdal [ 05/Jun/13 ]

Fixed the example in the release notes (first line in the "Handler" section; release notes document has proper formatting/indentation):

EJB module sth:

@Stateless public class C

@Stateless @WebService @HandlerChain(file = "handlers.xml") public class B {...}


<?xml version="1.0" encoding="UTF-8"?>
<jws:handler-chains ...>


public class X implements SOAPHandler<SOAPMessageContext>

{ @EJB private C; ...}
Generated at Mon Apr 24 05:03:12 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.