the zip file has a Maven pom in it. Running 'mvc eclipse:eclipse' on the command line will create an Eclipse project for you. I won't have time anywhere in the coming weeks / months to create an Eclipse web app for you, so you'll have to that yourself.

cheers,
Alef

Thank you very much for your quick response.

After further thoughts, this is the Proxy-based approach that is annoying me. It makes Spring slightly more intrusive because I need it systematically to create new object instances and I have to implement ApplicationContextAware more often. Now, is it really annoying ? No, the added value of using Spring is certainly much greater…

I see two main drawbacks with the proxy-based approach:

How can I be sure I can use Spring every where ? In the case of JPA, I'm not sure I can…
The equals() contract is broken (a.equals(b) but !b.equals(a)). In a nutshell, the equals() method implemented by the advised object makes an unadvised object (with exactly the same values and same underlying class) different (in my example, 'a' is the unadvised object and 'b' is my advised object). In the case of the @NotNull, that's a pity.

As you suggest, using AspectJ and its bytecode-manipulation capabilities could solve that.
Ah, I feel you want to do a second @NotNull with this approach
Regards,
Stéphane.

as for your first question, yes, you would have to use Spring. It's your own choice as to how negative a side effect you think that is. To my mind it's just as negative a side effect as having to use a JVM to run Java-based programs and just as negative a side effect as having to use Spring (or EJB3) for that matter to use @Transactional to demarcate your transactions. Again, it's up to you to decide what your feeling about this is, I won't force you ;-).

I don't fully understand the equals() issue. I don't consider this to be a big problem. Spring AOP is designed to apply behavior to services (DAOs, repositories, business services, et cetera) and I don't consider equals methods in those objects to be of real importance. You do have a point about the factory methods and domain objects and their respective equals methods. The recommended approach here would be to start using AspectJ, which removed any of the drawbacks that Advised (i.e. a proxy-based approach) has.

I hope this helps. Please don't hesitate to drop by again and ask for more clarification.

regards,
Alef

Using Annotations and AOP is a very interesting approach in order to extend the language. But I have some troubles with this approach anyway:
* In this example, if I want to take advantage of this annotation, I HAVE to use Spring every time and everywhere I need to access my objects, because they need to be advised by Spring. If not, the @NotNull will be useless.
* Another problem is that AOP breaks equals() method: myObject.equals(Advised(myObject)) will be true while Advised(myObject).equals(myObject) will be false. This is very annoying because, again, I have to guarantee that Spring will be used everywhere to create my objects. But can I guarantee that ?
What if I use JPA/Hibernate in order to persist my data ? Mapping files demand a concrete class (thus, a non-advised)..unless I can define a factory method ?

Did I miss something ?

Thanks for your help !

Yes, this convention is something I didn't know about either until a few months ago when Ben Alex pointed it out to me.

glad you liked it.

cheers,
Alef