[seam-dev] Wicket integration work

[Clint Popetz]

Greetings,
I've been working on wicket integration, and I have a number of things done
that I'd like to contirbute:

* An ant task to instrument wicket components at build time
* Fixes to make it possible to hot-deploy wicket components that have been
instrumented by that task.
* Fixes to problems surrounding inheritance and wicket components.
   (Currently if you try to inherit one wicket component from another, and
seam tries to instrument both, you'll hit lots of problems. The fixes are
both in how the components are instrumented and how
WicketComponent/WicketHandler function.)
* Fixes to make it possible for jsf, wicket, and other web tier components
(i.e. struts, using ContextFilter) to co-exist in the same deployment, which
is a requirement of ours.

I'd like to know how you suggest I go about submitting all this.  Should I
create jira issues for each, and then attach the patches to each?  Many are
entangled, so I can do this, but it will be harder for me, and harder for
whomever integrates, as the patches will collide.

For the last one (jsf/wicket co-existence) I'd like to have a discussion on
best practice.  The current approach of having things like
WicketExceptionFilter, WicketManager, and WicketStatusMessages override the
defaults if they are present, based on class dependencies, obviously doesn't
work for the above goal.  Some sort of architecture is needed to use the
correct component based on the type of request, which means we need someone
to say "whose request is this?"  Should that discussion happen on this list,
or through jira issue comments?

Also, with regard to the ant task, I don't know how you want that packaged.
 Is the plan to keep the just-in-time instrumentation of WEB-INF/wicket
(which isn't hot-deployment-compatible) as an option, with build time
instrumentation as the default (i.e. the default in seam-gen'd build files?)
Or get rid of the just-in-time thing?  Currently I have
JavassistInstrumentor extending extending org.apache.tools.ant.Task, but I
have it in a separate project to build the task jar.  It also could remain
in jboss-seam.jar.

I'm very happy with the results.  JSF/RichFaces has  unfortunately been a
nightmare for us in terms of maintainability, testability, and general
bugginess, butI didn't want to dump seam's contextual model, security
support, and event support in order to move to Wicket.  I'm very glad I
don't have to do so :)

Thanks,
-Clint
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20081017/ec603c01/attachment.html