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/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" <[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_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/
>>
>
