Martini package directory structure
Martini packages are persisted on the file system. Each package, (except the
core package), is assigned a folder named after it under the
directory. This folder's structure is expected to look like the following:
1 2 3 4 5 6 7 8 9 10
package ├── code ├── conf │ └── package.xml │ └── properties │ └── package.properties │ └── <prefix>.package.properties ├── lib ├── solr ├── web
This directory is used to contain your services' source files, as well as their corresponding byte code files (if any1). Files and directories under this directory must use a valid Java name and identifier. Specifically, they must follow the JLS 6.2 naming guidelines.
Naming files and directories under
Meaningful names are a must when it comes to writing clean code. A meaningful name should describe the purpose of the unit of code in just one glance. Learn more about how to name and organize model and service files here.
This directory contains your package's configuration files.
Contains any extra
.jarfiles necessary for the package. Classes within these JAR files will be registered to your package's classloader and thus, they will be available for use in your code.
Contains the schema files for embedded Solr cores.
This is where optional Java web application resources reside. It can contain web pages which will be used by the embedded Tomcat server to host web applications. If this directory exists, Martini will add the package as a webapp to the underlying Tomcat web manager. This directory can be used to store a
WEB-INF/web.xmlfile as well.
Package configuration XML file
Every package requires a file named
package.xml in its
conf directory. This file
stores package metadata as well as the following information:
- The Martini endpoints that belong to the package
- The list of custom Solr cores which can be used in the package to index data
- The Spring context files that define the Spring beans that need to be instantiated and included in your package's application context
- The JMS destinations that will be added to the instance's list of broker destinations (if they don't already exist)
It's possible to directly modify the
package.xml file in your file system.
Whether the changes reflect immediately or not depends on application property
package.config.file.caching.strategy. There are three possible values for this property:
directory-watcher-cachewhich uses the directory watcher to monitor changes in the
last-modified-cachewhich checks for the last modified time of
package.xmland pushes updates accordingly. This configuration however produces uncessary overhead, therefore it's best to avoid this configuration for production instances.
simple-map-cachewhich does not check for file modifications on
package.xmlfiles. This means your instance will only pick up changes upon instance restart. This is recommended for production instances, as modifying
package.xmldirectly on the file system is not advisable.
Example XML document
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
<package stateOnStartup="started" documentation-page="https://docs.torocloud.com/martini/v1/quick-start/resources/examples-package/" id="io.toro.examples" version="1.0.0" context-path="/examples"> <package-dependencies/> <startup-services> <startup-service>gloop:io.toro.examples.Prepare/io.toro.examples.Prepare</startup-service> </startup-services> <shutdown-services> <shutdown-service>gloop:io.toro.examples.Cleanup/io.toro.examples.Cleanup</shutdown-service> </shutdown-services> <endpoints> <endpoint type="scheduler" name="AnnouncementScheduler" service="gloop:io.toro.examples.SendAnnouncement/io.toro.examples.SendAnnouncement" enabled="true" modifiable="true"> <properties> <property name="schedule">simpleRepeating:1</property> <property name="track">true</property> <property name="scheduleType">simpleRepeating</property> <property name="documentType">Scheduler</property> <property name="stateful">false</property> <property name="simpleRepeating">1</property> </properties> </endpoint> </endpoints> </package>
.groovy) and Java (
.java) files have
.classfile counterparts. ↩