Fork me on GitHub
#immutant
<
2016-02-03
>
trancehime03:02:27

cURL didn't return anything...

trancehime03:02:59

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

tcrawley11:02:25

@trancehime: what is the status code?

tcrawley11:02:41

how is the app deployed? are you overriding the context-path at all? or using the default?

tcrawley11:02:17

if the default, and you're deploying some-app.war, are you hitting /some-app/?

trancehime12:02:04

@tcrawley: I'm using scanner in the Wildfly; status code is HTTP1.1 302

trancehime12:02:27

context-path is set to /crowd and I am deploying crowd.war

trancehime12:02:35

I do to /crowd/

trancehime13:02:29

So basically, cURL gives me a response of HTTP1.1 302 but when I try to access the URL normally, it gives me 403

tcrawley13:02:31

the 302 is a redirect, where is it redirecting you to?

tcrawley13:02:53

and by accessing normally, do you mean in a browser directly against WildFly, or against nginx?

trancehime13:02:29

the cURL response just regurgitated the same URL as normal <the domain>/crowd/ And as for accessing normally, I meant the latter

tcrawley13:02:24

where <the domain> is the domain where nginx is listening? do you have something in the app itself that explicitly redirects to that?

tcrawley13:02:42

you can try setting a host header to <the domain> on the curl request

trancehime13:02:48

Well right now the domain is set to localhost on the remote server

tcrawley13:02:19

do you have something that is ensuring https? is the redirect to https://?

trancehime13:02:44

And, as far as I am concerned, I do not force https either.

tcrawley13:02:37

so, when you curl directly against http://localhost:8080/crowd/, it redirects you to http://localhost/crowd/?

tcrawley13:02:44

so it's a redirect loop?

tcrawley13:02:56

or is the ... a subcontext?

trancehime13:02:43

I don't know where the redirect loop comes from because lein run seems to not have any issues

tcrawley13:02:33

any way you can share a project with me that recreates this?

trancehime13:02:34

And nah. "..." isn't subcontext

trancehime13:02:26

Actually, would the fact my project's using -main to initialize the web handler have anything to do with it

tcrawley13:02:49

no, that is the proper way to do it with immutant

tcrawley13:02:01

that will get called both inside and outside the container

tcrawley13:02:10

assuming that main is calling immutant.web/run

trancehime13:02:24

Yeah. I'm using immutant.web/run

trancehime13:02:55

And I guess :port is overriden right?

tcrawley13:02:17

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?

tcrawley13:02:38

the simplest way to do that is to rename the war to ROOT.war (case is important)

trancehime13:02:45

No, it has to be in some other context as that is a requirement I was given

tcrawley13:02:03

yes, the :host and :port options are ignored when in-container, yes

trancehime13:02:13

OK, good, just checking

tcrawley13:02:14

can you run WildFly locally on your dev macnine?

trancehime13:02:26

I suppose I'll need to try that

trancehime13:02:39

Would there be any kind of general causes for this problem though that I could look into?

trancehime13:02:57

Similar to what you suggested about something in my ring middleware stack not playing nicely with subcontexts

tcrawley13:02:10

I don't know what would cause this, generally.

trancehime13:02:11

(Which is weird because my ring middleware stack is basically the same as my other non-Immutant web app)

tcrawley13:02:24

That's the only guidance I have, really

tcrawley13:02:32

does the non-Immutant app run in WF?

tcrawley13:02:41

ah, right, it does

trancehime13:02:47

Yep, that's the one you gave me the fix for

tcrawley13:02:48

that's the one with the :vfs issue

trancehime13:02:58

Which is now perfectly fine thanks to the fix you gave me

trancehime13:02:26

What a strange problem...

tcrawley13:02:00

I'd try the immutant app locally in WildFly at the /crowd context, see if it redirects. if so, try it at /

tcrawley13:02:31

if it doesn't redirect at either, I would suspect something in the wildfly config (though I don't know what that would be)

tcrawley13:02:01

but if you don't mind checking locally, let me know what you find and we'll go from there

trancehime13:02:18

OK, reminder to self I will use Wildfly 9.0.2.Final locally as that is what was set up on the remote server

trancehime13:02:56

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

trancehime13:02:09

I'd think if it was really a problem with my project code, I'd have gotten log complaints...

trancehime13:02:06

For the mean time, I'll try doing some further investigation Z_Z

tcrawley13:02:31

if you can recreate the issue locally, can you share a gist of the middleware stack at least?

trancehime13:02:54

Yeah, definitely

trancehime13:02:47

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

tcrawley13:02:40

are you using basic auth?

tcrawley13:02:43

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

tcrawley13:02:00

if you aren't doing that, you'll be getting the default web.xml we provide

tcrawley13:02:12

which has that listener-class setting in it

trancehime13:02:22

Well, I'm using friend

kardan13:02:28

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.

tcrawley13:02:56

@kardan: can you share your duct code?

tcrawley13:02:27

how are you starting immutant? what are you passing to immutant.web/run?

tcrawley13:02:03

when using immutant, does that pprint get triggered?

kardan13:02:00

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

tcrawley13:02:30

called or not, software makes fools of us all every day

trancehime13:02:42

Tell me about it

kardan13:02:09

Hmm no, I still only get a "Resource not found” reply when using Immutant

tcrawley13:02:44

is that from the browser? what happens if you try to curl to the app?

kardan14:02:58

I just get connection refused. I wonder if I do something odd

tcrawley14:02:20

that makes me think that immutant isn't actually getting started then

tcrawley14:02:24

what port are you connecting to?

tcrawley14:02:30

immutant will start on 8080 by default

tcrawley14:02:36

not sure what aleph's default is

kardan14:02:59

It should be 3000, the default Duct template feed an option map {:port 3000}

kardan14:02:13

I’m testing both right now

tcrawley14:02:15

you should see 09:06:36.276 INFO [org.projectodd.wunderboss.web.Web] (main) Registered web context / when immutant starts

kardan14:02:08

I also looked the response headers and saw that I got a 404 from Undertow

tcrawley14:02:30

on 8080 or 3000?

kardan14:02:15

I think that was on 3000

kardan14:02:31

Maybe I need to take a step back and organise myself a bit

tcrawley14:02:34

and what are the full options that are being passed to immutant.web/run

kardan14:02:52

I thought I would ask if it was know to not work

tcrawley14:02:16

no, it should work, we have lots of users using component

tcrawley14:02:23

but I'm happy to help you figure it out

kardan14:02:25

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

tcrawley14:02:37

sure thing, just let me know if I can offer any more guidance once you are organized

kardan14:02:03

Thanks. Need to hit out and get kids soon so I might take a break and try later

tcrawley14:02:22

you can't have too many kids

jcrossley314:02:26

@trancehime: morning! catching up with your struggles, you wouldn't happen to be passing a :path option to web/run would you?

kardan14:02:40

I tried with and without

trancehime14:02:01

@jcrossley3: I am passing a :path option but it is the same name as the .WAR file

jcrossley314:02:10

if your app is called ctx.war, passing :path /ctx will result in a path of /ctx/ctx

trancehime14:02:10

Good morning to you too

tcrawley14:02:51

@jcrossley3: thanks for thinking of that :)

jcrossley314:02:17

it still may not solve anything

trancehime14:02:01

Hmm. Well still it's worth a shot.

trancehime14:02:41

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

trancehime14:02:22

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.

jcrossley314:02:33

best thing would be to bypass nginx for a sanity check, but that may not be possible

trancehime14:02:31

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

trancehime14:02:51

(As you can tell, I'm pretty horrid when it comes to app deployment)

jcrossley314:02:00

that @tcrawley has got it going on

jcrossley314:02:59

app deployment is like staining a plywood floor: easy to underestimate the difficulty and a pita to fix if you get it wrong

trancehime15:02:36

Well, it's getting late, so it's time for bed

jrotenberg23:02:54

“well, the rest of the team knows scala, so lets just write it in that"

jrotenberg23:02:05

“sure, no problem"

jrotenberg23:02:20

quietly goes back to desk and updates linkedin profile