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 Bernd Fondermann <bf...@brainlounge.de> on 2008/01/31 05:13:37 UTC
James OSGi Bundle
Hi,
with the release of the OSGi extension to Spring[1], it seems to be
reasonably easy to turn any spring app into an OSGi deployment ('bundle').
I'd like to try and make the spring deployment OSGi-deployable this way.
In a first step, this would only mean 'deployable'. I would defer
exposing any interfaces as OSGi services or even splitting James into
multiple bundles.
Any comments?
Bernd
[1] http://www.springframework.org/osgi
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James OSGi Bundle
Posted by Danny Angus <da...@apache.org>.
On Jan 31, 2008 4:13 AM, Bernd Fondermann <bf...@brainlounge.de> wrote:
> Hi,
>
> with the release of the OSGi extension to Spring[1], it seems to be
> reasonably easy to turn any spring app into an OSGi deployment ('bundle').
>
> I'd like to try and make the spring deployment OSGi-deployable this way.
>
> In a first step, this would only mean 'deployable'. I would defer
> exposing any interfaces as OSGi services or even splitting James into
> multiple bundles.
>
> Any comments?
+1 I Like it. I must try the spring deployment.
d.
>
> Bernd
>
> [1] http://www.springframework.org/osgi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James OSGi Bundle
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Feb 8, 2008 10:33 AM, Stefano Bagnara <ap...@bago.org> wrote:
>> Danny Angus ha scritto:
>>> Get it now?
>> No. What is the problem in redeploying all the processors every time you
>> need to redeploy one of them? You will have to stop the spoolmanager
>> thread anyway, so I don't see a big advantage in the big effort needed
>> to be able to redeploy a single processor (It would require much more
>> changes in our CoP, than full spoolmanager redeploy).
>
> shoulnd't need to stop the master thread, just the worker for the
> processor in question.
There is no "worker for a processor" concept right now. Threads are
started from the spoolmanager, they wait (blocking call) for a new
message in the spoolrepository and when a message is returned they look
at the state of the message and they run the mail through the associated
processor (if you use the default StateAwareProcessorList implementation).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James OSGi Bundle
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Feb 8, 2008 10:33 AM, Stefano Bagnara <ap...@bago.org> wrote:
> Danny Angus ha scritto:
> > On Feb 5, 2008 3:09 PM, Stefano Bagnara <ap...@bago.org> wrote:
> >
> >> I'm not sure I understand the advantages of the redeploy of a single
> >> processor.
> >
> > Processors are bigger than collections of mailet/matchers, they can
> > invoke one another and can be implemented in different ways, e.g.
> > jsieve.
> >
> > They are in fact "Mail Applications"
> >
> > I've always said (well for several *years* anyway) that we should
> > allow archived processors with their config archived with them in a
> > WAR-like structure to be deployed in James simply by dropping them in.
> > Then you just have to set up a "to processor" rule to have mail
> > handled by the app you've deployed.
+1
> > Get it now?
>
> No. What is the problem in redeploying all the processors every time you
> need to redeploy one of them? You will have to stop the spoolmanager
> thread anyway, so I don't see a big advantage in the big effort needed
> to be able to redeploy a single processor (It would require much more
> changes in our CoP, than full spoolmanager redeploy).
shoulnd't need to stop the master thread, just the worker for the
processor in question.
> About this topic you may remember I refactored the spoolmanager code to
> be more modular and you now are able to specify the class for the main
> processor (default to StateAwareProcessorList) and in that case you can
> specify a different class for each "state" processor (default to
> LinearProcessor). This code is in trunk since may 2006:
> http://issues.apache.org/jira/browse/JAMES-491
cool
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James OSGi Bundle
Posted by Stefano Bagnara <ap...@bago.org>.
Danny Angus ha scritto:
> On Feb 5, 2008 3:09 PM, Stefano Bagnara <ap...@bago.org> wrote:
>
>> I'm not sure I understand the advantages of the redeploy of a single
>> processor.
>
> Processors are bigger than collections of mailet/matchers, they can
> invoke one another and can be implemented in different ways, e.g.
> jsieve.
>
> They are in fact "Mail Applications"
>
> I've always said (well for several *years* anyway) that we should
> allow archived processors with their config archived with them in a
> WAR-like structure to be deployed in James simply by dropping them in.
> Then you just have to set up a "to processor" rule to have mail
> handled by the app you've deployed.
>
> Get it now?
No. What is the problem in redeploying all the processors every time you
need to redeploy one of them? You will have to stop the spoolmanager
thread anyway, so I don't see a big advantage in the big effort needed
to be able to redeploy a single processor (It would require much more
changes in our CoP, than full spoolmanager redeploy).
About this topic you may remember I refactored the spoolmanager code to
be more modular and you now are able to specify the class for the main
processor (default to StateAwareProcessorList) and in that case you can
specify a different class for each "state" processor (default to
LinearProcessor). This code is in trunk since may 2006:
http://issues.apache.org/jira/browse/JAMES-491
HTH,
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James OSGi Bundle
Posted by Danny Angus <da...@apache.org>.
On Feb 5, 2008 3:09 PM, Stefano Bagnara <ap...@bago.org> wrote:
> I'm not sure I understand the advantages of the redeploy of a single
> processor.
Processors are bigger than collections of mailet/matchers, they can
invoke one another and can be implemented in different ways, e.g.
jsieve.
They are in fact "Mail Applications"
I've always said (well for several *years* anyway) that we should
allow archived processors with their config archived with them in a
WAR-like structure to be deployed in James simply by dropping them in.
Then you just have to set up a "to processor" rule to have mail
handled by the app you've deployed.
Get it now?
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James OSGi Bundle
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> stefano is right that given our current COP, SpoolManager would have
> to be redeployed
>
> noel and danny are right that for reployment to work elegantly, the
> level of granularity should be the processor
I'm not sure I understand the advantages of the redeploy of a single
processor.
To redeploy a processor you will have anyway to stop the spoolmanager
threads or you will risk to find a mail destinated to an unavailable
processor that currently results in an error.
The undeploy/redeploy of the whole
spoolmanager/mailetloader/matchersloader chain is not a big issue in
availability because input/output channels like smtp, fetchmail and pop3
will work in the meantime.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James OSGi Bundle
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Feb 5, 2008 1:41 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Danny Angus ha scritto:
> > I agree with noel, processors should be the deployable application
>
> I'm not sure I understand yours and Noel idea. Noel's message seems to
> say that I proposed to redeploy single mailets, instead I proposed to
> redeploy the spoolmanager.
>
> Being able to undeploy and redeploy the spoolmanager then you can alter
> the configuration of each mailet and each processor.
>
> In the current architecture if you don't unload the spoolmanager you
> can't undeploy the mailet/matcher loader and this mean you cannot
> upgrade your mailets or add new mailets. Processors and Mailets are not
> components in our COP, SpoolManager is instead a component.
stefano is right that given our current COP, SpoolManager would have
to be redeployed
noel and danny are right that for reployment to work elegantly, the
level of granularity should be the processor
IMHO this area would be high pay for a relatively small amount of
work. perhaps we could focus on this at the hackathon.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James OSGi Bundle
Posted by Stefano Bagnara <ap...@bago.org>.
Danny Angus ha scritto:
> I agree with noel, processors should be the deployable application
I'm not sure I understand yours and Noel idea. Noel's message seems to
say that I proposed to redeploy single mailets, instead I proposed to
redeploy the spoolmanager.
Being able to undeploy and redeploy the spoolmanager then you can alter
the configuration of each mailet and each processor.
In the current architecture if you don't unload the spoolmanager you
can't undeploy the mailet/matcher loader and this mean you cannot
upgrade your mailets or add new mailets. Processors and Mailets are not
components in our COP, SpoolManager is instead a component.
Btw, this discussion is not so important. Once we'll have some mean to
redeploy components we will discuss what is the best granularity.
Stefano
> On 2/5/08, Noel J. Bergman <no...@devtech.com> wrote:
>> Stefano Bagnara wrote:
>>
>>> The really cool thing would be to have each top level component deployable
>>> as separate osgi bundle, so to be able to undeploy the spool manager,
>>> alter mailet configuration, deploy it back (and other similar things).
>> Mailet configuration seems the wrong place. Pipeline configuration means
>> configuring processors, which could be the deployable unit. Processors are
>> the containers for Mailets. Can you make the argument for why Mailets,
>> themselves, should not be kept simple and far far away from this stuff?
>>
>> --- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James OSGi Bundle
Posted by Danny Angus <da...@apache.org>.
I agree with noel, processors should be the deployable application
On 2/5/08, Noel J. Bergman <no...@devtech.com> wrote:
> Stefano Bagnara wrote:
>
> > The really cool thing would be to have each top level component deployable
> > as separate osgi bundle, so to be able to undeploy the spool manager,
> > alter mailet configuration, deploy it back (and other similar things).
>
> Mailet configuration seems the wrong place. Pipeline configuration means
> configuring processors, which could be the deployable unit. Processors are
> the containers for Mailets. Can you make the argument for why Mailets,
> themselves, should not be kept simple and far far away from this stuff?
>
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
--
Sent from Google Mail for mobile | mobile.google.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James OSGi Bundle
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Feb 2, 2008 8:24 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Bernd Fondermann ha scritto:
> > Hi,
> >
> > with the release of the OSGi extension to Spring[1], it seems to be
> > reasonably easy to turn any spring app into an OSGi deployment ('bundle').
> >
> > I'd like to try and make the spring deployment OSGi-deployable this way.
> >
> > In a first step, this would only mean 'deployable'. I would defer
> > exposing any interfaces as OSGi services or even splitting James into
> > multiple bundles.
> >
> > Any comments?
>
> This is very interesting and a needed first step. The really cool thing
> would be to have each top level component deployable as separate osgi
> bundle, so to be able to undeploy the spool manager, alter mailet
> configuration, deploy it back (and other similar things).
+1
but we'll need to tackle repackaging before we'll be able to do this
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: James OSGi Bundle
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano Bagnara wrote:
> The really cool thing would be to have each top level component deployable
> as separate osgi bundle, so to be able to undeploy the spool manager,
> alter mailet configuration, deploy it back (and other similar things).
Mailet configuration seems the wrong place. Pipeline configuration means
configuring processors, which could be the deployable unit. Processors are
the containers for Mailets. Can you make the argument for why Mailets,
themselves, should not be kept simple and far far away from this stuff?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James OSGi Bundle
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann ha scritto:
> Hi,
>
> with the release of the OSGi extension to Spring[1], it seems to be
> reasonably easy to turn any spring app into an OSGi deployment ('bundle').
>
> I'd like to try and make the spring deployment OSGi-deployable this way.
>
> In a first step, this would only mean 'deployable'. I would defer
> exposing any interfaces as OSGi services or even splitting James into
> multiple bundles.
>
> Any comments?
This is very interesting and a needed first step. The really cool thing
would be to have each top level component deployable as separate osgi
bundle, so to be able to undeploy the spool manager, alter mailet
configuration, deploy it back (and other similar things).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James OSGi Bundle
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Feb 3, 2008 8:30 PM, Bernd Fondermann <bf...@brainlounge.de> wrote:
> Bernd Fondermann wrote:
<snip>
> Spring-osgi (opposed to Spring in a web-container) is not yet ready to
> deal with custom ApplicationContexts (yet). This results in the fact I
> see no easy way currently to boot our components.
>
> Discussion about that is here:
> http://groups.google.com/group/spring-osgi/browse_thread/thread/c0228e1a21760103
i was very tempted to post to that thread saying that what's special
is that we've trying to run a complete email management system ;-)
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James OSGi Bundle
Posted by Bernd Fondermann <bf...@brainlounge.de>.
Bernd Fondermann wrote:
> Hi,
>
> with the release of the OSGi extension to Spring[1], it seems to be
> reasonably easy to turn any spring app into an OSGi deployment ('bundle').
>
> I'd like to try and make the spring deployment OSGi-deployable this way.
>
> In a first step, this would only mean 'deployable'. I would defer
> exposing any interfaces as OSGi services or even splitting James into
> multiple bundles.
I managed to hand-craft a bundle which could be deployed in Apache Felix
(which is our fellow OSGi container, as you probably know).
When it comes to activate our components, in our case it's starting to
get tricky though. It would be easy if we'd have a standard spring
deployment based on the typical spring-xml-config files. But...
We don't have standard. What we have is
a. a classic spring config (which is read by a standard
BeanDefinitionReader) with the basic components for mimicking Phoenix
behavior
_plus_
b. the original Avalon config file which is read by our _custom_
AvalonBeanDefinitionReader.
At startup, both are combined into the non-standard
AvalonApplicationContext.
Spring-osgi (opposed to Spring in a web-container) is not yet ready to
deal with custom ApplicationContexts (yet). This results in the fact I
see no easy way currently to boot our components.
Discussion about that is here:
http://groups.google.com/group/spring-osgi/browse_thread/thread/c0228e1a21760103
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James OSGi Bundle
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Jan 31, 2008 4:13 AM, Bernd Fondermann <bf...@brainlounge.de> wrote:
> Hi,
>
> with the release of the OSGi extension to Spring[1], it seems to be
> reasonably easy to turn any spring app into an OSGi deployment ('bundle').
>
> I'd like to try and make the spring deployment OSGi-deployable this way.
>
> In a first step, this would only mean 'deployable'. I would defer
> exposing any interfaces as OSGi services or even splitting James into
> multiple bundles.
+1
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James OSGi Bundle
Posted by Bernd Fondermann <be...@googlemail.com>.
On Feb 5, 2008 9:01 AM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> On 2/5/08, Noel J. Bergman <no...@devtech.com> wrote:
> > > with the release of the OSGi extension to Spring[1], it seems to be
> > > reasonably easy to turn any spring app into an OSGi deployment ('bundle').
> >
> > Yes, but doing so seems backwards. It appears that SpringSource is
> > conceding that OSGi is to Spring as JSF is to Struts, and that Spring will
> > go the way of Struts. So why not write directly to the standard in the
> > first place, and discard the legacy Spring code?
>
> OSGI isn't an IOC container. There's quite a lot of work needed on the
> COP in JAMES before OSGI is realistic option.
>
> If Felix people are around at the hackathon then this would be a good
> opertunity to work out what effort would be required.
+1
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James OSGi Bundle
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 2/5/08, Noel J. Bergman <no...@devtech.com> wrote:
> > with the release of the OSGi extension to Spring[1], it seems to be
> > reasonably easy to turn any spring app into an OSGi deployment ('bundle').
>
> Yes, but doing so seems backwards. It appears that SpringSource is
> conceding that OSGi is to Spring as JSF is to Struts, and that Spring will
> go the way of Struts. So why not write directly to the standard in the
> first place, and discard the legacy Spring code?
OSGI isn't an IOC container. There's quite a lot of work needed on the
COP in JAMES before OSGI is realistic option.
If Felix people are around at the hackathon then this would be a good
opertunity to work out what effort would be required.
- Robert
>
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James OSGi Bundle
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann ha scritto:
> On Feb 5, 2008 5:56 AM, Noel J. Bergman <no...@devtech.com> wrote:
>> and discard the legacy Spring code?
>
> :-) LOL. You are trolling. Avalon is a legacy. Spring is widely used,
> easy to handle, well documented and in active development.
> There is no reason why spring-, phoenix- and eventually
> pure-osgi-deployment couldn't exists side-by-side. And guess what:
> Everyone who is looking for ease-of-integration with other POJOs is
> best served with spring-deployment.
>
> Bernd
+1
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James OSGi Bundle
Posted by Bernd Fondermann <be...@googlemail.com>.
On Feb 5, 2008 5:56 AM, Noel J. Bergman <no...@devtech.com> wrote:
> > with the release of the OSGi extension to Spring[1], it seems to be
> > reasonably easy to turn any spring app into an OSGi deployment ('bundle').
>
> Yes, but doing so seems backwards.
Why? To me this seems very straightforward.
> It appears that SpringSource is
> conceding that OSGi is to Spring as JSF is to Struts, and that Spring will
> go the way of Struts.
Maybe, as I completely don't know what you are talking about.
> So why not write directly to the standard in the
> first place,
I agree, having a pure osgi deployment makes sense.
It would give as re-deployable components. (Setting aside the fact
that our components are not build to be redeployed. It simply will not
work without massive refactorings on a component-level.)
But who is willing to take the pain of either
* moving over our complete component framework to osgi, from one
massive-invasive to another one (I didn't yet take a look at iPojo,
though) and removing Avalon/Phoenix support
* creating another wrapper around Avalon, like the one we have in
spring-deployment. (at least spring is build for this task, see
BeanFactory and BeanDefinitionReader.)
> and discard the legacy Spring code?
:-) LOL. You are trolling. Avalon is a legacy. Spring is widely used,
easy to handle, well documented and in active development.
There is no reason why spring-, phoenix- and eventually
pure-osgi-deployment couldn't exists side-by-side. And guess what:
Everyone who is looking for ease-of-integration with other POJOs is
best served with spring-deployment.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: James OSGi Bundle
Posted by "Noel J. Bergman" <no...@devtech.com>.
> with the release of the OSGi extension to Spring[1], it seems to be
> reasonably easy to turn any spring app into an OSGi deployment ('bundle').
Yes, but doing so seems backwards. It appears that SpringSource is
conceding that OSGi is to Spring as JSF is to Struts, and that Spring will
go the way of Struts. So why not write directly to the standard in the
first place, and discard the legacy Spring code?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org