It's all about the answers!

Ask a question

How Do I Fix "assertion failed: " During OSLC Discovery?

Nate Decker (37814059) | asked Jun 24 '14, 8:23 a.m.
edited Jun 24 '14, 8:30 a.m.

I have used the OSLC “discovery mechanism” in the past as discussed on several wiki pages and posts on Under OSLC, you send the server an http request on the “discovery” url and the server responds with a  list of services that it has available. You then pick one of those services and send another request on that URL. You kind of “drill down” through several discovery layers to find out information about the server (e.g., what kinds of work items are available, what projects are present, what url to use for OSLC queries, etc…). Although this has worked in the past, today I am seeing that the server is not responding to one of the basic discovery requests in the way that is expected. This is what I’m seeing:

HTTP GET using https://[our server url:port]/ccm/oslc/workitems/catalog.xml

Responds as expected with an xml file that lists the project areas.  
The client picks one of the project areas that was returned from the sender and requests the “services.xml” associated with that project area. For example:
HTTP GET using https://[our server url:port]/ccm/oslc/contexts/_3ual1BiuEek3hs2s7AEXnQ/workitems/services.xml
(note that _3ual1BiuEek3hs2s7AEXnQ is the project identifier for the selected project area).
At this point, the server is SUPPOSED to return another XML file that provides a bunch of available services for that particular project area. Instead I am getting this:

<?xml version=”1.0” encoding=”UTF-8”?>
<oslc_cm:error xmlns:oslc_cm=>
     <oslc_cm:message>assertion failed: </oslc_cm:message>

I believe this is supposed to work up to this point regardless of whether or not the OSLC-Core-Version: 2.0 header is set, but I've tried it both ways just in case. It doesn't seem to make a difference.

Has anyone encountered this issue before? Is there a fix without a server restart? I have not had an opportunity to issue a server restart yet (there are too many active users who are not impacted by this discovery mechanism deficiency), but am hopeful that will fix it. This kind of issue negatively impacts our information assurance (e.g., availability).

One answer

permanent link
Rosa Naranjo (2.9k11523) | answered Sep 23 '14, 10:21 a.m.
Have you authenticated via OAuth or logged in the server on another browser tab?

Nate Decker commented Sep 23 '14, 10:25 a.m. | edited Sep 23 '14, 10:26 a.m.

This is done via OAuth with code, not within a browser. With that clarification, the answer to your question is yes. We have dozens of project areas across our implementation and the same HTTP request object successfully navigates the discovery tree for each project area except for this one errant project area.

However, by way of update, this appears to no longer be an issue. A couple of days/weeks after I initially encountered the problem, it resolved itself. I was able to once again get data via the discovery mechanism. I'm not sure what the issue was. Fortunately it occurred in a project area that isn't actively used, but I was concerned that the issue could manifest in another project area at some future time.

I'm uneasy that I don't know the cause of the problem or the solution, but for now I'm giving it a low priority and considering the issue closed.

Your answer

Register or to post your answer.