Community
Participate
Working Groups
Opening this bug to track an issue discovered from bug 235932. In that bug, a fix was made so that the Web service wizard will respect the "Overwrite files without warning" setting on the first page of the wizard. However, making the fix exposes a deeper problem which is the setting on the wizard actually changes the global preference setting. This problem is found late in 3.0 cycle and a proper fix to decouple the logic not only requires change in the core framework, but we also need to coordinate with adopters because there's code that reads the setting directly from preferences. Hopefully we can tackle this fix post 3.0.
Created attachment 104400 [details] prototype fix *This patch is only a prototype* This patch shows how we can pass-around a copy of the preference settings to be used during the wizard flow. However, in order for the fix to work we also need to make sure all adopter code retrieves the setting from the command framework's enviroment rather than going to the preference directly. This fix ONLY includes the changes necessary to make Axis scenario work.
*** Bug 225369 has been marked as a duplicate of this bug. ***
Continuing from #235942 >> Let's continue future discussions regarding this issue in bug 236523. >> I agree with you completely that the preference setting should not be touched during the wizard flow. >> ... we also need to ensure we do not break adopter's code, etc. I understand. I think we're in agreement. Thanks, -Ken
Sorry, that should have said from Bug #235932.
Created attachment 105068 [details] patch This patch has minor differences with prototype fix.
Patch committed and released to WTP 3.0.1 as v200806181924. The only change that's not committed is the change to JavaMerger. We need to discuss what's the best way to handle that. Once we desided on that, we'll open a defect to address that specific problem.
*** Bug 235932 has been marked as a duplicate of this bug. ***
Note on the JavaMerger: In JavaMerger I'm purposely forcing overwrite to true using a TransientResourceContext. The reason is because when the axis emitter generates the skeleton file, it is first generated to a temp location and copied back to the workspace. So at this point there would already be a prompt to overwrite the file, and the skeleton merge code will run only if the user answers yes for the prompt. Secondly, skeleton merge is controlled by a separate preference option. Therefore, if the users answers yes to overwrite and skeleton merge option is enabled, it would be redundant to prompt the user again. I've discuss this with Kathy and agree that this is the correct behaviour.
Thanks for the clarification, Andrew! I've committed Andrew's original patch for JavaMerger. I've released it to WTP 3.0.1 as v200806191512.
Verified, closing.
