I'm developing a Spring MVC web application (Java 6 and Spring 3.0.6 currently).
I'm starting to write some Spring integration tests using Junit4 that extend AbstractTransactionalJUnit4SpringContextTests. I invoke these either through our Maven build or in the EclipseIDE (3.7). These tests invoke Controller methods (i.e., methods annotated with #RequestHandler in a class annotated with #Controller).
All was going well until I added aspect-based logging into the controller :
// public controller methods
#Pointcut("execution(public * com.axiope.webapp.controller.*.*(..))")
private void publicControllerMethod() {
}
#Pointcut("#annotation(org.springframework.web.bind.annotation.RequestMapping)")
private void requestHandler(){}
#Pointcut("publicControllerMethod() && requestHandler() ")
private void controllerHandler(){}
// logs contoller exceptions
#AfterThrowing(
pointcut="controllerHandler()",
throwing="ex")
public void logControllerExceptions(Throwable ex) {
logger = LogFactory.getLog(ex.getClass());
logger.error("Controller exception !" + ex.getMessage());
}
Now when I run tests through Maven I get an error like :
No unique bean of type [com.axiope.webapp.controller.StructuredDocumentController]
is defined: expected single bean but found 0:
In the tests, I'm loading the controller from the applicationContext in the setUp method:
structuredDocumentController = applicationContext.getBean(
StructuredDocumentController.class);
This error doesn't happen if I comment out the aspect. I suspect it has something to do with Spring proxying the controller and then the controller class isn't identifiable by its class name. I've tried declaring the controller as a bean in applicationContext.xml but this doesn't help. This problem also occurs when running the tests in Eclipse, so it's not a problem with my Maven configuration.
My question is : how can I get the controller bean detected in the tests?
Would be really grateful for any help - is it wrong to add aspects to methods in controller classes? Should I disable aspects somehow when testing? (Although ideally I'd like to see in the integration tests that logging is working properly).
Thanks very much
Richard
Aspects are not the likely issue, you should be able to use them in the controller also without any problems.
My guess is that you are not loading up the correct context for your tests - how have you specified the application context to use for this test - is there #ContextConfiguration on your test class with the location, is the location to Root context(one specified through ContextLoaderListener) or Web application Context(one specified via DispatcherServlet).
Related
I'm trying to execute a unit test for a service class that has an #Async("asyncExecutor") annotated method. This is a plain JUnit test class with no Spring runners and no intention of using Spring at all in the unit test. I get the exception,
BeanFactory must be set on AnnotationAsyncExecutionAspect to access qualified executor 'asyncExecutor'
Where asyncExectuor is the name of the bean to be used during normal execution. My configuration class looks like this and I solved that previous error message at runtime by adding the mode = AdviceMode.ASPECTJ portion. This service works at runtime without issue in an Async way.
#Configuration
#EnableAsync(mode = AdviceMode.ASPECTJ)
public class AsyncConfiguration {
#Bean(name = "asyncExecutor")
public Executor asyncExecutor() {
...
}
}
I don't understand why the Spring context is being constructed at all in the unit test. The test class is simply annotated #Test on the methods with no class annotations and no mention of Spring. I was hoping to unit test this service class method as a regular method ignoring the async nature, but the annotation is being processed for some reason.
I'm contributing to a much larger gradle + Spring 4 project that I'm not fully knowledgeable about. Is there anything I should be looking for to see if a Spring context is being created by default for all tests?
As you noticed, Spring context is not loaded, that is the reason of your error. Try to initialize Spring context in your test by adding #RunWith and #ContextConfiguration annotations
Trying to register hystrix concurrency strategy fails after migrating to Spring-boot-2.0 with spring actuator enabled with java.lang.IllegalStateException stating that "Another strategy was already registered" . This is although I have not used registerConcurrencyStrategy anywhere else in my code.
I'd like to register concurrency strategy to carry-forward Log MDC context so that I'm able to log both within and outside the Hystrix wrapped method equally well, which includes thread-locals. And this used to work perfectly in spring-boot-1.5
After having migrated to spring-boot 2.0 (from 1.5), the HystrixPlugins.getInstance().registerConcurrencyStrategy(this); fails with IllegalStateException
As per https://github.com/Netflix/Hystrix/issues/1057, this issue can come if either (a) Any other code flow would have registered its own or default ConcurrencyStrategy before this is invoked (b) any call would have come via Hystrix before this is invoked
Since the above invocation is within the constructor of a class which is annotated with #Component, this should get invoked ideally before any method call happens (except initialization of other beans, including their constructors).
We even tried moving this code inside the SpringBoot Application Class's main method before invoking the SpringApplication.run(MyApplication.class, args); but that also didn't work
#Component
public class ContextCopyHystrixConcurrencyStrategy extends HystrixConcurrencyStrategy {
private static final String EVENT = "HystrixConcurrencyStrategy";
private static final String ACTION = "ContextCopy";
public ContextCopyHystrixConcurrencyStrategy(Logger logger, LoggerUtil defaultLoggerUtil) {
try {
HystrixPlugins.getInstance().registerConcurrencyStrategy(this);
} catch (IllegalStateException e) {
defaultLoggerUtil.logEvents(logger, Level.WARN, e.getMessage(), EVENT, ACTION, "", "Race condition! Could not register strategy. HystrixConcurrencyStrategy is already initialized.");
}
Expected: My registering should have happened before any other code and registering should have been successful
Actual: My registering fails with IllegalStateException
How do I make sure that my registering happens well before any other registering (which is not present in my code, but may be inside some of the libraries that I may be transitively using)
By default, Spring boot 2 accuator registers Hystrix Metric Binder beans which reset already set HystrixConcurrencyStrategy and sets HystrixConcurrencyStrategyDefault.
So, disabling that bean by
management.metrics.binders.hystrix.enabled=false
would help not resetting your custom HystrixConcurrencyStrategy
We took a close look at my maven .m2 directory classes and looked for registerConcurrencyStrategy inside all the classes in all the jars. And we found that
io.micrometer.core.instrument.binder.hystrix
was internally registering the HystrixConcurrencyStrategy with the default one.
And upon further research we found that setting the following property in application.properties:
management.metrics.binders.hystrix.enabled=false disabled the Hystrix Metrics Binder (I'm actually not sure what it does though!) and then things worked
I was using spring-boot-starter-parent v2.5.3 with Spring Cloud version 2020.0.3.
I had to manually include version for spring-cloud-starter-netflix-hystrix. I was getting "Another strategy was already registered" exception when starting my microservice. I included the
management.metrics.binders.hystrix.enabled=false
in the application.properties file and this issue got resolved.
I'm implementing an AOP-based caching layer similar to Spring Cache, and I'm having trouble getting my advice to execute when the joinpoint is called by another method in its own class. I was initially using Spring AOP's AspectJAutoProxy, and I understand why that doesn't allow for this use case, so I tried switching to AspectJ's load-time weaver, but it doesn't appear to have done anything. Here are all the details:
Spring version: 4.5.2
AspectJ version: 1.8.9
Java agent(s) added to run command. Note that I've tried including each of the two agents separately and together, without any difference in behavior:
-javaagent:/var/app/cops/jars/aspectjweaver-1.8.9.jar -javaagent:/var/app/cops/jars/spring-instrument-4.3.0.RELEASE.jar
Application entrypoint:
#Configuration
#EnableLoadTimeWeaving(aspectjWeaving = EnableLoadTimeWeaving.AspectJWeaving.ENABLED)
public class Application implements ApplicationContextAware {
#Bean
public InstrumentationLoadTimeWeaver loadTimeWeaver() throws Throwable {
InstrumentationLoadTimeWeaver loadTimeWeaver = new InstrumentationLoadTimeWeaver();
return loadTimeWeaver;
}
// Other unrelated beans
}
Advice signature:
#Around("#annotation(cacheable)")
public Object processCacheable(ProceedingJoinPoint joinPoint, Cacheable cacheable) throws Throwable
Method signature:
#Cacheable(key = "'test-key'")
public Map<String, Object> getDataFromSource()
"processCacheable" gets executed before "getDataFromSource" is called by another class, but still not if called from within the same class. Is there some configuration I'm missing in order to get LTW working correctly?
My usual disclaimer: I am not a Spring user. So I have next to zero experience with Spring configuration. But having looked at the weaving agent you put on your command line, I cannot find any AspectJ-related stuff in there. It is a really small JAR with only instrumenting classes that seem to rely on other transformers/weavers being deployed and somehow configured in your container.
I suggest you put the actual AspectJ weaving agent on your command line and see what happens. ;-)
Update: Or you if that does not help try both agents on the command line at the same time. I cannot tell you exactly what spring-instrument does, but I think it somehow integrates aspectjweaver (which does the actual aspect weaving) deeper into the Spring framework, even though AspectJ would also work without Spring even knowing of its existence.
In the example below, is there a way to avoid doing a context.getBean()? All the other beans subsequently used by the testService get autowired. (It is a console application)
public class Test {
private static ITestService testService;
private static ApplicationContext context;
public static void main(String[] args) {
context = new ClassPathXmlApplicationContext(
new String[]{"/META-INF/spring/app-context.xml"});
ITestService testService = context.getBean(ITestService.class);
}
}
I tried adding autowire annotation to ApplicationContext, but it didnt work. Besides how does it know where my app-context.xml is located if I autowire it?
Update: I found what I needed over here
Right, you're missing out a few details here.
Below is a short explanation of how Spring works.
1- The application context is loaded somehow (we will get there soon).
2- After loaded, app context will initialize/create all beans defined. Here is when beans get injected as dependencies. After this Whenever you get a bean back from the app context, that bean is all initialized and ready to go with all the dependencies in place (considering everything went fine).
RE the first step, there are a few way to automate the Spring initialization.
One way is what you are doing, explicitly instantiating one. Other way could be via a context listener in case you're in a web environment, or maybe with the #RunWith. (You can find more here)
In your case, I believe you are looking for using Spring in a (Unit?!?) test environment so you are looking for something like
#RunWith(SpringJUnit4ClassRunner.class)
#ContextConfiguration
public class MyTest {
#Autowired
private ApplicationContext applicationContext;
// class body...
}
further details here
http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#testing
You cannot call beans without initializing the application context first.
Secondly in your case Test class should be bean itself to be managed by spring then to autowire ITestService. The purpose of Application context as a container is to manage the bean lifecycle so u need to initialize it first by ClassPathXmlApplicationContextand then it will initialize all beans declared by you in ur xml file. About avoiding the getBean method if you are using servlets for creating web app you can avoid getBean. If not you should handle it manually.
I agree with what #Desorder has said. When I started working with #RunWith(SpringJUnit4ClassRunner.class) and #ContextConfiguration, I used to get my test cases working. But it took me some time to understand how these two are working internally and their default configurations.
If you would like to take some different approach and would like to try without #RunWith and #ContextConfiguration, take a look at the link - TUTORIAL: JUNIT #RULE. With this, you will be very clear which spring xml file locations are provided.
I'm having a problem whereby spring is re-creating my beans and re-auto wiring after each junit test has been run. I only want spring to do this once, on the post construct of the test class, which is what I've configured it to do.
I've also tried setting the #DirtiesContext class mode to AFTER_CLASS, but this still didn't solve the issue.
Any ideas?
Cheers.
You can create a class:
#SpringJUnitConfig(classes = {ConfigClassOne.class, ConfigClassTwo.class, ConfigClassThree.class})
public abstract class ModelTest {}
and extend it in the test classes. Beans will not be recreated because the application contexts are already mentioned in the annotation.