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
>