Bugzilla – Full Text Bug Listing
| Summary: | Submit fails silently | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | David Green <greensopinion> |
| Component: | Mylyn | Assignee: | Steffen Pingel <steffen.pingel> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P2 | CC: | robert.elves, steffen.pingel |
| Version: | unspecified | ||
| Target Milestone: | 2.1 | ||
| Hardware: | Macintosh | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
| Bug Depends on: | 186379 | ||
| Bug Blocks: | |||
| Attachments: | |||
|
Description
David Green
You are describing two unrelated issues. For the first one, as far as I know you do need to submit your issue explicitly using submit button in the task editor. So, it is working as expected. Rob, can you please confirm that. However all attachment support (including attaching task context) don't work in offline mode and you should get a error or warning when trying to submit. Also see bug 149210 and bug 152271 I've tried pressing the "submit" button with the same result. Perhaps I should be more clear: - there appears to be no way to "save" changes to a JIRA issue, either by using 'Ctrl+S', or by pressing the 'Submit' button in the editor itself. - the editor does not make any indication of a problem saving via either method - the editor refreshes and all changes are lost Can you please be more specific what kind of changes you are doing? I can see that newly added comment is saved ok and I can see outgoing change in the task list, which stays there after I synchronize that task (F5). Scenario 1: I type in the "new comment" area of a JIRA, then press the submit button. Scenario 2: I right click on the task in the Task List view, and select "Context->Attach" Ok. Let's take one thing at a time. Please answer the following questions: - do you have any errors in the Eclipse logs or in Error Log view? - what is the version of your JIRA server and version of Mylyn JIRA connector - does validate settings button in JIRA repo properties works? - can you get query results back from the server? You may also want to check the following FAQ page about JIRA connector http://wiki.eclipse.org/Mylyn_FAQ#JIRA_Connector (In reply to comment #6) My answers below: > Ok. Let's take one thing at a time. Please answer the following questions: > > - do you have any errors in the Eclipse logs or in Error Log view? No errors at all. > - what is the version of your JIRA server and version of Mylyn JIRA connector JIRA server: Enterprise Edition, Version: 3.7.2-#186 Mylyn JIRA connector: 2.0.0.v20070627 > - does validate settings button in JIRA repo properties works? Yes, confirmation message appears. > - can you get query results back from the server? Yes, read-only access seems to work really well. > > You may also want to check the following FAQ page about JIRA connector > http://wiki.eclipse.org/Mylyn_FAQ#JIRA_Connector > Thanks David. It seems like you are using quite old JIRA connector and we already have number of fixes, including better error handling. Can you please update and try most recent dev build or 2.1m1 from the update site listed at http://www.eclipse.org/mylyn/downloads/builds.php Looks like the latest dev build and sources from HEAD have the same problem. Also, you could try to enable debug tracing as described at http://wiki.eclipse.org/Mylyn_FAQ#Reporting_issues bit it probably won't help, since you are not seeing any errors in the logs (which is really weird). Other then that, since you already have source code, you can try to step trough in the debugger. Put a breakpoint at sourceJiraTaskDataHandler.postTaskData(..) and see if you can capture server response for your submissions. Created attachment 78114 [details]
mylyn/context/zip
Looks like the POST at JiraWebIssueService line 188 returns HTTP 302. This appears to be the only HTTP error message for which an error is not logged:
if (result != HttpStatus.SC_MOVED_TEMPORARILY) {
handleErrorMessage(post, result);
}
Obviously on 302 the data is not saved, so I don't know why the "if" statement is there.
302 response is a normal JIRA behavior, it is simply redirecting to the page that shows task info. Can you try to follow that redirect and capture html for the page you are being redirected to? David: could you please also summarize all of your proxy/network settings, and whether they're global (set via Preferences) or repository specific? of course :) these things are not always as simple as they seem (302 was not intuitive to me initially, but it makes sense now - redirect after post) My network settings are straightforward. No proxies or special settings, just a simple network connection. I'll attempt to reproduce tomorrow and output the response to the console. This is the results of the post. I'm going to try again, setting followRedirects to true on the post to see what the resulting page shows. Post result: 302 Date: Thu, 13 Sep 2007 17:07:54 GMT Server: Apache/2.0.59 (FreeBSD) mod_ssl/2.0.59 OpenSSL/0.9.7e-p1 mod_jk/1.2.21 Location: https://portal.makesolutions.ca/jira/secure/EditIssue.jspa Content-Length: 379 Connection: close Content-Type: text/html; charset=iso-8859-1 response body: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>302 Found</title> </head><body> <h1>Found</h1> <p>The document has moved <a href="https://portal.makesolutions.ca/jira/secure/EditIssue.jspa">here</a>.</p> <hr> <address>Apache/2.0.59 (FreeBSD) mod_ssl/2.0.59 OpenSSL/0.9.7e-p1 mod_jk/1.2.21 Server at portal.makesolutions.ca Port 80</address> </body></html> In your repository settings did you use http://... or https:// for the repository url? So I tried again, and here's what I got: ************************************************************ POST '/jira/secure/EditIssue.jspa' result: 302 Request Headers: Content-Type: application/x-www-form-urlencoded; charset=utf-8 User-Agent: Eclipse Mylyn (HttpClient/3.0.1) Host: portal.makesolutions.ca Cookie: $Version=0; JSESSIONID=********************************; $Path=/jira Content-Length: 8337 Response Headers: Date: Thu, 13 Sep 2007 17:23:31 GMT Server: Apache/2.0.59 (FreeBSD) mod_ssl/2.0.59 OpenSSL/0.9.7e-p1 mod_jk/1.2.21 Location: https://portal.makesolutions.ca/jira/secure/EditIssue.jspa Content-Length: 379 Connection: close Content-Type: text/html; charset=iso-8859-1 response body: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>302 Found</title> </head><body> <h1>Found</h1> <p>The document has moved <a href="https://portal.makesolutions.ca/jira/secure/EditIssue.jspa">here</a>.</p> <hr> <address>Apache/2.0.59 (FreeBSD) mod_ssl/2.0.59 OpenSSL/0.9.7e-p1 mod_jk/1.2.21 Server at portal.makesolutions.ca Port 80</address> </body></html> ************************************************************ GET '/jira/secure/EditIssue.jspa' result: 500 Request Headers: User-Agent: Eclipse Mylyn (HttpClient/3.0.1) Host: portal.makesolutions.ca Cookie: $Version=0; JSESSIONID=********************************; $Path=/jira Response Headers: Date: Thu, 13 Sep 2007 17:23:33 GMT Server: Apache/2.0.59 (FreeBSD) mod_ssl/2.0.59 OpenSSL/0.9.7e-p1 mod_jk/1.2.21 Content-Length: 5126 Connection: close Content-Type: text/html;charset=utf-8 response body: <html><head><title>Apache Tomcat/5.5.20 - Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 500 - </h1><HR size="1" noshade="noshade"><p><b>type</b> Exception report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>The server encountered an internal error () that prevented it from fulfilling this request.</u></p><p><b>exception</b> <pre>org.apache.jasper.JasperException: Issue with id 'null' or key 'null' could not be found in the system org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:512) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:395) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) com.opensymphony.module.sitemesh.filter.PageFilter.writeDecorator(PageFilter.java:173) com.opensymphony.module.sitemesh.filter.PageFilter.applyDecorator(PageFilter.java:158) com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:62) com.atlassian.jira.web.filters.SitemeshExcludePathFilter.doFilter(SitemeshExcludePathFilter.java:38) com.atlassian.seraph.filter.SecurityFilter.doFilter(SecurityFilter.java:182) com.atlassian.seraph.filter.LoginFilter.doFilter(LoginFilter.java:181) com.atlassian.util.profiling.filters.ProfilingFilter.doFilter(ProfilingFilter.java:132) com.atlassian.jira.web.filters.JIRAProfilingFilter.doFilter(JIRAProfilingFilter.java:16) com.atlassian.jira.web.filters.ActionCleanupDelayFilter.doFilter(ActionCleanupDelayFilter.java:41) com.atlassian.jira.web.filters.RequestCleanupFilter.doFilter(RequestCleanupFilter.java:49) com.atlassian.johnson.filters.JohnsonFilter.doFilter(JohnsonFilter.java:91) com.atlassian.jira.web.filters.gzip.GzipFilter.doFilter(GzipFilter.java:68) com.atlassian.core.filters.AbstractEncodingFilter.doFilter(AbstractEncodingFilter.java:37) com.atlassian.jira.appconsistency.db.DatabaseCompatibilityEnforcerFilter.doFilter(DatabaseCompatibilityEnforcerFilter.java:25) </pre></p><p><b>root cause</b> <pre>com.atlassian.jira.exception.IssueNotFoundException: Issue with id 'null' or key 'null' could not be found in the system com.atlassian.jira.web.action.issue.AbstractIssueSelectAction.getIssue(AbstractIssueSelectAction.java:89) com.atlassian.jira.web.action.issue.AbstractIssueSelectAction.getIssueObject(AbstractIssueSelectAction.java:347) com.atlassian.jira.web.action.issue.AbstractIssueSelectAction.getSummaryIssue(AbstractIssueSelectAction.java:367) org.apache.jsp.decorators.issuesummary_jsp._jspService(issuesummary_jsp.java:184) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:334) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) com.opensymphony.module.sitemesh.filter.PageFilter.writeDecorator(PageFilter.java:173) com.opensymphony.module.sitemesh.filter.PageFilter.applyDecorator(PageFilter.java:158) com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:62) com.atlassian.jira.web.filters.SitemeshExcludePathFilter.doFilter(SitemeshExcludePathFilter.java:38) com.atlassian.seraph.filter.SecurityFilter.doFilter(SecurityFilter.java:182) com.atlassian.seraph.filter.LoginFilter.doFilter(LoginFilter.java:181) com.atlassian.util.profiling.filters.ProfilingFilter.doFilter(ProfilingFilter.java:132) com.atlassian.jira.web.filters.JIRAProfilingFilter.doFilter(JIRAProfilingFilter.java:16) com.atlassian.jira.web.filters.ActionCleanupDelayFilter.doFilter(ActionCleanupDelayFilter.java:41) com.atlassian.jira.web.filters.RequestCleanupFilter.doFilter(RequestCleanupFilter.java:49) com.atlassian.johnson.filters.JohnsonFilter.doFilter(JohnsonFilter.java:91) com.atlassian.jira.web.filters.gzip.GzipFilter.doFilter(GzipFilter.java:68) com.atlassian.core.filters.AbstractEncodingFilter.doFilter(AbstractEncodingFilter.java:37) com.atlassian.jira.appconsistency.db.DatabaseCompatibilityEnforcerFilter.doFilter(DatabaseCompatibilityEnforcerFilter.java:25) </pre></p><p><b>note</b> <u>The full stack trace of the root cause is available in the Apache Tomcat/5.5.20 logs.</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/5.5.20</h3></body></html> The repository URL starts with https:// It seems that we are not posting to the edit page expected by the repository. Just to make sure: the full repository URL should be https://portal.makesolutions.ca/jira/. If that is the case the repository is redirecting to to the same page so I am not sure how to fix that. Eugene, we should probably not only check for the 302 redirect code but also make sure the redirect location matches the one we expect in order to determine if a post was successful. Created attachment 78354 [details]
the results of a post followed by a get, this time with the issue id specified in the get
Attached the results of a post, followed by a get to the specified Location, but this time with the issue id specified in the GET.
From what I can see there are some errors displayed on the page. If you search for class="errMsg" in the results, there are several error messages there. My guess is that these errors may be related to the previous POST, since when I try the same GET URL in my browser with the same issue id (but obviously without the same cookie and session) the error messages do not appear.
Created attachment 78357 [details] My repository settings As you can see in the attached screenshot, the repository URL is specified as https://portal.makesolutions.ca/jira (In reply to comment #21) > From what I can see there are some errors displayed on the page. If you search > for class="errMsg" in the results, there are several error messages there. My > guess is that these errors may be related to the previous POST, since when I > try the same GET URL in my browser with the same issue id (but obviously > without the same cookie and session) the error messages do not appear. I am not sure about that. The errors should not be persisted in the session. It looks more like a separate request which is lacking most fields. I am suspecting that something goes wrong with the URL. From the response headers it looks like the requests go through Apache and mod_jk which might mangle the URL in funny ways. It would be helpful if you could edit an issue through a web browser and take a look at the request/response headers. Created attachment 78379 [details]
a screenshot of the browser-based request headers
I'm not sure if I agree with your assessment. A successful edit redirects to the /jira/browse/ticket URI, whereas an edit submission with errors redirects to the /jira/secure/EditIssue.jspa URI.
Find attached a screenshot of the request/response headers of a successful edit submission via browser.
I have only verified with more recent versions of JIRA all of which behave as I described in comment 23. Take a look at this page for instance which displays a bunch of errors that are not a result of a post: http://mylyn.eclipse.org/jira-enterprise-3.9/secure/EditIssue.jspa?id=13084 I could be that we pick up the wrong http://... repository URL when following the redirects during login resulting in the redirect to https://... when posting the issue update. Eugene the login redirects are traceable somehow, right? (In reply to comment #25) > Eugene the login redirects are traceable somehow, right? I am hesitating to add Eclipse tracing to jira.core to make it possible to use it as a standalone library. David, if you still have your Eclipse environment setup you can step through the code yourself. The login is done in JiraWebSession. If you set a break point in line 122 you should be able to tell from the url variable if you are being redirected to http. You can also set a break point in line 111 of JiraWebIssueService and check if baseUrl is correct. Also note this report which might have the same cause: bug 203052. Good call on this one. I've added some System.out logging of the login sequence code and here's what I see: Opening an issue for edit (before the save) generates the following login sequence: Login attempt 0 to https://portal.makesolutions.ca/jira/login.jsp redirect location: http://portal.makesolutions.ca/jira/success Login attempt 1 to http://portal.makesolutions.ca/jira/login.jsp redirect location: https://portal.makesolutions.ca/jira/login.jsp Login attempt 2 to https://portal.makesolutions.ca/jira/login.jsp redirect location: http://portal.makesolutions.ca/jira/success Pressing the submit button results in the following login sequence: Login attempt 0 to https://portal.makesolutions.ca/jira/login.jsp redirect location: http://portal.makesolutions.ca/jira/success Login attempt 1 to http://portal.makesolutions.ca/jira/login.jsp redirect location: https://portal.makesolutions.ca/jira/login.jsp Login attempt 2 to https://portal.makesolutions.ca/jira/login.jsp redirect location: http://portal.makesolutions.ca/jira/success Looks like JIRA is incorrectly sending redirect locations that jump protocols back and forth. I guess there are a few issues here: - Any tips for users to correct this problem? (Is it a misconfigured JIRA instance?) - Mylyn should detect this problem and warn the user of a possible JIRA misconfiguration - *maybe* Mylyn should always use the protocol specified in the repository settings. At the very least, Mylyn should prevent information from going over HTTP if HTTPS is specified. BTW, do you have https or http in Mylyn's JIRA settings for your repository? (In reply to comment #30) > BTW, do you have https or http in Mylyn's JIRA settings for your repository? > https. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=202834#c22 for more details. Thanks for debugging this. > Login attempt 0 to https://portal.makesolutions.ca/jira/login.jsp > redirect location: http://portal.makesolutions.ca/jira/success > Login attempt 1 to http://portal.makesolutions.ca/jira/login.jsp > redirect location: https://portal.makesolutions.ca/jira/login.jsp > Login attempt 2 to https://portal.makesolutions.ca/jira/login.jsp > redirect location: http://portal.makesolutions.ca/jira/success It might be that your repository is configured with http but the web-server redirects to https. Could you contact your administrator to check the JIRA settings under Administration -> General Configuration: Base URL? > - Any tips for users to correct this problem? (Is it a misconfigured JIRA > instance?) See above. > - Mylyn should detect this problem and warn the user of a possible JIRA > misconfiguration I have been meaning to do that as part of the repository validation in the properties dialog: bug 186379 . I have scheduled it for the next release. > - *maybe* Mylyn should always use the protocol specified in the repository > settings. At the very least, Mylyn should prevent information from going over > HTTP if HTTPS is specified. Yes, that needs to be checked. I didn't expect that potential misconfiguration of repositories could lead to redirects to http when implementing the login code. (In reply to comment #32) > > - Mylyn should detect this problem and warn the user of a possible JIRA > > misconfiguration > I have been meaning to do that as part of the repository validation in the > properties dialog: bug 186379 . I have scheduled it for the next release. That sounds like a great idea. If we could detect those redirect and show a warning when validating repository settings. No problem. Implementing repository integration via web form POSTing looks far more complicated/fragile than one would initially assume. Kudos for getting it working. I'm guessing that JIRA's XML-RPC interface is not sufficient for Mylyn's needs. Perhaps that should be investigated as a more favorable integration strategy. Just FYI, the JIRA base URL (in the JIRA settings on the server) is set to https://portal.makesolutions.ca/ I'll ask our IT guys to look into this problem further. David (In reply to comment #32) > Thanks for debugging this. > > > Login attempt 0 to https://portal.makesolutions.ca/jira/login.jsp > > redirect location: http://portal.makesolutions.ca/jira/success > > Login attempt 1 to http://portal.makesolutions.ca/jira/login.jsp > > redirect location: https://portal.makesolutions.ca/jira/login.jsp > > Login attempt 2 to https://portal.makesolutions.ca/jira/login.jsp > > redirect location: http://portal.makesolutions.ca/jira/success > > It might be that your repository is configured with http but the web-server > redirects to https. Could you contact your administrator to check the JIRA > settings under Administration -> General Configuration: Base URL? > > > - Any tips for users to correct this problem? (Is it a misconfigured JIRA > > instance?) > > See above. > > > - Mylyn should detect this problem and warn the user of a possible JIRA > > misconfiguration > > I have been meaning to do that as part of the repository validation in the > properties dialog: bug 186379 . I have scheduled it for the next release. > > > - *maybe* Mylyn should always use the protocol specified in the repository > > settings. At the very least, Mylyn should prevent information from going over > > HTTP if HTTPS is specified. > > Yes, that needs to be checked. I didn't expect that potential misconfiguration > of repositories could lead to redirects to http when implementing the login > code. > > Implementing repository integration via web form POSTing looks far more > complicated/fragile than one would initially assume. Kudos for getting it > working. I'm guessing that JIRA's XML-RPC interface is not sufficient for > Mylyn's needs. Perhaps that should be investigated as a more favorable > integration strategy. Thanks. The JIRA code is based on an external contribution that uses a mixed approach of SOAP and POSTing. We have spent significant amounts of time getting that to work across JIRA versions and the wide variety of repository configurations that are used. If anyone contributed a rewrite that supported the same feature set and was entirely based on SOAP or XML-RPC I would happily consider it as a replacement for all the HTML parsing and redirection handling code :). > Just FYI, the JIRA base URL (in the JIRA settings on the server) is set to > https://portal.makesolutions.ca/ Thanks for verifying. I'll consider bug 186379 for next week to hopefully get this issue fixed in time for 2.1. Remaining to be done here: - check redirect location returned after submit for correct URL I sat next to our IT guy and we looked into our server setup in detail. After some investigation this is what we discovered: - our apache server on HTTP port 80 was configured to forward all requests to our secure server - our apache server on HTTPS (port 443) was configured to talk to our Tomcat/JIRA instance using mod_jk and AJP/1.3 It was not easy to figure out, but the Tomcat side of the AJP connector was causing the problem as it was not propagating the fact that the connection was secure, nor the HTTPS connection port. Thus the application itself thought that it was on HTTP port 80, and thus all returned 302 locations were to http port 80, which would of course be caught by our HTTP server forwarding back to the HTTPS instance, and thus we see the ping-pong forwarding behaviour. So what we did to fix it is this: on our Tomcat server we configured the AJP/1.3 connector as follows: <Connector port="8009" secure="true" proxyHost="portal.makesolutions.ca" proxyPort="443" enableLookups="false" redirectPort="8443" protocol="AJP/1.3" /> This may be a bit "heavyweight", but it did the trick. Thanks for spending so much time helping with this one. Hopefully it'll help to improve Mylyn, and perhaps others can avoid such a problematic server configuration. Thank you for posting the results of the your configuration analysis, stepping through the code and all your feedback! It helped to uncover deficiencies in the redirect handling and status code verification of the JIRA connector which need to be addressed for the next release. I have added code to detect circular redirects that logs to the Eclipse error log. This should help to find the cause of similar problems more quickly in the future. Eugene, I am leaning towards disabling following redirects during login entirely and to rely on the URL that was determined during validation. Do you thing that is feasible? Implemented checking of redirect locations. This needs testing. Mik, could you please provide a dev build? Created attachment 78524 [details]
mylyn/context/zip
Steffen, can you please put David's summary somewhere to the faq? Wow, great detective work guys. Dev build will be available within 2 hours. (In reply to comment #40) > Steffen, can you please put David's summary somewhere to the faq? David: if possible it would be best if you had a moment to do this, since the summary originated from you. This should go into: http://wiki.eclipse.org/index.php/Mylyn_FAQ#Why_can.27t_I_connect.3F I have added a reference to this bug here: http://wiki.eclipse.org/index.php/Mylyn_FAQ#Why_do_I_get_errors_about_an_unexpected_redirect_when_submitting_an_issue.3F David, feel free to edit that entry. I've added some hints about the Tomcat server configuration to the wiki entry. Thanks! I got hit by this one again with a new JIRA installation. This time I had to also set the 'scheme' attribute on the connector configuration. See http://tomcat.apache.org/tomcat-6.0-doc/config/ajp.html for AJP connector options. |