Procfile container to facilitate running packaged jar applications

[mrdavidlaing]

In cases where you need to run a third party Java app that comes packaged as a jar, being able to specify the exact startup command(s) via a Procfile is very useful development, and running the via the start command specified in the Procfile using Forego works well when deployed to Cloud Foundry.

An example of this in action is https://github.com/mybytes/personal-data-api.

[mrdavidlaing]

At this stage I'd just like a yes or no as to whether this extension could be generally useful enough to get merged.

If yes then I'll polish & squash the commits as per the CONTRIBUTING guide

[nebhale]

I'm going to start with no (which totally blows my statement that I default to yes out of the water) but I'm willing to be convinced otherwise. In general, the java-buildpack does not have a goal of running any arbitrary command that uses Java behind the scenes. It is intended to run an 80% scope of applications very well and without modification. Beyond that, I'm not sure what this functionality would do that using a Cloud Foundry custom command wouldn't.

Again, I'm open to having my mind changed; strong opinions loosely held, and all that.

[mrdavidlaing]

Beyond that, I'm not sure what this functionality would do that using a Cloud Foundry custom command wouldn't

My issue with using a Cloud Foundry custom command was that the buildpack "compile" phase always fails because it can't find a supported container.

If we could get around that issue, then you could just bundle Forego with your specific app.

That said, being able to grab the custom JAVA_OPTS from buildpack is quite useful.

[mrdavidlaing]

@nebhale - poke 😄

Has my issue with not being able to specify a custom command because of the lack of a supported container swayed your opinion at all?

[nebhale]

Sorry, headed out on holiday before responding. Looking back over the discussion, you mention "In cases where you need to run a third party Java app that comes packaged as a jar,...". If that is the case, we already have a container that runs it. Are you not seeing that behavior? Another issue that comes to mind is how the detect phase would work. Given that we would simply look for a Procfile how does this not conflict with other buildpacks that will also look for Procfiles?

In my own mind, I keep circling back to the idea that a JAR file (either with a Main-Class manifest attribute or specifying java_main_class) can be run with any set of arguments using a fork.

The design of the buildpack (currently) is not to run anything that requires Java, but rather to run a specific (expandable) set of artifact types. If you don't mind I'd like to delve into specifically what artifact types you can't run today using the facilities provided. I'd like to solve the problem for everyone rather than just pushing users to specify a custom command line.

[mrdavidlaing]

@nebhale - thanks for working with me to find the underlying root issue here.

As you suggest, a concrete example will be helpful here.

Specifically I'm trying to deploy this project - https://github.com/mybytes/personal-data-api

This is a Apache Jena Fuseki HTTP endpoint that allows me to make SPARQL over HTTP queries against a Linked Data database.

Fuseki comes packaged as a jar. When you extract the Fuseki distribution tgz you get:

$ ls -lah fu*
-rwxr-xr-x  1 mrdavidlaing  staff   8.8K 12 Sep 10:49 fuseki
-rwxr-xr-x  1 mrdavidlaing  staff   1.5K 12 Sep 10:49 fuseki-server
-rw-r--r--  1 mrdavidlaing  staff    91B 12 Sep 10:49 fuseki-server.bat
-rw-r--r--  1 mrdavidlaing  staff    17M 12 Sep 11:01 fuseki-server.jar

The "howto run fuseki instructions" instructs you to launch it using a command like fuseki-server --port=$PORT --file all_data.nt /ds

fuseki-server is a shell script that essentially resolves to exec java -jar fuseki-server.jar --port=$PORT --file all_data.nt /ds

LogStash is another Java app that comes packaged as a jar, with similar "launch with java -jar " instructions, so I'm guessing this is a common pattern.

In both these cases I don't really want to explode the jar and go looking for the Main class, I just want to use this as documented as a component in my CF app.

Hopefully this helps give you some context to my specific issue.

I think that the root cause is that there is currently no way with the java-buildpack to specify a custom command if a supported container is not found during the bin/compile phase.

If there was a way to tell the java-buildpack to just package the jvm and let my app's manifest.yml worry about the custom start command then I'd be able to deploy -jar apps like this.

[scottfrederick]

If there was a way to tell the java-buildpack to just package the jvm and let my app's manifest.yml worry about the custom start command then I'd be able to deploy -jar apps like this.

A trick you can use in this scenario is to add a META-INF/MANIFEST.MF file to the uploaded bits. If the MANIFEST.MF file has a Main-Class: attribute in it (the value can be empty or contain a junk value), that's enough for the buildpack to pick a container and continue with staging. The value of the Main-Class: attribute won't matter if a custom command is set up for the app.

This isn't very obvious or elegant, and it would be nice if there were a cleaner solution, but it works as a short-term hack.

[nebhale]

The concrete example sheds a huge amount of light on this. Fundamentally Fuseki is a container, and therefore should be implemented (and contributed back) as a component. A user (you @mrdavidlaing) should be able to simply push the all_data.nt file (e.g. cf push --path all_data.nt) and the buildpack does the rest. In that case, during compile it will need to download the Fuseki TAR and unpack it, then create the fuseki-server --port=$PORT --file <..> /ds command line during release. detect should probably trigger on the existence of .nt files maybe?

A great example to base this component on would be the Groovy container.

[mrdavidlaing]

Hmm - your conception of the specificity of containers is a lot tighter
than mine.

I understand your design goals for the java-buildpack better, and can see
why this doesn't fit.

Let's close this PR.
On 17 Oct 2013 11:28, "Ben Hale" notifications@github.com wrote:

The concrete example sheds a huge amount of light on this. Fundamentally
Fuseki is a container, and therefore should be implemented (and contributed
back) as a component. A user (you @mrdavidlainghttps://github.com/mrdavidlaing)
should be able to simply push the all_data.nt file (e.g. cf push --path
all_data.nt) and the buildpack does the rest. In that case, during compileit will need to download the Fuseki TAR and unpack it, then create the fuseki-server
--port=$PORT --file <..> /ds command line during release. detect should
probably trigger on the existence of .nt files maybe?

A great example to base this component on would be the Groovy containerhttps://github.com/cloudfoundry/java-buildpack/blob/master/lib/java_buildpack/container/groovy.rb
.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/15#issuecomment-26493598
.

[nebhale]

OK, thanks for taking the time to discuss this with us. Any chance we should be expecting a Fuseki container contribution from you? ;)

[mrdavidlaing]

@nebhale - If I do some more work with Fuseki, then yes.