Skip to main content

[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


Back to the top