Hi Sergey,
Can you post a sample resource class, a sample signature and a sample
adapter.
E.g. this is a sample method in my SEI:
void SetmultiContainClassA(
@XmlJavaTypeAdapter(ReposRootRefAdapter.class) ReposRoot rootRef,
@XmlJavaTypeAdapter(TopClassARefAdapter.class) List<TopClassA>
valuesRef) throws Exception;
A "pointer" to some repository root instance is passed, and then a list
of pointers to TopClassA instances. The semantics is that the repository
root shall contain the TopClassA instances, however since they already
exist in the database, only (typed) pointers are passed. So the pointer
type of ReposRoot is called ReposRootRef and the pointer type of
TopClassA is called TopClassARef. There is also a type hierarchy among
pointer classes, resembling the type hierarchy of the instance classes.
We didnt want to pass just String values as pointer, and we have a
better documentation of the signature at the same time. A pointer class
just holds a String value, namely the id of the domain instance , and
the XMLAdapter is capable of resolving the pointer to the actual domain
instance. Another reason for typed pointer is that we need to know the
type of the domain instance for resolving the pointer.
Now, to get more performance, we wanted to try REST methods. So we
augmented the signature in the following way:
@PUT
@Path("/SetmultiContainClassA/{id}")
@Produces({"application/xml", "application/json"})
@Consumes({"application/xml", "application/json"})
void SetmultiContainClassA(@PathParam("id")
@XmlJavaTypeAdapter(ReposRootRefAdapter.class) ReposRoot rootRef,
@XmlJavaTypeAdapter(TopClassARefAdapter.class) List<TopClassA>
valuesRef) throws Exception;
So the pointer to the repository root is passed in the URI, and the
other pointers are put into the body as typed list. The implementation
class of the SEI is then also registered as REST service. The SEI is
known by the service client, who can use either the web service or -
with help of RESTbyContract - the REST service - whatever is faster or
whatever is accessible. Also important is, that we can test the REST
interface and the WS interface with the same unit tests - just by either
using the plain webservice or by using the RESTasContract proxy.
So for having REST, no further implementation is needed, only adding
some annotations and registering the REST service in the XMLs (which was
horrible to get working since the examples on the CXF site were no
working). And thats why I wanted that special treatment of XMLAdapters.
Its actually also the expected behavior, since XMLAdapter and @Path can
be both used together, while your fix uses one or the other. So from a
more theoretical point of view, in my fix REST and WS annotations are
additive in functionality, in your modified fix, they are exclusive -
however to achieve exclusive functionality, one can just omit either the
REST or WS annotations, but one cannot use the addition of the
functionality with your fix.
As you see, we make have use of XMLAdapters in the signature, this is
just a very useful concept. But we use them also in our domain classes
heavily. I just tested jax-ri 2.2.1.1 and they have still bugs with
XMLAdapters (without digging deaper in the code). Version 2.2.2 solved
the problems for our domain classes, so would be nice if CXF could be
delivered with that version.
Cheers,
Joerg
