Question on the rationale behind using Spring (especially to the veteran
developers):

I know that early versions/predecessors of ApacheDS used other
frameworks (Avalon?). Which frameworks or lightweight containers were
used/considered in the progress before Spring? Is there any
documentation on the architectural decision or rationale to use Spring?

Thanks in advance,
Stefan Zoerner (szoerner)

[ Post a follow-up to this message ]

Hi Stefan,

Well let me break down the history behind our container drama .  It
started out a while back in the first days of ldapd over at SF.net in 2002.
I started using Avalon Phoenix back then and had carved out blocks
(components in Avalon terms) for each of the subsystems. This was course
grained.

When ldapd came to Apache and became ApacheDS we started switching from
Phoenix to Merlin which was the "new" container that factions in Avalon were
pushing.   And it looked like Phoenix was going to die and it did sort of
with one last trip out of the fire as Loom at codehaus.  Loom also died I
think.  I was sad to see this happen since Phoenix was a damn good container
for Avalon.  It just worked.  Loom and Phoenix were totally compatible.

With all this flux at Avalon I just abandoned messing around with IoC and
got a bad taste in my mouth over it.  So I tried to write most of the modern
subsystems with simple POJOs while keeping an open eye for some container
to  come along and make my day.

Trustin at some point got sick of using env properties inside the JNDI
provider to describe complex objects and talked me into using Spring just
for configuration.  I was reluctant at first but it fixed some problems for
us.  The env hashtable based approach with key value pairs was just a
hassle.  So this is how Spring came into the picture.  We could have used
other things like commons-configuration but I did not have the time to look
into that at the time.  We do not use Spring for anything other than
configuration.

I am hoping this OSGi stuff is the silver bullet to fix all of Java's
container wars as the victor.  So we can go back to using a container for
more than just configuration.  Looks btw like the Spring guys got infected
by the OSGi bug so there might be some cross pollination going on between
these efforts.

I am optimistic mostly because of the Spring guys' interest.

Alex

On 4/22/07, Stefan Zoerner <stefan-EQq9qWhC7IA@public.gmane.org> wrote:
>
> Question on the rationale behind using Spring (especially to the veteran
> developers):
>
> I know that early versions/predecessors of ApacheDS used other
> frameworks (Avalon?). Which frameworks or lightweight containers were
> used/considered in the progress before Spring? Is there any
> documentation on the architectural decision or rationale to use Spring?
>
> Thanks in advance,
>      Stefan Zoerner (szoerner)
>
>

[ Post a follow-up to this message ]

Alex, just a question :

back two years later, I remembe rthat all the configuration was provided
through a property file, so I guess we can't really talk about a container
approach back them, am I wrong ?


On 4/23/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
>
> Hi Stefan,
>
> Well let me break down the history behind our container drama .  It
> started out a while back in the first days of ldapd over at SF.net in
> 2002.  I started using Avalon Phoenix back then and had carved out blocks
> (components in Avalon terms) for each of the subsystems. This was course
> grained.
>
> When ldapd came to Apache and became ApacheDS we started switching from
> Phoenix to Merlin which was the "new" container that factions in Avalon we
re
> pushing.   And it looked like Phoenix was going to die and it did sort of
> with one last trip out of the fire as Loom at codehaus.  Loom also died I
> think.  I was sad to see this happen since Phoenix was a damn good contain
er
> for Avalon.  It just worked.  Loom and Phoenix were totally compatible.
>
> With all this flux at Avalon I just abandoned messing around with IoC and
> got a bad taste in my mouth over it.  So I tried to write most of the mode
rn
> subsystems with simple POJOs while keeping an open eye for some container
> to  come along and make my day.
>
> Trustin at some point got sick of using env properties inside the JNDI
> provider to describe complex objects and talked me into using Spring just
> for configuration.  I was reluctant at first but it fixed some problems fo
r
> us.  The env hashtable based approach with key value pairs was just a
> hassle.  So this is how Spring came into the picture.  We could have used
> other things like commons-configuration but I did not have the time to loo
k
> into that at the time.  We do not use Spring for anything other than
> configuration.
>
> I am hoping this OSGi stuff is the silver bullet to fix all of Java's
> container wars as the victor.  So we can go back to using a container for
> more than just configuration.  Looks btw like the Spring guys got infected
> by the OSGi bug so there might be some cross pollination going on between
> these efforts.
>
> I am optimistic mostly because of the Spring guys' interest.
>
> Alex
>
> On 4/22/07, Stefan Zoerner <stefan-EQq9qWhC7IA@public.gmane.org > wrote: 
>


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

[ Post a follow-up to this message ]

Alex Karasulu wrote:

> Hi Stefan,
>
> Well let me break down the history behind our container drama .
> ...

Thanks Alex for taking your time and describing the history in detail! I
was asked why we use Spring and what other options we
examined/considered. Your explanation was very helpful!

Greetings from Wiesbaden,
Stefan Zoerner (szoerner)

[ Post a follow-up to this message ]

On 4/23/07, Emmanuel Lecharny <elecharny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:[vbc
ol=seagreen]
>
> Alex, just a question :
>
> back two years later, I remembe rthat all the configuration was provided
> through a property file, so I guess we can't really talk about a container
> approach back them, am I wrong ?[/vbcol]


Well we had a container before then even if we were using properties files
for the standalone server configuration.  Also the JNDI based configuration
with a standalone server using jndi.properties may have come after the
removal of all Avalon code.

Alex

[ Post a follow-up to this message ]