james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Soren Hilmer <soren.hil...@tietoenator.com>
Subject Re: SpringJames vs. JamesNG
Date Fri, 08 Apr 2005 14:34:42 GMT
This is a very good point! 
It is very easy to make a CDI wrapper around an SDI POJO, but the other way 
around is rather difficult.

This is probably the strongest argument for SDI, I gave seen.

--Søren

On Friday 08 April 2005 12:47, Simon Funnell wrote:
> Use of CDI 'only' limits a component to certain types of containers, for
> example components with getter/setters patterns can have their dependencies
> changed at runtime, I believe CDI limits a components reuse in other
> projects.
>
> A container should ideally be able to use any component by supporting
> multiple component lifecycle types, Avalon describes/specifies a highly
> detailed lifecycle, Pico container a very simple lifecycle.  The point is
> that a simple container cant manage a component with a complex lifecycle
> where as a sophisticated container could/should host any component
> lifecycle, therefore any component.
>
> - A good component will allow containers to create/manage their lifecycle.
> - A good framework will allow the management of multiple lifecycle types.
>
> I think the spring framework is a strong move in that direction container
> wise as the configurations are geared to wiring up components.  This is
> close to being (if not is) a dynamic way of describing lifecycles of any
> type.
>
> Simon
>
>
> ----- Original Message -----
> From: "Daniel Perry" <d.perry@netcase.co.uk>
> To: "James Developers List" <server-dev@james.apache.org>
> Sent: Friday, April 08, 2005 11:02 AM
> Subject: RE: SpringJames vs. JamesNG
>
> > > Okay, so you prefer code looking like:
> > > p = new SomePOJO ("bla", null, null, null, null, "bli", null,
> > > null, null);
> > >
> > > to code looking like:
> > > p = new SomePOJO ();
> > > p.setBla("bla");
> > > p.setBli("bli");
> > >
> > > I must say, I prefer the latter.
> >
> > I prefer the CDI one.
> >
> > Take two cases:
> >
> > In a normal environment (ie where the container provides the
>
> dependencies),
>
> > the class will be instantiated by the container, so you wont be writing
> > "p
>
> =
>
> > new SomePOJO (...". So it doesnt matter which is used, as you'll never
> > see it!
> >
> > Now consider an environment where someone (who probably has no idea about
> > james's code) is using a component in their own code without DI.  My
> > argument is that with CDI they are less likely to miss a dependency.  The
> > dependencies are listed in an obvious place - the (only) constructor.
> > They have to provide them.  They dont have to go find documentation that
> > says: "you must set bla, and bli after creating the class.  You can set
> > other things, but they're optional."
> >
> > CDI makes sense to me.  The constructor is where the initialisation of
> > the object takes place, and you can provide initiailisation parmaeters. 
> > The constructor is only called once, so dependencies can easily be mate
> > immutable.  Using CDI ensures that once an object exists, it is usable.
> > There is no easy way to determine what state an SDI object is in.
>
> Therefore
>
> > it seems logical that it is the place to introduce hard dependencies.
> >
> > > > Another way of avoiding "parameter bloat" is to identify those
> > >
> > > parameters
> > >
> > > > common to many of an application's Classes and gather them together
> > > > in
>
> a
>
> > > > single Class so that instances can be injected as a single object.
> > >
> > > Sure this works, but unfortunately have the effect that classes
> > > are created
> > > for the sole purpose as being place-holders. This leads to a more
> > > complicated
> > > class-hierarchy. Which IMO is to be avoided. Again KISS.
> >
> > Really? I thought this was the main principle of object orientation -
> > encapsulation.  You take a bunch of related things, and bundle them
>
> together
>
> > inside an object. Say like, a person (could have a name, date of bith,
>
> etc)
>
> > or a CoreServices (could provide logging, configuration, etc)!
> >
> > > > The key point is that CDI does not force us to deal with a n*n-1
> > > > constructor problem. There are a number of patterns that can be
> > >
> > > applied to
> > >
> > > > avoid this and the associated "parameter bloat" problem.
> > >
> > > Unfortunately all these patterns to deal with parameter bloat
> > > introduces more
> > > complexity and are thus violating the KISS principle.
> >
> > I would argue against that.  KISS doesnt mean do it in the least number
> > of classes, or do it in the least number of calls.  It means "Keep It
> > Simple Stupid".  Minimising the number of classes might contribute to
> > this, but i think the biggest factor is making it easy to understand, and
> > follow. Providing a CDI subclass of each SDI class is simple.  Subclass
> > with one constructor.  If you name it appropriately so that people can
> > find it,
>
> then
>
> > i dont think this violates KISS in any way!
> >
> > > I agree that we should not focus on any given container.
> > > Apparently we cannot
> > > agree upon which concept JavaBean/CDI is the way to go, so I then move
>
> in
>
> > > favour of supporting both. That way we can run in any POJO container.
> > > As someone (sorry forgot who) posted earlier this is quite easy as the
> > > CDI constructor can be implemented like:
> > >
> > > SomePOJO (String a, String b, String c, String d)
> > > {
> > >    this();
> > >    setA(a); setB(b); setC(c); setD(d);
> > > }
> > >
> > > Alongside the mandatory no-args constructor.
> >
> > AFAIK this wont work, as CDI relies on a constructors to determine
> > dependencies.  If there is a no-argument constructor, then it will
>
> determine
>
> > that there are no dependencies!  If you support both, then you will have
>
> to
>
> > extend the classses to make a CDI version:
> >
> > public class SomePOJOCDI{
> >    SomePOJOCDI (String a, String b, String c, String d)
> >    {
> >       super();
> >       setA(a); setB(b); setC(c); setD(d);
> >    }
> > }
> >
> > Daniel.
> >
> >
> > ---------------------------------------------------------------------
> > 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

-- 
Søren Hilmer, M.Sc.
R&D manager		Phone:	+45 72 30 64 00
TietoEnator IT+ A/S	Fax:	+45 72 30 64 02
Ved Lunden 12		Direct:	+45 72 30 64 57
DK-8230 Åbyhøj		Email:	soren.hilmer <at> tietoenator.com

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


Mime
View raw message