openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Prud'hommeaux <mprud...@apache.org>
Subject Re: Request to add new runtime exception in openjpa-lib subproject for error control in bootstrap process
Date Wed, 18 Jul 2007 18:39:06 GMT

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.


Mime
View raw message