- v1.0.0-latest-prod
As of Broadleaf Release Train 2.1.3-GA, all microservices have been upgraded to Spring Boot 3.3
StorageProvider Path ChangesThis release makes changes to the internal logic used by StorageProvider implementations such as FilesystemStorageProvider and GoogleCloudStorageProvider to determine the 'actual path' used to store asset data.
The primary motivation for this change is to mitigate the possibility of a 'collision', where two assets with distinct URL values could still be assigned the same 'actual path' in the StorageProvider.
The new approach guarantees uniqueness in the 'actual paths'.
High level takeaways for this change:
All new assets created with 2.0.3+ of AssetServices will use the new path calculation logic and be stored/resolved at the new paths
Existing assets created prior to 2.0.3 will continue to be resolvable from their current locations
This does not require any migration of existing asset data
Detailed changes:
Introduce a new StorageLocationMapping entity and supporting service/repository to map between 'original' and 'actual' storage provider locations
See the Schema Changes section on how to absorb the new table
Add new cache configuration properties for StorageLocationMapping (broadleaf.asset.cache.storage-location-mapping.by-provider-type-and-original-location-enabled and broadleaf.asset.cache.storage-location-mapping.by-provider-type-and-original-location-ttl).
This cache is disabled by default.
DefaultContentResolver.readResourceWithMetadata has been updated to not engage any caching behavior when processing a request with image effects.
This only affects how StorageLocationMapping records are fetched.
Update FilesystemStorageProvider
Update the storage path calculation logic to use a globally unique filename and leverage StorageLocationMapping to track the mapping
FilesystemStorageProvider#getHashedResourcePath is now only used to support resolving existing assets for backward compatibility.
If you have overridden this method in your project to customize the logic, then consider reviewing and adding similar logic to the new FilesystemStorageProvider#calculateHashedStorageLocationDirectory method, which is used to generate the hashed directory prefix for new assets.
FilesystemStorageProvider#mapGivenPathsToHashedPaths is deprecated and now no longer called by the framework
If you have overridden this method in your project to customize the logic, you may consider reviewing these replacement methods and potentially add your customizations to them instead: FilesystemStorageProvider.generateActualStorageLocations() and FilesystemStorageProvider.resolveExistingActualStorageLocations()
Due to the internal filename naming changes, any callers of the already-deprecated FilesystemStorageProvider.readResource() and FilesystemStorageProvider.readResources() methods will now see a different filename value in the result.
Callers of the newer FilesystemStorageProvider.readStreamableResourceWithMetadata()/FilesystemStorageProvider.readStreamableResourcesWithMetadata() will see the original value.
Update GoogleCloudStorageProvider
Update the storage path calculation logic to use a globally unique filename and leverage StorageLocationMapping to track the mapping
GoogleCloudStorageProvider.getBlobId is deprecated and now no longer called by the framework
If you have overridden this method in your project to customize the logic, you may consider reviewing these replacement methods and potentially add your customizations to them instead: GoogleCloudStorageProvider.generateActualStorageLocations() and GoogleCloudStorageProvider.resolveExistingActualStorageLocations()
GoogleCloudStorageProvider#getHashedResourcePath is now only used to support resolving existing assets for backward compatibility.
The new approach does not use hashing.
Updated methods DefaultStorageService#mapEligibleProperties and DefaultStorageService#generateAssetForUploadRequest to be access-level protected
Allow altText and title to be supplied on the asset upload request
Folders and assets now sorted alphabetically by default
Fix issue that prevents assets with string content in name to be found
GoogleCloudStorageProvider.deleteResource() now throws the BLC StorageException when a requested item is not successfully deleted.
This is now consistent with the expectations defined in the StorageProvider interface.
GoogleCloudStorageProvider.deleteResources() now throws the BLC BulkStorageException instead of the BLC StorageException when it internally encounters com.google.cloud.storage.StorageException.
This is now consistent with the expectations defined in the StorageProvider interface.
Fixed an issue where DefaultStorageService and ImageMagickImageOperationService did not invoke StorageProvider.addResourceFromStream() with a try-with-resources for the InputStream.
The input stream may have been left open in the event of an error.
Updated addResourcesFromStreams(), deleteResources(), and addResourcesFromFiles() implementations in FilesystemStorageProvider and GoogleCloudStorageProvider to ensure that the success/failure responses given back to the caller (either in BulkAddResourcesResponse or in BulkStorageException) always return by the original path the caller provided rather than any cleaned representation. This ensures the caller can track success/failure purely by the path they gave rather than receiving a path they do not recognize, matching the original intent of the API contract.
Decouple the @EnableConfigurationProperties(AssetCacheProperties.class) from the registration of the Ignite specific configuration in AssetCacheAutoConfiguration, increasing flexibility
The database schema has changed as part of this version.
Create/update changes (new tables, new columns, etc) are automatically included in the updated *changelog-master.xml after you upgrade to the new Asset Services JAR.
The new changesets inside will run automatically to migrate existing data.
| Database Platform | Create/Update Changelog File Name |
|---|---|
PostgreSQL |
|
MariaDB |
|
MySQL |
|
Oracle |
|
YugabyteDB |
|