techno.blog("Dion")

I seem to be in a battle with comment spammers.

I installed MT-Blacklist, which is great.

However I still get some annoying comments slip through the net.

I was talking with Cedric about this (since he uses MT too) and quickly hacked MT to NOT show any links, as that is what the comment spammers want (to have links back to their site… to try to fool Google).

So, I edited:

lib/MT/Template/Context.pm:

and changed the following:

sub _hdlr_comment_author_link {
sanitize_on($_[1]);
my($ctx, $args) = @_;
my $tag = $ctx->stash('tag');
my $c = $ctx->stash($tag =~ /Preview/ ? 'comment_preview' : 'comment')
or return $ctx->_no_comment_error('MT' . $tag);
my $name = $c->author;
$name = '' unless defined $name;
my $show_email = 1 unless exists $args->{show_email};
#    my $show_url = 1 unless exists $args->{show_url};
#    if ($show_url && $c->url) {
#        my $url = remove_html($c->url);
#        return sprintf qq(%s), $url, $name;
if ($show_email && $c->email) {
my $email = remove_html($c->email);
my $str = "mailto:" . $email;
$str = spam_protect($str) if $args->{'spam_protect'};
return sprintf qq(%s), $str, $name;
} else {
return $name;
}
}

I also edited the comment template to take out the URL field, since it isn’t used now.

Damn spammers.

Dion

Cedric has written an interesting post on AOP and annotations.

I think things are going to get a little hairy here.

The main problem is that we can start chasing out tail:

xml -> annotations -> aop to put in the annotations -> xml to define how aop puts in the annotations -> repeat

I think there is going to be some art when it comes to knowing WHEN to use annotations.

I don’t think that it makes sense to annotate on major cross cutting concerns. The obvious example is having to put @loggable on every method ;)

I guess annotations will allow you to tag some cross cutting concerns when they don’t fit the pattern. E.g. setterDogsAreNice(). There could be an annotation that lets the system know that this is NOT a property. However things get dicy.

We are all going to go hog-wild with the new shiny toy that is annotations. It is human nature :) Over time we will work out the subset of items that should use this style, and the areas in which you shouldn’t. Having code with a ratio of 100:1 annotations:code is going to happen, and it doesn’t seem to readable to me.

So I think there will be SOME marriage between AOP and annotations, and it will be interesting to find the balance. I mean, some annotations can be considered a cross-cutting concern ;)

*runs off after his tail*

Adrian Colyer has created a new blog.

His first post was on how you can use AspectJ to invoke AOPAlliance compliant interceptors (those from Spring, dynaop, etc).

Read Integrating AspectJ and AOP Alliance based aspects

I was taking part in the AOP panel discussion at last weeks TSS symposium, and listening to Rod Johnson and Bob Lee describe how dynaop and Spring can share aspects since they both implement the AOP Alliance interfaces. Sounds like both projects have some great aspects already written, and with more to come the obvious question crossed my mind: can I use aspects written to the AOP Alliance interfaces from within AspectJ?

A few hours later and I had a solution that lets you use the expressive power of AspectJ’s pointcut language to invoke advice (interceptors) written to the AOP Alliance interfaces, and to freely mix and match AspectJ and AOP Alliance advice in the same program, even applying at the same join points. Here’s how it looks…

Welcome Adrian.

I had a major refactoring project to do this week. Everything was tightly coupled, so the changes propogated through the code, view (JSPs and the like), xml config, and scripts.

Thanks to IntelliJ IDEA 4, it took care of the grunt work for me. I couldn’t believe that it really just worked :)

I spent more time trying to get CVS happy again as everything was moved around….. than on the refactoring itself.

I enjoy having the “Freedom” that you have when using a tool like this. It is nice to feel Agile ;)

Adrian Colyer, lead of the AspectJ team, was obviously a busy man on his flight back from Las Vegas to London.

He posted a message to the aspectj mailling list, which talks about a JoinPointMatcher. This class is built to handle dynamically working with join points a la:

JoinPointMatcher jpm = new JoinPointMatcher(”within(patterntesting..*)”);

He says more:

At any join point, you can ask JoinPointMatcher whether or not it matches:
if( jpm.matches(thisJoinPoint)) …

Here’s an aspect that allows runtime configuration using this mechanism:

aspect DynamicPointcutConstructionExample {

private static JoinPointMatcher jpm;

public void setPointcutExpression(String pointcutExpr) {
jpm = new JoinPointMatcher(pointcutExpr);
}

// this pointcut is used to narrow down as far as possible at compile time the set of places
// at which a dynamic pointcut could match (for efficiency)
pointcut scope() : within(org.xyz.foo);

before() : scope() && if(jpm.matches(thisJoinPoint)) {
System.out.println(”I matched!!”);
}

}

The consequence you pay for using dynamic pointcuts (I’m using the word dynamic in analogy to the use of “dynamic” in DII, it may not be the best
term) is that the pointcut matching is (very much) less efficient since the jpm.match code is driven for every join point in the scope (whereas the same pointcut specified at compile time would cause the advice to execute exactly where it needs to with no additional overhead or redundancy). If a dynamic pointcut proved to be too slow, you could always switch back to a traditional statically specified pc.

If you’re using Spring with the above example, you can configure the aspect with e.g.

"http://www.springframework.org/dtd/spring-beans.dtd">


class="DynamicPointcutConstructionExample"
factoryMethod="aspectOf">

execution(* *(..)) && this(Foo)

Spring will set the value of the pointcutExpression attribute when the aspect is constructed. Many thanks are due to Rod Johnson for the inspiration to look into this.

This is *very* cool stuff. I know that Vincent Massol has a need for this type of dynamic pointcut, and many others will be found. Of course, you want to NOT do things in this manner when possible for performance reasons etc…. but having the power to drop down to this when needed is fantastic.

Now all we need is to have the ability to write reusable aspect libraries and I will be a very happy man.

I went to see Howard Gardner speak at the Harvard Ed School on Changing Minds: The Art and Science of Changing Our Own and Other People’s Minds. This is the topic in his new book.

It was really interesting to learn about how to change someones mind (including your own).

He used many examples, including Margret Thatcher. It is interesting to learn about the techniques…. and to try to relate them to the my world.

Who in the tech industry is good at changing people’s minds? What happens to change the industries mind (e.g. movement from C -> C++).

One thing that wasn’t mentioned was the “backing the winner” phenomenon. It is always interesting how people want to jump on a particular bandwagon.

Scott Crawford has written up his thoughts on the EJB 3.0 process.

Scott is an independent member of the EJB expert group, and his thoughts are very interesting.

I agree with a lot of the comments that he made in his various articles on the topic, however I do dissagree (of course) with the following:

Since I am not a world expert on object persistence but I do want to do the right thing I listen carefully to these arguments. But I also try to take a step back and look at the big picture. A persuasive point for me is to consider the fundamental design goals of JDO and of the O/R tools. One of JDO

Rickard is talking about how to implement domain models in AOP which includes both behaviour and state.

Although some blogs mentioned being tired of AOP from the symposium… this wasn’t the norm.

I had ~40 or 50 people come up to me at the symposium…. all saying that they are going to take a close look at AOP (after the various talks). Even at an event like TSSS, with high caliber people, the majority of people have only heard of the term AOP. A small percentage have really started to play with it.

This actually makes presenting on AOP at this type of event tough. The baseline is across the board. You have people like Sam Pullara in the audience…. and then of course Gregor and Adrian :)

The aim was to spread the word… show people some of the things that you can do, and hopefully they will pick up a book… download a framework… and start to play a little. If that happens, we have a win.

There has obviously been a lot of buzz that cropped up after the EJB 3 announcement at TheServerSide Java Symposium. On the one hand, it is very impressive that the JCP is making a bold move…. and really trying to make EJB simpler to develop. Although it is great to see this happen, I can’t help but find myself confused when it comes to the persistence side of the equation.

JDO vs. EJB: Technical differences

There are a few technical differences between what looks to be in EJB 3 (which is still in VERY early stages by the way… and who knows when IBM will wake up ;). Gavin blogged about some of the issues he has with JDO, and I appreciate him coming out in public. I think it is really important to have these discussions in the open, and we are very lucky here with Gavin.

However, if you look at the points raised (e.g. JDO-QL isn’t as he likes, and persistence-by-reachability), I think they are fairly minor. Both JDO 2 and EJB 3 are not finished, however if you look at the features sets as they stand today, you will see many more similarities than differences. They are SO close that it isn’t even funny. In fact, they are so close that I don’t understand why Gavin and Oracle (who announced they are leaving the JDO expert group by the way) wouldn’t want to discuss them more. I know the expert group has really enjoyed having both of those parties involved, and together the java-persistence world is a great force.

So, the technical discussions between JDO and EJB have started. I hope they continue. However, I am actually more concerned about looking at the forests instead of the trees.

Do one thing. Keep it loosely coupled. Do it well

I really do not understand why persistence has ever been coupled to EJB. Persistence is a cross-cutting concern, that needs to be solved in AND out of the enterprise.

Let’s take a look at two alternate universes:

1. JDO and EJB working together

Imagine if the persistence experts from both the EJB side, and the JDO side all got together. JDO would become a fantastic persistence standard (in fact I think JDO 2.0 already is…). From the EJB world, we would make sure that JDO is written in such a way that it fits in perfectly with the needs from that side of the house. JDO has always tried to do this (working with J2EE CA, EJB transaction model, etc)…. and I think it is very important.

So, now we have a top class persistence spec, which would be ready to roll pretty darn quickly. EJB 3.0 can now get rid of ALL of the entity baggage (what is the % of the spec?). They can focus on making the programming model lean and mean. Session beans will be so clean to write, Message Driven beans a pleasure, and we have a chance to handle more. EJB should be all about transaction processing, and handling true enterprise needs. Now the expert group can spend time on a half decent security model, a nice thread worker pool for the times in which you need them, an interceptor stack, and things the enterprise truly needs.

Wow, as I type this I feel happier. Wouldn’t this all be great? Wouldn’t this be something we could be proud of? Now if you say “I use EJB” people say “I am so sorry”. In this alternate universe that would disappear. Let’s get back to the current real world though :(

2. JDO and EJB fighting, or ignoring each other

As it looks right now, we have two separate camps. There will be infighting between them. Developers will find it hard to choose which technology to use on their project. If an application isn’t an enterprise application they can simply plug into JDO. Then imagine if they want to migrate it to an enterprise app… would they want to change it to EJB 3?

Why wouldn’t you want universe #1?

I am finding it really hard to understand what sane person wouldn’t vote for universe #1. Please correct me if I am wrong here, but are there any technical reasons for this?

The only reason I can come up with is political: Vendors want the lock-in that they get with the current tight coupling of their persistence engines to their EJB container

Take a look at the EJB specs, and how:

(EJB 2.0 spec, page 509)

“We plan to provide the following in future releases of the EJB specification:

- specification for the pluggability of Persistence Managers

Why has this been on the list for all of time with respect to EJB? Isn’t it time to get around to this yet? I worry that the only reason is that vendors are scared. They want their container to be tightly coupled to their persistence engine. This actually seems so bizarre to me. I think it would be in the vendors interest to open this up. At one time the CMP engine was a main differentiator. Now we have moved up the stack, and there are plenty of others areas. The application server is becoming a commodity, so lets open up the bad boy and move on.

If we were writing code that tightly coupled items such as business objects with persistence, we would make fun of ourselves.

Let’s go for a brave new world

I really hope we end up at universe #1 one day. At this point the EJB spec will just be a standardization of some enterprise services. When it makes sense, sub-specs can be created allowing us to divide and conquer. We can work on the sub-parts in parallel, and experts in those areas can work on doing the best job they can.

I have been honored to work with the JDO expert group members. There are too many of them who are far too knowledgeable of the world of transparent persistence, and ORM, to not be part of the biggest effort.

As Marc Fleury himself would say… let’s take the red pill ;)

Wow, what a busy few days in Vegas for TheServerSide Java Symposium. It feels like one loooooong day, with time running so fast, and the casino showing you constant daylight.

It was interesting to see the show grow from last year. It is really all about the people. The entire community makes this event what it is. If you looked around the event you see:

• Talks: The presentations were quality, and by smart people
• Collaboration: It was so great to see people from various companies, and open source projects, coming together to discuss things. As good as the talks are… it is this collaboration which makes the event so much more. Here you can see Spring, Dynaop, and AspectJ leaders talk about issues and techniques that the employ within AOP (or should I just be saying AO now too ;). Various frameworks discuss how they can leverage eachother…. how best to plug together…. and generally play nice. It also gives the users a chance to talk to the project leads on apps that they are using day in, day out. This feedback loop is so important. This was shown by the JCP, and how keen they were to listen (thanks Onno and company).

Let’s face it. You can’t beat face to face communication. Having a beer with someone, and connecting with them in general does wonders. When you are emailing eachother you can picture the other end. You *get* who they are a little more.

Anyway, I was really excited to see the community together. Thanks for making it all happen. I look forward to seeing you all next year!