Add support for passing main method arguments#2
Conversation
|
The continued existence of |
|
I am deploying some Dropwizard-based services, which are typically launched with a command like the following:
This build pack handles (a) automatically but cannot in its current form (transparently) handle (b) and (c). (c) is just a convenience, because anything in that configuration file can be passed to the application via |
|
I just realized that this pull request was pinned to the wrong branch. If you want to keep it under consideration, I would be happy to create a new one. |
|
It is not yet clear why (b) could not be provided using an environment variable or system property and what the downsides of those alternatives might be. |
|
I guess the only downside is that it makes running a Dropwizard service on CF even less idiomatic. This pull is obsolete anyway now that support for |
|
@celkins while I'm not convinced it's a high priority (lots of stuff around web applications come first), I think command line arguments are actually something we need to implement. I've put an story on our backlog about it, and while that doesn't mean we'll do it soon, it does mean that it'll stare us in the face every day. Thanks for your contributions and insight. |
|
I'm not sure I understand what is not supported about command line args. I'm using the java build pack with java -jar and it doesn't stop me from passing args. If a build pack would somehow make it easier I would be interested to know more, but I don't immediately see how it would. |
|
@dsyer How are you passing args? By using a custom command? |
|
Yes, a custom command. I suppose a build pack could look in my MANIFEST.mf and discover the main class, and then I might not need a custom command. But how would it know how to set the port to listen on? I assumed that all the build pack gave me was a JRE, and it was up time to use it. |
|
That's where things are today. I'm looking to make something smarter than that ;) To that end, the new buildpack already looks at |
|
@celkins I just wanted to let you know that argument support has been added. |
|
@celkins What's the state of deploying Dropwizard to CF? Did you work through the 'server' arg? or is there different approach? |
|
The support for arguments is convenient, but there's always been a workaround in its absence by hard-coding a default in the main method. AFAICT you still have to fork the buildpack in order to pass the dynamically-assigned HTTP port to Dropwizard. That along with some other useful/necessary defaults is the sole purpose of my fork. What has changed since I last looked at this issue is support in the buildpack for the |
|
@slangeberg In general, we'd aim to detect and treat Dropwizard as a first-class container (similar to Servlet Apps, Grails Apps, etc.). There hasn't really been any demand (as in issues opened) for this so we've not really pursued it. If this is something you'd like to see, please open an issue in this repository to register your interest for it. It shouldn't be massively hard to add directly. |
|
I am revisiting this topic; as many of our app developers look to migrate apps to CF, the issue of cli args rears its ugly head again. Specifying a custom start command for java buildpacks to get CLI args is not the greatest user experience imo. As far as I can tell you loose the JAVA_HOME and JAVA_OPTS variables since the output of the release function is ignored when a custom command is specified, so users must know these and set them in the start command (if the location of the JDK ever changes within the container, all the custom start commands disappear). Any java_opts i want to enforce globally are lost. There are many different application patterns, whether they be bespoke patterns employed by teams or third party frameworks like dropwizard. As I see a drive towards increased use of embedded servlet containers and wrapper frameworks, trying to add buildpack support becomes more and more cumbersome, especially as they all start to look very similar when trying to run detect over them but have very subtle differences in start command formats. My experimental fork of the buildpack simply picks up JAVA_ARGS from the environment and appends it to the end of the start command for a number of the different containers (not tomcat). Its perhaps a little naive and simplistic but this gives my users the flexibility they need to specify cli args. |
|
@johnmcteague We are considering a generic way to override buildpack config through environment variables. This conversation is happening in issue #122 could you look over there to keep it all in one place and as this issue was closed off a while ago. Thanks. |
|
FYI, This should now be achievable with the support added in #122 See the readme for more information. |
# This is the 1st commit message: Initial check in of Sealights Buildpack # This is the commit message cloudfoundry#2: Add logs to SealightsAgent # This is the commit message cloudfoundry#3: Print before the logger # This is the commit message cloudfoundry#4: Add more logs # This is the commit message cloudfoundry#5: Add some more logs + add configuration file for the agent # This is the commit message cloudfoundry#6: Logging in base component
# This is the 1st commit message: Initial check in of Sealights Buildpack # This is the commit message cloudfoundry#2: Add logs to SealightsAgent # This is the commit message cloudfoundry#3: Print before the logger # This is the commit message cloudfoundry#4: Add more logs # This is the commit message cloudfoundry#5: Add some more logs + add configuration file for the agent # This is the commit message cloudfoundry#6: Logging in base component # This is the commit message cloudfoundry#7: Logging in base component # This is the commit message cloudfoundry#8: Finishes and testing for the Sealights Agent # This is the commit message cloudfoundry#9: Undo changes to the open_jdk_jre.yml
# This is the 1st commit message: Initial check in of Sealights Buildpack # This is the commit message cloudfoundry#2: Add logs to SealightsAgent # This is the commit message cloudfoundry#3: Print before the logger # This is the commit message cloudfoundry#4: Add more logs # This is the commit message cloudfoundry#5: Add some more logs + add configuration file for the agent # This is the commit message cloudfoundry#6: Logging in base component # This is the commit message cloudfoundry#7: Logging in base component # This is the commit message cloudfoundry#8: Finishes and testing for the Sealights Agent # This is the commit message cloudfoundry#9: Undo changes to the open_jdk_jre.yml # This is the commit message cloudfoundry#10: Undo changes to the open_jdk_jre.yml # This is the commit message cloudfoundry#11: Cleanups before PR
# This is the 1st commit message: Initial check in of Sealights Buildpack # This is the commit message cloudfoundry#2: Add logs to SealightsAgent # This is the commit message cloudfoundry#3: Print before the logger # This is the commit message cloudfoundry#4: Add more logs # This is the commit message cloudfoundry#5: Add some more logs + add configuration file for the agent # This is the commit message cloudfoundry#6: Logging in base component # This is the commit message cloudfoundry#7: Logging in base component # This is the commit message cloudfoundry#8: Finishes and testing for the Sealights Agent # This is the commit message cloudfoundry#9: Undo changes to the open_jdk_jre.yml # This is the commit message cloudfoundry#10: Undo changes to the open_jdk_jre.yml # This is the commit message cloudfoundry#11: Cleanups before PR # This is the commit message cloudfoundry#12: Add Sealights to the java buildpack # This is the commit message cloudfoundry#13: Logs in the buildpack # This is the commit message cloudfoundry#14: Logging the configuration flow
Inject java 9 flags to Takipi Agent
Inject java 9 flags to Takipi Agent
7 participants
No description provided.