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 19:32:38 GMT

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: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.


Mime
View raw message