Rickard's AOP blog
Ok I was reading the rickard blog in Paris and bill wanted to defend but I said "just code" he is so beyond what we all do, the system AOP vision is extremelly clear, powerful, simple that I don't even want to put that burden of answering on him, just keep on leading I will deal with side casualties, I will deal with the blog noise, keep on koding...
:)
Rickard, first of all thanks for finally talking about technology, you are such a better read when you talk about tech than when you talk about people or politics. So thanks, at least it doesn't suck and we enjoy the feedback.
Onto the points.
1- XML mess
nah... you invoke QDoc, we invoke XDoc, we are trailing the solid simplicity of the dotnet
public void [simple-tag] doSomething() {}
everything else is plagiarism and bad copy... we still don't have that at the language level, I wish we did. I hear we can embed info in the classbyte since JVM 1.0? it should simplify even your configuration file mess.
2- the factories.
Bill says they are in fact optional and he was just showing the XML to make it clear.
3- J2EE security
J2EE declarative security has well known applications and limitations. Simply securing a Pojo would enable us to simply secure JNDI for example, ala weblogic, something we failed to do back when you were in 2.0. The long rant you propose would in fact be a one one mapping with the points from Scott Stark's work in JBoss... see proxy security in JBoss from 2.4 and up and context based stuff. That is what we have and offer to AOP, meaning that the point of J2EE declarative being not enough is false in the context of JBoss
4-. Introductions:
I understand introductions to be instrumentation of the POJO itself. If that is the case then we are talking about that and mostly that in fact in JBOss. See cache discussion. We instrument the reference itself. We offer both modes remote needs proxy and interceptors POJO needs introduction of interceptors in the instance. something we do dynamically to the object and which is completely missing from your presentation so far. We understand the limitations of interface/DP approach very clearly (there are many others such as difficulty of recursive implementation) anyway... POJO instrumentation and the separation between class and instance is absent from what I can tell in your stuff, whereas in the cache we are writing we instrument instances dynamically through the advisable interface. Check it out beautiful work.
5- XML indirection
creating logical indirection is a natural step for me. I did for you in fact when you submitted the JBoss2.0 prototype, you remember that you required users to specify the container stack in XML? for every component? i did the same remark to you as I did to bill, meaning that it is OK for a prototype but for 1st iteration we need defaults. I did it for JB2.0 and JBoss2.0 was a killer product.
OK, on the vision stuff...are you kidding?
you are ranting about application aspects like it is something new... it is old as Bill points out something that corba mapped out already, and in fact the advisable stuff (introductions?) is something that is already in CVS and being used in system level applications by us (cache, persistence, acid). The vision is very clear... we have system aspects and a nice list of them, that enables us to offer the power of J2EE services in a dotnet like develompent framework... how powerful is that. In JB5 we will see if dynamic composition of objects is something the masses are ready for (they may be but I am not seeing the need in system right now) so I will put my money on
future == system AOP + POJO application
whereas you are doing
future == POJO system + AOP application
as far as I can read.
I will accuse you of lack of vision my friend, Rickard is a dinausor.
PLgAOP
