You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Daniel Lipofsky <Da...@bricsnet.com> on 2008/05/07 21:34:25 UTC
turning off @XmlSeeAlso in wsdl2java in CXF 2.1
With CXF 2.1 wsdl2java the generated code now adds @XmlSeeAlso.
Is there a way to turn this off?
This only case seems to be "@XmlSeeAlso({ObjectFactory.class})".
I don't want to use ObjectFactory and have been choosing to
delete it but without it I can't compile because of this tag.
(ObjectFactory seems to be totally unneccessary to me,
and since it has one per service and I choose to have many
services generate into the same package this is a problem
unless I restructure everything about my build. I was hoping
to just do a simple migration from 2.0.5).
Thanks,
Dan
Re: turning off @XmlSeeAlso in wsdl2java in CXF 2.1
Posted by Daniel Kulp <dk...@apache.org>.
On May 19, 2008, at 12:47 PM, Daniel Lipofsky wrote:
> On May 16, 2008, at 1:31 PM, Daniel Kulp wrote
>>
>>
>> Startup performance would probably be slightly better if you grabbed
>> all of the wrapper types, even the ones for the unwrapped methods.
>> If you look in the service interface for those methods, you'll see a
>> @RequestWrapper/@ReponseWrapper annotation that points to those
>> classes. With 2.1, if they are there, we use them. If not, we use
>> ASM to dynamically generate them at startup time. Thus, if you have
>> them, we can avoid the ASM stuff.
>
> Avoiding ASM would be nice.
>
> I am still wondering though, if I am using an unwrapped
> method signature, then I am not using the RequestWrapper
> or ReponseWrapper, at least not anywhere in my code,
> neither client nor server side.
>
> So is it using it behind the scenes in CXF code where I
> can't see it? If not can we avoid generating those objects
> and avoid ASM without including them in my build?
Per JAX-WS spec, if the method is supposed to go on the wire as a
"wrapped" doc/lit form, we're supposed to look for the wrapper beans
and use them.
The reference implementation REQUIRES the wrapper beans to be there.
You need to run the wsimport tool to generate them. CXF doesn't
require them. If they aren't there, with 2.1, we'll use ASM to
generate them. If they aren't there and ASM ISN'T available, (no
asm.jar on the classpath), then we make a "best attempt" to work, but
there are various JAXB things that don't work properly that way. For
most cases, it works fine. (FYI: CXF 2.0 didn't do the asm thing.
Thus, the jax-ws 2.0 use cases should work fine without asm, it's the
newer jax-ws 2.1 stuff that requires it)
>>> I use one namespace per service
>>
>> Well, there is the namespace for the service and then there is the
>> namespace of the types. Are all the types in the same namespace?
>> If so, you may be OK. If not, you could have issues.
>
> My WSDL declares
> <xsd:schema targetNamespace="http://....">
> and doesn't declare any other namespaces or do any imports
> in the schema section.
>
> My SOAP messages look like
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> <soap:Body>
> <ns1:GetObjects xmlns:ns1="http://www.foobar.com/Tx">
> <searchTerms>
> <key>alphaId</key>
> <value>TX-WS-EXAMPLE</value>
> <type>like</type>
> </searchTerms>
> <offset>0</offset>
> <length>100</length>
> </ns1:GetObjects>
> </soap:Body>
> </soap:Envelope>
>
> *BUT* what I do might be unusual. Things like "GetObjects"
> and "searchTerms" exist in many namespaces, it is identical
> across all of them. I duplicate them in each WSDL rather
> than doing an import.
>
>>> So far it seems to work fine, I just had to do the
>>> hack for ObjectFactory when I switched from 2.0.5 to 2.1,
>>> but that class seems to be unused since I made an empty
>>> one and it still works. All my unit tests work.
>>
>> You're schemas might be simple enough. If all your schemas are set
>> for elementForm="unqualified", this becomes easier as the namespaces
>> don't really go on the wire. Thus, it's more immune to these types
>> of issues.
>
> I don't explicitly say "unqualified" anywhere, but maybe that
> is the default.
>
Yep. Unqualified is the default. Thus, you're probably OK in this
case.
---
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
RE: turning off @XmlSeeAlso in wsdl2java in CXF 2.1
Posted by Daniel Lipofsky <Da...@bricsnet.com>.
On May 16, 2008, at 1:31 PM, Daniel Kulp wrote
>
> On May 16, 2008, at 12:29 PM, Daniel Lipofsky wrote:
> >
> > I choose the "all services in one directory" strategy
> > because many of my services use the same message wrapper
> > objects (the @XmlRootElement objects), and I have extended
> > some of those classes, so I am not even using the generated
> > versions of them.
> >
> > I don't even use package-info.java or ObjectFactory.java
> > (I generate to a temp directory and don't bother to copy them).
> > Same with many of the @XmlRootElement objects, most of my methods
> > are called unwrapped, so I only need them for the few methods that
> > are wrapped. So the only thing I really generate and use is
> > *PortType.java and *Service.java
>
> Startup performance would probably be slightly better if you grabbed
> all of the wrapper types, even the ones for the unwrapped methods.
> If you look in the service interface for those methods, you'll see a
> @RequestWrapper/@ReponseWrapper annotation that points to those
> classes. With 2.1, if they are there, we use them. If not, we use
> ASM to dynamically generate them at startup time. Thus, if you have
> them, we can avoid the ASM stuff.
Avoiding ASM would be nice.
I am still wondering though, if I am using an unwrapped
method signature, then I am not using the RequestWrapper
or ReponseWrapper, at least not anywhere in my code,
neither client nor server side.
So is it using it behind the scenes in CXF code where I
can't see it? If not can we avoid generating those objects
and avoid ASM without including them in my build?
> > I use one namespace per service
>
> Well, there is the namespace for the service and then there is the
> namespace of the types. Are all the types in the same namespace?
> If so, you may be OK. If not, you could have issues.
My WSDL declares
<xsd:schema targetNamespace="http://....">
and doesn't declare any other namespaces or do any imports
in the schema section.
My SOAP messages look like
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ns1:GetObjects xmlns:ns1="http://www.foobar.com/Tx">
<searchTerms>
<key>alphaId</key>
<value>TX-WS-EXAMPLE</value>
<type>like</type>
</searchTerms>
<offset>0</offset>
<length>100</length>
</ns1:GetObjects>
</soap:Body>
</soap:Envelope>
*BUT* what I do might be unusual. Things like "GetObjects"
and "searchTerms" exist in many namespaces, it is identical
across all of them. I duplicate them in each WSDL rather
than doing an import.
> > So far it seems to work fine, I just had to do the
> > hack for ObjectFactory when I switched from 2.0.5 to 2.1,
> > but that class seems to be unused since I made an empty
> > one and it still works. All my unit tests work.
>
> You're schemas might be simple enough. If all your schemas are set
> for elementForm="unqualified", this becomes easier as the namespaces
> don't really go on the wire. Thus, it's more immune to these types
> of issues.
I don't explicitly say "unqualified" anywhere, but maybe that
is the default.
Thanks,
Dan
Re: turning off @XmlSeeAlso in wsdl2java in CXF 2.1
Posted by Daniel Kulp <dk...@apache.org>.
On May 16, 2008, at 12:29 PM, Daniel Lipofsky wrote:
> OK, I'm still pretty green to all this.
>
> I choose the "all services in one directory" strategy
> because many of my services use the same message wrapper
> objects (the @XmlRootElement objects), and I have extended
> some of those classes, so I am not even using the generated
> versions of them.
>
> I don't even use package-info.java or ObjectFactory.java
> (I generate to a temp directory and don't bother to copy them).
> Same with many of the @XmlRootElement objects, most of my methods
> are called unwrapped, so I only need them for the few methods that
> are wrapped. So the only thing I really generate and use is
> *PortType.java and *Service.java
Startup performance would probably be slightly better if you grabbed
all of the wrapper types, even the ones for the unwrapped methods.
If you look in the service interface for those methods, you'll see a
@RequestWrapper/@ReponseWrapper annotation that points to those
classes. With 2.1, if they are there, we use them. If not, we use
ASM to dynamically generate them at startup time. Thus, if you have
them, we can avoid the ASM stuff.
> I use one namespace per service
Well, there is the namespace for the service and then there is the
namespace of the types. Are all the types in the same namespace?
If so, you may be OK. If not, you could have issues.
> So far it seems to work fine, I just had to do the
> hack for ObjectFactory when I switched from 2.0.5 to 2.1,
> but that class seems to be unused since I made an empty
> one and it still works. All my unit tests work.
You're schemas might be simple enough. If all your schemas are set
for elementForm="unqualified", this becomes easier as the namespaces
don't really go on the wire. Thus, it's more immune to these types
of issues.
Dan
> Am I setting myself up for a disaster?
> (what could possibly go wrong ... :-)
>
> - Dan
>
>
>> -----Original Message-----
>> From: Daniel Kulp [mailto:dkulp@apache.org]
>> Sent: Friday, May 16, 2008 9:42 AM
>> To: users@cxf.apache.org
>> Cc: Daniel Lipofsky
>> Subject: Re: turning off @XmlSeeAlso in wsdl2java in CXF 2.1
>>
>>
>> It's kind of required per-spec. Thus, we don't really have a way to
>> turn it off.
>>
>> That said, in many cases, the ObjectFactory classes are necessary for
>> the JAXB runtime to actually work correctly. If you have types by
>> extension (subclasses in java code), they may not get picked up into
>> the context (unless you use some extra configuration), sometimes
>> certain enums don't work, etc...
>>
>> Also, what's even more important: With JAXB 2.1, if you generate more
>> than one schema into the same package, you are definitely going to
>> have problems. The default namespace and whether elements are
>> qualified or not are stored in the package-info.java class. Thus,
>> if you have multiple schemas getting generated in there, which even
>> is
>> generated "last" will control the namespace and element
>> qualifications
>> for everything. Thus, you would/could definitely end up with invalid
>> XML being generated. I had someone run into this last week with
>> using the -p flag on wsdl2java. I need to add some checks to that
>> flag to make sure it will work. If there are multiple namespaces, it
>> really won't.
>>
>> Dan
>>
>>
>> On May 16, 2008, at 11:27 AM, Daniel Lipofsky wrote:
>>
>>> I did figure out I could create an empty ObjectFactory
>>> class to overcome this problem. But I am still wondering
>>> if the generation of this tag could be turned off, or
>>> what it is used for and why is it needed.
>>>
>>> Thanks,
>>> Dan
>>>
>>>> -----Original Message-----
>>>> From: Daniel Lipofsky [mailto:Daniel.Lipofsky@bricsnet.com]
>>>> Sent: Wednesday, May 07, 2008 1:34 PM
>>>> To: users@cxf.apache.org
>>>> Subject: turning off @XmlSeeAlso in wsdl2java in CXF 2.1
>>>>
>>>> With CXF 2.1 wsdl2java the generated code now adds @XmlSeeAlso.
>>>> Is there a way to turn this off?
>>>>
>>>> This only case seems to be "@XmlSeeAlso({ObjectFactory.class})".
>>>> I don't want to use ObjectFactory and have been choosing to
>>>> delete it but without it I can't compile because of this tag.
>>>>
>>>> (ObjectFactory seems to be totally unneccessary to me,
>>>> and since it has one per service and I choose to have many
>>>> services generate into the same package this is a problem
>>>> unless I restructure everything about my build. I was hoping
>>>> to just do a simple migration from 2.0.5).
>>>>
>>>> Thanks,
>>>> Dan
>>
>> ---
>> Daniel Kulp
>> dkulp@apache.org
>> http://www.dankulp.com/blog
>>
>>
>>
>
---
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
RE: turning off @XmlSeeAlso in wsdl2java in CXF 2.1
Posted by Daniel Lipofsky <Da...@bricsnet.com>.
OK, I'm still pretty green to all this.
I choose the "all services in one directory" strategy
because many of my services use the same message wrapper
objects (the @XmlRootElement objects), and I have extended
some of those classes, so I am not even using the generated
versions of them.
I don't even use package-info.java or ObjectFactory.java
(I generate to a temp directory and don't bother to copy them).
Same with many of the @XmlRootElement objects, most of my methods
are called unwrapped, so I only need them for the few methods that
are wrapped. So the only thing I really generate and use is
*PortType.java and *Service.java
I use one namespace per service
So far it seems to work fine, I just had to do the
hack for ObjectFactory when I switched from 2.0.5 to 2.1,
but that class seems to be unused since I made an empty
one and it still works. All my unit tests work.
Am I setting myself up for a disaster?
(what could possibly go wrong ... :-)
- Dan
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: Friday, May 16, 2008 9:42 AM
> To: users@cxf.apache.org
> Cc: Daniel Lipofsky
> Subject: Re: turning off @XmlSeeAlso in wsdl2java in CXF 2.1
>
>
> It's kind of required per-spec. Thus, we don't really have a way to
> turn it off.
>
> That said, in many cases, the ObjectFactory classes are necessary for
> the JAXB runtime to actually work correctly. If you have types by
> extension (subclasses in java code), they may not get picked up into
> the context (unless you use some extra configuration), sometimes
> certain enums don't work, etc...
>
> Also, what's even more important: With JAXB 2.1, if you generate more
> than one schema into the same package, you are definitely going to
> have problems. The default namespace and whether elements are
> qualified or not are stored in the package-info.java class. Thus,
> if you have multiple schemas getting generated in there, which even is
> generated "last" will control the namespace and element qualifications
> for everything. Thus, you would/could definitely end up with invalid
> XML being generated. I had someone run into this last week with
> using the -p flag on wsdl2java. I need to add some checks to that
> flag to make sure it will work. If there are multiple namespaces, it
> really won't.
>
> Dan
>
>
> On May 16, 2008, at 11:27 AM, Daniel Lipofsky wrote:
>
> > I did figure out I could create an empty ObjectFactory
> > class to overcome this problem. But I am still wondering
> > if the generation of this tag could be turned off, or
> > what it is used for and why is it needed.
> >
> > Thanks,
> > Dan
> >
> >> -----Original Message-----
> >> From: Daniel Lipofsky [mailto:Daniel.Lipofsky@bricsnet.com]
> >> Sent: Wednesday, May 07, 2008 1:34 PM
> >> To: users@cxf.apache.org
> >> Subject: turning off @XmlSeeAlso in wsdl2java in CXF 2.1
> >>
> >> With CXF 2.1 wsdl2java the generated code now adds @XmlSeeAlso.
> >> Is there a way to turn this off?
> >>
> >> This only case seems to be "@XmlSeeAlso({ObjectFactory.class})".
> >> I don't want to use ObjectFactory and have been choosing to
> >> delete it but without it I can't compile because of this tag.
> >>
> >> (ObjectFactory seems to be totally unneccessary to me,
> >> and since it has one per service and I choose to have many
> >> services generate into the same package this is a problem
> >> unless I restructure everything about my build. I was hoping
> >> to just do a simple migration from 2.0.5).
> >>
> >> Thanks,
> >> Dan
>
> ---
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
>
Re: turning off @XmlSeeAlso in wsdl2java in CXF 2.1
Posted by Daniel Kulp <dk...@apache.org>.
It's kind of required per-spec. Thus, we don't really have a way to
turn it off.
That said, in many cases, the ObjectFactory classes are necessary for
the JAXB runtime to actually work correctly. If you have types by
extension (subclasses in java code), they may not get picked up into
the context (unless you use some extra configuration), sometimes
certain enums don't work, etc...
Also, what's even more important: With JAXB 2.1, if you generate more
than one schema into the same package, you are definitely going to
have problems. The default namespace and whether elements are
qualified or not are stored in the package-info.java class. Thus,
if you have multiple schemas getting generated in there, which even is
generated "last" will control the namespace and element qualifications
for everything. Thus, you would/could definitely end up with invalid
XML being generated. I had someone run into this last week with
using the -p flag on wsdl2java. I need to add some checks to that
flag to make sure it will work. If there are multiple namespaces, it
really won't.
Dan
On May 16, 2008, at 11:27 AM, Daniel Lipofsky wrote:
> I did figure out I could create an empty ObjectFactory
> class to overcome this problem. But I am still wondering
> if the generation of this tag could be turned off, or
> what it is used for and why is it needed.
>
> Thanks,
> Dan
>
>> -----Original Message-----
>> From: Daniel Lipofsky [mailto:Daniel.Lipofsky@bricsnet.com]
>> Sent: Wednesday, May 07, 2008 1:34 PM
>> To: users@cxf.apache.org
>> Subject: turning off @XmlSeeAlso in wsdl2java in CXF 2.1
>>
>> With CXF 2.1 wsdl2java the generated code now adds @XmlSeeAlso.
>> Is there a way to turn this off?
>>
>> This only case seems to be "@XmlSeeAlso({ObjectFactory.class})".
>> I don't want to use ObjectFactory and have been choosing to
>> delete it but without it I can't compile because of this tag.
>>
>> (ObjectFactory seems to be totally unneccessary to me,
>> and since it has one per service and I choose to have many
>> services generate into the same package this is a problem
>> unless I restructure everything about my build. I was hoping
>> to just do a simple migration from 2.0.5).
>>
>> Thanks,
>> Dan
---
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
RE: turning off @XmlSeeAlso in wsdl2java in CXF 2.1
Posted by Daniel Lipofsky <Da...@bricsnet.com>.
I did figure out I could create an empty ObjectFactory
class to overcome this problem. But I am still wondering
if the generation of this tag could be turned off, or
what it is used for and why is it needed.
Thanks,
Dan
> -----Original Message-----
> From: Daniel Lipofsky [mailto:Daniel.Lipofsky@bricsnet.com]
> Sent: Wednesday, May 07, 2008 1:34 PM
> To: users@cxf.apache.org
> Subject: turning off @XmlSeeAlso in wsdl2java in CXF 2.1
>
> With CXF 2.1 wsdl2java the generated code now adds @XmlSeeAlso.
> Is there a way to turn this off?
>
> This only case seems to be "@XmlSeeAlso({ObjectFactory.class})".
> I don't want to use ObjectFactory and have been choosing to
> delete it but without it I can't compile because of this tag.
>
> (ObjectFactory seems to be totally unneccessary to me,
> and since it has one per service and I choose to have many
> services generate into the same package this is a problem
> unless I restructure everything about my build. I was hoping
> to just do a simple migration from 2.0.5).
>
> Thanks,
> Dan