Community
Participate
Working Groups
All errors have the same cause: "java.lang.RuntimeException: No protocol specified in URL '/workspace/A'" when trying to create a project. Probably caused by bug 341928.
The UI is not broken and I still can create new users, new workspaces and folders inside. Boris, is your fix a temporary solution? Shouldn't the locations be a non-relative URIs? Right now I can't copy locations from JSON representations and give it to another guy to open it.
I was hoping that the changes I made can be permanent. Sorry for breaking the tests! My assumption was that removing scheme, host, and port from JSON does not introduce ambiguity as to which server is addressed. In the following example request: GET http://server.com:8080/some/resource with returned JSON as follows: { nextURL: 'otherResource', previousURL: '/path/parent', searchURL: 'http://otherserver.com:80/look/here'} the URLs should be interpreted as follows, shouldn't they: nextURL: http://server.com:8080/some/otherResource previousURL: http://server.com:8080/path/parent searchURL: http://otherserver.com:80/look/here How can I run the tests myself? I can try to make them pass again.
If you comment out the following line in OrionServlet.java, do the tests pass again? removeOwnProtocolHostPort((JSONObject) result, req.getScheme(), req.getServerName(), req.getServerPort()); Pasting a stack trace from one of the test failures would help.
(In reply to comment #2) > How can I run the tests myself? I can try to make them pass again. Use org.eclipse.orion.server.tests/launchConfigurations/All Server Tests.launch
(In reply to comment #3) > If you comment out the following line in OrionServlet.java, do the tests pass > again? Nope, it didn't help :| > Pasting a stack trace from one of the test failures would help. java.lang.RuntimeException: No protocol specified in URL '/workspace/A' at com.meterware.httpunit.WebRequest.newURL(WebRequest.java:113) at com.meterware.httpunit.WebRequest.getURL(WebRequest.java:90) at com.meterware.httpunit.WebConversation.getRequestURL(WebConversation.java:147) at com.meterware.httpunit.WebConversation.newResponse(WebConversation.java:69) at com.meterware.httpunit.WebClient.createResponse(WebClient.java:647) at com.meterware.httpunit.WebWindow.getResource(WebWindow.java:220) at com.meterware.httpunit.WebWindow.getSubframeResponse(WebWindow.java:181) at com.meterware.httpunit.WebWindow.getResponse(WebWindow.java:158) at com.meterware.httpunit.WebClient.getResponse(WebClient.java:122) at org.eclipse.orion.server.tests.servlets.workspace.WorkspaceServiceTest.testCreateProject(WorkspaceServiceTest.java:125) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:600) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.junit.runners.Suite.runChild(Suite.java:128) at org.junit.runners.Suite.runChild(Suite.java:24) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:62) at org.eclipse.pde.internal.junit.runtime.CoreTestApplication.run(CoreTestApplication.java:23) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:600) at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:587) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:198) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:600) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577) at org.eclipse.equinox.launcher.Main.run(Main.java:1410) at org.eclipse.equinox.launcher.Main.main(Main.java:1386)
(In reply to comment #2) > My assumption was that removing scheme, host, and port from JSON does not > introduce ambiguity as to which server is addressed. In the following example > request: > > GET http://server.com:8080/some/resource > > with returned JSON as follows: > > { nextURL: 'otherResource', previousURL: '/path/parent', searchURL: > 'http://otherserver.com:80/look/here'} > > the URLs should be interpreted as follows, shouldn't they: > > nextURL: http://server.com:8080/some/otherResource > previousURL: http://server.com:8080/path/parent > searchURL: http://otherserver.com:80/look/here We used to use the Location field to carry the full URI with it. Right now the information will be lost, when you pass JSON to another widget/component. Example: 1. call GET http://server.com:8080/some/resource 2. you get { nextURL: 'otherResource', previousURL: '/path/parent', searchURL: > 'http://otherserver.com:80/look/here'} 3. JSON is passed to another service or component 4. the other service wants to process 'nextURL'
(In reply to comment #6) > We used to use the Location field to carry the full URI with it. Right now the > information will be lost, when you pass JSON to another widget/component. > Example: > > 1. call GET http://server.com:8080/some/resource > 2. you get { nextURL: 'otherResource', previousURL: '/path/parent', searchURL: > > 'http://otherserver.com:80/look/here'} > 3. JSON is passed to another service or component > 4. the other service wants to process 'nextURL' This is only a problem if one component comes from a different server/port combination than the other component, i.e. if Orion "plugins" are involved. Given that components with a different server/port combination cannot open HTTP connections to foreign hosts anyway, I don't see why this would be a problem. Or am I missing something?
(In reply to comment #7) > This is only a problem if one component comes from a different server/port > combination than the other component, i.e. if Orion "plugins" are involved. > Given that components with a different server/port combination cannot open HTTP > connections to foreign hosts anyway, I don't see why this would be a problem. > Or am I missing something? I'm not sure, but if a JSON is passed to a component with a different server/port combination, this other component may include URIs from the JSON on a page. I could also imagine that JSON is passed to a server and we want the server to access Location(s) from the JSON. And there is no such limitation on the server side about HTTP connections.
I am still working on this.
John has reverted the fix in http://git.eclipse.org/c/e4/org.eclipse.orion.server.git/commit/?id=79520e5fb30762ff17e1024baf016773b7922208.
Tests are passing again now with this fix to the "make absolute" logic in the test suites: http://git.eclipse.org/c/e4/org.eclipse.orion.server.git/commit/?id=a9950778c2ca532a65b8254285c4d5f09f575d02
Verified with results for http://download.eclipse.org/e4/orion/drops/I201105170200/.
