Hi Alessio,
On 05/30/2013 07:37 PM, Alessio Soldano wrote:
Hi Jim,
On 05/30/2013 08:21 AM, Jim Ma wrote:
to be honest, it's not a matter of users here, we're talking about an
interface that's used for container integration needs. So, the reason
why we had that LifeCycleHandler thing was afair to have clear control
point for the endpoint start/stop. During undeploy, the first thing we
do is stopping the endpoint, which basically close the processing of
requests, allowing the undeploy process to do what it has to do.
So, any solution we come out with needs to ensure we immediately stop
processing incoming requests as the first step of the undeploy process.
So just please make sure that moving stuff in the EndpointService
satisfies this "requirement".
I thought the LifeCycleHandler somewhat
likes the EndpointStart/Stop
Listener.
Thanks for pointing this. For this reason, we should keep the
LifeCyelcHandler.
This could be the only thing we can improve or refactor :
ATM, The LifeCycleHandler is executed in EndpointServiceDA after the
EndpointService installed.
There is no code to check if the EndpointService is started or failed,
The EndpointServiceDA takes it as
sucessfully installed and set the Endpoint state to STARTED in the
LifeCycleHandler. Is it necessary
we check the EndpointService's status before set the Endpoint state ? is
it better that we execute
the LifecycleHandler in the EndpointService.start() ?
Thanks,
Jim