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
--
Christian Essl
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
-------------------------------------------------------
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
