Hi Joerg
thanks for posting this example
> 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;
>
>
Can you let me know how does the signature of ReposRootRefAdapter.class look
like ?
thanks, Sergey
> 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
>
--
Sergey Beryozkin
Application Integration Division of Talend <http://www.talend.com>
http://sberyozkin.blogspot.com
