Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Add support for read-only JDBC URI

Open
#72 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Tech stack
java, spring-boot
Domain
backend, databases

Research direction

Start by tracing how CfService credentials are exposed through Spring Boot auto-configuration, then examine whether a JdbcUrlCreator entry point already exists. Define and document an extensibility mechanism for a secondary read-only JDBC URI, supporting either a supplied URL or generated values from read-* credentials, and add coverage for the chosen behavior.

Written by the indexing model from the issue text.

Description

First off, I really like the simplicity of this new CfEnv project for parsing Cloud Foundry VCAP_SERVICES and injecting properties into spring-boot for auto-configuration. I think it has a lot of potential!

I have been trying to figure out an easy way to support an additional parameter in the credentials property of a given CfService. My specific use case is to support a read-only URI that could be used as a secondary data source, similar to what is mentioned here: https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#howto-two-datasources.

In the best case, the jdbc-url for the secondary datasource would be provided in the service-broker/user-provided-service directly. In the worse case, the jdbc-url would have to be generated by a JdbcUrlCreator from a series of credentials.read-* properties (url/uri, host, port, username, password...) in the service-broker/user-provided-service.

Since spring-framework has no pre-defined properties for this specific use case, I'm not sure this is something that should be explicitly covered by this library. However, at the same time I feel that this library could be more accommodating to custom service-broker(s)/user-provided-service(s) credentials properties. As such, I think it's worth exploring how to support this use case through some sort of extensibility mechanism.

I am looking forward to the feedback on this and am willing to become a contributor to this project.

Dominant language
Java
Stars
97
Forks
64
Avg merge
6h 36m
Merged PRs (30d)
6

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from pivotal-cf/java-cfenv

All issues in pivotal-cf/java-cfenv

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.