It's all about the answers!

Ask a question

CLM 5.0 + RHEL 6.5: error registering a second CCM application


Mike Brouwers (341318) | asked Jul 14 '14, 2:52 p.m.
retagged Jul 22 '14, 4:59 p.m. by Ken Tessier (84117)
 Hi,

I'm trying to setup a second ccm application, but when registering the second application through jts/setup I keep getting the following error:

The server could not access the discovery URL for the application. If you have configured a virtual host for an application, the virtual hostname must be used in the URL for the application.ID CRJAZ2081E
hide details
Unable to load https://myurl:9443/demo/scr status: 404
My other applications (CCM, JTS, QM are working fine)
I have tried redeploying the war files, tried multiple new server/conf/ccm (but then renamed to demo and the right parameters adjusted).
I'm out of ideas.
This is a server migrated from v4.0.5 but the problem does not seem to be related to that.
Please help.
Mike

4 answers



permanent link
Stephanie Bagot (2.1k1513) | answered Jul 14 '14, 3:19 p.m.
FORUM MODERATOR / JAZZ DEVELOPER
Are you using Websphere? There is a virtual host configuration option in Websphere, see:
http://pic.dhe.ibm.com/infocenter/clmhelp/v4r0m1/index.jsp?topic=%2Fcom.ibm.jazz.install.doc%2Ftopics%2Ft_configuring_virtual_hosts.html
(this is from the 4.0.1 Information center, but the steps are pretty much the same)
Make sure your virtual host is configured properly. Otherwise, I would recommend checking the WAS logs for that application and seeing if there are any errors there.

Comments
Mike Brouwers commented Jul 14 '14, 3:35 p.m.

 Hey Stephanie, 


no I'm using tomcat... On first sight I do not see anything wrong in the logs there..


permanent link
Mike Brouwers (341318) | answered Jul 14 '14, 4:34 p.m.
 This is the error I get in the logs:

Jul 14, 2014 4:27:58 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet [equinoxbridgeservlet] in context with path [/demo] threw exception
Throwable occurred: java.lang.IllegalStateException: Cannot call sendError() after the response has been committed
at org.apache.catalina.connector.ResponseFacade.sendError(ResponseFacade.java:450)
at org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:78)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at org.eclipse.equinox.servletbridge.BridgeServlet.service(BridgeServlet.java:120)
at com.ibm.team.repository.server.servletbridge.JazzServlet.service(JazzServlet.java:74)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at com.ibm.team.repository.server.servletbridge.BridgeFilter.processDelegate(BridgeFilter.java:165)
at com.ibm.team.repository.server.servletbridge.BridgeFilter.initialize(BridgeFilter.java:319)
at com.ibm.team.repository.server.servletbridge.BridgeFilter.doFilter(BridgeFilter.java:196)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:610)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:312)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1040)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:313)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:906)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:929)
at java.lang.Thread.run(Thread.java:761)

permanent link
Donald Nong (14.5k614) | answered Jul 14 '14, 10:34 p.m.
I am quite sure your second CCM application is not deployed correctly and it has little to do with JTS. Simply try the URL https://myurl:9443/demo/scr or https://myurl:9443/demo/ in your browser. If you get the same HTTP 404 error, you need to check the deployment of the second CCM application.
I did a quick and dirty test in both my 4.0.5 and 5.0 environments and had no difficulties with bringing up the second CCM application. Here are what I did.
1. Copy server/conf/ccm to server/conf/demo
2. Modify server/conf/demo/teamserver.properties by changing the paths to "demo".
3. Copy server/tomcat/webapps/ccm.war to server/tomcat/webapps/demo.war.
4. Start Tomcat.
That's it really. I can see the login page if I access https://<server>:9443/demo, or get an XML output if I access https://<server>:9443/demo/scr. I have not checked carefully whether I need to change anything else but that should get you started anyway.
Note: I did not register the second CCM "demo" in JTS since I don't want to keep it in my environment.
When checking catalina.out, make sure that there are no errors after the line saying deploying demo.war.

Comments
Mike Brouwers commented Jul 14 '14, 10:58 p.m. | edited Jul 14 '14, 11:00 p.m.

Hey Donald,


I have installed a complete new server, and followed the steps you mentioned. In windows this works flawless ( I have done this many times), but not in Linux.

I cannot open the https://<server>:9443/demo/scr nor can I open the https://<server>:9443/demo/scr.
If I can access it I can register it. But I can't even access it.



Mike Brouwers commented Jul 14 '14, 11:01 p.m. | edited Jul 14 '14, 11:01 p.m.

 What I have also noticed is in the localhost.2014-07-14.log when logging for other applications (I have enabled the logging level ALL on all possible logs) "Checking for SSO cookie" is logged. But when it logs about the demo application I get the error "SSO cookie not present". And right after this message I get the 

Jul 14, 2014 4:27:58 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet [equinoxbridgeservlet] in context with path [/demo] threw exception
Throwable occurred: java.lang.IllegalStateException: Cannot call sendError() after the response has been committed

Any ideas?


Donald Nong commented Jul 15 '14, 2:32 a.m.

I don't think the SSO cookie has anything to do with the HTTP 404 error, because, it's about SSO. The SEVERE error message that you pointed out earlier seems the one we should look at. Since com.ibm.team.repository.server.servletbridge.JazzServlet.service appears in the stack trace, I assume that the CCM application binary already tried to run, but failed. In this case, take a look at server/tomcat/work/Catalina/localhost/demo/eclipse/workspace/.metadata/.log and see what you can find. Maybe you can compare it with server/tomcat/work/Catalina/localhost/ccm/eclipse/workspace/.metadata/.log.


permanent link
Mike Brouwers (341318) | answered Jul 15 '14, 1:16 p.m.
edited Jul 15 '14, 1:18 p.m.
 Hey Donald, the demo application does not have a .log file, not even a .metadata folder. The ccm application does have one...

Everything else in that directory looks exactly the same though...

Comments
Donald Nong commented Jul 15 '14, 9:22 p.m.

Hi Mike, it gets more difficult then. I think we are now in the Eclipse territory and it appears that the Eclipse base cannot be initialized. Next thing I would look at is a particular install.log file which can be found in the eclipse/configuration/org.eclipse.osgi/bundles/ folder (use "find" command to locate it). If you can't find anything wrong there, I am afraid that I have nothing more to say.

Your answer


Register or to post 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.