You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@olingo.apache.org by "Klevenz, Stephan" <st...@sap.com> on 2014/07/03 12:51:53 UTC
[DISCUSS] client / default accept header
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_SERVICE);
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.
Regards,
Stephan
Re: [DISCUSS] client / default accept header
Posted by Francesco Chicchiriccò <il...@apache.org>.
Hi,
I am trying to build the master branch but I have the following problem:
'mvn clean install' from root directory stops at olingo-server-test with
the following message
[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]
It seems that lib/server-tecsvc/pom.xml declares
<dependency>
<groupId>org.apache.olingo</groupId>
<artifactId>olingo-server-tecsvc</artifactId>
<version>${project.version}</version>
<scope>test</scope>
</dependency>
but, being olingo-server-tecsvc a WAR artifact it just cannot work.
Could you check this, please?
On 03/07/2014 17:04, Klevenz, Stephan 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ò" <il...@apache.org> 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ò" <il...@apache.org> 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_SERVICE
>>>>> );
>>>>>
>>>>> 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/
Re: [DISCUSS] client / default accept header
Posted by "Klevenz, Stephan" <st...@sap.com>.
Cool and thx.
On 04.07.14 11:24, "Francesco Chicchiriccò" <il...@apache.org> 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ò" <il...@apache.org> 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 <st...@sap.com>
>>>> 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" <st...@sap.com> 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ò" <il...@apache.org>
>>>>> 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ò" <il...@apache.org>
>>>>>>> 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/
>
Re: [DISCUSS] client / default accept header
Posted by Francesco Chicchiriccò <il...@apache.org>.
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ò" <il...@apache.org> 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 <st...@sap.com>
>>> 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" <st...@sap.com> 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ò" <il...@apache.org>
>>>> 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ò" <il...@apache.org>
>>>>>> 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/
Re: [DISCUSS] client / default accept header
Posted by "Klevenz, Stephan" <st...@sap.com>.
Right. I have fixed it. Please pull again.
Stephan
On 04.07.14 08:56, "Francesco Chicchiriccò" <il...@apache.org> 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 <st...@sap.com>
>> 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" <st...@sap.com> 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ò" <il...@apache.org>
>>>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ò" <il...@apache.org>
>>>>> 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/
>
Re: [DISCUSS] client / default accept header
Posted by Francesco Chicchiriccò <il...@apache.org>.
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(ContentNegotiator.java:131)
at
org.apache.olingo.server.core.ContentNegotiatorTest.testContentNegotiation(ContentNegotiatorTest.java:165)
at
org.apache.olingo.server.core.ContentNegotiatorTest.testServiceDocument(ContentNegotiatorTest.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 <st...@sap.com>
> 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/EdmEnumType
> Impl.java
> diff --git
> a/lib/client-core/src/main/java/org/apache/olingo/client/core/edm/EdmEnumTy
> 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/EdmEnumTy
> peImpl.java
> +++
> b/lib/client-core/src/main/java/org/apache/olingo/client/core/edm/EdmEnumTy
> 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" <st...@sap.com> 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ò" <il...@apache.org> 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ò" <il...@apache.org>
>>>> 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_SERVIC
>>>>>> 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/
Re: [DISCUSS] client / default accept header
Posted by "Klevenz, Stephan" <st...@sap.com>.
I am having another issue here:
commit 62eccf9c19fef21d436309bea70c8aef0a6df1cb
Author: Stephan Klevenz <st...@sap.com>
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/EdmEnumType
Impl.java
diff --git
a/lib/client-core/src/main/java/org/apache/olingo/client/core/edm/EdmEnumTy
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/EdmEnumTy
peImpl.java
+++
b/lib/client-core/src/main/java/org/apache/olingo/client/core/edm/EdmEnumTy
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" <st...@sap.com> 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ò" <il...@apache.org> 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ò" <il...@apache.org>
>>>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_SERVIC
>>>>>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/
>>
>
Re: [DISCUSS] client / default accept header
Posted by "Klevenz, Stephan" <st...@sap.com>.
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ò" <il...@apache.org> 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ò" <il...@apache.org> 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_SERVICE
>>>>);
>>>>
>>>> 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/
>
Re: [DISCUSS] client / default accept header
Posted by Francesco Chicchiriccò <il...@apache.org>.
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ò" <il...@apache.org> 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_SERVICE);
>>>
>>> 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/
Re: [DISCUSS] client / default accept header
Posted by "Klevenz, Stephan" <st...@sap.com>.
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?
Regards,
Stephan
On 03.07.14 12:57, "Francesco Chicchiriccò" <il...@apache.org> 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_SERVICE);
>>
>> 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/
>
Re: [DISCUSS] client / default accept header
Posted by "Klevenz, Stephan" <st...@sap.com>.
Hi Francesco,
> odata.getConfiguration().setDefaultPubFormat(ODataFormat.JSON)
This is what I was looking for :-)
Thanks,
Stephan
On 03.07.14 12:57, "Francesco Chicchiriccò" <il...@apache.org> 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_SERVICE);
>>
>> 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/
>
Re: [DISCUSS] client / default accept header
Posted by Francesco Chicchiriccò <il...@apache.org>.
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_SERVICE);
>
> 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/