SpringSource dm Server™ User Guide

The SpringSource dm Server requires Java SE 6 or later to be installed. Java is available from Sun and elsewhere.

To start SpringSource dm Server run the startup.sh (Linux) or startup.bat (Windows) script. For both platforms, the script is located in the SERVER_HOME/bin directory.

prompt$ cd $SERVER_HOME
prompt$ bin/startup.sh
	

[2009-03-30 12:12:12.111] Deployer Recovery <SPPM0002I> Server open for business with profile 'web'.

prompt> cd %SERVER_HOME%
prompt> bin\startup.bat
	

[2009-03-30 12:12:12.111] Deployer Recovery <SPPM0002I> Server open for business with profile 'web'.

When you start dm Server in clean mode, the startup script removes the SERVER_HOME/work directory (and hence all running applications) as well as all trace, log and dump files. It leaves the SERVER_HOME/repository and SERVER_HOME/pickup directories untouched, which means that any applications previously hot deployed will be automatically reinstalled.

prompt$ cd $SERVER_HOME
prompt$ bin/startup.sh -clean
	

prompt> cd %SERVER_HOME%
prompt> bin\startup.bat -clean
	

Use the -configDir option to specify an alternate config directory, different from the default SERVER_HOME/config directory. This option allows you to use the same SpringSource dm Server installation to run multiple instances of dm Server . Simply create a config directory for each instance, specify unique port numbers, logging and tracing directories, and so on. and then specify that directory when starting SpringSource dm Server.

If you specify a relative path for the -configDir parameter, the startup script interprets the path as relative to the root of the SpringSource dm Server installation, and not relative to the directory from which you execute the startup script.

prompt$ cd $SERVER_HOME
prompt$ bin/startup.sh -configDir /config/node1
			

prompt> cd %SERVER_HOME%
prompt> bin\startup.bat -configDir c:\config\node1
			

To use the SpringSource Admin Console, start the SpringSource dm Server and then enter the following URL in your browser of choice.

http://localhost:8080/admin

Replace localhost with the hostname of the computer on which the SpringSource dm Server is running if it is not the same as the computer on which you are running your browser. The Admin Console uses basic authentication, therefore you will need to enter the default administration ID and password.

ID: admin 
Password: springsource
		

To change the ID and password for the Admin Console, update the SERVER_HOME/config/servlet/tomcat-users.xml file, which is in the standard Tomcat users-file format. Change the values of the username and password attributes of the <user> element with the admin role. For example, if you want change the administration username to hamlet with password tobeornottobe change the file as follows:

<user username="hamlet" password="tobeornottobe" roles="admin">

The Admin Console runs against the admin role, therefore this cannot be changed.

The main Admin Console page displays several sections. The Deployed Applications section shows a list of all the deployed artifacts and the modules that comprise them. When you first install dm Server, there will be two artifacts deployed: the Admin Console itself and a splash screen application. As these artifacts both contain Web components, the Admin Console provides a link so you can quickly view them in your browser. The Admin Console provides a similar link for all deployed artifacts that contain Web components.

The other fields in the table give the ‘Name’ of the artifact, which is the name of the actual file if no specific name is supplied. The ‘Origin’ describes how the artifact was deployed. The possible values are Hot Deployed if the artifact was dropped in the pickup directory, Admin Console if deployed using the console and Programmatic if deployed programmatically, that is, through the integrated artifact deployer in the SpringSource dm Server Tools. The version is 0 if no specific version is supplied by the artifact. The ‘Date’ column shows when the artifact was last deployed to dm Server.

In the Deploy an Application section, you can upload a file that will be deployed automatically to the SpringSource dm Server. Once the artifact is deployed it will appear in the Deployed Applications table. You can use the Browse button to browse your local computer for the file. Note that the specific GUI for uploading varies according to your browser and platform.

When clicked, the ‘Upload’ button reloads the page. This may take a few seconds while the file is uploaded and deployed. If any problems occurred, the Admin Console outputs a status message at the top of the page. If the file deployed with no problems, the messages says Application deployed.

For more information on how to work with artifacts see Chapter 6, Working with Applications.

At the bottom of the main page, the Information section provides details of the dm Server you have accessed. This is useful for verifying that you have accessed the correct dm Server instance. The Server Properties table lists basic properties of the dm Server instance, such as the version of the embedded Tomcat server and the operation system on which the dm Server instance is running.

This section describes the provisioning repository feature of SpringSource dm Server, the reasons for using it, and how to configure it.

In most use cases, your application includes dependencies on third-party libraries, such as Spring Framework and Hibernate. You typically express the dependencies between your application and third-party libraries using the Import-Package or Import-Library manifest header in the MANIFEST.MF file of your application.

The Import-Package header is standard to OSGi; however, Import-Library is specific to SpringSource dm Server. Some third-party dependencies consist of multiple bundles but are logically one unit. To support this, the SpringSource dm Server introduces the concept of a library. A library is a collection of related bundles that can be referenced as a whole. For additional details about the creation and usage of libraries, as well as general information about dependencies, see Programmer’s Guide.

In SpringSource dm Server, you store all third-party dependencies needed by your applications, such as Spring Framework and Hibernate, as valid OSGi bundles in the provisioning repository. SpringSource dm Server supports only dependencies that are valid OSGi bundles.

When you deploy your application, SpringSource dm Server installs the bundle in which it is packaged to the dm Server runtime; part of this internal installation procedure is to satisfy all the application’s dependencies. If your application has a dependency that cannot be satisfied from the bundles that you have already deployed (and dm Server has thus installed), the dm Server searches the provisioning repository for a bundle that can satisfy that dependency.

The provisioning repository for a particular instance of SpringSource dm Server can include bundles in the following general locations:

You configure the provisioning repository using the SERVER_HOME/config/repository.properties file.

As previously implied, a particular instance of SpringSource dm Server can itself also act as a repository host for remote server instances to use when satisfying the dependencies of the applications deployed to it. In this case, you configure a hosted repository using the SERVER_HOME/config/hostedRepository.properties file. Typically, only remote clients use hosted repositories and their contents; the SpringSource dm Server instance that actually hosts the repository does not typically use the bundles in it. Rather, it uses bundles in its local repository.

Making a third-party dependency available to your application is simply a matter of adding its bundle or library to the appropriate location in the provisioning repository. This could be either in the local directories or the remote ones if you are getting bundles from a remotely-hosted repository.

When you first install SpringSource dm Server, the local provisioning repository is located at $SERVER_HOME/repository by default and consists of three main directories: bundles, libraries and installed.

The bundles directory contains all the bundles available in the repository. The libraries directory contains all the library definitions. Note that libraries reference bundles that are installed elsewhere in the repository; by default, these bundles are installed under the bundles directory, but you can customize this behavior. The installed directory is used by the SpringSource dm Server at runtime; you should never install bundles or libraries used by your applications into the installed directory.

The bundles directory is further subdivided into three directories: ext, usr and subsystems. You install third-party bundles into the ext and usr directories; typically, the ext directory contains bundles supplied with the SpringSource dm Server and usr contains bundles installed by the end user. The subsystems directory is for internal use only; do not install any bundles in this directory.

The libraries directory is similarly organized, with an ext and usr directory. As with bundles, you install your own new libraries into libraries/usr.

The following graphic shows the default SpringSource dm Server provisioning repository directory structure right after installation.

To install a bundle into the default bundle repository, simply copy it into the $SERVER_HOME/repository/bundles/usr directory. Similarly, to install a library, copy its definition into the $SERVER_HOME/repository/libraries/usr directory.

If you have configured additional watched or external repositories (additional, that is, to the default ones already configured in a freshly-installed dm Server instance), you install bundles and libraries in the same way: simply copy the files to the configured directories. You configure additional watched or external repositories in the same file as the default repositories: repository.properties.

When you install a library, you must ensure that all referenced bundles within the library have been installed as well.

Bundles must have unique names so it is considered best practice to include the version number in the file name, allowing for multiple versions of the bundle to be installed at the same time. For example, a bundle file name might be my-exciting-bundle.2.1.0.jar.

In some cases the SpringSource dm Server manages to automatically detect changes in its provisioning repository at runtime, thereby avoiding the need to restart the dm Server.

Of specific relevance during development is picking up changes to an application’s direct dependencies during deployment of the application. For example, if you deploy an application and receive a message that a dependency is missing, you can simply add the dependency to the repository and then redeploy the application. The redeploy will cause the new dependency to be picked up, allowing progress to be made without restarting the dm Server. For other changes such as addition of indirect dependencies, the SpringSource dm Server must be restarted to pick up any changes to the provisioning repository.

The SpringSource Enterprise Bundle Repository is a public collection of open source libraries commonly used for developing enterprise Java applications with the Spring Framework and dm Server. It contains more than 400 of the most popular enterprise Java libraries made available for general use in an OSGi-ready format. You can browse the collection and then download the bundles that you need into your own local repository.

The SpringSource Enterprise Bundle Repository is located here.

You can find bundles in the repository using a number of options. You use the ‘Search’ facility by typing in a keyword. The matching criteria returned can be explored by name, symbolic name, class, package or resource.

There is also the option of clicking on ‘Browse by Bundle’. This gives an alphabetical list of bundles. You can select the desired bundle to see details and find the download link. Finally, you can also choose to ‘Browse by Library’, which allows you to browse the alphabetical list of libraries in the repository.

Details of how to configure a SpringSource dm Server installation’s provisioning repository can be found in Configuring the Provisioning Repository. See Configuring a Hosted Repository for details on how to configure a repository that remote clients can access, also called a hosted repository.

The two configuration chapters describe the format of the repository properties files of SpringSource dm Server, how to add new directories to the local repository, how to configure the repository to get bundles from a remote repository hosted on a remote dm Server, instance, and how to configure the local dm Server instance to itself host a repository that other remote servers access.

Event log files are low-volume logs of important events in SpringSource dm Server. Each server message written to an event log file is accompanied by a code enclosed in angle brackets. An example is shown below:

[2009-08-25 15:04:57.044] server-dm-7                  <OF0001I> OSGi telnet console available on port 2401.

(For a description of the log code syntax, see Appendix A, Event log codes.) The format of event log messages from the server is fully configurable.

By default, event log messages are stored in $SERVER_HOME/serviceability/eventlogs/eventlog_i.log and output to the console. The index i varies from 1 to 4, at 10Mb boundaries. An examination of the Logback configuration will show these defaults being set. They may be modified.

For a description of the syntax and facilities provided by this file see the Logback documentation (referenced in Appendix C, Further Reading ).

The SpringSource dm Server’s logging (trace) support serves two main purposes:

By default, the dm Server trace file is called $SERVER_HOME/serviceability/logs/dm-server/log_i.log, and, again by default, the application trace files are called $SERVER_HOME/serviceability/logs/application_name/log_i.log, where application_name is automatically set by dm Server for each application artifact installed and run (it is a combination of the artifact name and the version).

The index i varies from 1 to 4, on a rolling basis, as each log file exceeds 10Mb.

Entries in trace files are by default of the form <timestamp> <thread-name> <source> <level> <entry-text>. For example:

[2008-05-15 09:09:46.940] server-dm-2 org.apache.coyote.http11.Http11Protocol I Initializing Coyote HTTP/1.1 on http-48080
	    

although this format is completely determined by the Logback configuration file serviceability.xml.

[2008-05-16 09:28:45.874] server-tomcat-thread-1 System.out I Hello world!
[2008-05-16 09:28:45.874] server-tomcat-thread-1 System.err E Hello world!
			

A service dump is triggered when one of the following events occurs:

A service dump contains a snapshot of all the important state from the running SpringSource dm Server instance. This snapshot is not intended for end user consumption but is useful for service personnel.

By default, service dumps are created in $SERVER_HOME/serviceability/dump.

You can deploy artifacts to SpringSource dm Server using either the hot-deploy directory on the file system or by using the Admin Console.

prompt$ cp myapp.par $SERVER_HOME/pickup

[2009-03-08 17:00:00.000] fs-watcher   <SPDE0010I> - Deployment of 'myapp.par' version '0' completed.

You can undeploy artifacts from SpringSource dm Server using either the hot-deploy directory on the file system, or by using the Admin Console.

prompt$ cd $SERVER_HOME/pickup
prompt$ rm myapp.par

[2009-03-08 17:00:05.000] fs-watcher     <SPDE0012I> - Undeployment of 'myapp.war' version '0' completed.

SpringSource dm Server uses properties files in the SERVER_HOME/config directory to configure most of its subsystems. Each subsystem has its own properties file, as described in the following table.

There are two subsystems that do not use properties files:

This section provides information about configuring the dm Server kernel by updating the file SERVER_HOME/config/kernel.properties. Topics include:

deployer.timeout=300
deployer.pickupDirectory=pickup

io.workDirectory=work

shell.enabled=true
shell.port=2401

The serviceability subsystem of the SpringSource dm Server is configured in the serviceability.xml file found in the config directory. This is a Logback configuration file, and is explained in some more detail in Chapter 5, Serviceability.

SpringSource dm Server embeds an OSGi-enhanced version of the Tomcat Servlet Container in order to provide support for deploying Java EE WARs and Web Bundles. You configure the embedded Servlet container using the standard Apache Tomcat configuration. The main difference is that the configuration file is called tomcat-server.xml rather than server.xml. As with the other dm Server configuration files, the tomcat-server.xml file is located in the $SERVER_HOME/config directory.

The following listing displays the default configuration distributed with the dm Server; for clarity, the listing does not include the standard Apache License.

<?xml version='1.0' encoding='utf-8'?>

<Server port="8005" shutdown="SHUTDOWN">

  <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
  <Listener className="org.apache.catalina.core.JasperListener" />
  <Listener className="org.apache.catalina.mbeans.ServerLifecycleListener" />
  <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />

  <Listener className="com.springsource.server.web.tomcat.ServerLifecycleLoggingListener"/>

  <GlobalNamingResources>
    <Resource name="UserDatabase" auth="Container"
              type="org.apache.catalina.UserDatabase"
              description="User database that can be updated and saved"
              factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
              pathname="config/tomcat-users.xml" />
  </GlobalNamingResources>

  <Service name="Catalina">

    <Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" />

    <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
               maxThreads="150" scheme="https" secure="true"
               clientAuth="false" sslProtocol="TLS"
               keystoreFile="config/management/keystore"
               keystorePass="changeit"/>


    <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />

    <Engine name="Catalina" defaultHost="localhost">

      <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
             resourceName="UserDatabase"/>

      <Host name="localhost"  appBase="webapps"
            unpackWARs="true" autoDeploy="true"
            xmlValidation="false" xmlNamespaceAware="false">

         <Valve className="org.apache.catalina.valves.AccessLogValve" 
               directory="serviceability/logs/access"
               prefix="localhost_access_log." suffix=".txt" pattern="common" 
               resolveHosts="false"/>
      </Host>
    </Engine>
  </Service>
</Server>

Description of the Default Apache Tomcat Configuration

The following bullets describe the main elements and attributes in the default tomcat-server.xml file; for details about updating this file to further configure the embedded Apache Tomcat server, see the Apache Tomcat Configuration Reference.

	Relative paths
	If the configured path to a directory or file does not represent an absolute path, dm Server typically interprets it as a path relative to the SERVER_HOME directory.

• The root element of the tomcat-server.xml file is <Server>. The attributes of this element represent the characteristics of the entire embedded Tomcat servlet container. The shutdown attribute specifies the command string that the shutdown port number receives via a TCP/IP connection in order to shut down the servlet container. The port attribute specifies the TCP/IP port number that listens for a shutdown message.

• The <Listener> XML elements specify the list of lifecycle listeners that monitor and manage the embedded Tomcat servlet container. Each listener class is a Java Management Extensions (JMX) MBean that listens to a specific component of the servlet container and has been programmed to do something at certain lifecycle events of the component, such as before starting up, after stopping, and so on.

  The first four <Listener> elements configure standard Tomcat lifecycle listeners. The listener implemented by the com.springsource.server.web.tomcat.ServerLifecycleLoggingListener class is specific to SpringSource dm Server and manages server lifecycle logging.

• The <GlobalNamingResources> XML element groups together the global JNDI resources that Web applications deployed to the servlet container can use. The <Resource> element defines the database used to load the users and roles from the SERVER_HOME/config/tomcat-users.xml file into an in-memory data structure. This resource will be later referenced by the <Engine> XML element so that Web applications deployed to the servlet container can query the database for the list of users and the roles they are mapped to, as well as update the file.

• The <Service> XML element groups together one or more connectors and a single engine. Connectors define a transport mechanism, such as HTTP, that clients use to to send and receive messages to and from the associated service. There are many transports that a client can use, which is why a <Service> element can have many <Connector> elements. The engine then defines how these requests and responses that the connector receives and sends are in turn handled by the servlet container; you can defined only a single <Engine> element for any given <Service> element.

  The sample tomcat-server.xml file above includes three <Connector> elements: one for the HTTP transport, one for the HTTPS transport, and one for the AJP transport. The file also includes a single <Engine> element, as required.

• The first connector listens for HTTP requests at the 8080 TCP/IP port. The connector, after accepting a connection from a client, waits for a maximum of 20000 milliseconds for a request URI; if it does not receive one from the client by then, the connector times out. If this connector receives a request from the client that requires the SSL transport, the servlet container automatically redirects the request to port 8443.

• The second connector is for HTTPS requests. The TCP/IP port that users specify as the secure connection port is 8443. Be sure that you set the value of the redirectPort attribute of your non-SSL connectors to this value to ensure that users that require a secure connection are redirected to the secure port, even if they initially start at the non-secure port. The SSLEnabled attribute specifies that SSL is enabled for this connector. The secure attribute ensures that a call to request.isSecure() from the connecting client always returns true. The scheme attribute ensures that a call to request.getScheme() from the connecting client always returns https when clients use this connector.

  The maxThreads attribute specifies that the servlet container creates a maximum of 150 request processing threads, which determines the maximum number of simultaneous requests that can be handled. The clientAuth attribute specifies that the servlet container does not require a certificate chain unless the client requests a resource protected by a security constraint that uses CLIENT-CERT authentication.

  The keystoreFile attribute specifies the name of the file that contains the servlet container’s private key and public certificate used in the SSL handshake, encryption, and decryption. You use an alias and password to access this information. In the example, this file is SERVER_HOME/config/management/keystore. The keystorePass attributes specify the password used to access the keystore.

• The third AJP Connector element represents a Connector component that communicates with a web connector via the AJP protocol.

• The engine has a logical name of Catalina; this is the name used in all log and error messages so you can easily identify problems. The value of the defaultHost attribute refers to the name of a <Host> child element of <Engine>; this host processes requests directed to host names on this servlet container.

• The <Realm> child element of <Engine> represents a database of users, passwords, and mapped roles used for authentication in this service. By default, the realm simply references the UserDatabase resource, defined by the <Resource> child element of <GlobalNamingResources>.

• The <Host> child element represents a virtual host, which is an association of a network name for a server (such as www.mycompany.com) with the particular server on which Catalina is running. The servlet container unpacks Web applications into a directory hierarchy if they are deployed as WAR files. The xmlValidation attribute specifies that the servlet container does not validate XML files when parsing them, or in other words, it accepts invalid XML. The xmlNamespaceAware attribute specifies that the servlet container does not take namespaces into account when reading XML files.

• Finally, the org.apache.catalina.valves.AccessLogValve valve creates log files in the same format as those created by standard web servers. The servlet container creates the log files in the SERVER_HOME/serviceability/logs/access directory. The log files are prefixed with the string localhost_access_log., have a suffix of .txt, use a standard format for identifying what should be logged, and do not include DNS lookups of the IP address of the remote host.

Connector Configuration

The SpringSource dm Server supports JSON-based configuration of any connector supported by Apache Tomcat. See the default configuration above for syntax examples, and for further details on the configuration properties supported for various <Connector> implementations, consult the official Tomcat HTTP Connector documentation.

	Configuring SSL for Tomcat
	The SpringSource dm Server distribution includes a preconfigured SERVER_HOME/config/management/keystore file that contains a single self-signed SSL Certificate. The password for this keystore file is changeit. This keystore file is intended for testing purposes only. For detailed instructions on how to configure Tomcat’s SSL support, consult the official Tomcat SSL Configuration HOW-TO.

You configure the locations that SpringSource dm Server includes in its provisioning repository by editing the repository.properties file in the $SERVER_HOME/config directory.

When you specify a property in the file, use the format repository-name.property=value, where:

For example, bundles-usr.type=external specifies that the type property of the repository with name bundles-usr is external.

For each specific repository, you configure a number of properties, such as its type (external, watched, or remote) and its searchpath, watched directory, or URI that specifies the actual location of the bundles and libraries. The particular properties that configure these options are listed in the table after the example.

The chain property specifies the order in which SpringSource dm Server searches the searchpaths when it looks for dependencies; the first path listed specifies the first actual directory that SpringSource dm Server searches, until the last listed path. The chain property uses the names of the searchpaths as specified in the individual repository properties; for example, in the property bundles-usr.type=external, the name of the repository is bundles-usr.

The default repository configuration for a newly installed SpringSource dm Server is as follows:

bundles-subsystems.type=external
bundles-subsystems.searchPattern=repository/bundles/subsystems/{subsystem}/{component}

bundles-ext.type=external
bundles-ext.searchPattern=repository/bundles/ext/{bundle}

bundles-usr.type=external
bundles-usr.searchPattern=repository/bundles/usr/{bundle}

libraries-ext.type=external
libraries-ext.searchPattern=repository/libraries/ext/{library}

libraries-usr.type=external
libraries-usr.searchPattern=repository/libraries/usr/{library}

chain=bundles-subsystems,bundles-ext,bundles-usr,libraries-ext,libraries-usr

The default configuration shown above has five searchpaths, each of which SpringSource dm Server searches when locating entries for inclusion in the repository. The chain property shows the order in which SpringSource dm Server searches the searchpaths.

SpringSource dm Server requires that you always include the bundles-subsystem, bundles-ext, and libraries-ext searchpaths, as shown above, in your repository configuration. You can configure the user-related searchpaths as you wish.

The following table lists all the available properties that you can use to describe a named path and the repository search chain in the repository.properties file.

bundles-subsystems.type=external
bundles-subsystems.searchPattern=repository/bundles/subsystems/{subsystem}/{component}

bundles-ext.type=external
bundles-ext.searchPattern=repository/bundles/ext/{bundle}

bundles-usr.type=external
bundles-usr.searchPattern=${user.home}/.ivy2/cache/{org}/{name}/{version}/{bundle}.jar

libraries-ext.type=external
libraries-ext.searchPattern=repository/libraries/ext/{library}

libraries-usr.type=external
libraries-usr.searchPattern=repository/libraries/usr/{library}

chain=bundles-subsystems,bundles-ext,bundles-usr,libraries-ext,libraries-usr

bundles-subsystems.type=external
bundles-subsystems.searchPattern=repository/bundles/subsystems/{subsystem}/{component}

bundles-ext.type=external
bundles-ext.searchPattern=repository/bundles/ext/{bundle}

bundles-usr.type=external
bundles-usr.searchPattern=${user.home}/.m2/repository/**/{bundle}.jar

libraries-ext.type=external
libraries-ext.searchPattern=repository/libraries/ext/{library}

libraries-usr.type=external
libraries-usr.searchPattern=repository/libraries/usr/{library}

chain=bundles-subsystems,bundles-ext,bundles-usr,libraries-ext,libraries-usr

bundles-subsystems.type=external
bundles-subsystems.searchPattern=repository/bundles/subsystems/{subsystem}/{component}

bundles-ext.type=external
bundles-ext.searchPattern=repository/bundles/ext/{bundle}

bundles-usr.type=external
bundles-usr.searchPattern=repository/bundles/usr/{bundle}

libraries-ext.type=external
libraries-ext.searchPattern=repository/libraries/ext/{library}

libraries-usr.type=external
libraries-usr.searchPattern=repository/libraries/usr/{library}

remote-repo.type=remote
remote-repo.uri=http://my-host:8080/com.springsource.server.repository/my-hosted-repo
remote-repo.indexRefreshInterval=30

watched-repo.type=watched
watched-repo.watchedDirectory=repository/watched
watched-repo.watchedInterval=5

chain=bundles-subsystems,bundles-ext,bundles-usr,libraries-ext,libraries-usr,remote-repo,watched-repo

You configure a dm Server instance to host a repository by editing the config/hostedRepository.properties file; remote clients can then access the artifacts in this hosted repository and use them locally.

When you specify a property in the file, use the format repository-name.property=value, where:

For example, my-hosted-repo.type=external specifies that the type property of the my-hosted-repository repository is external.

The following table lists the properties that you can include in the hostedRepository.properties file.

The following sample shows a hostedRepository.properties file with a single external repository called my-hosted-repo with search pattern SERVER_HOME/repository/hosted/*.

my-hosted-repo.type=external
my-hosted-repo.searchPattern=repository/hosted/*

See Example of watched and remote repositories for details on how a local repository can remotely access the artifacts in this hosted repository.