[]
EJB 3 Interceptors: Finally! Or...?
[ tirsen ] 23:27, Wednesday, 9 February 2005

Ok, so the EJB team has finally understood the value of supporting custom interceptors. For some reason they can't avoid the temptation to put in some ludicrous limitation making it way less useful than it could've been. This time they've decided that entity beans doesn't need interceptors. So the following (incomplete) list of applications is according to the EJB spec committee pointless and unnecessary:


  • Fine-grained data-based access control (this person can see this data, this person can't see this data)
  • Data-based audit logging (create date/who, modified date/who, etc)
  • Indexing (reindex this data when modified)
  • Messaging (send me an email when this data has changed)

Personally I've been to few projects that doesn't need one or more of the above things. (And implemented them in more or less elegant ways, the more elegant ways have always been some type of interception on domain object level, be it Hibernate interceptors, bytecode magic, dynamic proxies or full-blown AOP.)

EJB 3... Still not impressed.

Oh well...

Update: Gavin King points out that EJB 3 supports entity callbacks which can be used to implement parts of the above list. I'm not sure about all of them though. What about data-based access control?


Comments

This is of course all totally wrong.

POJO-based persistence solutions today (Hibernate, JDO) don't have method level interception. Instead they have a callback model based upon CRUD operations (eg. Hibernate Interceptor interface, which is *not* an "Interceptor" in the sense of the EJB spec).

The EJB persistence spec supports entity callback listeners which work just like a Hibernate Interceptor and let you do all the things you just mentioned. And yes, I pushed really damn hard to get this stuff in the spec 'cos I know just how important it is from our experience with Hibernate.

Please pay better attention before slamming other people's hard work.

Thanks,

Gavin

--Gavin King, February 10, 2005 06:18 AM

The @PostLoad callback may be used to implement row-level security to the extent that this problem can be tackled by a callback based approach. However, I think that the only really compelling solution for row-level security is a combination of callbacks and something like Hibernate3 Filters. of course, since filters are basically a completely new idea (though there is some similarity to Oracle VPD), it would be absolutely inappropriate to standardize them now.

Of course, if you will use EJB3 in JBoss, you will get filters as a vendor extension ;-)

--Gavin King, February 10, 2005 11:27 AM
Post a comment









Remember personal info?