> When I created an XFire test client using the precompiled class JAR file, I > kept getting nulls in most of the object members, and I finally looked at > the SOAP going across and realized the members had the wrong namespace. I > finally realized XFire saw the CXF-version annotations and simply ignored > them, and use the class package name for the namespace of the members.
What do you mean by annotations in this context? (@'s)? It sure is true that the CXF runtime is ignorant of the old XFire annotations and vica versa, since we've changed all the packages. An @nnotation is just an object in a class. No way can XFire see the new @nnotations, since they all got new names. A jar of annotated classes has to go with the reader of the annotations. If you annotate using JAXB, then they can use any client stack that supports JAXB. If you annotate using XFire, you're got to distribute XFire. If you annotate with CXF/Aegis, then you need a compatible runtime, namely, CXF. If you 'annotate' using .aegis.xml files, there's reasonable hope, however, that you can use either the CXF runtime or the older XFire runtime. But no other kit will pay the slightest attention. In my limited experience, it seems more common for server-providers to tell their clients to pick the kit of their choice and use wsdl2java to build their own proxies. > > So I reverted to using the earlier XFire-annotated JAR classes and now it > works again. So I now realize that we can't really safely publish a JAR > full of proxy objects and assume all of our customers can use it - rather, > only customers using the specific stack (XFire 1.2) can make correct use of > this JAR file. > > So the question becomes - what is the standard way of providing customers > with proxy objects? I'm guessing the answer is: "Let them use the WSDL to > generate proxy objects with their chosen framework." > > Does that make sense? Again, I'm still feeling my way past the basic > examples that we extended for our own use, so I'm "wet behind the ears yet."
