db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
Date Tue, 25 Mar 2008 06:59:24 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581799#action_12581799
] 

Mamta A. Satoor commented on DERBY-3320:
----------------------------------------

I have added a test suite in CollationTest to test for a locale that does not have support
from JVM. The test suite added is as follows (in CollationTest.suite())
        suite.addTest(collatedSuite("xx", "testNorwayCollation"));
The 2nd argument really does not make a difference in this test case because locale "xx" is
not supported by the JVM and hence we expect to get an error during database creation. When
I run CollationTest, I get expected error for unsupported locale "xx" but I am not able to
catch that exception. Apparently, the create database code path is taken through following
path
2008-03-25 06:17:34.033 GMT Thread[TestRunner-Thread,6,main] Cleanup action starting
ERROR XBM04: Collator support not available from the JVM for the database's locale 'xx'.
	at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:286)
	at org.apache.derby.iapi.types.DataValueFactoryImpl.verifyCollatorSupport(DataValueFactoryImpl.java:1160)
	at org.apache.derby.iapi.types.DataValueFactoryImpl.boot(DataValueFactoryImpl.java:156)
	at org.apache.derby.iapi.types.J2SEDataValueFactory.boot(J2SEDataValueFactory.java:45)
	at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1999)
	at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291)
	at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:553)
	at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:427)
	at org.apache.derby.impl.db.BasicDatabase.boot(BasicDatabase.java:189)
	at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1999)
	at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291)
	at org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1836)
	at org.apache.derby.impl.services.monitor.BaseMonitor.createPersistentService(BaseMonitor.java:1024)
	at org.apache.derby.iapi.services.monitor.Monitor.createPersistentService(Monitor.java:596)
	at org.apache.derby.impl.jdbc.EmbedConnection.createDatabase(EmbedConnection.java:2319)
	at org.apache.derby.impl.jdbc.EmbedConnection.<init>(EmbedConnection.java:363)
	at org.apache.derby.impl.jdbc.EmbedConnection30.<init>(EmbedConnection30.java:73)
	at org.apache.derby.impl.jdbc.EmbedConnection40.<init>(EmbedConnection40.java:54)
	at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Driver40.java:68)
	at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:238)
	at org.apache.derby.jdbc.EmbeddedDataSource.getConnection(EmbeddedDataSource.java:478)
	at org.apache.derby.jdbc.EmbeddedDataSource.getConnection(EmbeddedDataSource.java:422)
	at org.apache.derbyTesting.junit.Decorator$2.setUp(Decorator.java:185)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:18)
	at junit.framework.TestResult.runProtected(TestResult.java:124)
	at junit.extensions.TestSetup.run(TestSetup.java:23)
	at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:59)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
	at junit.framework.TestResult.runProtected(TestResult.java:124)
	at junit.extensions.TestSetup.run(TestSetup.java:23)
	at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:59)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
	at junit.framework.TestResult.runProtected(TestResult.java:124)
	at junit.extensions.TestSetup.run(TestSetup.java:23)
	at junit.framework.TestSuite.runTest(TestSuite.java:208)
	at junit.framework.TestSuite.run(TestSuite.java:203)
	at junit.swingui.TestRunner$16.run(TestRunner.java:623)

I thought I could overwrite the run() method in CollaitonTest as follows and I would be able
to trap the unavailable Collator exception and move on to the next test. But the code in catch
block never gets executed.
  public final void run(junit.framework.TestResult result) {
	  try {
		  super.run(result);
	  } catch (Exception ex) {
		  if (ex instanceof SQLException){
			  SQLException sqle = (SQLException)ex; 
	          assertEquals("Unexpected error when connecting to database ",
	                  "XBM04",
	                  sqle.getSQLState());
		  } 
      }
  }

Anyone has any tips on how I can successfully catch the exception thrown at the database create
time and assert that it is XBM04.

> Database creation and boot should fail if collation=TERRITORY_BASED and the selected
locale is not supported
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3320
>                 URL: https://issues.apache.org/jira/browse/DERBY-3320
>             Project: Derby
>          Issue Type: Bug
>    Affects Versions: 10.4.0.0
>         Environment: Java ME:
> Product: phoneME Advanced (phoneme_advanced_mr2-b34)
> Profile: Foundation Profile Specification 1.1
> Linux 2.4.21-40.ELsmp #1 SMP Thu Feb 2 22:14:12 EST 2006 i686 athlon i386 GNU/Linux
>            Reporter: Vemund Østgaard
>            Assignee: Mamta A. Satoor
>         Attachments: DERBY_3320_Collator_Support_Check_diff_v2.txt, DERBY_3320_Collator_Support_Check_stat_v2.txt,
DERBY_3320_not_ready_for_commit_diff_v1.txt, DERBY_3320_not_ready_for_commit_stat_v1.txt,
DERBY_3320_Repro.java
>
>
> A problem I've discovered when testing with the phoneME advanced platform is that the
collationtests expect other locales than Locale.US to be available on the platform that is
used for the test, and for phoneME advanced (when compiled as foundation profile) only Locale.US
is available. From the jdk1.6 javadoc of Collator.getAvailableLocales() I see that only Locale.US
is strictly required:
> public static Locale[] getAvailableLocales()
>     Returns an array of all locales for which the getInstance methods of this class can
return localized instances. The returned array represents the union of locales supported by
the Java runtime and by installed CollatorProvider implementations. It must contain at least
a Locale instance equal to Locale.US.
>     Returns:
>         An array of locales for which localized Collator instances are available.
> This led me to thinking about how Derby should behave if created/booted with collation=TERRITORY_BASED
and territory=<some unsupported locale>. I'm not sure what the consequences could be
if the database is first created on a platform that supports whatever locale is set and later
booted with one that doesn't, or created on a platform missing support and later booted with
one that has. In any case I think it may confuse a user needlessly to see the database boot
successfully with his collation setting and later behave in a way he does not expect.
> Opinions voiced on the derby-dev list are that both database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported.
> If a change like this is implemented, the collationtests should be changed to verify
correct behavior also if they are executed in an environment were some of the tested locales
are not supported.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message