Hi, We are trying to push an buildpack using cf creat-buildpack command and below are the CF_TRACE logs REQUEST: [2016-05-03T06:20:46Z] PUT /v2/buildpacks/9899f3d5-8eab-454e-accb-fcb6d139d69f/bits

Hi, We are trying to push an buildpack using cf creat-buildpack command and below are the CF_TRACE logs REQUEST: [2016-05-03T06:20:46Z] PUT /v2/buildpacks/9899f3d5-8eab-454e-accb-fcb6d139d69f/bits

Thanks for investigation. Actually my APP is a jetty based application, the APP releases included all required jetty jar and configuration files, so it should not related to this tomcat setting? As

Agree ! That's awesome ! Envoyé de mon iPhone

This is awesome! Thanks guys! Mike

Agree with Dan. Currently most APM vendors use the VCAP_APPLICATION env variable for mapping and keeping track of a specific instance using the instance guid, instance index, app guid fields.

I have a few customers that grab that instance index to aid in monitoring and logging and to self identify in certain situations. Is there an issue with continuing to expose the instance index? I

I know some of the build packs will look at application name and use that for configuration of some of the APM agents (NewRelic, AppDynamics,

While I dont use this directly, my first reaction is some libraries such as Spring Cloud Connectors depend on this to identify that an app is running in CF, and we rely heavily on Spring Cloud

Hi CF-Dev, The CAPI team is working hard to get to MVP for V3 of the Cloud Foundry API. You can follow along by visiting our documentation and

Hi Stanley, We can reproduce your issue when we push your .war file to a CF running on bosh-lite. We actually also see this same behavior when we run the .war file on a local Tomcat with default

Hi there! We wanted to let you know of a significant feature addition to the PHP buildpack. Thanks to Daniel Mikusa and the Buildpacks team the PHP Buildpack now has support for persistent sessions

hello, I tried with latest cf/diego release. I still can reproduce the issue. I am using all things provided by CF without any customization. I just push my servlet APP and access it from command

Hi, Mod_security [1] is a flexible opensource web application firewall, which runs configureable rules to detect and possible filter malicious incoming HTTP requests received (XSS, SQL injection

If possible add more logging or increase logging levels. Not sure what language / runtime you're using, but you might be able to add an exit hook or some code that is guaranteed to run before your

No, I didn't see error or related messages in the logs prior to the application existing. I also executed the command "bosh logs cell_z1 0" to get the log of cell_z1 0, but didn't find any useful

This isn't really a problem with the build pack. It's a problem with compiling one of the native modules that you are using ` dtrace-provider(a)0.2.8`. Not sure why that's failing. There's some

It is the exit status of your application. In other words, your app exited and returned this number. http://tldp.org/LDP/abs/html/exit-status.html It may be an application specific number or it

Sorry, the version of CF and Diego in previous mail is incorrect, CF release version is v233, Diego version is V 0.1460.0

Hello, I deployed an application to Diego, found this application often got restarted, there is no error message in the log, just found the following message, what does the status code 255