We are using Grails 4.x with RxJava 2.x plugin (grails-event-rxjava2:4.0.0). We are trying to change the default Io scheduler to a different one. Documentation shows how to this for the default event bus implementation, but we cannot change it for RxJava 2
grails-app/conf/spring/resources.groovy
import org.grails.events.bus.*
import java.util.concurrent.*
beans = {
eventBus(ExecutorEventBus, Executors.newFixedThreadPool(5))
}
For RxJava2 we are supposed to use RxJavaPlugins class, but we don't know how to configure the resources.groovy.
Anyone can help? Thanks in advance
RxEventBus is configured with Java's ServiceLoader via a src/main/resources/META-INF/services/grails.events.bus.EventBus file, using its default constructor with a Schedulers.io() scheduler. Since the scheduler attribute is final, the only way I imagine you can achieve what you want is to provide your own implementation:
Make grails-events-rxjava2 a compileOnly dependency, otherwise both RxEventBus and YourEventBus will be found, resulting in an error.
Subclass org.grails.events.rxjava2.RxEventBus:
class YourEventBus extends RxEventBus {
YourEventBus() {
super(Schedulers.computation()) //or whatever
}
}
Register your custom implementation in a src/main/resources/META-INF/services/grails.events.bus.EventBus file.
Related
I would like to disable the rabbit health check in my default RabbitMockConfiguration.
We have a Configuration that is imported via #Import. Unfortunately the Configuration does not prevent the health check from being added to the health indicator as that happens once spring-rabbit is in the classpath.
We have the workaround, that we add a properties file in every service using that Configuration, which disables the property management.health.rabbit.enabled, but for us it would be much nicer to be able to disable that heathcheck on configuration level.
I thought about the tests with #TestPropertySource(properties = ["management.health.rabbit.enabled=false"]), but I could not find an equivalent to use for the a #Configuration, as #PropertySource expects a location for a properties file and does not accept single properties.
Any idea what we can do?
Spring boot version: 2.2.4
Spring amqp version: 2.2.3
Spring Version: 5.2.3
If you want to change the behaviour of the health check, I'd rather override the health check so that it states Rabbit is in mock mode.
To do so, just create a HealthIndicator bean named rabbitHealthIndicator:
#Bean
public HealthIndicator rabbitHealthIndicator() {
return () -> Health.up().withDetail("version", "mock").build();
}
This has the effect of switching the production one and exposes the fact the app is running with a mock.
I guess you should add 'ApplicationListener' and add the implementation to 'src/main/resources/META-INF/spring.factories' to your module with MockReddisConfiguration. This is described in more detail here
I am creating a new plugin containing CustomService which is intended to replace an existing service from an existing plugin. Following the pattern found in custom security implementations and shown here, I've added the configuration to the resources.groovy, oldService(path.to.new.CustomService). I've also tried adding all injected classes into the closure for this service.
(Actual service names are RegistrationPersonRegistrationCompositeService and NewRegistrationPersonRegistrationCompositeService in code block)
I dont want the original application code to have any reference to the new plugin. However, BuildConfig at the application level will require plugin.location entry. My resource.groovy mods are in the new plugin. I have not had success in this endeavor. Am I modifying the wrong resources.groovy? If this change is required in the original application code, I've lost the ability to leave the original code unaltered. I'm not extending the original Service nor using override annotation. My intent is to replace the service (Spring bean) on start-up. The new plugin has a dependency on the old plugin in an attempt to manage order of operations in loading these classes.
Does it matter that the old service is previously injected in a controller? this would require me to override the controller in the new plugin in the same fashion and inject the correct service for desired behavior?
I've found documentation showing that within a plugin, the resources.groovy will be ignored. Also, building the resources.groovy into a war is problematic. I have not found a solution. I'm getting no error that I can share, just that the desired behavior is missing; the original service is handling the requests.
//was resource.groovy - now renamed to serviceOverRide.groovy - still located in \grails-app\conf\spring of plugin
//tried this with and without the BeanBuilder. Theory: I'm missing the autowire somehow
import org.springframework.context.ApplicationContext
import grails.spring.BeanBuilder
def bb = new BeanBuilder()
bb.beans {
registrationPersonRegistrationCompositeService(path.to.services.registration.NewRegistrationPersonRegistrationCompositeService) { bean ->
bean.autowire = true
registrationRestrictionCompositeService = ref("registrationRestrictionCompositeService")
registrationPersonTermVerificationService = ref("registrationPersonTermVerificationService")
}
classRegistrationController(path.to.services.registration.ClassRegistrationController) { bean ->
bean.autowire = true
selfServiceLookupService = ref("selfServiceLookupService")
registrationPersonRegistrationCompositeService = ref("registrationPersonRegistrationCompositeService")
}
}
ApplicationContext appContext = bb.createApplicationContext()
Additional information: Added the following lines to the PluginGrailsPlugin.groovy. The original service is still handling these requests
def dependsOn = ['appPersonRegistration': '1.0.20 > *']
List loadAfter = ['appPersonRegistration']
def doWithSpring = {
registrationPersonCourseRegistrationCompositeService(path.to.new.registration.TccRegistrationPersonCourseRegistrationCompositeService)
}
def doWithApplicationContext = { applicationContext ->
SecurityContextHolder.setStrategyName(SecurityContextHolder.MODE_INHERITABLETHREADLOCAL)
DefaultListableBeanFactory beanFactory = (DefaultListableBeanFactory) applicationContext.getBeanFactory()
beanFactory.registerBeanDefinition("registrationPersonCourseRegistrationCompositeService", BeanDefinitionBuilder.rootBeanDefinition(TccRegistrationPersonCourseRegistrationCompositeService.class.getName()).getBeanDefinition())
}
I highly recommend you read the section of the documentation on Plugins. The reason why I recommend this is because plugins:
Do not include, or make use of resources.groovy
Provide a means through doWithSpring to effect the spring application
Following the information in the documentation you should have no issue overriding the service in the application context.
You must implement your changes to the application context using doWithSpring this is the key to solving your issues.
In this implementation, I had a utility method in a service for which I was attempting to provide an override. Problem is, the Aspect works as a proxy and must override a method that is called directly from another class. In my classRegistrationController, I was calling service processRegistration() which in turn called applyRules(). Example-only method names used. Since the service was calling its own utility, there was no opportunity for the proxy/wrapper to circumvent the call to applyRules(). Once this was discovered, I refactored the code in this fashion: Controller calls processRegistration as it always had. After returning, another call is made to the service, processLocalRules(). The new method is an empty placeholder intended to be overridden by the client's custom logic. The plugin with Aspect works now using resources.groovy. I prefer the doWithSpring as Joshua explained for this reason: my intent to get the plugin to work without modification to the original app-config; otherwise resource.groovy is a valid approach. Upvoting Joshua's answer as it does satisfy the requirement and is cleaner. Thanks!
We are trying to use spring-cloud-aws to receive messages from AWS SQS
We would like to receive messages using annotation. In spring documentation, it is confusing.
Below, they stated to use MessageMapping and QueueMessageHandler annotation.
Annotation-driven listener endpoints are the easiest way for listening
on SQS messages. Simply annotate methods with MessageMapping and the
QueueMessageHandler will route the messages to the annotated methods.
But in the sample, #SQSListener is used.
#SqsListener("queueName")
public void queueListener(Person person) {
// ...
}
I searched for #SqsListener and found that it is being used in test classes like here . So we tried to import, org.springframework.cloud.aws.messaging.listener.annotation.SqsListener. Unfortunately this annotation class is not available in latest release.
Is the org.springframework.cloud.aws.messaging.listener.annotation.SqsListener that I am using is proper one? Or it is not yet present in released version? If not released can I use #MessageMapping to receive messages from SQS?
It appears to not be included in the 1.0.4 release of Spring Cloud AWS however I was able to successfully import SqsListener when using 1.1.0.RC1
You need to add:
dependencyManagement {
imports {
mavenBom 'org.springframework.cloud:spring-cloud-aws:1.1.0.RC1'
mavenBom "org.springframework.boot:spring-boot-starter-parent:1.3.3.RELEASE"
}
Additionally the messaging dependency needs to be added (and I've got actuator included too):
dependencies {
compile("org.springframework.cloud:spring-cloud-starter-aws")
compile("org.springframework.cloud:spring-cloud-aws-messaging")
compile("org.springframework.boot:spring-boot-starter-actuator")
}
Note, I haven't tested it to see if it can actually consume a message of SQS but at least the dependency is resolving.
I am using the 1.1.0.RELEASE, that's the dependencies I have:
compile("org.springframework.boot:spring-boot-starter:1.3.5.RELEASE")
compile("org.springframework.cloud:spring-cloud-starter-aws-messaging:1.1.0.RELEASE")
I tried both annotations #SqsListener and #MessageMapping both work fine. The SqsListener is a specialization of the MessageMapping annotation which is adding an additional property, the deletion policy.
I am guessing the documentation has to be updated, I got confused as well.
Now #SqsListener available with 1.1.0.RELEASE.
I'm trying to use the Spring DSL functionality in a Grails plugin. However, it doesn't work. Here's what I have in my plugin's conf/spring/resources.groovy file:
import org.springframework.aop.scope.ScopedProxyFactoryBean
// Place your Spring DSL code here
beans = {
baseSvcProxy(ScopedProxyFactoryBean) {
targetBeanName = 'baseService'
proxyTargetClass = true
}
}
However, it seems to be completely ignored. If I move the exact same code to the application's conf/spring/resources.groovy file everything works perfectly. Is there something that needs to be done differently for plugins for this to work?
In order to modify the spring context from a Grails plugin you need to use the doWithSpring section of your plugin by hooking into the runtime configuration. Resources.groovy is ignored in plugins.
In my spring + maven app, I have created some tests for the Data Access Layer that I would like now to run against multiple datasources. I have something like:
#ContextConfiguration(locations={"file:src/test/resources/testAppConfigMysql.xml"})
public class TestFooDao extends AbstractTransactionalJUnit38SpringContextTests {
public void testFoo(){
...
}
}
It has currently the config location hardcoded, so it can be used only against one datasource.
What is the best way to invoke the test twice and pass two different configs (say testAppConfigMysql.xml and testMyConfigHsqlDb.xml)?
I've seen suggestions to do this via system properties. How can I tell maven to invoke the tests twice, with different values of a system property?
I don't know if there is some sexy and fancy solution, being simple as well, for this. I would just implement base class with all testing stuff and then inherit it into 2 classes with different annotation-based configuration, like this:
#ContextConfiguration(locations={"firstDs.xml"})
public class TestFooDaoUsingFirstDs extends TestFooDao {
}
#ContextConfiguration(locations={"secondDs.xml"})
public class TestFooDaoUsingSecondDs extends TestFooDao {
}
Unless you have to handle really high number of different datasources this way, that is OK for me.
Rather than file:..., you can use classpath:... (remove the src/test/resources, it's implicit if you use classpath). Then you can have a single master context with the line:
<import resource="dao-${datasource}.xml" />
If you run the Maven build with the option -Ddatasource=foo, it will replace the ${datasource} in the master context with the whatever you specify. So you can have datasource-foo.xml, datasource-bar.xml etc. for your different configurations.
(You need to enable Maven resource filtering in the POM for this to work).
Alternatively, check out the new stuff in Spring 3.1: http://www.baeldung.com/2012/03/12/project-configuration-with-spring/
Edit: A third option would be to have all the test classes extend some superclass, and use
Junit's #Parameterised, where the parameters are the different Spring contexts. You couldn't use #ContextConfiguration in that case, but you can always create the Spring context manually, then autowire the test class using org.springframework.beans.factory.config.AutowireCapableBeanFactory.autowireBean()
Check maven invoker plugin. It supports profiles also.