Community
Participate
Working Groups
Can't create queries against one "Generic Web-Based" repository (PCN, an instance of IssueZilla), even with parameters copied from several other working IZs. Failure is "Unable to parse resource. Check query regexp." Nothing in Error Log. I've compared working and failing HTML carefully (will attach them), don't see any difference that would fool the regexp. Failing repository _does_ use SSL (HTTPS); some working repositories do, some don't.
Created attachment 60744 [details] failing html note that this HTML was accessed by a very long URL, with lots of unused query parameters. That's not the cause of this problem, though: I've had the same failure from the query preconfigured for GlasFish (except for changing the component). This HTML comes from pasting the Mylar URL into the embedded browser and fixing up the ${serverUrl} bit.
Created attachment 60745 [details] working html captured in the same was as "failing html", from a tigris.org IZ site.
Jack, I can't find anything incriminating in the failing.html page. So, it could be that connector can't download page. We have some troubleshooting tips on the wiki page at http://wiki.eclipse.org/index.php/Mylar_FAQ#Generic_Web_Repository_Connector You can at least try to specify "(.+?)(\n)" as query template to see what page connector gets. If that does not help then I'll need to see the output from wget command on this url. Is it some repository I can access? It would be easier to debug this. Thanks.
Both debugging tricks (wget and "(.+?)(\n)") show the same thing: the request is being redirected to the login page. Confirmation: the GlassFish IssueZilla repository (which works just fine anonymously) fails in this same way if I provide a user name and password. I'll add query.log and query.html (from the wget failure).
Created attachment 61643 [details] wget-fetched HTML This is the HTML for the login page, eventually reached through the series of redirects recorded in the query.log
Created attachment 61644 [details] wget query.log the wget log that matches the query.html above
Eugene: any news on this?
I'll try to look at it this week.
Jack, apparently cookie support in commons http client, that Mylar using don't work to well with Collabnet web sites (something about domain that is changed during several redirects that are happens there), so cookie set on logon page is not visible at the request page. I had to put special handling for this in another connector you know about. Anyways, while fixing bug 167282 we disabled custom code to handle redirects that I initially wrote and turned standard redirect back on. I don't remember all the details, but main reason probably was that my code didn't work on some web sites. Maybe Willian can recall more details on this.
(In reply to comment #9) > I don't remember > all the details, but main reason probably was that my code didn't work on some > web sites. Maybe Willian can recall more details on this. > Sorry, I don't remember exactly what was the situation. But according to what I wrote on that bug, I think this is a different case.
Well, at this point I don't see any other option then re-enable back that custom redirect code and then try to fix anything that would breaks...
Jack, please reopen if you still experience this problem with the latest version of Mylyn and provide additionals details how to reproduce the problem.
