I feel your pain. After spending time shuffling code up and down from a contrib folder so that gump would, then would not compile those sources, I finally moved the code over to sf.net and updated the docs to mention the additional impls.
I would like a straight answer on this too. I wish I could keep everything together. -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx ----- Original Message ----- From: "Eric Pugh" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Wednesday, October 06, 2004 3:16 PM Subject: RE: [configuration] handling exceptions in AbstractConfiguration implementations > This is really driving me crazy.. I have tracked threads on general and > jakarta-pmc mailing lists about this.. And everytime it comes down to "I am > not a lawyer" and a bunch of FUD. We really need someone from the top of > Apache to provide direction. I work a lot with hibernate code and can think > of at least 4 projects that have hibernate code in them (at least as far as > import statements). > > Of course, I guess this isn't the right mailing list.. I could try and push > this to some sort of conclusion, but I don't want to be told no! right now > you can just pick your interpretation! > > Argh, > Eric > > > -----Original Message----- > > From: James Mitchell [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, October 06, 2004 7:23 PM > > To: Jakarta Commons Developers List > > Subject: Re: [configuration] handling exceptions in > > AbstractConfiguration implementations > > > > > > 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] > > > --------------------------------------------------------------------- > 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]