Wicket Buildtime Instrumentation Annotation?

[paulmooney]

I would like to implement (or suggest) an alternative to the Seam JavassistInstrumentor, and subsequently an ANT task to go with it, that instruments Classes with a specific annotation (let's say something like @WicketComponent or @Seam) as opposed to the current Ant task that instruments classes based on their directory or package pattern. I think this would fall a little more inline with seam components that are instrumented or proxied at runtime because they are annotated with @Name.

One concern to the implementation I had thoughts about was in regards to inner classes and anonymous inner classes. I think the instrumentor, when it encounters a @WicketComponent annotated class, should traverse the hierarchy of inner classes and anonymous inner classes to instrument them as well as the parent class.

Does anyone have any other thoughts or ideas on this wicket annotation instrumentor? Please Let me know.

[cpopetz]

I think this is a reasonable suggestion.  Currently I have local changes to implement the following instrumentation approaches for wicket components:

1. At runtime in WEB-INF/wicket through the classloader supplied to the WicketFilter


2. At runtime with the instrumentation (ClassFileTransformer) interface, i.e. useing -javaagent:<path-to-wicket-jar>, which then uses a system property representing patterns of packages to instrument


3. At build time with an ant task, which looks at the set of paths passed in


4. At build time with a maven plugin, which looks at the set of paths passed in.

Giving each of these the option to pay attention to an annotation as an option, rather than looking at paths and patterns, would be a good addition.  Please open a JIRA feature request.  I also agree that non-static nested classes (including anonymous) should be instrumented iff the parent is.

I personally like (2) for development, because I don't have to worry about keeping things in synch, I just run jetty from eclipse with -javaagent without even building a war.  I use (4) for the final war that goes to deployment, but not everyone uses maven (I only just started, in fact), so (3) has to stick around.

Also, you should be aware that if the code in question has to look at an annotation rather than a package/path it will be inherently slower, because it will have to build metadata for each class file in order to determine if it needs instrumentation.  That would be an unacceptable performance hit for large code bases (like mine), particularly for (2), as it sees every class that's loaded.

[paulmooney]

I'm a little late to the party but I've finally opened a JIRA:

My Link

On another note:
Clint you've mentioned a maven plugin. Is that currently available in any repositories (even if it's a snapshot)? Is there any information available (usage,configuration, or source code) for this plugin?

[cpopetz]

I'm in the process of getting that plugin into the jboss repository at the moment; should be no more than a day or two.

-Clint

[paulmooney]

I just saw that this Feature Request is done, thanks Clint!

I'm excited for Seam 2.1.2, and the maven plugin. I like that you've kept the package/class set arguments for the javaagent and ant task in order to make the instrumentation scan more efficient.

You should get Pete Muir to include a piece on Wicket Instrumentation, the different methods available, and the advantages/disadvantages of each when he writes his 3rd 'Seamless Wicket' article.

Thanks again!

[cpopetz]

Paul Mooney wrote on Mar 13, 2009 18:56:


I just saw that this Feature Request is done, thanks Clint!

You are welcome, thanks for the idea.

I'm excited for Seam 2.1.2, and the maven plugin. I like that you've kept the package/class set arguments for the javaagent and ant task in order to make the instrumentation scan more efficient.

You should get Pete Muir to include a piece on Wicket Instrumentation, the different methods available, and the advantages/disadvantages of each when he writes his 3rd 'Seamless Wicket' article.

That's JBSEAM-4010...Pete is quite busy with Web Beans, so I don't know if he'll blog about it, but at least it will be documented in the reference.

Speaking of this, once Seam uses WebBeans for injection, all of this instrumentation will go away, because we'll just post-process wicket components onComponentInstantiation() to inject WebBeans proxies.  (That's in the works, actually.)