Description

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.

So the Local Business interface is LocalTimeProvider.

The following injection is performed on a SessionScoped Bean
@Inject
private LocalTimeProvider timeProvider1;

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. Is Weld incorrect in mapping the method to its declaring interface. Weld must instead use the injected type as the business interface, while trying to get the business object.

Activity

I discussed this with Ales and we decided that this was to big a change for a point release.

For now it can be worked around by having SessionObjectReference guess at the
correct business interface to use, based on the interface type that is passed in,
for the majority of situations this should not cause any problems.

Stuart Douglas
added a comment - 21/Jun/11 6:50 PM - edited I discussed this with Ales and we decided that this was to big a change for a point release.
For now it can be worked around by having SessionObjectReference guess at the
correct business interface to use, based on the interface type that is passed in,
for the majority of situations this should not cause any problems.

stuartdouglas: A fix that will cover 99% of cases and remove the need for the work around is to create multiple client proxies per EJB, one per business interface
stuartdouglas: And embed the business interface in a field in the proxy
stuartdouglas: So the proxy just 'knows' the correct business interface

Jozef Hartinger
added a comment - 26/Mar/13 4:23 AM - edited stuartdouglas: A fix that will cover 99% of cases and remove the need for the work around is to create multiple client proxies per EJB, one per business interface
stuartdouglas: And embed the business interface in a field in the proxy
stuartdouglas: So the proxy just 'knows' the correct business interface

We are using GlassFish 3.1.2.x with WELD-1.1.x and are hit by this bug.
Would it be possible to backport this fix into the 1.1 branch?

More specifically I would like to request a cherry-pick of the following commits into the 1.1. branch:
5b31406 - WELD-921 Incorrect handling of business interfaces for EJBs (2013-03-26) <Jozef Hartinger>
b99a570 - Testcase for WELD-921 (2013-03-26) <Jozef Hartinger>

Oliver Wahlen
added a comment - 11/Mar/15 9:26 AM We are using GlassFish 3.1.2.x with WELD-1 .1.x and are hit by this bug.
Would it be possible to backport this fix into the 1.1 branch?
More specifically I would like to request a cherry-pick of the following commits into the 1.1. branch:
5b31406 - WELD-921 Incorrect handling of business interfaces for EJBs (2013-03-26) <Jozef Hartinger>
b99a570 - Testcase for WELD-921 (2013-03-26) <Jozef Hartinger>