This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-02-03
Channels
- # aatree (5)
- # admin-announcements (52)
- # announcements (1)
- # aws (2)
- # beginners (55)
- # boot (494)
- # braid-chat (17)
- # cider (2)
- # cljsjs (4)
- # cljsrn (8)
- # clojure (157)
- # clojure-austin (6)
- # clojure-czech (7)
- # clojure-denmark (1)
- # clojure-dev (102)
- # clojure-ireland (6)
- # clojure-japan (4)
- # clojure-miami (2)
- # clojure-poland (90)
- # clojure-russia (415)
- # clojurebridge (2)
- # clojurescript (143)
- # core-async (1)
- # datavis (4)
- # datomic (20)
- # devcards (5)
- # dirac (40)
- # emacs (9)
- # events (103)
- # gorilla (1)
- # immutant (122)
- # jobs (3)
- # ldnclj (20)
- # lein-figwheel (1)
- # mount (2)
- # off-topic (22)
- # om (170)
- # onyx (7)
- # overtone (6)
- # parinfer (100)
- # proton (2)
- # re-frame (5)
- # reagent (32)
- # ring-swagger (2)
- # spacemacs (6)
Damn.
cURL didn't return anything...
It connected, but the content-length of the response is 0.
@trancehime: what is the status code?
how is the app deployed? are you overriding the context-path at all? or using the default?
@tcrawley: I'm using scanner in the Wildfly; status code is HTTP1.1 302
context-path
is set to /crowd
and I am deploying crowd.war
I do to /crowd/
So basically, cURL gives me a response of HTTP1.1 302 but when I try to access the URL normally, it gives me 403
and by accessing normally, do you mean in a browser directly against WildFly, or against nginx?
the cURL response just regurgitated the same URL as normal <the domain>/crowd/
And as for accessing normally, I meant the latter
where <the domain> is the domain where nginx is listening? do you have something in the app itself that explicitly redirects to that?
Well right now the domain is set to localhost on the remote server
It is not
And, as far as I am concerned, I do not force https either.
so, when you curl directly against http://localhost:8080/crowd/, it redirects you to http://localhost/crowd/?
It redirects to http://localhost:8080/crowd/ ...
I don't know where the redirect loop comes from because lein run
seems to not have any issues
And nah. "..." isn't subcontext
Actually, would the fact my project's using -main
to initialize the web handler have anything to do with it
Yeah. I'm using immutant.web/run
And I guess :port
is overriden right?
maybe you are using something in your ring middleware stack that doesn't like being at a subcontext. Would it be possible to deploy this at the root context in WildFly?
No, it has to be in some other context as that is a requirement I was given
OK, good, just checking
I suppose I'll need to try that
Would there be any kind of general causes for this problem though that I could look into?
Similar to what you suggested about something in my ring middleware stack not playing nicely with subcontexts
(Which is weird because my ring middleware stack is basically the same as my other non-Immutant web app)
Yep, that's the one you gave me the fix for
Which is now perfectly fine thanks to the fix you gave me
What a strange problem...
I'd try the immutant app locally in WildFly at the /crowd context, see if it redirects. if so, try it at /
if it doesn't redirect at either, I would suspect something in the wildfly config (though I don't know what that would be)
but if you don't mind checking locally, let me know what you find and we'll go from there
OK, reminder to self I will use Wildfly 9.0.2.Final locally as that is what was set up on the remote server
And really, I don't have any other options but to take this approach to try and uncover potential reasons for this problem. It's quite mindboggling
I'd think if it was really a problem with my project code, I'd have gotten log complaints...
For the mean time, I'll try doing some further investigation Z_Z
if you can recreate the issue locally, can you share a gist of the middleware stack at least?
Yeah, definitely
https://developer.jboss.org/thread/249050?start=0&tstart=0 this is pretty much the only clue I could find on it before I decided to ask here, but I don't know where to find a web.xml
We generate a web.xml for you and put it in the war. You can override the web.xml used with the :resource-paths option to the immutant plugin
Well, I'm using friend
I tried to hook up immutant/web with Duct, according to https://github.com/weavejester/ring-jetty-component/blob/master/src/ring/component/jetty.clj. For some reason I can’t get Immutant to not reply with a 404. If I swap to Aleph it works. Do anyone know if there is something inherit with how Immutant works that don’t fly with the Duct setup? Or is the guess that I’m just doing something wrong? I tried to start Immutant without and without options.
I added that when I was trying to find out what was going on. I need to double check that I’m not a fool
Tell me about it
you should see 09:06:36.276 INFO [org.projectodd.wunderboss.web.Web] (main) Registered web context /
when immutant starts
I’m very thankful, but right now it feels like I steal your time and I’m a bit unorganised with what I have done
sure thing, just let me know if I can offer any more guidance once you are organized
@trancehime: morning! catching up with your struggles, you wouldn't happen to be passing a :path
option to web/run
would you?
@jcrossley3: I am passing a :path
option but it is the same name as the .WAR file
if your app is called ctx.war
, passing :path /ctx
will result in a path of /ctx/ctx
Good morning to you too
...welp
@jcrossley3: thanks for thinking of that :)
it still may not solve anything
Hmm. Well still it's worth a shot.
Since for most of my general playing about with it I've been passing a :path
option of /crowd
and deploying the .WAR file under the name crowd.war
The browser path may just have /crowd/
as context, it may actually be treated by the server as /crowd/crowd
as you said which is not handled by nginx.
best thing would be to bypass nginx for a sanity check, but that may not be possible
That is what @tcrawley had suggested to me in the first place, but I had enough trouble even getting any of my web apps to properly be hosted on a virtual url without it
(As you can tell, I'm pretty horrid when it comes to app deployment)
that @tcrawley has got it going on
app deployment is like staining a plywood floor: easy to underestimate the difficulty and a pita to fix if you get it wrong
Well, it's getting late, so it's time for bed
aww man
“well, the rest of the team knows scala, so lets just write it in that"
“sure, no problem"
quietly goes back to desk and updates linkedin profile