How do I install a Java version other than the default, with the Java buildpack?

[Noburou Taniguchi]

Hi,

I have a question describe in the subject. (I'm afraid it's a very novice question.)

The Ruby and Node buildpack docs introduce the ways to install different version of runtime, just by configuring some values within an app to be deployed.

http://docs.cloudfoundry.org/buildpacks/ruby/ruby-tips.html#buildpack
http://docs.cloudfoundry.org/buildpacks/node/node-tips.html#buildpack

But there is no such description in the Java buildpack docs.

According to this section of the document,

http://docs.cloudfoundry.org/buildpacks/java/java-tips.html#configuration

do we have to fork and customize the Java buildpack to deploy a Java app that uses a Java version other than the default? Or, is there any easier way to do it?

And if the former is true, I also want to know how many people want another way to specify a Java version on using the Java buildpack.

Thanks in advance.

[Daniel Mikusa]

On May 8, 2014, at 8:03 AM, Noburou Taniguchi <d...@nota.m001.jp> wrote:

> Hi,
>
> I have a question describe in the subject. (I'm afraid it's a very novice question.)
>
> The Ruby and Node buildpack docs introduce the ways to install different version of runtime, just by configuring some values within an app to be deployed.
>
> http://docs.cloudfoundry.org/buildpacks/ruby/ruby-tips.html#buildpack
> http://docs.cloudfoundry.org/buildpacks/node/node-tips.html#buildpack
>
> But there is no such description in the Java buildpack docs.
>
> According to this section of the document,
>
> http://docs.cloudfoundry.org/buildpacks/java/java-tips.html#configuration
>
> do we have to fork and customize the Java buildpack to deploy a Java app that uses a Java version other than the default?

This is my understanding too.

> Or, is there any easier way to do it?

I haven’t looked recently, but last time I checked the intended way to do this was by forking.

Dan

> And if the former is true, I also want to know how many people want another way to specify a Java version on using the Java buildpack.
>
> Thanks in advance.
>

> To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

[Noburou Taniguchi]

Thank you for the immediate response, Daniel

We do think there will be some needs from our (future) customers to specify a Java version just by pushing an app. So I think we will implement the feature in the coming months.

If someone has any plan alike, I want to share thoughts and keep step with them. And if there are people who is interested in such a feature, we may examine a plan to publish our implementation-to-be as open source.

Please let me know your thoughts, guys.
Thank you.

2014年5月8日木曜日 21時17分10秒 UTC+9 Daniel Mikusa:

[Daniel Mikusa]

I haven’t heard of anyone working on a similar feature, but Ben Hale would be the guy to ask. He can give you a definitive answer.

Dan

[Alan Moran]

Hi Noburou,

We recently been doing this for the java build pack.

Comment the one java jre you don’t want to use here:

https://github.com/cloudfoundry/java-buildpack/blob/master/config/components.yml#L32

In case of oracle jre you will have to upload the jre yourself or find a palace to download it without accepting the policy.

I would recommend you to upload it to s3 or atoms in this format:

http://your-open-buket.s3.amazonaws.com/oracle/lucid/x86_64/oracle-1.7.0_51.tar.gz

In the config file you can actually indicate the version but for oracle you will need an index yml that reference to all the versions available.

This yml should be at http://your-open-buket.s3.amazonaws.com/oracle/lucid/x86_64/index.yml and have the following structure:

---

1.7.0_51: http://your-open-buket.s3.amazonaws.com/oracle/lucid/x86_64/oracle-1.7.0_51.tar.gz

8_5: http://your-open-buket.s3.amazonaws.com/oracle/lucid/x86_64/oracle-8_5.tar.gz

Finally you will need to modify either the open jre config or the oracle jre config, in this example you could indicate either version 1.7.0_+ or 8_+ for oracle.

https://github.com/cloudfoundry/java-buildpack/blob/master/config/oracle_jre.yml

https://github.com/cloudfoundry/java-buildpack/blob/master/config/open_jdk_jre.yml

- Bonzo.

make sure that if you provide the following structure:

https://github.com/cloudfoundry/java-buildpack/blob/master/config/oracle_jre.yml

[Noburou Taniguchi]

Thank you, Alan

One of my collegues was trying to do that, and finally he's achieved his end.
But we think it's bothering for our customers to do.

The collegue told me that in Heroku Java buildpack, version selection operation is done with "system.properties" file. So one of our plan may be like:

• By default, the default version of Java is used (a customer just has to push her/his app)
• In case she/he wants to use another version of Java for an app, she/he has to push the app with a "system.properties" file having the Java version.

We are afraid that there might be any downside with "system.properties" method because we don't have much experience with buildpacks. We will be grateful for you guys to tell us anything about it.

2014年5月8日木曜日 23時41分50秒 UTC+9 Alan Morán:

[Daniel Mikusa]

On May 9, 2014, at 6:29 AM, Noburou Taniguchi <d...@nota.m001.jp> wrote:

> Thank you, Alan
>
> One of my collegues was trying to do that, and finally he's achieved his end.
> But we think it's bothering for our customers to do.
>
> The collegue told me that in Heroku Java buildpack, version selection operation is done with "system.properties" file. So one of our plan may be like:
> • By default, the default version of Java is used (a customer just has to push her/his app)
> • In case she/he wants to use another version of Java for an app, she/he has to push the app with a "system.properties" file having the Java version.
> We are afraid that there might be any downside with "system.properties" method because we don't have much experience with buildpacks. We will be grateful for you guys to tell us anything about it.

You could certainly do this. I think one of the reasons that the Java build pack does not do this is because it wants to make sure you’re running the latest version of Java available (so you get bug and security fixes). This is one of the really nice features of PaaS after all, the developer just focuses on writing the app and everything needed to run the app is just handled for you. If you lock in a specific major & minor version Java, you lose the ability for the build pack to keep the version of Java automatically up-to-date.

Personally, I think it’d be nice if the build pack had an easier way to switch between Java 6 / 7 / 8 (i.e. major versions). Setting the version manually somehow would work, but if the build pack was able to look at my compiled classes and determine the major version of Java to use, that would be pretty slick.

Dan

[Ryan Morgan]

On Fri, May 9, 2014 at 4:51 AM, Daniel Mikusa <dmi...@gopivotal.com> wrote:

....

Personally, I think it’d be nice if the build pack had an easier way to switch between Java 6 / 7 / 8 (i.e. major versions).  Setting the version manually somehow would work, but if the build pack was able to look at my compiled classes and determine the major version of Java to use, that would be pretty slick.

Dan

Dan,

That's an interesting suggestion.. Noburou, do you have a requirement to be able to specify the minor version or would something along the lines of what Dan suggested be sufficient?

-Ryan

 

[Noburou Taniguchi]

Thank you, Dan and Ryan,

I think Dan's idea is interesting, too.

On our assumption, there may be few cases to require specifying a minor version. So with Java versions, it'll be generally OK.

However, we think the proposal may not be able to manage a case that, for example, class files of an app are compiled for Java 6, but the developer(s) of the app want to run it on Java 7 (or 8). It should be a usual case.

There is also another hurdle that which class file(s) should be used to determine the Java version. For example, there may be a case that the main class file is compiled with Java 7 while class files in a library JAR are compiled with Java 8, or vice versa. I know the latter case is actually not an issue, but for the former case the Java version can't be determined only with the main class file.

I'll say again that Dan's idea is interesting. But I think there will be some difficulties yet with the automatic determination of Java version.

Thanks again, guys. And I'm still wating for Ben Hale's opinion on the original issue.


2014年5月15日木曜日 7時33分30秒 UTC+9 Ryan Morgan:

[Noburou Taniguchi]

Bringing up this (somewhat old) thread for an annoucement / notification.

We've published a configurable version of Java Buildpack at:
https://github.com/cloudn/java-buildpack

With this buildpack, an application developer can switch Java version by a config file in her/his application directory.

Here is an explanation for how to switch Java version.

Feel free to use this for your convenience. We also welcome any comment or issue from users of the buildpack.

We still want it to be merged the upstream, so I would like the Pivotal peoplea to take a look if you have time.


2014年5月8日木曜日 21時03分42秒 UTC+9 Noburou Taniguchi:

[David Currie]

Now that the Java buildpack has moved up to Java 8 and, given that there are incompatibilities between Java 7 and 8 (we hit an issue in OpenJPA with changes to ConcurrentHashMap for example), bumping this for input from the Java buildpack team on whether they'd consider adding support for the end user to specify the required Java version.

Regards,

David

[Christopher Frost]

Hi,

You will need to fork the Java buildpack and edit the Java version in this [1] file. Then edit the deployment manifest for you application to specify your fork of the buildpack.

[1] https://github.com/cloudfoundry/java-buildpack/blob/master/config/open_jdk_jre.yml

Chris.

--
You received this message because you are subscribed to the Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/ff3c0a99-0580-4ab5-a481-f0958ad8b589%40cloudfoundry.org.

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

--

--
Christopher Frost - GoPivotal UK

[David Currie]

Chris

Forking the buildpack seems a heavy price for the end user to pay in order to express what is otherwise a very simple constraint on the application dependencies. Do I take this to mean that you would not consider providing the ability for the user to select between multiple Java versions at push time from a single instance of the buildpack?

Regards
David

[Ben Hale]

David,

We've got an issue on the backlog to auto-detect the major version of Java that an app is likely to want and that'll probably be the direction that we go.  There have been discussions on how to allow users to specify configuration within the application, but I've not been convinced by any example that I've seen yet.  It's not to say that we wouldn't do such a thing, but the value that it added would need to outweigh the complexity that it introduced before we'd start considering the change.

-Ben Hale

Cloud Foundry Java Experience

[cfr...@pivotal.io]

Just to update this thread.

Our first attempt at implementing auto-detection didn't work out too well, turned out to be a few edge cases that cause the buildpack to fail staging in different circumstance. This change has been backed out for now and we are looking at other possible solutions to this problem.

Chris.

[John McTeague]

Im very much of the opinion that this should be a straightforward flag, possibly an env var (e.g JAVA_VERSION=1.8.0_+), to allow explicit selection. Auto detection just seems like the buildpack trying to be too smart and edge cases will occur that break the auto-detection model.

Other buildpacks (ruby, php) have mechanisms to explicitly declare runtime versions. I would like to see some degree of consistency across all the buildpacks in this regard.

John

[da...@curries.org.uk]

I'm in agreement with John that explicit selection should be allowed (at least at the major version level) and we are currently discussing what form such a flag should take for the WebSphere Liberty buildpack. As always, it would be preferable if that were something in common with the Java buildpack.

Regards,

David

[Quintessence Anx]

Would it be possible to allow the Java buildpack to use the manifest.yml file to read in the user's desired version number in a way similar to the way that it is done manually (i.e. forking) now?

[Ken Krueger]

No, the manifest.yml is not known outside of the client.  However The buildpack can read environment variables, and you can specify an environment variable in a manifest - which amounts to the same thing.  Many buildpacks allow environment variables to control the version.

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/480721f5-6632-4ea9-a12b-34d578ffe6d5%40cloudfoundry.org.

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

--

Ken Krueger  

Manager, Global Education Delivery

407 256 9737 Mobile

kenkrueger65 Skype

Education questions?  educ...@pivotal.io

[Guillaume Berche]

FYI, related thread at https://groups.google.com/a/cloudfoundry.org/d/msg/vcap-dev/4-KAD11FKfI/hzQFLrGN9osJ

[Jack C]

+1 for the env variable approach.

Or, we introduce a deployment file just like other buildpacks have (package.json for node.js, etc.)?

Jack

[cfr...@pivotal.io]

All,

We have now introduced this feature in to master and it will be released in due course.

See https://github.com/cloudfoundry/java-buildpack#configuration-and-extension

Thanks, Chris.

[James Bayer]

great news! thanks for listening to the community feedback and adjusting this. the developer user experience is much improved with this approach.

--

You received this message because you are subscribed to the Google Groups "Cloud Foundry Developers" group.

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/6dfa0c82-2412-46a0-a252-10053f67071f%40cloudfoundry.org.

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

--

Thank you,

James Bayer

[Josh Long]

cool! Thanks for this! I suspect this’ll dramatically reduce the # of forks out there :)   

-- 


Thanks,
Josh Long
Spring Developer Advocate
Pivotal
http://www.joshlong.com || joshlong.com || http://twitter.com/starbuxman

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAB%3Dt-sXZ%3DFK43wqkBDQfU0U9hYt9501Kq3NWq-HgoFPUwEAtCw%40mail.gmail.com.

[Noburou Taniguchi]

It's a good news for me (and our team) as the starter of this thread.

Thanks to the Java buildpack team!

2015年3月25日水曜日 21時04分23秒 UTC+9 cfr...@pivotal.io:

[Guillaume Berche]

Thanks a lot Chris for implementing this feature which opens up new potentials for automation (e.g. automated compatibility testing across java/tomcat major branch latest versions in a ci pipeline, and always using the latest buildpack version), I love it!

Some teams might find it useful to define some of these variables in a "staging environment variable group" when it makes sense to share them among apps, and they don't want to fork the buildpack. Wondering whether it could make sense to mention it into https://github.com/cloudfoundry/java-buildpack#configuration-and-extension.

I tried defining the key into a manifest but it seems the cli rejected it, unless I mistyped it ? Should I submit a cli issue ?

$ cat pivotal-spring-travel-master.yml
---
applications:
- name: spring-travel
[...]
  env:
    -  JBP_CONFIG_TOMCAT: '[ access_logging_support: { access_logging: enabled }  ]'

$ cf push -f pivotal-spring-travel-master.yml --no-start -b https://github.com/cloudfoundry/java-buildpack.git
FAILED
Error reading manifest file:
Expected env to be a set of key => value, but it was a [map[JBP_CONFIG_TOMCAT:[ access_logging_support: { access_logging: enabled }  ]]].

$ cf --version
C:\Program Files (x86)\CloudFoundry\cf.exe version 6.10.0-b78bf10-2015-02-11T22:26:25+00:00

Assigning the same env with "cf set-env" works fine.

I tried enabling the tomcat access logging with it. This seems to indeed trigger the access logging in the buildpack, but I can't see the logs coming out in cf logs. I'm suspecting this is unrelated to buildpack config (maybe a regression w.r.t. tomcat version ?). Full details follow (should we continue in another thread or a  dedicated java-buildpack issue?).

Thanks again,

Guillaume.

$ cf push -f pivotal-spring-travel-master.yml --no-start -b https://github.com/cloudfoundry/java-buildpack.git
$ cf set-env spring-travel JBP_LOG_LEVEL DEBUG
$ cf set-env spring-travel JBP_CONFIG_TOMCAT '[ access_logging_support: { access_logging: enabled }  ]'

Access logs don't output:

$ cf logs spring-travel
Connected, tailing logs for app spring-travel in org bercheg-org / space development as bercheg...

2015-03-26T12:52:08.52+0100 [App/0]      OUT DEBUG: org.springframework.webflow.mvc.servlet.FlowHandlerMapping - No flow mapping found for request with URI '/'
2015-03-26T12:52:08.54+0100 [RTR/1]      OUT spring-travel-nonoperatic-plagioclastic.cfapps.io - [26/03/2015:11:52:08 +0000] "GET / HTTP/1.1" 200 3662 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0" 10.10.2.122:45631 x_forwarded_for:"193.252.157.50" vcap_request_id:fa987115-cebf-4242-5450-24785692abe0 response_time:0.011854906 app_id:f6f01940-217e-4164-b134-75430b45619f
2015-03-26T12:52:08.80+0100 [App/0]      OUT DEBUG: org.springframework.webflow.mvc.servlet.FlowHandlerMapping - No flow mapping found for request with URI '/resources/javascript/spring/Spring-Dojo.js'
2015-03-26T12:52:08.82+0100 [RTR/1]      OUT spring-travel-nonoperatic-plagioclastic.cfapps.io - [26/03/2015:11:52:08 +0000] "GET /resources/javascript/spring/Spring-Dojo.js HTTP/1.1" 304 0 "http://spring-travel-nonoperatic-plagioclastic.cfapps.io/" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0" 10.10.2.122:45631 x_forwarded_for:"193.252.157.50" vcap_request_id:5a961d61-c140-4db8-66a

I indeed see the config modification triggered

[ConfigurationUtils] DEBUG Configuration from /tmp/buildpacks/java-buildpack/config/tomcat.yml: {"tomcat"=>{"version"=>"8.0.+", "repository_root"=>"{default.repository.root}/tomcat"}, "lifecycle_support"=>{"version"=>"2.+", "repository_root"=>"{default.repository.root}/tomcat-lifecycle-support"}, "logging_support"=>{"version"=>"2.+", "repository_root"=>"{default.repository.root}/tomcat-logging-support"}, "access_logging_support"=>{"version"=>"2.+", "repository_root"=>"{default.repository.root}/tomcat-access-logging-support", "access_logging"=>"disabled"}, "redis_store"=>{"version"=>"1.+", "repository_root"=>"{default.repository.root}/redis-store", "database"=>0, "timeout"=>2000, "connection_pool_size"=>2}, "gemfire_store"=>{"gemfire"=>{"version"=>"8.0.+", "repository_root"=>"{default.repository.root}/gem-fire"}, "gemfire_modules"=>{"version"=>"8.0.+", "repository_root"=>"{default.repository.root}/gem-fire-modules"}, "gemfire_modules_tomcat7"=>{"version"=>"8.0.+", "repository_root"=>"{default.repository.root}/gem-fire-modules-tomcat7"}, "gemfire_security"=>{"version"=>"8.0.+", "repository_root"=>"{default.repository.root}/gem-fire-security"}, "gemfire_logging"=>{"version"=>"1.5.8", "repository_root"=>"{default.repository.root}/slf4j-jdk14"}, "gemfire_logging_api"=>{"version"=>"1.5.8", "repository_root"=>"{default.repository.root}/slf4j-api"}}}
[ConfigurationUtils] DEBUG Configuration from /tmp/buildpacks/java-buildpack/config/tomcat.yml modified with: [ access_logging_support: { access_logging: enabled, version: "2.+", repository_root: "{default.repository.root}/tomcat-access-logging-support" } ]

and the logging support being downloaded and enabled in JVM properties

App spring-travel was started using this command `JAVA_HOME=$PWD/.java-buildpack/open_jdk_jre JAVA_OPTS="-Djava.io.tmpdir=$TMPDIR -XX:OnOutOfMemoryError=$PWD/.java-buildpack/open_jdk_jre/bin/killjava.sh -Xmx768M -Xms768M -XX:MaxMetaspaceSize=104857K -XX:MetaspaceSize=104857K -Xss1M -Daccess.logging.enabled=true -Dhttp.port=$PORT" $PWD/.java-buildpack/tomcat/bin/catalina.sh run`



$ cf files spring-travel app/.java-buildpack/tomcat/lib | grep logging
tomcat_access_logging_support-2.4.0_RELEASE.jar 3.5K


The access valve seems enabled in tomcat:

$ cf files spring-travel app/.java-buildpack/tomcat/conf/server.xml
Getting files for app spring-travel in org bercheg-org / space development as bercheg@gmail.com...
OK

<?xml version='1.0' encoding='utf-8'?>

<Server port='-1'>

 <Service name='Catalina'>
 <Connector port='${http.port}' bindOnInit="false"/>

 <Engine defaultHost='localhost' name='Catalina'>
 <Valve className="org.apache.catalina.valves.RemoteIpValve" protocolHeader="x-forwarded-proto"/>
 <Valve className="com.gopivotal.cloudfoundry.tomcat.logging.access.CloudFoundryAccessLoggingValve"
 pattern='[ACCESS] %{org.apache.catalina.AccessLog.RemoteAddr}r %l %t %D %F %B %S vcap_request_id:%{X-Vcap-Request-Id}i'
 enabled="${access.logging.enabled}"/>
 <Host name='localhost'>
 <Listener className="com.gopivotal.cloudfoundry.tomcat.lifecycle.ApplicationStartupFailureDetectingLifecycleListener"/>
 </Host>
 </Engine>
 </Service>

</Server>

[Christopher Frost]

Hi Guillaume

You have an extra '-' in your manifest file before the variable declaration. Try this.

---
applications:
- name: cgfrost-web-servlet-2-application 

  ... 

  env:
    JBP_CONFIG_TOMCAT: '[ access_logging_support: { access_logging: enabled }  ]'
   

Works for me, send me the whole manifest if your still having issues.

Chris.

On Thu, Mar 26, 2015 at 1:10 PM, Christopher Frost <cfr...@pivotal.io> wrote:

Hi Guillaume

You have an extra '-' in your manifest file before the variable declaration. Try this.

---
applications:
- name: cgfrost-web-servlet-2-application 

  ... 

  env:
    JBP_CONFIG_TOMCAT: '[ access_logging_support: { access_logging: enabled }  ]'
   

Works for me, send me the whole manifest if your still having issues.

Chris.

--

--
Christopher Frost - GoPivotal UK

[Guillaume Berche]

Thanks Chris, sorry for the typo and the associated noise.

Guillaume.

[Etourneau Gwenn]

Thanks, that's a really good new.