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 @SpringBean, but @SpringBean doesnt have the complexity of a bytecode instrumentation step. -igor On Tue, Jul 28, 2009 at 1:03 AM, Martijn Dashorst<martijn.dasho...@gmail.com> 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 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 as proxies to your services) > > Martijn > > On Tue, Jul 28, 2009 at 9:50 AM, Eelco > Hillenius<eelco.hillen...@gmail.com> wrote: >> 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 >> Hillenius<eelco.hillen...@gmail.com> wrote: >>> 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 all evil' in mind; 99.9% chance you're >>> optimizing something that will never ever become a bottleneck. >>> >>> Eelco >>> >>> 2009/7/27 Murat Yücel <kodeperke...@gmail.com>: >>>> 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 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") >>>>> private DAOServices daoService; >>>>> >>>>> private String objectID; >>>>> >>>>> public Iterator iterator(final int first, final int count){ >>>>> ..... >>>>> return daoService.load(objectId).subList(first, >>>>> first+count).iterator(); >>>>> } >>>>> >>>>> } >>>>> >>>>> >>>>> >>>>> I always write a singleton helper class for the service to be used, so I >>>>> can >>>>> have the model this way: >>>>> >>>>> public class MyViewObjectProvider extends SortableDataProvider{ >>>>> //so no reference to the dao service object >>>>> >>>>> private String objectID; >>>>> public Iterator iterator(final int first, final int count){ >>>>> ..... >>>>> //here the DAOServiceHelper.get() returns a instance that managed by >>>>> spring(with the actual service object injected.) >>>>> return DAOServiceHelper.get().load(objectId).subList(first, >>>>> first+count).iterator(); >>>>> } >>>>> >>>>> } >>>>> >>>>> So my question is, will there be a noticeable performance gain to do it >>>>> the >>>>> 2nd way? >>>>> The reason to ask is that the static kind of singleton usage is indeed >>>>> anti-spring, and makes >>>>> my eyes bleed.... >>>>> >>>>> If no one has done a performance comparison, I might have to do one >>>>> myself. >>>>> Just being lazzzzzy... >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Jason Wang >>>>> >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>> >>>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > > > -- > Become a Wicket expert, learn from the best: http://wicketinaction.com > Apache Wicket 1.3.5 is released > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org