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: [email protected] 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: [email protected] 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: [email protected] > 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
