|
From: Rod J. <rod...@in...> - 2004-05-11 21:05:06
|
Colin
I didn't say your solution was bad, just that I'm in love with mine.
As yours is merely a FactoryBean and not an IoC core mod (should have read
your email more closely) I see no issue in putting it in if it's useful.
Sorry!
R
----- Original Message -----
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Tuesday, May 11, 2004 9:11 PM
Subject: Re: [Springframework-developer] Prototype handling support
> 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.FactoryBeanCreatingFactoryB
e
> >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
> >>>
> >>>
> >>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
> deliver higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
|