Bug 1188420 - [GSS](6.4.z) EJB Asynchronous pass POJO by reference leading to ClassCastException errors in remote invocations
Summary: [GSS](6.4.z) EJB Asynchronous pass POJO by reference leading to ClassCastExce...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: EJB
Version: 6.2.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: CR2
: EAP 6.4.1
Assignee: Brad Maxwell
QA Contact: hsvabek
URL:
Whiteboard:
Depends On:
Blocks: 1191758 eap641-payload
TreeView+ depends on / blocked
 
Reported: 2015-02-02 20:29 UTC by William Antônio
Modified: 2019-04-16 14:34 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Known Issue
Doc Text:
In this release of JBoss EAP 6, an Asynchronous EJB call via the EJB's Remote Interface from a client to an EJB running in the same JVM fails with a ClassCastException. This is because the request/response are not being marshalled as they should and the client and EJB are not using the same classloader. This is expected to be resolved in a future release and the request/response will be marshalled as it should since it is a Remote interface call, allowing the client and EJB to use different classloaders and not fail with a ClassCastException.
Clone Of:
: 1191758 (view as bug list)
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker WFLY-4331 0 Major Resolved EJB Asynchronous pass POJO by reference leading to ClassCastException errors in remote invocations 2017-11-08 20:21:49 UTC

Description William Antônio 2015-02-02 20:29:48 UTC
Description of problem:

When invoking EJB asynchronous in different deployments and returning a POJO object, which will be retrieved using future.get, we have ClassCastException error.

Version-Release number of selected component (if applicable):
6.2

How reproducible:
Always.

Steps to Reproduce:
1. Deploy an EJB in an EAR that uses Asynchronous methods;
2. Deploy a Servlet in a WAR which will use this EJB;
3. Inject the EJB in a servlet and try to invoke it, then try to retrieve the result. Here's an example:

        @EJB(lookup="java:global/testejb/testejb-ejb/AsyncService!rh.test.AsyncEJB")
        private AsyncEJB asyncEJB;
    
        @Override
        protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
                Future<ReturnObject> futro = asyncEJB.testAsync();
                ReturnObject ro; 
                try {
                        // this line below should throw the CCE
                        ro = futro.get();
                }   
                catch (InterruptedException e) {
                        printResponse(resp, e.getMessage());
                        return;
                }   
                catch (ExecutionException e) {
                        printResponse(resp, e.getMessage());
                        return;
                }
                printResponse(resp, String.format("Servlet response: %s", ro.getMessage()));
        }


Actual results:
Error:

 JBWEB000236: Servlet.service() for servlet rh.test.AsyncServlet threw exception: java.lang.ClassCastException: rh.test.ReturnObject cannot be cast to rh.test.ReturnObject

Expected results:
Invocation without error

Additional info:

It will work if we create a custom module with the model objects and make both deployments dependents of this module.
The configuration to force EAP to always use pass by value will not help in this issue.

Comment 7 JBoss JIRA Server 2015-03-03 03:45:55 UTC
Brad Maxwell <bmaxwell> updated the status of jira WFLY-4331 to Reopened

Comment 9 JBoss JIRA Server 2015-03-09 05:15:46 UTC
Brad Maxwell <bmaxwell> updated the status of jira WFLY-4331 to Resolved

Comment 15 Rostislav Svoboda 2015-04-23 11:10:37 UTC
Re-acking after "qa_ack flag reset for and jboss-eap-6.4.0 and jboss-eap-6.4.z items" cleanup.

Comment 17 hsvabek 2015-05-18 12:04:32 UTC
verified

Comment 18 Petr Penicka 2017-01-17 10:00:21 UTC
Retroactively bulk-closing issues from released EAP 6.4 cummulative patches.

Comment 19 Petr Penicka 2017-01-17 10:00:49 UTC
Retroactively bulk-closing issues from released EAP 6.4 cummulative patches.


Note You need to log in before you can comment on or make changes to this bug.