[PROPOSAL] Make Lifecycle mandatory rather than optional

[Mark Thomas <ma...@apache.org>]

Currently, Lifecycle is an optional interface for components. I'd like
to make it mandatory for Server, Service and Container.

My reasons for this are:
1. Much of the current implementation depends on Lifecycle (e.g. JNDI,
configuration) and breaks if the component doesn't implement Lifecycle

2. There is a lot of casting to StandardXXX to access Lifecycle methods
that could be removed. This would enable a much wider use of interfaces
rather than concrete classes throughout the codebase.

3. Lifecycle is easy to implement, particularly with the
LifecycleSupport class

4. Implementing some of the Servlet 3.0 dynamic configuration requires
knowledge of the Context Lifecycle so Context is going to have to
support Lifecycle, possible with some additions to that interface.[1]

Whilst making Lifecycle mandatory, does add an additional burden for
those writing custom Tomcat components I would argue that the savings
from addressing point 2 (which would be eased by this change and the
associated clean-up) more than outweighs the burden from point 3.

Unless there are any objections, I plan to start implementing this in
the next day or so.

Cheers,

Mark

[1] Note the current Servlet 3.0 implementation for dynamic
configuration whilst it looks complete won't actually work. The
Lifecycle changes are required to Context to get this working.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: [PROPOSAL] Make Lifecycle mandatory rather than optional

[Mark Thomas <ma...@apache.org>]

On 15/02/2010 14:42, Konstantin Kolinko wrote:

Thanks for the feedback. All my comments below are preliminary ideas I
have had whilst trying to figure out how best to clean this up. Nothing
is absolute at this stage but whichever way I thought of things adding
Lifecycle to Container always seemed to make things neater hence my
proposal in that area first.

Other proposals may follow depending on how the ideas below pan out. If
I feel things are getting too invasive, I'll put forward a proposal
before I start to commit.

> 2010/2/15 Mark Thomas <ma...@apache.org>:
>> Currently, Lifecycle is an optional interface for components. I'd like
>> to make it mandatory for Server, Service and Container.
> 
> +1, Let's make it mandatory.
> 
> I agree with 1.,2.,3. of your reasons.
> 
> Cannot comment on 4. as I do not know that subject. Is there any
> outline of those changes?

Not yet. Only rough ideas at this stage. In short, I'll need to be able
to tell what stage in the Lifecycle the context is in. I am thinking
something along the lines of getLifecycleState(). How fine-grained the
states will be is TBD. I'll almost certainly use LifecycleSupport to
implement this and use the various events to trigger a change in state.

> a) Lifecycle has two methods, start() and stop(), and implementors of
> those have to fire three events each. The JavaDoc for start()/stop()
> mentions only one event of those three.
> 
> E.g. for start() those are BEFORE_START_EVENT, START_EVENT,
> AFTER_START_EVENT, but only START_EVENT is mentioned.

I didn't mention this as I wanted to keep the proposal clean. One of the
things I'd like to do as better define what events a method is expected
to call, when they should be called and what they signify.

eg (more for example than a hard definition at this stage):
BEFORE_START_EVENT - fires as early as possible in start() once the
component has determined it is going to try to start. If start() is
aborted because the component has already started, this event will jot fire.
START_EVENT - fired once the component is sufficiently started that
dependent components may start().
AFTER_START_EVENT - fired at the very end of the start() method and
indicates start() was successful.

> b) Server, Service also implement initialize() method. It is a part of
> their lifecycle, but it is not present in the Lifecycle interface, and
> there exists Lifecycle.INIT_EVENT.
> 
> The JavaDoc for Server#initialize() says "This is used to allow
> connectors to bind to restricted ports under Unix operating
> environments." so there is a specific reason to have it separated from
> start().

I'm TBD on whether this should be added to the Lifecycle interface. The
pragmatic approach is to see how many components use it and how many do
not. If the majority implement it then it can be added.

> c) There is also Lifecycle.DESTROY_EVENT, fired by
> StandardContext.destroy(). Also, not a part of the Lifecycle
> interface.
> 
> The JavaDoc comment for StandardContext.destroy() explains why it was needed.

init() and destroy() are mainly used for MBeans. My thinking here is to
create an MBeanLifecycle interface that extends MBeanRegistration. This
could potentially allow for another fair chunk of clean-up.

> d) Once stop() is called, you cannot reuse the component by calling
> start(). You have to destroy it and call start() on a new instance of
> it. It is already mentioned in JavaDoc for Lifecycle.stop(), "This
> method should be the last one called on a given instance of this
> component.".
> That is what was once asked and replied on the users@ list. (Somebody
> using an embedded Tomcat instance was trying to stop() and then
> start() it).

That does vary between components. Some will let you start/stop (eg
Context) some won't. That might need better documentation. Maybe a
restartable marker interface?

> e) Reaction when start() fails (throws a LifecycleException):
> 
> I think that the component failing to start should be removed from service,
> (as JavaDoc says "@exception LifecycleException if this component
> detects a fatal error
> that prevents this component from being used")
> 
> but that was not the case in all places - see BZ 48625 and its fix (r752323)
> Though that might have been an occasional error - I have not searched
> all places.

Agreed. There was a nastier one where a context would continue if a
filter didn't start. If the filter implemented your application's
security...

Mark



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: [PROPOSAL] Make Lifecycle mandatory rather than optional

[Konstantin Kolinko <kn...@gmail.com>]

2010/2/15 Mark Thomas <ma...@apache.org>:
> Currently, Lifecycle is an optional interface for components. I'd like
> to make it mandatory for Server, Service and Container.

+1, Let's make it mandatory.

I agree with 1.,2.,3. of your reasons.

Cannot comment on 4. as I do not know that subject. Is there any
outline of those changes?


My own observations wrt. to Lifecycle are the following:
These are not to object this proposal, but just mere observations.

a) Lifecycle has two methods, start() and stop(), and implementors of
those have to fire three events each. The JavaDoc for start()/stop()
mentions only one event of those three.

E.g. for start() those are BEFORE_START_EVENT, START_EVENT,
AFTER_START_EVENT, but only START_EVENT is mentioned.


b) Server, Service also implement initialize() method. It is a part of
their lifecycle, but it is not present in the Lifecycle interface, and
there exists Lifecycle.INIT_EVENT.

The JavaDoc for Server#initialize() says "This is used to allow
connectors to bind to restricted ports under Unix operating
environments." so there is a specific reason to have it separated from
start().


c) There is also Lifecycle.DESTROY_EVENT, fired by
StandardContext.destroy(). Also, not a part of the Lifecycle
interface.

The JavaDoc comment for StandardContext.destroy() explains why it was needed.


d) Once stop() is called, you cannot reuse the component by calling
start(). You have to destroy it and call start() on a new instance of
it. It is already mentioned in JavaDoc for Lifecycle.stop(), "This
method should be the last one called on a given instance of this
component.".
That is what was once asked and replied on the users@ list. (Somebody
using an embedded Tomcat instance was trying to stop() and then
start() it).


e) Reaction when start() fails (throws a LifecycleException):

I think that the component failing to start should be removed from service,
(as JavaDoc says "@exception LifecycleException if this component
detects a fatal error
that prevents this component from being used")

but that was not the case in all places - see BZ 48625 and its fix (r752323)
Though that might have been an occasional error - I have not searched
all places.


Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: [PROPOSAL] Make Lifecycle mandatory rather than optional

[Filip Hanik - Dev Lists <de...@hanik.com>]

+1 works for me

On 02/15/2010 03:23 AM, Mark Thomas wrote:
> Currently, Lifecycle is an optional interface for components. I'd like
> to make it mandatory for Server, Service and Container.
>
> My reasons for this are:
> 1. Much of the current implementation depends on Lifecycle (e.g. JNDI,
> configuration) and breaks if the component doesn't implement Lifecycle
>
> 2. There is a lot of casting to StandardXXX to access Lifecycle methods
> that could be removed. This would enable a much wider use of interfaces
> rather than concrete classes throughout the codebase.
>
> 3. Lifecycle is easy to implement, particularly with the
> LifecycleSupport class
>
> 4. Implementing some of the Servlet 3.0 dynamic configuration requires
> knowledge of the Context Lifecycle so Context is going to have to
> support Lifecycle, possible with some additions to that interface.[1]
>
> Whilst making Lifecycle mandatory, does add an additional burden for
> those writing custom Tomcat components I would argue that the savings
> from addressing point 2 (which would be eased by this change and the
> associated clean-up) more than outweighs the burden from point 3.
>
> Unless there are any objections, I plan to start implementing this in
> the next day or so.
>
> Cheers,
>
> Mark
>
> [1] Note the current Servlet 3.0 implementation for dynamic
> configuration whilst it looks complete won't actually work. The
> Lifecycle changes are required to Context to get this working.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>    


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org