Cloud Foundry Java Buildpack + support zip files are having *.war + Shared lib support with YAML upload having maven GAV co-ordinates with custom tomcat,jdk,jce and Valve support with Multiple catalina containers
The java-buildpack
is a [Cloud Foundry][] buildpack for running JVM-based applications. It is designed to run many JVM-based applications ([Grails][], [Groovy][], Java Main, [Play Framework][], [Spring Boot][], and Servlet) with no additional configuration, but supports configuration of the standard components, and extension to add custom components.
Also we can push *.zip file which has contain multiple war files. cleartrust-plugin jar will be available in part of buildpack and will be extracted into tomcat/libs folders. Also Tomcat-Valve config entry will be part of section in server.xml
currently this buildback has been enhanced for supporting YAML structure which will have libraries , webapps , repository url , credentials,for getting maven application artifacts. multiple context path mapping also take care. Added custom tomcat and jdk support with YAML structure.
web applications along with supported libraries can be uploaded as YAML format with GAV co-ordinates. below are the sample YAML structure. Also multiple context path will be dynamically added to Server.xml as a entry.
location: <LOCATION>
repo-id: <REPOSITORY>
authentication:
username: <username>
password: <password>
libraries: #specify all libraries as a sequence of GAV Coordinates. These would go in tomcat\lib folder
- g: <groupId>
a: <artifactId>
v: <version>
webapps: #specify all wars as a sequence of GAV Coordinates this would go into tomcat\webapps folder
- g: <groupId>
a: <artifactId>
v: <version>
context-path: <contextpath>
- g: <groupId>
a:<artifactId>
v:<version>
context-path: /abc
container: #allowed keys for configtomcat[tomcat8,tomcat7,tomcat6] and configjdk[oraclejdk8,oraclejdk7,openjdk8,openkdk7]
configtomcat: <tomcatkey>
configjdk: <jdkkey>
all the jars and wars will be downloaded and verify SHA checksum for validation. all the jars will be copied over to tomcat/lib and webapps will have all wars.
###Even shared libs can be (optional). if we want to use libraries as optional then remove the below section from YAML
libraries: #specify all libraries as a sequence of GAV Coordinates. These would go in tomcat\lib folder
- g: <groupId>
a: <artifactId>
v: <version>
##Following are the steps to push this yaml and test out the buildpack..
1. Copy the attached YAML to an empty directory
2. With PWD being the directory in 1 do a "cf p <app-name> -b https://github.com/Covisint-PST/java-buildpack.git”
3. Your instance should come up with out issue.
4. Now go to http://<domain>/check. And you should get a success response.
5. Now go to http://<domain>/classes?className=sample.SampleTCValve. And it will tell the sample.SampleTCValve class was found. This class is part of the library that is being pushed using the manifest and it goes into the shared classpath.
##Notes:
- Passing the manifest using "–p” does not work. Looks like the CF CLI does not support upload of a single file which is not an Archive. I think this might work using the CF rest APIs. Let me know if it does not.. Will find some work around for you.
- Use *.yaml for now. *.yml does not work. Looks like CF CLI strips *.yml files before upload. Should work with the rest API. But stick to *.yaml as that seems to the official extension
##convert YAML file into zip formation and use like below
cf p <app-name> -b https://github.com/Covisint-PST/java-buildpack.git -p repo-manifest.zip
##Generic support for different jdk , tomcat version with JCE support
This build has now enhanced to support different jdk and tomcat versions enable via config.yml and based on that versions both jdk(open and Oracle) and tomcat will be downloaded.
Also respective version of JCE security jars will be copied over to jre/security/ folder.
cf p <app-name> -b https://github.com/Covisint-PST/java-buildpack.git -p repo-manifest.zip
##Support for Valves with Multiple catalina containers
This build has now enhanced to support different valves which user will set through environment variables.Environment variables which is set as valve will be in JSON format.Which will contain three type of catalina containers which are host,context and engine.Based on these container valve entry with attributes and values will set into respective containers inside server and context xml files.These environment variable user can set with manifest file or through CF cli.Before setting these valves user has to give G,A,V coordinates of jars so that it will download and available under tomcat/lib folder.If user is not providing G,A,V coordinates then user needs to put these jars into tomcat/lib folder.
##Setting of Environment variable for Valves Valves which users are setting here are in JSON format and contains three type of catalina containers.which are host,engine and context.it behaves as key here.
{
"host" : [
{
"className":"c1",
"changeSessionIdOnAuthentication":"false",
"disableProxyCaching":"false",
"securePagesWithPragma":"true"
},
{
"className":"c2",
"alwaysUseSession":"true",
"changeSessionIdOnAuthentication":"true"
}
],
"engine" :[
{
"className":"c1",
"changeSessionIdOnAuthentication":"false",
"disableProxyCaching":"false",
"securePagesWithPragma":"true"
},
{
"className":"c2",
"alwaysUseSession":"true",
"changeSessionIdOnAuthentication":"true"
}
],
"context" : [
{
"className":"c1",
"changeSessionIdOnAuthentication":"false",
"disableProxyCaching":"false",
"securePagesWithPragma":"true"
},
{
"className":"c2",
"alwaysUseSession":"true",
"changeSessionIdOnAuthentication":"true"
}
]
}
To use this buildpack specify the URI of the repository when pushing an application to Cloud Foundry:
cf push <APP-NAME> -p <ARTIFACT> -b https://github.com/Covisint-PST/java-buildpack.git
The following are very simple examples for deploying the artifact types that we support.
The buildpack supports extension through the use of Git repository forking. The easiest way to accomplish this is to use [GitHub's forking functionality][] to create a copy of this repository. Make the required extension changes in the copy of the repository. Then specify the URL of the new repository when pushing Cloud Foundry applications. If the modifications are generally applicable to the Cloud Foundry community, please submit a [pull request][] with the changes.
Buildpack configuration can be overridden with an environment variable matching the configuration file you wish to override minus the .yml
extension and with a prefix of JBP_CONFIG
. The value of the variable should be valid inline yaml. For example, to change the default version of Java to 7 and adjust the memory heuristics apply this environment variable to the application.
cf set-env my-application JBP_CONFIG_OPEN_JDK_JRE '[jre: {version: 1.7.0_+}, memory_calculator: {memory_heuristics: {heap: 85, stack: 10}}]'
If the key or value contains a special character such as :
it should be escaped with double quotes. For example, to change the default repository path for the buildpack.
cf set-env my-application JBP_CONFIG_REPOSITORY '[ default_repository_root: "http://repo.example.io" ]'
Environment variable can also be specified in the applications manifest
file. See the [Environment Variables][] documentation for more information.
To learn how to configure various properties of the buildpack, follow the "Configuration" links below. More information on extending the buildpack is available here.
- Design
- Security
- Standard Containers
- Standard Frameworks
- AppDynamics Agent (Configuration)
- Introscope Agent (Configuration)
- DynaTrace Agent (Configuration)
- Java Options (Configuration)
- JRebel Agent (Configuration)
- MariaDB JDBC (Configuration)
- New Relic Agent (Configuration)
- Play Framework Auto Reconfiguration (Configuration)
- Play Framework JPA Plugin (Configuration)
- PostgreSQL JDBC (Configuration)
- Spring Auto Reconfiguration (Configuration)
- Spring Insight
- Standard JREs
- Extending
- Debugging the Buildpack
- Buildpack Modes
- Related Projects
The buildpack can be packaged up so that it can be uploaded to Cloud Foundry using the cf create-buildpack
and cf update-buildpack
commands. In order to create these packages, the rake package
task is used.
The online package is a version of the buildpack that is as minimal as possible and is configured to connect to the network for all dependencies. This package is about 50K in size. To create the online package, run:
bundle install
bundle exec rake package
...
Creating build/java-buildpack-cfd6b17.zip
The offline package is a version of the buildpack designed to run without access to a network. It packages the latest version of each dependency (as configured in the [config/
directory][]) and [disables remote_downloads
][]. This package is about 180M in size. To create the offline package, use the OFFLINE=true
argument:
To pin the version of dependencies used by the buildpack to the ones currently resolvable use the PINNED=true
argument. This will update the [config/
directory][] to contain exact version of each dependency instead of version ranges.
bundle install
bundle exec rake package OFFLINE=true PINNED=true
...
Creating build/java-buildpack-offline-cfd6b17.zip
Keeping track of different versions of the buildpack can be difficult. To help with this, the rake package
task puts a version discriminator in the name of the created package file. The default value for this discriminator is the current Git hash (e.g. cfd6b17
). To change the version when creating a package, use the VERSION=<VERSION>
argument:
bundle install
bundle exec rake package VERSION=2.1
...
Creating build/java-buildpack-2.1.zip
To run the tests, do the following:
bundle install
bundle exec rake
[Running Cloud Foundry locally][] is useful for privately testing new features.
To run the tests, do the following: Bring up the vagrant virtual machine and ssh into it.
vagrant up
vagrant ssh
Run the detect
, compile
and release
commands within the vagrant machine.
cd /vagrant/<directory-containing-war-or-zip-files>
/vagrant/vagrant/run/detect
/vagrant/vagrant/run/compile
/vagrant/vagrant/run/release