RE: [Springframework-developer] IoC container enhancements

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Btw, I too prefer this over autowire-by-type in some cases and would
like it to be added, as it effectively provides control over both which
properties are autowired and which bean is wired to them.

Regards,
Tom.

On Mon, 28 Jun 2004 08:05:56 +0200, "Tom Turelinckx"
<tom...@pr...> said:
> Sorry, I only read your last mail, not the discussion in Confluence :$
> Shouldn't send mails after midnight ;-)
>=20
> Now that I've read it, I do agree with Juergen that an injection
> interface having a single method with a single parameter would be
> sufficient.
>=20
> A single interface with multiple setters would probably be used to
> combine DAO's often used together. I suppose you could just create an
> interface extending several other interfaces with a single setter each
> in that case?
>=20
> Best regards,
> Tom.
>=20
> On Mon, 28 Jun 2004 00:35:55 +0200, "Tom Turelinckx"
> <tom...@pr...> said:
> > James,
> >=20
> > What about a BeanPostProcessor?
> >=20
> > For example:
> >=20
> > public interface DaoAware {
> >     public void setDao( Dao dao );
> > }
> >=20
> > public class DaoAwareProcessor implements BeanPostProcessor,
> > InitializingBean {
> >     Dao dao;
> >=20
> >     public void setDao( Dao dao ) {
> >         this.dao =3D dao;
> >     }
> >=20
> >     public void afterPropertiesSet() throws Exception {
> >         if ( dao =3D=3D null ) {
> >             throw new ApplicationContextException( "dao property must be
> >             set on " + getClass() );
> >         }
> >     }
> >=20
> >     public Object postProcessBeforeInitialization( Object bean, String
> >     name ) {
> >         if ( bean instanceof DaoAware ) {
> >             ( ( DaoAware ) bean ).setDao( dao );
> >         }
> >         return bean;
> >     }
> >=20
> >     public Object postProcessAfterInitialization( Object bean, String
> >     name ) {
> >         return bean;
> >     }
> > }
> >=20
> > Kind regards,
> > Tom.
> >=20
> > On Sun, 27 Jun 2004 10:43:00 -0400, "James Cook"
> > <jim...@do...> said:
> > > Well, I will argue it a bit :-)
> > >=20
> > > We use it to simplify the mapping of our DAO's to our web tier by mak=
ing
> > > our
> > > servlet actions implement a DAOAware interface. It is extremely
> > > convenient
> > > to implement an interface and get the mapping for free. It is one step
> > > more
> > > explicit than autowire-by-type which I like. (Too much magic on large
> > > projects can create very difficult to debug scenarios.) It helps mini=
mize
> > > the size of our Spring configuration, and it *works*.
> > >=20
> > > I'm too close to the solution to notice "any oddness" in its
> > > configuration
> > > :-) Without some additional framework support, I don't see any other =
way
> > > to
> > > do it now. The single property<->value relationship in that configura=
tion
> > > could be expanded to take a collection of property<->value relationsh=
ips
> > > in
> > > order to support multiple setters in a single interface.
> > >=20
> > > It's OK if you don't want to internalize it into the framework since =
it
> > > is
> > > obviously supported now in some fashion. If you did come up with some=
 way
> > > to
> > > internalize it, perhaps it wouldn't get used much, I don't know. I kn=
ow
> > > our
> > > team greatly appreciates the convenience.
> > >=20
> > > > -----Original Message-----
> > > > From: spr...@li...
> > > > [mailto:spr...@li...] On B=
ehalf
> > > > Of j=FCrgen h=F6ller [werk3AT]
> > > > Sent: Friday, June 25, 2004 1:19 PM
> > > > To: spr...@li...
> > > > Subject: Re: [Springframework-developer] IoC container enhancements
> > > >=20
> > > > While this would be easy enough to add, I doubt that many people wi=
ll use
> > > > it. IMHO, it feels a bit odd to first implement an interface that
> > > > specifies a setter and then still apply the property value via a
> > > > "property" key (which has to match the bean property of the setter =
in the
> > > > interface).
> > > >=20
> > > > If we do magic anyway, why not assume that the injection interface
> > > > specifies a single method with a single parameter? We could then in=
voke
> > > > that method with the specified argument value. This would at least =
remove
> > > > the "property" redundancy.
> > > >=20
> > > > I understand that this was the first way of IoC that XWork/WebWork2
> > > > supported, but I'm not convinced that it is really recommendable. F=
eel
> > > > free to argue about that :-)
> > > >=20
> > > > Juergen
> > > >=20
> > > >=20
> > > > ________________________________
> > > >=20
> > > > Von: spr...@li... im Auftr=
ag von
> > > > James Cook
> > > > Gesendet: Fr 25.06.2004 15:40
> > > > An: spr...@li...
> > > > Betreff: RE: [Springframework-developer] IoC container enhancements
> > > >=20
> > > >=20
> > > >=20
> > > > Since you are enhancing the injection support for the container, do=
 you
> > > > think it is worthwhile adding syntax to support Type 1 (Interface
> > > > Injection)
> > > > IoC?
> > > >=20
> > > > http://opensource.atlassian.com/confluence/spring/display/DISC/Addi=
ng+Inte
> > > > rf
> > > > ace+Injection+to+Spring
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > > > > -----Original Message-----
> > > > > From: spr...@li...
> > > > > [mailto:spr...@li...] On=
 Behalf
> > > > > Of Rod Johnson
> > > > > Sent: Friday, June 25, 2004 3:50 AM
> > > > > To: spr...@li...
> > > > > Subject: Re: [Springframework-developer] IoC container enhancemen=
ts
> > > > >
> > > > > > Lookup methods can be combined with Setter Injection. They
> > > > > > can't presently be combined with Constructor Injection, but I
> > > > > > will add support for this, assuming that it's possible with
> > > > > > CGLIB.
> > > > >
> > > > >
> > > > > I've just removed this restriction.
> > > > >
> > > > >
> > > > >
> > > > > -------------------------------------------------------
> > > > > This SF.Net email sponsored by Black Hat Briefings & Training.
> > > > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> > > > > digital self defense, top technical experts, no vendor pitches,
> > > > > unmatched networking opportunities. Visit www.blackhat.com
> > > > > _______________________________________________
> > > > > Springframework-developer mailing list
> > > > > Spr...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/springframework-deve=
loper
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > > > -------------------------------------------------------
> > > > This SF.Net email sponsored by Black Hat Briefings & Training.
> > > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> > > > digital self defense, top technical experts, no vendor pitches,
> > > > unmatched networking opportunities. Visit www.blackhat.com
> > > > _______________________________________________
> > > > Springframework-developer mailing list
> > > > Spr...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/springframework-develo=
per
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > > > -------------------------------------------------------
> > > > This SF.Net email sponsored by Black Hat Briefings & Training.
> > > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> > > > digital self defense, top technical experts, no vendor pitches,
> > > > unmatched networking opportunities. Visit www.blackhat.com
> > > > _______________________________________________
> > > > Springframework-developer mailing list
> > > > Spr...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/springframework-develo=
per
> > >=20
> > >=20
> > >=20
> > >=20
> > > -------------------------------------------------------
> > > This SF.Net email sponsored by Black Hat Briefings & Training.
> > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> > > digital self defense, top technical experts, no vendor pitches,
> > > unmatched networking opportunities. Visit www.blackhat.com
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >=20
> >=20
> > -------------------------------------------------------
> > This SF.Net email sponsored by Black Hat Briefings & Training.
> > Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> > digital self defense, top technical experts, no vendor pitches,
> > unmatched networking opportunities. Visit www.blackhat.com
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer