Read global property file in custom plugins

[RJ Peterson]

Creating several custom plugins that share common properties such as db settings. Want to create a global property file that lives outside of the plugins that can be referenced by all plugins. Using InputStream, how do I determine the path for the file?

InputStream in = getClass().getClassLoader().getResourceAsStream(path);

Thanks

[Jobin Kuruvilla [Adaptavist]]

Reminded me of an older post where I had discussed this and another option :)

[Alied Perez]

Nice!!!

And nice to have it posted here, so others can find it.

However; and this is why these solutions (still) don't work in my case; I want the properties to be read by Spring and used to configure my beans. I also don't want to do Spring's job, and I don't like to do what I should have for free. If anybody knows a way to load .properties files by Spring I promess a few karme points.

[jacob delddd]

Sorry for disturbing you in this old post, but did you find a solution on using spring framework?

[thangvietle1289]

Hello,

You can find solution at here: https://stackoverflow.com/questions/50685819/configure-bitbucket-plugin-to-avoid-hardcoding-of-secure-variable/55293119#55293119

Thanks!

[David at David Simpson Apps]

Here you are:

// Get the Confluence home directory
String applicationHome = BootstrapUtils.getBootstrapManager().getApplicationHome();
File file = new File(applicationHome, "some-file.properties");
FileInputStream fileInputStream = new FileInputStream(file);

Properties p = new Properties();
p.load(fileInputStream);

// read individual key
p.getProperty("test.key")

It's @jobin's example code adapted for Confluence. I'm using a properties file in the Confluence home directoryrather than in for example WEB-INF/classes so that it doesn't get blasted away on upgrade.

[Steve Gerstner [bridgingIT]]

You cannot use it in a spring.xml.

The bundle has its own classpath! That means, WEB_INF/classes is NOT in your classpath in a version 2 plugin. That's the world of OSGi.

Put them in your plugin and you can load them via spring.

Or you can load them by code, but then, you need a basic class like String to get the classloader of the system bundle and then you can access your properties file.

[David at David Simpson Apps]

Update: Doesn't work so I've converted Jobin's comment to an answer :)

Using this in your plugin/add-on:

InputStream in = this.getClass().getClassLoader().getResourceAsStream("some-file.properties");

...will access a file located at WEB-INF/classes/some-file.properties

This is handy for admins who don't want the restrictions of a bundled properties file.

[Steve Gerstner [bridgingIT]]

You are in an OSGi plugin, so the defaultclassloader will be the one from your plugin.

Take a class from the SystemBundle like org.apache.commons.lang.StrungUtils

and get the classloader from StringUtils.

To get a thrid option to Jospehs answer, if you have more date, you can use ActiveObjects to store your data.

Furthermore, you can put all your properties in one file and work with prefixes. Then just set an environmentvariable to determine wich environment you are using and pick the correct values.

[Alied Perez]

Thanks, Steve,

but all that seems overkill for a couple Strings. I'd rather make the properties in the jar to be edited in place, or fill the .properties at build time.

I was hoping to use (the very outdated) Spring and a PropertyPlaceholderConfigurer to set my values in the bean definitions. That's it. If I had to add one line of code other than that; I would be exceeding the requirements.

Anyway, there are things you can do with Maven.

[Joe Clark]

How are you planning to install the properties file onto the Confluence server? You'll probably have to manually copy it onto the file system in $confluence_webapp/WEB-INF/classes. The path you need to pass in will be relative to this directory.

I'm not 100% sure if a plugin written using version 2 of the plugin framework will actually be able to read resources from the confluence web-inf directory. You should probably perform a simple proof-of-concept test before going down this path, to be sure.

Atlernatives to this approach include:

* Storing the configuration values in the Bandana table in the database

* Storing the properties file in just one of the plugins, and then expose a Spring bean from the plugin to the other plugins that provides the configuration values.

[Alied Perez]

Hi, I know it's been a long time.

Can I have a .properties file with environment-dependent data, like, jdbc url and driver, so I can edit it and point each environment? I just need a couple values to be quickly edited at environment setup: and perhaps once every other year or sonething.

if so, How can I configure it? I have tried several combinations but without luck.

[Alied Perez]

It seems there is no straightforward way. At least not just with Spring context alone.