Cannot create connection to Repository
We just installed RRC Beta2 client on a user's machine. He's been added to the repository to which we want him to connect. When he fires up his client and clicks the Get Started button, the repository connection dialog appears. He enters the name of the repository in the Name field, the URI to the server, his username and password. The OK button remains greyed out so he can't complete the connection.
I've seen this behavior before when the URI was invalid or something else was entered incorrectly, however, if he copies and pastes the URI into a browser, the site comes up just fine and he's able to log in using the username and password we gave him. The URI we're using looks like this: http://<server>:9080/jazz We've turned off certificates so we're using port 9080 instead of 9443, for those of you who are wondering. Any other ideas? Is there something we need to configure in his client first? I don't remember having to do that previously. Thanks, John |
5 answers
The URI we're using looks like this: There was a jazz team server bug related to interpretation of URIs, and at the moment I don't recall whether it was fixed before or after beta 2 was released. First, I assume you aren't using "localhost" as the RRC server name, since another user can't connect to your "localhost" (by definition). Second, I suggest you make sure the user is connecting with the EXACT same URI you used when you configured the RRC server. By exact I mean exactly the same string (including which letters are capitalized), and this should match the host name of the system as well. If you didn't define RRC with a fully qualified domain name, then you would need to do it again. Yes, this is more restrictive than the Internet RFCs defining acceptable domain name representation in URIs (and related behavior). |
The URI we're using looks like this: There was a jazz team server bug related to interpretation of URIs, and at the moment I don't recall whether it was fixed before or after beta 2 was released. The problem appears to have been that I should have used "rdm" instead of "jazz" in the URI for that dialog. I was able to get to another client machine which had been working and check that out. Now that that is solved, the next issue is that when I use the 9080 port, I get a message saying I'm being redirected to 9443 "because the server is configured to use it". I modified both the appropriate config files and restarted Tomcat, so why is it still configured for 9443? I do not get this message on either our RTC or RQM servers. Thanks, John |
So first, yes "rdm" is what you want, not "jazz". I think there may be some confusion over our web client. There are actually two web interfaces. I suspect the one you reached by using "jazz" is actually the Jazz Web Admin ui for the underlying Jazz server. This is not the same as the Composer web client which you would access using http://<server>:9080/rdm/web/rrc
As for the issue with port 9080, if you manually updated any config files, you will likely need to at least go to the rdm/configure page and reconfigure the server or make sure you update those files BEFORE going through the rdm/setup process (though I'll defer to the server team to confirm or deny that). |
So first, yes "rdm" is what you want, not "jazz". I think there may be some confusion over our web client. Ya think? :-) Seriously, there's a great deal of confusion inherent in the whole Jazz model, IMO. There are actually two web interfaces. I suspect the one you reached by using "jazz" is actually the Jazz Web Admin ui for the underlying Jazz server. This is not the same as the Composer web client which you would access using http://<server>:9080/rdm/web/rrc Yes, I'm aware of that. In this case, the fat client won't even accept the URI ending in "jazz", but of course it doesn't give any indication of what its problem is. It just leaves the OK button greyed out. As for the issue with port 9080, if you manually updated any config files, you will likely need to at least go to the rdm/configure page and reconfigure the server or make sure you update those files BEFORE going through the rdm/setup process (though I'll defer to the server team to confirm or deny that). Running the configure page doesn't appear to offer the ability to change the port number. I see three options: server name, "Create new storage areas and indices and rebuild existing indices. Existing data will be preserved." and "Create all storage areas and indices. Any existing data will be lost." The server name is fine, so I'd have to choose one of the other two options. The first (preserve data) would be preferred, but both options are a bit scary. |
In this case, the fat client won't even accept the URI ending in "jazz", but of course it doesn't give any indication of what its problem is. It just leaves the OK button greyed out. Right, because the URI ending in jazz refers to the JFS server which is not what the rich client is for. By default, the URI shown when creating a new repository connection ends with "rdm", and while we could include a tip message indicating it should end with that (sort of like the "examples" in the rdm/setup pages), "rdm" is not a cast in stone segment - it will be configurable in the future (just as "jazz" can be changed in 2.0 already). Running the configure page doesn't appear to offer the ability to change the port number. I see three options: server name, "Create new storage areas and indices and rebuild existing indices. Existing data will be preserved." and "Create all storage areas and indices. Any existing data will be lost." Understandable. Again, I'll back out and hope a server representative can chime in on what needs to happen in order to get a port change acknowledged. My suspicion is that the port has already been cached away somewhere and while changing the files is the first step, something else needs to occur for that change to actually go into affect. |
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.