[
https://issues.apache.org/jira/browse/XMLRPC-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12720667#action_12720667
]
Livnat Peer edited comment on XMLRPC-174 at 6/17/09 6:38 AM:
-------------------------------------------------------------
>>Your intention is to get a server working, which is implemented in a
>>completely different environment. If I get it right, then you intend to
>>create a Java interface, which resembles the servers API. You are fine with
>>the logic that converts parameters into XML-RPC requests and result objects
>>from XML-RPC response. What you want to override is the method which derives
>>the XML-RPC methodCall. That's right?
yes. exactly right.
>>"Thinking about it, I like the basic idea. It should simplify work for a lot
>>of XML-RPC users. However, I do have concerns with the suggested >>approach.
>>
>>a) I'd rather see something like annotations, like @methodName="..." in the
>>interface, which acts as a description. Ok, that would mean leaving >>Java
>>1.4 behind, but I think it's time for that. "
that can be cool. (one can extend this attitude to fields name as well...)
nevertheless, IMO, the option of using the API as it is today (without
annotation) should stay. and if i use what the package has today i still want
to be able to call methods without prefix.
There is no "cost" for adding this because calling ".foo()" makes no sense in
java. so as far as i understand we do not lose anything by removing the "." if
the pRemoteName is empty.
>>b) We are using the possibilty to gain metadata by inspecting a Java class.
>>There is a second method for gaining metadata, which is not >>compatible. We
>>should keep in mind to merge use of this. Possibly by generating Java classes
>>from the API.
>>
>>The latter one is less important, because the ClientFactory is, by
>>definition, clearly tied to the Java language.
I agree
was (Author: livnats):
>>Your intention is to get a server working, which is implemented in a
>>completely different environment. If I get it >>right, then you intend to
>>create a Java interface, which resembles the servers API. You are fine with
>>the logic that >>converts parameters into XML-RPC requests and result objects
>>from XML-RPC response. What you want to >>override is the method which
>>derives the XML-RPC methodCall. That's right?
yes. exactly right.
>>"Thinking about it, I like the basic idea. It should simplify work for a lot
>>of XML-RPC users. However, I do have >>concerns with the suggested >>approach.
>>
>>a) I'd rather see something like annotations, like @methodName="..." in the
>>interface, which acts as a >>description. Ok, that would mean leaving >>Java
>>1.4 behind, but I think it's time for that. "
that can be cool. (one can extend this attitude to fields name as well...)
nevertheless, IMO, the option of using the API as it is today (without
annotation) should stay. and if i use what the package has today i still want
to be able to call methods without prefix.
There is no "cost" for adding this because calling ".foo()" makes no sense in
java. so as far as i understand we do not lose anything by removing the "." if
the pRemoteName is empty.
>>b) We are using the possibilty to gain metadata by inspecting a Java class.
>>There is a second method for gaining >>metadata, which is not >>compatible.
>>We should keep in mind to merge use of this. Possibly by generating Java
>>>>classes from the API.
>>
>>The latter one is less important, because the ClientFactory is, by
>>definition, clearly tied to the Java language.
I agree
> The ClientFactory always concatenates a "." before the method name.
> -------------------------------------------------------------------
>
> Key: XMLRPC-174
> URL: https://issues.apache.org/jira/browse/XMLRPC-174
> Project: XML-RPC
> Issue Type: Bug
> Components: Source
> Affects Versions: 3.1.1
> Reporter: Livnat Peer
> Priority: Minor
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> I want to invoke a remote method, who's name is without any prefix.
> In the "newInstance" methods:
> 1. The first 2 signatures add the class name as a prefix:
> public interface X{
> public void foo();
> }
> foo() invokes--> X.foo()
> 2. The 3rd signature adds the string passed in pRemoteName as a prefix:
> invoking newInstance with pRemoteName="goo" invokes--> "goo.foo()"
> passing pRemoteName="" invokes
> --> ".foo()"
> suggested patch:
> In the class
> "ClientFactory.java"
> In method
> "public Object newInstance(ClassLoader pClassLoader, final Class pClass,
> final String pRemoteName)"
> add a check if the pRemoteName is empty, if this is the case then no need to
> concatenate "." before the method name.
> today - String methodName = pRemoteName + "." + pMethod.getName();
> a fix - String methodName = pMethod.getName();
> if(pRemoteName.length()>0){
> methodName = pRemoteName + "." + methodName;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
