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(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/
