james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Funnell" <si...@atomic-operations.com>
Subject Re: SpringJames vs. JamesNG
Date Fri, 08 Apr 2005 10:47:51 GMT
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

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


----- 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
> 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.
> 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
> > > 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
> inside an object. Say like, a person (could have a name, date of bith,
> 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,
> 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
> > 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
> that there are no dependencies!  If you support both, then you will have
> 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

View raw message