Re: Lifecycle of runtime extensions, was: [DISCUSS] Next version - What should be in it

[Simon Nash]

The problem I have been working on is TUSCANY-1218.  See the problem
desription and the comments on my attached patch for more details of
the problem and how my patch resolves it.

I'm aware of the ModuleActivator.stop() method and I am using it in
my patch for TUSCANY-1218.  However, this isn't sufficient to provide
a complete solution.  This method only gets called when the Axis2
binding extension is unloaded.  If an Axis2 reference binding owns
system resources that need to be released when that reference is
freed but the Axis2 binding extension remains loaded, then there is
currently no solution for this as far as I am aware.

There are start() and stop() methods in ReferenceImpl and ServiceImpl
that should provide a solution by calling start() and stop() methods
for all bindings of the reference or service, but these methods are
currently not being called.  This causes other problems.  For example,
because the start() method in ReferenceImpl is not being called,
a hack has been added to the Axis2ServiceBinding constructor to call
the start() method from the constructor.

I think we need a lifecycle mechanism that's finer grained than
extension modules and can be used to call start() and stop() methods
for a variety of runtime objects such as individual references and
services.  Is there anything currently that can do this?

  Simon

Jean-Sebastien Delfino wrote:

[snip]
Simon Nash wrote:

I agree with the comments from Ant and Simon on focusing on stability
and consumability at the moment rather than adding a large amount of
new function.

I've been working on a complex bug fix recently (watch this space
for a JIRA and patch) and I noticed that we lost some previously
working support for AbstractLifecycle in the recent round of
runtime changes to remove the use of SCA to assemble the Tuscany
runtime.  I have had to code around this to make progress and I
would like to get a good story in place for how we manage the
lifecycle of runtime objects, focusing particularly on destruction
and resource reclamation in long-running scenarios.  Failure to do
this can lead to a variety of problems that are hard to track down.
I would be pleased to work on this to put in place a consistent
approach and document how it works.

  Simon

Simon,

There is support for managing the lifecycle of runtime extensions. ModuleActivators must implement the ModuleActivator.start() and stop() methods, and cleanup their state in the stop() method. Could you describe the specific problem you've run into? Is one of the ModuleActivators in particular not implementing stop() correctly?

Thanks

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]