Bugzilla – Full Text Bug Listing
| Summary: | Service Project not updated after selecting service definition | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [WebTools] WTP Webservices | Reporter: | Shane Clarke <shane_clarke> | ||||
| Component: | jst.ws | Assignee: | Eric Peters <ericdp> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Kathy Chan <kathy> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | oisin.hurley, pmoogk, shane_clarke | ||||
| Version: | 3.0 | ||||||
| Target Milestone: | 3.1 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Thanks for this patch as well! We'll look at putting it into WTP for the V3.1 release. Hi Eric, Can you review and test Shane's patch for this defect. Thanks. Hi Shane, Thanks for proposing this patch, sorry it took me a while to review. The current behavior is working by design, let me explain. The behavior you propose (default the service project to where the artifact was chosen from) makes sense for Bottom up web services and is the behavior e.g. for Bottom up Java Bean web service. I do not think this behavior is the best option for Top down web services, reasons are: 1. We have chosen default values for fields in the first page of the wizard based on a combination of web services preferences and initial selection object that are compatible with each other. If we then change the project based on WSDL location we may indeed put them in an error state (e.g. wsdl is in a project that is not one a valid service project). It is better to have the user put themselves in an error state by explicitly choosing the invalid service project. 2. Also related to 1. somewhat, if we change the project as proposed without changing the EAR project (for adopters some servers/ws types require an EAR) we may be creating a new project-EAR association that may be unexpected by the user. Better to let the user change the project via the project selection dialog which will also change the EAR to one associated with the project. 3. Different from bottom up web services, the object selection may not reside in a project at all but rather a URL on the web somewhere (e.g. Top down Java bean web service), therefore does not make as much sense to change the project from the defaults when a new/different object is selected. 4. For Bottom up web services the selection object you are choosing to create the web service from generally must reside in the selected service project, otherwise you will get an error in the wizard as this will not work at runtime. 5. Also for bottom up, the fields on the first page of the wizard (WS runtime, Server) are strongly tied to the Selection object- only some combinations will work with a given selection object. Therefore after you select the object the fields below (WS runtime, SXerver) may change to ensure the resultant web service can function (i.e. there are no validation errors on the page). Hope this design and rationale make sense to you, please let us know if there is a compelling reason to change existing behavior we are not aware of and we can discuss further. Thanks, This bug has been in resolved state for a while (with resolution set to Invalid, Duplicate, wontfix or workforme). Please verify that you're OK with this resolution and close the defect. Please re-open if you don't agree with this assessment. If this is not verified within 2 weeks, we'll be verifying the bug on your behalf. Thanks! Thanks guys for the detailed explanation. Explanation is fine. Closing. |
Created attachment 109296 [details] Updates service project name after selection Build ID: I20080617-2000 Steps To Reproduce: 1. Create two dynamic web projects. "a" and "b". Each project contains a wsdl file. 2. Select the "b" project and open the web service wizard. 3. Select the browse button and navigate to the location of the wsdl file in project "a". Hit OK. The service project still shows "b". Progressing with the Web Service wizard will lead to code being generated into the "b" project. More information: Tested against HEAD 6th August 08. callObjectTransformation() in ServerWizardWidget is called after modifying the text field or after browsing for a service definition. setProject is called here and the 'project_' variable is updated. But the 'serviceProjectName_' variable isn't. Attaching patch.