Community
Participate
Working Groups
Steps to reproduce: 1. Create a trac ticket and attach a Mylyn task context. 2. Switch to another work space. 3. Open the above ticket (using a query) etc. 4. Retrieve task context. 5. Popup: "No local task context exists. Retrieve from repository" 6. Answer: "Yes" 7. Selection dialog to show the list of task context attachments appears 8. Goto step 4 Only way to break out of this loop is to answer "No" if asked whether to retrieve context. Tried to workaround by creating a dummy task context first. But this lead to the same behaviour, in addition, the dummy context was cleared. In the consequence, this disables the retrieve context from Trac for me. Therefore "major" Would be happy to have any workarounds at least.
Thanks for reporting this is problem. It is most likely caused by a failed download. The wizard will reactivate the task when closed which triggers the context check again.
(In reply to comment #1) > Thanks for reporting this is problem. It is most likely caused by a failed > download. The wizard will reactivate the task when closed which triggers the > context check again. Actually, I experienced this issue already some weeks ago, but did not take the time to report it. Now, as we moved from the Web template connector to the Trac connector, we want to also use the context sharing features. In addition, I found that there is currently no workaround if it happens. So please provide me with some ideas how I could debug / correct this issue. What do mean by failed download? We connect locally in our intranet to the trac system. Of course, I would appreciate if the correction would appear in the "weekly" (not "dev") builds soon. If you need more input or a TCP level trace / dump to debug, please tell me what you need. Cheers, Jörg
Is there an error in the log? For some reason the context is not found when the task is activated in step 4 triggering a prompt to download the context again. So far I have not been able to reproduce this, e.g. with this task: http://mylyn.eclipse.org/tractest/ticket/18 . With version of Trac are you using?
(In reply to comment #3) > Is there an error in the log? For some reason the context is not found when the > task is activated in step 4 triggering a prompt to download the context again. No, I cannot see any error in the log. Just some unrelated errors from groovy and some breakpoint manager. > So far I have not been able to reproduce this, e.g. with this task: > http://mylyn.eclipse.org/tractest/ticket/18 . That task works as expected. >With version of Trac are you using? We use 0.10.4 on a Ubuntu Gutsy or Hardy system as a Debian package. For the XML_RPC we use plugin version 0.1 If you suspect an error retrieving the task, at least the error handling should be improved.
Hi Steffen, please, could I drag your attention to this bug: How could I find out what the reason for my error is? Perhaps you could improve the error handling to show any problems on retrieving the context? Thanks, Jörg
I am having the same problem after moving a bugzilla backend database to another machine. Having an IP number based addressing scheme, I notice that the new machine has another IP address than the old machine with the bugzilla database and I am wondering if it can have something to do with that, noting that in the "mylyn-context.zip" file, the xml filename seems to be the url of the bugzilla database machine (http%3A%2F%2F147.214.208.36%3A8080-22) in my case. I unzipped the .xml file an rezipped it with the ip-address changed but this didnt seem to help so maybe it is a bad lead... I can synchronize the tasks fine, but retrieving the context I get the repeating "No local task context exists. Retrieve from repository". Mylyn Tasks Core 2.3.2.v20080402-2100 Mylyn Context Core 2.3.2.v20080402-2100 Mylyn IDE UI 2.3.2.v20080402-2100 Mylyn Bugzilla Connector UI 2.3.2.v20080402-2100 I don't see eny errors in the Eclipse Error Log that seems obviously related to this either. Cheers! -Leif
Joerg, Leif, could check if the context file is actually created in the workspace/.metadata/.mylyn/contexts/ folder? Which OS are you using? The file name is based on the URL of the task repository and task id. Mylyn always uses the url that was entered in the task repository properties which could be different from the actual URL of the repository.
Hi Steffen, First, the bugzilla database is migrated from a Windows 2000 machine to a Windows Vista machine. So right now it is on a Windows Vista machine. The machine with eclipse/mylyn is the exact same machine in both cases a Suse Linux Enterprise 10 machine. In my workspace/.metadata/.mylyn/contexts/ there are only two files activity.xml.zip and local-1.xml.zip. I can add that using the bugzilla webinterface I can fecth the attached context file and open it manually. Cheers! -Leif
Leif, can you check the permissions of the context folder on the new machine? Is it writeable by the user running Eclipse?
OK, I did download the Mylyn context manually and found that its name is: http%3A%2F%2Ftsystem%2Ftrac%2FGlox7-67.xml which refers to the URL "http://tsystem/trac/Glox7-67.xml" The Id attribute stored in this XML file is also "Id="http://tsystem/trac/Glox7-67". But the URL "http://tsystem/trac/Glox7" refers to the old name of the trac installation. Meanwhile, we have renamed it to "http://trac/trac/development", while "http://tsystem/trac/development" would also work. In principal, some people could have the tsystem URL in their repository configuration, others the trac URL. If the different URLs can cause the context loading to fail, I still wonder why no error message is displayed. Moreover, if I try to load a context and the loading fails, my previous context is also cleared. From home, I access the Trac repository from a slightly different URL with another port. This would also lead to a different context name. If this is the cause of all these issues, do you see anyway to use another mechanism or ask the user if he wants to relocative the alien context to match the current path?
Now I did some experiments: 1. Renamed only the Id inside the XML files and attached the context with the description "mylyn/context/zip" --> same result 2. Additionally renamed the name of the XML file to match the repository URL --> this worked 3. Did not try to just rename the file while leaving the Id alone. As I said previously, I sometimes the repository from a different URL (at least different port). Also some people access it as "tsystem", others as "trac" (both the same IP). Therefore, chances are big to get more such errors. Now I wonder why the repository ID is so tightly coupled with the host and port? Options are: - Make the repository ID configurable, suggest the current scheme as default - Allow to migrate alien contexts (let the user choose whether he want to ignore the different URL) What do you think? Could this restriction relaxed at bit quit soon since this prevented us from using the context attachments at all?
Thanks for analyzing the bug Joerg! Using the full handle which includes the repository url in the context zip file can indeed break sharing of contexts when different urls are used to access the repository. In addition the code should be made robust to validate the file when it is downloaded to inform the user of any failures. Mik, what are your thoughts on this?
I would suggest the following steps / options. 1. Provide a check / error message to alert the user. 2. Extend 1. to allow the user to accept that differing URL and apply the context anyway. 3. Provide a configuration dialog (per repository) to add task URL aliases. Point 3. is motivated by my use case, that I access the trac repo using a different host/port combination because I have to go over a SSH tunnel from home. I would really appreciate if points 1. (and 2.) could be implemented rather soon.
Hi Steffen, You say "Using the full handle which includes the repository url in the context zip file can indeed break sharing of contexts when different urls are used to access the repository." does this in some way imply that there is some kind of workaround that me and Jörg can use until this bug is resolved? Can we configure our systems in some way to not use "full handle" and get it to work temporarily? Cheers! -Leif
Sorry, I can't think of a workaround other than manually renaming the file in the zip which is not practical. The fact that Mylyn uses the full handle is an internal implementation detail which probably needs to be changed to fix this bug. I'll raise this on Thursday's conference call.
I see! Thanks for the quick reply! Cheers! -Leif
(In reply to comment #15) > [...] The fact that Mylyn uses the full handle is an > internal implementation detail which probably needs to be changed to fix this > bug. I'll raise this on Thursday's conference call. Steffen, what is the outcome of raising this issue in the last conference call? What are the next steps? Thanks, Jörg
The discussion on the call indicated that the current implementation is expected to handle the case correctly where a context is accessed with a different url but there appears to be a bug in the code. Shawn, will you have to time to look into fixing this?
I can have a look into this later this week.
It looks like this broke between 2.0.0 and 2.1.0. Right now, it tries to match the name of the internal entry in zip with the handle of the task that is trying to be loaded. This means that if the context file in the zip file does not have the same identifier, it will not get loaded (as this bug describes). This seems to have been added as a part of some import/export functionality. Mik, Steffen, what would the desired fall back be in this scenario? One potential solution: * try to find perfect match * if one exists, use it * if one doesn't exist, try to make based on task id from the handle Or should we go with a simpler (or more complicated) solution?
The code in SaxContextReader should fall back to something that is similar to LocalContextStore.getFirstContextHandle(). Ideally there would only be a single implementation.
Shawn, I'll try to take a pass at fixing this in the next few days.
Thanks Steffen, I havent been able to get time to look into this and don't know if I will before the new year.
(In reply to comment #22) > Shawn, I'll try to take a pass at fixing this in the next few days. > I also have the same problem, and if you need any help from a user experiencing it, let me know.
Created attachment 121323 [details] fix
I have committed the attached patch. Shawn, can you review?
Cool. I am looking forward to see this in the next weekly build. Will this be this week? Thanks, Jörg
Steffen, thanks for getting to this. The patch looks right to me. One thing I was wondering was whether we should be looking for the current contexts handle, and if we cant find it, then use the first context handle in the zip? This would ensure that if a zip had multiple contexts, it would choose the right one if it exists in the file. This would complicate the code a bit more and may not be needed. What do you think?
I have triggered a build, it should be available from the weekly update site in a few hours. The code should check for a perfect match first and then fall back to the first context handle (the first call to readContext() retuns null in that case).
Right, I see that now. Sorry I missed that.
I am marking this bug resolved. Please reopen if you still experience the problem with weekly builds >=I20081231-0000.
