|
From: Tom T. <tom...@pr...> - 2004-06-27 22:36:00
|
James,
What about a BeanPostProcessor?
For example:
public interface DaoAware {
public void setDao( Dao dao );
}
public class DaoAwareProcessor implements BeanPostProcessor,
InitializingBean {
Dao dao;
public void setDao( Dao dao ) {
this.dao =3D dao;
}
public void afterPropertiesSet() throws Exception {
if ( dao =3D=3D null ) {
throw new ApplicationContextException( "dao property must be
set on " + getClass() );
}
}
public Object postProcessBeforeInitialization( Object bean, String
name ) {
if ( bean instanceof DaoAware ) {
( ( DaoAware ) bean ).setDao( dao );
}
return bean;
}
public Object postProcessAfterInitialization( Object bean, String
name ) {
return bean;
}
}
Kind regards,
Tom.
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 minimize
> 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 configuration
> 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 way
> 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 Behalf
> > 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 u=
se
> > 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 t=
he
> > 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 invoke
> > that method with the specified argument value. This would at least remo=
ve
> > 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 v=
on
> > 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/Adding+I=
nte
> > rf
> > ace+Injection+to+Spring
> >=20
> >=20
> >=20
> >=20
> > > -----Original Message-----
> > > From: spr...@li...
> > > [mailto:spr...@li...] On Beh=
alf
> > > 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-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
>=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
|