I added a custom document & ui model config like this:
mgm.services.core.system-models.custom-document-models=classpath*:/model/picus/*.xml
mgm.services.core.system-models.custom-ui-models=classpath*:/model/melies/*.xml
Funnily enough the platform server did not start anymore since it was missing the default document model s (e.g. for user and such).
After I added
mgm.services.core.system-models.document-models=classpath*:/com/mgmtp/a12/platform/documentmodels/*.xml
everythig was fine again. The default value was taken from the excellent [options documentation]<INTERNAL_LINK>.
But why I had to add the default mgm.services.core.system-models.document-models puzzles me - does anybody got a clue or know what I did wrong?
Hi @marcus-stellar-pool could you put the running and not running properties file?
Hi,
of course. I do not see why this helps, but anyway:
not running
spring.datasource.url=jdbc:postgresql://cosmo-claims-postgres:5432/cosmo-claims
spring.datasource.username=postgres
spring.datasource.password=postgres
spring.activemq.broker-url=tcp://cosmo-claims-activemq:61616
mgm.services.core.search.service=solrclient
mgm.services.core.search.remoteSolrUrl=http://cosmo-claims-services-solr:8983/solr
mgm.services.core.search.startup=regular
mgm.services.core.system-models.custom-document-models=classpath*:/model/picus/*.xml
mgm.services.core.system-models.custom-ui-models=classpath*:/model/melies/*.xml
mgm.services.core.system-models.document-models=classpath*:/com/mgmtp/a12/platform/documentmodels/*.xml
not running:
spring.datasource.url=jdbc:postgresql://cosmo-claims-postgres:5432/cosmo-claims
spring.datasource.username=postgres
spring.datasource.password=postgres
spring.activemq.broker-url=tcp://cosmo-claims-activemq:61616
mgm.services.core.search.service=solrclient
mgm.services.core.search.remoteSolrUrl=http://cosmo-claims-services-solr:8983/solr
mgm.services.core.search.startup=regular
mgm.services.core.system-models.custom-document-models=classpath*:/model/picus/*.xml
mgm.services.core.system-models.custom-ui-models=classpath*:/model/melies/*.xml
Which is essential as in the first post
@tomas-thin-gale do you have any idea about this?
Configurations that are provided in core.properties and rest.properties configuration files should be considered a default configuration and the default values for the initialization of server. Therefore If you remove some of the values, the server does not know where to take values for those configuration properties. Rather than removing those properties, a new configuration file should be provided application.properties which overwrites the values of the default configuration. This being said there still might be a problem on the services side.
I have made several tests and it looks like that this particular property is not needed every time the server is started but there is a bug in spring boot 2 where Resource property resolution does not work properly and therefore we are forced to use @Value annotation in UserDocumentConfiguration class. This means that the server will fail to start-up if this property is missing.
The following error appears in the logs:
Caused by: java.lang.IllegalArgumentException: Could not resolve placeholder 'mgm.services.core.system-models.custom-ui-models' in value "${mgm.services.core.system-models.custom-ui-models}"
at org.springframework.util.PropertyPlaceholderHelper.parseStringValue(PropertyPlaceholderHelper.java:172)
at org.springframework.util.PropertyPlaceholderHelper.replacePlaceholders(PropertyPlaceholderHelper.java:124)
at org.springframework.core.env.AbstractPropertyResolver.doResolvePlaceholders(AbstractPropertyResolver.java:237)
at org.springframework.core.env.AbstractPropertyResolver.resolveRequiredPlaceholders(AbstractPropertyResolver.java:211)
at org.springframework.context.support.PropertySourcesPlaceholderConfigurer.lambda$processProperties$0(PropertySourcesPlaceholderConfigurer.java:175)
at org.springframework.beans.factory.support.AbstractBeanFactory.resolveEmbeddedValue(AbstractBeanFactory.java:839)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1086)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1065)
at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:584)
at org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:91)
at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:373)
... 30 common frames omitted
I have tried to remove other properties and I can see that the behavior of server is not consistent. The server sometimes survives removal of configuration key and sometimes not. I have created a ticket <INTERNAL_LINK> for consolidation of default values for all services configuration options. The ticket is marked as breaking because the changes in default configuration values is considered breaking change. And upgrade of 3rd party libraries is also considered breaking change. Therefore fixing this cannot be done sooner than in February release.
Thank you for your post. We will try to fix this inconsistency as soon as possible.
Yes,
we give the properties to the service via
-Dspring.config.location=/cosmo-claims/config/services.properties
Good to see that there are oddities you are inspecting. It does not matter that this is fixed in the next release. We have a working config for now and there is no real pressure to get this now fixed.
By the way the server did not complain about missing properties but of missing default document models. When debugging I noticed that the ressources array is empty, but given.
Thanks
Marcus
I am happy that this problem is not blocking you, but on the services side, we should have a unified policy on how to provide default values anyway. Therefore it makes sense to spend some time on unifying it so there will be a clear statement from our side how to handle configuration.