RE: [Springframework-developer] IoC container enhancements

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

Sorry, I only read your last mail, not the discussion in Confluence :$
Shouldn't send mails after midnight ;-)

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.

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?

Best regards,
Tom.

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 making
> > 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 minimi=
ze
> > 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 configurati=
on
> > could be expanded to take a collection of property<->value relationships
> > 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 w=
ay
> > to
> > internalize it, perhaps it wouldn't get used much, I don't know. I know
> > our
> > team greatly appreciates the convenience.
> >=20
> > > -----Original Message-----
> > > From: spr...@li...
> > > [mailto:spr...@li...] On Beh=
alf
> > > 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 will=
 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 invo=
ke
> > > that method with the specified argument value. This would at least re=
move
> > > 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. Feel
> > > free to argue about that :-)
> > >=20
> > > Juergen
> > >=20
> > >=20
> > > ________________________________
> > >=20
> > > Von: spr...@li... im Auftrag=
 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 y=
ou
> > > think it is worthwhile adding syntax to support Type 1 (Interface
> > > Injection)
> > > IoC?
> > >=20
> > > http://opensource.atlassian.com/confluence/spring/display/DISC/Adding=
+Inte
> > > rf
> > > ace+Injection+to+Spring
> > >=20
> > >=20
> > >=20
> > >=20
> > > > -----Original Message-----
> > > > From: spr...@li...
> > > > [mailto:spr...@li...] On B=
ehalf
> > > > Of Rod Johnson
> > > > Sent: Friday, June 25, 2004 3:50 AM
> > > > To: spr...@li...
> > > > Subject: Re: [Springframework-developer] IoC container enhancements
> > > >
> > > > > 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-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
> > >=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
> >=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