Bug 75410 - [customization] WS client app code not refactored when package is changed
[customization] WS client app code not refactored when package is changed
Status: VERIFIED FIXED
Product: webservices
Classification: Unclassified
Component: Customization
5.x
All All
: P2 (vote)
: 6.x
Assigned To: Milan Kuchtiak
issues@webservices
:
: 81751 (view as bug list)
Depends on: 105645
Blocks:
  Show dependency treegraph
 
Reported: 2006-04-24 13:51 UTC by Lukas Jungmann
Modified: 2007-10-16 21:51 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lukas Jungmann 2006-04-24 13:51:14 UTC
-create new web project
-create some ws client in it
-call some ws operation eg. from servlet
-go to WSDL cust. dialog and change there package name of ws client

=> "new client" is generated, OK, but user cannot clean & build project because
of  usages of the old client (which is now not being re-built) - we can probably
reuse some refactoring capabilities here to prevent such thing
Comment 1 Roderico Cruz 2006-04-24 20:25:35 UTC
Changing the Summary field to reflect a more precise description of this bug.
The problem here is that when the user customizes the client wsdl, the user may
have previously written application code based on the old wsdl->Java mappings.
Comment 2 Roderico Cruz 2006-04-29 06:14:03 UTC
A warning is now displayed whenever the user customizes the wsdl, stating that
user application code may have to be changed to keep up with the code generation
changes.
Comment 3 Roderico Cruz 2006-06-15 05:19:53 UTC
When the package has been changed using the customizer, user code should be
refactored to reflect the change in the generated classes.
Comment 4 Roderico Cruz 2006-07-19 00:52:51 UTC
We tried to use the Refactoring API to fix this but ran into technical problems.
As a solution, Lukas Jungmann has agreed to just display a warning (already
implemented) whenever the wsdl for a client is customized, and to change this
into an enhancement for future a release.
Comment 5 Lukas Jungmann 2006-08-03 12:08:24 UTC
*** Issue 81751 has been marked as a duplicate of this issue. ***
Comment 6 Lukas Jungmann 2007-04-25 17:50:07 UTC
Refactoring API itself should be rewritten in 6.0, so we should try to fix this
for 6.0.
Comment 7 Milan Kuchtiak 2007-08-09 14:48:28 UTC
I'll try to fix this.
Comment 8 Milan Kuchtiak 2007-08-13 14:46:38 UTC
package name refactoring requires package folder to be on source classpath.
Comment 9 Milan Kuchtiak 2007-09-10 17:37:30 UTC
I'll try to implement a specific ClassPathProvider for generated java artifacts recommended by Tomas Zezula.
Comment 10 Milan Kuchtiak 2007-09-19 16:48:36 UTC
The implementation has started. Requires also some fixes in Java SE Platfiorm module and Refactoring module.
I am waiting for these changes.
Meanwhile, I started with implementation of a special ClassPathProvider for generated java artifacts.
Comment 12 Milan Kuchtiak 2007-09-21 10:39:28 UTC
To explain the previous changes in web project :

The changes are necessary to enable specify classpath for sources generated outside the project sources (avaiable
through project.getLookup().lookup(Sources.clsss)). Specifically, I mean for sources generated into build directory by
wsimport, wsgen etc. Otherwise, we are not able to implement refactoring for those source files.
Comment 17 Tomas Zezula 2007-09-21 17:49:24 UTC
J2SEProject part:

RCS file: /cvs/java/j2seproject/src/org/netbeans/modules/java/j2seproject/ClassPathProviderMerger.java,v
done
Checking in src/org/netbeans/modules/java/j2seproject/ClassPathProviderMerger.java;
/cvs/java/j2seproject/src/org/netbeans/modules/java/j2seproject/ClassPathProviderMerger.java,v  <-- 
ClassPathProviderMerger.java
initial revision: 1.1
done
Checking in src/org/netbeans/modules/java/j2seproject/J2SEActionProvider.java;
/cvs/java/j2seproject/src/org/netbeans/modules/java/j2seproject/J2SEActionProvider.java,v  <--  J2SEActionProvider.java
new revision: 1.60; previous revision: 1.59
done
Checking in src/org/netbeans/modules/java/j2seproject/J2SEProject.java;
/cvs/java/j2seproject/src/org/netbeans/modules/java/j2seproject/J2SEProject.java,v  <--  J2SEProject.java
new revision: 1.95; previous revision: 1.94
done
Checking in src/org/netbeans/modules/java/j2seproject/classpath/J2SEProjectClassPathModifier.java;
/cvs/java/j2seproject/src/org/netbeans/modules/java/j2seproject/classpath/J2SEProjectClassPathModifier.java,v  <-- 
J2SEProjectClassPathModifier.java
new revision: 1.4; previous revision: 1.3
done
Checking in test/unit/src/org/netbeans/modules/java/j2seproject/classpath/SourcePathImplAddonsTest.java;
/cvs/java/j2seproject/test/unit/src/org/netbeans/modules/java/j2seproject/classpath/SourcePathImplAddonsTest.java,v  <--
 SourcePathImplAddonsTest.java
new revision: 1.2; previous revision: 1.1
done
Checking in test/unit/src/org/netbeans/modules/java/j2seproject/classpath/SourcePathImplementationTest.java;
/cvs/java/j2seproject/test/unit/src/org/netbeans/modules/java/j2seproject/classpath/SourcePathImplementationTest.java,v
 <--  SourcePathImplementationTest.java
new revision: 1.10; previous revision: 1.9
done
Comment 19 Tomas Zezula 2007-09-26 20:58:17 UTC
Checking in src/org/netbeans/modules/java/j2seplatform/platformdefinition/DefaultClassPathProvider.java;
/cvs/java/j2seplatform/src/org/netbeans/modules/java/j2seplatform/platformdefinition/DefaultClassPathProvider.java,v 
<--  DefaultClassPathProvider.java
new revision: 1.14; previous revision: 1.13
done
Checking in test/unit/src/org/netbeans/modules/java/j2seplatform/platformdefinition/DefaultClassPathProviderTest.java;
/cvs/java/j2seplatform/test/unit/src/org/netbeans/modules/java/j2seplatform/platformdefinition/DefaultClassPathProviderTest.java,v
 <--  DefaultClassPathProviderTest.java
new revision: 1.6; previous revision: 1.5
done
Comment 21 Lukas Jungmann 2007-10-16 21:51:14 UTC
v.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo