On Wed, Sep 30, 2015 at 5:04 PM, Naga Rakesh <nagarakesh4(a)gmail.com> wrote:
It was a user-provided service instance.
Yes, thanks, I was able to figure out that i didn't do a manual URL
encoding and this seems to be working, Thanks,
I have a question now, does this mean the service instance gets connected
to a database based only on the URI? Can we change this approach in our
How you interpret service data is entirely up to your application. CF just
provides that information for you via VCAP_SERVICES.
If you use a library to help read service information, which is common for
Java apps, then you'd want to look at how that particular library reads
VCAP_SERVICES. Spring Cloud Connectors does look at the URL, but I don't
believe that's the whole story. I can't recall of the top of my head
though. If you're using that library and curious, you might want to look
closer at the code and see exactly what it's doing.
On Wed, Sep 30, 2015 at 5:34 AM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:
On Tue, Sep 29, 2015 at 11:15 PM, Naga Rakesh <nagarakesh4(a)gmail.com>
Hello,How did you create this service instance? Is it from a service broker?
I am facing an issue while bounding app to a service instance. The
service instance points to a database which has a '@' (at symbol) in its
password (example : abc(a)def). When I bind this service instance to an
existing app, the app throws up the following error when trying to access
or is it a user provided service?
That's because the URL is not valid. Your "@" in the password should be
*OUT java.net.UnknownHostException: null: unknown error*
*at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method).*
The sample URI in the env formed was "mysql://username:abc(a)def@
18.104.22.168:3306/dbname", as you can see the password was having a '@'
character in it. I believe how it works is it parses the URI as
*drivername://username:password(a)hostname:port/dbname* and in this case
as the password contains @ it is unable to parse the hostname correctly.
url encoded (the username and password sections should both be urlencoded,
the "@" is just the only character that would change from being
If you're passing this URL through a user provided service then you need
to manually urlencode it. If you're using a service broker, then that
sounds like a bug with the broker.