|
From: Colin S. <col...@ex...> - 2003-10-15 15:42:46
|
I agree. Just because I don't think source level transaction declarations don't make sense (for me, or for the general usecases), doesn't mean there are not some usecases where they probably do make sense. On top of that, there are a lot of other things (besides transaction declarations) you can do with source level (or bytecode level, post-compilation) metadata... Rod Johnson wrote: >Spring doesn't try to tell people what to think. So we should aim to please >both camps, and assume that users know best. (The customer is always right.) >We already have a solution for the "externalization" camp--and we should >improve it if we can. We now need to create a solution for the metadata >camp. > >R > >----- Original Message ----- >From: "Kopylenko, Dmitry" <dko...@su...> >To: "'Rod Johnson'" <rod...@in...>; "Kopylenko, Dmitry" ><dko...@su...> >Cc: <spr...@li...> >Sent: Wednesday, October 15, 2003 1:01 PM >Subject: RE: [Springframework-developer] new bean factory and application >context features > > >I tend to think so too. However there going to be "two camps" of people - >1)People who think source level metadata is a good thing > >2)People who think source level metadata is evil > >Dmitriy. > >-----Original Message----- >From: Rod Johnson [mailto:rod...@in...] >Sent: Wednesday, October 15, 2003 7:56 AM >To: Kopylenko, Dmitry >Cc: spr...@li... >Subject: Re: [Springframework-developer] new bean factory and application >context features > > >I think .NET does this well. I think it can simplify typical usage, without >sacrificing the ability to do more complex things externally. > >So I'm very keen to get it implemented--not too much work once we have >usable attributes--and give it a spin. > >Regards, >Rod > >----- Original Message ----- >From: "Kopylenko, Dmitry" <dko...@su...> >To: "'Colin Sampaleanu'" <col...@ex...> >Cc: "' '"jürgen höller [werk3AT]" ' '" <jue...@we...>; ><spr...@li...> >Sent: Wednesday, October 15, 2003 12:53 PM >Subject: RE: [Springframework-developer] new bean factory and application >context features > > >I guess it's -1 against the source level metadata use case. Well, since this >is a brand new concept (for java at least) what are everyone's >thoughts/feelings about it? > >Regards, >Dmitriy. > > >-----Original Message----- >From: Colin Sampaleanu [mailt:col...@ex...] >Sent: Tuesday, October 14, 2003 6:09 PM >To: Kopylenko, Dmitry >Cc: "'\"jürgen höller [werk3AT]\" '"; >'spr...@li... ' >Subject: Re: [Springframework-developer] new bean factory and application >context features > > >I suppose, although to tell you the truth I prefer to declare my >trnasactions separately from the source. Putting them in the source couples >things too closely for my taste, and makes management harder, given that I >want to change things around for unit tests and the like. > > >Kopylenko, Dmitry wrote: > > > >>Colin, >> >>that will be possible when the metadata support and "magic" >>TransactionAutoProxy creator will be in place ;-) >> >>Regards, >>Dmitriy. >> >>-----Original Message----- >>From: Colin Sampaleanu >>To: "jürgen höller [werk3AT]" >>Cc: spr...@li... >>Sent: 10/14/2003 5:49 PM >>Subject: Re: [Springframework-developer] new bean factory and >>application context features >> >>jürgen höller [werk3AT] wrote: >> >> >> >> >> >>>... >>> >>>This is a BeanPostProcessor bean that can be set up as follows to >>>proxy >>> >>> >>> >>> >>the beans with the given names with the given interceptors. Note that >>this is only one bean with proxy settings to define, although there >>might be dozens of target beans with the same proxy behavior. >> >> >> >> >>><bean id="autoProxyCreator" >>> >>> >>> >>> >>class="org.springframework.aop.framework.support.AutoProxyCreator"> >> >> >> >> >>><property >>> >>> >>> >>> >>name="beanNames"><value>myBean1,myBean2,myBean3</value></property> >> >> >> >> >>><property name="interceptors> >>> <list> >>> <ref bean="myInterceptor1"/> >>> <ref bean="myInterceptor2"/> >>> </list> >>></property> >>></bean> >>> >>>So setting up 10 transactional beans would just involve 1 >>> >>> >>> >>> >>AutoProxyCreator and 1 transaction interceptor plus the 10 target beans >>(12 beans in total), instead of 10 TransactionProxyFactoryBeans plus >>the 10 target beans (20 beans in total). The transaction attributes >>would be centralized though, in contrast to TransactionProxyFactoryBean >>that keeps them local per individual proxy definition. >> >> >> >> >>> >>> >>> >>> >>Hi Juergen, >> >>How do you see this being used (if at all) with the current >>TransactionInterceptor, since its TransactionAttributeSource property >>gets satisfied via a MethodMapTransactionAttributeSource instance >>(which >> >>needs definitions in the format 'FQN.methodName'). While this works >>fine >> >>when doing individual interceptors for use with ProxyFactoryBean, short >>of adding new code I'm at a loss as to how I could use >>TransactionInterceptor with BeanNameAutoProxy to do transactions on all >>methods in all the beans I feed to the auto proxy. >> >>Just wondering if I missed something? >> >>Regards, >>Colin >> >> |