Re: [Springframework-developer] Prototype handling support

[Colin S. <col...@ex...>]

I can certainly keep it to myself, it's not a big deal. I agree that 
your solution is the strategic one, and would be more convenient to use 
to boot. However, I don't think the two solutions are covering the exact 
same use cases given that my code is completely usable without cglib or 
other code modification. It actually consists of just the small 
FactoryBean implementation, plus a simpler variant of FactoryBean 
(called ObjectFactory) which is what it returns, that has only a 
getObject() method in it which throws BeansException (as opposed to 
FactoryBean's Exception).

I do agree that it's not worth modifying the container in any way (i.e. 
changes to the DTD and container code to short-circuit the manual 
factory bean creation), given that your solution is more comprehensive.

Let me know either way....

Regards,
Colin

Rod Johnson wrote:

>Colin
>
>I think my solution is the strategic one, as I wanted to avoid any
>dependency on Spring in such cases. Can you work with yours in your own
>patch until we can build in the better way?
>
>Rgds
>Rod
>
>----- Original Message -----
>From: "Colin Sampaleanu" <col...@ex...>
>To: <spr...@li...>
>Sent: Tuesday, May 11, 2004 5:05 PM
>Subject: Re: [Springframework-developer] Prototype handling support
>
>
>  
>
>>Rod,
>>
>>I am almost done a much simpler interimn (aka not as good) solution,
>>which is a FactoryBeanCreatingFactoryBean.
>>
>>It is simply a FactoryBean which produces a FactoryBean which will then
>>be used for accessing a prototype. So you have the current definition.
>>
>>    <bean id="prototype" class="a.b.c.D" singleton="false">
>>      ...
>>    </bean>
>>    <bean id="myX" class="a.b.c.XXX">
>>      ...
>>    </bean>
>>
>>and the current java code
>>
>>class XXX implements BeanFactoryAware {
>>    BeanFactory _bf;
>>    void setBeanFactory(BeanFactory beanFactory) throws BeansException
>>{  ...  };
>>
>>    ... in some method
>>    D dInstance = _bf.getBean("prototype");
>>    ...
>>}
>>
>>This would become:
>>
>>    <bean id="prototypeTarget" class="a.b.c.D" singleton="false">
>>      ...
>>    </bean>
>>    <bean id="prototype"
>>
>>    
>>
>class="org.springframework.beans.factory.config.FactoryBeanCreatingFactoryBe
>an">
>  
>
>>      <property name="targetName"><idref
>>local="prototypeTarget"/></property>
>>    </bean>
>>    <bean id="myX" class="a.b.c.XXX">
>>      <property name="prototypeFactory"><ref
>>    
>>
>local="prototype"/></property>
>  
>
>>    </bean>
>>
>>with the Java code:
>>
>>class XXX  {
>>    FactoryBean _prototypeFactory;
>>    void setPrototypeFactory(FactoryBean factoryBean) {  ...  };
>>
>>    ... in some method
>>    D dInstance = (D) _prototypeFactory.getObject();;
>>    ...
>>}
>>
>>Now is the second form better? Personally I think so; there is still a
>>tie to Spring of course (FactoryBean), but at least it's not
>>BeanFactoryAware, and the client can only get at one bean, not _any_
>>bean in the BeanFactory. It would be a lot simpler of course if the
>>container itself could create the FactoryBean on the fly as part of the
>>property setting.
>>
>>Your solution is much nicer of course. I would be interested in using
>>and polishing up your code, but I can't do it myself either until about
>>1.5 to 2 weeks from now. We have a situation with an app running on "the
>>most popular open-source EJB server" which has become intolerable due to
>>unreliability in the face of increased usage, and I need to work to move
>>my current CVS code to production next week.
>>
>>Colin
>>
>>
>>Rod Johnson wrote:
>>
>>    
>>
>>>Colin
>>>
>>>When it gets into Spring depends on when I have time to
>>>polish it. Basically that means some time in June. It
>>>basically works and it's _very_ useful. (I keep thinking of
>>>cool things to use it for: I kept boring Juergen and Alef
>>>about it on Sunday morning :-) It also needs discussion with
>>>at least Juergen about the extensions to the DTD. (100%
>>>backward compatible, of course.) And to accommodate the
>>>upcoming AspectJ integration in 1.0.3 (new feature but again
>>>very useful!) it needs to be implemented in a slightly
>>>different, more open way.
>>>
>>>If you want to take responsibility for completing it, in
>>>conjunction with myself and Juergen to discuss how the slight
>>>enhancements to the core IoC stuff should work, that would be
>>>great! I could send you the code and tests today.
>>>
>>>That way we will get it for 1.0.3, which would also be great.
>>>Of course if you're on HEAD you could be using it by the end
>>>of the week... As I said, it already works.
>>>
>>>Rgds,
>>>Rod
>>>---- Original message ----
>>>
>>>
>>>      
>>>
>>>>Date: Tue, 11 May 2004 09:05:59 -0400
>>>>From: Colin Sampaleanu <col...@ex...>
>>>>Subject: [Springframework-developer] Prototype handling
>>>>
>>>>
>>>>        
>>>>
>>>support
>>>
>>>
>>>      
>>>
>>>>To: spr...@li...
>>>>
>>>>Rod,
>>>>
>>>>At the TSS Symposium you mentioned having done some code to
>>>>
>>>>
>>>>        
>>>>
>>>allow the
>>>
>>>
>>>      
>>>
>>>>appcontext to dynamically modify a class so that a create or
>>>>
>>>>
>>>>        
>>>>
>>>getter
>>>
>>>
>>>      
>>>
>>>>method within it could actualy be hooked up to a prototype
>>>>
>>>>
>>>>        
>>>>
>>>bean within
>>>
>>>
>>>      
>>>
>>>>the factory. What are your thoughts on adding this code in
>>>>
>>>>
>>>>        
>>>>
>>>at this time?
>>>
>>>
>>>      
>>>
>>>>It would actually be of use to me...
>>>>
>>>>Colin
>>>>
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>This SF.Net email is sponsored by Sleepycat Software
>>>>Learn developer strategies Cisco, Motorola, Ericsson &
>>>>
>>>>
>>>>        
>>>>
>>>Lucent use to
>>>
>>>      
>>>