Apache ShardingSphere provides the ShardingSphereDataSource to encapsulate the routing mechanisme. So, if we inject a ShardingSphereDataSource into a EntityManager, we can easily persist our data and route to the planned destination via EntityManager#persist method.
I don't know my understanding is correct or not, Does Panache seems to only accept AgroalDataSource?
I refer to this project to produce a ShardingSphereDataSource bean, and use following code snippet to inspect whether the ShardingSphereDataSource is produced successfully.
CDI.current().getBeanManager().getBeans(DataSource.class).forEach(bean -> {
log.info("DataSource Bean name:{}, beanClass:{}", bean.getName(), bean.getBeanClass());
});
The result shows I have a ShardingSphereDataSource named defaultDs in the CDI context.
DataSource Bean name:defaultDs, beanClass:class org.apache.shardingsphere.driver.jdbc.core.datasource.ShardingSphereDataSource
Next, I config a persistent unit and refer to this datasource.
quarkus.hibernate-orm.datasource=defaultDs
quarkus.hibernate-orm.packages=x.y.x.domain
I get the error message.
Caused by: io.quarkus.runtime.configuration.ConfigurationException: The datasource 'defaultDs' is not configured but the persistence unit '<default>' uses it. To solve this, configure datasource 'defaultDs'. Refer to https://quarkus.io/guides/datasource for guidance.
So, how do we configure a non-AgroalDataSource within Quarkus and Panache?
Related
In a Spring Boot application how do you register custom converts to be used when processing application configuration?
I have made a custom convert (org.springframework.core.convert.converter.Converter) so it can be used by the ApplicationConversionService/Binder to parse #ConfiguraitonProperties defined in application.properties and application.yaml configuration files but do not know how to register it.
I have tried the solution here https://stackoverflow.com/a/41205653/45708 but it creates an instance of my converter after the application configuration parameters have been processed.
I ran into this issue myself recently. From what I can tell, the key issue is that binding to configuration properties occurs very early in the Spring startup process, before the Application Context is fully initialized. Therefore the usual methods for registering a converter are not reliable. In fact the ConversionService used for configuration binding appear to be a one-off and not really connected to the ConversionService that is stored in the Application Context.
I was able to get something working but it feels like a hack, as it relies on internal implementation details that may work today but not tomorrow. In any case, this is the code I used:
((ApplicationConversionService) ApplicationConversionService.getSharedInstance()).addConverter(myCustomConverter);
The trick I found was to make sure this gets called as soon as possible at application startup so that it gets called before the configuration binding where it's needed. I put it in a #PostConstruct block inside my main #SpringBootApplication class as this seemed to get invoked early on, at least in my case.
Can I dynamically refresh properties that are used by Spring Boot's auto configuration setup?
For example, I have the following properties set (via cloud config) to auto configure a dataSource:
spring.datasource.username=user1
spring.datasource.password=test
Now if I change the password prop on the config server, and hit the /refresh endpoint, I can see that the updated prop is retrieved but the DataSource is not refreshed.
I know I can manually configure the DataSource beans and make sure they fall under a RefreshScope, but I was hoping to find a way to mark the auto configured properties as "refreshable". I have some use cases where I'd want to refresh props used by Spring Boot for other beans besides DataSources, and setting up some of those beans manually could be a pain.
I think I spoke too soon, at least as far as my DataSource example goes. A new db connection was being created with the updated props.
Which makes sense especially when looking at the docs here
This didn't re-connect some of my spring.cloud.stream.bindings properties I had, but in that case I can probably solve the issue with #RefreshScope.
There's a configuration property to set in case of the Autoconfigured bean is immutable (don't change the properties after initialized)
You can put a list (set) of classes that you need to be refreshed and you don't have control over the source code, you can put them under the property: spring.cloud.refresh.extra-refreshable
e.g.:
spring
cloud
refresh
extra-refreshable:
- org.springframework.mail.javamail.JavaMailSenderImpl
see: https://cloud.spring.io/spring-cloud-static/Greenwich.SR1/single/spring-cloud.html#refresh-scope
I have several tests which all extends the same root test which define the Spring test application context. One of my test use a different profile so I have annotated the child class with #ActiveProfiles("specialTestProfile"), this profile create a special mock bean which is injected in the context. I want to clear my context before and after executing this test, but I didn't find the correct way to do it. I know that the Spring test framework does some context caching and that in my case I should have two different context and it should not be necessary to reload the context but it is not working because of bitronix which generate this strange error if I don't clean the context:
Caused by: bitronix.tm.resource.ResourceConfigurationException: cannot create JDBC datasource named unittestdb
at bitronix.tm.resource.jdbc.PoolingDataSource.init(PoolingDataSource.java:57)
at sun.reflect.GeneratedMethodAccessor404.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1608)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1549)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1479)
... 62 more
Caused by: java.lang.IllegalArgumentException: resource with uniqueName 'unittestdb' has already been registered
at bitronix.tm.resource.ResourceRegistrar.register(ResourceRegistrar.java:55)
at bitronix.tm.resource.jdbc.PoolingDataSource.buildXAPool(PoolingDataSource.java:68)
at bitronix.tm.resource.jdbc.PoolingDataSource.init(PoolingDataSource.java:53)
... 68 more
Even if I reload the context for each test class (by annotating my parent class with #DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_CLASS), I still get the error above at some point... do you have any idea how to solve this problem?
Without seeing your exact configuration for the PoolingDataSource, I cannot know exactly how to solve your issue.
However, it appears that you can likely solve this issue by creating your PoolingDataSource with a unique name by invoking the setUniqueName() method (in an #Bean method if you're using Java config) or by setting the uniqueName property (if you're using XML config). How you generate the unique name depends on the configuration style you are using.
If you do not set a unique name for each ApplicationContext that creates the PoolingDataSource bean, you will continue to see the exception telling you that a second pool cannot be created with the "unittestdb" name since it already exists. The reason is that the init() method in PoolingDataSource delegates to ManagementRegistrar.register() which registers an MBean under the unique name, and the same MBeanServer is used for all tests within the same JVM process (i.e., for all tests in your suite).
Instead of generating a unique pool name per application context, another option might be to disable the use of JMX by setting the bitronix.tm.disableJmx property to false. Consult the isDisableJmx() and setDisableJmx() methods in bitronix.tm.Configuration for details.
I'm using springFramework and I try to setBeanDefinitions, the problem is that this methode need a Map beanDefinition as a param... could U tell me plz how I could instantiate this param?
NullPointerException at com.liferay.portal.spring.util.SpringFactoryImpl.setBeanDefinitions(SpringFactoryImpl.java:56)
additional information:
I try to deploy a liferay project without using liferay configuration files (only springFramework libraries), I created my own sessionFactory, my own dataSource ... etc!!
when I run the program, I'm able to create dataBase Schema basing on portlet-hbm.xml information... well now I try to instantiate beans for portal-spring.xml.. (which are xxxxpersistance.java)! those latters told me that they use 'com.liferay.portal.kernel.dao.orm.SessionFactory' as a required type and it can not convert property value of type 'org.hibernate.impl.SessionFactoryImpl'!! so I tried to use the liferay libraries only for those beans and I try to instanciate them manually... but I wasn't able to setBeanDefinitions cause I need a Map beanDefinition as a param... I don't know if there is a way to get them using sessionFactory or not!!
Thanks again
You only mention junit in the tags to your question. I'd recommend to write unit tests without relying on the whole Liferay infrastructure. That will tremendously lower your required setup efforts and simplify your life a lot.
We're building a Spring-based application which will be delivered to end users as a distribution package. Users are responsible for properly configuring whatever needs to be configured (it's mostly about various filesystem locations, folder access permissions, etc). There's a good idea to make the app help users understand what is not configured or which parts of configuration are invalid.
Our current approach is a custom ApplicationContextInitializer which does all the environment validation "manually" and then registers few "low level" beans in the application context explicitly. If something is wrong, initializer throws, exception is caught somewhere in main(), interpreted (converted into plain English) and then displayed.
While this approach works fine, I'm wondering if there are any best practices to minimize hand-written code and use Spring whenever possible.
Here's an illustrative example. The application requires a folder for file uploads. This means:
There should be a configuration file
This file should be accessible by the app
This file should have no syntax errors
This file should explicitly define some specific property (let it be app.uploads.folder)
This property should describe the existing filesystem entity
This entity should be a folder
The app should have read/write access to this folder
Does Spring provide any tools to implement this sort of validation easily?
Spring Boot has a nice feature for context and external configuration validation. If you define a POJO class and declare it as #ConfigurationProperties then Spring will bind the Environment (external properties and System/OS typically) to its properties using a DataBinder. E.g.
#ConfigurationProperties(name="app.uploads")
public class FileUploadProperties {
private File folder;
// getters and setters ommitted
}
will bind to app.uploads.folder and ensure that it is a File. For extra validation you can do it manually in the setter, or you can implement Validator in your FileUploadProperties or you can use JSR-303 annotations on the fields. By default an external property in app.uploads.* that doesn't bind will throw an exception (e.g. a mis-spelled property name, or a conversion/format error).
If you use Spring Boot Autoconfigure #EnableAutoConfigure you don't have to do anything else, but if it's just vanilla Spring (Boot) you need to say #EnableConfigurationProperties in your #Configuration somewhere as well.
A bonus feature: if you also use the Spring Boot Actuator you will also get JMX and HTTP support (in a webapp) for inspecting the bindable and bound properties of #ConfigurationProperties beans. The HTTP endpoint is "/configprops".