Date   

CF Release Scripts Moved

Natalie Bennett
 

CF Release top-level scripts have been moved. The new location is under the
`scripts/` folder.

Thanks,
CF OSS Release Integration Team


Migrating from 10.244.0.34.xip.io to bosh-lite.com

Dan Wendorf
 

On the CAPI team, we were experiencing pain around the flakiness of xip.io
causing spurious test failures. We have registered bosh-lite.com, which is
just an A record to 10.244.0.34, as well as for its subdomains (e.g.
foo.bar.bosh-lite.com also resolves to 10.244.0.34).

We would like to switch cf-release, cf-acceptance-tests, and smoke-tests to
use bosh-lite.com exclusively, but wanted to check with the community to
see if there are any compelling reasons not to switch. In the case that
there's no reason not to switch, we wanted to give a little bit of a
heads-up before making the change.

In our testing of this, CATs run just fine. On our bosh-lite CF
environment, we had to `cf delete-shared-domain 10.244.0.34.xip.io`, `cf
target -o CATS-persistent-org && cf delete CATS-persistent-app`, and update
the file in our CONFIG environment variable to make tests pass, but
everything else "just worked".

You can review these changes on the bosh_lite_com branches of the following
repositories:

cf-acceptance-tests
<https://github.com/cloudfoundry/cf-acceptance-tests/tree/bosh_lite_com>
cf-smoke-tests
<https://github.com/cloudfoundry/cf-smoke-tests/tree/bosh_lite_com>
cf-release <https://github.com/cloudfoundry/cf-release/tree/bosh_lite_com>
sprout-capi
<https://github.com/cloudfoundry-incubator/sprout-capi/tree/bosh_lite_com>
(for those interested in configuring their bosh-lite via Sprout)

Thoughts?


FYI: Survey: Cloud Foundry Service Broker Compliance

Michael Maximilien
 

Hi, all,

I've been working on some side projects with IBM Research to improve
various aspects of CF. Some are pretty early research work and some are
ready to graduate and presented to you.

One of these relates to compliance of CF Service Brokers. We want to share
this work and make it open. We are planning a series of meetings next week
to socialize, open, and propose incubation. If interested then ping me
directly.

--------
In the mean time, Mohamed and Heiko, my colleagues from IBM Research, and
I have put together a short (literally two minutes) survey to gage what
would be the value of having Cloud Foundry (CF) service brokers
compliance.

https://www.surveymonkey.com/r/N37SD85

We'd be grateful if you could find some time to take this short survey
before we start socializing the solution we have been working on.

--------
Feel free to forward the survey link to others who may not be on this
mailing list and that you think should also take the survey

After we gather results, we will share a summary with everyone by next
Thursday.

All the best,

Mohamed, Heiko, and Max

------
dr.max
ibm cloud labs
silicon valley, ca
maximilien.org


CF-Abacus: IPMs

Michael Maximilien
 

Hi, all,

For anyone interested in CF-Abacus, we are having our IPMs on Friday's @
10a PDT @ Pivotal HQ.

I don't have a room reserve for tomorrow, but please ping me if you are
interested in joining and I will add you to the invite list.

For folks at Pivotal, the team will have our scrum right after standup
near the ping pong area tomorrow, so feel free to swing by.

Best,

------
dr.max
ibm cloud labs
silicon valley, ca
maximilien.org


UAA: Level count of Spaces under an Org

Zongwei Sun
 

Currently, there is only 1 level of Spaces under an Org with UAA. I heard people talking about adding more levels of Spaces to it. I'd like to have some discussions if this really makes sense. Thanks.


Re: tcp-routing in Lattice

Atul Kshirsagar
 

Great! Give us your feedback after you have played around with tcp routing.


Re: tcp-routing in Lattice

Jack Cai
 

After ssh into the vagrant VM and digging into the processes/ports, I found
out that in my previous attempt I was trying to map one additional port
that was already occupied by garden (7777). Because of this conflict,
haproxy gave up mapping all the ports. Once I changed 7777 to 17777, the
issue went away.

So the lesson-learn is to examine the ports that are already in use in the
vagrant VM, and avoid using them.

Jack

On Thu, Sep 10, 2015 at 2:18 PM, Jack Cai <greensight(a)gmail.com> wrote:

Thanks Atul and Marco for your advice.

Below is the command I used to push the docker image:

* ltc create hello <docker-image> --ports 8888,8788 --http-routes
hello:8888 --tcp-routes 8788:8788 --memory-mb=0 --timeout=10m
--monitor-port=8888*

After the push completed, it reported below:





*...hello is now running.App is reachable at:192.168.11.11.xip.io:8788
<http://192.168.11.11.xip.io:8788>http://hello.192.168.11.11.xip.io
<http://hello.192.168.11.11.xip.io>*

I also tried to update the routes:


* ltc update hello --http-routes hello:8888 --tcp-routes 8788:8788*
If I do "ltc status hello", I see the below routes:








*Instances 1/1Start Timeout 0DiskMB 0MemoryMB
0CPUWeight 100Ports 8788,8888Routes
192.168.11.11.xip.io:8788 <http://192.168.11.11.xip.io:8788> =>
8788 hello.192.168.11.11.xip.io
<http://hello.192.168.11.11.xip.io> => 8888*

But when I visited http://192.168.11.11.xip.io:8788/, I got "Unable to
connect", while I could visit http://hello.192.168.11.11.xip.io/
successfully.

Below is the log I saw when doing "vagrant up" to bring up Lattice:



















*...==> default: stdin: is not a tty==> default: mkdir: created directory
â/var/latticeâ==> default: mkdir: created directory â/var/lattice/setupâ==>
default: Running provisioner: shell... default: Running: inline
script==> default: stdin: is not a tty==> default: * Stopping web server
lighttpd==> default: ...done.==> default: Installing cflinuxfs2
rootfs...==> default: done==> default: * Starting web server lighttpd==>
default: ...done.==> default: Installing Lattice (v0.4.0) (Diego
0.1398.0) - Brain==> default: Finished Installing Lattice Brain (v0.4.0)
(Diego 0.1398.0)!==> default: Installing Lattice (v0.4.0) (Diego 0.1398.0)
- Lattice Cell==> default: Finished Installing Lattice Cell (v0.4.0) (Diego
0.1398.0)!==> default: bootstrap start/running==> default: Lattice is now
installed and running.==> default: You may target it using: ltc target
192.168.11.11.xip.io <http://192.168.11.11.xip.io>*

There is an error "stdin: is not a tty", and I don't see haproxy mentioned
in the log. Maybe haproxy is not started at all?

Jack



On Wed, Sep 9, 2015 at 8:13 PM, Marco Nicosia <mnicosia(a)pivotal.io> wrote:

Hi Jack,

In addition to Atul's suggestions, could you please give us the exact
command lines which you used to launch the two apps?

The CLI arguments are tricky, we may be able to see something about the
way you've tried to configure the routes by looking at how you've launched
the apps.

--
Marco Nicosia
Product Manager
Pivotal Software, Inc.
mnicosia(a)pivotal.io
c: 650-796-2948


On Wed, Sep 9, 2015 at 2:32 PM, Jack Cai <greensight(a)gmail.com> wrote:

I'm playing around with the tcp-routing feature in the latest Lattice
release. I started two node.js applications in the pushed image (listening
on two ports), one mapped to an http route and the other to a tcp route. I
can connect to the http route successfully in the browser, but when I try
to connect to the tcp port in the browser, I got connection refused. It
looks like the mapped public tcp port on 192.168.11.11 is not open at all.
Any advice on how to diagnose this? Thanks in advance!

Jack


Starting Spring Boot App after deploying it to CF

Qing Gong
 

I built a Spring Boot App and using java -jar SpringBootApp.jar to run it, the code works as expected. The System.out printed as expected.

public static void main(String[] args)
{
SpringApplication.run(Application.class, args);
System.out.println("Spring Boot Test Message");
}

However, when deployed in CF using cf push myApp -p SpringBootApp.jar, the main() was not executed. I have tried using META-INF/MANIFEST.MF to include the Main-Class, or using config/java-main.yml, or manifest.yml to include java_main_class, none worked. The app just would not start. Do I need to do anything else to trigger the app to start its main method?

Thanks!


Re: tcp-routing in Lattice

Jack Cai
 

Thanks Atul and Marco for your advice.

Below is the command I used to push the docker image:

* ltc create hello <docker-image> --ports 8888,8788 --http-routes
hello:8888 --tcp-routes 8788:8788 --memory-mb=0 --timeout=10m
--monitor-port=8888*

After the push completed, it reported below:





*...hello is now running.App is reachable at:192.168.11.11.xip.io:8788
<http://192.168.11.11.xip.io:8788>http://hello.192.168.11.11.xip.io
<http://hello.192.168.11.11.xip.io>*

I also tried to update the routes:


* ltc update hello --http-routes hello:8888 --tcp-routes 8788:8788*
If I do "ltc status hello", I see the below routes:








*Instances 1/1Start Timeout 0DiskMB 0MemoryMB
0CPUWeight 100Ports 8788,8888Routes
192.168.11.11.xip.io:8788 <http://192.168.11.11.xip.io:8788> =>
8788 hello.192.168.11.11.xip.io
<http://hello.192.168.11.11.xip.io> => 8888*

But when I visited http://192.168.11.11.xip.io:8788/, I got "Unable to
connect", while I could visit http://hello.192.168.11.11.xip.io/
successfully.

Below is the log I saw when doing "vagrant up" to bring up Lattice:



















*...==> default: stdin: is not a tty==> default: mkdir: created directory
â/var/latticeâ==> default: mkdir: created directory â/var/lattice/setupâ==>
default: Running provisioner: shell... default: Running: inline
script==> default: stdin: is not a tty==> default: * Stopping web server
lighttpd==> default: ...done.==> default: Installing cflinuxfs2
rootfs...==> default: done==> default: * Starting web server lighttpd==>
default: ...done.==> default: Installing Lattice (v0.4.0) (Diego
0.1398.0) - Brain==> default: Finished Installing Lattice Brain (v0.4.0)
(Diego 0.1398.0)!==> default: Installing Lattice (v0.4.0) (Diego 0.1398.0)
- Lattice Cell==> default: Finished Installing Lattice Cell (v0.4.0) (Diego
0.1398.0)!==> default: bootstrap start/running==> default: Lattice is now
installed and running.==> default: You may target it using: ltc target
192.168.11.11.xip.io <http://192.168.11.11.xip.io>*

There is an error "stdin: is not a tty", and I don't see haproxy mentioned
in the log. Maybe haproxy is not started at all?

Jack

On Wed, Sep 9, 2015 at 8:13 PM, Marco Nicosia <mnicosia(a)pivotal.io> wrote:

Hi Jack,

In addition to Atul's suggestions, could you please give us the exact
command lines which you used to launch the two apps?

The CLI arguments are tricky, we may be able to see something about the
way you've tried to configure the routes by looking at how you've launched
the apps.

--
Marco Nicosia
Product Manager
Pivotal Software, Inc.
mnicosia(a)pivotal.io
c: 650-796-2948


On Wed, Sep 9, 2015 at 2:32 PM, Jack Cai <greensight(a)gmail.com> wrote:

I'm playing around with the tcp-routing feature in the latest Lattice
release. I started two node.js applications in the pushed image (listening
on two ports), one mapped to an http route and the other to a tcp route. I
can connect to the http route successfully in the browser, but when I try
to connect to the tcp port in the browser, I got connection refused. It
looks like the mapped public tcp port on 192.168.11.11 is not open at all.
Any advice on how to diagnose this? Thanks in advance!

Jack


Proposal: UAA SAML Integration & Mapping CF Roles to external groups

Sree Tummidi
 

Hi all,

The UAA team has come with a proposal for handling claims (User Attributes
& Group Memberships) from SAML Identity Providers. These claims can be
further mapped to CF roles in order to derive CF role memberships from
external group memberships.

The Proposal is split into two parts.


- Part 1 deals with the general UAA & SAML Integration for handling SAML
claims. This involves exposing them in OpenID Connect ID Token and allow
mapping of claims to OAuth Scopes for coarse grained authorization. The
proposal can be found here
<https://docs.google.com/a/pivotal.io/document/d/107sv7YqxdoDWi2vX5Z8WHm1JaqwHZOL_wa-esn2U5cE/edit?usp=sharing>
.
- Part 2 deals with leveraging the claims received in the ID Token to
derive CF role memberships. The proposal can be found here
<https://docs.google.com/a/pivotal.io/document/d/1UBtwEma5pkivNHD1QfTXOpPZAWCBE8Az9OVoT7oO0G4/edit?usp=sharing>
.



We are looking forward to you valuable feedback and suggestions on these
topics.
Happy Reviewing !!


Thanks,
Sree Tummidi
Sr. Product Manager
Identity - Pivotal Cloud Foundry


Re: Cloud Foundry NodeJS 4 support and release schedule

Mike Dalessio
 

Quick update on Node 4, which is that we're blocked on openssl
compatibility.

One of the requirements we place on binaries we ship with CF buildpacks is
that libraries should be dynamically linked from the rootfs whenever
possible, particularly for libraries that are likely to be affected by
CVEs, so that we can patch everything with a rootfs update.

Node has defaulted, for quite a while, to statically linking OpenSSL,
despite a history of not-infrequent CVEs affecting that library. The Node
build scripts do allow overriding this, and choosing to dynamically link
instead. We've used this option successfully for building all of the
CF-supported 0.x node versions against the openssl 1.0.1 versions that are
shipped with Ubuntu 14.04 LTS (and therefore the cflinuxfs2 rootfs).

However, in Node 4, the code only supports openssl 1.0.2. That is, it fails
to compile against openssl 1.0.1 headers.

(Possibly worth mentioning for additional context, even RHEL7 appears to
still ship openssl 1.0.1.)

We opened a Github issue on the node project, which has been closed without
a suggested fix for our situation:

https://github.com/nodejs/node/issues/2783

We've also reached out to friends of the CFF at Joyent, and IBM has notably
reached out to their own Node committers on staff. I'll keep this thread
updated as the conversation progresses.

I'm not comfortable introducing a new binary to the CF ecosystem that's not
"patch-able" via a rootfs update. I'm open to suggestions around what else
we could be doing to move towards shipping Node 4, but for right now we're
blocked.

-m

On Wed, Sep 9, 2015 at 3:52 PM, Shawn Nielsen <sknielse(a)gmail.com> wrote:

Thanks for the quick feedback on this, we appreciate your responsiveness.
We'll continue to follow the issue in the pivotal tracker.

On Wed, Sep 9, 2015 at 12:36 PM, Mike Dalessio <mdalessio(a)pivotal.io>
wrote:

Hi Shawn,

Great question, thanks for asking it.

The Buildpacks team has a Tracker story in its backlog to work on Node 4:

https://www.pivotaltracker.com/story/show/102941608

Generally our turnaround time on vanilla version updates is less than a
day; however, Node 4 isn't just a regular version update, as it comes from
io.js lineage which we haven't ever officially supported; and so we're
going to proceed carefully.

The story I linked to has some specific acceptance criteria:

* Does the binary build with our current tooling? If not, we'll have to
update our tooling.
* Does the binary dynamically link openssl? (This was a specific use case
we've had to work around in the past.) If not, we'll have to make sure it
does, so that rootfs updates will be sufficient to address openssl CVEs.
* Does the binary avoid statically linking any other rootfs libraries? If
not, see above.
* Does the binary pass BRATs? If not, we'll have to fix BRATs.

Only when all of the above look good will we ship; and since we haven't
worked with io.js and family before, I don't want to make any promises
about delivery. If things go well, it could ship as early as tomorrow,
though that's probably overly optimistic.

Additionally I'll likely delay committing it into cf-release until we
have positive feedback from the community.

I'm happy to keep this thread updated with our progress; or you can
follow along at the Tracker story.

Cheers,
-mike


On Wed, Sep 9, 2015 at 11:33 AM, Shawn Nielsen <sknielse(a)gmail.com>
wrote:

NodeJS version 4 was released yesterday to the community.

Generally speaking, what is the typical release schedule for buildpack
binaries after new runtime releases are announced?

More specifically, I'd be curious if you have information on release
schedule of the NodeJS 4 buildpack binaries.






CF Summit EU / China - Dates and contributor registration codes

Chip Childers <cchilders@...>
 

Hi all!

Two things about our upcoming CF Summit EU and CF Summit China:

Key dates for both... (The call for talk proposals for both are closing
soon):

*CF Summit EU - November 2nd & 3rd - Berlin*
CFP Closed: September 11, 2015 - http://berlin2015.cfsummit.com/program/cfp
CFP Notifications: September 29, 2015
Schedule Announced: October 1, 2015
Event Dates: November 2-3, 2015

*CF Summit China - December 2nd & 3rd - Shanghai*
CFP Closed: September 25, 2015 -
http://shanghai2015.cfsummit.com/program/cfp
CFP Notifications: October 13, 2015
Schedule Announced: October 15, 2015
Event Dates: December 2 & 3, 2015

For these events, we are providing a 25% discount code for registration to
contributors of CF projects. This is "trust-based", in that I'm sharing on
public lists. If you have contributed to the development of a CF project in
any way (docs, code, feature comments), feel free to use these codes.

Berlin: CFEU15CON

Shanghai: CFAS15CON


Chip Childers | VP Technology | Cloud Foundry Foundation


Re: Update on Mailman 3 launch

Marco Nicosia
 

Hi Marco V,

Thanks for remembering to keep on this.

Now that you mention it, I haven't gotten any cf-bosh digests till I
suddenly got two this morning.

But less recent e-mails ("Bosh target password." from Sept 2) have never
appeared in my inbox.


--
Marco Nicosia
Product Manager
Pivotal Software, Inc.
mnicosia(a)pivotal.io
c: 650-796-2948

On Thu, Sep 10, 2015 at 8:07 AM, Voelz, Marco <marco.voelz(a)sap.com> wrote:

Bump & adding Eric and Marco Nicosia directly, just in case. Any updates
on this?




On 28/08/15 11:23, "Marco Voelz" <marco.voelz(a)sap.com> wrote:

Hi Eric,

Just to confirm, did you leave it enabled in "mime digest" mode for
longer than
a day so that there was list traffic to bundle and digest for you? I
don't see any
errors in the error log related to MIME digest sends, but see about
reproducing this today
and submit a bug.
Yes, I can confirm that I left mime digest on for several days and there
were mails which I didn't receive. Note that regular digests aren't working
for me, either. Currently the only working setting seems to be single mail
delivery, which is not my preferred setting.

Did you manage to reproduce that?

The preference lookup appears to give precedence to the settings on the
subscription, then
on the address, then on the user ("global"), and finally on the system
default—it stops at the first defined value it sees. I'll file a bug
to have some
better clarification in the UI.
Great, thanks for the bug and the explanation!

Warm regards
Marco


Re: UAA user dynamic properties

Sree Tummidi
 

Just wanted to add that we could collaborate on the design front and we are open to pull requests !!

-sree

Sent from my iPad

On Sep 10, 2015, at 6:45 AM, Sree Tummidi <stummidi(a)pivotal.io> wrote:

Hi,
We do have plans to support custom attributes and is a roadmap item. This is however not in the immediate future.

Thanks,
Sree

Sent from my iPhone

On Sep 10, 2015, at 4:13 AM, Viktor Khoroshko <oceansize(a)tut.by> wrote:

Hello everyone,

We're currently evaluating UAA to be used as Central Identity Provider in our system. And the issue for us is that It's not allowed to store additional user properties (you're limited by users columns that are currently supported).
Therefore, we have a question - are there any plans to add user dynamic properties support in future releases? Or, at least, do you agree that this would be an useful feature (so we may contribute)?

Thanks in advance


Re: Stdout from Spring Boot app in CF

Qing Gong
 

Thanks James. It was my mistake in Spring Boot app configuration. The stdout did go to the firehose.

Sorry about this.


Re: Update on Mailman 3 launch

Marco Voelz
 

Bump & adding Eric and Marco Nicosia directly, just in case. Any updates on this?

On 28/08/15 11:23, "Marco Voelz" <marco.voelz(a)sap.com> wrote:

Hi Eric,

Just to confirm, did you leave it enabled in "mime digest" mode for longer than
a day so that there was list traffic to bundle and digest for you? I don't see any
errors in the error log related to MIME digest sends, but see about reproducing this today
and submit a bug.
Yes, I can confirm that I left mime digest on for several days and there were mails which I didn't receive. Note that regular digests aren't working for me, either. Currently the only working setting seems to be single mail delivery, which is not my preferred setting.

Did you manage to reproduce that?

The preference lookup appears to give precedence to the settings on the subscription, then
on the address, then on the user ("global"), and finally on the system
default—it stops at the first defined value it sees. I'll file a bug to have some
better clarification in the UI.
Great, thanks for the bug and the explanation!

Warm regards
Marco


Re: Stdout from Spring Boot app in CF

James Bayer
 

can you supply a simple sample example on github or similar that
demonstrates the issue? i haven't had issues with using spring boot logs on
CF before.

On Thu, Sep 10, 2015 at 5:56 AM, Qing Gong <qinggong(a)gmail.com> wrote:

I can get a simple Java app stdout (deployed using cf push JavaClass) to
go to firehose as logging messages. However, when I deployed a Spring Boot
app, I don't get the logging (to stdout) messages from the firehose. If I
just ran the Spring Boot app alone (using java -jar SpringBootApp.jar
instead of cf push SpringBootApp.jar), I could get the messages coming out
in the console or log file that I configured through log4j. System.out also
works fine in the console. So, why stdout doesn't work from a Spring Boot
app for firehose collection? How is it different from a plain Java app
which works fine for firehose?

Thanks!
--
Thank you,

James Bayer


Re: Java Buildpack v3.2

James Bayer
 

chris,

congrats on the release. this has lots of very nice improvements. i thought
Luna HSM was more about a hardware security module for establishing trust
instead of a way to add entropy to a system. does it also have capabilities
related to entropy?

On Thu, Sep 10, 2015 at 4:22 AM, Christopher Frost <cfrost(a)pivotal.io>
wrote:

I'm pleased to announce the release of the java-buildpack, version 3.2. This
release focuses on more options to configure JRE memory settings. It has
the following highlights:

- Memory calculator 2.0.0 which includes support for specifying
initial memory values and expected thread values.
- Support for Luna HSM service to provide entropy.
- Improved Dynatrace documentation. (via Josef Hoerandtner
<https://github.com/cloudfoundry/java-buildpack/pull/207>)
- Allow any additional New Relic configuration to be passed through to
the agent. (via Bryan Custer
<https://github.com/cloudfoundry/java-buildpack/issues/221>)
- Support for Spring Insight updated to version 2.0.0.

For a more detailed look at the changes in 3.2, please take a look at the commit
log <https://github.com/cloudfoundry/java-buildpack/compare/v3.1.1...v3.2>.
Packaged versions of the buildpack, suitable for use with create-buildpack
and update-buildpack, can be found attached to this release
<https://github.com/cloudfoundry/java-buildpack/releases/tag/v3.2>.
*Packaged Dependencies*

- AppDynamics Agent: 4.1.3_1
- GemFire 8.0.0
- GemFire Modules 8.0.0.1
- GemFire Modules Tomcat7 8.0.0.1
- GemFire Security 8.0.0
- Groovy: 2.4.4
- JRebel 6.2.3
- MariaDB JDBC: 1.2.0
- Memory Calculator (mountainlion): 2.0.0.RELEASE
- Memory Calculator (precise): 2.0.0.RELEASE
- Memory Calculator (trusty): 2.0.0.RELEASE
- New Relic Agent: 3.20.0
- OpenJDK JRE (mountainlion): 1.8.0_60
- OpenJDK JRE (precise): 1.8.0_60
- OpenJDK JRE (trusty): 1.8.0_60
- Play Framework JPA Plugin: 1.10.0.RELEASE
- PostgreSQL JDBC: 9.4.1202
- RedisStore: 1.2.0_RELEASE
- Spring Auto-reconfiguration: 1.10.0_RELEASE
- Spring Boot CLI: 1.2.5_RELEASE
- Tomcat Access Logging Support: 2.4.0_RELEASE
- Tomcat Lifecycle Support: 2.4.0_RELEASE
- Tomcat Logging Support: 2.4.0_RELEASE
- Tomcat: 8.0.26


Christopher Frost - Pivotal UK
Java Buildpack Team


--
Thank you,

James Bayer


Re: UAA user dynamic properties

Sree Tummidi
 

Hi,
We do have plans to support custom attributes and is a roadmap item. This is however not in the immediate future.

Thanks,
Sree

Sent from my iPhone

On Sep 10, 2015, at 4:13 AM, Viktor Khoroshko <oceansize(a)tut.by> wrote:

Hello everyone,

We're currently evaluating UAA to be used as Central Identity Provider in our system. And the issue for us is that It's not allowed to store additional user properties (you're limited by users columns that are currently supported).
Therefore, we have a question - are there any plans to add user dynamic properties support in future releases? Or, at least, do you agree that this would be an useful feature (so we may contribute)?

Thanks in advance


Stdout from Spring Boot app in CF

Qing Gong
 

I can get a simple Java app stdout (deployed using cf push JavaClass) to go to firehose as logging messages. However, when I deployed a Spring Boot app, I don't get the logging (to stdout) messages from the firehose. If I just ran the Spring Boot app alone (using java -jar SpringBootApp.jar instead of cf push SpringBootApp.jar), I could get the messages coming out in the console or log file that I configured through log4j. System.out also works fine in the console. So, why stdout doesn't work from a Spring Boot app for firehose collection? How is it different from a plain Java app which works fine for firehose?

Thanks!

7781 - 7800 of 9417