Russell Miles continues his introduction to AOP in Spring with a Cuckoo's Egg Design Pattern example. The CuckoosEgg interceptor routes method invocations to alternative implementations in his ReplacementFeature class. The example uses the AOP Alliance APIs, which means it can be used in other AOP containers.

Read more in: An Introduction to Aspect-Oriented Programming with the Spring Framework, Part 2

Read Bob Lee's thoughts at: Porting the Cuckoo's Egg

Take a look at the first part: An Introduction to Aspect-Oriented Programming with the Spring Framework, Part 1

Staale Pederson has written a nice blog
about using JBoss AOP to implement the Mock pattern. Its really about injecting Mocks anywhere in your application without the requirement of delegating to some intrusive IoC framework for the creation of your objects.

We also talk a bit about using JBoss AOP to write tests. in the JBoss AOP User Guide.

I think you'll find that JBoss AOP gives you a lot more fine-grain control for testing than the IoC and proxy-based AOP approaches. Especially with the call, withincode, and within pointcut expressions. Combined with the hot-deployment features of JBoss AOP, you've got true power in testing your applications outside and inside your application server within automated builds.

Bill

Staale Pederson has written a nice blogabout using JBoss AOP to implement the Mock pattern. Its really about injecting Mocks anywhere in your application without the requirement of delegating to some intrusive IoC framework for the creation of your objects.

Bill,

Why is it that JBoss folks are unable to inform the community of functionality that the JBoss products provides without labeling competing solutions as 'intrusive' or telling us what it is 'really' about? I would prefer it if you let me decide what I find intrusive (recent posts by members of the JBoss team would be on my list).

Please dont get me wrong, I think the JBoss group's technology set is quite superb and it is clear that some very smart guys have been working on it, but it is your resonsibility not to allow this to turn into arrogance. It is possible to make the community aware of your software and services without making subtle negative comments about other similar products. I would expect this kind of behaviour from Microsoft or IBM but not from a group who has risen from the community itself!

Perhaps my comments have fallen on deaf ears, I hope not.

Also, if you speak to Marc, you may wish to tell him that ending his JBoss newsletter emails with "...and remember, we love you' just makes him sound like a bit of a prick.

Thanks

Wesley Hall

Why is it that JBoss folks are unable to inform the community of functionality that the JBoss products provides without labeling competing solutions as 'intrusive' or telling us what it is 'really' about? I would prefer it if you let me decide what I find intrusive (recent posts by members of the JBoss team would be on my list).

What is so wrong for competing products to call each other intrusive? Would you rather prefer them sucking up to each other all the time?

--Dmitriy.

I've read today's post by Bill about JBoss AOP. I thought I'd check out some Spring AOP stuff. Lo and behold, the first post is by Bill. I feel like Bill is following me round with a megaphone shouting "JBoss rocks". Like, well, OK, but can you just leave me alone for a bit?

Now inevitably the Spring dudes have to be on the defensive, and before you know it, there's going to be ANOTHER big fat flame war, and nobody gets to discuss anything technical. *yawn*

Now inevitably the Spring dudes have to be on the defensive, and before you know it, there's going to be ANOTHER big fat flame war, and nobody gets to discuss anything technical. *yawn*

How do you plan to have a "technical" discussion if everyone agrees and praises everyone else? I *yawn* at posts like "Your product is wonderful and so is everything in it" because it is never true.

Open your mind and read the posts. This thread does indeed discuss an interesting technical issue.

--Dmitriy.

I *yawn* at posts like "Your product is wonderful and so is everything in it" because it is never true.

Funny, because that's exactly how the JBoss AOP thread read...

Open your mind and read the posts. This thread does indeed discuss an interesting technical issue.

'Interesting' might be pushing it. My mind might be more open if it wasn't for all this bizarre chimpanzee-style alpha-male posturing. As it is, I'm off to have a beer. Cheers.

Yeah, I don’t understand either what was wrong with Bill’s post (although I would disagree with some of what he’s saying).

Has anyone actually looked at the example of Spring configuration (springconfig.xml)? I found it really impossible to comprehend for anyone who is not intimately familiar with Spring. I mean > 50 lines of obfuscated XML to just to define two primitive advises? Here it goes:

   <!--CONFIG-->
   <bean id="businesslogicbean"
      class="org.springframework.aop.framework.ProxyFactoryBean">
      <property name="proxyInterfaces">
         <value>IBusinessLogic</value>
      </property>
      <property name="target">
         <ref local="beanTarget"/>
      </property>
      <property name="interceptorNames">
         <list>
            <value>theCuckoosEggAdvisor</value>
         </list>
      </property>
   </bean>
   
   <bean id="businesslogicbean2"
      class="org.springframework.aop.framework.ProxyFactoryBean">
      <property name="proxyInterfaces">
         <value>IBusinessLogic2</value>
      </property>
      <property name="target">
         <ref local="beanTarget2"/>
      </property>
      <property name="interceptorNames">
         <list>
            <value>theCuckoosEgg2Advisor</value>
         </list>
      </property>
   </bean>

   <!--CLASS-->
   <bean id="beanTarget" class="BusinessLogic"/>
   <bean id="beanTarget2" class="BusinessLogic2"/>
   
   <!--ADVISOR-->
   <bean id="theCuckoosEggAdvisor"
      class="org.springframework.aop.support.RegexpMethodPointcutAdvisor">
      <property name="advice">
         <ref local="theReplacementFeaturePart1Advice"/>
      </property>
      <property name="pattern">
         <value>IBusinessLogic.*</value>
      </property>
   </bean>
   
   <bean id="theCuckoosEgg2Advisor"
      class="org.springframework.aop.support.RegexpMethodPointcutAdvisor">
      <property name="advice">
         <ref local="theReplacementFeaturePart2Advice"/>
      </property>
      <property name="pattern">
         <value>IBusinessLogic2.bar*</value>
      </property>
   </bean>
   
   <!--ADVICE-->
   <bean id="theReplacementFeaturePart1Advice" class="CuckoosEgg"/>
   <bean id="theReplacementFeaturePart2Advice" class="CuckoosEgg"/>

It looks almost ridiculous. In my opinion it just shows another design problem with Spring where it attempts to use over-generic XML configuration approach for every part of Spring configuration whether it fits or doesn’t. Looking at other AOP frameworks it is clear that the same configuration can be achieved in 2-5 lines of clear XML or BeanShell code (if external configuration is required at all).

Regards,
Nikita.

Looking at other AOP frameworks it is clear that the same configuration can be achieved in 2-5 lines of clear XML or BeanShell code (if external configuration is required at all). Regards,Nikita.

JBoss AOP and AspectWerks also have annotations as a configuration mechanism. I'm not familiar with AW anymore, so I'll stick to a JBoss AOP example:


@Aspect(scope=Scope.PER_VM)
public class TheCuckoosEggAdvisor
{
   protected int configValue = 5;
 
   @Bind(pointcut="execution(* $instanceof{IBusinessLogic}->*(..))")
   public Object someAdvice(Invocation invocation)
   {
       ...body...
   }
}


If you need to configure an aspect , then just use inheritance:


@Aspect
public class Cuckoo2 extends TheCuckoosEggAdvisor
{
   public Cuckoo2()
   {
       configValue = 25;
   }

   @Bind(pointcut="execution(* $instanceof{SomethingElse}->*(..))")
   public Object someAdvice(Invocation invocation)
   {
      return super.someAdvice(invocation);
   }
}


I prefer XML, but to-each-his-own.

Bill

I mean > 50 lines of obfuscated XML to just to define two primitive advises?

It's not obfuscated - in fact it is the exact opposite. It is an overly verbose config file that makes the wiring and advice absolutely explicit, using the most straightforward of Spring's AOP mechanisms. It holds your hand as it plainly instantiates two different beans and applies a different advisor to each using a different regex matcher. There are a number of much terser ways you can achieve the same goal in Spring.

Looking at other AOP frameworks it is clear that the same configuration can be achieved in 2-5 lines of clear XML or BeanShell code

As indeed it could be with spring in a less verbose example. For example, you don't necessarily have to explicitly apply advisors using the ProxyFactory as in the above example, or you could use annotations to describe the pointcuts. One of the enduring problems with Spring is that there are generally at least 5 ways of solving the same problem with the framework - and just when you think you've picked the best approach, another even more convenient one comes crawling out of the woodwork...

Hi Dave,
I could have not said it better:

One of the enduring problems with Spring is that there are generally at least 5 ways of solving the same problem with the framework - and just when you think you've picked the best approach, another even more convenient one comes crawling out of the woodwork...

Again, we may have different philosophies but in my book that is a definite design smell.

Keith,

Spring favors one configuration format for them all---a generic one that is simple yet flexible, grounded in standard javabean concepts. No more having to learn a million different/inconsistent configuration formats.

I was certainly aware of this (but it really took me like 10 mins to understand this exact example). You point is very valid though. It is a delicate design decision on whether to favor uniform but overly generic approach or straight and concise approach that will require learning different XML notations. In a product similar to Spring I have chosen the latter because the level of configuration we require simply could no be achieved with plain XML-ed JavaBeans. I believe the same true for Spring. As an example, look at JBoss example:
<blockqoute>
@Aspect(scope=Scope.PER_VM)
public class TheCuckoosEggAdvisor
{
   protected int configValue = 5;
 
   @Bind(pointcut="execution(* $instanceof{IBusinessLogic}->*(..))")
   public Object someAdvice(Invocation invocation)
   {
       ...body...
   }
}, or even better, the DynaAop example:

interceptor(IBusinessLogic, "foo", CuckoosEgg);
interceptor(IBusinessLogic2, "bar", CuckoosEgg);

I think the difference in clarity and simplicity is quite obvious. I would go further saying that the benefits you are getting from clear and concise configuration like that overweight the downside of learning specific lingo like certain annotations, XML or BeanShell.

Since Spring simply delegates to others for most of it functionality it may not feel the awkwardness of (or need to change) its configuration. But imagine that you have to fully configure Hibernate and iBATIS using only Spring XML beans… I guess my point would become much clearer.

Best,
Nikita.

It is a delicate design decision on whether to favor uniform but overly generic approach or straight and concise approach that will require learning different XML notations.

Yes it certainly is! And I'd say Spring's XML format is not appropriate for extremley fine grained configuration. Just to give you an example, with the Spring Rich Client Project (Spring Rich) we leverage the format for configuring application 'command bars' (menubar/toolbar/etc definitions, somewhat coarse grained), which works well, but favor "plain old java" for fine-grained configuration and layout of GUI forms. It's a balance like you said, by far the important thing is decoupling configuration from use.

In general, I feel Spring's externalized, consistent configuration mechanism is well suited for configuring and assembling application objects (services, DAOs, controllers, etc.) It makes it easy to parameterize those objects with pluggable strategies for varying implementation at runtime, and between runtime and test time. It's also very good at encapsulating object creation and/or lookup logic via the FactoryBean concept, which is extremely powerful (no more hand-coded JNDI lookups, no more hand-coded business delegates or EJB service locators.) The fundamental goal here is to promote a well-layered application decoupled from infrastructure, one with zero to very little hand-coded glue or configuration code.

But as you mentioned, exactly, for things like Hibernate mapping files or ibatis maps; obviously, we're much better suited to leverage those product's great configuration formats (typically 'specialized' xml based.) It would be crazy to try and code a hibernate mapping in Spring XML! Yet, Spring's format is an excellent choice for declaratively configuring an Hibernate Session Factory (loading mapping files from declaratively specified as resources, and injecting that factory to DAOs that need it.) It's more about providing the 'glue'--which gives you that balance and consistency we're looking for IMO.

Again, we may have different philosophies but in my book that is a definite design smell.

I like how you ignored the rest of my comment, and picked up only on the flippant note I added at the end. Do I have to add a ;)?

We evidently do have different philosophies, as in my book that just highlights the flexibility and convenience of the core framework. You can always do what you want to within the confines of the framework, without resorting to an ugly hack - and generally you find that the framework provides a number of alternatives, and you pick the one most convenient to the job at hand.

Dave Hewitt:
It's not obfuscated - in fact it is the exact opposite. It is an overly verbose config file that makes the wiring and advice absolutely explicit, using the most straightforward of Spring's AOP mechanisms. It holds your hand as it plainly instantiates two different beans and applies a different advisor to each using a different regex matcher. There are a number of much terser ways you can achieve the same goal in Spring.

You are spinning the argument.

Here is the DynAop 2 line definition which is equivalent to Spring's 60 line of XML.

interceptor(IBusinessLogic, "foo", CuckoosEgg);
interceptor(IBusinessLogic2, "bar", CuckoosEgg);

It literally took me 10 seconds to understand what it does.

However, when I looked at ridiculously undecipherable 2 screen pages of Spring XML which does exactly the same thing as a 2-liner above, it took me about 20 minutes to only partially guess what it does. I think the difference is more than obvious here.

How can you possibly argue that Spring's XML format for AOP is "straightforward" or "holds user's hand"? My experience is quite the opposite!

--Dmitriy.

I have to agree with you: Spring XML format is generic and hence verbose. But Spring has a well defined API for all the things, so anybody (you or me) could come up with another XML syntax where elements would bear more semantics. I'm sure we'd have less XML then.

There is TransactionProxy (or something like this) which could be modeled with more general ProxyFactory. This is both API and configuration convenience. XML with semantics would introduce no new API but more configuration convenience.

On the other hand, the generic XML syntax allows for simpler IDE tools (e.g. Eclipse plugin) since all items are handled equally. But here the discussion starts from the beginning :-)

It literally took me 10 seconds to understand what [the dynaop configuration] does.However, when I looked at ridiculously undecipherable 2 screen pages of Spring XML which does exactly the same thing as a 2-liner above, it took me about 20 minutes to only partially guess what it does.

I imagine. For whatever reason, Russell's configuration is far more cumbersome than it needs to be because it doesn't use Spring's DefaultAdvisorAutoProxyCreator. If you do, then applying eg.FooBar advice to Foo.bar() is as simple as this:

  <bean id="fooBarAdvisor" class="org.springframework.aop.support.RegexpMethodPointcutAdvisor">
    <constructor-arg>
      <bean class="eg.FooBar">
    </constructor-arg>
    <property name="pattern">
      <value>Foo\.bar</value>
    </property>
  </bean>

While at 9 lines this is undeniably still more verbose than dynaop's one-liner bsh configuration, I feel we're comparing apples to oranges to some extent: both advice and advisor are defined as Spring IoC beans with all the advantages that this gives you, where the dynaop example simply seems to instantiate the advice without any wiring at all.

- Peter

I imagine. For whatever reason, Russell's configuration is far more cumbersome than it needs to be because it doesn't use Spring's DefaultAdvisorAutoProxyCreator. If you do, then applying eg.FooBar advice to Foo.bar() is as simple as this:&nbsp;&nbsp;<bean id="fooBarAdvisor" class="org.springframework.aop.support.RegexpMethodPointcutAdvisor">&nbsp;&nbsp;&nbsp;&nbsp;<constructor-arg>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<bean class="eg.FooBar">&nbsp;&nbsp;&nbsp;&nbsp;</constructor-arg>&nbsp;&nbsp;&nbsp;&nbsp;<property name="pattern">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<value>Foo.bar</value>&nbsp;&nbsp;&nbsp;&nbsp;</property>&nbsp;&nbsp;</bean>While at 9 lines this is undeniably still more verbose than dynaop's one-liner bsh configuration, I feel we're comparing apples to oranges to some extent: both advice and advisor are defined as Spring IoC beans with all the advantages that this gives you, where the dynaop example simply seems to instantiate the advice without any wiring at all.- Peter

First, it's not apples to oranges to any extent. Auto wiring advice in Dynaop is trivial. I have a client that wires advice with Spring and applies advice to Spring beans with Dynaop.

Second, this is a trivial example. What happens to the XML when things get a little more complicated? The following Dynaop example says, "apply the CuckoosEgg interceptor to methods if the target class is an implementation of Foo or has 'Bar' in the name and the method signature contains 'run' or 'doSomething' or an implementation of Tee declares the method and it returns an implementation of List." When I say, "an implementation of," I mean it can match that class or sub classes of that class.


interceptor(
  union(Foo, "Bar"),
  union(
    "run",
    "doSomething",
    intersection(returnType(java.util.List), declaringClass(Tee))
  ),
  CuckoosEgg
);


Can you provide an equivalent example in Spring XML?

Can you provide an equivalent example in Spring XML?

Can you provide the use case for this pointcut? If not, what is the point of an academic example? Spring is first and foremost a framework for today's day to day software development practice.

The available pointcut definitions in Spring (regexps, attributes, transaction metadata) have served my team fine so far. In the unlikely case that we needed to define a pointcut as convoluted as this, I'd implement the Pointcut interface - a couple of lines of Java code that will be no harder to understand than the beanshell script above. If you really insist that java code is a no-no and bsh pointcut definitions are a must have in an AOP framework, it would be fairly straightforward to create a BeanshellMethodPointcutAdvisor that works along the same lines as dynaop.

The original article's configuration was bulky and confusing, but it seems we agree that was through no fault of Spring. I would also agree that Spring AOP has its limitations, but it seems to me that the way it is configured is not really one of them, and certainly not a major one. There are far more important matters that would drive one's choice between AOP frameworks.

 - Peter

Can you provide the use case for this pointcut? If not, what is the point of an academic example?

No offense, but that sounds like a cop out to me. Anyone who's used AOP for anything more than trivial aspects knows that pointcut orthagonality and composition is very important. The AspectJ folks recognized this very early on.

Here's an example from a production application (names changed). Please provide the Spring AOP equivalent (use custom pointcut implementations, BeanShell, or whatever you like).

// these pointcut defs are reused in other places.
fooClasses = ...;
fooMethods = ...;

interceptor(
  fooClasses,
  intersection(fooMethods, not(membersOf(Bar))),
  TeeInterceptor
);

There are far more important matters that would drive one's choice between AOP frameworks.

I'd be more than happy to debate them, and I'm certain that Dynaop comes out on top in each category, but let's start with the Spring port of the above example first.

BTW, I love Spring, and I use it personally. I'm just not that crazy about the AOP implementation.

I'd be more than happy to debate them, and I'm certain that Dynaop comes out on top in each category, but let's start with the Spring port of the above example first.

Bob,

here is an examaple on how you would do it programmaticaly (you could always create a FactoryBean to ease the configuration of such a pointcut in Spring DI environment. Let's say you have two "reusable" ClassFilters for Exception.class and AopChallangeTest.class and two "reusable MethodMatchers for "toString" and "hashCode":

public class AopChallengeTest extends TestCase {

    private MethodMatcher method1 = new StaticMethodMatcher(){

        public boolean matches(Method m, Class targetClass) {
            return m.getName().equals("toString");
        }
    };

    private MethodMatcher method2 = new StaticMethodMatcher(){

        public boolean matches(Method m, Class targetClass) {
            return m.getName().equals("hashCode");
        }
    };

    private ClassFilter class1 = new RootClassFilter(AopChallengeTest.class);

    private ClassFilter class2 = new RootClassFilter(Exception.class);

    public void testComplexPointcut() throws NoSuchMethodException {
        Pointcut pc = new ComposablePointcut(class1, method1).union(class2).union(method2);
        
        assertTrue(Pointcuts.matches(pc, AopChallengeTest.class.getMethod("toString", (Class[])null), AopChallengeTest.class, null));
        assertTrue(Pointcuts.matches(pc, AopChallengeTest.class.getMethod("hashCode", (Class[])null), AopChallengeTest.class, null));
        assertTrue(Pointcuts.matches(pc, Exception.class.getMethod("toString", (Class[])null), Exception.class, null));
        assertTrue(Pointcuts.matches(pc, Exception.class.getMethod("hashCode", (Class[])null), Exception.class, null));
        assertFalse(Pointcuts.matches(pc, BeanWrapperImpl.class.getMethod("toString", (Class[])null), BeanWrapperImpl.class, null));
        assertFalse(Pointcuts.matches(pc, BeanWrapperImpl.class.getMethod("hashCode", (Class[])null), BeanWrapperImpl.class, null));
    }
}

Cheers,
Dmitriy.

Nikita,

You're familiar with JavaBeans right? Each <bean> of a given implementation class has one or more <property> elements. Each <property> can accept a scalar <value>, a collection value such as a <list>, <map>, or <set>, or a <ref> (reference) value to another bean.

That's complex? That's about as straightforward as it gets. Spring favors one configuration format for them all---a generic one that is simple yet flexible, grounded in standard javabean concepts. No more having to learn a million different/inconsistent configuration formats.

Best regards,
Keith

Spring favors one configuration format for them all---a generic one that is simple yet flexible, grounded in standard javabean concepts. No more having to learn a million different/inconsistent configuration formats.Best regards,Keith

The flip side is that you have no way at all to verify your configuration. AOP frameworks with explicit XML configuration have DTDs/schema to validate the config. AOP frameworks that use annotations(JBoss or AW) or have an API(Nanning, DynAOP??), have the Java compiler to do the validation.

Bill

AOP frameworks that use annotations(JBoss or AW) or have an API(Nanning, DynAOP??), have the Java compiler to do the validation.Bill

Spring's AOP framework *does* have a well-defined Java API, which is obvious for anyone who actually reads up on Spring's AOP support.

The XML bean definition format is just one of way of tapping into those services, and the above example is a particularly verbose one which can be significantly shortened, for example through leveraging unnamed inner beans.

An example for programmatic proxy configuration, configuring two target beans with one proxy each, applying an interceptor to specific regex method patterns:

TestBean tb1 = new TestBean("tb1", 99);
ProxyFactory proxyFactory1 = new ProxyFactory(tb1);
proxyFactory1.addAdvisor(new RegexpMethodPointcutAdvisor(".*get.*", new DebugInterceptor()));
ITestBean proxy1 = (ITestBean) proxyFactory1.getProxy();

TestBean tb2 = new TestBean("tb2", 88);
ProxyFactory proxyFactory2 = new ProxyFactory(tb2);
proxyFactory2.addAdvisor(new RegexpMethodPointcutAdvisor(".*set.*", new DebugInterceptor()));
ITestBean proxy2 = (ITestBean) proxyFactory2.getProxy();

proxy1.getName();
proxy2.setName(...);
...

I think it's quite hard to argue that this is overly verbose. It's plain Java, so validated through the Java compiler. And it can work with either JDK proxies or CGLIB proxies - no special build steps, no special class loader.

Juergen

Side note: The RegexpMethodPointcutAdvisor convenience constructor used in the example code above, taking a single pattern plus advice, has been introduced for the upcoming Spring 1.1.2.

Juergen

Of course Spring has a validating AOP API silly! :-) What else would drive configuration, then? A solid API must come first, or you don't have anything! The XML configuration medium is just one way of tapping into that API--a way that makes sense when externalizing configuration from java code is a requirement.

Would it make sense for Spring to have its own specialized, proprietary format for declaratively defining advice? Quite possibly, but it's a tradeoff, as Nikita mentioned. The motto has been to construct a solid API, and leverage our own container as one way to wield it--it gives us more bang for the buck. Users can still use the API programatically, or they can "tell Spring's IoC container" how to wield it via XML descriptors, property files, or a specialized format.

Will we see a standard AOP configuration format emerge? Now that'd be interesting! Even a standard API would be nice (hint hint - why did you guys pass on aopalliance!?)

Regards,
Keith

Bill:
The flip side is that you have no way at all to verify your configuration. AOP frameworks with explicit XML configuration have DTDs/schema to validate the config. AOP frameworks that use annotations(JBoss or AW) or have an API(Nanning, DynAOP??), have the Java compiler to do the validation.

I must agree with this statement.

There is a fundamental difference between saying
<advise> - the straightforward way, and
<property name="advice"> - the Spring's way.

In the first case the XML editor will tell you if you made a mistake in AOP definition, but in the second case - it won't. In the first case you can fix the error right away, and in the second case - you must run Java code to detect the error.

I think the natural advantage goes to strong DTD/Schema based XML for AOP.

--Dmitriy.

I think the natural advantage goes to strong DTD/Schema based XML for AOP.--Dmitriy.

I agree. However, I like how Spring provides a generic configuration language that *does only one well defined thing and does it well* (i.e. instantiates, configures and binds beans - well that's 3 things, but they really are one big thing :-).

Now, as someone else pointed out, this well defined language is easy to build upon. IMHO this is a modern incarnation of the great Unix philosophy: specialized programs that can be used together in unforeseen ways.

So, for example, if you prefer to use a strict and terse syntax for defining aspects (and you should, if there are lots of them), use XSLT or whatever conversion language is close to your heart (sed, perl, ...) to generate the Spring configuration file.

And if there is some project-specific reduncancy in a configuration file written in this new "aspect-configuration" language, create a new project-specific little language that generates the "aspect-configuration" file.

So the bottom line is that tools to create little languages quickly should belong to everybody's toolbox. This way each little language suits well some concrete problem without trying to be "everything for everybody" which easily leads to "nothing for anybody".

It's too bad this thread ended up being about JBoss.


Bill is certainly right that other AOP frameworks (particularly the various containerS) are extremely intrusive. This isn't marketing-speak, it's the cold-hard truth. Complaining about this is just stupid.

That being said, it'd be interesting to ever see a post where Bill doesn't try to sell JBoss to us. I wonder if such a thing could exist.

Not sure what people on this thread mean when they say "intrusive".

If there were an IDE, for example, that did all the wiring up in Spring using D&D, so that one never saw the Spring XML config files, is it still intrusive, or if one wrote Beanshell or Groovy scripts that did the wiring up based on company POJO resource repositories (the ancient marketing spin for reusable Components)?

I thought that 'intrusive' was meant in the context of IoC, where the code did not become a dependent on the container.

I guess in this sense of the term, JBoss is trying to make itself unncessary since it is doing so much for non-intrusiveness? :)

In the article the following portion:

   <bean id="theCuckoosEgg2Advisor"
      class="org.springframework.aop.support.RegexpMethodPointcutAdvisor">
      <property name="advice">
         <ref local="theReplacementFeaturePart2Advice"/>
      </property>
      <property name="pattern">
         <value>IBusinessLogic2.bar*</value>
      </property>
   </bean>

Is the regular expression <code>IBusinessLogic2.bar*</code> correct? This means the method would be to be like IBusinessLogic2.barrrrrr(...) to be matched (assuming default package).

I think it should be <code>IBusinessLogic2.bar.*

Please correct me if I am wrong. Cheers!

btw. Spring ROCKS!!!!!

regards
tmjee

I think it should be <code>IBusinessLogic2.bar.*Please correct me if I am wrong. Cheers!btw. Spring ROCKS!!!!!regardstmjee
It should be ".*IBusinessLogic2.*bar.*"

Regards,
Dmitriy.