We Keep Coding

ProxyBeanMethods in Spring

Can someone give a real case example of how using boolean element proxyBeanMethods is going to change how the application's bean interact with one another ? From my understand setting proxyBeanMethods to false is similiar to using #Lazy annotation on the dependencies of a bean in which those dependencies will only be created once the methods that return them are called therefore improve the startup speed. Is there anything I'm missing ?

It isn't the same as #Lazy and this is also explained in the javadoc of the property.
The default is true meaning each #Bean method will get proxied through CgLib. Each call to the method will pass through the proxy and assuming singleton scoped beans, it will return the same instance each time the method is called.
When setting it to false no such proxy method will be created and each call to the method will create a new instance of the bean. It will act just as a factory method. This is basically the same as the so called Bean Lite Mode, or #Bean methods on non-#Configuration annotated classes.
Now the latter isn't the same as #Lazy which will only defer the construction to the moment it is needed.

Disable Transaction for specific method

I'm using a Interface with #Transaction, and I have a method that performs a loop and check some information, but this loop takes long time to finish it, and i added a parameter in the database. And inside of the loop, is checked the parameter, and if is equal true, the loop will stop.
My problem is at the moment that check the parameter, it not get the parameter updated, it keep with the old value of the parameter.
is there a way to keep the transaction on interface and disable for specific method?

Try to split in two your method and you put "Requires new" on that check the parameters, in order to create a new transaction and suspend the current transaction if one exists.
#Transactional(propagation = Propagation.REQUIRES_NEW)
I hope I've given you all the answers about your question.

The first thing is undestand why you are using #Transaction on interfaces, beacause the correct way is to annote concrete classes (and methods of concrete classes) with the #Transactional annotation.
From spring references documentation:
Spring recommends that you only annotate concrete classes (and methods of concrete classes) with the #Transactional annotation, as opposed to annotating interfaces. You certainly can place the #Transactional annotation on an interface (or an interface method), but this works only as you would expect it to if you are using interface-based proxies. The fact that Java annotations are not inherited from interfaces means that if you are using class-based proxies ( proxy-target-class="true") or the weaving-based aspect ( mode="aspectj"), then the transaction settings are not recognized by the proxying and weaving infrastructure, and the object will not be wrapped in a transactional proxy, which would be decidedly bad.
Then can you share your code with us?

How exactly does Spring inject properties when annotating with #Value?

I've been wondering: how exactly does Spring inject properties when using the #Value annotation? What's the mechanism behind this that checks if a field has the annotation? Is it using reflection and some class that finds all annotated classes and creates an instance of them injecting the property, or is it doing it some other way? I know annotation processing would only be used during compilation and will not change the code, so what's happening behind the scenes here really...?
Thanks in advance!

The #Value annotation type has the #Retention(value=RUNTIME) annotation, which means that the information is available at runtime (i.e. using reflection).
A BeanPostProcessor, in particular the AutowiredAnnotationBeanPostProcessor can check for the presence of this annotation on fields, methods or constructors of a bean after instantiation.

If annotation-config feature is on then each time Spring instantiates a bean it goes thru all of its fields and methods and checks if they are annotated with one of Spring supported annotations using reflection.

Spring #Transactional class vs method precedence rules

Spring says abuot #Transactional
The most derived location takes precedence when evaluating the transactional settings for a method.
Does this mean the annotation on method completely overrides annotation from class or does the omitted attributes (so defaults) does not count?
E.g.
#Transactional(isolation=Isolation.SERIALIZABLE)
public class MyService {
#Transactional(readOnly=true)
public void method() {
...
}
}
So what is the isolation settings of the method? Is this Isolation.DEFAULT because this is the default so it implicitly overrides Isolation.SERIALIZABLE or is it Isolation.SERIALIZABLE because none was explicitly specified on method annotation?

The annotation at the method level completely overrides the annotation at the type-level. Any kind of hierarchy is not quite possible here. Let me explain a little more. There is no way to find out if a value was specified by the user for a specific attribute, or if a default value is being returned when you read the attributes of an annotation. So, Spring, or anybody else, cannot determine whether a specific attribute was overridden, or if a default value is being used. So, there is no way to make a decision based on the presence or absence of an attribute. For that reason, whenever you override any annotation (that is, specify it with finer granularity), you need to specify all the required attributes. So, in your case, the Isolation.DEFAULT will be the isolation applied.
However, as a aside, suppose you have your own custom annotation that specifies an empty-string as the default value for some attribute. In that case, if your class-level annotation specifies a non-empty string for that attribute, and your method-level annotation doesn't specify any value (thus using the default value: the empty-string), you could infer that the attribute-value from the class-level annotation should be used. That is, not allowing the default-value in the method-level annotation to override the user-specified value at the class-level. In any such scenario, you have to be sure that the default-value doesn't represent a valid attribute-value. In the case of the #Transactional annotations, Isolation.DEFAULT does represent a valid value and it may have been explicitly be specified by the user.

Spring getter and setter dependent?

I would like to make sure if I understand this correctly. Spring needs a setter to inject a field reference? Couldn't it do it by just detecting it as a public field?
Is there an alternative to this. From what I understand Java EE's #Inject annotation can do this without any problem. But I have always been inclined more to Spring.

This depends on how you're creating your bean. Spring does not require setters. There are a number of other ways:
Autowiring (with or without Qualifiers) via annotation at the field level
Constructor injection (either by xml or annotations in the code)
Public fields (as you suggested) might work, though i have never tried it, and would advise against it even if it does.
Unfortunately, the XML approach does not look into private fields (that i know of). You either need to add a setter, use the constructor, or set up some sort of autowiring.
Keep in mind, autowiring can be combined with XML. Spring will pay attention to your wiring annotations even if you create your bean via xml (as opposed to something like #Component and component scanning).

It is not necessary to have Setter to inject a reference, you can use Autowire on a public variable of a class or on the setter method, u can also inject beans using constructor-arg which is a good way of injecting dependencies and autowiring can be done on Constructors also. #inject also does the same functionality as #autowired, however #Autowired has an additional behaviour where it internally also uses #required attribute, to see if the bean has a references and injected properly.

Spring provides several alternatives for DI besides setter injection. For example, you can use constructor injection. Alternatively, you can use Spring's #Autowired annotation for constructor, field or setter injection. Since you mentioned it, I guess that you would also be interested in knowing that Spring supports the #Inject annotation.