[GLASSFISH-16186] Unable to convert ejbRef for ejb to a business object, the container picks the wrong interface Created: 09/Mar/11  Updated: 02/Apr/13  Resolved: 02/Apr/13

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: fabmars Assignee: jjsnyder83
Resolution: Fixed Votes: 11
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Windows 7 x86, JDK 1.6.0_24, Glassfish 3.1 GA, JSF2.

Attachments: Text File GLASSFISH-16186.log     Zip Archive sources.zip     File truc-dev-autodeploy.ear    
Tags: 3_1_1-next, 3_1_1-scrubbed, 3_1_2-exclude, weld-int-required


I've been converting a quite big site from EE5 to EE6, with CDI of course.
There's ONE sole thing that bugs me but it's quite peculiar.

I have:

  • @Named @Stateless TimeProviderImpl extends SimpleTimeProvider implements LocalTimeProvider.
  • SimpleTimeProvider implements TimeProvider (the latter defining some methods, the former implementing them. No annotations.)
  • LocalTimeProvider is @Local and also extends TimeProvider and does nothing more.

If I read the EJB 3.1 spec ยง4.9.7, I believe I'm still compliant.

Now, if I try to access this EJB from my web application with EL or through a ManagedBean where it's @Inject injected, I get the exception below.
If I try to access it through the ManagedBean where it's @EJB injected, my page displays correctly (as it used to work in EE5).

Example and logs are attached. Deploy EAR and call http://localhost:8080/TrucWeb/test.jsf

We're somewhere around these but it's slightly different.

If i had to take a wild guess I'd say the issue lies in the Glassfish/Weld integration.

Comment by Sivakumar Thyagarajan [ 13/Jun/11 ]

Transferring to the EJB container team for further evaluation and confirm if this scenario is valid. During investigation, it appears that in EJBContainerServicesImpl.getBusinessObject() for this EJBRef, the business interface com.dummy.time.TimeProvider doesn't seem to belong to the list of local business interfaces for that EJB.

Comment by marina vatkina [ 13/Jun/11 ]

For an interface to be an EJB business interface, it needs to be explicitly denoted as such on the class that is marked as @Stateless. Interfaces implemented by the superclasses, are not component interfaces.

Comment by fabmars [ 15/Jun/11 ]

Excuse me but the point never was to have com.dummy.time.TimeProvider as a business interface. Based on this assumtion, Marina's reasoning definitely makes sense.

But this is NOT the point of the issue, neither this of the attached example.

The point is that something here works with the EJB container and NOT with the CDI container. Please consider reopening this issue and reassigning.

Comment by marina vatkina [ 15/Jun/11 ]

reopening as it seems like a CDI error

Comment by marina vatkina [ 15/Jun/11 ]


See in the description:

*Now, if I try to access this EJB from my web application with EL or through a ManagedBean where it's @Inject injected, I get the exception below.
If I try to access it through the ManagedBean where it's @EJB injected, my page displays correctly*

Comment by Sivakumar Thyagarajan [ 15/Jun/11 ]

Marina: Yes, this appears to work in the @EJB case and not in the @Inject case, as for handling the @Inject case, the weld integration code goes through the EJBContainerServices API to resolve an EJB reference, and the EJBContainerServicesImpl doesn't seem to provide com.dummy.time.TimeProvider as a business interface for that ejb-ref.

Assigning to Cheng who handles EJB and requesting him to investigate further.

Comment by marina vatkina [ 15/Jun/11 ]


EJB container is correct - com.dummy.time.TimeProvider is not a business interface. Weld integration shouldn't ask for it.

Back to cdi.

Comment by Sivakumar Thyagarajan [ 19/Jun/11 ]

Here is the scenario. An injection of
private LocalTimeProvider timeProvider1;
is performed in a SessionScoped Bean.

The Weld bean proxy for the SessionBean Object reference being injected(timeProvider1) tries to get [1] the BusinessObject when a method is invoked on it. Weld seems to use [2] the declaring class of the method being invoked to determine the business interface. Though the business interface of the Bean is set to com.dummy.time.LocalTimeProvider, the class that declares the method being invoked ("getThisMonth()") is com.dummy.time.TimeProvider.

Therefore, the Weld implementation calls SessionObjectReferenceImpl.getBusinessObject("com.dummy.time.TimeProvider"), which fails, as TimeProvider is not a Business interface. As per [3], the businessInterfaceType must be a type of the business interface of the bean. Weld appears to be incorrect in asking through the SPI for a Business Object for a non-Business interface. Filed a Weld issue https://issues.jboss.org/browse/WELD-921 to get this fixed.

[1] https://github.com/weld/core/blob/76c31d311cf1ff449eb2d5c80943b913651bed96/impl/src/main/java/org/jboss/weld/bean/proxy/EnterpriseBeanProxyMethodHandler.java#L123
[3] https://github.com/weld/api/blob/master/weld-spi/src/main/java/org/jboss/weld/ejb/api/SessionObjectReference.java#L31

Comment by Sivakumar Thyagarajan [ 14/Nov/11 ]

The Weld 1.1.3 release that is being integrated into 3.1.2 does not have a fix for WELD-921, and so marking this as 3_1_2-exclude

Comment by scatari [ 06/Dec/11 ]

https://issues.jboss.org/browse/WELD-921 seems to be fixed in 1.2.0 Beta1. We recently integrated 1.1.4 to GF 3.1.2. Can we selectively port fixes from 1.2.0 to 1.1.4?

Comment by Sivakumar Thyagarajan [ 11/Dec/11 ]

@scatari: Selectively including fixes from another branch, would require GlassFish to create a modified release of Weld, and so we are not doing that. The fix for WELD-921 has only been targetted for 1.2.0.Beta1 IIRC.

Marking this issue as "3_1_2_exclude", as a fix doesn't seem to be available in the 3.1.2 timeframe.

Comment by Sivakumar Thyagarajan [ 10/Dec/12 ]

Transferring to JJ Snyder

Comment by tlcksnyder [ 28/Mar/13 ]

Weld bug https://issues.jboss.org/browse/WELD-921 is targeted for Weld 2.0.0.CR1. Retest with CR1.

Comment by jjsnyder83 [ 02/Apr/13 ]

Committed revision 61099.

Generated at Fri May 29 01:39:14 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.