You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Ricardo Gladwell <ri...@btinternet.com> on 2004/10/06 12:55:52 UTC
[configuration] handling exceptions in AbstractConfiguration implementations
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
Re: Licensing
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 7 Oct 2004, at 15:58, Ricardo Gladwell wrote:
> Henning P. Schmiedehausen wrote:
>> Henri Yandell <fl...@gmail.com> writes:
>> IMHO, it is a real "must read" for everyone that writes and especially
>> uses open source. Funnily enough, many of the points that she raises
>> don't apply to the ASF.
>
> Hmm... I might disagree with that one. For example, I don't know many
> newbie users who could single-handedly set-up and configure the Apache
> web server with Tomcat without encountering a few problems.
hmm...
not sure that that's a very good example.
AIUI interoperation with apache HTTPD was never really a primary goal
of tomcat (and was left to secondary sub-projects). jserv is the ASF
project which fills that gap. IIRC as a very green newbie, i found
jserv really easy to install and integrate with apache HTTPD.
> Also, some ASF projects have very skimpy documentation in places.
i'd go as far as saying most. but (once a project's been around long
enough) there are usually enough books and articles to make up for this
deficit. it interests me that academic licensed project seem to make up
for lack of technical documentation by the quantity of published hard
copy.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Licensing
Posted by James Mitchell <jm...@apache.org>.
How dare they say that about us!!!
;)
--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx
----- Original Message -----
From: "Ricardo Gladwell" <ri...@btinternet.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Thursday, October 07, 2004 10:58 AM
Subject: Re: Licensing
> Henning P. Schmiedehausen wrote:
> > Henri Yandell <fl...@gmail.com> writes:
> > IMHO, it is a real "must read" for everyone that writes and especially
> > uses open source. Funnily enough, many of the points that she raises
> > don't apply to the ASF.
>
> Hmm... I might disagree with that one. For example, I don't know many
> newbie users who could single-handedly set-up and configure the Apache
> web server with Tomcat without encountering a few problems. Also, some
> ASF projects have very skimpy documentation in places.
>
> > "Fighting for one's political stand is an honorable action, but re-
> > fusing to acknowledge that there might be weaknesses in one's
> > position - in order to identify them so that they can be remedied -
> > is a large enough problem with the Open Source movement that it
> > deserves to be on this list of the top five problems."
> > -- Michelle Levesque, "Fundamental Issues with
> > Open Source Software Development"
>
> I have heard an interesting theory behind this: that the technical
> affinity shared by geeks and open-source advocates across the world is
> actually a form of mild autism, passed down the male line. Anecdotally,
> on my father's side many of my uncles are engineers, and my grandfather
> was an engineer (who, interestingly, claims to have invented the flip
> chart which he failed to patent) - the geek old guard. And, in this
> generation, most of my male cousins are working in the IT industry as
> programmers and system administrators - the new geeks.
>
> Anyway, my point is that it would also seem that, along with poor social
> skills and shyness, a form bi-polar fanaticism seems to come with this
> "techno-autism". The constant "them or us" attitude one sees on forums
> such as /. seem to be near universal constant.
>
> I mention it only for interests sake. :)
>
> Kind regards,
> -- Ricardo
>
> ---------------------------------------------------------------------
> 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
Re: Licensing
Posted by Ricardo Gladwell <ri...@btinternet.com>.
Henning P. Schmiedehausen wrote:
> Henri Yandell <fl...@gmail.com> writes:
> IMHO, it is a real "must read" for everyone that writes and especially
> uses open source. Funnily enough, many of the points that she raises
> don't apply to the ASF.
Hmm... I might disagree with that one. For example, I don't know many
newbie users who could single-handedly set-up and configure the Apache
web server with Tomcat without encountering a few problems. Also, some
ASF projects have very skimpy documentation in places.
> "Fighting for one's political stand is an honorable action, but re-
> fusing to acknowledge that there might be weaknesses in one's
> position - in order to identify them so that they can be remedied -
> is a large enough problem with the Open Source movement that it
> deserves to be on this list of the top five problems."
> -- Michelle Levesque, "Fundamental Issues with
> Open Source Software Development"
I have heard an interesting theory behind this: that the technical
affinity shared by geeks and open-source advocates across the world is
actually a form of mild autism, passed down the male line. Anecdotally,
on my father's side many of my uncles are engineers, and my grandfather
was an engineer (who, interestingly, claims to have invented the flip
chart which he failed to patent) - the geek old guard. And, in this
generation, most of my male cousins are working in the IT industry as
programmers and system administrators - the new geeks.
Anyway, my point is that it would also seem that, along with poor social
skills and shyness, a form bi-polar fanaticism seems to come with this
"techno-autism". The constant "them or us" attitude one sees on forums
such as /. seem to be near universal constant.
I mention it only for interests sake. :)
Kind regards,
-- Ricardo
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Licensing (was: Re: [configuration] handling exceptions in AbstractConfiguration implementations)
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Henri Yandell <fl...@gmail.com> writes:
>(Henning's .sig is especially apt in his reply btw. :) )
To me, the Levesque paper is a pretty good summary of the current
state of the (mostly GPL) open source community as a whole. It hurts
and she steps on so many toes of all the self-declared open-source
advocats and "all information must be free" types. This might be the
main reason, why "leading open source community advocates" did their
best to damage the reputation of her.
IMHO, it is a real "must read" for everyone that writes and especially
uses open source. Funnily enough, many of the points that she raises
don't apply to the ASF. Which IMHO shows, that the ASF, for all its
shortcomings and problems, seem to have gotten quite a number of
things right.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
"Fighting for one's political stand is an honorable action, but re-
fusing to acknowledge that there might be weaknesses in one's
position - in order to identify them so that they can be remedied -
is a large enough problem with the Open Source movement that it
deserves to be on this list of the top five problems."
-- Michelle Levesque, "Fundamental Issues with
Open Source Software Development"
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Licensing
Posted by Serge Knystautas <se...@lokitech.com>.
Henri Yandell wrote:
> I'll work to resolve the lack of published information. It's more than
> just LGPL really, we need a page that lists all acceptable
> OSI-accepted licences. LGPL is just the biggest issue as it's probably
> the 2nd most common open-source Java licence behind BSD-like.
http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing
This is on the old-soon-to-be-deprecated wiki, and it hasn't been ported
over.
--
Serge Knystautas
Lokitech >>> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Licensing (was: Re: [configuration] handling exceptions in AbstractConfiguration implementations)
Posted by Henri Yandell <fl...@gmail.com>.
Correct.
I'll work to resolve the lack of published information. It's more than
just LGPL really, we need a page that lists all acceptable
OSI-accepted licences. LGPL is just the biggest issue as it's probably
the 2nd most common open-source Java licence behind BSD-like.
As far as the FUD/IANAL stuff, it's all pretty honest but I'm happy to
take a stand and say that we won't have LGPL in Jakarta code until we
hear otherwise from the board.
I'd love to be using JFreeChart here, but it's LGPL.
Hen
(Henning's .sig is especially apt in his reply btw. :) )
On Wed, 6 Oct 2004 22:13:30 +0000 (UTC), Henning P. Schmiedehausen
<hp...@intermeta.de> wrote:
> "Eric Pugh" <ep...@upstate.com> writes:
>
> >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).
>
> There _is_ a clear statement from the board. And even though we don't
> really like it technology-wise, it is sound from a licensing point of
> view.
>
> #1 "No LGPL dependencies in code delivered from *.apache.org"
>
> #2 "import <xxx>" where <xxx> is a LGPLed package is already a dependency.
>
> I think that Geir made this clear on general@.
>
> So every project that does have e.g. Hibernate dependencies in there
> must move off-Apache. This holds true for some maven-plugins and it
> would also hold true for a possible Hibernate-related
> commons-configuration module.
>
> This is not a bad thing IMHO. Apache is mainly about community and the
> drive to keep the "sources clean".
>
> Having some modules or code being outside apache.org (e.g. on
> SourceForge) shouldn't be a big problem. We add a "links to related
> stuff" to the site and everything is fine.
>
> Regards
> Henning
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
> hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>
> RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
> Linux, Java, perl, Solaris -- Consulting, Training, Development
>
> "Fighting for one's political stand is an honorable action, but re-
> fusing to acknowledge that there might be weaknesses in one's
> position - in order to identify them so that they can be remedied -
> is a large enough problem with the Open Source movement that it
> deserves to be on this list of the top five problems."
> -- Michelle Levesque, "Fundamental Issues with
> Open Source Software Development"
>
> ---------------------------------------------------------------------
> 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
Licensing (was: Re: [configuration] handling exceptions in AbstractConfiguration implementations)
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Eric Pugh" <ep...@upstate.com> writes:
>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).
There _is_ a clear statement from the board. And even though we don't
really like it technology-wise, it is sound from a licensing point of
view.
#1 "No LGPL dependencies in code delivered from *.apache.org"
#2 "import <xxx>" where <xxx> is a LGPLed package is already a dependency.
I think that Geir made this clear on general@.
So every project that does have e.g. Hibernate dependencies in there
must move off-Apache. This holds true for some maven-plugins and it
would also hold true for a possible Hibernate-related
commons-configuration module.
This is not a bad thing IMHO. Apache is mainly about community and the
drive to keep the "sources clean".
Having some modules or code being outside apache.org (e.g. on
SourceForge) shouldn't be a big problem. We add a "links to related
stuff" to the site and everything is fine.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
"Fighting for one's political stand is an honorable action, but re-
fusing to acknowledge that there might be weaknesses in one's
position - in order to identify them so that they can be remedied -
is a large enough problem with the Open Source movement that it
deserves to be on this list of the top five problems."
-- Michelle Levesque, "Fundamental Issues with
Open Source Software Development"
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] handling exceptions in AbstractConfiguration implementations
Posted by James Mitchell <jm...@apache.org>.
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" <ep...@upstate.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
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: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" <sm...@lfjr.net>
> > To: "Jakarta Commons Developers List" <co...@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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] handling exceptions in AbstractConfiguration
Posted by Ricardo Gladwell <ri...@btinternet.com>.
Emmanuel Bourg wrote:
> Ricardo Gladwell wrote:
>> Henning P. Schmiedehausen wrote:
>>> (Can we keep the unavoidable licensing flame-fest centered on one
>>> list? general@jakarta or even general@apache.org preferred).
>>
>> I think you flamed first. Emmanuel just trolled :P
>
> Well I'm just highly interested in these license issues, I don't mean to
> flame anyone, it's just a courteous debate :)
>
> Emmanuel Bourg
Sorry, just me being facetious :)
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] handling exceptions in AbstractConfiguration
Posted by Emmanuel Bourg <sm...@lfjr.net>.
Ricardo Gladwell wrote:
> Henning P. Schmiedehausen wrote:
>
>> (Can we keep the unavoidable licensing flame-fest centered on one
>> list? general@jakarta or even general@apache.org preferred).
>
>
> I think you flamed first. Emmanuel just trolled :P
Well I'm just highly interested in these license issues, I don't mean to
flame anyone, it's just a courteous debate :)
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] handling exceptions in AbstractConfiguration
Posted by Ricardo Gladwell <ri...@btinternet.com>.
Henning P. Schmiedehausen wrote:
> (Can we keep the unavoidable licensing flame-fest centered on one
> list? general@jakarta or even general@apache.org preferred).
I think you flamed first. Emmanuel just trolled :P
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] handling exceptions in AbstractConfiguration
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Emmanuel Bourg <sm...@lfjr.net> writes:
>Henning P. Schmiedehausen wrote:
[...]
>> No, it is not. You should try to consider the implications of
>> e.g. paragraphs 5 and 6 of LGPLv2 in respect to your application.
>Ok, let's look at them, let me know if my understanding of the license
>is wrong.
> From http://www.fsf.org/licenses/lgpl.html
[...]
>"However, linking a "work that uses the Library" with the Library
>creates an executable that is a derivative of the Library (because it
>contains portions of the Library), rather than a "work that uses the
>library". The executable is therefore covered by this License. Section 6
>states terms for distribution of such executables."
>I understand it is a static linking, that's when the compilation produce
>one executable file containing both the author code and the library
>code. It doesn't apply to Java since every component remains in its own
>.class and .jar, all the code isn't melted into a single file.
Is it? Who draws the line? Think .war deployment. Think in-war
execution as e.g. WebLogic does. This is _one_ file, a complete
application (executeable) which runs in its environment. From a
lawyers point of view, it might not that much different from a
self-extracting archive that runs on a command line (You can argue,
that a WAR or EAR is a "distribution medium" for Java code, but then
again: That is a question for a lawyer, not a developer).
The distinction is blurred, right. The C-concepts simply don't apply
to Java code. You and I try to find a technical solution for a legal
problem. There is none. We simply use the wrong set of tools for this.
LGPL is a license defined and backed by the FSF. If you choose to
apply it verbatim to your code and distribute your code under this
license, you (as the licensor) and the user as the licensee are
_bound_ to this license! If you try to add additional restrictions to
the LGPL, you might find out, that LGPL suddently does not apply
anymore (paragraph 10) and in fact, no license between the two parties
exist. This is stupid, but I have already seen incredibly stupid
things in court.
>"When a "work that uses the Library" uses material from a header file
>that is part of the Library, the object code for the work may be a
>derivative work of the Library even though the source code is not.
>Whether this is true is especially significant if the work can be linked
>without the Library, or if the work is itself a library. The threshold
>for this to be true is not precisely defined by law."
>Header files doesn't exist in Java, this point is moot. Once again there
>is no code imported (I'm not sure about static variables in interfaces
>though, I'll have to check this).
Does it not? At which point, the code from the LGPL archive is
referenced? At compile time (Which is clearly not linking, but
inclusion in the C-sense)? Or at run-time? (Which would be dynamically
linking in the C-sense). Inclusion would make your code a derived
work!
I can get even worse than this... :-)
Imagine a malicious user writing a file
--- cut ---
package net.sf.hibernate;
public interface Session extends java.io.Serializable
{
[... add lots of method signatures
}
--- cut ---
and putting this under ASFv2 license. If I build against a set of mock
interfaces, can the result be put onto an apache.org server?
[...]
>So, what did I miss exactly ?
Nothing. You just _interpreted_ paragraph 5 and 6 with the intention
that ASFv2 and LGPL are compatible. So you put some meaning into Java
things like importing or runtime-references that fit your
explanation. Thats fine and a valid point of view It is possible to
interpret these things differently. And until the body that created
the LGPL (FSF) clears these different points of view up, there are
different interpretations.
I was just trying to play devils' advocate here.
The FSF refuses to clarify. So in the end, the board decided to play
it safe. Which means "LGPL is viral when used with Java code, so we
cannot have it on apache.org servers".
On a personal note: I do agree with you. However, our agreement
doesn't could much in a court.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
"Fighting for one's political stand is an honorable action, but re-
fusing to acknowledge that there might be weaknesses in one's
position - in order to identify them so that they can be remedied -
is a large enough problem with the Open Source movement that it
deserves to be on this list of the top five problems."
-- Michelle Levesque, "Fundamental Issues with
Open Source Software Development"
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] handling exceptions in AbstractConfiguration
Posted by Emmanuel Bourg <sm...@lfjr.net>.
Henning P. Schmiedehausen wrote:
> This is FUD. Hibenate is under LGPL. The LGPL and its implications are
> clearly defined by the FSF and they refuse (according to the board) to
> clarify the virality and the implications of the LGPL (which has been
> written a long, long time ago with C and C++ in mind) when used with
> Java code.
Yes, but it doesn't matter for projects not licensed by the FSF. The
Hibernate team picked the LGPL, they acknowledged the ambiguity with
regard to dynamic/static linking, and clarified how the LGPL applied for
their work. Even if it is not mentionned in the license it still has a
legal value, see my other post about this.
> The Hibernate people can write on their web site anything they
> want. In the end, the only License that you have is LGPL. This is,
> what counts in court. Not some "Licensing FAQ" which implies that
> program <xxx> is almost LGPL but not exactly and there is this
> exception if the wind is blowing from the east and christmas falls on
> a monday". [1]
You have the license + a clarification from the authors, that's enough
to clear the uncertaincy. This clarification is not a promise like "You
are infringing if you do so but I'll not sue you", I won't trust such a
promise, but it is "You are not infringing if you do so".
> If the Hiberate people really _want_ to make exceptions, they could
> easily license under one of the true free licenses which have been
> approved by the OSI: e.g. ASFv2, OSL, BSD.
Or they can keep the LGPL and put an exception in it, some projects do
this, for example GNU ClassPath that uses the GPL with an exception.
>>Excluding LGPLed projects is just a political decision imho.
>
> No, it is not. You should try to consider the implications of
> e.g. paragraphs 5 and 6 of LGPLv2 in respect to your application.
Ok, let's look at them, let me know if my understanding of the license
is wrong.
From http://www.fsf.org/licenses/lgpl.html
"5. A program that contains no derivative of any portion of the Library,
but is designed to work with the Library by being compiled or linked
with it, is called a "work that uses the Library". Such a work, in
isolation, is not a derivative work of the Library, and therefore falls
outside the scope of this License."
Great, no problem so far, it's the basic concept of the LGPL.
"However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library". The executable is therefore covered by this License. Section 6
states terms for distribution of such executables."
I understand it is a static linking, that's when the compilation produce
one executable file containing both the author code and the library
code. It doesn't apply to Java since every component remains in its own
.class and .jar, all the code isn't melted into a single file.
"When a "work that uses the Library" uses material from a header file
that is part of the Library, the object code for the work may be a
derivative work of the Library even though the source code is not.
Whether this is true is especially significant if the work can be linked
without the Library, or if the work is itself a library. The threshold
for this to be true is not precisely defined by law."
Header files doesn't exist in Java, this point is moot. Once again there
is no code imported (I'm not sure about static variables in interfaces
though, I'll have to check this).
"If such an object file uses only numerical parameters, data structure
layouts and accessors, and small macros and small inline functions (ten
lines or less in length), then the use of the object file is
unrestricted, regardless of whether it is legally a derivative work.
(Executables containing this object code plus portions of the Library
will still fall under Section 6.)"
Ok so even importing static variables from an interface is fine.
"Otherwise, if the work is a derivative of the Library, you may
distribute the object code for the work under the terms of Section 6.
Any executables containing that work also fall under Section 6, whether
or not they are linked directly with the Library itself."
Ok, let's look at the section 6:
"6. As an exception to the Sections above, you may also combine or link
a "work that uses the Library" with the Library to produce a work
containing portions of the Library, and distribute that work under terms
of your choice, provided that the terms permit modification of the work
for the customer's own use and reverse engineering for debugging such
modifications."
That means we are allowed to distribute only a part of the library, for
example a modified jar containing only the classes needed for our project.
" You must give prominent notice with each copy of the work that the
Library is used in it and that the Library and its use are covered by
this License. You must supply a copy of this License. If the work during
execution displays copyright notices, you must include the copyright
notice for the Library among them, as well as a reference directing the
user to the copy of this License. Also, you must do one of these things:"
Fair enough. The following points explain how the source code can be
distributed, I don't think it affects Java differently.
"For an executable, the required form of the "work that uses the
Library" must include any data and utility programs needed for
reproducing the executable from it. However, as a special exception, the
materials to be distributed need not include anything that is normally
distributed (in either source or binary form) with the major components
(compiler, kernel, and so on) of the operating system on which the
executable runs, unless that component itself accompanies the executable."
I think the distribution of the Ant or Maven build file complies with
this requirement.
"It may happen that this requirement contradicts the license
restrictions of other proprietary libraries that do not normally
accompany the operating system. Such a contradiction means you cannot
use both them and the Library together in an executable that you distribute"
It doesn't apply here.
So, what did I miss exactly ?
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] handling exceptions in AbstractConfiguration
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Emmanuel Bourg <sm...@lfjr.net> writes:
> From a technical/legal point of view there is no reason to avoid a
>dependency on a LGPLed component in an Apache project, the license FAQ
>on Hibernate is pretty clear:
>"The use of the unmodified Hibernate binary of course never affects the
>license of your application or distribution.
>If you modify Hibernate and redistribute your modifications, the LGPL
>applies."
This is FUD. Hibenate is under LGPL. The LGPL and its implications are
clearly defined by the FSF and they refuse (according to the board) to
clarify the virality and the implications of the LGPL (which has been
written a long, long time ago with C and C++ in mind) when used with
Java code.
The Hibernate people can write on their web site anything they
want. In the end, the only License that you have is LGPL. This is,
what counts in court. Not some "Licensing FAQ" which implies that
program <xxx> is almost LGPL but not exactly and there is this
exception if the wind is blowing from the east and christmas falls on
a monday". [1]
If the Hiberate people really _want_ to make exceptions, they could
easily license under one of the true free licenses which have been
approved by the OSI: e.g. ASFv2, OSL, BSD.
>Excluding LGPLed projects is just a political decision imho.
No, it is not. You should try to consider the implications of
e.g. paragraphs 5 and 6 of LGPLv2 in respect to your application.
Regards
Henning
(Can we keep the unavoidable licensing flame-fest centered on one
list? general@jakarta or even general@apache.org preferred).
[1] Everyone that uses Linux with binary modules _should_ be aware,
that this is really a GPL violation. The fact that the copyright
holder (Linus Torvalds) does not intend to sue, does not mean, that
there still is a license violation and strictly spoken, noone that
uses a binary module with the Linux kernel actually has a license for
the OS [2].
[2] personally, I couldn't live without the nvidia accelerated module. :-)
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
"Fighting for one's political stand is an honorable action, but re-
fusing to acknowledge that there might be weaknesses in one's
position - in order to identify them so that they can be remedied -
is a large enough problem with the Open Source movement that it
deserves to be on this list of the top five problems."
-- Michelle Levesque, "Fundamental Issues with
Open Source Software Development"
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] handling exceptions in AbstractConfiguration implementations
Posted by Tim Reilly <ti...@gmail.com>.
> Does the ASF and the FSF not get along?
Philosophically Yes!
The FSF philosophy is that software is a right. The Apache philosophy
is basically "give credit where credit is due", but your programs that
are derived from ASL software need not be free, and may be commercial
works. Sort of a socialism versus capitalism analogy. (Disclaimer -
it's been way too long since studying Rousseau, Marx etc..so don't
flame me if socialism isn't correct)
>From GNU - "Copyleft licenses such as the GNU GPL insist that modified
versions of the program must be *free software as well*. Non-copyleft
licenses do not insist on this."
Part of the GPL on derivative work;
"You must cause any work that you distribute or publish, that in whole
or in part contains or is derived from the Program or any part
thereof, to be licensed as a whole at no charge to all third parties
under the terms of this License."
Ok, so FSF is ALL about free software and keeping it free. The GPL is
all about making sure commercial programs don't swipe the code to make
an enhanced for profit version.
But then there's the LGPL basically created as to allow shared library
code to be used by proprietary vendors as well.
The problem as I see it is that the LGPL was written with C/C++ in
mind, thus the words "linked", "object code", "object files" etc, are
used. For example; "We use this license for certain libraries in order
to permit *linking* those libraries into non-free programs."
- the relevance of the wording in regards to Java, scripted languages
etc, makes everything less than clear.
Well, the FSF is coming up to its 20th anniversary. Perhaps, we can
help them celebrate by asking them to reword the licenses in a more
language neutral manner.
I have no legal background. I'm just expressing my own conclusions
after researching this question, and trying to figure out what the
problem was.
On Thu, 07 Oct 2004 11:41:28 +0100, Ricardo Gladwell
<ri...@btinternet.com> wrote:
> Emmanuel Bourg wrote:
> > Excluding LGPLed projects is just a political decision imho.
> >
> > Emmanuel Bourg
>
> Sorry for sounding newbie about this, but what exactly are the political
> difficulties to hosting LGPL and ASL projects on the apache.org domain.
> Does the ASF and the FSF not get along?
>
> Kind regards,
> -- Ricardo
>
>
>
>
> ---------------------------------------------------------------------
> 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
Re: Licensing
Posted by Henri Yandell <fl...@gmail.com>.
On Thu, 07 Oct 2004 16:19:36 +0200, Emmanuel Bourg <sm...@lfjr.net> wrote:
> Henri Yandell wrote:
>
> > Now we're onto the IANAL stuff and ponderings on how to get such
> > suggestions to a lawyer without it turning into an expensive 2 week
> > Q&A. Can Promissory Estoppel (whatever that is) be given just on a
> > website etc.
> >
> > For example, I'd love to see an ASF lawyer come up with a concise
> > 'footnote' to the LGPL that we could ask Java LGPL users to add to
> > their licences. Or just a 'promissory estoppel' that could be placed
> > there.
>
> That's a good idea, how do we contact the ASF lawyers ?
With difficulty. Eavesdropping on the board list, they are working on
ways to get a better line of communication to the legal team (and
getting a more defined legal team). There are some number of pro-bono
hours per month, but these are easy to use up I think.
My plan for this issue is:
1) Identify the current situation to get away from the "Can I use
project X which is under LGPL" questions. See
http://wiki.apache.org/jakarta/LicenceIssues.
2) Ensure the Jakarta cvs repository is clean in regards to said issues.
3) Collate ideas for work-arounds. Plugin-architecture; footnotes to LGPL etc.
4) Any work-arounds that seem good would then be put on a request for
the board to consider.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Licensing
Posted by Emmanuel Bourg <sm...@lfjr.net>.
Henri Yandell wrote:
> To answer Richard's question (didn't see it) I think the only
> political difficulty is the usual 'Free-Software' vs 'Open-Source' one
> that has existed for a long time. Which links to Henning's point; we
> spend tonnes of time and effort on tiny matters on legal pedantics
> instead of coding.
True, but on the other hand we could spend tonnes of times and effort
duplicating LGPL code because no one cleared the legal uncertaincy.
> Now we're onto the IANAL stuff and ponderings on how to get such
> suggestions to a lawyer without it turning into an expensive 2 week
> Q&A. Can Promissory Estoppel (whatever that is) be given just on a
> website etc.
>
> For example, I'd love to see an ASF lawyer come up with a concise
> 'footnote' to the LGPL that we could ask Java LGPL users to add to
> their licences. Or just a 'promissory estoppel' that could be placed
> there.
That's a good idea, how do we contact the ASF lawyers ?
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Licensing
Posted by Henri Yandell <fl...@gmail.com>.
On Thu, 07 Oct 2004 13:13:32 +0200, Emmanuel Bourg <sm...@lfjr.net> wrote:
> Ricardo Gladwell wrote:
> > Emmanuel Bourg wrote:
> >
> >> Excluding LGPLed projects is just a political decision imho.
> >>
> >> Emmanuel Bourg
> >
> >
> > Sorry for sounding newbie about this, but what exactly are the political
> > difficulties to hosting LGPL and ASL projects on the apache.org domain.
> > Does the ASF and the FSF not get along?
To answer Richard's question (didn't see it) I think the only
political difficulty is the usual 'Free-Software' vs 'Open-Source' one
that has existed for a long time. Which links to Henning's point; we
spend tonnes of time and effort on tiny matters on legal pedantics
instead of coding.
> The concept of the LGPL is quite clear for me, it's "do whatever you
> want with your code, but if you change my LGPL code, you have to license
> your modification under the LGPL".
>
> I agree the LGPL may be worded ambiguously with regard to Java programs,
> but for Hibernate this ambiguity is clarified in the License FAQ. One
> could say this FAQ has no legal value if it's not included in the actual
> license, but it's not true. It's a promise made on the official site,
> that's endorsed by the authors, that they will not consider this usage
> as an infringement of their copyright, and this kind of promise has a
> legal value in court, see "Promissory Estoppel" for more information.
Now we're onto the IANAL stuff and ponderings on how to get such
suggestions to a lawyer without it turning into an expensive 2 week
Q&A. Can Promissory Estoppel (whatever that is) be given just on a
website etc.
For example, I'd love to see an ASF lawyer come up with a concise
'footnote' to the LGPL that we could ask Java LGPL users to add to
their licences. Or just a 'promissory estoppel' that could be placed
there.
I agree that no one who has made their library LGPL does so for
potential Java virality.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Licensing
Posted by Emmanuel Bourg <sm...@lfjr.net>.
Ricardo Gladwell wrote:
> Emmanuel Bourg wrote:
>
>> Excluding LGPLed projects is just a political decision imho.
>>
>> Emmanuel Bourg
>
>
> Sorry for sounding newbie about this, but what exactly are the political
> difficulties to hosting LGPL and ASL projects on the apache.org domain.
> Does the ASF and the FSF not get along?
The concept of the LGPL is quite clear for me, it's "do whatever you
want with your code, but if you change my LGPL code, you have to license
your modification under the LGPL".
I agree the LGPL may be worded ambiguously with regard to Java programs,
but for Hibernate this ambiguity is clarified in the License FAQ. One
could say this FAQ has no legal value if it's not included in the actual
license, but it's not true. It's a promise made on the official site,
that's endorsed by the authors, that they will not consider this usage
as an infringement of their copyright, and this kind of promise has a
legal value in court, see "Promissory Estoppel" for more information.
You can ask any author of a Java LGPLed project to make a similar
clarification if you want to use its work in an ASLed code, I'm ready to
bet none will refuse because it was the way they intended to distribute
their work.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] handling exceptions in AbstractConfiguration
implementations
Posted by Ricardo Gladwell <ri...@btinternet.com>.
Emmanuel Bourg wrote:
> Excluding LGPLed projects is just a political decision imho.
>
> Emmanuel Bourg
Sorry for sounding newbie about this, but what exactly are the political
difficulties to hosting LGPL and ASL projects on the apache.org domain.
Does the ASF and the FSF not get along?
Kind regards,
-- Ricardo
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] handling exceptions in AbstractConfiguration
implementations
Posted by Emmanuel Bourg <sm...@lfjr.net>.
Eric Pugh wrote:
> 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).
From a technical/legal point of view there is no reason to avoid a
dependency on a LGPLed component in an Apache project, the license FAQ
on Hibernate is pretty clear:
"The use of the unmodified Hibernate binary of course never affects the
license of your application or distribution.
If you modify Hibernate and redistribute your modifications, the LGPL
applies."
Excluding LGPLed projects is just a political decision imho.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [configuration] handling exceptions in AbstractConfiguration implementations
Posted by Eric Pugh <ep...@upstate.com>.
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" <sm...@lfjr.net>
> To: "Jakarta Commons Developers List" <co...@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
Re: [configuration] handling exceptions in AbstractConfiguration implementations
Posted by James Mitchell <jm...@apache.org>.
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" <sm...@lfjr.net>
To: "Jakarta Commons Developers List" <co...@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
Re: [configuration] handling exceptions in AbstractConfiguration
implementations
Posted by Ricardo Gladwell <ri...@btinternet.com>.
Emmanuel Bourg wrote:
> 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.
Nothing, AFAIK: the only reason I developed it was because I was using
Hibernate in my own application and I just thought it would be nice if
all database calls, including those for configuration, could be
re-directed through the Hibernate API to take advantage of it's caching,
logging, etc.
I only posted it here to demonstrate the issue I was explaining and
because of the interest - otherwise it will just sit in my project never
reaching the wider world. Do what thou wilt with it :)
Kind regards,
-- Ricardo
> 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
Re: [configuration] handling exceptions in AbstractConfiguration
implementations
Posted by Emmanuel Bourg <sm...@lfjr.net>.
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
Re: [configuration] handling exceptions in AbstractConfiguration
implementations
Posted by Ricardo Gladwell <ri...@btinternet.com>.
P.S. Please find the JUnit test code attached.
Ricardo Gladwell wrote:
> Eric Pugh wrote:
>
>> Hi Ricardo.. Sounds like you are working on something I've been
>> wanting for
>> a long time!
>
>
> Of course, I was going to release it anyway so please find the
> source-code attached. Not sure it belongs in commons-configration API;
> probably better contributed to the hibernate project. If you can think
> of any improvements please mail the patches back to me for my own
> project :)
>
>> In otherwords, say I am using a Configuration object in my code, and I do
>> configuration.getDouble("key");. If getDouble throws an exception
>> then I am
>> going to have these try/catch cluases all over the place, cluttering the
>> code. and, I really except getDouble() to allows work. If it
>> doesn't, my
>> application will just pass it on,not have some sort of fancy if getDouble
>> fails, then try getString or something weird.
>
>
> Good point, although I'm still dubious about throwing RuntimeExceptions
> - those things shoot straight through everything like a silver bullet
> and can even crash some servlet engines.
>
> From my perspective, I'm not bothered if the Configuration object
> throws exceptions: I wouldn't catch such exceptions in my web
> application, instead letting them fly all the way to the exception
> screen. This way, I can see them occuring as I test my application
> through the browser.
>
> Obviously, sometimes when configuring your application you just want
> your configuration to work or keep on working untill if it encounters an
> errors. However, simply allowing your application to ignore exceptions
> until they create new exception elsewhere seems like a good way to
> create hard-to-fix bugs. Surely, it would be better to relay the errors
> and let the application decide what to do with them?
>
>> I think what you can do is just wrap your HibernateException in a
>> ConfiguratoinRuntimeException and toss that. JDBCConfiguration should
>> probably be doning the same thing.
>
>
> Another alternative would be to have a getExceptions() method for all
> Configurations which stores exceptions occuring and stores them for
> later reporting. A good comprimise would be to allow all Configuration
> objects to have two modes: one where exceptions are thrown as soon as
> they occur and another one which stores exceptions as I suggested.
>
> Kind regards,
> -- Ricardo Gladwell
>
>>> -----Original Message-----
>>> From: Ricardo Gladwell [mailto:ricardo.gladwell@btinternet.com]
>>> Sent: Wednesday, October 06, 2004 12:56 PM
>>> To: Jakarta Commons Developers List
>>> Subject: [configuration] handling exceptions in AbstractConfiguration
>>> implementations
>>>
>>>
>>> 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
>
>
> ------------------------------------------------------------------------
>
> package net.sf.jexus.server.components;
>
> import org.apache.commons.logging.Log;
> import org.apache.commons.logging.LogFactory;
>
> import java.util.Iterator;
> import java.util.List;
>
> import net.sf.hibernate.HibernateException;
> import net.sf.hibernate.Session;
> import net.sf.hibernate.Transaction;
> import net.sf.jexus.server.data.object.ConfigurationProperty;
>
> import org.apache.commons.beanutils.ConvertUtils;
> import org.apache.commons.configuration.AbstractConfiguration;
>
> /**
> * <p>Hibernate configuation class. Reads configuration infomation from a
> * database through the <a href="http://www.hibernate.org/">Hibernate</a>
> * O/R mapping API. Data is stored as name-value pairs, along with the class
> * information of data stored, using the mapping* defined by the
> * {@link ConfigurationProperty} POJO hibernate xdoclet directives. Values are
> * converted to and from strings using
> * {@link org.apache.commons.beanutils.ConvertUtils}.</p>
> *
> * @author <a href="mailto:ricardo.gladwell@btinternet.com">Ricardo Gladwell</a>
> */
> public class HibernateConfiguration extends AbstractConfiguration {
>
> /**
> * Logger for this class
> */
> private static final Log log = LogFactory.getLog(HibernateConfiguration.class);
>
> /**
> * Reference to the session factory.
> */
> Session session;
>
> /**
> *
> */
> class KeyIterator implements Iterator {
>
> Iterator iterator;
> String last;
>
> public KeyIterator(Iterator iterator) throws HibernateException {
> this.iterator = iterator;
> }
>
> /**
> * @see java.util.Iterator#hasNext()
> */
> public boolean hasNext() {
> return iterator.hasNext();
> }
>
> /**
> * @see java.util.Iterator#next()
> */
> public Object next() {
> ConfigurationProperty config = (ConfigurationProperty)iterator.next();
> String key = config.getName();
> last = key;
> return key;
> }
>
> /**
> * @see java.util.Iterator#remove()
> */
> public void remove() {
> clearProperty(last);
> }
>
> }
>
> /**
> *
> */
> public HibernateConfiguration(Session session) {
> super();
> if(log.isTraceEnabled()) log.trace("HibernateConfiguration()");
> this.session = session;
> }
>
> /**
> * @see org.apache.commons.configuration.AbstractConfiguration#getPropertyDirect(java.lang.String)
> */
> protected Object getPropertyDirect(String key) {
> if(log.isTraceEnabled()) log.trace("getPropertyDirect("+key+")");
> ConfigurationProperty config = null;
> try {
> config = (ConfigurationProperty) session.get(ConfigurationProperty.class,key);
> } catch(HibernateException e) {
> log.error("Error reading congfiguration property=["+key+"]",e);
> return null;
> }
> try {
> Class clazz = getClass().getClassLoader().loadClass(config.getType());
> return ConvertUtils.convert(config.getValue(), clazz);
> } catch(ClassNotFoundException e) {
> log.warn("Cannot find class=["+config.getType()+"] for property=["+key+"]",e);
> }
> return config.getValue();
> }
>
> /**
> * @see org.apache.commons.configuration.AbstractConfiguration#addPropertyDirect(java.lang.String, java.lang.Object)
> */
> protected void addPropertyDirect(String key, Object value) {
> if(log.isTraceEnabled()) log.trace("addPropertyDirect("+key+","+value+")");
> ConfigurationProperty config = new ConfigurationProperty();
> config.setName(key);
> config.setValue(ConvertUtils.convert(value));
> config.setType(value.getClass().getName());
> try {
> Transaction transaction = session.beginTransaction();
> session.save(config);
> transaction.commit();
> } catch(HibernateException e) {
> log.error("Error adding congfiguration property=["+key+"]",e);
> }
> }
>
> /**
> * @see org.apache.commons.configuration.Configuration#isEmpty()
> */
> public boolean isEmpty() {
> if(log.isTraceEnabled()) log.trace("isEmpty()");
> try {
> List list = session.find("from Configuration");
> return list.isEmpty();
> } catch(HibernateException e) {
> log.error("Error reading keys.",e);
> return true;
> }
> }
>
> /***
> * @see org.apache.commons.configuration.Configuration#containsKey(java.lang.String)
> */
> public boolean containsKey(String key) {
> if(log.isTraceEnabled()) log.trace("containsKey("+key+")");
> return (getPropertyDirect(key) != null);
> }
>
> /**
> * @see org.apache.commons.configuration.Configuration#clearProperty(java.lang.String)
> */
> public void clearProperty(String key) {
> if(log.isTraceEnabled()) log.trace("clearProperty("+key+")");
> ConfigurationProperty config = new ConfigurationProperty();
> config.setName(key);
> try {
> Transaction transaction = session.beginTransaction();
> session.delete(config);
> transaction.commit();
> } catch(HibernateException e) {
> log.error("Error clearing congfiguration property=["+key+"]",e);
> }
> }
>
> /**
> * @see org.apache.commons.configuration.Configuration#getKeys()
> */
> public Iterator getKeys() {
> if(log.isTraceEnabled()) log.trace("getKeys()");
> try {
> List list = session.find("from Configuration");
> return new KeyIterator(list.iterator());
> } catch(HibernateException e) {
> log.error("Error reading keys.",e);
> return null;
> }
> }
>
> }
>
>
> ------------------------------------------------------------------------
>
> /*
> * Copyright 2004 Ricardo Gladwell
> *
> * Licensed under the Apache License, Version 2.0 (the "License");
> * you may not use this file except in compliance with the License.
> * You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
>
> package net.sf.jexus.server.data.object;
>
> /**
> * Hibernate persistance JavaBean encapsulating information about
> * a configuration property.
> *
> * @hibernate.class
> * table="configuration"
> *
> * @todo Create JUnit test cases.
> * @author <a href="mailto:ricardo.gladwell@btinternet.com">Ricardo Gladwell</a>
> * @version $Revision: 1.1 $, $Date: 2004/10/05 14:03:55 $
> */
> public class ConfigurationProperty {
>
> /**
> * Name of this configuration property.
> */
> String name;
>
> /**
> * String representation of the valye of this configuration property.
> */
> String value;
>
> /**
> * Fully qualified class for this configuration property's type.
> */
> String type;
>
> /**
> * Returns the key name for this configuration property.
> *
> * @hibernate.id
> * generator-class="assigned"
> *
> * @return Returns the name.
> */
> public String getName() {
> return name;
> }
>
> /**
> * Sets the key name for this configuration property.
> * @param name The name to set.
> */
> public void setName(String name) {
> this.name = name;
> }
>
> /**
> * Returns the value of this property.
> *
> * @hibernate.property
> *
> * @return Returns the value.
> */
> public String getValue() {
> return value;
> }
>
> /**
> * Sets the value of this property.
> * @param value The value to set.
> */
> public void setValue(String value) {
> this.value = value;
> }
>
> /**
> * Returns the fully qualified class name for the type
> * of the value for this configuration property.
> *
> * @hibernate.property
> *
> * @return Returns the type.
> */
> public String getType() {
> return type;
> }
>
> /**
> * Sets the fully qualified class name for the type
> * of the value for this configuration property.
> * @param type The type to set.
> */
> public void setType(String type) {
> this.type = type;
> }
> }
>
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] handling exceptions in AbstractConfiguration implementations
Posted by James Mitchell <jm...@apache.org>.
That is good to know. I am not a licensing expert. I'm just going off of a
prior conversation Stefan Bodewig whom I assume is more knowledgeable than I
wrt this issue.
----- Original Message -----
From: "Stefan Bodewig" <bo...@apache.org>
To: <co...@jakarta.apache.org>
Sent: Thursday, July 08, 2004 6:02 AM
Subject: Re: [GUMP@brutus]: jakarta-commons-sandbox/commons-resources
success
> On Tue, 6 Jul 2004, James Mitchell <jm...@minotaur.apache.org>
> wrote:
> > On Fri, 2 Jul 2004, Stefan Bodewig wrote:
> >
> >> Please note also that Hibernate's license is LGPL.
> >
> > I did not realize that. Can we continue to build these with this
> > dependency?
>
> I don't think so. At least you can't do a release with a dependency
> like this.
>
> > (If not, I can always push them back up to the contrib folder)
>
> If the contrib folder is outside of an ASF CVS or SVN repository.
>
> Stefan
--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx
----- Original Message -----
From: "Emmanuel Bourg" <sm...@lfjr.net>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Wednesday, October 06, 2004 1:03 PM
Subject: Re: [configuration] handling exceptions in AbstractConfiguration
implementations
> James Mitchell wrote:
> > Problem with having Hibernate implementations is that the license is
> > incompatible with the ASL. So you'll need to keep any incompatible code
> > somewhere else....like I do with commons-resources at sf.net.
>
> AKAIK Hibernate is licensed under the LGPL and is perfectly compatible
> with the ASL. Building an HibernateConfiguration doesn't constitue a
> modification of Hibernate requiring its distribution under the LGPL.
>
> Emmanuel Bourg
>
> ---------------------------------------------------------------------
> 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
Re: [configuration] handling exceptions in AbstractConfiguration
implementations
Posted by Emmanuel Bourg <sm...@lfjr.net>.
James Mitchell wrote:
> Problem with having Hibernate implementations is that the license is
> incompatible with the ASL. So you'll need to keep any incompatible code
> somewhere else....like I do with commons-resources at sf.net.
AKAIK Hibernate is licensed under the LGPL and is perfectly compatible
with the ASL. Building an HibernateConfiguration doesn't constitue a
modification of Hibernate requiring its distribution under the LGPL.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] handling exceptions in AbstractConfiguration implementations
Posted by James Mitchell <jm...@apache.org>.
I don't know about a parallel site, but I put my code under
sf.net/projects/struts (just because I already use that repos)
I'm not one of those letter-of-the-law types, but I don't want anything I
work on to be accused of said infractions (Gawd!! I sound like one now ;)
--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx
----- Original Message -----
From: "Eric Pugh" <ep...@upstate.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Wednesday, October 06, 2004 9:05 AM
Subject: RE: [configuration] handling exceptions in AbstractConfiguration
implementations
> I tried hitting commons-resources.sf.net but no joy.. I think this
> licensing thing is going to bite a lot of projects.. I was thinking of
> settingup a sf project called "hibernatecodethatiwantedatapache.sf.net"
> where I could toss all these bits and pieces.
>
> Has Jakarta-Commons actually set up a parralel site on SF to work around
> these issues?
>
> ERic
>
> > -----Original Message-----
> > From: James Mitchell [mailto:jmitchell@apache.org]
> > Sent: Wednesday, October 06, 2004 2:15 PM
> > To: Jakarta Commons Developers List
> > Subject: Re: [configuration] handling exceptions in
> > AbstractConfiguration implementations
> >
> >
> > Problem with having Hibernate implementations is that the license is
> > incompatible with the ASL. So you'll need to keep any incompatible code
> > somewhere else....like I do with commons-resources at sf.net.
> >
> >
> > --
> > James Mitchell
> > Software Engineer / Open Source Evangelist
> > EdgeTech, Inc.
> > 678.910.8017
> > AIM: jmitchtx
> >
> > ----- Original Message -----
> > From: "Ricardo Gladwell" <ri...@btinternet.com>
> > To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> > Sent: Wednesday, October 06, 2004 8:07 AM
> > Subject: Re: [configuration] handling exceptions in
AbstractConfiguration
> > implementations
> >
> >
> > > Eric Pugh wrote:
> > > > Hi Ricardo.. Sounds like you are working on something I've
> > been wanting
> > for
> > > > a long time!
> > >
> > > Of course, I was going to release it anyway so please find the
> > > source-code attached. Not sure it belongs in commons-configration API;
> > > probably better contributed to the hibernate project. If you can think
> > > of any improvements please mail the patches back to me for my
> > own project
> > :)
> > >
> > > > In otherwords, say I am using a Configuration object in my code, and
I
> > do
> > > > configuration.getDouble("key");. If getDouble throws an
> > exception then
> > I am
> > > > going to have these try/catch cluases all over the place,
> > cluttering the
> > > > code. and, I really except getDouble() to allows work. If
> > it doesn't,
> > my
> > > > application will just pass it on,not have some sort of fancy if
> > getDouble
> > > > fails, then try getString or something weird.
> > >
> > > Good point, although I'm still dubious about throwing
RuntimeExceptions
> > > - those things shoot straight through everything like a silver bullet
> > > and can even crash some servlet engines.
> > >
> > > From my perspective, I'm not bothered if the Configuration object
> > > throws exceptions: I wouldn't catch such exceptions in my web
> > > application, instead letting them fly all the way to the exception
> > > screen. This way, I can see them occuring as I test my application
> > > through the browser.
> > >
> > > Obviously, sometimes when configuring your application you just want
> > > your configuration to work or keep on working untill if it encounters
an
> > > errors. However, simply allowing your application to ignore exceptions
> > > until they create new exception elsewhere seems like a good way to
> > > create hard-to-fix bugs. Surely, it would be better to relay the
errors
> > > and let the application decide what to do with them?
> > >
> > > > I think what you can do is just wrap your HibernateException in a
> > > > ConfiguratoinRuntimeException and toss that. JDBCConfiguration
should
> > > > probably be doning the same thing.
> > >
> > > Another alternative would be to have a getExceptions() method for all
> > > Configurations which stores exceptions occuring and stores them for
> > > later reporting. A good comprimise would be to allow all Configuration
> > > objects to have two modes: one where exceptions are thrown as soon as
> > > they occur and another one which stores exceptions as I suggested.
> > >
> > > Kind regards,
> > > -- Ricardo Gladwell
> > >
> > > >>-----Original Message-----
> > > >>From: Ricardo Gladwell [mailto:ricardo.gladwell@btinternet.com]
> > > >>Sent: Wednesday, October 06, 2004 12:56 PM
> > > >>To: Jakarta Commons Developers List
> > > >>Subject: [configuration] handling exceptions in
AbstractConfiguration
> > > >>implementations
> > > >>
> > > >>
> > > >>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
> > >
> >
> >
> > ------------------------------------------------------------------
> > ----------
> > ----
> >
> >
> > > package net.sf.jexus.server.components;
> > >
> > > import org.apache.commons.logging.Log;
> > > import org.apache.commons.logging.LogFactory;
> > >
> > > import java.util.Iterator;
> > > import java.util.List;
> > >
> > > import net.sf.hibernate.HibernateException;
> > > import net.sf.hibernate.Session;
> > > import net.sf.hibernate.Transaction;
> > > import net.sf.jexus.server.data.object.ConfigurationProperty;
> > >
> > > import org.apache.commons.beanutils.ConvertUtils;
> > > import org.apache.commons.configuration.AbstractConfiguration;
> > >
> > > /**
> > > * <p>Hibernate configuation class. Reads configuration
> > infomation from a
> > > * database through the <a
> > href="http://www.hibernate.org/">Hibernate</a>
> > > * O/R mapping API. Data is stored as name-value pairs, along with the
> > class
> > > * information of data stored, using the mapping* defined by the
> > > * {@link ConfigurationProperty} POJO hibernate xdoclet
> > directives. Values
> > are
> > > * converted to and from strings using
> > > * {@link org.apache.commons.beanutils.ConvertUtils}.</p>
> > > *
> > > * @author <a href="mailto:ricardo.gladwell@btinternet.com">Ricardo
> > Gladwell</a>
> > > */
> > > public class HibernateConfiguration extends AbstractConfiguration {
> > >
> > > /**
> > > * Logger for this class
> > > */
> > > private static final Log log =
> > LogFactory.getLog(HibernateConfiguration.class);
> > >
> > > /**
> > > * Reference to the session factory.
> > > */
> > > Session session;
> > >
> > > /**
> > > *
> > > */
> > > class KeyIterator implements Iterator {
> > >
> > > Iterator iterator;
> > > String last;
> > >
> > > public KeyIterator(Iterator iterator) throws
> > HibernateException {
> > > this.iterator = iterator;
> > > }
> > >
> > > /**
> > > * @see java.util.Iterator#hasNext()
> > > */
> > > public boolean hasNext() {
> > > return iterator.hasNext();
> > > }
> > >
> > > /**
> > > * @see java.util.Iterator#next()
> > > */
> > > public Object next() {
> > > ConfigurationProperty config =
> > (ConfigurationProperty)iterator.next();
> > > String key = config.getName();
> > > last = key;
> > > return key;
> > > }
> > >
> > > /**
> > > * @see java.util.Iterator#remove()
> > > */
> > > public void remove() {
> > > clearProperty(last);
> > > }
> > >
> > > }
> > >
> > > /**
> > > *
> > > */
> > > public HibernateConfiguration(Session session) {
> > > super();
> > > if(log.isTraceEnabled())
log.trace("HibernateConfiguration()");
> > > this.session = session;
> > > }
> > >
> > > /**
> > > * @see
> > org.apache.commons.configuration.AbstractConfiguration#getProperty
> > Direct(jav
> > a.lang.String)
> > > */
> > > protected Object getPropertyDirect(String key) {
> > > if(log.isTraceEnabled())
> > log.trace("getPropertyDirect("+key+")");
> > > ConfigurationProperty config = null;
> > > try {
> > > config = (ConfigurationProperty)
> > session.get(ConfigurationProperty.class,key);
> > > } catch(HibernateException e) {
> > > log.error("Error reading congfiguration
> > property=["+key+"]",e);
> > > return null;
> > > }
> > > try {
> > > Class clazz =
> > getClass().getClassLoader().loadClass(config.getType());
> > > return ConvertUtils.convert(config.getValue(), clazz);
> > > } catch(ClassNotFoundException e) {
> > > log.warn("Cannot find class=["+config.getType()+"] for
> > property=["+key+"]",e);
> > > }
> > > return config.getValue();
> > > }
> > >
> > > /**
> > > * @see
> > org.apache.commons.configuration.AbstractConfiguration#addProperty
> > Direct(jav
> > a.lang.String, java.lang.Object)
> > > */
> > > protected void addPropertyDirect(String key, Object value) {
> > > if(log.isTraceEnabled())
> > log.trace("addPropertyDirect("+key+","+value+")");
> > > ConfigurationProperty config = new ConfigurationProperty();
> > > config.setName(key);
> > > config.setValue(ConvertUtils.convert(value));
> > > config.setType(value.getClass().getName());
> > > try {
> > > Transaction transaction = session.beginTransaction();
> > > session.save(config);
> > > transaction.commit();
> > > } catch(HibernateException e) {
> > > log.error("Error adding congfiguration
> > property=["+key+"]",e);
> > > }
> > > }
> > >
> > > /**
> > > * @see org.apache.commons.configuration.Configuration#isEmpty()
> > > */
> > > public boolean isEmpty() {
> > > if(log.isTraceEnabled()) log.trace("isEmpty()");
> > > try {
> > > List list = session.find("from Configuration");
> > > return list.isEmpty();
> > > } catch(HibernateException e) {
> > > log.error("Error reading keys.",e);
> > > return true;
> > > }
> > > }
> > >
> > > /***
> > > * @see
> > org.apache.commons.configuration.Configuration#containsKey(java.la
> > ng.String)
> > > */
> > > public boolean containsKey(String key) {
> > > if(log.isTraceEnabled()) log.trace("containsKey("+key+")");
> > > return (getPropertyDirect(key) != null);
> > > }
> > >
> > > /**
> > > * @see
> > org.apache.commons.configuration.Configuration#clearProperty(java.
> > lang.Strin
> > g)
> > > */
> > > public void clearProperty(String key) {
> > > if(log.isTraceEnabled()) log.trace("clearProperty("+key+")");
> > > ConfigurationProperty config = new ConfigurationProperty();
> > > config.setName(key);
> > > try {
> > > Transaction transaction = session.beginTransaction();
> > > session.delete(config);
> > > transaction.commit();
> > > } catch(HibernateException e) {
> > > log.error("Error clearing congfiguration
> > property=["+key+"]",e);
> > > }
> > > }
> > >
> > > /**
> > > * @see org.apache.commons.configuration.Configuration#getKeys()
> > > */
> > > public Iterator getKeys() {
> > > if(log.isTraceEnabled()) log.trace("getKeys()");
> > > try {
> > > List list = session.find("from Configuration");
> > > return new KeyIterator(list.iterator());
> > > } catch(HibernateException e) {
> > > log.error("Error reading keys.",e);
> > > return null;
> > > }
> > > }
> > >
> > > }
> > >
> >
> >
> > ------------------------------------------------------------------
> > ----------
> > ----
> >
> >
> > > /*
> > > * Copyright 2004 Ricardo Gladwell
> > > *
> > > * Licensed under the Apache License, Version 2.0 (the "License");
> > > * you may not use this file except in compliance with the License.
> > > * You may obtain a copy of the License at
> > > *
> > > * http://www.apache.org/licenses/LICENSE-2.0
> > > *
> > > * Unless required by applicable law or agreed to in writing, software
> > > * distributed under the License is distributed on an "AS IS" BASIS,
> > > * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> > implied.
> > > * See the License for the specific language governing permissions and
> > > * limitations under the License.
> > > */
> > >
> > > package net.sf.jexus.server.data.object;
> > >
> > > /**
> > > * Hibernate persistance JavaBean encapsulating information about
> > > * a configuration property.
> > > *
> > > * @hibernate.class
> > > * table="configuration"
> > > *
> > > * @todo Create JUnit test cases.
> > > * @author <a href="mailto:ricardo.gladwell@btinternet.com">Ricardo
> > Gladwell</a>
> > > * @version $Revision: 1.1 $, $Date: 2004/10/05 14:03:55 $
> > > */
> > > public class ConfigurationProperty {
> > >
> > > /**
> > > * Name of this configuration property.
> > > */
> > > String name;
> > >
> > > /**
> > > * String representation of the valye of this configuration
> > property.
> > > */
> > > String value;
> > >
> > > /**
> > > * Fully qualified class for this configuration property's type.
> > > */
> > > String type;
> > >
> > > /**
> > > * Returns the key name for this configuration property.
> > > *
> > > * @hibernate.id
> > > * generator-class="assigned"
> > > *
> > > * @return Returns the name.
> > > */
> > > public String getName() {
> > > return name;
> > > }
> > >
> > > /**
> > > * Sets the key name for this configuration property.
> > > * @param name The name to set.
> > > */
> > > public void setName(String name) {
> > > this.name = name;
> > > }
> > >
> > > /**
> > > * Returns the value of this property.
> > > *
> > > * @hibernate.property
> > > *
> > > * @return Returns the value.
> > > */
> > > public String getValue() {
> > > return value;
> > > }
> > >
> > > /**
> > > * Sets the value of this property.
> > > * @param value The value to set.
> > > */
> > > public void setValue(String value) {
> > > this.value = value;
> > > }
> > >
> > > /**
> > > * Returns the fully qualified class name for the type
> > > * of the value for this configuration property.
> > > *
> > > * @hibernate.property
> > > *
> > > * @return Returns the type.
> > > */
> > > public String getType() {
> > > return type;
> > > }
> > >
> > > /**
> > > * Sets the fully qualified class name for the type
> > > * of the value for this configuration property.
> > > * @param type The type to set.
> > > */
> > > public void setType(String type) {
> > > this.type = type;
> > > }
> > > }
> > >
> > >
> >
> >
> > ------------------------------------------------------------------
> > ----------
> > ----
> >
> >
> > > ---------------------------------------------------------------------
> > > 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
RE: [configuration] handling exceptions in AbstractConfiguration implementations
Posted by Eric Pugh <ep...@upstate.com>.
I tried hitting commons-resources.sf.net but no joy.. I think this
licensing thing is going to bite a lot of projects.. I was thinking of
settingup a sf project called "hibernatecodethatiwantedatapache.sf.net"
where I could toss all these bits and pieces.
Has Jakarta-Commons actually set up a parralel site on SF to work around
these issues?
ERic
> -----Original Message-----
> From: James Mitchell [mailto:jmitchell@apache.org]
> Sent: Wednesday, October 06, 2004 2:15 PM
> To: Jakarta Commons Developers List
> Subject: Re: [configuration] handling exceptions in
> AbstractConfiguration implementations
>
>
> Problem with having Hibernate implementations is that the license is
> incompatible with the ASL. So you'll need to keep any incompatible code
> somewhere else....like I do with commons-resources at sf.net.
>
>
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> EdgeTech, Inc.
> 678.910.8017
> AIM: jmitchtx
>
> ----- Original Message -----
> From: "Ricardo Gladwell" <ri...@btinternet.com>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Wednesday, October 06, 2004 8:07 AM
> Subject: Re: [configuration] handling exceptions in AbstractConfiguration
> implementations
>
>
> > Eric Pugh wrote:
> > > Hi Ricardo.. Sounds like you are working on something I've
> been wanting
> for
> > > a long time!
> >
> > Of course, I was going to release it anyway so please find the
> > source-code attached. Not sure it belongs in commons-configration API;
> > probably better contributed to the hibernate project. If you can think
> > of any improvements please mail the patches back to me for my
> own project
> :)
> >
> > > In otherwords, say I am using a Configuration object in my code, and I
> do
> > > configuration.getDouble("key");. If getDouble throws an
> exception then
> I am
> > > going to have these try/catch cluases all over the place,
> cluttering the
> > > code. and, I really except getDouble() to allows work. If
> it doesn't,
> my
> > > application will just pass it on,not have some sort of fancy if
> getDouble
> > > fails, then try getString or something weird.
> >
> > Good point, although I'm still dubious about throwing RuntimeExceptions
> > - those things shoot straight through everything like a silver bullet
> > and can even crash some servlet engines.
> >
> > From my perspective, I'm not bothered if the Configuration object
> > throws exceptions: I wouldn't catch such exceptions in my web
> > application, instead letting them fly all the way to the exception
> > screen. This way, I can see them occuring as I test my application
> > through the browser.
> >
> > Obviously, sometimes when configuring your application you just want
> > your configuration to work or keep on working untill if it encounters an
> > errors. However, simply allowing your application to ignore exceptions
> > until they create new exception elsewhere seems like a good way to
> > create hard-to-fix bugs. Surely, it would be better to relay the errors
> > and let the application decide what to do with them?
> >
> > > I think what you can do is just wrap your HibernateException in a
> > > ConfiguratoinRuntimeException and toss that. JDBCConfiguration should
> > > probably be doning the same thing.
> >
> > Another alternative would be to have a getExceptions() method for all
> > Configurations which stores exceptions occuring and stores them for
> > later reporting. A good comprimise would be to allow all Configuration
> > objects to have two modes: one where exceptions are thrown as soon as
> > they occur and another one which stores exceptions as I suggested.
> >
> > Kind regards,
> > -- Ricardo Gladwell
> >
> > >>-----Original Message-----
> > >>From: Ricardo Gladwell [mailto:ricardo.gladwell@btinternet.com]
> > >>Sent: Wednesday, October 06, 2004 12:56 PM
> > >>To: Jakarta Commons Developers List
> > >>Subject: [configuration] handling exceptions in AbstractConfiguration
> > >>implementations
> > >>
> > >>
> > >>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
> >
>
>
> ------------------------------------------------------------------
> ----------
> ----
>
>
> > package net.sf.jexus.server.components;
> >
> > import org.apache.commons.logging.Log;
> > import org.apache.commons.logging.LogFactory;
> >
> > import java.util.Iterator;
> > import java.util.List;
> >
> > import net.sf.hibernate.HibernateException;
> > import net.sf.hibernate.Session;
> > import net.sf.hibernate.Transaction;
> > import net.sf.jexus.server.data.object.ConfigurationProperty;
> >
> > import org.apache.commons.beanutils.ConvertUtils;
> > import org.apache.commons.configuration.AbstractConfiguration;
> >
> > /**
> > * <p>Hibernate configuation class. Reads configuration
> infomation from a
> > * database through the <a
> href="http://www.hibernate.org/">Hibernate</a>
> > * O/R mapping API. Data is stored as name-value pairs, along with the
> class
> > * information of data stored, using the mapping* defined by the
> > * {@link ConfigurationProperty} POJO hibernate xdoclet
> directives. Values
> are
> > * converted to and from strings using
> > * {@link org.apache.commons.beanutils.ConvertUtils}.</p>
> > *
> > * @author <a href="mailto:ricardo.gladwell@btinternet.com">Ricardo
> Gladwell</a>
> > */
> > public class HibernateConfiguration extends AbstractConfiguration {
> >
> > /**
> > * Logger for this class
> > */
> > private static final Log log =
> LogFactory.getLog(HibernateConfiguration.class);
> >
> > /**
> > * Reference to the session factory.
> > */
> > Session session;
> >
> > /**
> > *
> > */
> > class KeyIterator implements Iterator {
> >
> > Iterator iterator;
> > String last;
> >
> > public KeyIterator(Iterator iterator) throws
> HibernateException {
> > this.iterator = iterator;
> > }
> >
> > /**
> > * @see java.util.Iterator#hasNext()
> > */
> > public boolean hasNext() {
> > return iterator.hasNext();
> > }
> >
> > /**
> > * @see java.util.Iterator#next()
> > */
> > public Object next() {
> > ConfigurationProperty config =
> (ConfigurationProperty)iterator.next();
> > String key = config.getName();
> > last = key;
> > return key;
> > }
> >
> > /**
> > * @see java.util.Iterator#remove()
> > */
> > public void remove() {
> > clearProperty(last);
> > }
> >
> > }
> >
> > /**
> > *
> > */
> > public HibernateConfiguration(Session session) {
> > super();
> > if(log.isTraceEnabled()) log.trace("HibernateConfiguration()");
> > this.session = session;
> > }
> >
> > /**
> > * @see
> org.apache.commons.configuration.AbstractConfiguration#getProperty
> Direct(jav
> a.lang.String)
> > */
> > protected Object getPropertyDirect(String key) {
> > if(log.isTraceEnabled())
> log.trace("getPropertyDirect("+key+")");
> > ConfigurationProperty config = null;
> > try {
> > config = (ConfigurationProperty)
> session.get(ConfigurationProperty.class,key);
> > } catch(HibernateException e) {
> > log.error("Error reading congfiguration
> property=["+key+"]",e);
> > return null;
> > }
> > try {
> > Class clazz =
> getClass().getClassLoader().loadClass(config.getType());
> > return ConvertUtils.convert(config.getValue(), clazz);
> > } catch(ClassNotFoundException e) {
> > log.warn("Cannot find class=["+config.getType()+"] for
> property=["+key+"]",e);
> > }
> > return config.getValue();
> > }
> >
> > /**
> > * @see
> org.apache.commons.configuration.AbstractConfiguration#addProperty
> Direct(jav
> a.lang.String, java.lang.Object)
> > */
> > protected void addPropertyDirect(String key, Object value) {
> > if(log.isTraceEnabled())
> log.trace("addPropertyDirect("+key+","+value+")");
> > ConfigurationProperty config = new ConfigurationProperty();
> > config.setName(key);
> > config.setValue(ConvertUtils.convert(value));
> > config.setType(value.getClass().getName());
> > try {
> > Transaction transaction = session.beginTransaction();
> > session.save(config);
> > transaction.commit();
> > } catch(HibernateException e) {
> > log.error("Error adding congfiguration
> property=["+key+"]",e);
> > }
> > }
> >
> > /**
> > * @see org.apache.commons.configuration.Configuration#isEmpty()
> > */
> > public boolean isEmpty() {
> > if(log.isTraceEnabled()) log.trace("isEmpty()");
> > try {
> > List list = session.find("from Configuration");
> > return list.isEmpty();
> > } catch(HibernateException e) {
> > log.error("Error reading keys.",e);
> > return true;
> > }
> > }
> >
> > /***
> > * @see
> org.apache.commons.configuration.Configuration#containsKey(java.la
> ng.String)
> > */
> > public boolean containsKey(String key) {
> > if(log.isTraceEnabled()) log.trace("containsKey("+key+")");
> > return (getPropertyDirect(key) != null);
> > }
> >
> > /**
> > * @see
> org.apache.commons.configuration.Configuration#clearProperty(java.
> lang.Strin
> g)
> > */
> > public void clearProperty(String key) {
> > if(log.isTraceEnabled()) log.trace("clearProperty("+key+")");
> > ConfigurationProperty config = new ConfigurationProperty();
> > config.setName(key);
> > try {
> > Transaction transaction = session.beginTransaction();
> > session.delete(config);
> > transaction.commit();
> > } catch(HibernateException e) {
> > log.error("Error clearing congfiguration
> property=["+key+"]",e);
> > }
> > }
> >
> > /**
> > * @see org.apache.commons.configuration.Configuration#getKeys()
> > */
> > public Iterator getKeys() {
> > if(log.isTraceEnabled()) log.trace("getKeys()");
> > try {
> > List list = session.find("from Configuration");
> > return new KeyIterator(list.iterator());
> > } catch(HibernateException e) {
> > log.error("Error reading keys.",e);
> > return null;
> > }
> > }
> >
> > }
> >
>
>
> ------------------------------------------------------------------
> ----------
> ----
>
>
> > /*
> > * Copyright 2004 Ricardo Gladwell
> > *
> > * Licensed under the Apache License, Version 2.0 (the "License");
> > * you may not use this file except in compliance with the License.
> > * You may obtain a copy of the License at
> > *
> > * http://www.apache.org/licenses/LICENSE-2.0
> > *
> > * Unless required by applicable law or agreed to in writing, software
> > * distributed under the License is distributed on an "AS IS" BASIS,
> > * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> implied.
> > * See the License for the specific language governing permissions and
> > * limitations under the License.
> > */
> >
> > package net.sf.jexus.server.data.object;
> >
> > /**
> > * Hibernate persistance JavaBean encapsulating information about
> > * a configuration property.
> > *
> > * @hibernate.class
> > * table="configuration"
> > *
> > * @todo Create JUnit test cases.
> > * @author <a href="mailto:ricardo.gladwell@btinternet.com">Ricardo
> Gladwell</a>
> > * @version $Revision: 1.1 $, $Date: 2004/10/05 14:03:55 $
> > */
> > public class ConfigurationProperty {
> >
> > /**
> > * Name of this configuration property.
> > */
> > String name;
> >
> > /**
> > * String representation of the valye of this configuration
> property.
> > */
> > String value;
> >
> > /**
> > * Fully qualified class for this configuration property's type.
> > */
> > String type;
> >
> > /**
> > * Returns the key name for this configuration property.
> > *
> > * @hibernate.id
> > * generator-class="assigned"
> > *
> > * @return Returns the name.
> > */
> > public String getName() {
> > return name;
> > }
> >
> > /**
> > * Sets the key name for this configuration property.
> > * @param name The name to set.
> > */
> > public void setName(String name) {
> > this.name = name;
> > }
> >
> > /**
> > * Returns the value of this property.
> > *
> > * @hibernate.property
> > *
> > * @return Returns the value.
> > */
> > public String getValue() {
> > return value;
> > }
> >
> > /**
> > * Sets the value of this property.
> > * @param value The value to set.
> > */
> > public void setValue(String value) {
> > this.value = value;
> > }
> >
> > /**
> > * Returns the fully qualified class name for the type
> > * of the value for this configuration property.
> > *
> > * @hibernate.property
> > *
> > * @return Returns the type.
> > */
> > public String getType() {
> > return type;
> > }
> >
> > /**
> > * Sets the fully qualified class name for the type
> > * of the value for this configuration property.
> > * @param type The type to set.
> > */
> > public void setType(String type) {
> > this.type = type;
> > }
> > }
> >
> >
>
>
> ------------------------------------------------------------------
> ----------
> ----
>
>
> > ---------------------------------------------------------------------
> > 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
Re: [configuration] handling exceptions in AbstractConfiguration implementations
Posted by James Mitchell <jm...@apache.org>.
Problem with having Hibernate implementations is that the license is
incompatible with the ASL. So you'll need to keep any incompatible code
somewhere else....like I do with commons-resources at sf.net.
--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx
----- Original Message -----
From: "Ricardo Gladwell" <ri...@btinternet.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Wednesday, October 06, 2004 8:07 AM
Subject: Re: [configuration] handling exceptions in AbstractConfiguration
implementations
> Eric Pugh wrote:
> > Hi Ricardo.. Sounds like you are working on something I've been wanting
for
> > a long time!
>
> Of course, I was going to release it anyway so please find the
> source-code attached. Not sure it belongs in commons-configration API;
> probably better contributed to the hibernate project. If you can think
> of any improvements please mail the patches back to me for my own project
:)
>
> > In otherwords, say I am using a Configuration object in my code, and I
do
> > configuration.getDouble("key");. If getDouble throws an exception then
I am
> > going to have these try/catch cluases all over the place, cluttering the
> > code. and, I really except getDouble() to allows work. If it doesn't,
my
> > application will just pass it on,not have some sort of fancy if
getDouble
> > fails, then try getString or something weird.
>
> Good point, although I'm still dubious about throwing RuntimeExceptions
> - those things shoot straight through everything like a silver bullet
> and can even crash some servlet engines.
>
> From my perspective, I'm not bothered if the Configuration object
> throws exceptions: I wouldn't catch such exceptions in my web
> application, instead letting them fly all the way to the exception
> screen. This way, I can see them occuring as I test my application
> through the browser.
>
> Obviously, sometimes when configuring your application you just want
> your configuration to work or keep on working untill if it encounters an
> errors. However, simply allowing your application to ignore exceptions
> until they create new exception elsewhere seems like a good way to
> create hard-to-fix bugs. Surely, it would be better to relay the errors
> and let the application decide what to do with them?
>
> > I think what you can do is just wrap your HibernateException in a
> > ConfiguratoinRuntimeException and toss that. JDBCConfiguration should
> > probably be doning the same thing.
>
> Another alternative would be to have a getExceptions() method for all
> Configurations which stores exceptions occuring and stores them for
> later reporting. A good comprimise would be to allow all Configuration
> objects to have two modes: one where exceptions are thrown as soon as
> they occur and another one which stores exceptions as I suggested.
>
> Kind regards,
> -- Ricardo Gladwell
>
> >>-----Original Message-----
> >>From: Ricardo Gladwell [mailto:ricardo.gladwell@btinternet.com]
> >>Sent: Wednesday, October 06, 2004 12:56 PM
> >>To: Jakarta Commons Developers List
> >>Subject: [configuration] handling exceptions in AbstractConfiguration
> >>implementations
> >>
> >>
> >>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
>
----------------------------------------------------------------------------
----
> package net.sf.jexus.server.components;
>
> import org.apache.commons.logging.Log;
> import org.apache.commons.logging.LogFactory;
>
> import java.util.Iterator;
> import java.util.List;
>
> import net.sf.hibernate.HibernateException;
> import net.sf.hibernate.Session;
> import net.sf.hibernate.Transaction;
> import net.sf.jexus.server.data.object.ConfigurationProperty;
>
> import org.apache.commons.beanutils.ConvertUtils;
> import org.apache.commons.configuration.AbstractConfiguration;
>
> /**
> * <p>Hibernate configuation class. Reads configuration infomation from a
> * database through the <a href="http://www.hibernate.org/">Hibernate</a>
> * O/R mapping API. Data is stored as name-value pairs, along with the
class
> * information of data stored, using the mapping* defined by the
> * {@link ConfigurationProperty} POJO hibernate xdoclet directives. Values
are
> * converted to and from strings using
> * {@link org.apache.commons.beanutils.ConvertUtils}.</p>
> *
> * @author <a href="mailto:ricardo.gladwell@btinternet.com">Ricardo
Gladwell</a>
> */
> public class HibernateConfiguration extends AbstractConfiguration {
>
> /**
> * Logger for this class
> */
> private static final Log log =
LogFactory.getLog(HibernateConfiguration.class);
>
> /**
> * Reference to the session factory.
> */
> Session session;
>
> /**
> *
> */
> class KeyIterator implements Iterator {
>
> Iterator iterator;
> String last;
>
> public KeyIterator(Iterator iterator) throws HibernateException {
> this.iterator = iterator;
> }
>
> /**
> * @see java.util.Iterator#hasNext()
> */
> public boolean hasNext() {
> return iterator.hasNext();
> }
>
> /**
> * @see java.util.Iterator#next()
> */
> public Object next() {
> ConfigurationProperty config =
(ConfigurationProperty)iterator.next();
> String key = config.getName();
> last = key;
> return key;
> }
>
> /**
> * @see java.util.Iterator#remove()
> */
> public void remove() {
> clearProperty(last);
> }
>
> }
>
> /**
> *
> */
> public HibernateConfiguration(Session session) {
> super();
> if(log.isTraceEnabled()) log.trace("HibernateConfiguration()");
> this.session = session;
> }
>
> /**
> * @see
org.apache.commons.configuration.AbstractConfiguration#getPropertyDirect(jav
a.lang.String)
> */
> protected Object getPropertyDirect(String key) {
> if(log.isTraceEnabled()) log.trace("getPropertyDirect("+key+")");
> ConfigurationProperty config = null;
> try {
> config = (ConfigurationProperty)
session.get(ConfigurationProperty.class,key);
> } catch(HibernateException e) {
> log.error("Error reading congfiguration
property=["+key+"]",e);
> return null;
> }
> try {
> Class clazz =
getClass().getClassLoader().loadClass(config.getType());
> return ConvertUtils.convert(config.getValue(), clazz);
> } catch(ClassNotFoundException e) {
> log.warn("Cannot find class=["+config.getType()+"] for
property=["+key+"]",e);
> }
> return config.getValue();
> }
>
> /**
> * @see
org.apache.commons.configuration.AbstractConfiguration#addPropertyDirect(jav
a.lang.String, java.lang.Object)
> */
> protected void addPropertyDirect(String key, Object value) {
> if(log.isTraceEnabled())
log.trace("addPropertyDirect("+key+","+value+")");
> ConfigurationProperty config = new ConfigurationProperty();
> config.setName(key);
> config.setValue(ConvertUtils.convert(value));
> config.setType(value.getClass().getName());
> try {
> Transaction transaction = session.beginTransaction();
> session.save(config);
> transaction.commit();
> } catch(HibernateException e) {
> log.error("Error adding congfiguration property=["+key+"]",e);
> }
> }
>
> /**
> * @see org.apache.commons.configuration.Configuration#isEmpty()
> */
> public boolean isEmpty() {
> if(log.isTraceEnabled()) log.trace("isEmpty()");
> try {
> List list = session.find("from Configuration");
> return list.isEmpty();
> } catch(HibernateException e) {
> log.error("Error reading keys.",e);
> return true;
> }
> }
>
> /***
> * @see
org.apache.commons.configuration.Configuration#containsKey(java.lang.String)
> */
> public boolean containsKey(String key) {
> if(log.isTraceEnabled()) log.trace("containsKey("+key+")");
> return (getPropertyDirect(key) != null);
> }
>
> /**
> * @see
org.apache.commons.configuration.Configuration#clearProperty(java.lang.Strin
g)
> */
> public void clearProperty(String key) {
> if(log.isTraceEnabled()) log.trace("clearProperty("+key+")");
> ConfigurationProperty config = new ConfigurationProperty();
> config.setName(key);
> try {
> Transaction transaction = session.beginTransaction();
> session.delete(config);
> transaction.commit();
> } catch(HibernateException e) {
> log.error("Error clearing congfiguration
property=["+key+"]",e);
> }
> }
>
> /**
> * @see org.apache.commons.configuration.Configuration#getKeys()
> */
> public Iterator getKeys() {
> if(log.isTraceEnabled()) log.trace("getKeys()");
> try {
> List list = session.find("from Configuration");
> return new KeyIterator(list.iterator());
> } catch(HibernateException e) {
> log.error("Error reading keys.",e);
> return null;
> }
> }
>
> }
>
----------------------------------------------------------------------------
----
> /*
> * Copyright 2004 Ricardo Gladwell
> *
> * Licensed under the Apache License, Version 2.0 (the "License");
> * you may not use this file except in compliance with the License.
> * You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
>
> package net.sf.jexus.server.data.object;
>
> /**
> * Hibernate persistance JavaBean encapsulating information about
> * a configuration property.
> *
> * @hibernate.class
> * table="configuration"
> *
> * @todo Create JUnit test cases.
> * @author <a href="mailto:ricardo.gladwell@btinternet.com">Ricardo
Gladwell</a>
> * @version $Revision: 1.1 $, $Date: 2004/10/05 14:03:55 $
> */
> public class ConfigurationProperty {
>
> /**
> * Name of this configuration property.
> */
> String name;
>
> /**
> * String representation of the valye of this configuration property.
> */
> String value;
>
> /**
> * Fully qualified class for this configuration property's type.
> */
> String type;
>
> /**
> * Returns the key name for this configuration property.
> *
> * @hibernate.id
> * generator-class="assigned"
> *
> * @return Returns the name.
> */
> public String getName() {
> return name;
> }
>
> /**
> * Sets the key name for this configuration property.
> * @param name The name to set.
> */
> public void setName(String name) {
> this.name = name;
> }
>
> /**
> * Returns the value of this property.
> *
> * @hibernate.property
> *
> * @return Returns the value.
> */
> public String getValue() {
> return value;
> }
>
> /**
> * Sets the value of this property.
> * @param value The value to set.
> */
> public void setValue(String value) {
> this.value = value;
> }
>
> /**
> * Returns the fully qualified class name for the type
> * of the value for this configuration property.
> *
> * @hibernate.property
> *
> * @return Returns the type.
> */
> public String getType() {
> return type;
> }
>
> /**
> * Sets the fully qualified class name for the type
> * of the value for this configuration property.
> * @param type The type to set.
> */
> public void setType(String type) {
> this.type = type;
> }
> }
>
>
----------------------------------------------------------------------------
----
> ---------------------------------------------------------------------
> 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
Re: [configuration] handling exceptions in AbstractConfiguration
implementations
Posted by Ricardo Gladwell <ri...@btinternet.com>.
Eric Pugh wrote:
> Hi Ricardo.. Sounds like you are working on something I've been wanting for
> a long time!
Of course, I was going to release it anyway so please find the
source-code attached. Not sure it belongs in commons-configration API;
probably better contributed to the hibernate project. If you can think
of any improvements please mail the patches back to me for my own project :)
> In otherwords, say I am using a Configuration object in my code, and I do
> configuration.getDouble("key");. If getDouble throws an exception then I am
> going to have these try/catch cluases all over the place, cluttering the
> code. and, I really except getDouble() to allows work. If it doesn't, my
> application will just pass it on,not have some sort of fancy if getDouble
> fails, then try getString or something weird.
Good point, although I'm still dubious about throwing RuntimeExceptions
- those things shoot straight through everything like a silver bullet
and can even crash some servlet engines.
From my perspective, I'm not bothered if the Configuration object
throws exceptions: I wouldn't catch such exceptions in my web
application, instead letting them fly all the way to the exception
screen. This way, I can see them occuring as I test my application
through the browser.
Obviously, sometimes when configuring your application you just want
your configuration to work or keep on working untill if it encounters an
errors. However, simply allowing your application to ignore exceptions
until they create new exception elsewhere seems like a good way to
create hard-to-fix bugs. Surely, it would be better to relay the errors
and let the application decide what to do with them?
> I think what you can do is just wrap your HibernateException in a
> ConfiguratoinRuntimeException and toss that. JDBCConfiguration should
> probably be doning the same thing.
Another alternative would be to have a getExceptions() method for all
Configurations which stores exceptions occuring and stores them for
later reporting. A good comprimise would be to allow all Configuration
objects to have two modes: one where exceptions are thrown as soon as
they occur and another one which stores exceptions as I suggested.
Kind regards,
-- Ricardo Gladwell
>>-----Original Message-----
>>From: Ricardo Gladwell [mailto:ricardo.gladwell@btinternet.com]
>>Sent: Wednesday, October 06, 2004 12:56 PM
>>To: Jakarta Commons Developers List
>>Subject: [configuration] handling exceptions in AbstractConfiguration
>>implementations
>>
>>
>>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
RE: [configuration] handling exceptions in AbstractConfiguration implementations
Posted by Eric Pugh <ep...@upstate.com>.
Hi Ricardo.. Sounds like you are working on something I've been wanting for
a long time! At any rate.. I believe there is a
ConfigurationRuntimeException that you could throw, even though it's not
part of the API.
I think the reason that most of the gets don't throw an exception is because
99% of the time if you throw an exception then the calling class will just
have to rethrow it.
In otherwords, say I am using a Configuration object in my code, and I do
configuration.getDouble("key");. If getDouble throws an exception then I am
going to have these try/catch cluases all over the place, cluttering the
code. and, I really except getDouble() to allows work. If it doesn't, my
application will just pass it on,not have some sort of fancy if getDouble
fails, then try getString or something weird.
I think what you can do is just wrap your HibernateException in a
ConfiguratoinRuntimeException and toss that. JDBCConfiguration should
probably be doning the same thing.
Eric
> -----Original Message-----
> From: Ricardo Gladwell [mailto:ricardo.gladwell@btinternet.com]
> Sent: Wednesday, October 06, 2004 12:56 PM
> To: Jakarta Commons Developers List
> Subject: [configuration] handling exceptions in AbstractConfiguration
> implementations
>
>
> 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