Hi Kevin,
I would be willing to add a “server platform config” for NetWeaver.
I have tried. But, my stopper is the XML parsing issue below. Seems that
dynamically adding the “server platform config”
name in XMLSessionConfigProj does not work.
Maybe its an issue with the SAX-Parser? Don’t
know.
Regards,
Adrian
Von: eclipselink-dev-bounces@xxxxxxxxxxx
[mailto:eclipselink-dev-bounces@xxxxxxxxxxx] Im Auftrag von Kevin Yuan
Gesendet: Freitag, 11. Dezember 2009 15:26
An: Dev mailing list for Eclipse Persistence Services
Betreff: Re: [eclipselink-dev] NativeAPITest
Hi Adrian,
That's true that this test suite is for "native" API, and the reason
adding jap testing is because we try to share the same build scripts for server
testing, As to "server.platform"
currently not support NetWeaver, I think you can log a bug, otherwise, you can
comment out this test suite in "server-test-lrg" within
jpa\eclipselink..jpa.test\build.xml temp.
Thanks,
Kevin
Goerler, Adrian wrote:
we
are having trouble to run the NativeAPITest on NetWeaver. We are getting the
following exception:
org.xml.sax.SAXParseException:
cvc-elt.4.2: Cannot resolve 'oc4j-platform' to a type definition for element
'server-platform'.
at
org.eclipse.persistence.exceptions.SessionLoaderException.finalException(SessionLoaderException.java:103)
at
org.eclipse.persistence.sessions.factories.XMLSessionConfigLoader.load(XMLSessionConfigLoader.java:246)
at
org.eclipse.persistence.sessions.factories.SessionManager.getSession(SessionManager.java:395)
at org.eclipse.persistence.sessions.factories.SessionManager.getSession(SessionManager.java:288)
at
org.eclipse.persistence.testing.tests.nativeapitest.NativeAPITests.testSetup(NativeAPITests.java:72)
at
org.eclipse.persistence.testing.framework.junit.JUnitTestCase.runBareServer(JUnitTestCase.java:463)
at
org.eclipse.persistence.testing.framework.server.TestRunnerBean.runTest(TestRunnerBean.java:87)
at
com.sap.engine.services.ejb3.runtime.impl.RequestInvocationContext.proceedFinal(RequestInvocationContext.java:47)
at com.sap.engine.services.ejb3.runtime.impl.AbstractInvocationContext.proceed(AbstractInvocationContext.java:166)
at
com.sap.engine.services.ejb3.runtime.impl.Interceptors_StatesTransition.invoke(Interceptors_StatesTransition.java:19)
at com.sap.engine.services.ejb3.runtime.impl.AbstractInvocationContext.proceed(AbstractInvocationContext.java:177)
at
com.sap.engine.services.ejb3.runtime.impl.Interceptors_Resource.invoke(Interceptors_Resource.java:47)
at
com.sap.engine.services.ejb3.runtime.impl.AbstractInvocationContext.proceed(AbstractInvocationContext.java:177)
at
com.sap.engine.services.ejb3.runtime.impl.Interceptors_Transaction.doWorkWithAttribute(Interceptors_Transaction.java:37)
at
com.sap.engine.services.ejb3.runtime.impl.Interceptors_Transaction.invoke(Interceptors_Transaction.java:21)
at
com.sap.engine.services.ejb3.runtime.impl.AbstractInvocationContext.proceed(AbstractInvocationContext.java:177)
at
com.sap.engine.services.ejb3.runtime.impl.Interceptors_MethodRetry.invoke(Interceptors_MethodRetry.java:46)
at com.sap.engine.services.ejb3.runtime.impl.AbstractInvocationContext.proceed(AbstractInvocationContext.java:177)
at
com.sap.engine.services.ejb3.runtime.impl.AbstractInvocationContext.proceed(AbstractInvocationContext.java:189)
at com.sap.engine.services.ejb3.runtime.impl.Interceptors_StatelessInstanceGetter.invoke(Interceptors_StatelessInstanceGetter.java:16)
at
com.sap.engine.services.ejb3.runtime.impl.AbstractInvocationContext.proceed(AbstractInvocationContext.java:177)
at com.sap.engine.services.ejb3.runtime.impl.Interceptors_SecurityCheck.invoke(Interceptors_SecurityCheck.java:25)
at
com.sap.engine.services.ejb3.runtime.impl.AbstractInvocationContext.proceed(AbstractInvocationContext.java:177)
at com.sap.engine.services.ejb3.runtime.impl.Interceptors_ExceptionTracer.invoke(Interceptors_ExceptionTracer.java:17)
at
com.sap.engine.services.ejb3.runtime.impl.AbstractInvocationContext.proceed(AbstractInvocationContext.java:177)
at
com.sap.engine.services.ejb3.runtime.impl.DefaultInvocationChainsManager.startChain(DefaultInvocationChainsManager.java:138)
at
com.sap.engine.services.ejb3.runtime.impl.DefaultEJBProxyInvocationHandler.invoke(DefaultEJBProxyInvocationHandler.java:164)
at
com.sap.engine.services.ejb3.runtime.impl.RemoteEJBProxyInvocationHandler.invoke(RemoteEJBProxyInvocationHandler.java:98)
at
com.sap.engine.services.ejb3.runtime.impl.RemoteEJBProxyInvocationHandlerp4_Skel.dispatch(RemoteEJBProxyInvocationHandlerp4_Skel.java:120)
at
com.sap.engine.services.rmi_p4.DispatchImpl._runInternal(DispatchImpl.java:456)
at
com.sap.engine.services.rmi_p4.server.ServerDispatchImpl.run(ServerDispatchImpl.java:69)
at com.sap.engine.services.rmi_p4.P4Message.process(P4Message.java:72)
at com.sap.engine.services.rmi_p4.P4Message.execute(P4Message.java:43)
at com.sap.engine.services.cross.fca.FCAConnectorImpl.executeRequest(FCAConnectorImpl.java:983)
at com.sap.engine.services.rmi_p4.P4Message.process(P4Message.java:59)
at com.sap.engine.services.cross.fca.MessageReader.run(MessageReader.java:55)
at com.sap.engine.core.thread.execution.Executable.run(Executable.java:115)
at com.sap.engine.core.thread.execution.Executable.run(Executable.java:96)
at
com.sap.engine.core.thread.execution.CentralExecutor$SingleThread.run(CentralExecutor.java:315)
Frankly
speaking, I understood very little what’s going on here and I’ve
got many questions:
1)
The tests seems to test the legacy “native” API. Why is it under
jpa/eclipselink.jpa.test then?
2)
It appears that we should provide some subclass of ServerPlatformConfig for
NetWeaver. This ServerPlatformConfig class should be associated with a symbolic
name, which seems to be dynamically bound into some XML-schema (or at least
something XML-ish) in XMLSession ConfigProj. buildServerPlatformConfigDescriptor.
3)
It seems that we have to provide configure some value for server.platform in
our netweaver.properties file. (The current value is
“oc4j-platform”, as you see in the stack trace, which is wrong,
obviously) .
4)
We had tried to provide this ServerPlatformConfig class as described above but
failed with the same stack trace as above (Cannot resolve 'netweaver-platform'). Then we tried to
use the “oc4j-platform” instead but failed as well.
To
me it seems that this technique of dynamically mixing in the symbolic names for
the server platform configs in XMLSessionConfigProj.
buildServerPlatformConfigDescriptor fails in NetWeaver and hence the
parsing of the session.fails.
We
are pretty much stuck here. Any idea how to get this flying?
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
