Community
Participate
Working Groups
Build Identifier: There's already been one added in the Twitter client, but if the automated XML service gets pulled out of the receiver, then there's no reason why the (example) Twitter client's JSON implementation can't be used in other places as well. Reproducible: Always
The org.json parser is included with ECF right now (since 3.2). In ECF 3.3 the jar is named: org.json_1.0.0.v201003050614.jar There is test code that uses this parser in org.eclipse.ecf/tests/bundles/org.eclipse.ecf.tests.remoteservice.rest project/bundle. Is this json parser insufficient for some reason?
Sorry, should have been a bit clearer. I meant the parameter serializer that's used with the rest service. The twitter example provides a parameter binding/result parsing, but does so via an internal class. If you still don't know what in referring to, I'll fibdvthe class names I'm referring to and add them in here
(In reply to comment #2) > Sorry, should have been a bit clearer. I meant the parameter serializer that's > used with the rest service. The twitter example provides a parameter > binding/result parsing, but does so via an internal > class. > > If you still don't know what in referring to, I'll fibdvthe class names I'm > referring to and add them in here Yes, the twitter example uses an inner class, but it's only implementing the org.eclipse.ecf.remoteservice.client.IRemoteResponseDeserializer interface (via the inner class)...so others are able to create any impl of IRemoteResponseDeserializer desired (i.e. json parsing...or whatever). I don't think that we really want to do more than org.json.JSONArray/JSONObject, etc. Are you looking for some wrapper classes for the JSON* classes in org.json.*...or something else?
Yeah, that's what I was thinking, but abstract it away from the org.json stuff completely. So you could get back a Map (or something that implemented Map), or Double, or String. That way, you can treat the data as being something that produces vanilla Java objects.
(In reply to comment #4) > Yeah, that's what I was thinking, but abstract it away from the org.json stuff > completely. So you could get back a Map (or something that implemented Map), or > Double, or String. That way, you can treat the data as being something that > produces vanilla Java objects. I guess I'm not quite understanding what is actually desired besides/in addition to JSONArray and/or JSONObject. The reason I say this is that as soon as we/ECF define some specific set of java types, with their corresponding json representation (e.g. an array of name-value pairs), it will be necessary for the service implementation to also use these classes/representations (instead of 'raw' json) so that the 'on-the-wire' format is the same on both ends. We are working on an ECF-based server additions (i.e. ECF based service impl) and perhaps these classes could be added to that? (i.e. to make it easier to create service impls as well as clients of those services). If I'm not understanding what you are looking for then maybe you could attach a class/code/patch that describes what you are interested in.
(In reply to comment #5) > (In reply to comment #4) <stuff deleted> > > If I'm not understanding what you are looking for then maybe you could attach a > class/code/patch that describes what you are interested in. Alex...As I still don't understand what you are looking for...above and beyond the org.json classes and serializer/deserializer interfaces...which are also there...and I don't wish to add API classes without a good reason...I'm inclined to close this as works-for-me without some further input. Thanksinadvance.
We/ECF do have the org.json parser included with recent versions of ECF, so as per comment #6 closing as worksforme. If something more specific is desired, please reopen and specify.
