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
