Hi Linus

You're welcome. 
If you were able not use a form submission, but simply POST a JSON sequence
as is, that is instead of 

POST /someaddress
Content-Type : application/x-www-form-urlencoded 
undis={"collection":["foo":"bar"}}

just do

POST /someaddress
Content-Type : application/json
{"collection":["foo":"bar"]}

then you'd be able to do


public Response addUnids(@QueryParam("userId")String userid,
                                   UnidCollection unids) {}

and JSONProvider would deserialize the collection.

If you do need to use forms then for JSON be deserialized properly without
you doing some manual JSON parsing, we'd need to enhance the way
multipart/form-data is handled (and you'd then need to have requests
serialized according to multipart/form-data rules). At the moment
multipart/form-data requests are handled transparently only when the
individual filed values are Strings. For handling the files uploads one
needs to work with MultipartBody. So we'd need to enhance it a bit such that
registered MessageBodyReaders could also read field values. I've added a
task to my list... 

cheers, Sergey





Linus Kamb-2 wrote:
> 
> Sergey,
> 
> Thanks so much for your reply.  (And thank you as well for all your other
> patient and informative list replies.  I've gotten a lot out of them.)
> 
> I have read that bit you mention.  As I have said, I'm still quite new to
> this so am still trying to understand it all...
> 
> What we are trying to do (and maybe it's all craziness, I don't know) is
> the
> following:
> 
> We have a portlet that needs to communicate with our back-end service. 
> The
> portlet crafts information (collection of information in this case) in
> JSON
> format that it wants to POST to the back-end service.  This is what I'm
> trying to figure out how to.  The service method definition below is what
> I've been working with, and so far it seems to work (testing with
> HttpClient
> PostMethod, and using the fromString() to build the object from the POSTed
> JSON.)  
> 
> If there is a more natural way to do that, I'd love to hear it. 
> Otherwise,
> this is working for the moment.
> 
> Thanks,
> Linus
> 
> 
> -----Message d'origine-----
> De : Sergey Beryozkin [mailto:[email protected]] 
> Envoyé : Thursday, September 10, 2009 11:36 AM
> À : [email protected]
> Objet : RE: fromString() not found
> 
> 
> Hi,
> 
> You can also register ParameterHandler, for ex,
> CollectionHandler<UnidCollection>, if you do not want to have
> fromString(),
> valueOf(), etc...
> http://cxf.apache.org/docs/jax-rs.html#JAX-RS-DealingwithParameters
> 
>> why do I need to have the demarshaller when CXF can marshall the
>> Collection
> 
> I'm presuming you refer to this method :
> 
>  public Response addUnids(@QueryParam("userId")String userid,
> 
>                               @FormParam("unids")UnidCollection unids) {
> 
>             [..]
> 
>             return Response.ok().build();
> 
>       }
> 
> 'unids' is referring here to a form field, so it's not JSON at all in this
> case, right ?
> 
> Or are you referring to the fact no explicit JSON collections (those
> without
> a root element wrapper) can  be deserialized at the moment ? I nealy made
> it
> working the other day, there was some subtle JAXB issue I could not
> overcome. I've seen exactly the same issue recently when testing that
> collections like List<Book>, where Book.class has no @XmlRootElement, can
> be
> deserialized, so at least I have some reproducible failure pattern to look
> at...
> 
> cheers, Sergey
> 
> 
> Linus Kamb-2 wrote:
>> 
>> D'oh!  It always works that way. Send off the message right before you
>> find
>> the obvious.
>> 
>> I was looking at the final error message, not the stack trace.  In fact
>> the
>> method was found but had thrown an Exception.  Sorry about that.
>> 
>> But the ultimate question of why do I need to have the demarshaller when
>> CXF
>> can marshall the Collection fine still stands.
>> 
>> Thanks,
>> Linus
>> 
>> 
>> -----Message d'origine-----
>> De : Linus Kamb [mailto:[email protected]] 
>> Envoyé : Thursday, September 10, 2009 10:40 AM
>> À : [email protected]
>> Objet : fromString() not found
>> 
>> Hi,
>> 
>>  
>> 
>> I am new to CXF, so I apologize if this is obvious and I've missed it in
>> the
>> docs.
>> 
>>  
>> 
>> First, what I am trying to do is POST JSON to a RS service.  And I've
>> made
>> that work, although it seems awkward.  I'll get to that.
>> 
>>  
>> 
>> I have services defined:
>> 
>>  
>> 
>>       // @Produces({"application/json", "text/javascript"})
>> 
>>       @POST
>> 
>>       @Path("/add") 
>> 
>>       public Response addUnids(@QueryParam("userId")String userid,
>> 
>>                               @FormParam("unids")UnidCollection unids) {
>> 
>>             [..]
>> 
>>             return Response.ok().build();
>> 
>>       }
>> 
>>       @Produces({"application/json", "text/javascript"})
>> 
>>       @GET
>> 
>>       @Path(("/get")
>> 
>>       public Response getUnids(@QueryParam("userId") String userId) {
>> 
>>             return Response.ok(buildUnidCollection()).build();
>> 
>>       }
>> 
>>  
>> 
>> The immediate question is:
>> 
>>  
>> 
>> I have two classes:  Unid, and UnidCollection.  The latter simply
>> contains
>> a
>> Collection of the former.
>> 
>>  
>> 
>> Both have public static <type> fromString(String str) methods  (as well
>> as
>> public static valueOf(String) methods).
>> 
>>  
>> 
>> However, when I invoke the service, I get an exception saying the
>> UnidOridCollection does not have String constructor, fromString or
>> valueOf
>> methods. In fact it has both.    If I add the String constructor to
>> UnidCollection, it's happy.  But I'd prefer not to go that route.
>> 
>>  
>> 
>> Why does it find the fromString() in Unid, but not in UnidCollection() ?
>> 
>>  
>> 
>> The bigger question I have is why is CXF able to automatically marshall
>> to
>> JSON, but not the other way around?
>> 
>> What is it that I need to do to make that automatic (and not need the
>> above
>> methods)?
>> 
>>  
>> 
>> Thanks so much, 
>> 
>> Linus
>> 
>>  
>> 
>> 
>> 
>> 
>> 
> 
> -- 
> View this message in context:
> http://www.nabble.com/fromString%28%29-not-found-tp25379507p25380185.html
> Sent from the cxf-user mailing list archive at Nabble.com.
> 
> 
> 
> 
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/fromString%28%29-not-found-tp25379507p25381244.html
Sent from the cxf-user mailing list archive at Nabble.com.

Reply via email to