Unfortunately the instrumentation does not help here. I'm using getters
at constructors to overcome this issue.
public class MyPanel extends Panel {
@SpringBean
private ContactDao contactDao;
public MyPanel(String id) {
super(id);
List<Contact> contacts = getContactDao().findAll();
// add a TextField for each contact
}
protected ContactDao getContactDao() {
return contactDao;
}
}
In test class I test through a stub implementation which provides the
dependency in getter:
public class MyPanelStub extends MyPanel {
@Override
protected ContactDao getContactDao() {
return new ContactDaoStub();
}
}
--
Joni Suominen
On Wed, 2005-11-30 at 00:50 +0100, Christian Essl wrote:
> A problem I face is that I often need the Spring beans already in the
> constructor. Ie in a AdvicedTasksPage to give the ProductsDAO further to
> the AdviceProductsPanel.
>
> I don't know how turning 'injection' off through a NoopInjector() could
> help in such a szenario in a unit test. Because when I write new PageXX()
> and than inject through some setters it is too late for my panel.
>
> My current solution is to provide two constructors one which does for
> production call the SpringInjector.getInstance().inject(this) method and a
> second one where the Spring Beans have to be provided directly - for unit
> tests.
>
> If Joni's instrumentation could help to save the extra constructor I'd be
> very glad.
>
> Christian
>
>
>
> On Tue, 29 Nov 2005 12:53:59 -0800, Igor Vaynberg
> <[EMAIL PROTECTED]> wrote:
>
> > I hit the same problem with unit tests. i created a singleton that did
> > exactly that. so in test setup i called InjectorLocator.setLocator(new
> > NoopInjector()); and my basepage used InjectorLocator.getLocator
> > ().inject(this);
> >
> > Your approach is definetely cleaner, but personallly i cant use it yet.
> > Is
> > anyone who is reading with us interested in this? if so would you like it
> > merged into wicket-contrib-spring? if so, Joni would you be interested in
> > donating and supporting it in wicket-stuff?
> >
> > -Igor
> >
> >
> > On 11/29/05, Joni Suominen <[EMAIL PROTECTED]> wrote:
> >>
> >> On Tue, 2005-11-29 at 09:15 -0800, Igor Vaynberg wrote:
> >> > thats really neat. i dont always have access to the command line that
> >> > launhces the server so that might be a problem.
> >>
> >> True. This restriction will be relaxed in mustang where they allow
> >> registering of instrumentation agent after vm startup.
> >>
> >> > also does it instrument every class construction? cant tell since
> >> > there is no code, but if it does, that would be a performance hit.
> >>
> >> It instruments only classes which contain at least 1 field with
> >> @SpringBean annotation, the rest will be just parsed with asm. So there
> >> will be a small performance hit at classloading time (i'm thinking of
> >> adding a configuration property for the agent which makes it to inspect
> >> only classes contained in particular packages, if the performace will
> >> become a problem). I attached the code if you want to take a deeper look
> >> at it.
> >>
> >> > did you see SpringPage class? it calls the SpringInjector.inject
> >> (this)
> >> > in its default constructor so if you extend from that page you never
> >> > have to call SpringInjector directly in your own code. you cane make a
> >> > SpringPanel that does the same. that should cover the two mostly used
> >> > use cases.
> >>
> >> Yes, I saw it but I like instrumentation approach slightly more elegant
> >> since there's no base classes or extra source level dependency. Base
> >> classes had also problem with unit testing. We had to create a wrapper
> >> around SpringInjector which did not call SpringInjector.inject() if a
> >> certain system property was set. This allowed us to manually wire the
> >> dependencies on unit tests but using the instrumentation this is not a
> >> problem since we just do not set the agent on unit test virtual
> >> machines.
> >>
> >> --
> >> Joni Suominen
> >>
> >>
> >>
>
>
>
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
