Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Spring DAO and applicationConfig

 
Gregg Bolinger
GenRocket Founder
Ranch Hand
Posts: 15302
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A partial answer is the "parent" attribute for bean inheritance:
 
Craig Walls
author
Ranch Hand
Posts: 363
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


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 ]
 
Gregg Bolinger
GenRocket Founder
Ranch Hand
Posts: 15302
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Craig. I guess I should really break open that book, huh.
 
Ken Krebs
Ranch Hand
Posts: 451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Have fun hitting those books Gregg

There are other organizational things you can do.

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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic