jabsorb support for JSON-RPC 2.0 specifications, named parameters

[progre55]

Hi guys,

I couldnt find it anywhere in the manuals. Does jabsorb support JSON-
RPC 2.0 specifications yet? Especially named parameters in rpc calls?
For example:
--> {"jsonrpc": "2.0", "method": "subtract", "params": {"subtrahend":
23, "minuend": 42}, "id": 3}
<-- {"jsonrpc": "2.0", "result": 19, "id": 3}

--> {"jsonrpc": "2.0", "method": "subtract", "params": {"minuend": 42,
"subtrahend": 23}, "id": 4}
<-- {"jsonrpc": "2.0", "result": 19, "id": 4}

Here is the specification proposal:
http://groups.google.com/group/json-rpc/web/json-rpc-2-0

Thanks in advance.

King regards,
Ikrom

[tibor....@gmail.com]

Hi,

As far as I know, jabsorb implements the secification of json-rpc 1.0,
which is the only finalized specification at this time. Other versions
of jsron-rpc are working drafts. @see http://en.wikipedia.org/wiki/JSON-RPC
or http://groups.google.com/group/json-rpc/msg/c5633df97dc8f16f.

Some thoughs on the topic:

1) In order to support named parameters, jabsorb would have to be able
to find out the parameter names of the java method in question.
Unfortunately, the names of the parameters are not stored in java
bytecode, unless the inclusion of debug information is turned on when
compiling. (Even if debug info is included by the compiler, parameter
names cannot be queried using reflection, it requires some bytecode
magic to find out them.) Hence, there is no reliable way of finding
out parameter names at runtime by using reflection or analyzing the
bytecode.

2) An alternative to finding out parameter names would be processing
annotations on method parameters, for example: String foo(@RpcParam
(name="bar") String bar). To be honest, this seems rather chatty to
me, and I do not like the idea that methods need to be specially
crafted to support invocation with named parameters. But technically,
this approach is possible. Of course, one would have to modify the
current code to support this feature.

Anyone, feel free to correct me in case I am wrong.

Cheers,
T

[Matthijs Wensveen]

Hmm, just thinking out loud here. I think it is possible to get the parameter names with APT during compilation. If this information is persisted somewhere (preferably within the class itself), the framework could use that to figure out what overload to use and in what order to pass them.

Matthijs

  T

--
You received this message because you are subscribed to the Google Groups "jabsorb-user" group.
To post to this group, send email to jabsor...@googlegroups.com.
To unsubscribe from this group, send email to jabsorb-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jabsorb-user?hl=en.

[Tibor Bősze]

Seems like my last two comments from yesterday are lost... sorry for duplicates in case.

Matthijs, you do not even have to use APT or any other tool: as i have written earlier, the parameter names are stored in the LocalVariableTable section of the class file in case javac is run with debug info enabled (option -g). See the specification of class file format http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html#5956

However, sometimes you are not in control of how some jars in your project are compiled - you might not have the source, just the bytecode without debug info in case of commercial components, or you simply would not be allowed to change the build process in case of larger project where you are only responsible for some part of the application. I can also well imagine the case that one would like to run the application without embedded debug info in production. Hence, it does not seems a good idea to depend on information that might be included in the class file or not might not be there. This would cause problems if some classes you want to expose via jabsorb are not compiled by you.

Runtime access to java parameter names using reflection has been considered for inclusion in Java 6 (feature #402), but rejected due to worries about promoting bad programming practices.

Should one really need this functionality, I would suggest using ParaNamer (http://paranamer.codehaus.org/), it implements all the different way I have outlined earlier:

* it can read parameter names from the class bytecode at runtime - relies on debug info, you need to ensure / change a compiler setting for this to work (-g).
* it can read annotations to figure out the parameter names -  you need to write / modify the source of the target classes in a special ways.
* it can instrument your classes to include a special public static String field where it stores the parameter names, and it reads this fields at runtime using reflection. This would require your build process to be changed.

The alternative approaches above might or might not be suitable for your project, there is no way that will work in all situations. In case you only get a stripped down jar to code against you will have no info to read the parameter names from. Having said these words of warning, I still hope this post is useful...

Cheers,
   T

[tibor....@gmail.com]

Matthijs,

You do not even have to use APT or any special tool. As I have
written, turning on debug info when compiling the classes will place
the parameter names into a special section of the class file, that is
normally used by debuggers. This can be achieved by using the -g
switch when using javac. The parameter names are stores in the section
calles LocalVariableTable of the class file, for reference, see the
spec of the class file format here:
http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html#5956

Hence, the parameter names can be aquired when comping your classes
with -g. However, the idea that one is relying on the code to be
compiled in a specific way, (like -g) or processed with specific tools
(like APT) is not a good pattern. What if you want to expose methods
implemented and compiled by third party without debug info, or having
a situation when you can not influence the compilation of a given set
of jars? I can also well imagine that one would compile his app
without debug info for production use.

In summary, as I have outlined above, there is a way to find it out,
but you are relying on some extra info being included in your class
file, which might or might not be present. In case you control the
whole build and each and every part of the application, this will
probably not be a problem. If you are working as part of a larger team
or working with third party components (think - commercial components
- typically not compiled with debug info) then this might not be an
option.

From an architectural point of view I would discourage relying on data
that is not guaranteed to be there where you expect it to be... But,
from the technical aspect, it is possible to get those parameter names
from the LocalVariableTable of the class.

Cheers,
T

[tibor....@gmail.com]

Matthijs,

should someone really need this functionality, I would suggest using
ParaNamer (http://paranamer.codehaus.org/) for the job. It provides
all the alternatives I have mentioned earlier:

* can analyse bytecode at runtime to read parameter names from debug
info in the class file. Requires you to use a specific compiler option
(-g).
* can use annotation on method parameters, requires you to change code
on target class for this to work.
* can instrument your class files to include a specially formatted
public static String field which will hold info about method parameter
names. Requires you to modify your build process.

Some more background on the topic: The ability to access parameter
names using reflection has been suggested to be included in Java 6
(jsr270 feature #402), but rejected.

Cheers,
T

[Arthur Blake]

Seems like a lot of trouble just for named parameters.
Why not just pass a Map as a single parm and pull the objects out by
name on the java side?

[Matthijs Wensveen]

Tibor,

I was just adding my 2 cents here. I don't really need this, but progre55 / Ikrom's post did arouse my interest. Thanks for your insights though, you seem to know a lot more about this than I do (although I was aware of the jsr you mentioned :) ).

Arthur, a Map might be okay in some / most cases, but requires you to change your (public) API. This might not always be wanted. Does jabsorb pass the "params" in the example as a Map to methods that receive a Map parameter?

Another option might be to manually match parameter names to method arguments, using some sort of mapping file (a la hibernate). You wouldn't need to recompile or anything. You can even make up your own parameter names if it seems more appropriate (i.e. an obfuscated 3rd partly library *). I does take some work to do, though.

*: Publishing (to JSON-RPC) a 3rd party lib wouldn't be smart anyway. You can always create some wrapper that you are able to compile in some sort of special way, but still..

Best regards,
Matthijs

[tibor....@gmail.com]

Arthur,

doing so is throughout possible, but in case someone wants to expose N
methods this way, one would have to implement N wrapper methods which
accept a map as the only param and do nothing more than extract the
params from the map and invoke the original method. This seems like
lots of boilerplate code.

I was focusing on a generic and preferably transparent way of exposing
java methods with parameter names. I really enjoy that I do not have
to craft my logic in a special way when working with jabsorb. Your
suggested pattern could be automated by using some code generator that
generates wrapper methods based on the java source files - this would
eliminate the manual work that is linear with the number of methods
exposed.

On Feb 27, 6:26 pm, Arthur Blake <arthur.bl...@gmail.com> wrote:
> Seems like a lot of trouble just for named parameters.
> Why not just pass a Map as a single parm and pull the objects out by
> name on the java side?
>

> On Sat, Feb 27, 2010 at 12:00 AM, tibor.boe...@gmail.com