Issue Details (XML | Word | Printable)

Key: GLASSFISH-7066
Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Sanjeeb Sahoo
Reporter: al130959
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
glassfish

EJB3 bean silently not published if it inherits the Remote interface from a POJO

Created: 19/Jan/09 01:01 PM   Updated: 06/Mar/12 09:57 PM
Component/s: verifier
Affects Version/s: 9.1peur2
Fix Version/s: not determined

Time Tracking:
Not Specified

File Attachments: 1. GZip Archive BeanClassHierarchyTest.tar.gz (626 kB) 19/Jan/09 01:04 PM - al130959

Environment:

Operating System: All
Platform: All


Issuezilla Id: 7,066
Tags:
Participants: al130959, Alexis MP, ksak, Sanjeeb Sahoo and Tom Mueller


 Description  « Hide

Consider the following scenario:

@Remote
public interface TheRealRemote {

String sayHello(String name);

}

public class SomeOrdinaryClassImplementingTheRealRemote implements TheRealRemote {

public String sayHello(String name) { return "Hello, " + name + "!"; }

}

@Stateless
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:

@Stateless
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!



al130959 added a comment - 19/Jan/09 01:04 PM

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


Alexis MP added a comment - 20/Jan/09 01:50 AM

adding myself to CC list


ksak added a comment - 20/Jan/09 05:56 AM

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 4.9.2.1 – Session Bean Superclasses. At best there could be some verifier warning,
though Changing category to verifier.


al130959 added a comment - 20/Jan/09 06:22 AM

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!

Andreas


Sanjeeb Sahoo added a comment - 17/Sep/09 01:44 AM

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


Tom Mueller added a comment - 06/Mar/12 09:57 PM

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