Package properties
Sometimes you may find it useful to store certain values for later use in your services. One way to achieve this is through the use of package properties.
Martini has two types of properties, those that are global to the instance, or local to a certain package. You'll want to use package properties if you want values to be persisted and used within a package only. A common use case would be for storing API access keys; you'd typically use the same set of credentials when invoking third-party services under the same API.
Packages declare their properties under conf/properties
:
1 2 3 4 5 |
|
The naming convention may be changed by configuring the
package.properties.prefix
application property.
So a package prefix of develop
dictates the application to look for develop.package.properties
instead of package.properties
. This is useful for storing package properties for multiple environments or
developers in the same place - all you need to do is configure your various installations
with their own package.properties.prefix
.
Like instance properties, changes to your package properties will be visible as soon as you save the properties file
(assuming the package.properties.reload-strategy
application property is set to always-check
).
Might have to manually create the files
Your .properties
files are not automatically generated when you create a package or when you re-specify the value
of package.properties.prefix
. If your .properties
files are missing,
simply create them under the conf/properties
folder.
Property merging
Properties are merged according to package hierarchy. Consider the following example:
- Package
petclinic-demo
depends onpetclinic
. -
Package
petclinic
declares the following property:1
petclinic.petstore-url=https://petstore.swagger.io
When accessing the property petclinic.petstore-url
from the petclinic-demo
package, the value
https://petstore.swagger.io
is resolved. This is possible because it depends on the petclinic
package. If the dependency is removed, the property resolves to null
.
The child package may declare a property of the same name, essentially overriding the parent
property. For instance, if the petclinic-demo
declares the following property:
1 |
|
The resolved value for petclinic.petstore-url
when accessing it from the petclinic-demo
package
is http://localhost:5000
.
Application properties inheritance
Aside from explicit package dependencies, packages also inherit properties from the system-wide application properties. If a property is not available in the package hierarchy, the system application properties is ultimately queried for a value.
Modifying package properties via Martini
To add new properties via user interface, follow the steps below:
- Go to the Navigator view.
- Look for your package and expand its contents by clicking on its node. Look for the
conf
directory, - Double click the
.properties
file to open it. -
Add, edit, and remove key-value pairs as needed.
Quick search for files
In Martini Desktop, you can do to search for your .properties
file(s) instead using the
Open Resource dialog. With this, you can open all of your .properties
files all at once.
Modifying and using package properties programmatically
The instance-wide classloader ships with a Groovy extension module packed with utility methods. This means that you can use the functions defined in that extension module in all of your Groovy or Gloop code.
When working with package properties, most, if not all, of the methods you'll be needing are present in the
Groovy
class.
You can add or modify package properties in Groovy code using some of the methods provided by the extension module mentioned. For example:
1 |
|
Array values
If you want to save an array of values, simply create a string of all the values separated by commas. Martini has utility methods that'll parse and split those values for you and return them in an array.
To remove a package property, do:
1 |
|
To fetch the value of a package property, you can do any of the following:
1 2 3 4 |
|
The methods for managing package properties are context-aware. If you call any of the methods above in a certain script
and that script is contained in a package called foo
, then only foo
's package properties will be fetched, added,
modified, or removed.
The function will follow the rules below on retrieving the property from your properties file:
- From the
package.properties
file - Iteratively from each parent package, until found
- From your application properties
Gloop and Flux is fully supported too
Most of the functions in the GroovyMethods
class also appear in the Navigator, and can be used in Gloop
and Flux services.
When updating properties, only the local package properties file is updated.