Community
Participate
Working Groups
The SDO server test failed at deployment stage on WebSphere 8 ND/AS. The test passed with WebSphere 7 ND/AS. Error Mesage: ============= websphere-deploy: [echo] *****Deploy deptApp on WebSphere Server***** [copy] Copying 1 file to /scratch/aime/eclipselink/org.eclipse.persistence/was8as/bin [exec] WASX7209I: Connected to process "server1" on node ottvm003Node01 using SOAP connector; The type of process is: UnManagedProcess [exec] deptApp was not previously installed [exec] ADMA5016I: Installation of deptApp started. [exec] ADMA5058I: Application and module versions are validated with versions of deployment targets. [exec] ADMA5005I: The application deptApp is configured in the WebSphere Application Server repository. [exec] ADMA5005I: The application deptApp is configured in the WebSphere Application Server repository. [exec] ADMA5081I: The bootstrap address for client module is configured in the WebSphere Application Server repository. [exec] ADMA5053I: The library references for the installed optional package are created. [exec] ADMA5005I: The application deptApp is configured in the WebSphere Application Server repository. [exec] ADMA5001I: The application binaries are saved in /scratch/aime/eclipselink/org.eclipse.persistence/was8as/profiles/AppSrv01/wstemp/Script1333f49d6c3/workspace/cells/ottvm003Node01Cell/applications/deptApp.ear/deptApp.ear [exec] ADMA5005I: The application deptApp is configured in the WebSphere Application Server repository. [exec] SECJ0400I: Successfully updated the application deptApp with the appContextIDForSecurity information. [exec] ADMA5005I: The application deptApp is configured in the WebSphere Application Server repository. [exec] ADMA5005I: The application deptApp is configured in the WebSphere Application Server repository. [exec] ADMA5113I: Activation plan created successfully. [exec] ADMA5011I: The cleanup of the temp directory for application deptApp is complete. [exec] ADMA5013I: Application deptApp installed successfully. [exec] deptApp(cells/ottvm003Node01Cell/applications/deptApp.ear/deployments/deptApp|deployment.xml#Deployment_1319616768377) [exec] (cells/ottvm003Node01Cell/applications/deptApp.ear/deployments/deptApp|deployment.xml#ApplicationDeployment_1319616768377) [exec] (cells/ottvm003Node01Cell/applications/deptApp.ear/deployments/deptApp|deployment.xml#Classloader_1319616768377) [exec] (cells/ottvm003Node01Cell/applications/deptApp.ear/deployments/deptApp|deployment.xml#LibraryRef_1319616771561) [exec] start the application now [junit] Running org.eclipse.persistence.testing.sdo.server.DeptServiceClientTestSuite [junit] Oct 26, 2011 4:12:52 AM null null [junit] SEVERE: security.JSAS1480I [junit] Oct 26, 2011 4:12:52 AM null null [junit] INFO: Client code attempting to load security configuration [junit] >> SERVER (id=4773e3aa, host=ottvm003.ca.oracle.com) TRACE START: [junit] >> javax.ejb.EJBException: See nested exception; nested exception is: java.lang.ClassCastException: com.ibm.xml.sdo.model.DataObjectElement incompatible with org.eclipse.persistence.testing.sdo.server.Dept [junit] >> SERVER (id=4773e3aa, host=ottvm003.ca.oracle.com) TRACE END. [junit] ; nested exception is: java.lang.ClassCastException: com.ibm.xml.sdo.model.DataObjectElement incompatible with org.eclipse.persistence.testing.sdo.server.Dept) [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 2.15 sec [echo] sdotest.build.location = '/net/ottvm003/scratch/aime/eclipselink/org.eclipse.persistence/trunk/sdo/eclipselink.sdo.test.server' [echo] sdotest.2.base.dir = '../..'
The test failed at "dept = (Dept) DataFactory.INSTANCE.create(Dept.class);" with following error message: Cannot create a data object because the type for class 'org.eclipse.persistence.testing.sdo.server.Dept' cannot be found.
WebSphere V8.0 ships with a more complete version of SDO (for their EMF plugin) than previous versions (of WAS) which results in IBM's SDO implementation being used by the service, not EclipseLink. This needs to be resolved. We tried changing the test case such that it specifically calls into the EclipseLink API, which seems to get us further, i.e. we can successfully cache and look up types based on the application name, create an object based on a type, and send back to the client. However, we cannot send that object back to the service. We get the following exception: CORBA MARSHAL 0x4942f896 No; nested exception is: org.omg.CORBA.MARSHAL: SERVER (id=4773e3aa, host=yipzhao-pc.st-mdc.ca.oracle.com) TRACE START: org.omg.CORBA.MARSHAL: Unable to read value from underlying bridge : null vmcid: IBM minor code: 896 completed: No at com.ibm.rmi.iiop.CDRReader.read_value(CDRReader.java:1637) at com.ibm.rmi.iiop.CDRReader.read_abstract_interface(CDRReader.java:1591) at com.ibm.rmi.iiop.CDRReader.read_abstract_interface(CDRReader.java:1583) ... This is most likely due to the fact that IBM's implementation is trying to deserialize the data object and cannot since our implementation created it.
The server-side deserialize issue was solved by using the EclipseLink SDOResolvable class' readExternal method as opposed to the one in commonj.sdo.impl.ExternalizableDelegator.
(In reply to comment #3) > The server-side deserialize issue was solved by using the EclipseLink > SDOResolvable class' readExternal method as opposed to the one in > commonj.sdo.impl.ExternalizableDelegator. Note: this change causes 6 failures and 1 error in SDOResolvableTestSuite, and 3 errors in SDOHelperContextTestSuite.
Created attachment 206475 [details] Partial fix. This patch gets the WAS V8.0 server test passing, but causes failures in the SDO unit tests.
Created attachment 206547 [details] Patch
Fixed and checked in to trunk (2.4), reviewed by bdoughan.
Rick, can we backport the fix to 2.3 stream?
Will backport this to 2.3.
Backported to 2.3.3.
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
