Issue Details (XML | Word | Printable)

Key: GALAXY-194
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Andrew Perepelytsya
Reporter: Todd Wells
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Galaxy

Galaxy presumes war is deployed in the root context

Created: 21/Apr/08 10:53 AM   Updated: 04/May/08 09:48 AM
Component/s: Core
Affects Version/s: 1.0-beta-2
Fix Version/s: 1.0-RC

Time Tracking:
Not Specified

Environment: Jetty 6.1.6
Issue Links:
Duplicate
 
Related
 

Labels:
User impact: High


 Description  « Hide
I took the galaxy beta 2 war and renamed it "galaxy.war" and dropped it in my jetty/webapps dir. It seemed to start up just fine, and I could successfully browse to http://server:8080/galaxy. But when I hit the ATOM feeds it fails with

HTTP ERROR: 404

NOT_FOUND

RequestURI=/api/registry/Default%20Workspace/hello-config.xml

From the error, it seems as if galaxy is presuming that it has been deployed at the root context of the web server.



 All   Comments   Work Log   Change History   Transitions   FishEye      Sort Order: Ascending order - Click to sort in descending order
Andrew Perepelytsya added a comment - 21/Apr/08 11:02 AM
Todd, have you tried with beta 3? This sounds like something which has been fixed already.

Dan Diephouse added a comment - 21/Apr/08 11:48 AM
I don't remember fixing any issues around this - but I asked Todd to file this so we could be sure to test it before b3 goes out.

Andrew Perepelytsya added a comment - 21/Apr/08 11:55 AM
Todd, could you please specify a full url you use? Do you just type it in a browser?

Todd Wells added a comment - 21/Apr/08 12:12 PM
I was just clicking on the feed link in the UI, e.g. http://server:8080/api/registry/Default%20Workspace/hello-config.xml?view=history

Todd Wells added a comment - 21/Apr/08 12:13 PM
To further clarify – the UI links seem to assume the root context, so the links (as in my above comment) are incorrect, they don't have the "galaxy" part of the path in the URL.


Andrew Perepelytsya added a comment - 24/Apr/08 08:22 PM
getServletContextName() is not a reliable source of this info, as the behavior is not consistent across containers (unfortunately). The best way is to get it from request.getContextPath(), but the catch is there's no request object available when the links are generated, thus the need to intercept and store it somewhere.

Andrew Perepelytsya added a comment - 25/Apr/08 08:35 AM
Reworked the solution to cover more cases reliably in http://fisheye.muleforge.org/changelog/galaxy/?cs=804