Comments on: Introducing HyperBeans – multi-dimensional POJOs http://jonasboner.com/2005/10/25/introducing-hyperbeans-%e2%80%93-multi-dimensional-pojos/ Down To The Bone Fri, 29 Aug 2008 09:29:12 +0000 http://wordpress.org/?v=2.0.2 by: Bill Burke http://jonasboner.com/2005/10/25/introducing-hyperbeans-%e2%80%93-multi-dimensional-pojos/#comment-3450 Tue, 30 Nov 1999 00:00:00 +0000 http://jonasboner.com/2005/10/25/introducing-hyperbeans-%e2%80%93-multi-dimensional-pojos/#comment-3450 <p>Jonas,</p> <p>What does it mean to do per instance? Is the HyperBean only applied to the instance you pass into the constructor? So, you can apply advices only to one particular object instances and <em>not</em> to other instances of the same type? If so, very clean man. </p> <p>Bill</p> Jonas,

What does it mean to do per instance? Is the HyperBean only applied to the instance you pass into the constructor? So, you can apply advices only to one particular object instances and not to other instances of the same type? If so, very clean man.

Bill

]]> by: Rémi Forax http://jonasboner.com/2005/10/25/introducing-hyperbeans-%e2%80%93-multi-dimensional-pojos/#comment-3451 Tue, 30 Nov 1999 00:00:00 +0000 http://jonasboner.com/2005/10/25/introducing-hyperbeans-%e2%80%93-multi-dimensional-pojos/#comment-3451 <p>I love the way you do deployement, the fact that you don't need another language to write advices and how you request injection of context informations to advice (@Callee).</p> <p>Three remarks : - just before the section about advice, in the example, you don't need to use a variable result. return in try/cath block is permitted :)</p> <ul> <li><p>why don't you have an annotation for InvocationContext.</p></li> <li><p>why don't you implement HyperBean using java.lang.instrumentation instead of using AOP support in JRockit ?</p></li> </ul> <p>Rémi</p> I love the way you do deployement, the fact that you don’t need another language to write advices and how you request injection of context informations to advice (@Callee).

Three remarks : - just before the section about advice, in the example, you don’t need to use a variable result. return in try/cath block is permitted :)

  • why don’t you have an annotation for InvocationContext.

  • why don’t you implement HyperBean using java.lang.instrumentation instead of using AOP support in JRockit ?

Rémi

]]> by: Jonas Bonér http://jonasboner.com/2005/10/25/introducing-hyperbeans-%e2%80%93-multi-dimensional-pojos/#comment-3452 Tue, 30 Nov 1999 00:00:00 +0000 http://jonasboner.com/2005/10/25/introducing-hyperbeans-%e2%80%93-multi-dimensional-pojos/#comment-3452 <p>Bill,</p> <p>All the deployments binds the HyperBean to the scope instance only. So for the per instance case you are correct. It binds the aspect to the sole instance that you pass in the ctor (annotated with @Scope).</p> <p>Thanks a lot.</p> Bill,

All the deployments binds the HyperBean to the scope instance only. So for the per instance case you are correct. It binds the aspect to the sole instance that you pass in the ctor (annotated with @Scope).

Thanks a lot.

]]> by: Jonas Bonér http://jonasboner.com/2005/10/25/introducing-hyperbeans-%e2%80%93-multi-dimensional-pojos/#comment-3453 Tue, 30 Nov 1999 00:00:00 +0000 http://jonasboner.com/2005/10/25/introducing-hyperbeans-%e2%80%93-multi-dimensional-pojos/#comment-3453 <p>Rémi, </p> <ol> <li><p>Thanks for the remark, should have seen that myself :)</p></li> <li><p>I do not see the point, all other annotations are used to pass in arbitrary types. But the InvocationContext will always be (has to be) of the same type - InvocationContext. Do I misunderstand you? What would be the usage? </p></li> <li><p>Simply because it is so much simpler (and more performant) using the JRockit API. I guess it would be possible to implement using JVMTI/HotSwap and plain old bytecode instrumentation. It would be cool if someone volunteered/helped out to do that (would be necessary in order to get it widely used in the short term). If anyone is interested, please let me know. :P</p></li> </ol> <p>Thanks for the feedback.</p> Rémi,

  1. Thanks for the remark, should have seen that myself :)

  2. I do not see the point, all other annotations are used to pass in arbitrary types. But the InvocationContext will always be (has to be) of the same type - InvocationContext. Do I misunderstand you? What would be the usage?

  3. Simply because it is so much simpler (and more performant) using the JRockit API. I guess it would be possible to implement using JVMTI/HotSwap and plain old bytecode instrumentation. It would be cool if someone volunteered/helped out to do that (would be necessary in order to get it widely used in the short term). If anyone is interested, please let me know. :P

Thanks for the feedback.

]]> by: Dean Wampler http://jonasboner.com/2005/10/25/introducing-hyperbeans-%e2%80%93-multi-dimensional-pojos/#comment-3454 Tue, 30 Nov 1999 00:00:00 +0000 http://jonasboner.com/2005/10/25/introducing-hyperbeans-%e2%80%93-multi-dimensional-pojos/#comment-3454 <p>Jonas, Very elegant! One question; is there a facility or plans for one that decouples pointcut definitions, as currently shown in the @Before, @After, and @Around annotations, from the source code. For example, using an XML config. file, as in AspectWerkz? That would make it easier to write reusable aspects. Okay, another question, again pertaining to reusability; have you given much thought to possible design patterns for defining base aspects (abstract or not) and subtyping them for specific cases, as is commonly done in AspectJ? Thanks and keep up the good work! ;)</p> Jonas, Very elegant! One question; is there a facility or plans for one that decouples pointcut definitions, as currently shown in the @Before, @After, and @Around annotations, from the source code. For example, using an XML config. file, as in AspectWerkz? That would make it easier to write reusable aspects. Okay, another question, again pertaining to reusability; have you given much thought to possible design patterns for defining base aspects (abstract or not) and subtyping them for specific cases, as is commonly done in AspectJ? Thanks and keep up the good work! ;)

]]> by: Jonas Bonér http://jonasboner.com/2005/10/25/introducing-hyperbeans-%e2%80%93-multi-dimensional-pojos/#comment-3455 Tue, 30 Nov 1999 00:00:00 +0000 http://jonasboner.com/2005/10/25/introducing-hyperbeans-%e2%80%93-multi-dimensional-pojos/#comment-3455 <p>Thanks a lot Dean.</p> <p>Decoupling of advice-pointcut is indeed necessary. I think it could be done the same way as in the @AspectJ 5 (and AW) syntax.</p> <p>Might be good to still support XML. I do not think that the general aop.xml file should be supported since this is an attempt to move away from the deployment descriptor and put it into the code itself, give the developer programmatic control over deployment and undeployment. But annotation over-riding might be neat to have, similar to what is proposed in EJB 3.</p> <p>Given that we have standalone PC definitions, I think that subclassing of abstract hyperbeans should work the same as with aspects in the AW/@AspectJ syntax. I have not given it much thought though. Design patterns is something that has to be worked out over time.</p> Thanks a lot Dean.

Decoupling of advice-pointcut is indeed necessary. I think it could be done the same way as in the @AspectJ 5 (and AW) syntax.

Might be good to still support XML. I do not think that the general aop.xml file should be supported since this is an attempt to move away from the deployment descriptor and put it into the code itself, give the developer programmatic control over deployment and undeployment. But annotation over-riding might be neat to have, similar to what is proposed in EJB 3.

Given that we have standalone PC definitions, I think that subclassing of abstract hyperbeans should work the same as with aspects in the AW/@AspectJ syntax. I have not given it much thought though. Design patterns is something that has to be worked out over time.

]]>