Hi thanks for looking into this issue...
On Sat, Mar 26, 2011 at 1:20 PM, [email protected] <[email protected]>wrote: > > 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. > > That was as far as I could get to awhile back, regarding reading JSON sequences into explicit collections :-), with the help of the *Jettison* based provider. Sorry, should've clarified it better. Nearly the same code works for JAXBElementProvider, so perhaps Jettison XMLStreamReader is not handling something properly, and may be it needs some 'help' at the JSONProvider level for the deserialization to succeed. So if you could tweak that patch a bit then it would be great :-) > 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. CXF ships a PrimitiveProvider which supporting reading/writing primitives but only for a text/plain type. > 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)? > This all can be done, I'm just not sure at the moment whether *default* JAXB and JSON providers should do it or not. May be it is the job of a PrimitiveJSON/XMLProvider - custom providers can be written and registered alongside the default ones - please consider doing it at this stage - and may be you can contribute them to CXF ? Then we can also discuss the possibility of having that code added to the default providers to minimize some possible duplication thanks. Sergey
