In hybris 6.6, almost all project-specific files are located in a special folder called the “data folder.” The structure of this folder is not well documented. The folders and files have “random” names. Basically, this is not very important until you find that this folder is too large. Understanding its structure and the purpose of its components will help you troubleshoot and optimize the system.
The official hybris documentation explains some technical aspects, but rather briefly. In this article, I’m trying to look deeper.
Location
The Hybris Data Dir is specified in env.properties:
HYBRIS_BIN_DIR=${platformhome}/../../bin
HYBRIS_CONFIG_DIR=${platformhome}/../../config
HYBRIS_DATA_DIR=${platformhome}/../../data
HYBRIS_LOG_DIR=${platformhome}/../../log
HYBRIS_TEMP_DIR=${platformhome}/../../temp/hybrisStructure
The data folder contains runtime data:
- Accelerator Services Batch Impex Base Folder for import and export. By default, it is DATADIR/acceleratorservices/import and DATADIR/acceleratorservices/export. Configurable via
acceleratorservices/project.properties. - Tomcat runtime files (
wrapper.conf), such as:- status file (hybristomcat.java.status),
- process ID files (hybristomcat.java.idfile and hybristomcat.java.pidfiles),
- lock file (hybristomcat.lock).
- HSQLDB data files (
/hsqldb; configurable; platform/project.properties) - SOLR data files (
solr/; configurable;solrserver/buildcallbacks.xml) - Swagger Maven plugin output directory docs (
/doc; bywebservicecommons) - Media replication directory (
/media; configurable;media.replication.dirsinadvanced.properties). Deprecated. - Media read directory (
/media; configurable;media.read.dirinadvanced.properties)sys_master/– for the default tenant “master”- All files here are referenced files; for example, there is an object (item) referencing the file.
sys_junit/– for the default tenant “junit”
- Lucene Index (
/luceneindex; configurable;lucenesearch.indexdirinadvanced.properties)
How to access the data folder from the code
MediaUtil.getLocalStorageDataDir()– data directory, for example:/data/;MediaUtil.getMediaReadDir()– media subdirectory, for example:/data/media/sys_master/;MediaUtil.getSystemDir();MediaUtil.getTenantMediaReadDir()– with a tenant subdirectory, for example:/data/media/sys_master/.
Media
Storage strategy
The storage strategy defines how hybris sources and organizes media files, such as images or documents. The relevant configuration parameter is <PREFIX>.storage.strategy.
There are four out-of-the-box storage strategies:
LocalFileMediaStorageFactoryGridFSMediaStorageFactoryS3MediaStorageFactoryWindowsAzureMediaStorageFactory
In this document, I am focusing on LocalFileMediaStorageFactory. In this strategy, all data is stored locally in local file system storage defined by the media.read.dir and media.replication.dirs configuration properties.
See the section “Configuration Parameters Prefix” below to learn more about what <PREFIX> is.
Local cache
The local cache is a way of speeding up the delivery of media files by caching them in memory. Caching is implemented via the region cache framework. By default, the configuration parameter <PREFIX>.local.cache specifies whether data from non-local strategies is cached or not.
There is a parameter, <PREFIX>.local.cache.rootCacheFolder. It specifies a root cache folder for all cached files. <PREFIX>.local.cache.maxSize is used to specify the maximum size of the media cache, in megabytes.
See the section “Configuration Parameters Prefix” below to learn more about what <PREFIX> is.
Local File Hierarchy
The file name of the media file consists of two parts:
- Base file name part. This name is actually a 13-digit
dataPKof the media object. - File extension part. The extension is one of the configured extensions, or
binfor others. These predefined “allowed” extensions are listed inadvanced.properties; see the configuration variables starting withmedia.customextension. Associating the MIME type is important if you download this file. For example, you may want to download HTML files rather than open them in the browser window.
So you can list all PKs of all stored media by listing all files in the media folder and compare them with the PKs stored in the database to see if there are any differences.
A typical file name looks like 9593242157086.xml.
The file path consists of two parts:
- Media folder (such as
hmcorimages) - Hash hierarchy of the specified depth (such as
h04/ha3/). Each component is one of the 256 values (h00..hff). The folders are created only if there is at least one file in them.
Typical file paths:
hmc/h04/ha3/images/h1a/h12/
The full path will look like this:

Media folders
A media folder is one of the parameters for the media when it is created. However, there are a number of predefined folders:
roothmc– for HMC configuration (XML files)images– for product images (ProductImageMediaService)impex– for ImpEx-specific media files, such asImpExMediaitemsjasperreports– for JasperReportscatalogsync– forCatalogVersionSyncScheduleMediacronjob– for cronjob logsdocumentsemail-bodyemail-attachmentsaccount-summarycouponcodes- etc.
Hashing depth
The hashing depth is the number of levels in the hierarchy (see the “hash part” above) used to limit the number of files per directory. By default, the configuration parameter hashing.depth is 2. You can change it in the configuration.
For building a hash value, hybris uses “salt” as a parameter. Different values of “salt” lead to different hashes. This value is specified by the configuration parameter <PREFIX>.storage.location.hash.salt. The value of this salt is the same for all installations; at least versions 6.2 and 6.6 have the same value hardcoded in the configuration.
See the section “Configuration Parameters Prefix” below to learn more about what <PREFIX> is.
Configuration Parameters Prefix
The configuration settings can be specified globally or for a particular folder. Some values can be marked as default. So, all mentioned configuration parameters start with <PREFIX>, which is one of the following values:
media.foldermedia.defaultmedia.globalSettings
Abandoned media and other special cases
- If you remove an object that refers to the media object, the media object won’t be removed.
- For example, if you remove a component that has a media attribute filled with an image, the component will be removed, but the image won’t. It creates “abandoned media”: media objects that are not used by anybody.
- Removing and changing media objects:
- If you remove the only media object for the file, the platform removes the file from the storage.
- The file is removed from the file system only if there is no
Mediaobject referring to the file. - If you replace an image for the object, the previous version of the image will be removed from the file system if there are no other objects using this image. The same applies to any other types of media objects.
- If you clear the image for the object, the old image file will be removed automatically. The same applies to any other types of media objects.
- However, all these actions are performed by
RemoveInterceptor, which is not involved if you decide to explicitly turn it off, for example, for ImpEx import. If so, removal or changes create abandoned files.
- Synchronizations:
- A synchronized copy of the object refers to the same physical file on the file system.
- If you synchronize media objects from version A to version B, and both objects have different media files, and both media files are not used by other objects, you will have only the first media file, from A, available after synchronization, because the second file, from B, will be removed automatically once it is not used by any objects anymore.