You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Joachim Draeger <jd...@gmx.de> on 2006/09/23 10:58:52 UTC
OSGi: the only choice for component life-cycle management?
Hi!
Having my hands in Avalon a few thoughts came to my mind concerning James future
and OSGi.
Well I think I have an idea now what OSGi is. But I'm still trying to find out
what it DOES. :-) (I'm really a novice and may be totally wrong)
AFAIK it doesn't help us with DI and IOC and configuration things. It provides a
base for dynamic reconfiguration (setting values) but for James needs it seems
like it would have to be much extended. (But it's even a good thing to have a
standard base)
But what it is able to do is really powerful: assembling and updating bundles on
the fly without any restart.
So it would be possible to change implementation of the different bundles
(services) like spoolmanager, pop3 or imap server. What's even more interesting:
changing implementations of different custom mailets or adding other extensions
without any restart.
And I guess to do so it much messes around with the class loader and such stuff.
There are many choices of choosing a container for DI/configuration stuff. And I
think even Avalon is not that bad.
But for that life-cycle management on the run there *only* seems to be OSGi.
Am I missing some other framework?
IMHO restarting servers sucks. ;-)
The following mail was quite informative for me:
http://www.mail-archive.com/server-dev@james.apache.org/msg06460.html
Joachim
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: OSGi: the only choice for component life-cycle management?
Posted by Guillermo Grandes <gu...@gmail.com>.
Hi Joachim,
You can see another options (for Mailets / SMTPHandlers)...
http://issues.apache.org/jira/browse/JAMES-599
http://issues.apache.org/jira/browse/JAMES-633
But... config.xml is not auto-reloadable... if you change this.... need to
reload (at the moment ;-))
Guillermo
----- Original Message -----
From: "Joachim Draeger" <jd...@joachim-draeger.de>
To: "James Developers List" <se...@james.apache.org>
Sent: Thursday, September 28, 2006 11:43 AM
Subject: Re: OSGi: the only choice for component life-cycle management?
> 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.
>
[...cut...]
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: OSGi: the only choice for component life-cycle management?
Posted by "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
Re: OSGi: the only choice for component life-cycle management?
Posted by Joachim Draeger <jd...@joachim-draeger.de>.
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
> If I
> understood it correctly there is nothing that stop you from writing an
> Avalon container that is able to reload single services/components on
> the fly.
Who is doing the classloader stuff in that case?
And yes we had to write such management on our own.
Joachim
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: OSGi: the only choice for component life-cycle management?
Posted by Stefano Bagnara <ap...@bago.org>.
Hi Joachim,
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 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.
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).
Furthermore I think that Avalon is a simple specification for
components, while OSGi is more a specification for containers. If I
understood it correctly there is nothing that stop you from writing an
Avalon container that is able to reload single services/components on
the fly.
Stefano
Joachim Draeger wrote:
>
>
> Hi!
>
> Having my hands in Avalon a few thoughts came to my mind concerning
> James future and OSGi.
> Well I think I have an idea now what OSGi is. But I'm still trying to
> find out what it DOES. :-) (I'm really a novice and may be totally wrong)
> AFAIK it doesn't help us with DI and IOC and configuration things. It
> provides a base for dynamic reconfiguration (setting values) but for
> James needs it seems like it would have to be much extended. (But it's
> even a good thing to have a standard base)
>
> But what it is able to do is really powerful: assembling and updating
> bundles on the fly without any restart.
>
> So it would be possible to change implementation of the different
> bundles (services) like spoolmanager, pop3 or imap server. What's even
> more interesting: changing implementations of different custom mailets
> or adding other extensions without any restart.
> And I guess to do so it much messes around with the class loader and
> such stuff.
>
> There are many choices of choosing a container for DI/configuration
> stuff. And I think even Avalon is not that bad.
> But for that life-cycle management on the run there *only* seems to be
> OSGi.
> Am I missing some other framework?
>
> IMHO restarting servers sucks. ;-)
>
> The following mail was quite informative for me:
> http://www.mail-archive.com/server-dev@james.apache.org/msg06460.html
>
> Joachim
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org