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" <[EMAIL PROTECTED]>
> 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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
