Does the application have to be using the same port as JTS?

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,

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>

<Application>



<jd>

<jd>https://localhost:9444/mcif</jd>

</jd>

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

java.lang.IllegalArgumentException

com.ibm.team.jfs.app.http.util.StringUtil.splitPair(StringUtil.java:54)

com.ibm.team.jfs.app.http.util.StringUtil.splitPair(StringUtil.java:25)

com.ibm.team.jfs.app.http.util.ContentRange.parse(ContentRange.java:178)

com.ibm.team.jfs.app.http.util.MediaRange.parse(MediaRange.java:295)

com.ibm.team.jfs.app.http.util.HttpParseUtil.isMimeTypeMatchesContentType(HttpParseUtil.java:314)

com.ibm.team.jfs.app.resource.entity.RDFEntity.isValidContentType(RDFEntity.java:128)

com.ibm.team.jfs.app.resource.entity.RDFEntity.validateContentType(RDFEntity.java:117)

com.ibm.team.jfs.app.resource.entity.RDFEntity.(RDFEntity.java:108)

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

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

java.lang.IllegalArgumentException

com.ibm.team.jfs.app.http.util.StringUtil.splitPair(StringUtil.java:54)

com.ibm.team.jfs.app.http.util.StringUtil.splitPair(StringUtil.java:25)

com.ibm.team.jfs.app.http.util.ContentRange.parse(ContentRange.java:178)

com.ibm.team.jfs.app.http.util.MediaRange.parse(MediaRange.java:295)

com.ibm.team.jfs.app.http.util.HttpParseUtil.isMimeTypeMatchesContentType(HttpParseUtil.java:314)

com.ibm.team.jfs.app.resource.entity.RDFEntity.isValidContentType(RDFEntity.java:128)

com.ibm.team.jfs.app.resource.entity.RDFEntity.validateContentType(RDFEntity.java:117)

com.ibm.team.jfs.app.resource.entity.RDFEntity.(RDFEntity.java:108)

com.ibm.team.jfs.app.resource.entity.RDFEntity.getRDFEntity(RDFEntity.java:205)

com.ibm.team.jfs.app.resource.entity.RDFEntity.getModel(RDFEntity.java:246)

com.ibm.team.repository.service.internal.discovery.FriendsAdminRestService.getDiscoveryDocumentModel(FriendsAdminRestService.java:980)

com.ibm.team.repository.service.internal.discovery.FriendsAdminRestService.getAppRegistrationHandler(FriendsAdminRestService.java:716)

com.ibm.team.repository.service.internal.discovery.FriendsAdminRestService.postRegisterApp(FriendsAdminRestService.java:555)

sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)

sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

java.lang.reflect.Method.invoke(Method.java:618)

org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord.invoke(ExportProxyServiceRecord.java:370)

org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord.access$0(ExportProxyServiceRecord.java:356)

org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord$ExportedServiceInvocationHandler.invoke(ExportProxyServiceRecord.java:56)

$Proxy243.postRegisterApp(Unknown Source)

sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)

sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

java.lang.reflect.Method.invoke(Method.java:618)

com.ibm.team.repository.servlet.AbstractTeamServerServlet.doModelledRestService(AbstractTeamServerServlet.java:500)

com.ibm.team.repository.servlet.AbstractTeamServerServlet.handleRequest2(AbstractTeamServerServlet.java:1817)

com.ibm.team.repository.servlet.AbstractTeamServerServlet.handleRequest(AbstractTeamServerServlet.java:1673)

com.ibm.team.repository.servlet.AbstractTeamServerServlet.service(AbstractTeamServerServlet.java:1584)

javax.servlet.http.HttpServlet.service(HttpServlet.java:729)

org.eclipse.equinox.http.registry.internal.ServletManager$ServletWrapper.service(ServletManager.java:180)

org.eclipse.equinox.http.servlet.internal.ServletRegistration.handleRequest(ServletRegistration.java:90)

org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:111)

org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:75)

javax.servlet.http.HttpServlet.service(HttpServlet.java:729)

org.eclipse.equinox.servletbridge.BridgeServlet.service(BridgeServlet.java:120)

com.ibm.team.repository.server.servletbridge.JazzServlet.service(JazzServlet.java:62)

javax.servlet.http.HttpServlet.service(HttpServlet.java:729)

org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)

org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)

org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)

org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)

org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:563)

org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)

org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)

org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:420)

org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)

org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)

org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:879)

org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)

org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)

org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)

org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)

java.lang.Thread.run(Thread.java:811)

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,

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>

<Application>



<jd>

<jd>https://localhost:9444/mcif</jd>

</jd>

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

java.lang.IllegalArgumentException

com.ibm.team.jfs.app.http.util.StringUtil.splitPair(StringUtil.java:54)

com.ibm.team.jfs.app.http.util.StringUtil.splitPair(StringUtil.java:25)

com.ibm.team.jfs.app.http.util.ContentRange.parse(ContentRange.java:178)

com.ibm.team.jfs.app.http.util.MediaRange.parse(MediaRange.java:295)

com.ibm.team.jfs.app.http.util.HttpParseUtil.isMimeTypeMatchesContentType(HttpParseUtil.java:314)

com.ibm.team.jfs.app.resource.entity.RDFEntity.isValidContentType(RDFEntity.java:128)

com.ibm.team.jfs.app.resource.entity.RDFEntity.validateContentType(RDFEntity.java:117)

com.ibm.team.jfs.app.resource.entity.RDFEntity.(RDFEntity.java:108)

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

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:

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.

Below is the header of the scr request from the log file:

2010-11-10 10:27:22,937 [         http-9443-Processor21] DEBUG org.apache.http.wire                                - >> "GET /mcif/scr HTTP/1.1[EOL]"

2010-11-10 10:27:22,937 [         http-9443-Processor21] DEBUG org.apache.http.wire                                - >> "Accept: application/rdf+xml[EOL]"

2010-11-10 10:27:22,937 [         http-9443-Processor21] DEBUG org.apache.http.wire                                - >> "Host: localhost:9444[EOL]"

2010-11-10 10:27:22,937 [         http-9443-Processor21] DEBUG org.apache.http.wire                                - >> "Connection: Keep-Alive[EOL]"

2010-11-10 10:27:22,937 [         http-9443-Processor21] DEBUG org.apache.http.wire                                - >> "User-Agent: Apache-HttpClient/4.0.1 (java 1.5)[EOL]"

2010-11-10 10:27:22,937 [         http-9443-Processor21] DEBUG org.apache.http.wire                                - >> "[EOL]"

2010-11-10 10:27:22,953 [         http-9443-Processor21] DEBUG org.apache.http.wire                                - << "HTTP/1.1 200 OK[EOL]"

2010-11-10 10:27:22,953 [         http-9443-Processor21] DEBUG org.apache.http.wire                                - << "ETag: "grBOBuqRviw2srnUe/A8o9SUiWQ="[EOL]"

2010-11-10 10:27:22,953 [         http-9443-Processor21] DEBUG org.apache.http.wire                                - << "Content-Length: 1408[EOL]"

2010-11-10 10:27:22,953 [         http-9443-Processor21] DEBUG org.apache.http.wire                                - << "Content-Type: application/rdf+xml[EOL]"

2010-11-10 10:27:22,953 [         http-9443-Processor21] DEBUG org.apache.http.wire                                - << "Server: Jetty(6.1.x)[EOL]"

2010-11-10 10:27:22,953 [         http-9443-Processor21] DEBUG org.apache.http.wire                                - << "[EOL]"

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:

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.

Below is the header of the scr request from the log file:

2010-11-10 10:27:22,937 [         http-9443-Processor21] DEBUG org.apache.http.wire                                - >> "GET /mcif/scr HTTP/1.1[EOL]"

2010-11-10 10:27:22,937 [         http-9443-Processor21] DEBUG org.apache.http.wire                                - >> "Accept: application/rdf+xml[EOL]"

2010-11-10 10:27:22,937 [         http-9443-Processor21] DEBUG org.apache.http.wire                                - >> "Host: localhost:9444[EOL]"

2010-11-10 10:27:22,937 [         http-9443-Processor21] DEBUG org.apache.http.wire                                - >> "Connection: Keep-Alive[EOL]"

2010-11-10 10:27:22,937 [         http-9443-Processor21] DEBUG org.apache.http.wire                                - >> "User-Agent: Apache-HttpClient/4.0.1 (java 1.5)[EOL]"

2010-11-10 10:27:22,937 [         http-9443-Processor21] DEBUG org.apache.http.wire                                - >> "[EOL]"

2010-11-10 10:27:22,953 [         http-9443-Processor21] DEBUG org.apache.http.wire                                - << "HTTP/1.1 200 OK[EOL]"

2010-11-10 10:27:22,953 [         http-9443-Processor21] DEBUG org.apache.http.wire                                - << "ETag: "grBOBuqRviw2srnUe/A8o9SUiWQ="[EOL]"

2010-11-10 10:27:22,953 [         http-9443-Processor21] DEBUG org.apache.http.wire                                - << "Content-Length: 1408[EOL]"

2010-11-10 10:27:22,953 [         http-9443-Processor21] DEBUG org.apache.http.wire                                - << "Content-Type: application/rdf+xml[EOL]"

2010-11-10 10:27:22,953 [         http-9443-Processor21] DEBUG org.apache.http.wire                                - << "Server: Jetty(6.1.x)[EOL]"

2010-11-10 10:27:22,953 [         http-9443-Processor21] DEBUG org.apache.http.wire                                - << "[EOL]"

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.