Hi Jason
I dont have a performance comparison, but i cannot see why you should
gain better performance.
All spring beans are as default singleton, so you will just forward a
singleton using a singleton.
/Murat
2009/7/28 Jason Wang jason.w...@bulletin.net:
Hi all,
Although I am using
Hi Jason,
You could have a look at http://code.google.com/p/salve/
By making use of some byte code instrumentation it will replace your
dependency injections by static lookups, i.e. the best of both worlds. I
wouldn't know about the performance of each approach however.
Regards,
Wilko
Jason
It might give you a very slight edge to use a singleton as you (or the
annotation processor in this case) don't have to introspect and work
through a proxy. If you're not bothered by singletons (I, for one
typically are): go for it. However, keep that famous 'premature
optimization is the root of
Actually, thinking about it, if you're very tight on memory, it will
save you a reference, particularly when the page gets serialized. So
if you are worrying about efficiency *and* are ok with this code
style, it's an option. :-)
Eelco
On Tue, Jul 28, 2009 at 12:47 AM, Eelco
There's the risk of keeping the retrieved service as a reference
somewhere, e.g. by declaring it final and using it inside an anon
inner class, negating any and all gains you've done by using the
static lookup. The @SpringBean annotated references are safe to pass
around (as they are implemented
also safe to do with salve because it removes the field and rewrites
field reads with lookups.
wicket-spring and salve were created for a reason - to make it easy to
work with services in an environment where objects are often
serialized.
salve doesnt have the memory overhead of wicket's
Don't guess, profile it.
2009/7/28 Jason Wang jason.w...@bulletin.net:
Hi all,
Although I am using spring-wicket to prevent the whole spring being
serialized, It still brothers me to see the references in the model
object, for example:
Instead of using this:
public class
Hi Martijin,
Thats a very good point. I definitely overlooked that risk before. Thank
you for pointing it out!
Thanks,
Jason Wang
Martijn Dashorst wrote:
There's the risk of keeping the retrieved service as a reference
somewhere, e.g. by declaring it final and using it inside an anon
inner
Hi all,
Although I am using spring-wicket to prevent the whole spring being
serialized, It still brothers me to see the references in the model
object, for example:
Instead of using this:
public class MyViewObjectProvider extends SortableDataProvider{
@SpringBean(daoService)