why dont you at least attach the code to an email message in this list. that way it will be archived and if somone searches down the road they can use it.

-Igor


On 4/22/06, Lasse Koskela <[EMAIL PROTECTED]> wrote:
Alright. I implemented a "SpringSetterInjector implements
IComponentInstantiationListener" and verified that it indeed injects
through setters when enabled for an application as follows:

public class MyApplication extends SpringWebApplication {
    protected void init() {
        addComponentInstantiationListener(
                new SpringSetterInjector(internalGetApplicationContext()));
    }
}

It injects any setter that matches a bean in the provided
BeanFactory/ApplicationContext, regardless of whether the method's
access is private/protected/package/public.

Anyone else interested in having the source?

-Lasse-

On 4/22/06, Lasse Koskela < [EMAIL PROTECTED]> wrote:
> Hi Igor,
>
> On 4/22/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > there is a thread here that explains why we did not go with setter-based
> > injection
> > http://www.nabble.com/New-features-Wicket-1.2-t1310931.html#a3497221
>
> As to your argument in the referenced thread:
> "we can write a traversal for setters, but i really dont see value in
> it, what is your setter going to do - stick it into some private
> field."
>
> The value I see is two-fold:
>
> 1) not needing to run on Java 5 in order to have clean dependency
> injection. (I don't consider commons-attributes a proper
> workaround--just a personal bias, of course)
>
> 2) being able to set dependencies in unit tests without involving a
> mock Spring context.
>
>
> On 4/22/06, Igor Vaynberg <[EMAIL PROTECTED] > wrote:
> > now all that said, there is nothing stopping you from writing the code to
> > scan for setters and injecting them, it should be trivial. remember, somehow
> > you will have to say /which/ setters should be injected since there is no
> > xml to configure this.
>
> Yes, this is the tricky part--which setters to invoke. I suppose the
> heuristic would go a bit like this:
>
>     If the setter's property name (e.g. "setAuthenticator" --> "authenticator")
>     matches a bean registered with the ApplicationContext and the types
>     match, inject that bean.
>
> Without having thought about this for longer than two minutes, the
> only downside I see with such an approach would be 1) the performance
> hit involved with reflection, and 2) a setter method not intended for
> DI being subjected to DI and thus forcing the developer to rename a
> method or the Spring bean.
>
>
> -Lasse-


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmdlnk&kid0709&bid&3057&dat1642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply via email to