`no main manifest attribute, in /my_app.jar` was t...

# ktor

[tjb]

no main manifest attribute, in /my_app.jar was the error

[rocketraman]

Where does my_app.jar come from? Aren't you running canti.jar?

[tjb]

sorry i replaced the name ona ccident when i copied it over

[tjb]

but yes you are correct it is canti.jar

[rocketraman]

Are you sure the right jar is getting copied into the container?

[rocketraman]

Have you exec'ed into the container to verify it?

[tjb]

checking now

[tjb]

you cannot exec into the container since it never starts

[rocketraman]

Just start it by overriding the command executed to a shell e.g. docker run -ti mycontainer /bin/sh. Since you are using `ENTRYPOINT`and not CMD you probably need to use --entrypoint to override it.

[tjb]

like so? docker run -it 87208166d967 /bin/sh --entrypoint

[rocketraman]

Probably more like docker run -it 87208166d967 --entrypoint /bin/sh

[tjb]

hmm i get Unable to find image '87208166d967:latest' locally but the image is there

87208166d967        canti:1.0.1                  "sh -c 'java $JAVA_O…"   6 minutes ago       Exited (1) 5 minutes ago                                                                                                 cocky_varahamihira

[rocketraman]

I think you are looking at containers, not images

[rocketraman]

docker images

[tjb]

oh man you are right my apologies

[tjb]

still get the original message of no main manifest attribute, in /canti.jar

[rocketraman]

Try: docker run -it --entrypoint /bin/sh mycontainer. It's easier to override CMD rather than ENTRYPOINT. I'd switch to CMD here unless you had a specific reason for using ENTRYPOINT.

[rocketraman]

And don't start a shell unnecessarily as that will mess up signal handling i.e. get rid of your sh -c bit.

[tjb]

cool! i was able to get in now

[tjb]

ok i will take notes of those

[tjb]

i see the jar in

[tjb]

its called canti.jar

[rocketraman]

All right, just try running it inside the container. What do you get?

[tjb]

Error: Could not find or load main class canti.jar

[rocketraman]

What did you run exactly?

[rocketraman]

Give me the command line

[tjb]

i first did

[tjb]

java canti.jar

[tjb]

then

[tjb]

java -jar canti.jar

[tjb]

same message both times

[tjb]

ah wait no sorry java canti.jar gave Error: Could not find or load main class canti.jar and java -jar canti.jar gave no main manifest attribute, in canti.jar

[rocketraman]

And when you run the same jar outside the container in the same way java -jar canti.jar, it works?

[tjb]

when id run locally id use intellij

[rocketraman]

Ah, well it goes back to my original point then: get your jar running outside of docker first. Using java -jar ....

[tjb]

ah ok

[tjb]

i will attempt that first then

[tjb]

sorry for the misunderstanding

[rocketraman]

If you're open to running it differently, you can use the distribution script the gradle application plugin creates for you. For example, here is the end of a dockerfile from one of my projects:

WORKDIR /foo
ADD distributions/foo.tar /
CMD ["./bin/foo"]

[rocketraman]

Those start scripts the plugin creates take care of all sorts of useful stuff like JVM options and other stuff you can now pass in as environment settings (which is a common way to configure the runtime env in Docker deployments).

[rocketraman]

But in any case, get it running first outside Docker. 🙂

[mkobit]

i have a feeling if you run java -cp canti.jar io.ktor.server.netty.DevelopmentEngine (or whatever it is) you will also see some class loading/class path issues too
in addition to what @rocketraman already mentioned, about the distribution script, https://github.com/johnrengelman/shadow is another option for "fat jar" type packaging

[rocketraman]

Fat jars are pretty unnecessary if deploying via Docker. The Docker container already contains everything it needs to run the app, so adding a fat jar is just extra packaging overhead for no particular benefit.

[rocketraman]

Which is also why executing your app via java -jar isn't the best idea either. java -jar was created to make things simple for end-users, and IMO is not the right way to package and deploy a server-side application.

[mkobit]

there are definitely tradeoffs

[rocketraman]

@mkobit What would you see as a benefit of the fat jar approach if your execution target is a Docker container?

[mkobit]

common packaging format i think can be an easy starting point since lots of tools already support it mostly out of the box (spring boot, shadow, vertx +shadow)

for example, if your organization has lots of different java services and wants to to have a hook into the build/deploy process you could share a "baseline" docker image with a base entrypoint and some environment variable knobs.

i think things like jlink in java 9, docker image layering, pods in kubernetes, better distribution mechanisms (like https://docs.gradle.org/current/userguide/java_library_distribution_plugin.html) all offer different approaches with different improves, but i think the "fatj ar" approach is one that is simple and easy to get moving fast with since it is a pattern that has been around for a while. i havent had the opportunity to do much development with java 9 so it might be different there, though

what are your thoughts?

[tjb]

ah HA! i figured it out i think

[tjb]

had to add this then rebuild and redockerize

[tjb]

jar {
    baseName = "canti"
    manifest {
        attributes 'Main-Class': mainClassName
    }
}

[tjb]

@rocketraman if you are interested ^

[rocketraman]

@tjb Glad you got it figured out!

[tjb]

thank you for your insight as well!