Re: OSGi: the only choice for component life-cycle management?

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Sep 28, 2006, at 2:43 AM, Joachim Draeger wrote:

> Am Samstag, den 23.09.2006, 18:44 +0200 schrieb Stefano Bagnara:
>
>> phoenix is able to reload an application or to deploy a new  
>> application
>> without restarting the full container. If you put a new sar file  
>> in the
>> apps folder it try to deploy it.
>> Maybe we could add some management code to make an sar-restart  
>> without a
>> phoenix restart
>
> When everything is in one SAR it makes no sense. Then I could also
> restart whole phoenix.
> The question is: It is possible to put e.g. Mailets in an  
> additional SAR
> and add, swap and remove them while running.
> Of course the utilizing services have to be aware of that. They  
> have to
> be notified and reconfigured.
>
>> but keep in mind that OSGi is not the holy grail in
>> this: just remember that most time you install new plugins or update
>> plugins in Eclipse you have to restart Eclipse... and eclipse is  
>> based
>> on OSGi. This simply happens because not only the container have to
>> support dynamic reloading, but the components must be aware of  
>> this and
>> this need work.
>
> Right. And it's obviously not trivial. And the question is do we  
> want to
> go in that direction at all.
> For now OSGi seems to be the only one who supports juggling of  
> services
> and their implementations at run-time out-of-the-box at all.
>
>> Imho we'll stay with Avalon for a lot, and I bet we'll change the
>> container before removing avalon code from our core components (maybe
>> we'll try plexus, maybe we'll write something to wrap an avalon
>> component as an OSGi bundle).
>
> Is Plexus able to do online add, swap and remove ?
>
>> Furthermore I think that Avalon is a simple specification for
>> components, while OSGi is more a specification for containers.
>
> Agree. OSGi alone won't help us.  As I understood OSGi can help us in:
>
>  - add, swap and remove services and make the appropriate  
> notifications
>  - wire the services
>  - make notifications for configuration updates
>  - start and stop everything
>
> What I don't like that all the others seem to depend on a monolithic
> "assembly.xml"
>
> But with OSGi we'll still need
>
>  - fine grained DI for the bundles
>  - A configuration framework


Check out http://opensource.atlassian.com/projects/spring/browse/ 
SPR-1802.  If we stick to POJOs, wire up the components in Spring, we  
get OSGi almost for free.  Add some XBean goodness on top and you're  
cookin'!


Regards,
Alan



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