Cool and thx. On 04.07.14 11:24, "Francesco Chicchiriccò" <[email protected]> wrote:
>Hi Stephan, >you were right about the two problems below: I've opened OLINGO-340 and >OLINGO-341, then committed the fixes. > >Regards. > >On 04/07/2014 09:02, Klevenz, Stephan wrote: >> 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(Con >>>te >>> ntNegotiator.java:131) >>> at >>> >>>org.apache.olingo.server.core.ContentNegotiatorTest.testContentNegotiati >>>on >>> (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/EdmEnum >>>>Ty >>>> pe >>>> Impl.java >>>> diff --git >>>> >>>> >>>>a/lib/client-core/src/main/java/org/apache/olingo/client/core/edm/EdmEn >>>>um >>>> 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/EdmEn >>>>um >>>> Ty >>>> peImpl.java >>>> +++ >>>> >>>> >>>>b/lib/client-core/src/main/java/org/apache/olingo/client/core/edm/EdmEn >>>>um >>>> 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_SE >>>>>>>>>RV >>>>>>>>> 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/ >
