@Annotation based questions (JSR-250)

[node159]

We're loving the annotation based configuration but have a few queries relating to behavior and best practices.

* Is it a good idea to use a explicit ‘name’ on all annotations, or is this just wasted energy? i.e. depend on automatic type matching, or does this get you into deep trouble on large projects? I'm very interested in peoples experience with this, particularly since we have a 'large' project we want to slowly convert to remove the megabytes of xml files we have currently

* Is ‘@Transactional(readOnly = true)’ more trouble than it’s worth? Since it doesn’t throw exception for the common case (only for modification of sets), it seems like it would often lead non-inutive situations with weird bugs, i.e. expecting a method to write but no write happening.

* Is it a problem to apply for example the @Service annotation on a class and then to define the bean in XML? We want to use annotation configuration for everything but have a few beans that require settings to be set on them using a property placeholder.

* Setter or instance variable for @Resource annotation? Is there any difference, or should one be preferred over the other?

* Is @Required implicit in for @Resource annotation? As in, its not need, seems logical but would like it confirmed.

* Finally, why do people insist on doing this?

@Aspect
public class BusinessProfiler {

        @Pointcut("execution(* com.example.spring.aop.*.*(..))")
        public void businessMethods() { }

        @Around("businessMethods()")
        public Object profile(ProceedingJoinPoint pjp) throws Throwable {
        …

Doesn’t this just create a proxy, and then add a proxy to go around that?

[Marten Deinum]

Well my 2ct here.

I wouldn't put names in annotations like @Autowired that basically means you either know all the bean names and don't trust autowiring, next to that that also means that each @Component needs to have the correct name. When it comes to testing this can be trouble some.

readonly transactions especially with ORM is a plus. It improves performance as no dirty checks need to be done.

You can mix all kinds of annotations so there is no problem unless you use component scanning then take into account that you need to exclude that bean from being scanned.

When using annotations I tend to put them on instance variables, that way you have all the configuration annotations on top of the class and it saves all the setters reducing your code by 3 lines per variable.


Regarding the aspect I suggest you re-read the aspects chapter as your understanding is quite off. There is no proxy created for @Aspect, the @Aspect is merely the configuration used to create the proxy (as you could also do in xml). What you show here is a named pointcut.

[node159]

Thank you for your feedback.

For the last point, I'm refering to the setting a cutpoint for all com.example.spring.aop.*, that directs to method 'businessMethods' which is empty and has an around set on it that invokes method 'profile'. Why not just set the around on com.example.spring.aop.* ?

[Marten Deinum]

As I stated it is a named pointcut. Imagine that you want to do 4 things on the com.example.spring.aop.* package. WIth a named pointcut you have simply refer it once, without it you would have to write (probably sloppy/paste) it 4 times. Named pointcuts enable reuse. (That is why I suggested reading the AOP chapter as it is explained there).

Also your understanding is wrong, there is no method calling another method at runtime it directly invokes profile there is no indirection/redirection what so ever. I suggest reading AspectJ in Action which explains all this in depth.