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:[EMAIL PROTECTED]
Sent: Friday, May 16, 2008 9:42 AM
To: [email protected]
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:[EMAIL PROTECTED]
Sent: Wednesday, May 07, 2008 1:34 PM
To: [email protected]
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
[EMAIL PROTECTED]
http://www.dankulp.com/blog
---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
