Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Better approach if i have multiple datasources JNDIObjectFactoryBean or JVM Variables

 
Akshay Lele
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,

I am working on a Spring project in which there are 2 JNDI data sources. At a time though only one JNDI data source will be used. Basically the client wants to easily switch between this 2 data sources, again this is not to be done at run time.

So to make the application code independent of the data source currently being used there are 2 approaches that i have figured out.

1. Use JNDIObjectFactoryBean class. Specify the jndi name in xml file. Inject the factory bean in DAO class to get Data Source.
In case data source needs to be changed just change the jndi name only in xml file, no change needed in DAO code.

2. Use a JVM Variable and set in Websphere. In DAO use System.getProperty() get the value of the variable. In case data source needs to be changed just change the value of JVM Variable. Here also there would be no change in DAO code.

What i really want to know is which would be a good approach (Point 1 or 2)? If any of you can tell me the pros and cons of these 2 approaches(with respect to performance etc) i would really appreciate it.

Thanks in Advance.

Regards,

Akshay
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes.

Both are good approaches.

If you are using the latest Spring version you can use the JVM Variable and SpEL Spring Expression Language to dynamically get it. So you wouldn't have to code System.getProperty("myPropertyName");

instead in your xml the value could be

#{systemProperties.myPropertyName}

or if you are using an older version of Spring you can use a PropertyPlaceholderConfigurer, you don't even need to set it to a .properties file. But by default the PropertyPlaceholderConfigurer will look for a property called myPropertyName first in the .properties file if there is one, then go to System.getProperty(), then look for an environment variable.

Mark
 
Akshay Lele
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mark Spritzler wrote:Yes.

Both are good approaches.

If you are using the latest Spring version you can use the JVM Variable and SpEL Spring Expression Language to dynamically get it. So you wouldn't have to code System.getProperty("myPropertyName");

instead in your xml the value could be

#{systemProperties.myPropertyName}

or if you are using an older version of Spring you can use a PropertyPlaceholderConfigurer, you don't even need to set it to a .properties file. But by default the PropertyPlaceholderConfigurer will look for a property called myPropertyName first in the .properties file if there is one, then go to System.getProperty(), then look for an environment variable.

Mark


Thank you Mark for the info. I am using a older version of Spring hence would try using PropertyPlaceholderConfigurer. But is there no definite advantage of using approach 1 over 2 right?
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Akshay Lele wrote:

Thank you Mark for the info. I am using a older version of Spring hence would try using PropertyPlaceholderConfigurer. But is there no definite advantage of using approach 1 over 2 right?


Right 6.00123 of one, half dozen of the other.

Meaning they have slight differences, but in general it is the same.

One is just slightly more externalized than the other. But both would require changing a file and redeploying. In the case of the xml file, if it is part of your archive file that you deploy, then you just have one more step to recreating your jar/war package.

Mark
 
Akshay Lele
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you Mark. I also implemented PropertyPlaceholderConfigurer successfully.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic