[
https://jira.jboss.org/jira/browse/JBSEAM-3621?page=com.atlassian.jira.pl...
]
Clint Popetz updated JBSEAM-3621:
---------------------------------
Attachment: seam-wicket-hotel-example-hotdeploy.patch
Here's a patch that modifies the wicket hotel example to instrument the wicket
components at build time if the instrumentAtBuildTime property is set, which it is by
default. If debug=true, the resulting classes are hot deployed to dev. If not,
they're put in WEB-INF/classes.
Note that the existing build compiled the wicket classes directly to WEB-INF/wicket.
I've changed this to build them to build-web/, instrument them to instrumented-web,
and then copy from either to the correct location in the exploded archive. Also, I keep a
cache file around to only instrument files that are changed, as instrumentation isn't
cheap.
I was able to modify wicket classes on the fly with this change.
Support hot-deployment of instrumented wicket components
--------------------------------------------------------
Key: JBSEAM-3621
URL:
https://jira.jboss.org/jira/browse/JBSEAM-3621
Project: Seam
Issue Type: Patch
Reporter: Clint Popetz
Assignee: Pete Muir
Fix For: 2.1.1.CR1
Attachments: seam-hot-deploy-wicket.diff, seam-hot-deploy-wicket2.diff,
seam-wicket-hotel-example-hotdeploy.patch, WicketFilter.java.patch
Attached is a patch to add support for hot deployment of wicket components that have been
instrumented by the wicket instrumentation ant task from JBSEAM-3505. That patch should
be applied first to avoid conflicts.
The elements of this patch are:
* I need access to the HotDeploymentStrategy from the wicket classloader, but it's
currently only exposed in the event context for the duration of startup. I've changed
this to place it in the application context. I don't know if that's correct, but
it seemed like a reasonable place to store it. So HotDeploymentStrategy now does this in
its constructor.
* Initialization.redeploy now calls ServletLifecycle.beginReinitialization before
createHotDeployment so that the app context exists. This puts createHotDeployment in the
same contextual surroundings as its other invocation in Initialization.init().
* The WicketFilter needs to be re-initialized upon redeployment. So WicketFilter now
delays initialization of the delegate (the @Unwrapped anonymous subclass of wicket's
own WicketFilter) until the first actual request, and at each request it checks a stored
initTime against Init.getTimestamp(). If they've changed, it re-inits. Also, I place
WicketFilter within the HotDeployFilter via @Filter(within), so that all of this can work.
This survives the absence of the HotDeployFilter, i.e. if you deploy without
jboss-seam-debug.jar, SeamFilter ignores the missing within reference, and the
WicketClassLoader just uses the thread's contextClassLoader for the parent of the
instrumenting class loader.
* WicketClassLoader uses the HotDeploymentStrategy's classloader as the parent
classloader, if it exists. This means that runtime-instrumented wicket components can
reference hot-deployed wicket components, but not vice-versa, similar to how
hot-deployable seam components can reference normally deployed components, but not
vice-versa.
--
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