how to give database connection string in configuration file

[Jitto P.Jose]

hai friends.
I am building a jsf application. previously i worked in asp.net and struts. in struts there is some way to specify datasource in struts-config.xml and also in asp.net, web.config.
shall i know what is the similar method that can be used with jsf application.
i am using netbeans 6 ide, mysql database. please help me
thank you
jittos....

[Hussein Baghdadi]

JSF doesn't support declaring a data source in configuration file.
You have to fall back to your own bag of tricks...

[Jitto P.Jose]

i think , we can specify connection string in web.xml or server.xml of tomcat. which one would be better if the application is used by more than 500 people at a time.

[Ulf Dittmer]

I wouldn't use either of those, but keep it in a properties file that also contains all other application settings, of which there are doubtless many. The number of users makes no difference.

[Hussein Baghdadi]

Tomcat provides a read-only JNDI registry, you can declare a global data source in Tomcat and use JNDI to get connections to your database.

[Jitto P.Jose]

shall i know, whether there any advantages if i specify datasource in sever other than code itself?

[Hussein Baghdadi]

Connections Pool is the first thing comes to my mind.
But please note that your need to restart your server if you changed your data source configuration (in the case you decided to take the global data source route).

[Jitto P.Jose]

what about connection pooling if i specify datasource in code? wont sever create connection pool then?

[Tim Holloway]

I recommend defining the connection pool (and the connections themselves) in the tomcat resources (Context). For a couple of reasons:

1. There are actually several different database connection poolers available to Tomcat. The most common one is Apache DBCP, but it's not the only one. If you specify the connection pooler externally as a Tomcat resource, you don't have to rebuild your application if you want to try a different pooler for performance reasons or to get around pooler bugs.

2. If you specify the connection info externally, you can switch to an alternate database without recompiling and rebuilding the app. This can be useful for disaster recovery purposes. It's also good for testing. Whenever I can, I build my apps so that the test WAR and the production WAR are the same WAR and all the test/production definitions are external. That way I'm assured that the code in production is the same code as what I tested.