Re: [jira] Commented: (XMLRPC-174) The ClientFactory always concatenates a "." before the method name.

[Livnat Sharabani <li...@gmail.com>]

reply in context -

On Mon, Jun 15, 2009 at 12:19 PM, Jochen Wiedmann (JIRA) <
xmlrpc-dev@ws.apache.org> wrote:

>
>    [
> https://issues.apache.org/jira/browse/XMLRPC-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12719478#action_12719478]
>
> Jochen Wiedmann commented on XMLRPC-174:
> ----------------------------------------
>
> Let's start to make sure that we understand your use case: The
> ClientFactory was originally designed to enable a very easy communication
> between client and server, which are both running Apache XML-RPC.
>
> 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.
>
>