cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: Startable components
Date Mon, 17 Oct 2005 20:27:35 GMT
Carsten Ziegeler wrote:
> Sylvain Wallez wrote
>   
>> - portal: AbstractComponent (so that they're registered as event listeners)
>>
>>     
> I guess you forgot to commit this :) Anyways I just did the changes.
>   

Oops sorry, I forgot to add "src/blocks/portal" in the commit command 
line :-/

> But I'm wondering what the best way to solve this problem is. Now
> preloading components implementing Startable is imho the right way. But
> it seems not so good for me that every component that should be
> preloaded must implement the Startable interface. In most cases the
> start and stop method simply do nothing.
> So, would it be better to add an additional marker interface? Don't know.
>   

Yeah, I thought about this also and wondered if a "Preloadable" marker 
interface in o.a.c.core would be the way to go. But that AFAICS 
components currently have no dependency on the core. Or we can put it in 
o.a.c.components.

> The portal uses an event mechanism, so every subscriber has to be
> preloaded. It seems for me too much work to add the Startable interface
> to all subscribers. What do you think of making the lazy load
> configurable per sitemap? So we can simply turn this on for the portal
> sitemap and forget there about the interface?
>   

Naah... this adds one more layer of configuration, and will break the 
system anyway if people forget to set the configuration in their 
sitemap. Isn't adding Startable to AbstractComponent enough, or do you 
prefer an additional interface?

> I don't know what the best solution is but I think Startable is not :)
>   

So let's go for a Preloadable marker interface.

But we then have to decide if Startable is also implicitely means 
preloadable. Looking at the components that implement Startable both in 
Cocoon and Excalibur, it looks like Startable is used to start some 
background processing (although this could equally be done in 
initialize()), but makes no assumption about _when_ this should be started.

So I would then revert my changes and add Preloadable where needed.

Thoughts?

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://people.apache.org/~sylvain     http://www.anyware-tech.com
Apache Software Foundation Member     Research & Technology Director


Mime
View raw message