oslcOauthClient.getResource returns ClientResponse with EofSensorInputStream value

[Kira-Cesonia]

While trying to parse a Requirement obtained by oslcOauthClient.getResource, I run into the problem that some of its Attribute Values are URIs that point to different objects, such as:

• http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-M-00000100/types/attrDef-1025#1
• http://localhost:8080/dwa/rm/acp/urn:rational::1-5efc6f9a4ff877cf-F-00000000/gFgcK1req0%252BQ5gE6yE5YsEZZcDI%253D%250A

I tried to resolve these by using them as inputs for oslcOauthClient.getResource, but instead of an object that tells me what this resource is, I just get a ClientResponse with an EofSensorInputStream as its entity. I do not know how to handle this.

To take it from the top, here is what I do:

1.) Obtain the Requirement using this code:

        String requirementURL = http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-O-2-00000100;
        ClientResponse requirementResponse = oslcOauthClient
            .getResource(requirementURL, OslcMediaType.APPLICATION_RDF_XML);
        Requirement requirement = requirementResponse.getEntity(Requirement.class);

2.) Translate the Requirement into a ReqIF SpecObject (my own data type, based on the ReqIF Definition)

2.1.) Translate all the basic values from the Requirement to the SpecObject, such as name, date, identifier, etc...

2.2.) Translate the Extended Properties to Attribute Values

This is where it gets tricky, because according to the ReqIF definition, every Attribute Value has to be one of a total of 7 datatypes (such as ATTRIBUTE-VALUE-INTEGER or ATTRIBUTE-VALUE-ENUM), so I need to be able to tell from each Extended Property which Datatype to use. For most of them, this is easy since the Extended Properties already are of easily mappable object types, such as int or boolean, but there is also a few attributes that are of the type URI instead.

Now, as I have understood it, the concept behind DOORS OSLC is that every object has a resource URI that can be used to get the resource, so I imagine that when the URI is something like http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-M-00000100/types/attrDef-1025#1, that this is the resource URI in DOORS.

I even have it down to the point where I have the URIs for what I imagine is the corresponding attribute definition. In above case, this would be http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-M-00000100/types/attrDef-1025.

Now, what I want in the next step is something that allows me to call those URIs, and return me objects representing the DOORS resources behind that object, such as:

        String attributeDefinitionRefValue = http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-M-00000100/types/attrDef-1025;
        ClientResponse datatypeResponse = oslcOauthClient
            .getResource(attributeDefinitionRefValue, OslcMediaType.APPLICATION_RDF_XML);
        AttributeDefinition attributeDefinition = datatypeResponse .getEntity(AttributeDefinition.class);

...however, this does not work as for a reason that I can't understand, above getResource call returns an EofSensorInputStream instead of an object that I can use to draw conclusions about the datatype of the queried object.

I'll try to sum it up again.

• Getting a requirement (Spec Object) by its URL via getResource works
• However, that requirement contains extended properties (Attribute Values) that are not of one of the seven allowable ReqIF Attribute Value types, but instead are URIs pointing to DOORS resources of unknown type
• I need some way to figure out which DOORS resources they are pointing to, so I can determine the correct data type to map it to
• Since I am very certain that the URI (which is contained within requirement.extendedProperties[x].value) is pointing to a DOORS resource (of unknown type to me), I would expect that oslcOauthClient.getResource would return that resource to me
• My intent was to look which kind of resource is returned, and take action accordingly
• However, instead of a valid resource, a response containing an EoFSensoringInputStream is returned

So, is this a limitation of LYO, or am I doing something wrong? In either case, feedback would be greatly appreciated.

[jadelkhoury]

Hi

EofSensorInputStream seems to be a DOORS-specific error message? I don't think we can help you there.

Extended Properties otherwise holds properties in the response from the OSLC server, that cannot be directly mapped to any of the attributes in the Requirements Java class.

from your description under https://github.com/eclipse/lyo.client/issues/93, I suspect you are handling the QName & values of the extended properties. Duplicated here to illustrate:

requirement
└extendedProperites
[8]
  ├QName key = {http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-M-00000100/types/}attrDef-1025
  └URI value = http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-M-00000100/types/attrDef-1025#1

I see that you have a few issues reported here. Maybe you can summarize the status of your questions on our forum https://forum.open-services.net/ or email the Lyo-Dev mailing list lyo-dev@eclipse.org. So we can try to help you from there.

[Kira-Cesonia]

I have by now figured out how to parse the EofSensorInputStream. It is not, as expected, an error message, but rather an XML that contains the Formal Module that contains the Requirement (at least for http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-M-00000100/types/attrDef-1025#1, for http://localhost:8080/dwa/rm/acp/urn:rational::1-5efc6f9a4ff877cf-F-00000000/gFgcK1req0%252BQ5gE6yE5YsEZZcDI%253D%250A, it really is an error message).

Here's how that parsed result looks:

<?xml version="1.0"?>
<rdf:RDF
    xmlns:dcterms="http://purl.org/dc/terms/"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:oslc="http://open-services.net/ns/core#"
    xmlns:acp="http://jazz.net/ns/acp#"
    xmlns:rm_property="http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-M-00000100/types/"
    xmlns:oslc_rm="http://open-services.net/ns/rm#"
    xmlns:doorsAttribute="http://jazz.net/ns/rm/doors/attribute#"
    xmlns:rm="http://jazz.net/ns/rm#"
    xmlns:foaf="http://xmlns.com/foaf/0.1/">
  <rm:Module rdf:about="http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-M-00000100">
    <oslc_rm:uses rdf:resource="http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-O-75-00000100"/>
    <oslc_rm:uses rdf:resource="http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-O-128-00000100"/>
    <oslc_rm:uses rdf:resource="http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-O-27-00000100"/>
    <dcterms:isPartOf rdf:resource="http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-P-00000028"/>
    <oslc_rm:uses rdf:resource="http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-O-29-00000100"/>
    <oslc_rm:uses rdf:resource="http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-O-64-00000100"/>
    <oslc_rm:uses rdf:resource="http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-O-82-00000100"/>
    <oslc_rm:uses rdf:resource="http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-O-95-00000100"/>
    <oslc_rm:uses rdf:resource="http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-O-137-00000100"/>
    <oslc_rm:uses rdf:resource="http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-O-115-00000100"/>
    <oslc_rm:uses rdf:resource="http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-O-45-00000100"/>
    <doorsAttribute:createdOn rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime"
    >2014-12-09</doorsAttribute:createdOn>
    <oslc_rm:uses rdf:resource="http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-O-21-00000100"/
[...the list goes on like this for some time...]
    <oslc_rm:uses rdf:resource="http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-O-15-00000100"/>
    <oslc_rm:uses rdf:resource="http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-O-110-00000100"/>
  </rm:Module>
</rdf:RDF>

Now, I don't know which datatype is used to handle Formal Modules in LYO, so I'm just going to call it "Module" from here on out.

The core of this issue is that when I call oslcOauthClient.getResource("http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-M-00000100/types/attrDef-1025#1"), I would expect it to return a ClientResponse with an entity of type Module and not EofSensorInputStream, similar to how the call oslcOauthClient.getResource(http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-O-2-00000100) returns a ClientResponse with an entity of type Requirement. That is my user story for this ticket.

[jadelkhoury]

My guess (but only a guess) is also that http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-M-00000100/types/attrDef-1025 is the attribute definition (from the word "attrDef"). But note that http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-M-00000100/types/attrDef-1025#1 is the same as the URI without the "#1". Since this so-called URI fragment (#1) is not sent to the server (have a read on https://en.wikipedia.org/wiki/URI_fragment and various Stackoverflow tracks about sending fragment to the server).

I think you should start with trying to workout what the Doors server is returning for the various URLs. before we deal with how Lyo (the client) is handling them. My guess is that maybe Doors is not returning what you expect.

So, What does the RDF/XML look like for your call to http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-M-00000100/types/attrDef-1025#1 ?

How Lyo then maps this RDF/XML to the classes, will depend on the RDF type in the response (In example above rm:Module)

<rm:Module rdf:about="http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-M-00000100">

[Kira-Cesonia]

I posted above what that RDF/XML looks like. For some reason that is not known to me yet, when I try either of these calls:

• getResource(http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-M-00000100/types/attrDef-1025#1)
• getResource(http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-M-00000100/types/attrDef-1025)
• getResource(http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-M-00000100)

...I always get essentially the same RDF/XML out of it. It sometimes is a little differently structured, but its core content is always the rm:Module, and it always gets mapped as an EofSensorInputStream.

However, this took me some time to figure out since the getResource function returned an EofSensorInputStream, as opposed to a Module, which from my current point of view would be the expected behaviour. Had it returned a Module, I would have been able to tell right away what was wrong.

"Hey, I expected it to return me some kind of AttributeDefinition, but the request returned a Module instead! DWA must be doing some faulty redirecting here!"

As it is, it's more along the lines of:

"Hey, I expected it to return me some kind of AttributeDefinition, but the request returned a... whatever in Lerra this is... What's going on, eh?"

So that's the core issue I want to raise here. Why does getResource return an EofSensorInputStream, even though as you observed above Lyo should map the class depending on the RDF Type, which in this case would be rm_Module.

[jadelkhoury]

Hi

But the RDF/XML above doesn't really show the lines that contain things like http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-M-00000100/types/attrDef-1025#1 Nor does it show anything with "EofSensorInputStream". From what I see, this is a Module resource. I can't even see how Lyo created the term EofSensorInputStream if this is not even in the input.

Maybe you need to attach the complete content?

One thing is for sure: http://....types/attrDef-1025#1 and http://....types/attrDef-1025 are the same thing when obtained by the server. See my link on URI Fragments above.

If you want to isolate this issue, I suggest you try to use POSTMAN to really understand what the server returns - irrespective of what Lyo does with it. Once this is clear, we can try to work out how Lyo is interpreting the input.

My suspicion is still that this is a DOORS (the server) issue. Have you tried posting at the jazz.net forum? That's where I believe you can get IBM-based tool support.

[Kira-Cesonia]

As I was trying to say, the issue at this particular construction site is that when I do this:

ClientResponse response = oslcOauthClient.getResource("http://localhost:8080/dwa/rm/urn:rational::1-5efc6f9a4ff877cf-M-00000100/types/attrDef-1025#1")

...then the entity of that response is an EofSensorInputStream representing a Module instead of an AttributeDefinition.

I guess what really bothers me most is that in I case like this where I only have a rough imagination of what sort of object I expect to be contained within the response, I can't just use Object responseEntity = requirementResponse.getEntity(); to figure out which sort of object is returned. I know that's probably kinda highbrow, but I think it would be really useful in these kinds of situations.

Because then I would have been able to tell right away "Hey, this request is returning me a Module instead of an AttributeDefinition. Something might be wrong with the DWA routing."

And by the way, let's not discuss the DWA routing issue here. I have already followed that one through on more appropriate places like these:

• https://forum.open-services.net/t/attribute-value-uri-cant-be-resolved/406
• https://jazz.net/forum/questions/271028/attribute-uri-resolving
• https://www.ibm.com/mysupport/s/forumsquestion?id=0D50z00006cPZ5sCAG
• https://stackoverflow.com/questions/63377594/get-doors-attribute-type-via-lyo

[berezovskyi]

We will try to address that in Lyo 5.1 if we can reproduce.

[berezovskyi]

Should not be returning https://www.javadoc.io/doc/org.apache.httpcomponents/httpclient/4.5.3/org/apache/http/conn/EofSensorInputStream.html under normal circumstances, anyway. But I need some way (read: help) to reproduce this.