Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Date: Thu, 28 Jul 2011 09:25:10 +0000 (UTC)
From: =?utf-8?Q?Piotr_Gli=C5=BAniewicz_=28JIRA=29?= <jira@apache.org>
To: dev@openjpa.apache.org
Message-ID: 
 <1681113379.15198.1311845110403.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1902795217.897.1309243337308.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (OPENJPA-2023) Meaningless messages when JNDI
 lookup fails.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/OPENJPA-2023?page=3Dcom.atlass=
ian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Piotr Gli=C5=BAniewicz updated OPENJPA-2023:
---------------------------------------

    Description:=20
If OpenJPA is configured to get the DataSource from JNDI and the lookup fai=
ls it return meaningless messages.

lookupConnectionFactory(String name, String userKey) in org.apache.openjpa.=
conf.OpenJPAConfigurationImpl swallows exceptions if a NamingException is t=
hrown during a JNDI lookup.

The effect is, that in createConnectionFactory in org.apache.openjpa.jdbc.c=
onf.JDBCConfigurationImpl, if a ConnectionFactoryName is provided which cau=
ses a NamingException, null is returned from getConnectionFactory() and it =
tries to get the DataSource using JDBC configuration data, what fails, sinc=
e there aren't any provided. It ends up with a ArgumentException with messa=
ge: "A JDBC Driver or DataSource class name must be specified in the Connec=
tionDriverName property." which is totally misleading.

Expected: the provider returns information about the failure to retrieve th=
e DataSource from JNDI. It shoul'd silently fall back to using JDBC propert=
ies.

  was:
If OpenJPA is configured to get the DataSource from JNDI and the lookup fai=
ls it return meaningless messages.

lookupConnectionFactory(String name, String userKey) in org.apache.openjpa.=
conf.OpenJPAConfigurationImpl swallows exceptions if a NamingException is t=
hrown during a JNDI lookup.

The effect is, that in createConnectionFactory in org.apache.openjpa.jdbc.c=
onf.JDBCConfigurationImpl, if a ConnectionFactoryName is provided which cau=
ses a NamingException, null is returned from getConnectionFactory() and it =
tries to get the DataSource using JDBC configuration data, what fails, sinc=
e there aren't any provided. It ends up with a ArgumentException with messa=
ge: "A JDBC Driver or DataSource class name must be specified in the Connec=
tionDriverName property." which is totally misleading.

Expected: the provider returns information about the failure to retrieve th=
e DataSource from JNDI. It should silently fall back to using JDBC properti=
es.


> Meaningless messages when JNDI lookup fails.
> --------------------------------------------
>
>                 Key: OPENJPA-2023
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-2023
>             Project: OpenJPA
>          Issue Type: Improvement
>          Components: kernel
>    Affects Versions: 2.0.1
>            Reporter: Piotr Gli=C5=BAniewicz
>
> If OpenJPA is configured to get the DataSource from JNDI and the lookup f=
ails it return meaningless messages.
> lookupConnectionFactory(String name, String userKey) in org.apache.openjp=
a.conf.OpenJPAConfigurationImpl swallows exceptions if a NamingException is=
 thrown during a JNDI lookup.
> The effect is, that in createConnectionFactory in org.apache.openjpa.jdbc=
.conf.JDBCConfigurationImpl, if a ConnectionFactoryName is provided which c=
auses a NamingException, null is returned from getConnectionFactory() and i=
t tries to get the DataSource using JDBC configuration data, what fails, si=
nce there aren't any provided. It ends up with a ArgumentException with mes=
sage: "A JDBC Driver or DataSource class name must be specified in the Conn=
ectionDriverName property." which is totally misleading.
> Expected: the provider returns information about the failure to retrieve =
the DataSource from JNDI. It shoul'd silently fall back to using JDBC prope=
rties.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira