You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@oodt.apache.org by "Thomas Bennett (Created) (JIRA)" <ji...@apache.org> on 2012/03/27 16:12:27 UTC

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

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
             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

        

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

Posted by "jiraposter@reviews.apache.org (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/OODT-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241173#comment-13241173 ] 

jiraposter@reviews.apache.org commented on OODT-433:
----------------------------------------------------


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/4553/
-----------------------------------------------------------

Review request for oodt, Chris Mattmann, brian Foster, Paul Ramirez, and Sheryl John.


Summary
-------

Get product references before calling retrieveProduct().
1) call setProductReferences method
2) remove d.retrieveProduct() outside the if else statement.

Fix unit tests testRetrieveFilesById() and testRetrieveFilesByName()
1) last method call is now getProductReferences not getProductByName/getProductById
2) The last method call has the product passed in as the argument. The call has been modified to retrieve the productName/productId correctly from the method call.


This addresses bug OODT-433.
    https://issues.apache.org/jira/browse/OODT-433


Diffs
-----

  trunk/filemgr/src/main/java/org/apache/oodt/cas/filemgr/cli/action/RetrieveFilesCliAction.java 1306745 
  trunk/filemgr/src/test/org/apache/oodt/cas/filemgr/cli/TestFileManagerCli.java 1306745 

Diff: https://reviews.apache.org/r/4553/diff


Testing
-------

* All unit tests now pass
* filemgr deployed and tested with the filemgr client using both local and remote data transfer factories.


Thanks,

Thomas


                
> 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

        

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

Posted by "Brian Foster (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=13240730#comment-13240730 ] 

Brian Foster edited comment on OODT-433 at 3/28/12 9:02 PM:
------------------------------------------------------------

1) ya i agree with chris... getProductBy(Name | Id) should only return the product info... no references
2) again agree with chris... this is a bug... RetrieveFilesCliAction should have asked the filemgr for the references after retrieving the Product
3) the second retrieveProduct should have been removed... wish i had gotten fluent with EasyMock when i was doing all the cas-cli stuff... a test around RetrieveFilesCliAction with an EasyMock of the filemgr client would have caught the second unexpected call to retrieveProduct.

So i see 2 changes in this issue:
1) Add fmClient.getProductReferences(product) to RetrieveFilesCliAction:
{code}
if (product != null) {
   product.setProductReferences(fmClient.getProductReferences(product));
   dt.retrieveProduct(product, destination);
} else {
   throw new Exception("Product was not found");
}
{code}
2) Removed the extra dt.retrieveProduct() (the one outside the check null if statment)
                
      was (Author: bfoster):
    1) ya i agree with chris... getProductBy(Name | Id) should only return the product info... no references
2) again agree with chris... this is a bug... RetrieveFilesCliAction should have asked the filemgr for the references after retrieving the Product
3) the second retrieveProduct should have been removed... which i had gotten fluent with EasyMock when i was doing all the cas-cli stuff... an test around RetrieveFilesCliAction with an EasyMock of the filemgr client would have caught the second unexpected call to retrieveProduct.

So i see 2 changes in this issue:
1) Add fmClient.getProductReferences(product) to RetrieveFilesCliAction:
{code}
if (product != null) {
   product.setProductReferences(fmClient.getProductReferences(product));
   dt.retrieveProduct(product, destination);
} else {
   throw new Exception("Product was not found");
}
{code}
2) Removed the extra dt.retrieveProduct() (the one outside the check null if statment)
                  
> 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

        

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

Posted by "Thomas Bennett (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/OODT-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241016#comment-13241016 ] 

Thomas Bennett commented on OODT-433:
-------------------------------------

Hey Brian,

+1 from me to. Excellent idea! Thats a really neat solution and makes perfect sense.
                
> 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

        

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

Posted by "Thomas Bennett (Closed) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/OODT-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Bennett closed OODT-433.
-------------------------------

    
> 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

        

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

Posted by "jiraposter@reviews.apache.org (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/OODT-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241461#comment-13241461 ] 

jiraposter@reviews.apache.org commented on OODT-433:
----------------------------------------------------


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/4553/#review6524
-----------------------------------------------------------

Ship it!


LGTM!

- Chris


On 2012-03-29 12:26:06, Thomas Bennett wrote:
bq.  
bq.  -----------------------------------------------------------
bq.  This is an automatically generated e-mail. To reply, visit:
bq.  https://reviews.apache.org/r/4553/
bq.  -----------------------------------------------------------
bq.  
bq.  (Updated 2012-03-29 12:26:06)
bq.  
bq.  
bq.  Review request for oodt, Chris Mattmann, brian Foster, Paul Ramirez, and Sheryl John.
bq.  
bq.  
bq.  Summary
bq.  -------
bq.  
bq.  Get product references before calling retrieveProduct().
bq.  1) call setProductReferences method
bq.  2) remove d.retrieveProduct() outside the if else statement.
bq.  
bq.  Fix unit tests testRetrieveFilesById() and testRetrieveFilesByName()
bq.  1) last method call is now getProductReferences not getProductByName/getProductById
bq.  2) The last method call has the product passed in as the argument. The call has been modified to retrieve the productName/productId correctly from the method call.
bq.  
bq.  
bq.  This addresses bug OODT-433.
bq.      https://issues.apache.org/jira/browse/OODT-433
bq.  
bq.  
bq.  Diffs
bq.  -----
bq.  
bq.    trunk/filemgr/src/test/org/apache/oodt/cas/filemgr/cli/TestFileManagerCli.java 1306745 
bq.    trunk/filemgr/src/main/java/org/apache/oodt/cas/filemgr/cli/action/RetrieveFilesCliAction.java 1306745 
bq.  
bq.  Diff: https://reviews.apache.org/r/4553/diff
bq.  
bq.  
bq.  Testing
bq.  -------
bq.  
bq.  * All unit tests now pass
bq.  * filemgr deployed and tested with the filemgr client using both local and remote data transfer factories.
bq.  
bq.  
bq.  Thanks,
bq.  
bq.  Thomas
bq.  
bq.


                
> 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

        

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

Posted by "Chris A. Mattmann (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/OODT-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240687#comment-13240687 ] 

Chris A. Mattmann commented on OODT-433:
----------------------------------------

bq. 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.

Yeah I think the semantics are that this is a "thin" call to getProductByName, which is fine: the references can be large (e.g., if it's a dir product), so I think that retrieveFiles is doing the right thing by calling false here (even if it generates another call)

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

I think instead, retrieveFiles should instead (after calling getProductByName), then get product.setProductReferences(getProductReferences)

bq. 3) Should the dt.retrieveProduct() be removed?

The 2nd call, right? That seems correct to me, to only have 1 call, if the Product isn't null.


                
> 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

        

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

Posted by "jiraposter@reviews.apache.org (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/OODT-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13242165#comment-13242165 ] 

jiraposter@reviews.apache.org commented on OODT-433:
----------------------------------------------------


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/4553/
-----------------------------------------------------------

(Updated 2012-03-30 08:45:40.520457)


Review request for oodt, Chris Mattmann, brian Foster, Paul Ramirez, and Sheryl John.


Changes
-------

Removed unused import and killed some white space :)


Summary
-------

Get product references before calling retrieveProduct().
1) call setProductReferences method
2) remove d.retrieveProduct() outside the if else statement.

Fix unit tests testRetrieveFilesById() and testRetrieveFilesByName()
1) last method call is now getProductReferences not getProductByName/getProductById
2) The last method call has the product passed in as the argument. The call has been modified to retrieve the productName/productId correctly from the method call.


This addresses bug OODT-433.
    https://issues.apache.org/jira/browse/OODT-433


Diffs (updated)
-----

  trunk/filemgr/src/main/java/org/apache/oodt/cas/filemgr/cli/action/RetrieveFilesCliAction.java 1306745 
  trunk/filemgr/src/test/org/apache/oodt/cas/filemgr/cli/TestFileManagerCli.java 1306745 

Diff: https://reviews.apache.org/r/4553/diff


Testing
-------

* All unit tests now pass
* filemgr deployed and tested with the filemgr client using both local and remote data transfer factories.


Thanks,

Thomas


                
> 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

        

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

Posted by "Thomas Bennett (Resolved) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/OODT-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Bennett resolved OODT-433.
---------------------------------

    Resolution: Fixed

Fixed. Brian - thanks for the help!
                
> 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

        

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

Posted by "jiraposter@reviews.apache.org (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/OODT-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241175#comment-13241175 ] 

jiraposter@reviews.apache.org commented on OODT-433:
----------------------------------------------------


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/4553/
-----------------------------------------------------------

(Updated 2012-03-29 12:26:06.602271)


Review request for oodt, Chris Mattmann, brian Foster, Paul Ramirez, and Sheryl John.


Changes
-------

Fixed my Eclipse editor to indent 3 spaces, soft tabs.


Summary
-------

Get product references before calling retrieveProduct().
1) call setProductReferences method
2) remove d.retrieveProduct() outside the if else statement.

Fix unit tests testRetrieveFilesById() and testRetrieveFilesByName()
1) last method call is now getProductReferences not getProductByName/getProductById
2) The last method call has the product passed in as the argument. The call has been modified to retrieve the productName/productId correctly from the method call.


This addresses bug OODT-433.
    https://issues.apache.org/jira/browse/OODT-433


Diffs (updated)
-----

  trunk/filemgr/src/test/org/apache/oodt/cas/filemgr/cli/TestFileManagerCli.java 1306745 
  trunk/filemgr/src/main/java/org/apache/oodt/cas/filemgr/cli/action/RetrieveFilesCliAction.java 1306745 

Diff: https://reviews.apache.org/r/4553/diff


Testing
-------

* All unit tests now pass
* filemgr deployed and tested with the filemgr client using both local and remote data transfer factories.


Thanks,

Thomas


                
> 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

        

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

Posted by "Chris A. Mattmann (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/OODT-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240789#comment-13240789 ] 

Chris A. Mattmann commented on OODT-433:
----------------------------------------

I think you are brilliant, and super +1!
                
> 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

        

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

Posted by "jiraposter@reviews.apache.org (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/OODT-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241174#comment-13241174 ] 

jiraposter@reviews.apache.org commented on OODT-433:
----------------------------------------------------


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/4553/#review6517
-----------------------------------------------------------

Ship it!


Lgtm

- Paul


On 2012-03-29 12:21:40, Thomas Bennett wrote:
bq.  
bq.  -----------------------------------------------------------
bq.  This is an automatically generated e-mail. To reply, visit:
bq.  https://reviews.apache.org/r/4553/
bq.  -----------------------------------------------------------
bq.  
bq.  (Updated 2012-03-29 12:21:40)
bq.  
bq.  
bq.  Review request for oodt, Chris Mattmann, brian Foster, Paul Ramirez, and Sheryl John.
bq.  
bq.  
bq.  Summary
bq.  -------
bq.  
bq.  Get product references before calling retrieveProduct().
bq.  1) call setProductReferences method
bq.  2) remove d.retrieveProduct() outside the if else statement.
bq.  
bq.  Fix unit tests testRetrieveFilesById() and testRetrieveFilesByName()
bq.  1) last method call is now getProductReferences not getProductByName/getProductById
bq.  2) The last method call has the product passed in as the argument. The call has been modified to retrieve the productName/productId correctly from the method call.
bq.  
bq.  
bq.  This addresses bug OODT-433.
bq.      https://issues.apache.org/jira/browse/OODT-433
bq.  
bq.  
bq.  Diffs
bq.  -----
bq.  
bq.    trunk/filemgr/src/main/java/org/apache/oodt/cas/filemgr/cli/action/RetrieveFilesCliAction.java 1306745 
bq.    trunk/filemgr/src/test/org/apache/oodt/cas/filemgr/cli/TestFileManagerCli.java 1306745 
bq.  
bq.  Diff: https://reviews.apache.org/r/4553/diff
bq.  
bq.  
bq.  Testing
bq.  -------
bq.  
bq.  * All unit tests now pass
bq.  * filemgr deployed and tested with the filemgr client using both local and remote data transfer factories.
bq.  
bq.  
bq.  Thanks,
bq.  
bq.  Thomas
bq.  
bq.


                
> 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

        

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

Posted by "Brian Foster (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/OODT-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240730#comment-13240730 ] 

Brian Foster commented on OODT-433:
-----------------------------------

1) ya i agree with chris... getProductBy(Name | Id) should only return the product info... no references
2) again agree with chris... this is a bug... RetrieveFilesCliAction should have asked the filemgr for the references after retrieving the Product
3) the second retrieveProduct should have been removed... which i had gotten fluent with EasyMock when i was doing all the cas-cli stuff... an test around RetrieveFilesCliAction with an EasyMock of the filemgr client would have caught the second unexpected call to retrieveProduct.

So i see 2 changes in this issue:
1) Add fmClient.getProductReferences(product) to RetrieveFilesCliAction:
{code}
if (product != null) {
   product.setProductReferences(fmClient.getProductReferences(product));
   dt.retrieveProduct(product, destination);
} else {
   throw new Exception("Product was not found");
}
{code}
2) Removed the extra dt.retrieveProduct() (the one outside the check null if statment)
                
> 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

        

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

Posted by "jiraposter@reviews.apache.org (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/OODT-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13242503#comment-13242503 ] 

jiraposter@reviews.apache.org commented on OODT-433:
----------------------------------------------------


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/4553/#review6580
-----------------------------------------------------------

Ship it!


LGTM!

- Chris


On 2012-03-30 08:45:40, Thomas Bennett wrote:
bq.  
bq.  -----------------------------------------------------------
bq.  This is an automatically generated e-mail. To reply, visit:
bq.  https://reviews.apache.org/r/4553/
bq.  -----------------------------------------------------------
bq.  
bq.  (Updated 2012-03-30 08:45:40)
bq.  
bq.  
bq.  Review request for oodt, Chris Mattmann, brian Foster, Paul Ramirez, and Sheryl John.
bq.  
bq.  
bq.  Summary
bq.  -------
bq.  
bq.  Get product references before calling retrieveProduct().
bq.  1) call setProductReferences method
bq.  2) remove d.retrieveProduct() outside the if else statement.
bq.  
bq.  Fix unit tests testRetrieveFilesById() and testRetrieveFilesByName()
bq.  1) last method call is now getProductReferences not getProductByName/getProductById
bq.  2) The last method call has the product passed in as the argument. The call has been modified to retrieve the productName/productId correctly from the method call.
bq.  
bq.  
bq.  This addresses bug OODT-433.
bq.      https://issues.apache.org/jira/browse/OODT-433
bq.  
bq.  
bq.  Diffs
bq.  -----
bq.  
bq.    trunk/filemgr/src/main/java/org/apache/oodt/cas/filemgr/cli/action/RetrieveFilesCliAction.java 1306745 
bq.    trunk/filemgr/src/test/org/apache/oodt/cas/filemgr/cli/TestFileManagerCli.java 1306745 
bq.  
bq.  Diff: https://reviews.apache.org/r/4553/diff
bq.  
bq.  
bq.  Testing
bq.  -------
bq.  
bq.  * All unit tests now pass
bq.  * filemgr deployed and tested with the filemgr client using both local and remote data transfer factories.
bq.  
bq.  
bq.  Thanks,
bq.  
bq.  Thomas
bq.  
bq.


                
> 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

        

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

Posted by "Brian Foster (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/OODT-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240735#comment-13240735 ] 

Brian Foster commented on OODT-433:
-----------------------------------

I also think we should add the concept of a LightWeightProduct which would have member variables for ProductId, ProductName, ProductType, etc (all the Product specific variables that should be set by getProductBy[Name | Id])... Product would just extend LightWeightProduct and add all the Reference based stuff... Then several of the methods could have their signatures modified so that they either accept or return a LightWieghtProduct instead of a Product so that it is clear they are not supposed to do anything with the References... This would also still support backward compatibility and passing in a Product object when only a LightWieghtProduct is accepted since Product would be a LightWeightProduct... what you guys think?
                
> 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

        

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

Posted by "Thomas Bennett (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/OODT-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Bennett updated OODT-433:
--------------------------------

    Comment: was deleted

(was: Hey Brian,

+1 from me to. Excellent idea! Thats a really neat solution and makes perfect sense.)
    
> 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

        

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

Posted by "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

        

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

Posted by "Thomas Bennett (Commented) (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 commented on OODT-433:
-------------------------------------

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

        

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

Posted by "Thomas Bennett (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/OODT-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241015#comment-13241015 ] 

Thomas Bennett commented on OODT-433:
-------------------------------------

Hey Brian,

+1 from me to. Excellent idea! Thats a really neat solution and makes perfect sense.
                
> 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

        

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

Posted by "jiraposter@reviews.apache.org (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/OODT-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241453#comment-13241453 ] 

jiraposter@reviews.apache.org commented on OODT-433:
----------------------------------------------------


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/4553/#review6523
-----------------------------------------------------------

Ship it!


LGTM

- brian


On 2012-03-29 12:26:06, Thomas Bennett wrote:
bq.  
bq.  -----------------------------------------------------------
bq.  This is an automatically generated e-mail. To reply, visit:
bq.  https://reviews.apache.org/r/4553/
bq.  -----------------------------------------------------------
bq.  
bq.  (Updated 2012-03-29 12:26:06)
bq.  
bq.  
bq.  Review request for oodt, Chris Mattmann, brian Foster, Paul Ramirez, and Sheryl John.
bq.  
bq.  
bq.  Summary
bq.  -------
bq.  
bq.  Get product references before calling retrieveProduct().
bq.  1) call setProductReferences method
bq.  2) remove d.retrieveProduct() outside the if else statement.
bq.  
bq.  Fix unit tests testRetrieveFilesById() and testRetrieveFilesByName()
bq.  1) last method call is now getProductReferences not getProductByName/getProductById
bq.  2) The last method call has the product passed in as the argument. The call has been modified to retrieve the productName/productId correctly from the method call.
bq.  
bq.  
bq.  This addresses bug OODT-433.
bq.      https://issues.apache.org/jira/browse/OODT-433
bq.  
bq.  
bq.  Diffs
bq.  -----
bq.  
bq.    trunk/filemgr/src/test/org/apache/oodt/cas/filemgr/cli/TestFileManagerCli.java 1306745 
bq.    trunk/filemgr/src/main/java/org/apache/oodt/cas/filemgr/cli/action/RetrieveFilesCliAction.java 1306745 
bq.  
bq.  Diff: https://reviews.apache.org/r/4553/diff
bq.  
bq.  
bq.  Testing
bq.  -------
bq.  
bq.  * All unit tests now pass
bq.  * filemgr deployed and tested with the filemgr client using both local and remote data transfer factories.
bq.  
bq.  
bq.  Thanks,
bq.  
bq.  Thomas
bq.  
bq.


                
> 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