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?
if the default, and you're deploying some-app.war
, are you hitting /some-app/
?
@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
the 302 is a redirect, where is it redirecting you to?
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?
you can try setting a host header to <the domain> on the curl request
Well right now the domain is set to localhost on the remote server
do you have something that is ensuring https? is the redirect to https://?
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/ ...
so it's a redirect loop?
or is the ... a subcontext?
I don't know where the redirect loop comes from because lein run
seems to not have any issues
any way you can share a project with me that recreates this?
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
no, that is the proper way to do it with immutant
that will get called both inside and outside the container
assuming that main is calling immutant.web/run
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?
the simplest way to do that is to rename the war to ROOT.war (case is important)
No, it has to be in some other context as that is a requirement I was given
yes, the :host
and :port
options are ignored when in-container, yes
OK, good, just checking
can you run WildFly locally on your dev macnine?
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
I don't know what would cause this, generally.
(Which is weird because my ring middleware stack is basically the same as my other non-Immutant web app)
That's the only guidance I have, really
does the non-Immutant app run in WF?
ah, right, it does
Yep, that's the one you gave me the fix for
that's the one with the :vfs issue
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
are you using basic auth?
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
if you aren't doing that, you'll be getting the default web.xml we provide
which has that listener-class setting in it
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.
@kardan: can you share your duct code?
how are you starting immutant? what are you passing to immutant.web/run
?
when using immutant, does that pprint get triggered?
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
called or not, software makes fools of us all every day
Tell me about it
Hmm no, I still only get a "Resource not found” reply when using Immutant
is that from the browser? what happens if you try to curl to the app?
I just get connection refused. I wonder if I do something odd
that makes me think that immutant isn't actually getting started then
what port are you connecting to?
immutant will start on 8080 by default
not sure what aleph's default is
It should be 3000, the default Duct template feed an option map {:port 3000}
I’m testing both right now
you should see 09:06:36.276 INFO [org.projectodd.wunderboss.web.Web] (main) Registered web context /
when immutant starts
Yes
I also looked the response headers and saw that I got a 404 from Undertow
on 8080 or 3000?
I think that was on 3000
Maybe I need to take a step back and organise myself a bit
and what are the full options that are being passed to immutant.web/run
?
sure
I thought I would ask if it was know to not work
no, it should work, we have lots of users using component
but I'm happy to help you figure it out
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
Thanks. Need to hit out and get kids soon so I might take a break and try later
you can't have too many kids
@trancehime: morning! catching up with your struggles, you wouldn't happen to be passing a :path
option to web/run
would you?
I tried with and without
(I think)
@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
TIL
@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.
true
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