sure. One of the aspects tests actually creates a proxy and returns that instead.
Constructor interception is an "around" thingy so you can return any instance you want of the constructor.
You can also do call side constructor interception of you only want to use the pool in certain code structures.
Yes, the constructor interceptor runs in the context of the calling code.
POJO pojo = new POJO();
Instrumented and intercepted - (pseudo code):
POJO pojo = POJO.staticMethodReplacingConstructor();
With a stacktrace similar to this:
Do I still need to call invocation.invokeNext(), or will I be missing executing some constructor processing if I don't?
o = Static.method();
No, you do not have to call invokeNext.
In fact, it isn't that you "don't have to", "you don't want to".
invocation.invokeNext() will lead to the real constructor creating an Object instance
you don't want.
When you do want to invoke the real constructor, use reflection.
Bill: "One of the aspects tests actually creates a proxy and returns that instead."
Is that in the AOP examples, or in jbosstest?
Bill: "You can also do call side constructor interception of you only want to use the pool in certain code structures."
I think Adrian mentioned that as well, in the JCA forum:
Adrian: "A real solution would be to do caller side analysis/weaving"
Slowly, this is beginning to make sense. Looking at the caller AOP example.
Let me know if the tutorial is complete enough and answers your questions well enough.
All of the examples use invocation.invokeNext(). It might be nice to see an example that doesn't use it (i.e. the proxy you mentioned before).
Do one of the unit tests do that? I'm looking through the jbosstest AOP tests and none of them jump out at me for a Proxy.
Do->Does. English. Grammar. Whatever.