You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by "Silberman, Nathan" <NS...@doubleclick.com> on 2007/12/26 20:48:48 UTC
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
Posted by James Mao <ja...@iona.com>.
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:mayankt@huawei.com]
> 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:glen.mazza@verizon.net]
> 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:glen.mazza@verizon.net]
>> 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
Posted by "Silberman, Nathan" <NS...@doubleclick.com>.
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:mayankt@huawei.com]
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:glen.mazza@verizon.net]
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:glen.mazza@verizon.net]
> 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
Posted by Mayank Thakore <ma...@huawei.com>.
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:glen.mazza@verizon.net]
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:glen.mazza@verizon.net]
> 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
Posted by Glen Mazza <gl...@verizon.net>.
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:glen.mazza@verizon.net]
> 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
Posted by "Silberman, Nathan" <NS...@doubleclick.com>.
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:glen.mazza@verizon.net]
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
Posted by Glen Mazza <gl...@verizon.net>.
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
Posted by Jim Ma <em...@iona.com>.
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
>
>