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 2006/10/27 13:09:55 UTC
James 2.3.0 running under Spring 2.0 Framework
Hi everyone,
I still can't quite believe it but in around 10 working hours I managed
to get James 2.3 up and running - not from Phoenix, but booting using
Spring 2.0. :-)
With thorough tests still pending, it is remarkable that James code and
the configuration remains unchanged. It is just providing new wrappers
for the Avalon lifecycle, throwing all the jars together, converting
assembly.xml to Spring bean configuration and providing some very lean
and mean gluecode.
Never thought it to be so easy.
I expect minor problems to arise and JMX is not yet available, but anyway.
I would like to check this stuff into a sandbox.
This opens some amazing possibilities:
+ Deploy with custom code/other beans in a much more easy manner
+ Deploy in J2EE servers and webcontainers etc., whatever a user may
think of
+ Use within an OSGi container, as soon as Spring does provide adapters
for this
+ full control over and possible customization of logging, configuration
and component lifecycle
Another consequence is, that there is no _need_ to walk away from
Avalon. It would be very easy to provide a Spring-bundled release in
parallel with the present packages.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James 2.3.0 running under Spring 2.0 Framework
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann wrote:
>> BTW: if everything runs well with Spring, which advantages brings us
>> staying with phoenix, apart from backward compatibility with custom
>> code?
>
> + everyone in the dev team knows Avalon/Phoenix
> + it is proven to run James components in a stable production-ready
> manner (we don't know yet which Spring-related and
> not-running-in-Phoenix-related problems we will run into. this would
> be the first painless migration in my career.
> + we still support Java 1.4, we should continue to support Phoenix
+1, I was writing a similar reply :-)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James 2.3.0 running under Spring 2.0 Framework
Posted by Stefano Bagnara <ap...@bago.org>.
Joachim raeger wrote:
> Am Freitag, den 27.10.2006, 20:45 +0200 schrieb Bernd Fondermann:
>
>>> BTW: if everything runs well with Spring, which advantages brings us
>>> staying with phoenix, apart from backward compatibility with custom
>>> code?
>> + everyone in the dev team knows Avalon/Phoenix
>> + it is proven to run James components in a stable production-ready
>> manner (we don't know yet which Spring-related and
>> not-running-in-Phoenix-related problems we will run into. this would
>> be the first painless migration in my career.
>
> :-)
>
>> + we still support Java 1.4, we should continue to support Phoenix
>
> I completely agree. But we can keep in mind that this are all "soft" or
> maybe non-functional arguments. I mean there is no important feature of
> phoenix currently missing in spring.
>
> Joachim
I don't use it, but phoenix has an optional Beanshell based kernel that
you can access with a console to manage the container and the contained
applications dynamically.
Phoenix has an HTTP adaptor on the ServiceManager that should allow you
to access the JMX services via web: we never really used this, but this
is in phoenix.
Phoenix supports autodeployment of new sar copied in the folder.
Phoenix supports classloader isolations between multiple applications
deployed inside it: I, as an example, have one single phoenix where I
deploy 3 different james instances.
Phoenix has some support to use RMI to control the behaviours of the
container (not sure anyone out-there is using this).
We (Norman) wrote a phoenix-daemon-loader that allow us to bind "<1024"
ports under unix and switch to an unpriviledged user: we would have to
write something similar for spring.
I don't know if spring provide any or multiple of this: This is to say
that there is not too much that keep us from going away, but there is
not too much that we gain leaving phoenix.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James 2.3.0 running under Spring 2.0 Framework
Posted by Norman Maurer <nm...@byteaction.de>.
Stefano Bagnara schrieb:
> Joachim raeger wrote:
>> Am Freitag, den 27.10.2006, 20:45 +0200 schrieb Bernd Fondermann:
>>
>>>> BTW: if everything runs well with Spring, which advantages brings us
>>>> staying with phoenix, apart from backward compatibility with custom
>>>> code?
>>> + everyone in the dev team knows Avalon/Phoenix
>>> + it is proven to run James components in a stable production-ready
>>> manner (we don't know yet which Spring-related and
>>> not-running-in-Phoenix-related problems we will run into. this would
>>> be the first painless migration in my career.
>>
>> :-)
>>
>>> + we still support Java 1.4, we should continue to support Phoenix
>>
>> I completely agree. But we can keep in mind that this are all "soft" or
>> maybe non-functional arguments. I mean there is no important feature of
>> phoenix currently missing in spring.
>>
>> Joachim
>
> I don't use it, but phoenix has an optional Beanshell based kernel
> that you can access with a console to manage the container and the
> contained applications dynamically.
>
> Phoenix has an HTTP adaptor on the ServiceManager that should allow
> you to access the JMX services via web: we never really used this, but
> this is in phoenix.
>
> Phoenix supports autodeployment of new sar copied in the folder.
>
> Phoenix supports classloader isolations between multiple applications
> deployed inside it: I, as an example, have one single phoenix where I
> deploy 3 different james instances.
>
> Phoenix has some support to use RMI to control the behaviours of the
> container (not sure anyone out-there is using this).
>
> We (Norman) wrote a phoenix-daemon-loader that allow us to bind
> "<1024" ports under unix and switch to an unpriviledged user: we would
> have to write something similar for spring.
>
> I don't know if spring provide any or multiple of this: This is to say
> that there is not too much that keep us from going away, but there is
> not too much that we gain leaving phoenix.
>
> Stefano
Im not familar with spring. Thats why i have not strong idea about it.
But after a quick search on the internet it seems there is no "commons
daemon" wrapper.
But it whould be cool to maybe offer a phoenix and a spring bundle ;-)
bye
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James 2.3.0 running under Spring 2.0 Framework
Posted by Joachim Draeger <jd...@gmx.de>.
Am Freitag, den 27.10.2006, 20:45 +0200 schrieb Bernd Fondermann:
> > BTW: if everything runs well with Spring, which advantages brings us
> > staying with phoenix, apart from backward compatibility with custom
> > code?
>
> + everyone in the dev team knows Avalon/Phoenix
> + it is proven to run James components in a stable production-ready
> manner (we don't know yet which Spring-related and
> not-running-in-Phoenix-related problems we will run into. this would
> be the first painless migration in my career.
:-)
> + we still support Java 1.4, we should continue to support Phoenix
I completely agree. But we can keep in mind that this are all "soft" or
maybe non-functional arguments. I mean there is no important feature of
phoenix currently missing in spring.
Joachim
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James 2.3.0 running under Spring 2.0 Framework
Posted by Bernd Fondermann <be...@googlemail.com>.
On 10/27/06, Joachim Draeger <jd...@gmx.de> wrote:
> > + Deploy with custom code/other beans in a much more easy manner
>
> I guess more people know how to work with spring than with phoenix.
And Spring is much less intrusive. Almost every code can be integrated
without change (even James :-) )
> > Another consequence is, that there is no _need_ to walk away from
> > Avalon. It would be very easy to provide a Spring-bundled release in
> > parallel with the present packages.
>
> I even don't see a blocker for going a step further to OSGi together
> with Avalon.
>
> BTW: if everything runs well with Spring, which advantages brings us
> staying with phoenix, apart from backward compatibility with custom
> code?
+ everyone in the dev team knows Avalon/Phoenix
+ it is proven to run James components in a stable production-ready
manner (we don't know yet which Spring-related and
not-running-in-Phoenix-related problems we will run into. this would
be the first painless migration in my career.
+ we still support Java 1.4, we should continue to support Phoenix
> To avoid any indignation: I'm not proposing to remove phoenix and switch
> to OSGi/Spring right now. But working prototypes will give us the
> possibility to evaluate concrete solutions.
Right. This is just a proof-of-concept.
I came to read the Spring 2.0 and suddenly I couldn't resist... never
thought it would work out so well. And I'd like to see similar
prototypes.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James 2.3.0 running under Spring 2.0 Framework
Posted by Joachim Draeger <jd...@gmx.de>.
Hi Bernd!
Am Freitag, den 27.10.2006, 13:09 +0200 schrieb Bernd Fondermann:
> I still can't quite believe it but in around 10 working hours I managed
> to get James 2.3 up and running - not from Phoenix, but booting using
> Spring 2.0. :-)
Amazing! Great! :-)
> I expect minor problems to arise and JMX is not yet available, but anyway.
This will bring us much more insight than 10 hours of discussing. ;-)
And it sounds like it could get to something useful soon.
> I would like to check this stuff into a sandbox.
Yeah, please go on!
> This opens some amazing possibilities:
> + Deploy with custom code/other beans in a much more easy manner
I guess more people know how to work with spring than with phoenix.
> + Deploy in J2EE servers and webcontainers etc., whatever a user may
> think of
This has often been requested. It might not only easier to setup than
running two jvms but also opens many possibilities integrating e.g.
Mailets with available business logic.
> + Use within an OSGi container, as soon as Spring does provide adapters
> for this
Spring is my favorite for OSGi integration, too.
There seem to be big efforts for Spring-OSGi and I guess it is pushed by
well-known companies. I expect the current implementation is already
usable, at least for doing some experiments.
As we have James running with Spring now, I expect a running James
inside OSGi soon.
Of course at first only a kind of pseudo OSGi-enabled without utilizing
most OSGi possibilities. But I'm sure it will bring us again more
insight than 10 hours of discussion.
+ Spring with iBatis as a backend for MailboxManager. :-)
I really love the possibilities of AOSD. At the moment, transaction
handling and Exception translation is a pain with Torque...
But that are dreams of the future. :-)
> Another consequence is, that there is no _need_ to walk away from
> Avalon. It would be very easy to provide a Spring-bundled release in
> parallel with the present packages.
I even don't see a blocker for going a step further to OSGi together
with Avalon.
BTW: if everything runs well with Spring, which advantages brings us
staying with phoenix, apart from backward compatibility with custom
code?
To avoid any indignation: I'm not proposing to remove phoenix and switch
to OSGi/Spring right now. But working prototypes will give us the
possibility to evaluate concrete solutions.
Joachim
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James 2.3.0 running under Spring 2.0 Framework
Posted by Danny Angus <da...@gmail.com>.
On 10/27/06, Bernd Fondermann <bf...@brainlounge.de> wrote:
> This opens some amazing possibilities:
Great stuff. I've wanted to see this happen for a long time! Well done.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James 2.3.0 running under Spring 2.0 Framework
Posted by Stefano Bagnara <ap...@bago.org>.
Well, as I'm not helping, I should probably wait for the classes to
appear in sandbox, but I'm curious ;-)
Bernd Fondermann wrote:
>> Can you elaborate on the "very lean and mean gluecode" ?
>
> 1 Main class, 5 classes for injecting Logger and calling
> contextualize(), service(), configure(), initialize().
> Helpers for Logger, ServiceManager, providing Configuration.
Good! So this is like a small avalon container written for Spring, and
nothing James specific, right?
>> I think we could create a script to automatically generate the spring
>> bean configuration starting from assembly.xml but I'd like to know if
>> what you described as "gluecode" is dependent from the assembly content
>> or is generic things to replace phoenix.
>
> Converting assembly.xml to spring-config.xml is straightforward on the
> syntax level, but I had to do some tweaking here and there.
I'm looking forward to see the spring-config.xml and the tweaks!
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James 2.3.0 running under Spring 2.0 Framework
Posted by Bernd Fondermann <be...@googlemail.com>.
On 10/27/06, Stefano Bagnara <ap...@bago.org> wrote:
> Bernd Fondermann wrote:
> > Hi everyone,
> >
> > I still can't quite believe it but in around 10 working hours I managed
> > to get James 2.3 up and running - not from Phoenix, but booting using
> > Spring 2.0. :-)
>
> Cool!
> Well, I expected it wasn't hard to move away from Phenix. The hard part
> would be remove the avalon framework, but as I always said I think
> avalon framework is good and still not a big limit for James.
Agreed. I expected it to be a limit on container migration, but it is
not a blocker, just an obstacle ;-)
> > With thorough tests still pending, it is remarkable that James code and
> > the configuration remains unchanged. It is just providing new wrappers
> > for the Avalon lifecycle, throwing all the jars together, converting
> > assembly.xml to Spring bean configuration and providing some very lean
> > and mean gluecode.
> > Never thought it to be so easy.
>
> I admit I would have expected more than 10 working hours. I'm sure
> you're better than me at Spring ;-)
Probably no. Spring Reference and API doc is extremly good.
> Can you elaborate on the "very lean and mean gluecode" ?
1 Main class, 5 classes for injecting Logger and calling
contextualize(), service(), configure(), initialize().
Helpers for Logger, ServiceManager, providing Configuration.
> I think we could create a script to automatically generate the spring
> bean configuration starting from assembly.xml but I'd like to know if
> what you described as "gluecode" is dependent from the assembly content
> or is generic things to replace phoenix.
Converting assembly.xml to spring-config.xml is straightforward on the
syntax level, but I had to do some tweaking here and there.
> > I expect minor problems to arise and JMX is not yet available, but anyway.
>
> If you did the rest in 10 hours we can give you 3 more hours for JMX :-P
Sure, no stopping here :-)
> > + full control over and possible customization of logging, configuration
> > and component lifecycle
>
> Customization of logging and configuration is already available in phoenix.
Yes, sure. But now it becomes easier to control over the whole
application lifecycle.
For example, it would now be relatively easy at startup time to
intercept the configuration loaded from file (base configuration) and
enhance it with other data (e.g. additional domain names, etc.) coming
from another source.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James 2.3.0 running under Spring 2.0 Framework
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann wrote:
> Hi everyone,
>
> I still can't quite believe it but in around 10 working hours I managed
> to get James 2.3 up and running - not from Phoenix, but booting using
> Spring 2.0. :-)
Cool!
Well, I expected it wasn't hard to move away from Phenix. The hard part
would be remove the avalon framework, but as I always said I think
avalon framework is good and still not a big limit for James.
> With thorough tests still pending, it is remarkable that James code and
> the configuration remains unchanged. It is just providing new wrappers
> for the Avalon lifecycle, throwing all the jars together, converting
> assembly.xml to Spring bean configuration and providing some very lean
> and mean gluecode.
> Never thought it to be so easy.
I admit I would have expected more than 10 working hours. I'm sure
you're better than me at Spring ;-)
Can you elaborate on the "very lean and mean gluecode" ?
I think we could create a script to automatically generate the spring
bean configuration starting from assembly.xml but I'd like to know if
what you described as "gluecode" is dependent from the assembly content
or is generic things to replace phoenix.
> I expect minor problems to arise and JMX is not yet available, but anyway.
If you did the rest in 10 hours we can give you 3 more hours for JMX :-P
> I would like to check this stuff into a sandbox.
++1
> This opens some amazing possibilities:
> + Deploy with custom code/other beans in a much more easy manner
> + Deploy in J2EE servers and webcontainers etc., whatever a user may
> think of
> + Use within an OSGi container, as soon as Spring does provide adapters
> for this
++1
> + full control over and possible customization of logging, configuration
> and component lifecycle
Customization of logging and configuration is already available in phoenix.
> Another consequence is, that there is no _need_ to walk away from
> Avalon. It would be very easy to provide a Spring-bundled release in
> parallel with the present packages.
I agree, this would be good!
And it seems to be not intrusive and as an additional package we could
also put this in next-major (if this will be stable and others will like
this too)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org