[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-3621) Support hot-deployment of instrumented wicket components

Pete Muir (JIRA) jira-events at lists.jboss.org
Thu Oct 23 19:18:20 EDT 2008


    [ https://jira.jboss.org/jira/browse/JBSEAM-3621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12435257#action_12435257 ] 

Pete Muir commented on JBSEAM-3621:
-----------------------------------

> I don't store another reference to the HotDeploymentStrategy; I just
> use the one from the app context, and upon a redeployment, that one is
> overwritten by the new one. So I'm not sure how I'm preventing a GC.

Well you change the storage from event scope (short lived) to app scoped (long lived) - I meant you are safe storing the classLoader. If you actually look at the way deploymentStrategy works, you'll see it holds a hard reference to classes and files it discovers that might be interesting to users. I don't want to hold these references for longer than essential.

> In any case, you are correct that I only need the classloader, but
> would storing that in the app context prevent GC as well? 

No you can hold the classLoader for as long as you like. Can you not store it in the appContext directly (as someone will abuse this) but grab it during (re)init and store it where you need it?

> 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
>
>
> 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

        



More information about the seam-issues mailing list