Agree on all counts. We've already suggested vendoring the gems inside the buildpack to ensure they're there on the staging container. I'm now suggesting that the bin scripts just can't find the

It's not an issue of pointing to the gems. The build pack runs (staging) in it's own container. The container is completely isolated from the DEA or Diego Cell where it's running. You can't access

Thanks DHR Team. Yes your correct like the required gem is not available in staging container stack. but these stacks are pre packaged in cf release. Not sure how we can do this Gem.path update for

Thanks a lot DHR team.. Let us try out this approach . Regards Lingesh M

So I think your problem is that your gems are on the DEA at staging time but aren't being found by the Ruby layer, right? If so the normal approach is to point to them via an env Var (eg BUNDLE_PATH,

You could change the config/repository.yml to point to a DNS name on your network. Then build out one or more local repositories on your network using the Java-buildpack-dependency-builder:

Hi Cloudfoundry , In java-buildpack ,*https://download.run.pivotal.io <https://download.run.pivotal.io> *URL is used for default_repository_root for all binaries , but this URL may not be accessible

not an issue .Thanks Dan !!!

You can take a look at https://github.com/pivotal-cf/pcfdev. Thanks wrote:

OK, my fault. I misunderstood what you're trying to do here. I was thinking that your application needed the gems, but it's your build pack that needs them. You originally said... because of few

Hi all, sorry in advance of the maybe naif question. I was wondering if I could find somewhere an all-In-One Virtual Machine with the last version of CF like openshift origin. thank you in advance

yes Dan, we have used below commands to package the buildpack . bundle install bundle exec rake package version=custom-java-buildpack after that we will take the zip and create a offline buildpack

yes, there has been a typo. Thank you for pointing out ! The correct CVE number is : *CVE-2016-3084* Thanks, Sree Tummidi Sr. Product Manager Identity - Pivotal Cloud

Hi Chip, I think there might be a typo here as the CVE reference seems to be the same as for the UAA persistent XSS vulnerability. G

CVE-2016-0781 UAA Password Reset VulnerabilitySeverity Low Vendor Cloud Foundry Foundation Versions Affected - Cloud Foundry release v236 and earlier versions - UAA release v3.3.0 and

-What information were you trying to understand from mem_used_bytes? We used mem_used_bytes and mem_free_bytes (currently metrics from bosh) to get an overview over the real overall memory usage of

You need to bundle install the gem in the staging container. The build pack would generally do this. Dan lingeshmouleeshwaran(a)gmail.com> wrote:

Hi Dan , yes I have installed the require gem via *bundle install* to specify the path of vendor staging directories which is available in below paths /var/vcap/data/packages/dea_next/*

lingeshmouleeshwaran(a)gmail.com> wrote: This is the way you should be doing it. What about this doesn't help / work for you? Dan

When 234 was released, we did not realize that Collector was creating additional metrics. Based on reports, we have added back any missing metrics that people felt were needed. Let me know if we