Does the application have to be using the same port as JTS?
Hi,
I tried to register and run an application on a different port from JTS's. The SCR service, which is at https://localhost:9444/micf/scr, returns content as follows <rdf:RDF> Basically, I ran the app on port 9444 instead of JTS's default port 9443. When I registered, I got the following error token is expected to be in 'name=value' format It worked just fine if the port was 9443. So, apparently, JTS does not allow registering an application running on a different port. If this is the case, then the error message seems misleading too. Any comments would be appreciated. Thanks, Vu |
6 answers
I don't see how the port number can make any kind of difference, but what the traceback fragment you posted seems to be showing is that there was an invalid Content-Type header being parsed. Does your /micf/scr resource respond with a Content-Type header, and if so, what is the value? If would be helpful to see the complete stack traceback, in order to understand where the parsing of the Content-Type header is occurring.
Hi, |
|
The Content-Type is "application/rdf+xml" in the header. The SCR service extends and overrides only one method getVariables() from the base class com.ibm.team.jfs.app.servlet.util.BaseServiceContributionResourceService, which returns this Content-Type.
Here is the complete error message. token is expected to be in 'name=value' format Many thanks. I don't see how the port number can make any kind of difference, but what the traceback fragment you posted seems to be showing is that there was an invalid Content-Type header being parsed. Does your /micf/scr resource respond with a Content-Type header, and if so, what is the value? If would be helpful to see the complete stack traceback, in order to understand where the parsing of the Content-Type header is occurring. Hi, |
|
The full traceback confirms that the JTS issued a GET request to your SCR service, and thinks it got an invalid Content-Type header in the response. You can do this to see the actual response:
1. Stop your Jazz server. 2. Edit the conf/jts/log4j.properties file to add log4j.logger.org.apache.http.wire=DEBUG 3. Start your Jazz server 4. Try registering your application The jts.log file should show the request sent to your SCR service, and the response. |
The full traceback confirms that the JTS issued a GET request to your SCR service, and thinks it got an invalid Content-Type header in the response. You can do this to see the actual response:
This shows that the Content-Type header is "application/rdf-xml" which matches the Accept header. |
|
Yes, the Content-Type header looks good; I can't see what the problem would be. If you'd like, you can submit a work item and we can get more details to try and debug this. If you do submit a work item, please add information about the build you are using (the exact build number). And file it against "Repository".
You can submit a work item at https://jazz.net/jazz/web/projects/Jazz%20Foundation#action=com.ibm.team.workitem.newWorkItem The full traceback confirms that the JTS issued a GET request to your SCR service, and thinks it got an invalid Content-Type header in the response. You can do this to see the actual response:
This shows that the Content-Type header is "application/rdf-xml" which matches the Accept header. |
|
Just in case anyone was wondering how this turned out: there was indeed a problem with the Content-Type header returned by the application, but it was for the /rootservices resource, not the /scr resource. The header value in the response was "application/rdf+xml;UTF-8", when it should have been "application/rdf+xml;charset=UTF-8". Hence the "token is expected to be in 'name=value' format" error.
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.