Re: Wsdl2java package usage
Hi Nathan, We currently don't have a plan to do that, However you probably could file a jira for that. Patches are welcome :) James Thanks to you both for the advice. Is there any plan to add a switch to allow for automatic merging of the ObjectFactory methods when executing wsdl2java against multiple wsdls? I imagine that this requirement is not uncommon and would make it much easier than having to maintan the ObjectFactory manually (especially since ObjectFactory need not be used by non JAXB/CXF code for the majority of simple bindings) Thanks again, Nathan -Original Message- From: Mayank Thakore [mailto:[EMAIL PROTECTED] Sent: Thursday, December 27, 2007 12:56 AM To: cxf-user@incubator.apache.org Subject: RE: Wsdl2java package usage We had 8 services like this. We ran wsdl2java separately for each of them. Then, copied everything into one folder-tree (overwriting along the way) and as Glen said, finally merged the ObjectFactory code manually. Regards Mayank -Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] Sent: Thursday, December 27, 2007 10:48 To: cxf-user@incubator.apache.org Subject: RE: Wsdl2java package usage I apologize, I stand corrected. Metro (JAXB apparently) *does* create this class. I did not realize it was a required object--still, I don't see it being referenced by other classes. Perhaps running wsdl2java twice, flipping the order of FooService and BarService, and then merging all the methods into *one* ObjectFactory would work. That's all I can think of. Glen Am Mittwoch, den 26.12.2007, 23:48 -0500 schrieb Silberman, Nathan: I actually had not been using ObjectFactory in my code at all. The reason why this came up is that I have 2 services, lets call them FooService and BarService, both of which have abstract and extended types. When I execute wsdl2java on FooService, and then BarService, ObjectFactory has only BarService create helper methods. No problem so far. Still not referencing these methods in my codebase. At this point, when I deploy my two services, only BarService works correctly, in that FooService's extended types are marshalled WITHOUT derived type information (thus rendering them impossible to unmarshall). If I instead execute wsdl2java on BarService and then FooService, thus ensuring that FooService's methods appear in ObjectFactory, then FooService works fine and BarService's derived/extended types no longer work. I hadn't though that ObjectFactory was used at from CXF but this is literally the only file I observed as being altered (aside from several file's whose' autogened timestamps were changed) when I switch the ordering of which I execute with wsdl2java first or second. Any thoughts? I can produce some sample code if this is unclear or if a real example is needed for any diagnosis. -Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 26, 2007 11:34 PM To: cxf-user@incubator.apache.org Subject: Re: Wsdl2java package usage Am Mittwoch, den 26.12.2007, 14:48 -0500 schrieb Silberman, Nathan: When using wsdl2java, I had been specifying the destination packages for several services to be the same package: com.foobar lets say. This is not problematic for all classes except one: ObjectFactory. The methods in objectFactory are only those of the last wsdl to be generated to java code. The consequence of this is that objectFactory is missing most of the element helper methods. Has anybody else run into this issue? If so, is there another solution other than having each wsdl2java output be sent to a different package? (The consequence of multiple output packages is that you end up with duplicate classes for wsdls that share types) ObjectFactory has always struck me as just a training wheel-type helper class for newbies. (IIRC GlassFish Metro's wsimport doesn't even generate it.) I would argue to keep your code JAX-WS portable and avoid using it in your work. Glen Nathan
Wsdl2java package usage
When using wsdl2java, I had been specifying the destination packages for several services to be the same package: com.foobar lets say. This is not problematic for all classes except one: ObjectFactory. The methods in objectFactory are only those of the last wsdl to be generated to java code. The consequence of this is that objectFactory is missing most of the element helper methods. Has anybody else run into this issue? If so, is there another solution other than having each wsdl2java output be sent to a different package? (The consequence of multiple output packages is that you end up with duplicate classes for wsdls that share types) Nathan
Re: Wsdl2java package usage
Hi Nathan, Wsdl2java can not merge the ObjectFactory to the previously generated class. We need to provide a warning message or an option before overwrite the generated code. I think you can use wsdl2java -pnamespce=package to map the different namespace to different package . for example: wsdl2java -porg.apache.cxf.schema1=com.foo.bar1 -porg.apache.cxf.schema2=com.cxf.foo.bar1 Hope this can help you . Regards Jim Silberman, Nathan wrote: When using wsdl2java, I had been specifying the destination packages for several services to be the same package: com.foobar lets say. This is not problematic for all classes except one: ObjectFactory. The methods in objectFactory are only those of the last wsdl to be generated to java code. The consequence of this is that objectFactory is missing most of the element helper methods. Has anybody else run into this issue? If so, is there another solution other than having each wsdl2java output be sent to a different package? (The consequence of multiple output packages is that you end up with duplicate classes for wsdls that share types) Nathan
Re: Wsdl2java package usage
Am Mittwoch, den 26.12.2007, 14:48 -0500 schrieb Silberman, Nathan: When using wsdl2java, I had been specifying the destination packages for several services to be the same package: com.foobar lets say. This is not problematic for all classes except one: ObjectFactory. The methods in objectFactory are only those of the last wsdl to be generated to java code. The consequence of this is that objectFactory is missing most of the element helper methods. Has anybody else run into this issue? If so, is there another solution other than having each wsdl2java output be sent to a different package? (The consequence of multiple output packages is that you end up with duplicate classes for wsdls that share types) ObjectFactory has always struck me as just a training wheel-type helper class for newbies. (IIRC GlassFish Metro's wsimport doesn't even generate it.) I would argue to keep your code JAX-WS portable and avoid using it in your work. Glen Nathan
RE: Wsdl2java package usage
I apologize, I stand corrected. Metro (JAXB apparently) *does* create this class. I did not realize it was a required object--still, I don't see it being referenced by other classes. Perhaps running wsdl2java twice, flipping the order of FooService and BarService, and then merging all the methods into *one* ObjectFactory would work. That's all I can think of. Glen Am Mittwoch, den 26.12.2007, 23:48 -0500 schrieb Silberman, Nathan: I actually had not been using ObjectFactory in my code at all. The reason why this came up is that I have 2 services, lets call them FooService and BarService, both of which have abstract and extended types. When I execute wsdl2java on FooService, and then BarService, ObjectFactory has only BarService create helper methods. No problem so far. Still not referencing these methods in my codebase. At this point, when I deploy my two services, only BarService works correctly, in that FooService's extended types are marshalled WITHOUT derived type information (thus rendering them impossible to unmarshall). If I instead execute wsdl2java on BarService and then FooService, thus ensuring that FooService's methods appear in ObjectFactory, then FooService works fine and BarService's derived/extended types no longer work. I hadn't though that ObjectFactory was used at from CXF but this is literally the only file I observed as being altered (aside from several file's whose' autogened timestamps were changed) when I switch the ordering of which I execute with wsdl2java first or second. Any thoughts? I can produce some sample code if this is unclear or if a real example is needed for any diagnosis. -Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 26, 2007 11:34 PM To: cxf-user@incubator.apache.org Subject: Re: Wsdl2java package usage Am Mittwoch, den 26.12.2007, 14:48 -0500 schrieb Silberman, Nathan: When using wsdl2java, I had been specifying the destination packages for several services to be the same package: com.foobar lets say. This is not problematic for all classes except one: ObjectFactory. The methods in objectFactory are only those of the last wsdl to be generated to java code. The consequence of this is that objectFactory is missing most of the element helper methods. Has anybody else run into this issue? If so, is there another solution other than having each wsdl2java output be sent to a different package? (The consequence of multiple output packages is that you end up with duplicate classes for wsdls that share types) ObjectFactory has always struck me as just a training wheel-type helper class for newbies. (IIRC GlassFish Metro's wsimport doesn't even generate it.) I would argue to keep your code JAX-WS portable and avoid using it in your work. Glen Nathan
RE: Wsdl2java package usage
We had 8 services like this. We ran wsdl2java separately for each of them. Then, copied everything into one folder-tree (overwriting along the way) and as Glen said, finally merged the ObjectFactory code manually. Regards Mayank -Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] Sent: Thursday, December 27, 2007 10:48 To: cxf-user@incubator.apache.org Subject: RE: Wsdl2java package usage I apologize, I stand corrected. Metro (JAXB apparently) *does* create this class. I did not realize it was a required object--still, I don't see it being referenced by other classes. Perhaps running wsdl2java twice, flipping the order of FooService and BarService, and then merging all the methods into *one* ObjectFactory would work. That's all I can think of. Glen Am Mittwoch, den 26.12.2007, 23:48 -0500 schrieb Silberman, Nathan: I actually had not been using ObjectFactory in my code at all. The reason why this came up is that I have 2 services, lets call them FooService and BarService, both of which have abstract and extended types. When I execute wsdl2java on FooService, and then BarService, ObjectFactory has only BarService create helper methods. No problem so far. Still not referencing these methods in my codebase. At this point, when I deploy my two services, only BarService works correctly, in that FooService's extended types are marshalled WITHOUT derived type information (thus rendering them impossible to unmarshall). If I instead execute wsdl2java on BarService and then FooService, thus ensuring that FooService's methods appear in ObjectFactory, then FooService works fine and BarService's derived/extended types no longer work. I hadn't though that ObjectFactory was used at from CXF but this is literally the only file I observed as being altered (aside from several file's whose' autogened timestamps were changed) when I switch the ordering of which I execute with wsdl2java first or second. Any thoughts? I can produce some sample code if this is unclear or if a real example is needed for any diagnosis. -Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 26, 2007 11:34 PM To: cxf-user@incubator.apache.org Subject: Re: Wsdl2java package usage Am Mittwoch, den 26.12.2007, 14:48 -0500 schrieb Silberman, Nathan: When using wsdl2java, I had been specifying the destination packages for several services to be the same package: com.foobar lets say. This is not problematic for all classes except one: ObjectFactory. The methods in objectFactory are only those of the last wsdl to be generated to java code. The consequence of this is that objectFactory is missing most of the element helper methods. Has anybody else run into this issue? If so, is there another solution other than having each wsdl2java output be sent to a different package? (The consequence of multiple output packages is that you end up with duplicate classes for wsdls that share types) ObjectFactory has always struck me as just a training wheel-type helper class for newbies. (IIRC GlassFish Metro's wsimport doesn't even generate it.) I would argue to keep your code JAX-WS portable and avoid using it in your work. Glen Nathan
