> I thought about creating a EntityBean Aspect to not require to use the ebean weaver
Thats interesting...
> I'd suggest to use AspectJ as there is already IDE support ...
To be honest I'm very happy using ASM... yes its a low level ("bare metal") approach ... but it means I have full control over the final byte code.
> also a maven task for compile-time weaving.
I think of ant/maven enhancement tasks as "build" time weaving... and I'd put the Eclipse Ebean plugin (that adds enhancement on save in eclipse... as "compile-time" weaving.
The Ant/Maven tasks really are relatively easy - yes I should have a maven enhancement task... I actually think someone already has done that.
If you would like to, I can donate the created aspect for PropertyChangeSupport to Avaje.
Yes, that could be interesting... but note the current Ebean entity enhancement already gets close due to "dirty" checking on setters etc. That is, there is already EntityBeanIntercept.preSetter(propName, newValue, oldValue) called ... so I'd probably be better off just hooking that into PropertyChangeSupport.
... but I would be very interested to see what exactly you are doing there ... and whether it is a good idea to support that with Ebean's current ASM based enhancement.
> I think if one is doing AOP it will be done with AspectJ
IMO it depends on who the "one" is... I think using ASM directly (as I do with Ebean and as Toplink/Eclipselink do) is great for framework type development because of the level of control you get... and because the AOP/Enhancement is well defined.
... with AOP for application development (rather than framework development)... I could imagine you want to use something higher level than ASM.
... but yes, I'm very happy using ASM - I think it is fantastic.