[GLASSFISH-7066] EJB3 bean silently not published if it inherits the Remote interface from a POJO Created: 19/Jan/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: verifier
Affects Version/s: 9.1peur2
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: al130959 Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: All
Platform: All

Attachments: GZip Archive BeanClassHierarchyTest.tar.gz    
Issuezilla Id: 7,066


Consider the following scenario:

public interface TheRealRemote {

String sayHello(String name);


public class SomeOrdinaryClassImplementingTheRealRemote implements TheRealRemote {

public String sayHello(String name)

{ return "Hello, " + name + "!"; }


public class TheRealBean extends SomeOrdinaryClassImplementingTheRealRemote {


Using plain Glassfish v2 UR2 b04, the Verifier returns 0 failures, 0 warnings
and 0 errors for the EJB-JAR/EAR containing these classes. Deployment of the EAR
also seems to complete fine without any error messages.

However, the SLSB will not be properly deployed and its Remote interface not be
published into JNDI. Any attempts to call this bean will therefore fail.

But when we change TheRealBean to explicitly, but redundantly state that it
implements TheRealRemote:

public class TheRealBean extends SomeOrdinaryClassImplementingTheRealRemote
implements TheRealRemote {


the SLSB deploys fine, its remote interface will be bound to JNDI and the bean
can successfully be called.

The error seems to be that some statical analysis on TheRealBean class fails to
detect that this class implements TheRealRemote indirectly, because it extends
another POJO class that implements it.

This issue has been found in a real-world customer application and was very hard
to debug due to the complete lack of any error messages other than the inability
to look up any Remote interfaces.

The attached NetBeans project contains the full source for a test case EAR.
Running the verifier on the EAR returns no errors, but TheRealRemote will not be
bound into JNDI after deployment. Then add the redundant "implements
TheRealRemote", and everything is fine.

Many thanks in advance for fixing this!

Comment by al130959 [ 19/Jan/09 ]

Created an attachment (id=2226)
Test case containing the scenario for issue #7066

Comment by Alexis MP [ 20/Jan/09 ]

adding myself to CC list

Comment by ksak [ 20/Jan/09 ]

Client views are not inherited through processing of super-classes. They can only be defined directly on
the bean class or through the deployment descriptor. This is an area that has been clarified in the 3.1
spec. See section – Session Bean Superclasses. At best there could be some verifier warning,
though Changing category to verifier.

Comment by al130959 [ 20/Jan/09 ]

Still my question would be:

The EJB 3.0 spec did not make any statements regarding the need to explicitly
include superclass-implemented interfaces in its own interface list. If
implementing parent class interfaces this shall be explicitly handled and
required by the EJB 3.1 spec - then fine from the EJB container point of view.

But in this case I would at least require a mandatory message rejecting a
bean class that has been set up like in my example - it's definitely not a
nice-to have thing to have "at best"....

So please change the Verifier to reject my bean and point to this section for
the reason why - although it will be "interesting" to refuse deployment of an
EJB 3.0 SLSB due to restrictions only being raised for the first time in the EJB
3.1 spec...

Many thanks!


Comment by Sanjeeb Sahoo [ 17/Sep/09 ]

As per conventions in verifier project, new assertions are classified as
enhancements. So, marking this issue as an enhancement.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

Generated at Mon Apr 24 09:17:54 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.