I talked with Aaron Mulder and Dain a bit on IRC -- they originally
implemented most of this IIRC. We can't remember any reason for
restart not to create new classloaders.
Ivan is definitely correct that restart of a plugin will result in the
same plugins being started as before the restart command, whereas stop/
start will not. I think this is desirable.
I don't understand what Jack is proposing. I'd like to see if we can
change the restart command to create new classloaders. I don't want
to change the current behavior of stop and start.
Here's an example of why we should not try to make stop/start remember
child modules:
A and B are independent modules and C depends on both A and B.
Stop A >> C stops
Stop B
Start A >> C can't start
Start B >> no way to know for sure if we want C to start.
thanks
david jencks
On Aug 12, 2009, at 10:48 PM, Jack Cai wrote:
So we can't do a simple “stop(); start();" call to achieve
"restart()" in the implementation. We need to implement it in a non-
trivial way.
1. Stop all configs that would otherwise be stopped in a "stop()"
operation;
2. Reverse this list of configs and do a start.
There is some complexity to handle in the
o.a.g.kernel.config.ConfigurationStatus class.
-Jack
On Thu, Aug 13, 2009 at 1:32 PM, Ivan <[email protected]> wrote:
Sometimes, restart is not equal to stop+start. Let's take an
example, component A is depending on component B.
While you restart B, Geronimo will do the actions like
1. stop A
2. stop B
3. start B
4. start A
But while you stop B, we have to stop A too, but we have no way to
record that A should be started while you start B in the future, so
A will not be started while you start B again.
Wish it helps !
2009/8/13 Jack Cai <[email protected]>
Agreed. Restart should have the same effect as "Stop + Start".
In the "o.a.g.kernel.config.ConfigurationStatus, "gc" is enabled for
stop by default, but there is no gc option (stop parent) for
restart. Maybe that's the place to modify?
-Jack
On Thu, Aug 13, 2009 at 8:19 AM, Kevan Miller
<[email protected]> wrote:
On Aug 12, 2009, at 6:08 AM, Ashish Jain wrote:
Hi,
Recently I have seen difference in the functionality of stop/start
and restart options available against each module. In case of stop/
start I see old classloaders
being discarded and new ones being created. In case of restart same
old classloaders are used.
I am attaching a sample DummyProject here and an explanation of how
it works
It has three classes: TestServlet , TestService and TestBean
1. Request comes to the TestServlet => Console prints “In TestServlet”
2. TestServlet makes a call to the TestService class. TestService
class has a static variable called testBean of type TestBean. This
variable is an initialized during class loading.
4. When the call comes to TestService, if the static variable is
created then the Console prints “In TestBean constructor”. In case
the static variables isn't created then this statement doesn’t get
printed to the console.
5. After which console prints “In TestService class”
Steps to run the application:
1. Deploy this application to WAS community edition
2. Start the application
3. Hit the <WAS url>/<context>/TestServlet
4. Check the console
If static variables are created then all the three statements must
appear as below in the console:
=> In TestServlet
=> In TestBean constructor
=> In TestService class
Restart the application and follow steps 2, 3 and 4. Notice only
first and last statements ('In TestServlet' & ' In TestService
class') appear indicating that static variables aren't created. But
when stop and the start this application, all the 3 statements appear.
I would like to know if this difference is intended or does it
require some fix so that restart behaves in a similar manner as stop/
start?
I'm not sure. My guess is that the differences are unintended, but
I'd have to spend some time to be sure... There may be some
consequences to changing this behavior. David J may have thoughts on
this...
A Stop is going to stop a configuration, then unload the
configuration (which will destroy the ClassLoader).
A restart is going to stop a configuration, then start the same
configuration (reusing the same ClassLoader). Thus any static
initialization would have already occurred.
Personally, I think a Restart should be functionally equivalent to
Stop/Start.
--kevan
--
Ivan
