The scheme for specifying a LifestyleManager from the kernel.xml profile
is not quite ready for prime time.
An instance of DefaultLifestyleManager is set up
initially and attached to the KernelManager.
Then the kernel.xml configuration is checked for a lifestyle manager
specification, and if present, it is classloaded and semi-lifecycled.
It gets only enableLogging, configuration, initialization.
To properly set up DefaultLifestyleManager, contextualization with
the pool manager is needed.
I am not clear on how the second lifestyle manager ends up over-riding
the first one, but it does.
Since the example kernel.xml from merlin
has the DefaultLifestyleManager specified in the kernel.xml file as the
LifestyleManager, the resulting setup is broken for pooling. Ironic,
since the DefaultLifestyleManager should work perfectly for pooling!
Gary
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
