[
https://issues.apache.org/jira/browse/OODT-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Barber updated OODT-626:
----------------------------
Fix Version/s: (was: 0.8)
0.9
> Unit tests for TestDeleteProductByName and TestDeleteProductById don't
> override all needed methods in getClient
> ---------------------------------------------------------------------------------------------------------------
>
> Key: OODT-626
> URL: https://issues.apache.org/jira/browse/OODT-626
> Project: OODT
> Issue Type: Bug
> Components: file manager
> Environment: Mac OS X 10.8.3
> [chipotle:oodt/trunk/filemgr] mattmann% java -version
> java version "1.6.0_45"
> Java(TM) SE Runtime Environment (build 1.6.0_45-b06-451-11M4406)
> Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01-451, mixed mode)
> [chipotle:oodt/trunk/filemgr] mattmann%
> Reporter: Chris A. Mattmann
> Fix For: 0.9
>
>
> While investigating a possible policy bug, I ran into the issue with the
> following two hanging action tests:
> * TestDeleteProductByIdAction
> * TestDeleteProductByNameAction
> Take the first action test, TestDeleteProductByIdAction. While investigating,
> I found that it hangs in this method on line 75 where it is creating a mock
> object FalseDeleteProductByNameCliAction.
> {code:java}
> cliAction = new FalseDeleteProductByNameCliAction();
> cliAction.setProductName(PRODUCT_NAME);
> try {
> cliAction.execute(printer);
> fail("Expected throw CmdLineActionException");
> } catch (CmdLineActionException ignore) {
> }
> {code}
> The actual line it hangs in is in cliAction.execute. Looking in that line it
> seems to hang because in AbstractDeleteProductionAction, line 50, due to this
> code block:
> {code:java}
> for (Reference ref : refs) {
> if (!client.removeFile(new File(new
> URI(ref.getDataStoreReference()))
> .getAbsolutePath())) {
> throw new Exception("Failed to delete file '"
> + ref.getDataStoreReference() + "'");
> }
> }
> {code}
> Basically it seems that TestGetDeleteProductByIdAction and its subclass
> FalseDeleteProductByNameCliAction do not define the method, removeFile, which
> in turn is called by the above code. The only problem is that version of that
> function that is called is the XmlRpcFileManagerClient#removeFile, which
> actually tries to make an XmlRpc connection. Because of the code here:
> {code:java}
> CommonsXmlRpcTransport transport = new CommonsXmlRpcTransport(
> url, client);
> transport
> .setConnectionTimeout(Integer
> .getInteger(
>
> "org.apache.oodt.cas.filemgr.system.xmlrpc.connectionTimeout.minutes",
> 20).intValue() * 60 * 1000);
> transport
> .setTimeout(Integer
> .getInteger(
>
> "org.apache.oodt.cas.filemgr.system.xmlrpc.requestTimeout.minutes",
> 60).intValue() * 60 * 1000);
> {code}
> it seems like this test should hang forever, and time out (or at least for 60
> minutes). However, we don't notice this...on tests that run on our own
> Jenkins server:
> https://builds.apache.org/job/oodt-trunk/964/org.apache.oodt$cas-filemgr/console
> Or on some of our dev computers (e.g., Andrew Hart's ubtuntu VM).
> Also I don't remember this failing over the past year too much and this code
> has existed for well over this time. So, I'm stumped. In the interest of
> helping anyone else that has this problem I attach a patch that fixes these 2
> tests by adding local override implementations of the methods removeFile and
> others required to intercept the calls and to stay away from XML-RPC calls.
> Brian Foster or anyone else it would be great if you can comment here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
