commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Pugh" <ep...@upstate.com>
Subject RE: [configuration] handling exceptions in AbstractConfiguration implementations
Date Wed, 06 Oct 2004 19:16:48 GMT
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:jmitchell@apache.org]
> 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" <smanux@lfjr.net>
> To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> 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: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message