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