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
1 2 3 4 5
├── conf │ ├── properties │ │ └── package.properties │ |... |...
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
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
Like instance properties, changes to your package properties will be visible as soon as you save the properties file
package.properties.reload-strategy application property is set to
Might have to manually create the files
.properties files are not automatically generated when you create a package or when you re-specify the value
package.properties.prefix. If your
.properties files are missing,
simply create them under the
Properties are merged according to package hierarchy. Consider the following example:
petclinicdeclares the following property:
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
package. If the dependency is removed, the property resolves to
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:
The resolved value for
petclinic.petstore-url when accessing it from the
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
- Double click the
.propertiesfile 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
You can add or modify package properties in Groovy code using some of the methods provided by the extension module mentioned. For example:
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:
To fetch the value of a package property, you can do any of the following:
1 2 3 4
'key'.getPackageProperty() 'key'.getPackageProperty('default-value') 'key'.getPackagePropertyArray() 'key'.getPackagePropertyArray(['default-value-one', 'default-value-two'])
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 one-liner will follow the rules below on retrieving the property from your properties file:
- From the
- Iteratively from each parent package, until found
- From your application properties
Gloop and Flux is fully supported too
Most of the one-liner methods 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.