I'm not quite sure how to help, sorry. I always do 'mvn install
-Pfastinstall' followed by "mvn -Psetup.eclipse" and then import the
projects. In this case we do have multiple target dirs but I've never had
any issues, why do you need the same structure ?
My CXF server and client Eclipse plugins have the CXF facet installed,
which adds the cxf jars to the build path/deployment. This is not at all
compatible to the idea of CXF projects in my workspace.
I have written a small Java application collecting all the jars, copying
them into one directory, but the final result looks quite different to
what is delivered with e.g. CXF 2.3.3 lib folder.
Actually if I add the CXF projects as project dependencies to my CXF
REST junit client, it wont start from whithin Eclipse (CreateProcess
error=87, Falscher Parameter=Wrong Parameter, may indicate a too long
cmd line for Windows). However if I pack all that CXF stuff with my unit
test into a single try.jar (93mb) (calling the test methods from within
the main()), and execute try.jar with "java -jar try.jar", then there is
still a bug with reading JSON list, actually equivalent when executing
JSONProviderTest.testReadQualifiedCollection():
org.apache.xerces.dom.ElementNSImpl cannot be cast to
org.apache.cxf.jaxrs.resources.TagVO2
So the orignal bug seems not to be resolved by your patch.
As I was advised in the cxf irc channel, the everything target could
create the jar structure in the distribution/target folder. However this
target not finishes succesfully, with some weired error message I cant
and I dont want to remember.
Though REST responses can write single java-primitive or String values,
these values cannot be read, neither with JAXBElementPRovider nor with
JSONProvider. However it should be quite simple like this (body is the
response string, targetType the expected type of the body):
if (targetType.isPrimitive())
return
targetType.getConstructor(String.class).newInstance(body);
if (targetType == String.class)
return body;
//otherwise
return myMessageBodyReader.readFrom(targetType,..);
So either it should be not possible to write primitive types/Strings, or
some code like the above should be added somewhere to be able to read
the response. Even if it is prohibited by the XML/JSON spec, it would be
a quite useful feature (at least for my purposes).
As you asked how to encode/decode top-level-lists, I favor the following
encoding for e.g. List<String>:
<Strings><String>s1</String><String>s2</String>..</Strings>. So it
behaves as if the type String has a XMLRootElement declaration with
name="String". Actually, when using the convention that the type name is
used when there is no XMLRootElement/name defined, then a
primitive/String-typed list could be managed automatically. Considering
the above hint on single value transmission, maybe a String should be
send as "<String>s1</String>" and not as "s1" over the network? Then its
more similar to a valid XML document. Or is there some way equivalent to
the @PathParam, but actually for the reverse direction of transmission,
maybe using the HTTP response headers (found no annotations for that)?
