"alesj" wrote : "jason.greene(a)jboss.com" wrote : | | but if the performance sucks as bad as this does, no one will use it. | | | Didn't you use this with PojoCache, but never noticed the bad performance? ;-) | Yes I inherited that choice, and I definitely noticed the problems, which is why I consider it's usage of AOP to be a failed experiment. Although we did tell people who cared about performance to use offline compilation when running under the AS. We also had all kinds of usability issues with it (most of problems reported where configuration errors, weaving issues, or stub compatibility problems). The future replacement of PojoCache will take a saner JPA-like approach. BTW I don't mean to criticize JBossAOP, it's a good implementation of AOP. I just think we are using it solve problems that have way simpler and way faster solutions. anonymous wrote : | "jason.greene(a)jboss.com" wrote : | | In general we should avoid expanding our usage of this until we know that the design is even fixable. | | | If Google can search a googol of entries in a split sec, | I don't see why we couldn't do the same for a handful of beans and aspects. | | Kabir, what's the current search/matching mechanism? | Can it be made plugable? | Or how much would it take to improve that? | | Idea of Lucene or Hadoop (on a single cpu) comes to my mind ... :-) | Or basically any decent BTrees impl should do. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230911#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...