Community
Participate
Working Groups
Provide http request tracing tool for all repository connectors (perhaps available on repository prefs page next to Validate button). So, it could show request details similar to "wget -v -d ..." and would also allow to save returned document to file. That would help to debug connection as well as parsing issues for all connectors.
I feel a urgent need for this thing to debug what the web connector is doing. When I tried to configure it to work with the mantis repository, it was a pain in the a$$ to try to figure out what was happening, what URLs it was trying to access, if there is a error on the pattern or it is because it is returning a error page, etc... I had to debug the connector, put some breakpoints, examine the httpclient variables, until discover it was a bug on connector. Regarding you idea, Eugene, I'd like to suggest to create a "Mylar Console", similar to the "CVS console", where the user can track all operations the connectors are trying to do.
(In reply to comment #1) > I feel a urgent need for this thing to debug what the web connector is doing. > > When I tried to configure it to work with the mantis repository, it was a pain > in the a$$ to try to figure out what was happening, what URLs it was trying to > access, if there is a error on the pattern or it is because it is returning a > error page, etc... I was going to check if I can add a link to the error message, that would open external web browser with content fetched from the current url. > I had to debug the connector, put some breakpoints, examine the httpclient > variables, until discover it was a bug on connector. Generally I just use wget to track down all the redirects and locations. > Regarding you idea, Eugene, I'd like to suggest to create a "Mylar Console", > similar to the "CVS console", where the user can track all operations the > connectors are trying to do. Not sure if console will work. We need to debug this stuff while being in the modal dialogs (repository properties or query wizard). So, I guess only practical options are either another popup dialog, or separate wizard page.
(In reply to comment #2) > Generally I just use wget to track down all the redirects and locations. The idea is to avoid using external tools (at least for the major cases). > Not sure if console will work. We need to debug this stuff while being in the > modal dialogs (repository properties or query wizard). So, I guess only > practical options are either another popup dialog, or separate wizard page. > Yes, the console would be for general connector tracking. For the webconnector we can have a little expandable section on the wizard, like what exists today for templates, with a panel where we can track the communication when the user hits "Preview". With this, we can at least see what URLs are being called, and the contents that are being returned. This should help a lot.
(In reply to comment #3) > (In reply to comment #2) > > Generally I just use wget to track down all the redirects and locations. > The idea is to avoid using external tools (at least for the major cases). I know. It was my idea after all. I just saying that you could of used the right tools. :-) > > Not sure if console will work. We need to debug this stuff while being in the > > modal dialogs (repository properties or query wizard). So, I guess only > > practical options are either another popup dialog, or separate wizard page. > Yes, the console would be for general connector tracking. Not sure it is needed after we already verified connection. > For the webconnector > we can have a little expandable section on the wizard, like what exists today > for templates, with a panel where we can track the communication when the user > hits "Preview". Heh. There is already too many expandable areas. This approach to UI does not scale well. > With this, we can at least see what URLs are being called, and the contents > that are being returned. This should help a lot. Url and content will be possible to see from the link in the error message. We don't need console for that. What console is really needed for is to see response headers and redirects...
(In reply to comment #4) > I know. It was my idea after all. I just saying that you could of used the > right tools. :-) Yes, I was completely unaware of wget. I'll start to use it next time. > Heh. There is already too many expandable areas. This approach to UI does not > scale well. :-) > Url and content will be possible to see from the link in the error message. We > don't need console for that. > > What console is really needed for is to see response headers and redirects... > I need to see the complete redirect story, not only the last URL.
(In reply to comment #5) > > What console is really needed for is to see response headers and redirects... > I need to see the complete redirect story, not only the last URL. That is what you'll see in the trace.
*** Bug 206844 has been marked as a duplicate of this bug. ***
Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn
