| Summary: | User can appear "locked" in License Loop if they "decline". | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [WebTools] WTP Common Tools | Reporter: | David Williams <david_williams> | ||||
| Component: | wst.internet | Assignee: | Lawrence Mandel <lmandel> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | critical | ||||||
| Priority: | P2 | ||||||
| Version: | 0.7 | ||||||
| Target Milestone: | 1.0 M6 | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
David Williams
David, the option in the cache dialog to "ask about licenses I've previously declined" is off by default. Users must explicitly set this. The repeated requests are, as you expected, due to requests to cache different resources that are bound by the same license. As the cache has no knowledge of operation state it must prompt for all requests in the same operation, leading to many of the same dialog. WRT the two preferences you suggest for the license dialog, 1. "disable caching" - I think this makes sense. I'll investigate adding it to the dialog. Do you think a better option is to disable caching for resources that have a license associated with them? ie. Never prompt and never cache these resources. 2. "do not ask me about licenses for which I have disagreed" - This is the standard option. Users have to explicitly enable this function. I think a better solution is to never ask users about licenses they've disageed to and to add a licenses tab to the cache preference page that allows users to tweak their license agreements. On 1. your idea to have "disable caching for resources that have a license associated with them" is a good one, but maybe should be worded as "disable caching for resources that have a *known* license associated with them" ... since, technically, we do not really know is a license is associated or not ... we have a hot list somewhere? How do we (or uesrs, or ISV's add to that?) ... so if users wanted to be completely safe they'd still have to 'disable all caching'. On 2. a tweaking might be better, but I think this loop was caused by repeated requests for the *same* resource (the j2ee xsd). You know, there's lots of seperate pieces that get's involved in "create web project" and each of them want's the content model or j2ee model ... none of them know about the others. And, even though, as a user, I explicitly set the request to keep asking me ... I think most users would interpret that as one "ask me per transaction" from their point of view, not each time some little snippet of our code of ours happened to request it. I suppose the delux solution would be to have a "begin/end" transaction API on the cache .. but that's a sort of version 1.5 enhancement I won't even bother writiing up at this point. Actually, now that I think of it, instead of "begin/end" transaction ... maybe some "begin/end" session is more appropriate ... and could be done more transparently ... a "session" beginning each time Eclipse opens, or J2EE perspective opened ... or something. 1. It sounds like you're still of the opinion that the license page should have an option to disable caching entirely. I think that's probably the easiest to understand. ISV's can add licenses for resources using an extension point on the cache. 2. Do you think the behaviour of this preference should be changed to prompt once per Eclipse invocation? That means, the first time the license is encountered while running Eclipse you will be prompted but not again until Eclipse is shutdown and restarted. This preference was put in place to allow a user to agree to licenses they've previously disagreed to until a better license management page can be put in place. Do you think this preference can live as is in 0.7 with the goal of adding the license preference page post 0.7 or do you think it's critical to have the license page in 0.7? you asked "Do you think this preference can live as is in 0.7" ... I think the only thing 'critical' for .7 is that the user not get stuck in an infinite loop (ok, you and I know its not infinite, but it appears to be from an end-users perspective). You're idea of "once per Eclipse invocation" is maybe the easyest way to fix that - and I think used rare enough that it will not be inconvient for users. There are other prefernces in Eclipse that have the caveat "The workbench must be restarted before this takes effect" .... or something similar. OK. I'll go with the prompt once per Eclipse invocation as the easy fix for the "appears to be an infinite loop" problem with the cache licenses. Post 0.7 we can revisit creating a separate tab for managing licenses and lose this preference alltogether. Do you think the dialog should also have the disable caching checkbox at this point? As for "Do you think the dialog should also have the disable caching checkbox at this point?" ... I'm not sure from a pure usability point of view -- typcially any preference that effects a dialog's behavior should be available from the dialog (in addition to preferences) ... but its not critical for this 'infinite loop' problem, since at most they would only be asked once (per previously declined resources). I'm uping the priority to P2 as this very negatively affects the user experience and should be addressed in 0.7. Changing version to 0.7. Created attachment 24855 [details]
Patch that only prompts the user for license acceptance once per Eclipse invocation.
This patch changes the behaviour of the "prompt me for licenses to which I've
already disagreed" option. Instead of being prompted repeatedly this option
will now prompt once per Eclipse session.
David, please review and provide approval if you are satisfied. I've reviewed this and bug 103611 but had trouble confirming all was working as expxected. I'm quite sure I would only be asked once per session, whether I agreed or disagreed, and which ever choice I made, the cache kept filling up with stuff. So ... not sure if I messed up the patching and tests ... or if there's a logic bug somewhere. If you do not see this particular behavior, Lawrence, feel free to release the code and/or get others to test it as well. Even if released, I recommend extensive testing be several people, to make sure its working as they expect. David, can you add a comment listing what shows up in your cache? The only resources that are restricted by licenses at this point are resources from Sun. Yes (and, as feature request, that list of entries should be selectable so I can copy/paste :) Scenerio: use tomcat 5.0.28 (on linux). fresh workspace, first run (i.e. fresh "configuration area"). create a 2.4 dynamic web project, then create a 2.3 dynamic web project, then create a 2.2 dynamic web project. On the first creation, I'm given the license info and then "decline". That is the only time I am ever asked. What ends up in my cache is: http://java.sun.com/dtd/web-app_2_3.dtd http://java.sun.com/j2ee/dtds/web-app_2_2.dtd http://java.sun.com/xml/ns/j2ee/jsp_2_0.xsd http://www.w3.org/2001/XMLSchema.dtd http://www.w3.org/2001/datatypes.dtd http://www.w3.org/2001/xml.xsd The first three I'm surprised about since I "declined" (first time, was never asked again). The last three I'm surprised about because we provide those via catalog. So ... are these different bugs? Like I (tried) to say ... I *think* it is sort of working, just hard to verify. Ah, I see if I accept that first time, I am also given in my cache http://java.sun.com/xml/ns/j2ee/j2ee_1.4.xsd http://java.sun.com/xml/nsj2ee/web-app_2.4.xsd http://www.ibm.com/webservices/xsd/j2ee_web_services_client_1_1.xsd Hope this helps. Please open a bug for the copy/paste action from the cache. This is not essential and can be addressed post 0.7. The following two entries should not be cached if the license is declined. I've added these to bug 104066. http://java.sun.com/dtd/web-app_2_3.dtd http://java.sun.com/j2ee/dtds/web-app_2_2.dtd Bug 104066 also addresses http://java.sun.com/xml/ns/j2ee/jsp_2_0.xsd The following three entries are not in the XML catalog but should be. I've opened bug 104241 requesting that they be added to the catalog. http://www.w3.org/2001/XMLSchema.dtd http://www.w3.org/2001/datatypes.dtd http://www.w3.org/2001/xml.xsd Fix committed and released 20050718, 1:50pm EDT. Thanks for clarifying what I was seeing, Lawrence. And, I meant the copy/paste as a tiny joke. :) I suspect we have more important things to do. Thanks again for getting this running. Thanks for reporting and working with me to reproduce the problem :-) As for the copy it really should be there. I hate it when I can't copy items in a list. There are definitely bigger fish to fry but if I find an extra few minutes I'll put it in for 1.0 anyway. Closing bug. |