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

Reply via email to