>>>> 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?
>>> I did not do it at module level, I didn't know that's even possible.
>>> Instead, I disabled the whole application before re-enabling it again.
I'm afraid both of us are right. :)
When you disable an EAR, then each of the contained WARs will be unloaded
(by calling the WebContainer's unloadWebModule()), meaning a subsequent
re-enabling of the EAR will reload and therefore restart each of the
This is different from the standalone case: when you disable a
standalone WAR, the
WebContainer's disableWebModule() is called, which merely marks the web
as unavailable, so that a subsequent re-enabling won't reload or restart
the web module,
but only mark it as available.
Can you file an issue (against deployment) for this? This should be made
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
I think that there is benefit in being able to restart webapps individually, even even those within EARs. I also think there should be a distinction between enabling, restarting, and redeploying.
Off the top of my head, disabling should essentially stop the listener from "seeing" the webapp. The webapp may internally still be running (so, for example, if it had any recurring threads they may still run), but the application is efectively dead to the web -- everything gets 404 errors, etc for URLs using the webapp.
We should also be able to stop and restart webapps. A Stopped web app is one that's unloaded from the server, but still "deployed". By unloaded, I mean all of the shutdown lifecycle events have been called, and classes unloaded from memory. If you start a stopped web app, it's no different than if the server is starting up (though server start up may have a different lifecycle event than webapp start up). If someone wanted to "reboot" a webapp (clearing out its singletons, etc.), then stopping and starting the webapp would do the trick.
The final event is deployment. This is when the application is being deployed and configured to run within the container. Standalone webapps should be able to be "redeployed" in place, with all of their server options given to it during original deployment retained (for example, virtual servers, which is not done now).
Webapps bundled within EARs can NOT be redeployed individually of their EAR, but they CAN BE disabled/enabled, and stop/started independent of their EAR.
I think there should be an option that the state of the webapp (disabled, stopped, etc.) should survive survive server restart (so if I have a disabled webapp, and the server restarts, it should still be disabled on startup).
I do not know how this should apply to Web Services deployed on Session Beans. I would think that they should at least be able to be disabled.
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.