users@glassfish.java.net

Re: How I can restart a single web application in glassfish?

From: <Jan.Luehe_at_Sun.COM>
Date: Thu, 07 Feb 2008 10:56:09 -0800

sahoo,

Sahoo wrote:

> Jan,
>
> I don't think this is how server behaves though. I tried with GF v2
> (post FCS) build. When I enable using the admin gui, it reloads the
> entire the application including creating a new class loader. This is
> the stack trace that shows that we do create a new class loader during
> re-enable:
> <init>():247, WebappClassLoader.java
> ...
> createClassLoader():842, WebappLoader.java
> start():721, WebappLoader.java
> start():5053, StandardContext.java
> start():327, WebModule.java
> addChildInternal():973, ContainerBase.java
> addChild():957, ContainerBase.java
> addChild():688, StandardHost.java
> loadWebModule():1222, WebContainer.java
> loadJ2EEApplicationWebModules():1147, WebContainer.java
> doLoad():141, TomcatApplicationLoader.java
> load():244, AbstractLoader.java
> applicationDeployed():336, ApplicationManager.java
> invokeApplicationDeployEventListener():934,
> AdminEventMulticaster.java
> handleApplicationDeployEvent():912, AdminEventMulticaster.java
> processEvent():461, AdminEventMulticaster.java
> multicastEvent():176, AdminEventMulticaster.java
> sendNotification():141, AdminNotificationHelper.java
> postInvoke():122, ConfigInterceptor.java
> invoke():110, ProxyClass.java
> setAttribute():475, MBeanProxyHandler.java
> ...
> setEnabled():-1
> ...
> setApplicationEnabled():253, TargetUtil.java
> ...
> run():116, WorkerThreadImpl.java
>
> Do we actually document the behavior one way or the other? I tested
> with an ear which had an ejb module and web module. Is it possible
> that what you mentioned holds good for pure web app? It would be too
> bad if that is the case.


i have limited capabilities debugging this right now since i have only
one hand to type, but there
is code in WebContainer.loadWebModule which checks whether a context
(web module)
already exists at the context root specified during deployment. if a
context already exists at the
specified root, the code performs various checks, including a check if
the existing context has
been disabled. if so, the context is re-enabled, by setting its
"available" property to true and
returning, ie., the module is not reloaded in this case:

        WebModule ctx = (WebModule)vs.findChild(wmContextPath);
        if (ctx != null) {
            [....]
            } else if (!ctx.getAvailable()){
                /*
                 * Context has been marked unavailable by a previous
                 * call to disableWebModule. Mark the context as
available and
                 * return
                 */
                ctx.setAvailable(true);
                return null;
            } else {
                [....]
            }
        }

this is the code path that should have been invoked when you re-enable a
standalone or ear-embedded webmodule.

did you disable the module before re-enabling it?

thanks,

jan



>
> Thanks,
> Sahoo
> glassfish_at_javadesktop.org wrote:
>
>> as for the difference between disabling and re-enabling vs
>> redeploying a webapp, notice that disable merely sets a flag in the
>> webcontext, causing any requests for any of the webapp's resources to
>> result in a 503 response, which indicates that the service is
>> unavailable. disabling a webapp does not stop the webapp, meaning its
>> webappclassloader (and any of the classes loaded by it) will remain
>> intact.
>>
>> this is different from a redeploy, which creates a new classloader
>> and discards the old one.
>> as for the admingui's redeployment behaviour (which caused a webapp
>> to always be deployed to all virtual servers, even if the webapp had
>> originally been deployed to just a subset of virtual servers), this
>> has been a bug in either the admingui or the deployment code, which
>> is supposed to have been fixed in the upcoming GF v2.1 release.
>> [Message sent by forum member 'jluehe' (jluehe)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=257781
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>