Re: Request to add new runtime exception in openjpa-lib subproject for error control in bootstrap process

Wed, 18 Jul 2007 12:33:11 -0700 


On Jul 18, 2007, at 12:22 PM, Pinaki Poddar wrote:


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?
It is neither advisable not possible: you can't have circular dependencies in modules, and openjpa-kernel already relies on openjpa- lib. 



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:[EMAIL PROTECTED] On Behalf Of 
Marc Prud'hommeaux
Sent: Wednesday, July 18, 2007 1:39 PM
To: [email protected]
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:[EMAIL PROTECTED]
Sent: Tuesday, July 17, 2007 5:26 PM
To: [email protected]
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:[EMAIL PROTECTED] On Behalf
Of Marc Prud'hommeaux
Sent: Tuesday, July 17, 2007 4:26 PM
To: [email protected]
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.

Reply via email to