From dev-return-4948-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org Wed Jul 18 19:23:55 2007 Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 43022 invoked from network); 18 Jul 2007 19:23:55 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 18 Jul 2007 19:23:55 -0000 Received: (qmail 6448 invoked by uid 500); 18 Jul 2007 19:23:41 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 6420 invoked by uid 500); 18 Jul 2007 19:23:41 -0000 Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openjpa.apache.org Delivered-To: mailing list dev@openjpa.apache.org Received: (qmail 6404 invoked by uid 99); 18 Jul 2007 19:23:41 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 18 Jul 2007 12:23:41 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of ppoddar@bea.com designates 66.248.192.39 as permitted sender) Received: from [66.248.192.39] (HELO repmmg02.bea.com) (66.248.192.39) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 18 Jul 2007 12:23:38 -0700 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6IJNG1N007117 for ; Wed, 18 Jul 2007 12:23:16 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6IJNFjk032118 for ; Wed, 18 Jul 2007 12:23:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: RE: Request to add new runtime exception in openjpa-lib subproject for error control in bootstrap process Date: Wed, 18 Jul 2007 12:22:10 -0700 Message-ID: <3992B07C0590B548BB294D31768A1DA240D948@repbex01.amer.bea.com> In-Reply-To: <1DC32375-6A0E-4905-91ED-7AAC0302B8FE@apache.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request to add new runtime exception in openjpa-lib subproject for error control in bootstrap process Thread-Index: AcfJawOtDWfB4ka/RBmRMPFKS2mDWwAAOAdQ References: <3992B07C0590B548BB294D31768A1DA240D52C@repbex01.amer.bea.com> <39AA3B31-E7D2-49F1-99D6-9A4F7A2CA206@apache.org> <3992B07C0590B548BB294D31768A1DA240D635@repbex01.amer.bea.com> <3992B07C0590B548BB294D31768A1DA240D886@repbex01.amer.bea.com> <1DC32375-6A0E-4905-91ED-7AAC0302B8FE@apache.org> From: "Pinaki Poddar" To: x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Virus-Checked: Checked by ClamAV on apache.org Hello, It would be better to handle OpenJPAException in ProductDerivations' bootstrap handling methods. But because of subproject dependency, ProductDerivations (in openjpa-lib) can not use OpenJPAException (in openjpa-kernel). So one option is to add compile-time dependency of openjpa-lib on openjpa-kernel (then no need to create a new BootstrapException). Is that advisable? ProductDerivations.beforeConfigurationConstruct() and beforeConfigurationLoad() are the two methods I am currently targetting to add this 'stop this bootstrap because something is fatally wrong' - behaviour. Currently these methods swallow all Exception. ProductDerivations.load() methods succeed as soon as any derivation finds its appropriate configuration. These methods throw exception *only* when no suitable derivation can load config. If any derivation prior to the successful one raises Throwable, those are swallowed too. Pinaki Poddar 972.834.2865 -----Original Message----- From: Marc Prud'hommeaux [mailto:mprudhomapache@gmail.com] On Behalf Of Marc Prud'hommeaux Sent: Wednesday, July 18, 2007 1:39 PM To: dev@openjpa.apache.org Subject: Re: Request to add new runtime exception in openjpa-lib subproject for error control in bootstrap process That seems like it might work (although I think I would prefer "BootstrapException" to "ConfigurationException"). However, there may be many places where already throw a UserException (or some other subclass of OpenJPAException) when there is a misconfiguration, and it might be difficult to track all of those down. On Jul 18, 2007, at 10:41 AM, Pinaki Poddar wrote: > Hello, > Given the dependency of exception classes in openjpa-kernel subproject > to PersistenceCapable/ImplHelper, migrating them to openjpa-lib will > require non-trivial changes. > Instead, proposed to add a ConfigurationException (extends > RuntimeException) in openjpa-lib subproject. Bootstrap process will > recognize this exception and abanadon bootstrapping for fatal > ConfigurationException thrown by any derivation. > > Comments? > > > Pinaki Poddar > 972.834.2865 > > -----Original Message----- > From: Pinaki Poddar [mailto:ppoddar@bea.com] > Sent: Tuesday, July 17, 2007 5:26 PM > To: dev@openjpa.apache.org > Subject: RE: Request to migrate generic exception classes from > openjpa-kernel to openjpa-lib subproject > > Marc, > Dependency in openjpa-kernel goes > UserException->OpenJPAException->Exceptions->PersistenceCapable. > > More surgery needed to migrate exceptions to openjpa-lib > > > Pinaki Poddar > 972.834.2865 > > -----Original Message----- > From: Marc Prud'hommeaux [mailto:mprudhomapache@gmail.com] On Behalf > Of Marc Prud'hommeaux > Sent: Tuesday, July 17, 2007 4:26 PM > To: dev@openjpa.apache.org > Subject: Re: Request to migrate generic exception classes from > openjpa-kernel to openjpa-lib subproject > > > I can't think of any reason why we couldn't do this. Provided we don't > change the package name or anything like that, swapping the module > that > contains this exception stuff wouldn't result in any user- visible > changes. > > > On Jul 17, 2007, at 1:04 PM, Pinaki Poddar wrote: > >> >> openjpa-kernel subproject contains >> org.apache.openjpa.util.OpenJPAException/UserException/ExceptionInfo. >> Can these classes be moved to openjpa-lib project? >> >> The context of this request is as follows: >> Currently, bootstrap process via ProductDerivations swallow all >> exceptions thrown by individual derivations. I want this exception >> mechanism to honour fatal OpenJPAException by abandoning the >> bootstrap > >> process. While this allows a rogue product derivation to hamper >> initialization, it also provides a means for a derivation to stop >> bootstrapping for invalid configuration. >> >> Is there a major impact/side-effect in migrating the above classes >> from openjpa-kernel to openjpa-lib subproject? >> >> >> Pinaki Poddar >> 972.834.2865 >> >> >> Notice: This email message, together with any attachments, may >> contain information of BEA Systems, Inc., its subsidiaries >> and affiliated entities, that may be confidential, proprietary, >> copyrighted and/or legally privileged, and is intended solely for >> the > >> use of the individual or entity named in this message. If you are not >> the intended recipient, and have received this message in error, >> please immediately return this by email and then delete it. > > > Notice: This email message, together with any attachments, may > contain > information of BEA Systems, Inc., its subsidiaries and > affiliated > entities, that may be confidential, proprietary, copyrighted > and/or > legally privileged, and is intended solely for the use of the > individual > or entity named in this message. If you are not the intended > recipient, > and have received this message in error, please immediately return > this > by email and then delete it. > > Notice: This email message, together with any attachments, may > contain information of BEA Systems, Inc., its subsidiaries > and affiliated entities, that may be confidential, proprietary, > copyrighted and/or legally privileged, and is intended solely for > the use of the individual or entity named in this message. If you > are not the intended recipient, and have received this message in > error, please immediately return this by email and then delete it. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.