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> <name>factory</name> <value>org.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]>
