[jbossseam-issues] [JBoss JIRA] Closed: (JBSEAM-4173) Wicket instrumentation results in incorrect disinjection when invoking superclass methods from a subclass constructor

[Clint Popetz (JIRA)]

     [ https://jira.jboss.org/jira/browse/JBSEAM-4173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clint Popetz closed JBSEAM-4173.
--------------------------------

    Resolution: Done


Fixed in r10910.

This fix involves:

(a) Only adding the handler field of the topmost instrumented class in an inheritance tree.
(b) Recursively instrumented classes above any class lower than that, so that the lower class can make a javassist reference to the handler field.

Because of (b) The four approaches to instrumentation (maven mojo, -javaagent, ant task, and runtime class loader for /WEB-INF/wicket) each have to know how to tell the instrumenting agent the set of all classes that can be instrumented, unless the @SeamWicketComponent annotation is used to mark instrumentable classes.   This is not determinable from the mojo or ant task unless a clean build is done, so in those cases the use of @SeamWicketComponent is the only reliable way to ensure proper instrumentation.

> Wicket instrumentation results in incorrect disinjection when invoking superclass methods from a subclass constructor
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBSEAM-4173
>                 URL: https://jira.jboss.org/jira/browse/JBSEAM-4173
>             Project: Seam
>          Issue Type: Bug
>          Components: Wicket
>            Reporter: Clint Popetz
>            Assignee: Clint Popetz
>             Fix For: 2.1.2
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Currently a WicketHandler instance is created for each class in a hierarchy, which means we don't maintain the reentrancy count correctly for situations like 
> class A { 
>  @In Dependent dep; 
>   A() { }
>    method() {  }
> }
> class B extends A { 
>     B() { 
>      super();
>      method();
>      dep.method();  //NPE because dep has been disinjected
>    }  
> }
> This only exhibits in constructors because otherwise the getHandler() call will always find the most derived handler instance.  
> The solution is to ensure that there is only one handler, living in the least-derived instrumented parent.  This means that instrumentation has to happen recursively, so that instrumenting child classes can make reference to the instrumented parent's handler field.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira