On 26/05/2014 16:43, Klevenz, Stephan wrote:
Well, it's hard to me to figure out a "very large" document to include
via reference, anyway...
Well, use case is the way vice versa. Large metadata can be partitioned
into smaller documents.
I know, I was wondering about how "large" can be effectively large.
Anyway as said it sounds like a nice improvement, as said.
At server side we deal with same difficulty with implementation. So first
we focus on API to keep it stable independent from concrete EDM provider
implementation.
I can solve the proxy issue for the integration tests. I found the
HttpClientFactory where I can load proxy settings more flexible from the
environment.
Nice to hear :-)
Regards.
We can keep this in the back. I am currently working on a more flexible
proxy detection for integration tests.
On 26.05.14 16:28, "Francesco Chicchiriccò" <[email protected]> wrote:
On 26/05/2014 14:00, Klevenz, Stephan wrote:
Hi Francesco,
What do you think about to resolve references lazy? That would allow to
know top level resources without following the reference. Types are
qualified and and referenced documents can be resolved only if needed.
Lazy resolution could be a nice enhancement but not straightforward to
implement: EdmClientImpl would need to generate metadata requests
"on-demand", e.g. only when accessing an element whose namespace wasn't
fetched yet.
Otherwise documents could be very large in case of each reference is
resolved directly.
Well, it's hard to me to figure out a "very large" document to include
via reference, anyway...
I think an option not to follow references makes no sense. You are right
at the end the document will be incomplete.
Regards,
Stephan
On 26.05.14 12:44, "Francesco Chicchiriccò" <[email protected]> wrote:
On 26/05/2014 12:14, Klevenz, Stephan wrote:
Hi,
I have implemented a first integration test [1] using the client code
to read service document and metadata from the server side
implementation. It works pretty cool except one issue.
The metadata contains a reference uri and during deserialization this
link is requested and results in an exception due to incomplete proxy
settings. Well, I can correct my proxy settings of course but want
also
to ask if there is a way to configure client not to follow links in
metadata?
Hi Stephan,
there is currently no such option, but it could be done by:
1. adding setFollowEdmReferences(boolean) / isFollowEmdReferences() to
V4's Configuration [2]
2. checking Configuration#isFollowEdmReferences() before processing
external references in XMLMetadataRequestImpl#execute [3]
Anyway, I am actually not sure it would be correct: after all, an Edm
document that declares external reference(s) is likely to have some
unresolved elements in it, if client is not following the external
references.
WDYT?
Regards.
<edmx:Edmx Version="4.0">
<Reference
Uri="http://docs.oasis-open.org/odata/odata/v4.0/cs02/vocabularies/Org.
OD
ata.Core.V1.xml">
<Include Namespace="Org.OData.Core.V1" Alias="Core"/>
</Reference>
<edmx:DataServices>
[1]
https://git-wip-us.apache.org/repos/asf?p=olingo-odata4.git;a=tree;f=fi
t/
src/test/java/org/apache/olingo/fit/tecsvc;h=dadbedfacccbb63e0575c5112e
91
d21d41a6ae9e;hb=olingo-266-tecsvc
[2]
https://git-wip-us.apache.org/repos/asf?p=olingo-odata4.git;a=blob;f=lib
/c
lient-api/src/main/java/org/apache/olingo/client/api/v4/Configuration.ja
va
[3]
https://git-wip-us.apache.org/repos/asf?p=olingo-odata4.git;a=blob;f=lib
/c
lient-core/src/main/java/org/apache/olingo/client/core/communication/req
ue
st/retrieve/v4/XMLMetadataRequestImpl.java
--
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/
