In order to avoid database connection leaks, it's possible to configure c3p0 to let you know when they occur, and point to the problem code:
<property name="unreturnedConnectionTimeout" value="900"/> <!-- seconds -->
<property name="debugUnreturnedConnectionStackTraces" value="true"/>
It'd be better to catch these before they are ever deployed. That is, catch them statically at build time. It seems that it would possible to 1) Identify classes that are DAO-type classes, either annotated as such or via an hbm file, and then 2) trace call trees upward and flag methods that are not marked #Transactional. Even if there were some false positives, that'd be a useful tool to help eliminate this issue. IDEs such as IntelliJ and Eclipse already know how to find a method's callers.
Is there an opensource tool that does something like this? Even if it didn't do the first step, it's easy enough to identify DAOs manually. It's the second part that would benefit most from an automated solution.
I faced a similar problem in a Spring application, and wrote a bean processer that ran at application startup, and examined each bean after it was initialized. It's not a compile-time solution, but assuming you run the application somewhere before production, you'll have an opportunity to find methods lacking the annotation in question.
It looked for classes with the #Service annotation, iterated over interfaces implemented by that class, and inspected each interface's methods. It looked for methods that either didn't have any method-level security defined, or had a custom #Unsecured annotation, indicating we had already discovered that method lacked security but determined that it didn't need security. Any methods that lacked security and the #Unsecured annotation were logged.
The following code worked at one point, but was used with an older version of Spring. I don't know if it will work with Spring 3.x, but if not, a similar approach should still work. You might need to adjust the inspection logic to suite your needs (e.g. look for classes with a different class-level annotation, inspect methods on the class itself instead of methods in interfaces implemented by the class, etc). Note that my approach didn't try to traverse call trees, so you'd probably get more false positives (i.e. not all service methods end up calling DAO methods).
public class UnsecuredServiceMethodProcessor implements BeanPostProcessor {
private static final Logger logger = LogManager.getLogger(UnsecuredServiceMethodProcessor.class);
private final MethodSecurityInterceptor interceptor;
public UnsecuredServiceMethodProcessor(MethodSecurityInterceptor interceptor) {
this.interceptor = interceptor;
}
#Override
public Object postProcessAfterInitialization(Object bean, String beanName)
throws BeansException {
Class<?> beanClass = bean.getClass();
if (logger.isInfoEnabled()) {
logger.info("checking bean " + beanName + " of type " + beanClass.getName());
}
for (Class<?> interfaceClass: beanClass.getInterfaces()) {
checkClass(beanClass, interfaceClass);
}
return bean;
}
/**
* #param beanClass
* #param interfaceClass
*/
private void checkClass(Class<?> beanClass, Class<?> interfaceClass) {
if (interfaceClass.isAnnotationPresent(Service.class)) {
if (logger.isDebugEnabled()) {
logger.debug("found service implementation: " + interfaceClass + " on " + beanClass);
}
for (Method method: interfaceClass.getMethods()) {
if (!method.isAnnotationPresent(Unsecured.class)) {
if (logger.isDebugEnabled()) {
logger.debug("checking " + method.getName());
}
MethodSecurityMetadataSource msms = interceptor.getSecurityMetadataSource();
Collection<ConfigAttribute> atts = msms.getAttributes(method, interfaceClass);
if (atts == null || atts.size() == 0) {
logger.warn("unsecured method: " + method.getDeclaringClass().getName() + "." + method.getName());
}
}
}
}
}
#Override
public Object postProcessBeforeInitialization(Object bean, String beanName)
throws BeansException {
return bean;
}
}
You'll need to either explicitly define a bean of this type in the application context, or add the #Component class-level annotation and scan for it.
Related
I am pretty new to Spring Boot and its flavor of AOP, but not new to programming in other languages and AOP frameworks. This one challenge I am not sure how to solve.
I have a simple metadata decorator:
#Target(ElementType.TYPE)
#Retention(RetentionPolicy.RUNTIME)
public #interface GreetingsMeta {
public float version() default 0;
public String name() default "";
}
It works just fine with dependency injection:
public GreetingController(List<IGreetingService> greetings) throws Exception {
this.greetings = new HashMap<>();
greetings.forEach(m -> {
Class<?> clazz = m.getClass();
if (clazz.isAnnotationPresent(GreetingsMeta.class)) {
GreetingsMeta[] s = clazz.getAnnotationsByType(GreetingsMeta.class);
this.greetings.put(s[0].name(), m);
}
});
}
Until I applied a standard logging aspect:
#Aspect
#Component
public class LoggingAspect {
#Around("execution(* com.firm..*(..)))")
public Object profileAllMethods(ProceedingJoinPoint joinPoint) throws Throwable {
MethodSignature methodSignature = (MethodSignature) joinPoint.getSignature();
String methodName = methodSignature.getName();
final StopWatch stopWatch = new StopWatch();
stopWatch.start();
Object result = joinPoint.proceed();
stopWatch.stop();
LogManager.getLogger(methodSignature.getDeclaringType())
.info(methodName + " " + (stopWatch.getTotalTimeSeconds() * 1000) + " µs");
return result;
}
}
Then the list of annotationsData becomes empty, even the #Component annotation is gone.
Sample meta-decorated class:
#Component
#GreetingsMeta(name = "Default", version = 1.0f)
public class DefaultGreetingsService implements IGreetingService {
#Override
public String message(String content) {
return "Hello, " + content;
}
}
How should I troubleshoot?
How do I prevent Spring Boot AOP from removing type annotations?
Spring Boot does not remove anything, but for Spring AOP is uses dynamic proxies generated during runtime, i.e. subclasses or interface implementations with event hooks (joinpoints) for aspect advice code wired in via pointcuts. By default, annotations are not inherited, so this is just a JVM feature.
There is one exception for subclasses inheriting annotations from parent classes: You can add the meta annotation #Inherited to your own annotation class GreetingsMeta. The effect will be that if you annotate any class with it, all subclasses (also dynamic proxies created by Spring AOP) will inherit the annotation and your original code should run as expected.
So in this case there is no need to use AnnotationUtils as suggested by JC Carrillo. His approach works too, of course. It is just more complicated because AnnotationUtils uses a lot of reflection magic and lots of helper classes internally in order to compute results. Thus, I would only use AnnotationUtils in cases where you don't directly annotate a class but e.g. methods or interfaces because #Inherited has no effect on them as documented. Or if you rely on a hierarchy of Spring (or own) meta annotations (annotations on annotations) and you need to get information from them all merged into one, AnnotationUtils or MergedAnnotations are appropriate.
You may want to look into AnnotationUtils
Method method = methodSignature.getMethod();
GreetingsMeta greetingsMeta = AnnotationUtils.findAnnotation(method, GreetingsMeta.class);
#Transactional(isolation = Isolation.SERIALIZABLE)
I have that annotation on several methods in my spring project. If there is an exception due to the "serialize access problems" what is the best approach if I want to retry the specific transaction. There is annotation #Retryable but it is not very straightforward to me how to use it so that the transaction will rollback and then retry only for that specific exception and just rollback for the other runtime exceptions. Thanks in advance.
A simple solution is to have a method that is the "entry point" for performing your logic; which delegates the actual logic to a transactional method. Typically a nice way of doing this is to have one class that has the Transactional annotations and that does the work and another which is the interface for clients to interact with that delegates; providing a form of indirection.
private static final int MAX_RETRY = 5;
public void doWork(T... parameters) {
doWork(0, parameters);
}
private void doWork(int retryLevel, T... parameters) {
if (retryLevel == MAX_RETRY) {
throw new MaximumRetryCountException(); //or any other exception
} else {
try {
//Get your Spring context through whatever method you usually use
AppContext().getInstance().getBean(classInterestedIn.class).doTransactionalMethod(parameters);
} catch (ExceptionToRetryFor e) {
doWork((retryLevel + 1), parameters);
}
}
}
#Transactional(isolation = Isolation.SERIALIZABLE)
public void doTransactionalMethod(parameters) {
...
}
Please note you may run into problems calling a Transactional method from a different method within that same class (i.e. calling this.doTransactionalMethod()) hence the invocation of Transactional Method is through the Spring Application Context. This is due to the way Spring AOP wraps classes to engage transactional semantics. See: Spring #Transaction method call by the method within the same class, does not work?
In my Spring application, I have components that use Spring's caching mechanism. Each #Cacheable annotation specifies the cache that is to be used. I'd like to autodiscover all the caches that are needed at startup so that they can be automatically configured.
The simplest approach seemed to create a marker interface (ex: CacheUser) to be used by each caching component:
#Component
public class ComponentA implements CacheUser {
#Cacheable("dictionaryCache")
public String getDefinition(String word) {
...
}
}
I would then have Spring autodiscover all the implementations of this interface and autowire them to a configuration list that can be used when configuring the cache manager(s). This works.
#Autowired
private Optional<List<CacheUser>> cacheUsers;
My plan was to take each discovered class and find all methods annotated with #Cacheable. From there I would access the annotation's properties and obtain the cache name. I'm using AnnotationUtils.findAnnotation() to get the annotation declaration.
That's where the plan falls apart. Spring actually wires proxies instead of the raw component, and the annotations aren't copied over to the proxies' methods. The only workaround I've found exploits the fact that the proxy implements Advised which provides access to the proxied class:
((Advised)proxy).getTargetSource().getTargetClass().getMethods()
From there I can get the original annotations, but this approach is clearly brittle.
So two questions, really:
Is there a better way to get to the annotations defined by the proxied class?
Can you suggest any other way to discover all uses of #Cacheable in my project? I'd love to do without a marker interface.
Thanks!
Spring has a lot of infrastructure interfaces which can help you tap into the lifecycle of the container and/or beans. For your purpose you want to use a BeanPostProcessor and the SmartInitializingSingleton.
The BeanPostProcessor will get a callback for all the beans constructed, you will only need to implement the the postProcessAfterInitialization method. You can in that method detect the annotations and fill a list of caches.
Then in the SmartInitializingSingletons afterSingletonsInstantiated method you use this list to bootstrap/init your caches.
Something like the following (it is untested but should give you an idea).
public class CacheInitialingProcessor implements BeanPostProcessor, SmartInitializingSingleton {
private final Set<String> caches = new HashSet<String>();
#Override
public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
return bean;
}
#Override
public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
Class<?> targetClass = AopUtils.getTargetClass(bean);
ReflectionUtils.doWithMethods(targetClass, new ReflectionUtils.MethodCallback() {
#Override
public void doWith(Method method) throws IllegalArgumentException, IllegalAccessException {
Cacheable cacheable = AnnotationUtils.getAnnotation(method, Cacheable.class);
if (cacheable != null) {
caches.addAll(Arrays.asList(cacheable.cacheNames()));
}
}
});
return bean;
}
#Override
public void afterSingletonsInstantiated() {
for (String cache : caches) {
// inti caches.
}
}
}
As far as I know, in Spring AOP when we want some method call to be intercepted, we configure an Aspect having such a pointcut configuration that matches wanted method invocation. In other words, we configure interception on the Aspect side.
Is there a way to configure it entirely from the opposite side, that is, on method which invocation is to be intercepted? I expect that something like this is possible:
#Component
class MyClass {
#Intercept(interctptor="myInterceptor", method="invoke")
Object methodThatWillBeIntercepted(Object arg) {
// ..
}
}
#Component(value="myInterceptor")
class MyInterceptor {
Object invoke(MethodInvocation mi) {
// ...
if (someCondition) {
return mi.proceed();
} else {
return someOtherValue;
}
}
}
You can, at least if you're using it with AspectJ. You can use the syntax #annotation(com.mycompany.MyAnnotation) in your pointcut declaration to target elements that are annotated with your annotation. You can read more about it in section 9.2.3 of the Spring reference documentation
If you're not using AspectJ, but a generic proxy based interceptor, a "brute force" approact would be to proxy all the object you want to check and then check the method invocation argument to see if the method is annotated with your annotation, something like this:
class MyInterceptor {
public Object invoke(MethodInvocation mi) {
if(mi.getMethod().getAnnotation(MyAnnotationClass.class) != null) {
// Do the interception
}
else {
return mi.proceed();
}
}
}
Don't remember the exact API for MethodInvocation, but something like that.
What would be a somewhat equivalent class for TransactionScope(.Net) in Spring.
I know absolutely nothing about .Net, so I'm not certain if this is what you're looking for. You can use SimpleTransactionScope in order to maintain objects across the lifecycle of a transaction. It is not registered by default, so you will have to register it with spring core like any custom scope, and give it a stringy name. Then if you want you can also create an annotation specifically to register one.
It was my issue that suggested this a few years ago, after this question was created for certain. We requested it specifically for timestamps across multiple methods for injection in a service. You can do something like this.
public class SimpleTransactionFactoryPostProcessor implements BeanFactoryPostProcessor {
#Override
public void postProcessBeanFactory(ConfigurableListableBeanFactory factory) throws BeansException {
factory.registerScope("transaction", new SimpleTransactionScope());
}
}
#Configuration
class MyConfiguration {
#Scope(scopeName = "transaction")
#Bean
Instant nowInstant() {
return Instant.now();
}
}
#Service
class MyService {
private final ObjectFactory<Instant> nowFactory;
MyService( #Qualifier("nowInstant") ObjectFactory<Instant> nowFactory ) {
this.nowFactory = nowfactory
}
#Transactional
public boolean nowisEqualAlways() {
var now = nowFactory.getObject();
var sameNow = nowFactory.getObject();
return Objects.equals( now, sameNow );
}
}
If you don't do this, your now could actually change during your transaction by a small amount of time. You can test that simply by spamming now calls in a test.
It may not be required for your needs, so it's hard for me to tell (obviously your needs are probably long past, hopeful.y this helps someone in the future though)
The #Transactional annotation looks equivalent.
This can be placed on classes and methods and can be defined with propagation, isolation, rollback etc.