Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 177234

Summary: [web connector] mysterious "Unable to parse resource. Check query regexp"
Product: z_Archived Reporter: Jack Repenning <jrepenning>
Component: MylynAssignee: Mylyn Inbox <mylyn-inbox>
Status: RESOLVED WONTFIX QA Contact:
Severity: normal    
Priority: P4 CC: hlhawkins, steffen.pingel, wmitsuda
Version: unspecifiedKeywords: helpwanted
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
failing html
none
working html
none
wget-fetched HTML
none
wget query.log none

Description Jack Repenning CLA 2007-03-13 18:36:07 EDT
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.
Comment 1 Jack Repenning CLA 2007-03-13 18:38:33 EDT
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.
Comment 2 Jack Repenning CLA 2007-03-13 18:39:44 EDT
Created attachment 60745 [details]
working html

captured in the same was as "failing html", from a tigris.org IZ site.
Comment 3 Eugene Kuleshov CLA 2007-03-21 23:02:07 EDT
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.
Comment 4 Jack Repenning CLA 2007-03-22 00:58:51 EDT
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).
Comment 5 Jack Repenning CLA 2007-03-22 01:00:37 EDT
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
Comment 6 Jack Repenning CLA 2007-03-22 01:01:20 EDT
Created attachment 61644 [details]
wget query.log

the wget log that matches the query.html above
Comment 7 Mik Kersten CLA 2007-04-16 14:43:09 EDT
Eugene: any news on this?
Comment 8 Eugene Kuleshov CLA 2007-04-16 14:55:28 EDT
I'll try to look at it this week.
Comment 9 Eugene Kuleshov CLA 2007-04-27 20:51:31 EDT
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.
Comment 10 Willian Mitsuda CLA 2007-05-16 00:37:56 EDT
(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.
Comment 11 Eugene Kuleshov CLA 2007-05-16 15:07:38 EDT
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...
Comment 12 Steffen Pingel CLA 2009-03-12 03:11:01 EDT
Jack, please reopen if you still experience this problem with the latest version of Mylyn and provide additionals details how to reproduce the problem.