Last week, we had the author of TDD for a Shopping Website LiveProject. Friday at 11am Ranch time, Steven Solomon will be hosting a live TDD session just for us. See for the agenda and registration link
As I aad DAO's my applicationConfig seems to be getting larger and larger. Here is my current applicationConfig.xml up to this point.
I still have at least 5 more DAO's left to code which means 15 more bean definitions with the current way I am doing things. Is there anything I can do to condense this a bit? Speficially all the service definitions are identical except for the target property. Is there anyway to define 1 service and configure it to pull whatever target I need? [ March 14, 2005: Message edited by: Gregg Bolinger ]
The TransactionAttributeSourceAdvisor collaborates with a TransactionInterceptor:
The TransactionInterceptor collaborates with a transaction manager (of your choosing) and a transaction attribute source (also of your choosing). It is the transaction attribute source that ultimately is consulted to define the pointcuts for the TransactionAttributeSourceAdvisor.
I recommend the use of MethodMapTransactionAttributeSource when autoproxying transactions because it lets you specify exactly which methods of which beans get proxied with transactions. For example:
Here I've defined 3 beans in addition to your application's service beans (and whatever other beans you may have). All of the transactions are declared in the "methodMap" property of the "transactionAttributeSource" bean. What's more, you can use wildcards to limit the configuration even further. If you take a closer look at the 2nd transaction attribute declaration, you'll see that I've used a wildcard to apply PROPAGATION_REQUIRED to all of IssueLevelServiceImpl's methods that start with "get".
This also gets rid of the notion of a "target" bean for each of your services. Instead of declaring your service beans as "myServiceTarget" and a ProxyFactoryBean as "myService" (which always seemed screwy to me), you simply declare a single bean named "myService" which is your service bean. The auto-proxy takes care of the rest.
All of this is explained in further detail in section 5.6.2 of Spring in Action. [ March 15, 2005: Message edited by: Craig Walls ]
There is an "import" tag to simply bring in another applicationContext file.
You can also organize your application contexts (or HierarchicalBeanFactory's of which ApplicationContext is a descendant) hierarchically. You can see an example of this when using SpringMVC, for instance in Petclinic. The root applicationContext file (either for jdbc, hibernat, or ojb) is the parent of the petclinic-servlet.xml application context. From the point of view of the petclinic-servlet.xml application context, all of the root application context beans are visible. The root application context beans however cannot see those in its child application contexts. Also peer application contexts cannot see each others beans.
kktec<br />SCJP, SCWCD, SCJD<br />"What we observe is not nature itself, but nature exposed to our method of questioning." - Werner Heisenberg
All of life is a contant education - Eleanor Roosevelt. Tiny ad:
Free, earth friendly heat - from the CodeRanch trailboss