Clojurians Log v2

Any tips on creating a WAR from BOOT that will work in wildfly 8.2? Going from the original deps in my POM that creates a working WAR, adding in hoplon front end deps,etc. When deploying it fails on NoClassDefFoundError: org/jboss/modules/Module. I never need this before. I add the dep to build.boot. The new WAR fails, says weld.weldclassintrospector is missing. Any Ides?

@symbit: how are you creating the war? are you using http://github.com/immutant/boot-immutant?

first I heard of it.

Am using the war boot task.

hmm, looks like we don't mention it in the WildFly guide, only lein-immutant: http://immutant.org/documentation/2.1.3/apidoc/guide-wildfly.html#h5392

Immutant-based wars need a little extra sauce in them so Immutant can tie in to WildFly internals

I'm not sure if it's relevant, but the NPE is at https://github.com/projectodd/wunderboss-release/blob/master/wildfly/core/src/main/java/org/projectodd/wunderboss/as/CoreServiceActivator.java#L33

that's what's tripping you up

NPE, or NCFE?

yes

NCDFE, that is

Caused by: java.lang.NullPointerException at org.projectodd.wunderboss.as.CoreServiceActivator.activate(CoreServiceActivator.java:33) at org.jboss.as.server.deployment.service.ServiceActivatorProcessor.deploy(ServiceActivatorProcessor.java:70) [wildfly-server-8 .2.0.Final.jar:8.2.0.Final] at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.2.0.Final.jar:8.2.0.Final]

either no module of the identifier is null. I haven't used/need this before when using mvn package and the clojure-maven-plugin

have you built immutant wars with mvn package that worked?

Yes

interesting. are you inserting a jboss-deployment-structure.xml in that war? otherwise, you should see the NCDFE

the NPE likely means the module isn't found, which is probably happening because you are now bundling jboss-modules in the war, so there are two copies of the classes

Yes, that file was created by lein-immutant when using lein.

That and the app.properties hook is also hardcoded.

and your app sees the "local" copy, instead of the one provided by the container, and the local copy can't find the correct module

right, so, any war created by boot needs those same files

which is what boot-immutant will give you

I see.

Is there an example you could share?

of using boot-immutant? sure, one sec

yes

hmm, I don't have an example beyond https://github.com/immutant/boot-immutant/blob/master/test-app/build.boot

the boot.immutant/immutant-war task works similarly to lein immutant war, and the options are doc'ed at: https://github.com/immutant/boot-immutant/blob/master/resources/deployment-guide.md

if you need more, I can work up a sample project

or, better, add a build.boot to our feature-demo

I'm not sure I follow the example

I'd expect a deftask like create-war that calls you boot-war task or something like that.

I'll add that, one sec

that test-app was there for me to manually confirm behavior via boot immutant-war on the command-line

actually, I'll add a build.boot to the feature-demo now, that will be more useful/comprehensive I think

Thanks you! I see the guide and options nowt too..

I'm looking to integrate this task above..

see if replacing (war) with (boot.immutant/immutant-war) (after adding [boot-immutant "0.5.0" :scope "test"] as a dep) works

ok, just a sec.

note that boot-immutant calls the uber task for you, but really should expect the uberjar to be in the fileset

so you may see the uberjar created twice

I'm assuming I should remove/rename my statif files webapp/app.properties and WEB-INF/jboss-deployment-structure.xml andjboss-web.xml ?

correct, you won't need those

but /me wonders why it failed before if you had those in the war generated by (war)

maybe they weren't ending up in the correct place

is the war task built-in?

ah, so it is

added [boot-immutant "0.5.0" :scope "test"] to my deps. not requiring since it has the full path.., but getting ClassNotFoundException on boot.immutant

changed to require :as i that worked.

It looks like boot doesn't like full package.

I'm getting a FNFE with my test-app now, so it may be that I haven't kept up with boot itself

related to the uberjar

'[boot.immutant :as i]

(i/immutant-war)

They're on 2.5.2 One new thing is there is an explicit target task you need to use.

sorry 2.5.5

is it working for you at all?

I'm looking at what it would take to use the uberjar in the fileset instead of creating one

yeah, that's what I'm getting as well

let me see if I can fix it and cut you a new plugin release quickly

Ok. Thank you!! (I was supposed to release last Friday, so this is a huge help!!)

right, it currently calls uber no matter what, and expects the result to be in target/, unfortunately

oh ok. np. Sound like you're on it..

How's it going? Let me know if you need any help.

sorry, trying to juggle a couple of things. right now, I can't seem to find any jars in the fileset after calling uber

@symbit: ^

did you add the new target task?

new this release

ah, I probably need uber -> jar -> immutant-war

otherwise nothing is written.

I'm looking in the fileset for it currently

(comp (hoplon) (cljs :optimizations :advanced) (aot) (pom) (web) (i/immutant-war) (target))

does that work for you?

if so, that may be a workaround until I improve the plugin to not uber itself

Adding target actually writes to the target directory, otherwise it goes through all steps, but does write anything at all.

and that doesn't throw an exception for you?

doesn't write anything..

oh

ok, let me see if I can give you a hack that works for today as a SNAPSHOT, and try to fix it for real after

since you're against a deadline

let me try again.. I didn't check the target directory with all the exceptions..

if you get exceptions, it's likely you don't have a valid war, since the war task calls uber w/o calling target, then looks for the jar in target/ for the war

That makes sense.

The only thing written the target dir are the 3 config files. web.xml,jboss-web.xml and jboss-deplyment-structure.xml I think those are written by a different task.

If I replace (i/immutant-war) with (war) the target dir has a war file, yes.

those probably get put in the fileset by the immutant plugin before it tries to build the war

yup

I just pushed a snapshot - can you try "0.6.0-SNAPSHOT" and see if it works for you?

see if it works with the task chain you posted here last

this one, to be exact: https://clojurians.slack.com/archives/immutant/p1457986826000084

Thank you @tcrawley ! Running now...

if it runs without exception, but you have no war output in target/, remove the (target) call from the end of the chain, since I think it cleans by default

the immutant task breaks the rules and writes to target/ directly instead of to the fileset

that's one of the things I need to fix

it got farther. Wrote to the target dir, created a war in the wildfly dir. Then exception.

what's the exception?

editing..

what if you get rid of the final (target) call? do you still get an exception?

and does the generated war work for you in WildFly?

I tried the generated war. It's missing the application code.

FileNotFoundException: Could not locate my_project/service/core__init.class

trying without (target) task

ah, can you try adding (set-env! :resource-paths #{"src"}) as well? (using whatever path you have for the source there)

added

:resource-paths #{"src/main/clojure" "......." "......."} :source-paths #{"src/main/clojure"})

trying without (target)..

no exc on build!

found the code, started the immutant cache, but exc

clojure.lang.ArityException: Wrong number of args (0) passed to: not -modified/wrap-not-modified/fn--11837

does this app run outside of WildFly?

and can you gist the full trace?

i think I have to scope a few things out.

https://github.com/pandeiro/boot-http/blob/master/src/pandeiro/boot_http/impl.clj#L126

yes, I can run it with boot dev

if you're using boot-http, you're not using Immutant's web bits

For dev I'm using that..

and inside the container, you may be trying to start up http-kit instead of using the container's web server

are you calling immutant.web/run anywhere?

yes

(run handler)

is the line you linked to in the stack trace?

what does the (web) task do?

nope

It looks like boot-http is getting called. I should be able to add :scope "test"

ah, cool

Is there an app.properties hook that calls the clojure "main" functions?

When I created the 3 files 1 year ago with lein-immutant that was the hook to call into the client app.

there is an entry in app.properties that calls your init fn that you specify with :init-fn 'your.app/main

Does it make sense that the boot-http was called first?

so you'll need to pass that to the immutant-war task to have it called

yes, I have that..

building again with [pandeiro/boot-http "0.7.0" :scope "test"]

k - I don't know enough about boot-http to know why it would be called

:scope "test" didn't have any effect.

are you sure it is being called? can you share the stack trace you get in WildFly?

yes..

given that stack, it looks like something that is triggered in your init-fn. are you calling wrap-not-modified directly in your code?

nothing direct.

Also, I don't see my app in the stack trace.

wrap-params from ring

is there a further cause in the stack trace?

what version of immutant are you using?

ring.middleware.defaults/wrap-defaults

nope that was the whole trace.

2.1.2

https://github.com/immutant/immutant/blob/2.1.2/wildfly/src/immutant/wildfly.clj#L90 is the last non-clojure line in that stack, which is what makes me think it's an issue somewhere in your init-fn

it may be a version mismatch between the ring you bring in and the one immutant depends on, maybe

ugh, I just realized, my init-fn is pointing to the def handler and not the function where (run/handler is defined. Small difference between running dev in lein/jetty and prod in wildfly

let me try pointing to the other function..

@tcrawley: Yup that was the last piece of the puzzle. Thank you for all your time. Let me know if you need me to test anything..

good to hear! I'll try to fix up the boot-immutant task a bit more, and release a 0.6.0. I'll let you know when I have something ready to test there