Date   

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!


Re: Add app monitoring agent framework in custom buildpack

Christopher Frost
 

Hi,

The Java Buildpack is under the Apache License so you can reuse the code as
you like but obviously you will need to rewrite it from Ruby to Java if
your buildpack is written in Java. The steps you will need to go through to
get New Relic or Wily working will be very similar regardless of the
language the buildpack is written in.


Christopher Frost - Pivotal UK
Java Buildpack Team

On Thu, Sep 10, 2015 at 9:07 AM, Swatz bosh <swatzron(a)gmail.com> wrote:

Hello,

I have a custom buildpack of my software and and I want to use NewRelic/CA
Wily agent frameworks which is added in java-buildpack [1].
So may I know what all components of these agents I can reuse from
java-buildpack? I found that these agents are written in Ruby, so can I
reuse them in my buildpack which is on java?

[1]
https://github.com/cloudfoundry/java-buildpack/blob/master/lib/java_buildpack/framework/new_relic_agent.rb


Thanks


Java Buildpack v3.2

Christopher Frost
 

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


UAA user dynamic properties

Viktor Khoroshko
 

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


Add app monitoring agent framework in custom buildpack

Swatz bosh
 

Hello,

I have a custom buildpack of my software and and I want to use NewRelic/CA Wily agent frameworks which is added in java-buildpack [1].
So may I know what all components of these agents I can reuse from java-buildpack? I found that these agents are written in Ruby, so can I reuse them in my buildpack which is on java?

[1] https://github.com/cloudfoundry/java-buildpack/blob/master/lib/java_buildpack/framework/new_relic_agent.rb


Thanks


script cleanup in cf-release

Amit Kumar Gupta
 

Hi cf-dev,

This is a final reminder that we will be cleaning up the various scripts
that had sprawled across cf-release, deleting unused ones and moving the
rest to the scripts directory.

Moves:
* bosh-lite/make_manifest -> scripts/generate-bosh-lite-dev-manifest
* generate_deployment_manifest -> scripts/generate_deployment_manifest
* update -> scripts/update
* update.bat -> scripts\update.bat

Deletions:
* scripts/travis/install_spiff
* check_travis.rb
* outdated
* outdated_stats
* the entire "shared" submodule

Please update your workflows, dev tooling, and CI scripts to reflect the
upcoming changes.

Best,
Amit