openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <dwo...@apache.org>
Subject Re: JPA2 - When should createEMF() return an Exception vs. NULL?
Date Fri, 24 Jul 2009 02:35:35 GMT


Pinaki Poddar wrote:
> The bootstrap should ask all (say N) available providers to createEMF().
> If any of them throws exception or return null, the bootstrap should
> continue asking rest of the providers.
> After all N provides have been queried by the bootstrap, let us say M
> providers have returned a valid EMF.
> 
> 
> 1. Log exceptions or null, as the case may be, for each of the (N-M) failed
> providers to give a deployer a chance to know what went wrong.

We currently do not require a log provider for the Geronimo Specs, as 
you have no idea what logging will be in place (Log4j, SLF4J, JDK, OSGi, 
.....)  Since the spec says to return null and doesn't define an 
exception to throw, it should be up to the providers to log why they 
couldn't create an EMF.

> 
> 2. if (M == 1)
>    return the only good one. 
> else if (M > 1)
>    tricky. Non-partisan approach will be to throw exception explaining that
> providers are behaving badly.

Disagree, as the way I read the spec is the first provider that creates 
an EMF should be the one that gets returned.  Also, I don't see it as 
the javax.persistence.Persistence impls job to cache and free these EMFs 
(nothing in the spec suggests this behavior.)  I would rather we ask the 
expert group for clarification, than create a nightmare for us to test.

>    Partisan behavior will be to return OpenJPA provider, if exists. If not
> the first one (unfair, because *first* is ambiguous/non-deterministic).
> else // M = 0
>    return null or throw exception
> 
> The key points are
> a) robust: not to let one *failed* provider spoil the chance of other good
> ones

agree

> b) fair: not to prefer one provider over another (slight bias towards
> OpenJPA is OK:). This will address the  case of more than one provider
> returning non-null EMF. Also do not return immediately at the first non-null
> EMF. Because the ordering on provider is inherently non-deterministic due to
> the nature of the discovery process.

don't see this as a problem, as 1) the spec defines support for 
providing a javax.persistence.provider property on the createEMF call, 
which should effective make that the only provider that should try to 
create a EMF, 2) we could look at the discovered list of persistence 
providers and try loading ours first.

> c) helpful: provide as much contextual info as possible for diagnosis (the
> deployer/developer will be pleased)

again, see this as the job of each provider, to log why they could not 
return a valid EMF (since they have to handle logging in JSE, JEE and 
OSGi today)

>    
> 
> So if OpenJPA is throwing exception on unsupported openjpa.Specification
> property value, let it continue to do so. Others may return null under
> certain circumstances, or throw exception in another.
> 
> Absorb the provider implementation variations in the bootstrap. 
> 
> 
> -----
> Pinaki 

Mime
View raw message