One advantage for me is having the ability to reuse your existing application's configuration. I created a Hibernate, iBatis, Torque, DBUtils, and straight JDBC implementations for commons-resource for this very purpose.
I moved the Hibernate impl over to sf.net because of license conflicts. -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx ----- Original Message ----- From: "Emmanuel Bourg" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Wednesday, October 06, 2004 12:59 PM Subject: Re: [configuration] handling exceptions in AbstractConfiguration implementations > I don't want to sound harsh, but what is the added value of using > Hibernate here for such a simple data structure ? A direct JDBC > implementation is good enough and spare a 1.5MB dependency. > > Emmanuel Bourg > > > Ricardo Gladwell wrote: > > Hi All, > > > > I'm currently developing a sub-class of the AbstractConfiguration > > classthat uses Hibernate to access configuration properties > > (unimaginatively called Hibernate Configuration). I'm slightly concerned > > about the way sub-classes are suposed to handle exceptions: > > > > All the abstract method are defined as not throwing exceptions. All > > calls to hibernate, however, throw HibernateExceptions. So, for example, > > my implementation of getPropertyDirect calls the hibernate Session.get() > > method which can throw an exception. > > > > Looking at your implementation of the DatabaseConfiguration I can see > > that it simply consumes SQLExceptions thrown from the JDBC API, logging > > the stack trace. However, what if you want to be warned of exceptions > > being thrown by the underlying implementation of Configuration? > > > > I notice you already have a nestable ConfigurationException implemented. > > Surely, all Configuration methods should indicate they will throw this > > exception if they are expected to read/write data? > > > > Also, the AbstractConfiguration class does not describe this contract > > (logging all errors throw by underlying framework) or what should be > > returned in the event of an error? I assume you should return null > > values but this is not described anywhere. > > > > Kind regards, > > -- Ricardo Gladwell > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
