You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 5, 2019. It is now read-only.
A DESCRIPTION OF THE REQUEST :
We use wsimport via a Maven plugin that generates client stubs for webservices we use in our project. The code generation is done automatically as part of our build.
Would it be possible to have an option to prefix packages of generated sources for a specific WSDL rather than only using the namespaces?
For ex. service1.wsdl is in NS 'ws1' and has a schema in NS 'x'. service2.wsdl is in NS 'ws2' and has a schema in NS 'y'. The option in wsimport would then allow to specify a prefix for the entire WSDL. If we would choose 'service1' as prefix for the first WSDL and 'service2' as prefix for the second WSDL, the code generated would respectively be in package: 'service1.x....' (for the data bindings) and 'service1.ws1....' (for the service bindings). Likewise, the code for service2 would be in package 'service2.y' and 'service2.ws2'. Note that the remainder of the package consists out of the original NS as before, only it is prefixed now.
FYI: we already looked at using binding customization, but AFAIK a namespace can only be written to a completely different package, but this is not what we want. The original NS should still automatically be retained but simply prefixed. something like "for all namespaces, map them to a corresponding package name but prefix it with %s"
We could of course lookup all namespaces and then list each of them manually in the binding and prefix them, but this would be a time consuming process which needs to be repeated manually every time the WSDL changes (new namespaces could be introduced) and is something we want to avoid
JUSTIFICATION :
We have different WSDLs from different service providers for which we generate client stubs automatically as part of our build. Packages for the generated code is automatically deduced from the service/schema namespaces. While the goal of namespaces is to be unique, this is unfortunately not always the case. We even have clashes from different WSDLs (but coming from the same provider). More specifically common datatypes that are re-used by them over different service WSDLs but not the same version (because of missing versioning, better said). This results in the code generation to be order dependent as they are written to the same package but are basically overwritten and thus the last one wins causing failures if the order changes
One way of thinking could be to ask the provider to fix this. However, in reality this is not always an option. fixing the WSDL ourselves is not something we want as we are not the service/schema owners and then it becomes a maintenance burden on our side. Adding an option to prefix generated packages seems a trivial change that could help sandboxing the generated code without impacting the uniqueness (since the remainder of the namespace is still automatically used) of the generated code within the sandbox
The text was updated successfully, but these errors were encountered:
Previously tracked via: https://bugs.openjdk.java.net/browse/JDK-8166338
A DESCRIPTION OF THE REQUEST :
We use wsimport via a Maven plugin that generates client stubs for webservices we use in our project. The code generation is done automatically as part of our build.
Would it be possible to have an option to prefix packages of generated sources for a specific WSDL rather than only using the namespaces?
For ex. service1.wsdl is in NS 'ws1' and has a schema in NS 'x'. service2.wsdl is in NS 'ws2' and has a schema in NS 'y'. The option in wsimport would then allow to specify a prefix for the entire WSDL. If we would choose 'service1' as prefix for the first WSDL and 'service2' as prefix for the second WSDL, the code generated would respectively be in package: 'service1.x....' (for the data bindings) and 'service1.ws1....' (for the service bindings). Likewise, the code for service2 would be in package 'service2.y' and 'service2.ws2'. Note that the remainder of the package consists out of the original NS as before, only it is prefixed now.
FYI: we already looked at using binding customization, but AFAIK a namespace can only be written to a completely different package, but this is not what we want. The original NS should still automatically be retained but simply prefixed. something like "for all namespaces, map them to a corresponding package name but prefix it with %s"
We could of course lookup all namespaces and then list each of them manually in the binding and prefix them, but this would be a time consuming process which needs to be repeated manually every time the WSDL changes (new namespaces could be introduced) and is something we want to avoid
JUSTIFICATION :
We have different WSDLs from different service providers for which we generate client stubs automatically as part of our build. Packages for the generated code is automatically deduced from the service/schema namespaces. While the goal of namespaces is to be unique, this is unfortunately not always the case. We even have clashes from different WSDLs (but coming from the same provider). More specifically common datatypes that are re-used by them over different service WSDLs but not the same version (because of missing versioning, better said). This results in the code generation to be order dependent as they are written to the same package but are basically overwritten and thus the last one wins causing failures if the order changes
One way of thinking could be to ask the provider to fix this. However, in reality this is not always an option. fixing the WSDL ourselves is not something we want as we are not the service/schema owners and then it becomes a maintenance burden on our side. Adding an option to prefix generated packages seems a trivial change that could help sandboxing the generated code without impacting the uniqueness (since the remainder of the namespace is still automatically used) of the generated code within the sandbox
The text was updated successfully, but these errors were encountered: