Re: BasicDataSourceFactory (dbcp)
Marc Logemann wrote: Hi, i just read http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jndi-datasource-examples-howto.html and saw that dbcp uses username as a property for their DataSource Implementation. I allways thought that the specs say that one should use user. Shouldnt this be consistent across all DataSource implementations? --- greetings from Marc Logemann Homebase @ www.logemann.info I have posted several times regarding this! In answer to your question, it ought to be, but because there is no standard DTD for servlet containers, or EJB containers, everybody can do his own thing! :-( I still think that there ought to be an DTD for server.xml, and maybe a way to map 'tomcat standard' parameter names to individual DataSource implementations. IMO, such a DTD (if documented!) would cut out a large proportion of the posts on this list! Just my Euro 0,02 Martin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: BasicDataSourceFactory (dbcp)
Hi, I have posted several times regarding this! In answer to your question, sorry to bother you :) it ought to be, but because there is no standard DTD for servlet containers, or EJB containers, everybody can do his own thing! :-( i dont know if a DTD would help out, i mean we cant define bean properties for a custom datasource in advance in an DTD or? I still think that there ought to be an DTD for server.xml, and maybe a way to map 'tomcat standard' parameter names to individual DataSource implementations. IMO, such a DTD (if documented!) would cut out a large proportion of the posts on this list! THe point is, SUN defined at least some property names in http://java.sun.com/products/jdbc/jdbc20.stdext.pdf Paragraph: 5.3.1 it would be nice if at least the common ones would be uniform. Also just my 2 cents. --- greetings from Marc Logemann Homebase @ www.logemann.info -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: BasicDataSourceFactory (dbcp)
Marc Logemann wrote: Hi, I have posted several times regarding this! In answer to your question, sorry to bother you :) I wasn't complaining - it was merely an observation; I 'discovered' this a month back, and have posted several replies to people in difficulty. it ought to be, but because there is no standard DTD for servlet containers, or EJB containers, everybody can do his own thing! :-( i dont know if a DTD would help out, i mean we cant define bean properties for a custom datasource in advance in an DTD or? I still think that there ought to be an DTD for server.xml, and maybe a way to map 'tomcat standard' parameter names to individual DataSource implementations. IMO, such a DTD (if documented!) would cut out a large proportion of the posts on this list! THe point is, SUN defined at least some property names in http://java.sun.com/products/jdbc/jdbc20.stdext.pdf Paragraph: 5.3.1 it would be nice if at least the common ones would be uniform. Having read the doc (thanks for the link), I think you ought to post a bug report to the DBCP project for an incorrect property name... come to think of it, I might try to do that myself! But, if there is a 'standard' set of properties for a DataSource, why can't they be expressed in a formal way - i.e. currently we write: Resource name=jdbc/RadiationDB auth=Container type=javax.sql.DataSource / ResourceParams name=jdbc/RadiationDB parameter namefactory/name valueorg.apache.commons.dbcp.BasicDataSourceFactory/value /parameter ... which means that an XML parser can only check that it is well-formed. Instead, it would be nice to be able to write: Resource name=jdbc/RadiationDB auth=Container type=javax.sql.DataSource / DataSourceParams name=jdbc/RadiationDB factory-class org.apache.commons.dbcp.BasicDataSourceFactory /factory-class ... with parameter reserved for vendor-specific extensions. This would allow a validating parser to barf at most errors, instead of us all having to rely on examining the log files and interpreting stack traces! Getting off soap-box, now! cheers, Martin. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: BasicDataSourceFactory (dbcp)
I can't tell you why it works this way, but with the MS JDBC driver, the param name has to be username. It doesn't work otherwise. - Andrew -Original Message- From: Martin Jacobson [mailto:[EMAIL PROTECTED]] Sent: Friday, July 12, 2002 7:39 AM To: Tomcat Users List Subject: Re: BasicDataSourceFactory (dbcp) Marc Logemann wrote: Hi, I have posted several times regarding this! In answer to your question, sorry to bother you :) I wasn't complaining - it was merely an observation; I 'discovered' this a month back, and have posted several replies to people in difficulty. it ought to be, but because there is no standard DTD for servlet containers, or EJB containers, everybody can do his own thing! :-( i dont know if a DTD would help out, i mean we cant define bean properties for a custom datasource in advance in an DTD or? I still think that there ought to be an DTD for server.xml, and maybe a way to map 'tomcat standard' parameter names to individual DataSource implementations. IMO, such a DTD (if documented!) would cut out a large proportion of the posts on this list! THe point is, SUN defined at least some property names in http://java.sun.com/products/jdbc/jdbc20.stdext.pdf Paragraph: 5.3.1 it would be nice if at least the common ones would be uniform. Having read the doc (thanks for the link), I think you ought to post a bug report to the DBCP project for an incorrect property name... come to think of it, I might try to do that myself! But, if there is a 'standard' set of properties for a DataSource, why can't they be expressed in a formal way - i.e. currently we write: Resource name=jdbc/RadiationDB auth=Container type=javax.sql.DataSource / ResourceParams name=jdbc/RadiationDB parameter namefactory/name valueorg.apache.commons.dbcp.BasicDataSourceFactory/value /parameter ... which means that an XML parser can only check that it is well-formed. Instead, it would be nice to be able to write: Resource name=jdbc/RadiationDB auth=Container type=javax.sql.DataSource / DataSourceParams name=jdbc/RadiationDB factory-class org.apache.commons.dbcp.BasicDataSourceFactory /factory-class ... with parameter reserved for vendor-specific extensions. This would allow a validating parser to barf at most errors, instead of us all having to rely on examining the log files and interpreting stack traces! Getting off soap-box, now! cheers, Martin. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
