Clojurians Log v2

@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

@kardan has joined the channel

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&amp;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?

https://gist.github.com/kardan/e810801e78fb6277ede4

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

thinks @jcrossley3 has done that recently

is working on his metaphors

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

Damn.

cURL didn't return anything...

It connected, but the content-length of the response is 0.