-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot Run Containerized Spring Boot Application #6
Comments
I noticed that the tutorial example creates a jar with all the class files for all of the dependencies, why is that necessary? |
Right now the Java app assumes everything is in one jar. So you need to build in all of your dependencies. We could also change the app so that it could allow alternate FROM images that had the spring libraries already in there... |
@brendandburns when you say "java app" are you referring to the metaparticle code? The metaparticle jars should be on the classpath, why do the class files need to be packaged in the jar itself? |
Yes the metaparticle code itself. The thing is that once the application is packaged as a container, the local classpath is gone, the only classes are the classes in the image. It would be interesting to introspect the Probably worth doing, but in the meantime if you want to get a Spring app working, you'll need to package of of the classes into a single .jar. |
So could we create an image that contains the metaparticle code within it so its not necessary for each app to do this? |
Spring Boot bundles the libraries by default, but the reason it won't start is that the plugin it uses to create a fat jar injects a wrapper that calls the real main method and moves all of the non loader classes to
|
Curious if anyone has found a good workaround for this. I am definitely interested in giving Metaparticle a go, but this is a blocker. |
The cause of the problem described in the original post is the Incidentally, there is another problem lurking here which concerns the generated Dockerfile. It's current final line ( Update: the above assertion that the generated Dockerfile won't work for any executable Jar is incorrect. Regular executable Jars work OK with |
@brendanburns For your consideration I've submitted a PR for this issue that consists of the changes to the library I made locally to containerize a Spring Boot application. Works for running with Maven ( |
* Follow up to previous PR for issue metaparticle-io#6
* Follow up to previous PR for issue #6
I still get the same issue and also have the latest version of Spring Boot. Can somebody help |
@faiz0019 I've just tried running a Boot application using the information in package samples and it all works OK. I'm using the latest level of package source and Spring Boot 2.0.3. What kind of failure do you see? |
@georgeharley We moved from our company base pom and it solved the issue. Thank You for your support |
* Updated Java package tutorial instructions (metaparticle-io#110) * Correct the expected value of the @Package/repository value * Mention the need for the @Package/publish=true field * Removed use of the @Runtime/publicAddress field since the tutorial does not appear to be ACI specific * Correct the type of service created on the remote Kubernetes cluster * Added missing unit test dependencies (metaparticle-io#109) * Update README.md (metaparticle-io#106) Slight typo. "a nd language of choice" ===> "and language of choice" * Create dotnet testrunner (metaparticle-io#87) * fix up examples and documentation * fix up indenting * add initial code for a dotnet test runner as part of metaparticle * add missed file * renamed env vars to be conssitent and also moved braces to new lines * Add travis for dotnet (#3) * add initial travis file * fix up missing dash * try again going into the right directory this time * no need for mono and we can set the dotnet core version * make build.sh executable * see what directory we are on * set to unix type * build the examples * move tests to attributes rather than using env var * Initial Set of Unit Tests For DotNet Metaparticle.Package (metaparticle-io#111) * Create unit test project and added tests for Metaparticle.Package.Config * Added unit tests for Config and an initial set of tests for the Driver * Minor update to Java sharding tutorial instructions (metaparticle-io#112) (metaparticle-io#113) * Fix typo in tutorial (metaparticle-io#114) * Support containerizing of Spring Boot apps (metaparticle-io#115) * Necessary to upgrade PowerMock version in order to run tests * Additions to gitignore file * Support sharding. (metaparticle-io#118) * Update definition of local functions with explicit const (metaparticle-io#120) * Add some words on Spring Boot support to package Java tutorial (metaparticle-io#121) * Follow up to previous PR for issue metaparticle-io#6 * Lazy intialize the Docker client. (metaparticle-io#119) * Fix missing comma, go fmt (metaparticle-io#122) * Adding rust (metaparticle-io#86) * learned a touch of rust * no decorator * base rust entrypoint * with bare docker builder and executor (#3) * Real traits jim (#4) * add placeholder functions for actual interface * move builder trait into builder module * move docker builder struct into correct module * move existing functions onto trait implementation * move executor trait to appropriate module * move executor struct into correct module * initial builder working * added docker run support; cleaned up command execs * refactor to str refs; added readme * We need strings here, I think The result of the format! call is a string, (as is the result of other ways of getting a u64 into a string). This change makes the method compile without changing anything's type signature. There might be other was to accomplish this, but I haven't found one. * added web example * use executable's path as Docker context * wrapped docker cmds in sh * write dockerfile to docker context explicitly * fix copy paste error in README * Python fix + cleanup (metaparticle-io#123) * general cleanup * nested options should be processed into objects from dictionaries * comments on logging; pythonic json read * Drive-by cleanups (metaparticle-io#126) * Let requirements match the latest version * Make print statements Python3-compatible * insulate more against Py2 -> Py3 changes * Add python additionalFiles option (metaparticle-io#125) * add python additionalFiles option * in case a dir is given * added tests for additionalFiles * Lazy intialize the Docker client. (metaparticle-io#127) * more efficient base image (metaparticle-io#131) * more efficient base image * squashed layers * removed breaking character * adding certs * sized down to 6mb and tested with simple http server
I tried using metaparticle to containerize a simple Spring Boot application but it is not running. I am not sure if maybe I am not doing something correctly or if it is a mismatch between what metaparticle expects and the conventions of Spring Boot. Here is my basic Boot app
I then run
./mvnw clean package
and it all works fine. But then I run the app using the traditionaljava -jar target/demo-0.0.1-SNAPSHOT.jar
, (This is how you would normally run a Boot app) but it fails withThe text was updated successfully, but these errors were encountered: