juneau-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JUNEAU-49) Support beans as arguments for GET calls using @RemoteableMethod
Date Tue, 30 May 2017 01:31:04 GMT

    [ https://issues.apache.org/jira/browse/JUNEAU-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16028696#comment-16028696
] 

ASF GitHub Bot commented on JUNEAU-49:
--------------------------------------

Github user clr-apache commented on a diff in the pull request:

    https://github.com/apache/incubator-juneau/pull/2#discussion_r118998959
  
    --- Diff: juneau-core/src/main/java/org/apache/juneau/internal/StringUtils.java ---
    @@ -618,7 +618,9 @@ public static boolean isEmpty(String s) {
     	 * @return <jk>true</jk> if specified string is <jk>null</jk>
or it's {@link #toString()} method returns an empty string.
     	 */
     	public static boolean isEmpty(Object s) {
    -		return s == null || s.toString().isEmpty();
    +		if( s == null ) return true;
    +		if( s instanceof List ) return ((List) s).size() == 0;
    --- End diff --
    
    There is a big discussion on stackoverflow on this topic. 
    https://stackoverflow.com/questions/3321526/should-i-use-string-isempty-or-equalsstring
    I like the simple 
    "".equals(s)
    which handles the null case.
    
    If you include s being an instance of collection, it seems that you could use
    if (s instanceof Iterable) return (Iterable) s).isEmpty();
    Then even user-defined types that implement Iterable can be used.
    



> Support beans as arguments for GET calls using @RemoteableMethod
> ----------------------------------------------------------------
>
>                 Key: JUNEAU-49
>                 URL: https://issues.apache.org/jira/browse/JUNEAU-49
>             Project: Juneau
>          Issue Type: Improvement
>            Reporter: Steve Blackmon
>
> The standard use case for wrapping a GET call with query parameters in a rest proxy is
to enumerate each of the possible get params in order and attach @query to each.
> However, when the number of possible parameters becomes large and many are optional,
the ability for the proxy to extract multiple params from a bean would make implementation
much more readable.
> Enable pojo arguments annotated @Query("\*") or @QueryIfNE("\*”) in a method annotated
@RemoteableMethod(httpMethod="GET") to serve as a source for multiple parameters (all query
parameters for now)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message