File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Other Application Frameworks and the fly likes Spring DAO and applicationConfig Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Frameworks » Other Application Frameworks
Bookmark "Spring DAO and applicationConfig" Watch "Spring DAO and applicationConfig" New topic

Spring DAO and applicationConfig

Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15302

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 ]

GenRocket - Experts at Building Test Data
Lasse Koskela

Joined: Jan 23, 2002
Posts: 11962
A partial answer is the "parent" attribute for bean inheritance:

Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Craig Walls
Ranch Hand

Joined: Sep 19, 2003
Posts: 335

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 ]

Spring in Action - Unleash POJO power in your applications!
Modular Java - Discover the secret weapon to modularity on the Java platform!
XDoclet in Action - Your complete guide to code generation with XDoclet.
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15302

Thanks Craig. I guess I should really break open that book, huh.
Ken Krebs
Ranch Hand

Joined: Nov 27, 2002
Posts: 451
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.

kktec<br />SCJP, SCWCD, SCJD<br />"What we observe is not nature itself, but nature exposed to our method of questioning." - Werner Heisenberg
I agree. Here's the link:
subject: Spring DAO and applicationConfig
It's not a secret anymore!