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.
>
> Thanks,
> Sahoo
For Legolas this is not enough. If Legolas would for example - use a
ServletContextListener - the Listener would not get notified of the
enabling. I have just verified that using GF v2 UR 1. So most probably
for the init()-method of a Servlet .
A redeploy on the other hand would result in the correct notification.
But I do agree. This should be documented - if it is not already.
Regards,
Wolfram
> 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
>
>