Skip to content
This repository has been archived by the owner on Oct 21, 2022. It is now read-only.

Problem with "fetch" when deploying as a war #9

Open
murtaza52 opened this issue Apr 20, 2012 · 2 comments
Open

Problem with "fetch" when deploying as a war #9

murtaza52 opened this issue Apr 20, 2012 · 2 comments

Comments

@murtaza52
Copy link

I am including the conversation from clj-noir list -

Hi,

I have a clojurescript app which uses fetch for remoting. The app works fine when run as lein run. However when compiled as an uberwar and deployed on jetty, I can see the following error in chrome's js console -

POST http://localhost:8080/_fetch 404 (Not Found)

The url I am using to access the system is http://localhost:8080/tms. All other resources such as css, and css get resolved correctly.

I also tried setting the {:base-url "/tms"} option in my handler, but that didnt help too.

It seems fetch should be making a call to tms/_fetch while it is making a call to /_fetch? How do I resolve this ?

Another observation - I tried deploying it on elasticbeanstalk with tomcat and it works!

So it fails in jetty 6 while works in tomcat 7!

Thanks,
Murtaza

Mark Rathwell mark.rathwell@gmail.com
7:53 PM (34 minutes ago)

to clj-noir

Another observation - I tried deploying it on elasticbeanstalk with tomcat
and it works!

But on elasticbeanstalk, the servlet is running in the root context
('/' not '/tms'), right? I don't see a built-in way for fetch to
handle a context path, so you should probably open an issue on github
[1].

[1] https://github.com/ibdknox/fetch/issues

Murtaza Husain
8:29 PM (0 minutes ago)

to clj-noir
Yes it is running as root in beanstalk.

Thanks, I will open an issue.

@ejackson
Copy link

ejackson commented May 8, 2012

I have the same problem. When deploying into tomcat6 my app is put into a context path, and fetch points at the root, rather than the context path. I'm happy to patch this if somebody can point me in the direction of figuring out what the context path is in a running app ?

@ejackson
Copy link

ejackson commented May 8, 2012

OK, I've got a workaround.

  • At first I pulled the context from the Ring request and passed that up to the .cljs and stitched it into the remote-uri var. Amusingly, something in the javascritp notices this and ADDS BACK IN the context path, so now I have it twice. So the original, incorrect, request goes to

http://myserver/_fetch

when I want to to got to

http://myserver/mycontext/_fetch

and by changing remote-uri to "mycontext/_fetch" I now have

http://myserver/mycontext/mycontext/_fetch.

How fun.

I don't know enough to figure out who is responsible for doing this. Maybe xhr or tomcat, or some interaction ?

  • So until a better solution can be found I've worked around the problem by adding a second _fetch handler to the noir side under the URI "/remotes/fetch" and on the cljs side stitched in a "remotes" to the remote-uri. Its not great, but its a workaround. So now by having this more complex URI the context gets magically reinserted and points to my handler. Baroque.

Code changes here:
https://github.com/ejackson/fetch/blob/master/src/noir/fetch/remotes.clj#L38
and here:
https://github.com/ejackson/fetch/blob/master/src/fetch/remotes.cljs

If anybody think of something better, or what I need to do to make this patchable, I'd love to fix this properly.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants