[jira] [Issue Comment Edited] (OODT-433) filemgr.getProductByName returns empty product references which results in a bug in --retrieveFilesByName and --retrieveFilesById

["Thomas Bennett (Issue Comment Edited) (JIRA)" <ji...@apache.org>]

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

Thomas Bennett edited comment on OODT-433 at 3/27/12 2:17 PM:
--------------------------------------------------------------

This issue relates to three problems, but I have the following questions:

1) getProductByName has the getRefs set to false. Should this be set to true, or should the client execute a second xml-rpc call to retrieve the product references.

2) Should refs be checked to see if its empty and throw an exception if it is empty? I.e.

if refs.isEmpty() {
    throw EmptyListException('There are no product references.')
}

3) Should the dt.retrieveProduct() be removed?
                
      was (Author: lmzxq.tom):
    This issue relates to three problems, but I have the following questions:

1) getProductByName has the references set to false. Should this be set to true, or should the client execute a second xml-rpc call to retrieve the product references.

2) Should refs be checked to see if its empty and throw an exception if it is empty? I.e.

if refs.isEmpty() {
    throw EmptyListException('There are no product references.')
}

3) Should the dt.retrieveProduct() be removed?
                  
> filemgr.getProductByName returns empty product references which results in a bug in --retrieveFilesByName and --retrieveFilesById
> ---------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: OODT-433
>                 URL: https://issues.apache.org/jira/browse/OODT-433
>             Project: OODT
>          Issue Type: Bug
>          Components: file manager
>    Affects Versions: 0.4
>            Reporter: Thomas Bennett
>            Assignee: Thomas Bennett
>            Priority: Minor
>              Labels: patch
>             Fix For: 0.4
>
>
> --retrieveFilesByName and --retrieveFilesById have a bug.
> Sequence of events:
> Here's the command that I ran:
> filemgr-client --url http://localhost:9101 --operation --retrieveFilesByName --productName 1332838758.h5 --destination /home/kat/ --transferer org.apache.oodt.cas.filemgr.datatransfer.LocalDataTransferFactory
> So, the  --retrieveFilesByName calls an XML-RPC "filemgr.getProductByName" to get the product details. However on the File Manager side in org.apache.oodt.cas.filemgr.catalog.LuceneCatalog.java line 412 and 415:
> return getProductByName(productName, false)  /*where the call signature is (defined on line 415 of the same file)*/
> getProductByName(String productName, boolean getRefs)
> getRefs is now passed (as false) as a parameter to the toCompleteProduct(..) method, which seems to indicate that the product references should not be returned.
> This is then received by the filemgr client in the methodResponse with the references set as [] i.e. an empty list :)
> On the client side in org.apache.oodt.cas.filemgr.datatransfer.LocalDataTransferer.java line 358 and 359 of the copyFilesToDir() method:
>       List<Reference> refs = product.getProductReferences();
>       for (Iterator<Reference> i = refs.iterator(); i.hasNext();)
> Since refs is empty the for loop loops zero times.
> Then a bit further up the call chain in org.apache.oodt.cas.filemgr.cli.action.RetrieveFilesCliAction.java line 55 to 60:
>          if (product != null) {
>             dt.retrieveProduct(product, destination);
>          } else {
>             throw new Exception("Product was not found");
>          }
>          dt.retrieveProduct(product, destination);
> It appears that dt.retrieveProduct is called a second time outside the if / else statement.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira