• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • Build & Test
  • qa
  • Reporter: wharley
  • March 23, 2009
  • 0
  • Watchers: 1
  • February 12, 2013
  • May 05, 2009

Description

When not logged into VPN, and running container tests based on AbstractTwoServerDeploymentTest, the following below banner and exception are always printed to the console. The error is innocuous and does not indicate a problem, but it is annoying and distracting. The “error” is simply showing that the Kong repository was not available and tim-get is falling back to the terracotta.org repository. It is appropriate to indicate which index location was eventually used, but there should not be an error banner or exception stack printed because this is not an error nor an exceptional condition, it is normal behavior for anyone not on the VPN.

The call generating the banner and exception is in ServerManager.runTimGet.

Personally my preference would be to simply output which index location is being used, and not even mention the fallback. If it is deemed important to show the reason why an earlier index location was not used, then I think we should be asking the question of why *.terracotta.lan locations are really necessary and what that means for our open source partners.

Logging in to Terracotta’s LAN should not be a requirement for error-free test output; and tests should not print “ERROR” to the console unless there is actually an error.

********************************** ERROR *********************************** * Error using url [http://forge-stage.terracotta.lan/api/2/index.xml.gz] * for tim-get, moving on to the next one ****************************************************************************

java.lang.RuntimeException: Unable to read TIM index: forge-stage.terracotta.lan at org.terracotta.modules.tool.CachedModules.loadData(CachedModules.java:141) at org.terracotta.modules.tool.CachedModules.list(CachedModules.java:239) at org.terracotta.modules.tool.CachedModules.find(CachedModules.java:178) at org.terracotta.modules.tool.commands.OneOrAllCommand.process(OneOrAllCommand.java:70) at org.terracotta.modules.tool.commands.InstallCommand.execute(InstallCommand.java:70) at org.terracotta.modules.tool.commands.CommandRegistry.executeCommand(CommandRegistry.java:52) at org.terracotta.modules.tool.commands.CommandRegistry.executeCommand(CommandRegistry.java:59) at org.terracotta.tools.cli.TIMGetTool.execute(TIMGetTool.java:90) at org.terracotta.tools.cli.TIMGetTool.mainWithExceptions(TIMGetTool.java:55) at com.tc.test.server.appserver.deployment.ServerManager.runTimGet(ServerManager.java:435) at com.tc.test.server.appserver.deployment.ServerManager.internalResolve(ServerManager.java:393) at com.tc.test.server.appserver.deployment.ServerManager.resolveContainerTIM(ServerManager.java:385) at com.tc.test.server.appserver.deployment.ServerManager.prepareClientTcConfig(ServerManager.java:312) at com.tc.test.server.appserver.deployment.ServerManager.makeWebApplicationServer(ServerManager.java:193) at com.tc.test.server.appserver.deployment.AbstractTwoServerDeploymentTest$TwoServerTestSetupBase.createServer(AbstractTwoServerDeploymentTest.java:102) at com.tc.test.server.appserver.deployment.AbstractTwoServerDeploymentTest$TwoServerTestSetupBase.setUp(AbstractTwoServerDeploymentTest.java:75) at com.tctest.ContainerHibernate325Test$ContainerHibernateTestSetup.setUp(ContainerHibernate325Test.java:137) at junit.extensions.TestSetup$1.protect(TestSetup.java:20) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:25) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:165) at org.apache.maven.surefire.Surefire.run(Surefire.java:107) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:289) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1005)

Comments

Alex Miller 2009-03-23

Agreed on the error. I believe we are still in transit towards a more public staging repository so from an external point of view, I think we are moving towards a better solution.

Alex Miller 2009-03-24

I think the other thing that’s at play here is that we’re executing the TimGet tool via code and we had problems before with swallowing exceptions so here we are seeing the result of just catching a generic RuntimeException. So, there are other cases where we really do want an error banner / stack trace here.

Alex Miller 2009-03-24

I added a new more specific exception to tim-get-tool that will be thrown when the repository index can’t be read and added code to ServerManager to treat this case specially by printing just an info (not an error) and no stack trace. Default behavior for catching RuntimeException from tim-get is unchanged.

Unfortunately this is difficult to test in trunk till we branch the tims, so leaving open for now.

Fiona OShea 2009-04-10

Please verify if still occuring in 3.0 branch

nadeem ghani 2009-04-29

Can’t see this problem on either trunk or tc-3.0 branch.