Hello, I have a problem with configuring two storage types - FS and S3 (not at the same moment) in my Spring Boot app.
I have the class with the configuration for FS:
@Configuration
@ConditionalOnProperty(value = "storage.type", havingValue = "springContentFilesystem")
@EnableFilesystemStores
public class SpringContentFilesystemStorageConfig {
@Bean
FileSystemResourceLoader storageLocationResourceLoader(StorageProperties storageProperties) {
return new FileSystemResourceLoader(storageProperties.getAbsoluteStorageLocationPath().toString());
}
@Bean
StorageService storageService(ResourceContentStore resourceContentStore) {
return new SpringContentStorageService(resourceContentStore);
}
}and the second one for S3:
@Configuration
@ConditionalOnProperty(value = "storage.type", havingValue = "springContentS3")
@EnableS3Stores
public class SpringContentS3StorageConfig {
@Bean
public AmazonS3 s3Client(@Value("${storage.s3.region}") String s3region) {
return AmazonS3ClientBuilder.standard()
.withRegion(Regions.fromName(s3region))
.withCredentials(new EnvironmentVariableCredentialsProvider())
.build();
}
@Bean
StorageService storageService(ResourceContentStore resourceContentStore) {
return new SpringContentStorageService(resourceContentStore);
}
}Currently, this class with the configuration is not imported / scanned anywhere - just adding spring-content-s3-boot-starter to the classpath (pom.xml) causes that the Bean of the ContentStore type is not created - context does not get up.
Where I made a mistake?
The exception is:
Caused by: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'storageService' defined in com.mypackage.storage.springcontent.SpringContentFilesystemStorageConfig: Unsatisfied dependency expressed through method 'storageService' parameter 0; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'com.mypackage.storage.springcontent.ResourceContentStore' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {}
And this is the ResourceContentStore:
public interface ResourceContentStore extends ContentStore<Resource, String> {
}In my opinion, the problem lies somewhere in the auto-configuration when we have these two modules simultaneously:
<dependency>
<groupId>com.github.paulcwarren</groupId>
<artifactId>spring-content-fs-boot-starter</artifactId>
<version>1.1.0.M4</version>
</dependency>
<dependency>
<groupId>com.github.paulcwarren</groupId>
<artifactId>spring-content-s3-boot-starter</artifactId>
<version>1.1.0.M4</version>
</dependency>But I can't figure out exactly what's going on.
I can try and help. By the looks, you have typed your ContentStore to a Spring Resource.
ContentStores are for associating content with Spring Data Entities and therefore you would type your ContentStore to your Entity; e.g. something like public interface MyEntityContentStore extends ContentStore<MyEntity, String>. If you don't want to do this then you would probably be best using a Store; e.g. public interface MyStore extends Store<String>. Which are you trying to do?
In addition to spring-content-fs, I want spring-content-s3 (depending on deployment (and configuration) - onpremises / kubernetes installation), I want to keep files in other places.
After adding the s3 starter to the application, the autoconfiguration does not create a ContentStore bean -
ResourceContentStore.
Got it. Thanks for the clarifications. Then I think you are headed in the right direction. You should add both storage module dependencies. But because you have both that means Spring Content will enter a "strict" mode when parsing for Stores; i.e. because you have two storage modules on the classpath it wont know what implementation you want for
ResourceContenStore so you will need to tell it by adding two stores that extend the implementation-specific ContentStores; i.e. FilesystemResourceContentStore extends FilesystemContentStoreand S3ResourceContentStore extends S3ContentStore. That will have a bit of a ripple effect into your storageService bean initializor methods but SpringContentStorageService can be typed to just ContentStore. I believe that might work for you.
Also, Spring Content REST should work on top of this too (in case you are using it)
I have a newContentCopy method ,which to handle workingCopy and locking
like this ```java
public static <T, ID extends Serializable> T newContentCopy(LockingAndVersioningRepository<T, ID> repository, T content, Consumer<T> onNewCopy) {
content = repository.lock(content);
try {
T newContent = repository.workingCopy(content);
try {
onNewCopy.accept(newContent);
return newContent;
} finally {
repository.unlock(newContent);
}
} finally {
repository.unlock(content);
}
}
but , this will have too many ObjectOptimisticLockingFailureException, which is the right coding about this?
I should return newContent or content ？ which is latest version ？
A working copy is meant to be a private working copy that only you can see. If you
unlock someone else could then lock content and create another working copy. I am not sure that I have tested that! My assumption has always been that the lock extends across newWorkinCopy and version but that said, perhaps unlock should throw an error if a working copy exists.
public static <T, ID extends Serializable> T newContentCopy(LockingAndVersioningRepository<T, ID> repository, T content, Predicate<T> predicate, Consumer<T> onNewCopy) {
content = repository.lock(content);
try {
if (predicate.test(content)){
T newContent = repository.workingCopy(content);
try {
onNewCopy.accept(newContent);
} finally {
return repository.unlock(newContent);
}
}
} finally {
repository.unlock(content);
}
return null;
}```java
IDEA will have >'return' inside 'finally' block
'return' inside 'finally' block
Or alternatively, just call
version instead on newWorkingCopy as it looks like you have no need for a real private working copy that can be edited multiple times and saved before versioning?
The more I look at your example the more I think you should be calling
version, not workingCopy. Working copies is a construct brought over from CMIS and is meant for use cases where you have a user that will want to edit their 'word doc' many times before versioning it. Your code suggests you dont want working copies. You just want to version
yes, I will do that , thanks
are you trying to do automatic versioning? because I recently added support to spring content for spring data envers
K. Spring data envers will automatically create a new version of an entity whenever you save it. And with the support in spring-content it will do that for every setContent operation too. This is all done through
save and setContent and because it is handled by hibernate removes the need for the pessimistic locking. It is more of an auditing thing but I mention it because it might be a better solution for you, depending on your use case.
Hi @paulcwarren , I'm curious to know if its possible for renditions to process a collection of resources from a JPA content store? Have been testing renditions and it works really well but I have a use case where I'm looking to merge multiple related resources and render a single output.
11 replies
Sounds like you need a version tree?
workingCopy doesn't set @SuccessorId, I think I have to use this method
If I don't have field annotated with @SuccessorId, Is
version can replaced with workingCopy?
But it is a version series, not a tree I never intended workingCopy to be used as a version tree. I am not sure how you would do that actually. But if it works for you then great.