Build Time Wicket Instrumentation with Ant (and other problems)

[robshep]

Hi,

A simple query for those who have build time instrumentation working with Wicket.

I have the following structure in the build.xml

                 <mkdir dir="classes/wicket" />

                   <!-- Compile the Wicket classes -->
                   <javac classpathref="wicket.classpath"
                          destdir="classes/wicket"
                          debug="${javac.debug}"
                          deprecation="${javac.deprecation}"
                          nowarn="off">
                      <src path="src/web" />
                   </javac>

                   <!-- Instrument the SEAM annotations -->
                   <instrumentWicket outputDirectory="${war.dir}/WEB-INF/classes" useAnnotations="false">
                        <classpath refid="build.classpath"/>
                        <fileset dir="classes/wicket" includes="**/*.class"/>
                   </instrumentWicket>



                   <!-- Copy the html markup to the same location -->
                   <copy todir="${war.dir}/WEB-INF/classes">
                      <fileset dir="src/web">
                         <include name="**/*.html"/>
                         <include name="**/*.js"/>
                      </fileset>
                   </copy>

But I see the following error during build at instrumentation time.

java.lang.RuntimeException: javassist.NotFoundException: com.example.myclass

This class exists in classes/wicket

So I'm not sure what the problem can be.  Can anybody see an obvious problem with my build.xml excerpt?

Incidentally,  I'm attempting to switch to compile-time wicket instrumentation to try and workaround/resolve/indicate a strange problem.

I have the following class in my web/ folder....

package com.example.effect;

import org.apache.wicket.Component;

public class TheClassName
{
    //private Component component;
     
    public TheClassName(/*Component component*/)
    {
     //this.component = component;
    }
}

...And, strangely if I uncomment the above lines (in fact just the first will do) Then my application fails as follows.

09:51:13,692 ERROR [[default]] Servlet.service() for servlet default threw exception
java.lang.ClassCastException: org.jboss.seam.wicket.WicketManager
     at org.jboss.seam.faces.FacesManager.instance(FacesManager.java:313)
     at org.jboss.seam.exception.DebugPageHandler.handle(DebugPageHandler.java:26)
     at org.jboss.seam.exception.Exceptions.handle(Exceptions.java:76)
     at org.jboss.seam.web.ExceptionFilter.endWebRequestAfterException(ExceptionFilter.java:114)
     at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:70)
     at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
     at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
     at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
     at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
     at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
     at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
     at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
     at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
     at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
     at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
     at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
     at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
     at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
     at java.lang.Thread.run(Thread.java:613)

....I'm thus making the assumption that Run-Time instrumentation is failing somehow (sliently) and WicketManager doesn't get constructed (Warning - guess hazarding in progress!!)

Strange but true.

With thanks for any help with these problems

Rob

[robshep]

Yay, as I assumed, it was a runtime instrumentation issue which was failing and switching to compile-time did show me that.

In summary,

1. HINT: The <classpath> that is given to the wicketInstrumentation task needs to include the compiled wicket classes in addition to them being provided in the <fileset>.  I found this by looking at the original patch (JBSEAM-3505) but there's a disparity between this and the common wicket setup build.xml (SeamlessWicket-blog-entry-based) and the wicket documentation.

2. CAVEAT: If one happens to have a field called component - the wicket instrumentation will fail, as it's trying to put one in called component too.  Don't have any fields called component in your wicket classes.

3. CAVEAT: same as above; don't have a field called handler.

4. CAVEAT: same as above; don't have any methods called getHandler() or getEnclosingInstance()

Phew, that took some finding.

Happy now.

Rob

[cpopetz]

Yes, those are all obnoxious artifacts of instrumentation, which is an obnoxious process.  There are others, for example debugging instrumented code, reloading instrumented code in a VM in debug mode, etc.  It's a mess.  Luckily, Seam3/Weld doesn't use instrumentation for the wicket integration.