[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
AW: [eclipselink-dev] NativeAPITest
|
Hi Tom,
> There is no-longer an "oc4j-platform". Instead there are a number of
> version-specific oc4j platforms. e.g. oc4j-1111-platform
aha! Thanks for the explanation.
We tried with "oc4j-platform" as we assumed this must be working. Bad choice, obviously ;-).
Now the pieces fit together in my picture:
Nothing is mixed in dynamically but I also have to adapt the eclipselink_session_2_0.xsd! (A bit of a challenge as the NetWeaver server platform is an incubator project).
Let's give it a try ...
-Adrian
Adrian Görler
SAP AG
Pflichtangaben/Mandatory Disclosure Statements: http://www.sap.com/company/legal/impressum.epx
-----Ursprüngliche Nachricht-----
Von: eclipselink-dev-bounces@xxxxxxxxxxx [mailto:eclipselink-dev-bounces@xxxxxxxxxxx] Im Auftrag von Tom Ware
Gesendet: Freitag, 11. Dezember 2009 15:56
An: Dev mailing list for Eclipse Persistence Services
Betreff: Re: [eclipselink-dev] NativeAPITest
Just to follow up on Kevin's email.
The comment for the NativeAPI test does a good job of telling us what it does:
/**
* EJB 3 NativeAPITests tests. Testing using EclipseLink Native ORM API in a JEE
* EJB 3 SessionBean environment. These tests can only be run with a server.
*/
The reason these tests are part of the JPA testing is that they are Java EE 5
tests. At the moment, the only place we have Java EE 5 tests is part of our JPA
testing. There may be an argument to move these tests somewhere else, but there
would have to be a good reason to create an extra project just for these tests.
It looks like there may be a bug in the test related to the strings that are
allowed for server-platform in the xsd. Take a look at:
<trunk>\foundation\org.eclipse.persistence.core\resource\xsd\eclipselink_sessions_2.0.xsd
There is no-longer an "oc4j-platform". Instead there are a number of
version-specific oc4j platforms. e.g. oc4j-1111-platform
If you have added a ServerPlatformConfig and the appropriate code in:
buildServerPlatformConfigDescriptor, you should also take a look at:
1. the constructor for XMLSessionConfigProject there are some lines like:
addDescriptor(buildServerPlatformConfigDescriptorFor(Oc4jPlatformConfig.class)),
that will need a NetWeaver addition
2. the xsd file mentioned above (eclipselink_sessions_2.0.xsd)
-Tom
Kevin Yuan wrote:
> 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:
>> Hi,
>>
>> 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 XMLSession
>> ConfigProj. 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?
>>
>> Thanks,
>>
>> Adrian
>>
>>
>> *Adrian Görler
>> **SAP AG
>>
>> *Pflichtangaben/Mandatory Disclosure Statements:
>> _http://www.sap.com/company/legal/impressum.epx_
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> eclipselink-dev mailing list
>> eclipselink-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> eclipselink-dev mailing list
> eclipselink-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev