This is more a question for the Spring Boot team, but here's how Spring Boot applications in Cloud Foundry work. When a Spring Boot application is created, your application is put into `/BOOT-INF` and

#spring #springboot #java

The Java Buildpack treats the Buildpack cache as an opaque directory. This means that there are larger system policies about whether it's cached per-cell, per-foundation, etc. but from the perspective

At this time I'm not planning on adding support for configuring the internalProxies explicitly both because it sets a precedent that I'm not comfortable with, and that it hasn't shown to be a big issu

#cf

I'm pleased to announce the release of Java Buildpacks v3.19 and v4.3. As always there are some bug fixes and a whole load of new functionality. Please see the release notes[1][2] for details about th

Configuring the `cf-java-client.token` logger to `DEBUG` will give you detailed information about the negotiated tokens. ``` cloudfoundry-client.request POST https://login.peach.springapps.io:443/oaut

Steven, The Maven and Gradle plugins were based on the 1.x line of the CF Java Client, and haven't been implemented against the 2.x line of the Java Client. The commit where you see removal is simply

I’m pleased to announce the release of Java Buildpack 4.0. This release has been a big effort for the team over the last couple of months and is the culmination of a major focus on improving how the J

The Java Client does not yet cover all CF APIs (we’re at abut 400 of 550 total APIs) and we have not yet added the user administration operations. If you’d like to see them moved up the priority list,

It does not. You would be required to provide your own JRE and ensure that your application knows where it resides. -Ben Hale Cloud Foundry Java Experience

The fundamental answer is timing. There is a very vocal contingent of users that dislikes how long it takes to stage applications. Today a typical Spring Boot staging takes well less than a minute[1]

The documentation you are referring to relates to Java Client 1.x. The `master` branch contains Java Client 2.x, and its best documentation currently exists in the README[1]. If you wish to continue u

Depending on how widely the native library is used, you probably don’t need to fork the buildpack to accomplish what you are looking to do. In general, libraries can be packaged within JAR files (I’d

The environment variable configuration is a “flow” style[1] YAML representation of the configuration file[2] being configured. If you review the documentation for the Tomcat configuration[3], you’ll s

I'm immensely pleased to announce Cloud Foundry Java Client `2.0.0.RELEASE`! This release is the culmination of 54 weeks of work, encompassing 10 milestones, two release candidates, and 2,344 commits[

I'm pleased to announce the release of the java-buildpack, version 3.7.1. This release is a dependency update highlighted by the availability of JREs with JCE Unlimited Strength encryption. * OpenJDK

I’m unsure why this is, although I haven’t been able to deploy the docker image you’ve created yet. I’m still attempting to get the image to start on a CF instance for validation and diagnostics. -Ben

As I mentioned earlier, the difference in behavior is down to the command that is being run when the application is pushed to Cloud Foundry. When you push your WAR to CloudFoundry, it is being run in

The Java Buildpack creates a very complex command to start applications (since it needs to manage the JVM’s memory space within the container’s memory space). Therefore, it detects standard artifact t

I'm pleased to announce the release of the java-buildpack, version 3.7. This release contains the addition of a number of frameworks and updates to the dependencies. * Container Certificate Trust Stor

In fact, the plan is currently to include both of those APIs. You can see the UAA is prioritized[1] and the DopplerClient is already[2] being worked. There will be a single API library and a single im