Right. I have fixed it. Please pull again. Stephan
On 04.07.14 08:56, "Francesco Chicchiriccò" <[email protected]> wrote: >Hi, >when trying to build the olingo337 branch I run into a failed test: > >testServiceDocument(org.apache.olingo.server.core.ContentNegotiatorTest) >Time elapsed: 0.022 sec <<< ERROR! >java.lang.RuntimeException: unsupported accept content type: >[application/json;q=0.2;q=0.2] != [('json', 'application/json'), >('json', 'application/json;odata.metadata=minimal')] > at >org.apache.olingo.server.core.ContentNegotiator.doContentNegotiation(Conte >ntNegotiator.java:131) > at >org.apache.olingo.server.core.ContentNegotiatorTest.testContentNegotiation >(ContentNegotiatorTest.java:165) > at >org.apache.olingo.server.core.ContentNegotiatorTest.testServiceDocument(Co >ntentNegotiatorTest.java:115) > >If I build with 'mvn clea install -DskipTests' (to skip test execution), >I ran into the same error I have on the master branch: > >[ERROR] Failed to execute goal on project olingo-server-test: Could not >resolve dependencies for project >org.apache.olingo:olingo-server-test:jar:0.1.0-SNAPSHOT: Could not find >artifact org.apache.olingo:olingo-server-tecsvc:jar:0.1.0-SNAPSHOT in >apache.snapshots (http://repository.apache.org/snapshots) -> [Help 1] > >Regards. > >On 04/07/2014 08:36, Klevenz, Stephan wrote: >> I am having another issue here: >> >> commit 62eccf9c19fef21d436309bea70c8aef0a6df1cb >> Author: Stephan Klevenz <[email protected]> >> Date: Thu Jul 3 12:54:07 2014 +0200 >> >> [OLINGO-337] improve AcceptType class to allow '*' >> WDFM00341572A:olingo-odata4 d036242$ git diff >> >>lib/client-core/src/main/java/org/apache/olingo/client/core/edm/EdmEnumTy >>pe >> Impl.java >> diff --git >> >>a/lib/client-core/src/main/java/org/apache/olingo/client/core/edm/EdmEnum >>Ty >> peImpl.java b/lib/client-core/src/main/java/org/apache/ol >> index 4a76953..ffcf768 100644 >> --- >> >>a/lib/client-core/src/main/java/org/apache/olingo/client/core/edm/EdmEnum >>Ty >> peImpl.java >> +++ >> >>b/lib/client-core/src/main/java/org/apache/olingo/client/core/edm/EdmEnum >>Ty >> peImpl.java >> @@ -64,9 +64,9 @@ public class EdmEnumTypeImpl extends >>AbstractEdmEnumType >> implements EdmEnumType >> } else { >> this.underlyingType = EdmPrimitiveTypeFactory.getInstance( >> EdmPrimitiveTypeKind.valueOfFQN(version, >> xmlEnumType.getUnderlyingType())); >> - if (!ArrayUtils.contains(VALID_UNDERLYING_TYPES, >> this.underlyingType.getKind())) { >> - throw new EdmException("Not allowed as underlying type: " + >> this.underlyingType.getKind()); >> - } >> +// if (!ArrayUtils.contains(VALID_UNDERLYING_TYPES, >> this.underlyingType.getKind())) { >> +// throw new EdmException("Not allowed as underlying type: " + >> this.underlyingType.getKind()); >> +// } >> } >> >> I did comment out the underlying type check because of it fails even if >> underlying type is allowed. That can be reproduced also with the >> BasicITCase test class (readMetadata). The feature branch is olingo337 >>and >> because of the un-comment test is working. >> >> >> Stephan >> >> >> >> >> On 03.07.14 17:04, "Klevenz, Stephan" <[email protected]> wrote: >> >>> Server responds fine and also underlying http request objects are >>>looking >>> fine. >>> >>> You can easily reproduce by the following: >>> >>> 1) mvn cargo:run (call this from the fit module directory to start >>>server) >>> 2) run the BasicITCase test and analyze response object >>> >>> BasicITCase implements 2 test methods. Reading the service document is >>>ok >>> and response looks healthy. The other method reads metadata document >>>and >>> here the response object isn't initialized correctly. >>> >>> After start of cargo server the service has the following base uri: >>> http://localhost:9080/olingo-server-tecsvc/odata.svc >>> >>> Please note that metadata document contains a reference to another >>> metadata document which results in multiple requests on client side. >>> >>> -- Stephan >>> >>> >>> >>> On 03.07.14 16:01, "Francesco Chicchiriccò" <[email protected]> >>>wrote: >>> >>>> On 03/07/2014 15:56, Klevenz, Stephan wrote: >>>>> I'am having another issue with this unit test (BasicITCase class): >>>>> >>>>> @Test >>>>> public void readMetadata() { >>>>> EdmMetadataRequest request = >>>>> odata.getRetrieveRequestFactory().getMetadataRequest(REF_SERVICE); >>>>> assertNotNull(request); >>>>> ODataRetrieveResponse<Edm> response = request.execute(); >>>>> >>>>> assertEquals(200, response.getStatusCode()); >>>>> ... >>>>> } >>>>> >>>>> The response object returns -1 for status code and it seems that the >>>>> object is just not correctly created. On the wire all data is fine. >>>>> Should >>>>> I open an issue? >>>> Could you please compare with the full response (including headers) >>>> returned by the static server? >>>> It's plenty of tests reading metadata documents - even the POJO >>>> generator does this, so it's hard to figure what kind of problem it >>>> might be, especially because the status code is just the one returned >>>>by >>>> the underlying HttpClient. >>>> >>>> Regards. >>>> >>>>> On 03.07.14 12:57, "Francesco Chicchiriccò" <[email protected]> >>>>> wrote: >>>>> >>>>>> On 03/07/2014 12:51, Klevenz, Stephan wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I have create an integration test to read the service document and >>>>>>> recognized that client sends an default accept header which is >>>>>>> "application/json;odata.metadata=full". The server currently >>>>>>>supports >>>>>>> only minimal and doesn't accept the request. >>>>>>> >>>>>>> >>>>>>> >>>>>>> @Test >>>>>>> >>>>>>> public void readServiceDocument() { >>>>>>> >>>>>>> ODataServiceDocumentRequest request = >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>odata.getRetrieveRequestFactory().getServiceDocumentRequest(REF_SERV >>>>>>>IC >>>>>>> E >>>>>>> ); >>>>>>> >>>>>>> assertNotNull(request); >>>>>>> >>>>>>> ODataServiceDocument serviceDocument = >>>>>>> request.execute().getBody(); >>>>>>> >>>>>>> assertNotNull(serviceDocument); >>>>>>> >>>>>>> } >>>>>>> >>>>>>> >>>>>>> Is it by purpose to add an accept header if client code doesn't >>>>>>>set a >>>>>>> header explicitly? If this is the case then I must overwrite the >>>>>>> header >>>>>>> by this >>>>>>> >>>>>>> >>>>>>> >>>>>>>request.setAccept("application/json;odata.metadata=minimal"); >>>>>>> >>>>>>> to get the request accepted. >>>>>> The client code will generate the header values from its >>>>>> configuration: >>>>>> doing >>>>>> >>>>>> request.setFormat(ODataFormat.JSON) >>>>>> >>>>>> should do the trick for this single request. >>>>>> >>>>>> Alternatively you can configure the default format via >>>>>> >>>>>> odata.getConfiguration().setDefaultPubFormat(ODataFormat.JSON) >>>>>> >>>>>> HTH >>>>>> Regards. > >-- >Francesco Chicchiriccò > >Tirasa - Open Source Excellence >http://www.tirasa.net/ > >Involved at The Apache Software Foundation: >member, Syncope PMC chair, Cocoon PMC, Olingo PMC >http://people.apache.org/~ilgrosso/ >
