[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577136#action_12577136 ] Mamta A. Satoor commented on DERBY-3320: Currently, I am thinking of concentrating only on making sure that Collator can be instantiated for the locale on a give JVM when a user is trying to create/boot a database with territory based collation. > 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_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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577151#action_12577151 ] Mamta A. Satoor commented on DERBY-3320: Also, I am considering throwing an exception if the exact locale is not found. If anyone has any comments on this proposed behavior, please add a comment to this jira entry. > 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_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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577157#action_12577157 ] Knut Anders Hatlen commented on DERBY-3320: --- Wasn't the problem that if a locale wasn't supported, the Collator would be instantiated anyway and silently use en_US? If that was the problem, I don't think checking that the Collator can be instantiated will help. > 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_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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577171#action_12577171 ] Mamta A. Satoor commented on DERBY-3320: Sorry for the brief comment "making sure that Collator can be instantiated for the locale on a give JVM ". Let me elaborate on what I am thinking of doing. Collator class has a method called getAvailableLocales which returns an array of locales which are the union of locales supported by the Java runtime and by installed CollatorProvider(a subclass of LocaleServiceProvider) implementations. Locale class also has a method called getAvailableLocales which returns an array of locales which are the union of locales supported by the Java runtime and by installed LocaleServiceProvider implementations. So, it appears that the locale arrary returned from Collator.getAvailableLocales will be a subset of locale array returned by Locale.getAvailableLocales What I was thinking of doing was adding a new method (don't know in which class at this point) which will go through the arrary returned by Collator.getAvailableLocales and see if the locale requested by the user is included in the locale arrary. If not, then throw an exception. I was planning on calling this method when I find at database create/boot time that user has asked for territory based collation. After thinking more about it, I think it will be better for us to make the new method more generic by going through Locale.getAvailableLocales rather than the Collator.getAvailableLocales. And then seee if the locale requested by the user is inclueded in the locale array. Making the method generic this way will enable us to use it for other Derby functionality that uses the database locale (some of this functionality has been identified by Dan in his earlier comment to this jira entry). > 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_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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577186#action_12577186 ] Knut Anders Hatlen commented on DERBY-3320: --- Thanks, that makes sense. > After thinking more about it, I think it will be better for us to > make the new method more generic by going through > Locale.getAvailableLocales rather than the > Collator.getAvailableLocales. What if Locale.getAvailableLocales() says that a locale is available and Collator.getAvailableLocales() says that we don't have collators for that locale? If we only look at Locale.getAvailableLocales(), won't we incorrectly conclude that we support collation for that locale and create an en_US Collator? > 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_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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577221#action_12577221 ] Daniel John Debrunner commented on DERBY-3320: -- Mamta> see if the locale requested by the user is included in the locale arrary What does that mean, especially with regards to this comment: Vemund> Something to consider is also whether you need an exact match to consider a locale supported for the purpose of the Collator, or if it is enough to get a language match? For instance, if looking for en_GB, is en_US good enough? > 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_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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577235#action_12577235 ] Daniel John Debrunner commented on DERBY-3320: -- Sorry missed earlier comment about exact match on locale. > 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_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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577486#action_12577486 ] Vemund Østgaard commented on DERBY-3320: My understanding is along the lines of what Knut writes, that the set of locales supported by Collator and Locale in theory can be different. If collation=TERRITORY_BASED the selected locale should be one of those returned by Collator.getAvailableLocales(). See also my comment on Jan. 25. 08. > 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_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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577500#action_12577500 ] Mamta A. Satoor commented on DERBY-3320: Thanks, Vemund and Knut. I was under the impression that if a locale is avaialble through Locale.getAvailableLocales(), then all the locale related functionality (including Collation) is automatically available. But it appears that it is not correct. Based on this, I will go ahead and code to look for Collator.getAvailableLocales rather than Locale.getAvailableLocales(). Is there a need to look at Locale.getAvailableLocales() also or is Collator.getAvailableLocales() sufficient? > 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_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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577882#action_12577882 ] Vemund Østgaard commented on DERBY-3320: I think it is sufficient as a first increment at least to check just Collator.getAvailableLocales(). I think you are correct in your earlier assessment that the locales returned by Collator.getAvailableLocales() is a subset of the locales returned by Locale.getAvailableLocales(), so if you find the locale in the first list it should also be in the second. > 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_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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579910#action_12579910 ] Mamta A. Satoor commented on DERBY-3320: I spent some time on this jira entry and found that we get the Locale and Collator for the database even before we know that we are dealing with a territory based database. This happens in DataValueFactoryImpl.setLocale which gets called by BasicDatabase.boot(). The reason we do this setting before the store module and data dictionary module boots up is so that Collator info is available to store if needs to do recovery. I am trying to tackle the problem first for database create time only(will address subsequent boot times later on). I will try to see if I can find the request for territory based database during DataValueFactory module bootup so we can see if Collator is really supported or not for the given locale. > 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_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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580106#action_12580106 ] Daniel John Debrunner commented on DERBY-3320: -- Why not just throw an exception when the collator object is created if the locale is not supported? Then there's no need to figure out if it's boot or create database time. > 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_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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580423#action_12580423 ] Mamta A. Satoor commented on DERBY-3320: In DVF.setLocale, the Collator object gets created whether we are dealing with territory based database or not. If the database is not territory based, then the Collator object never gets used. But if it is a territory based database, then Store might use the Collator object if it needs to database recovery. I think we can check if the Collator object can be created or not for the given locale irrespective of whether it is territory based db or UCS_BASIC db. So, I will go ahead and do the check and not worry about whether it is boot/create time and whether we are dealing with territory based db or not. > 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_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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580432#action_12580432 ] Daniel John Debrunner commented on DERBY-3320: -- That's not exactly what I meant, I was more thinking of just throwing an error when a collator was requested (ie. needed for collation) and could not be created. Thinking about it more though, that might be sometime later than create/boot. Though I'm not sure if that's a problem. Thinking about the future, a database may have many collations associated with it. Will it be a requirement that all collations are supported on the current jvm before the database can be booted? > 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_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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580436#action_12580436 ] Mamta A. Satoor commented on DERBY-3320: Dan wrote "Thinking about it more though, that might be sometime later than create/boot." I am not sure if that is correct, In case of recovery, store will need the collator object during boot. Based on the same thinking, in future, when a database may have many collations associated with it, we might need to make sure the all collations are supported at db boot time because they may be required during store recovery at the database boot time. > 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_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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580442#action_12580442 ] Daniel John Debrunner commented on DERBY-3320: -- I don't think store needs the collator if there is no recovery to perform (e.g. clean shutdown previously), so that's what I meant by "might be sometime later". So I'm saying if the database has tables with three collations A,B,C and the current vm only supports A,C, then if recovery does not touch any table with B, then why not let the database boot. If recovery needed B then an exception would be thrown and the database would fail to boot. > 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_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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580445#action_12580445 ] Mamta A. Satoor commented on DERBY-3320: So, seems like there could be 2 approaches here. During the boot, if the access to Collator object is required, then verify at that time that the Collator object can be created for the given locale. Once, the recovery/boot is over, 1)right before leaving the boot process, make sure that the Collator object can be created if it has not already been created. This would mean that if the database has tables with three different collations, then all those Collator objects should be supported by JVM once the boot process is over. 2)wait until the first access to Collator object and verify that Collator object can be instantiated. So, user may not find until much later in the database session(when they actually need to use the Collator object) that the required Collator object is not available. > 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_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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[
https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580477#action_12580477
]
Mamta A. Satoor commented on DERBY-3320:
I am starting to think of the implementation for the following approach
At the db create time, we will give the error for Collator not available (if
that is the case) when the database is getting created rather than wait until a
user creates a table with char column. For the database boot time, throw the
error whenever the Collator is accessed first(ie not right towards the end of
the boot time in BasicDatabase). This first access can happen because recovery
was required during boot time or later when user has triggered access to
Collator through SQL.
With the above approach in mind, I am thinking that I will keep the changes in
DVF.setLocale(the changes shown in the patch attached to this jira entry) where
I check if we are in here for database create time and check for Collator
object and if found, put it in collatorForCharacterTypes class variable. If not
for database create time, don't even create the Collator object in
DVF.setLocale ie do not load collatorForCharacterTypes.
DVF has a method called getCharacterCollator which now will have to see if it
is dealing with territory based db, If yes, then check if
collatorForCharacterTypes is not null. If not null, then return
collatorForCharacterTypes otherwise it mean that Collator object is getting
accessed for the first time and hence check if the JVM supports it. If not,
then throw exception. If it is supported, then put the Collator object in
collatorForCharacterTypes and return collatorForCharacterTypes from
getCharacterCollator. So, as we can see, now we will have an additional check
for territory based db in getCharacterCollator to see if
collatorForCharacterTypes is null or not and if null, then verify that Collator
is supported by the JVM. Pseudo code follows
DVF.getCharacterCollator (as it is in trunk)
if (collationType == StringDataValue.COLLATION_TYPE_UCS_BASIC)
return (RuleBasedCollator)null;
else
return collatorForCharacterTypes;
The new code for DVF.getCharacterCollator will be
if (collationType == StringDataValue.COLLATION_TYPE_UCS_BASIC)
return (RuleBasedCollator)null;
else if (collatorForCharacterTypes == null) {
Collator object supported by JVM for
databaseLocale?
If not, throw exception
If yes, then
collatorForCharacterTypes = Collator object
return collatorForCharacterTypes;
} else
return collatorForCharacterTypes;
> 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_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=. 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 boot
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580486#action_12580486 ] Daniel John Debrunner commented on DERBY-3320: -- The general approach looks good, though I would say all the create logic going into setLocale() really should be in DataValueFactoryImpl.boot() Then this avoids the need to change the signature of setLocale(). > 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_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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[
https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580497#action_12580497
]
Mamta A. Satoor commented on DERBY-3320:
I might not be understanding the boot handshake correctly but the signature of
the boot method in DVF is as follows
public void boot(boolean create, Properties properties) throws
StandardException
BasicDatabase.boot has gotten the Locale required for the db through the
following code
if (create)
{
if (startParams.getProperty(Property.CREATE_WITH_NO_LOG) ==
null)
startParams.put(Property.CREATE_WITH_NO_LOG, "true");
String localeID =
startParams.getProperty(org.apache.derby.iapi.reference.Attribute.TERRITORY);
if (localeID == null) {
localeID = Locale.getDefault().toString();
}
databaseLocale = monitor.setLocale(startParams, localeID);
} else {
databaseLocale = monitor.getLocale(this);
}
And then BasicDatabase.boot boots DVF and calls DVF.setLocale so that it can
pass the locale object that it has determined to DVF. It looks like there is no
way to pass that locale info through the boot machinery that we already have in
place. So, if we want DVF.boot to do the Collator checking, it will have to get
its hand on locale in it's boot method by going through code similar to
BasicDatabase.boot (copied above). This seems fine to me because then
everything related to boot is in boot method of the DVF and it does not have to
wait for DVF.setLocale to get it's locale set correctly. If we do decide to go
this path, then we can remove DVF.setLocal from BasicDatabase.boot and do the
locale setting in the DVF boot method.
> 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_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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581580#action_12581580 ] Mamta A. Satoor commented on DERBY-3320: Mike Matrigali had following comment on derby list Do you have some way of creating a database, but then making the Collator not available when you next try to boot the database. I am trying to think of the recovery test case, but need to be able to create the db using a territory based sorting and then the next test case needs to boot the db and find that collator not available. I assume you have the simple test case for creating the db with just picking a territory that does not exist anywhere. > 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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581583#action_12581583 ] Mamta A. Satoor commented on DERBY-3320: Mike asked, "I assume you have the simple test case for creating the db with just picking a territory that does not exist anywhere. " I do not have a territory which I know will not exist anymore. I will work on writing a standalone Java program to see if it is possible to determine a missing territory on a given JVM with some while loop. In the meantime, if anyone has any ideas on how to find such a territory, please share them. > 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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581593#action_12581593 ] Daniel John Debrunner commented on DERBY-3320: -- You can always just make up a locale that doesn't exist, xx_zz > 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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581597#action_12581597 ] Mamta A. Satoor commented on DERBY-3320: That worked, I tried it with my changes for catching requested locale that does not exist at database create time.Thanks, Dan. $ java org.apache.derby.tools.ij ij version 10.5 ij> connect 'jdbc:derby:c:/dellater/dbTerritory;create=true;territory=xx_zz;collation=TERRITORY_BASED'; ERROR XJ041: Failed to create database 'c:/dellater/dbTerritory', see the next exception for details. ERROR XBM04: Collator support not available from the JVM for the database's locale 'xx_ZZ'. ij> exit; > 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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[
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.(EmbedConnection.java:363)
at
org.apache.derby.impl.jdbc.EmbedConnection30.(EmbedConnection30.java:73)
at
org.apache.derby.impl.jdbc.EmbedConnection40.(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 su
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582013#action_12582013 ] Mamta A. Satoor commented on DERBY-3320: It appears that database creation happens through TestSetup heirarchy. CollationTest on the other hand does not extend TestSetup. It extends TestCase and I think that is why my run() method in CollationTest does not really get the exception thrown through the TestSetup class hierarchy. I will keep looking but if anyone has any ideas, please pass them along. Basically, what I am looking for is catching the exception thrown during the database creation time in CollationTest so that I can ignore Collator support not available exception. > 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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582028#action_12582028 ] Daniel John Debrunner commented on DERBY-3320: -- Why not just attempt to create the database directly in the text fixture. The decorator for collated database is intended to provide a working database for collation tests, it's not intended as a general test fixture. > 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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584028#action_12584028 ] Mamta A. Satoor commented on DERBY-3320: Committed changes into trunk with revision 643292. At the top level, following describes the changes that went in as 643292. DERBY-3320 This commit will ensure that if the Collator support does not exist during a territory based database creation, then we will throw an exception saying Collator support does not exist. In case of subsequent boot of a successfully created territory based database, we will check for the Collator support from JVM at the time first collation related operation is run on the database. This can happen if the database recovery needs to be done at the boot time or it can happen after the database has booted and user has issued a SQL which requires Collator support. The details of the changes that went into different classes can be seen in the commit comments. I added a test case for a territory based database creation with a locale for which Collator support does not exist. There is no test case for database recovery and missing Collator support yet. There is also no test for successful territory based database boot but detecting no Collator support when a SQL is issued which requires Collator support. > 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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585205#action_12585205 ] Mamta A. Satoor commented on DERBY-3320: I am researching into how support for a Collator can be removed from a JVM. What I am hoping to accomplish is create a territory based database with say Norwegian locale. Then shutdown the database and remove the support for Norwegian locale from the JVM in such a way that the Collator object for Nrowegian local can not be instantiated for that JVM. Then boot the database again and issue a SQL which requires collation operation and that SQL should fail because Collator could not be found for Norwegian. If anyone has any ideas on removal of Collator, please post a comment here. > 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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585564#action_12585564 ] Vemund Østgaard commented on DERBY-3320: I'm not sure if there is any easy way to accomplish what you want. What comes to mind is that I think you could write your own CollatorProvider. This CollatorProvider could be written in a way that allows you to instrument it to behave the way you want. This CollatorProvider would extend the support in the jdk/jre with some dummy Collator for a made up Locale when you want it to. Then, when you want it to no longer provide support for that Locale, you just tell it not to by setting a property or something. Basically you could just tell it to support any Locale, the jre will call a method: public abstract Collator getInstance(Locale locale) that you implement yourself in your CollatorProvider. The javadoc for LocaleServiceProvider says a bit about how to package such an extension. I don't know if this is a feasible path but it might be worth looking into. > 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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585566#action_12585566 ] Vemund Østgaard commented on DERBY-3320: Now that suites.All is running again on Java ME, I discovered that the new test in CollationTest fails on this platform. I tested on phoneME advanced and saw: There was 1 failure: 1) testMissingCollatorSupport(org.apache.derbyTesting.functionTests.tests.lang.CollationTest)junit.framework.AssertionFailedError: could not instantiate driver at org.apache.derbyTesting.functionTests.tests.lang.CollationTest.loadDriver()V(CollationTest.java:1320) at org.apache.derbyTesting.functionTests.tests.lang.CollationTest.testMissingCollatorSupport()V(CollationTest.java:1250) at org.apache.derbyTesting.junit.BaseTestCase.runBare()V(BaseTestCase.java:103) at sun.misc.CVM.runMain()V(CVM.java:514) AFAIK java.sql.Driver and DriverManager is not supported with JSR169, only DataSource. > 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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585639#action_12585639 ] Mamta A. Satoor commented on DERBY-3320: Vemund thanks for your comments. I will further investigate into what you suggested. I will also look into DriverManager vs DataSource issue. > 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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585641#action_12585641 ] Mamta A. Satoor commented on DERBY-3320: I have migrated the revision 643292 from trunk into 10.4 codeline with revision 644779. I will work on migrating it to 10.3 codeline as well. > 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 > Fix For: 10.4.0.0, 10.5.0.0 > > 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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586523#action_12586523 ] Mamta A. Satoor commented on DERBY-3320: Checked in a fix for DriverManager vs DataSource issue with the newly added test. JSR169 does not support DriverManager. I changed the test to use TestUtil.getConnection rather than getting the Connection directly through DriverManager.getConnection. The change went in as 645665 into trunk. I will merge this into 10.4 codeline later. > 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 > Fix For: 10.4.0.0, 10.5.0.0 > > 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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586554#action_12586554 ] Mamta A. Satoor commented on DERBY-3320: Migrated test changes into 10.4 codeline with revision 645706. > 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 > Fix For: 10.4.0.0, 10.5.0.0 > > 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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586677#action_12586677 ] Mamta A. Satoor commented on DERBY-3320: Merged 643292 and 645665 from trunk into 10.3 codeline. The revision for 10.3 merge is 645775. > 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 > Fix For: 10.3.2.2, 10.4.0.0, 10.5.0.0 > > 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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586921#action_12586921 ] Mamta A. Satoor commented on DERBY-3320: The only item remaining on this issue is adding 2 test cases. The test cases that will be nice to have are 1)create a territory based database, then crash it, then make sure that the Collator support for the database's locale is not available anymore and then try to reboot the database, This should make the database go through the recovery and the recovery code should fail because Collator support does not exist 2)create a territory based database, then shut it down, then make sure that the Collator support for the database's locale is not available anymore and then reboot the database. The database reboot should succeed because it did not need access to Collator. Now, issue a SQL which will do a collation operation and then collation operation should fail because Collator is not available. The manual steps in ij for test case 1 would be connect 'jdbc:derby:c:/dellater/dbTerritory;create=true;territory=no;collation=TERRITORY_BASED'; create table t1(c11 int, c12 char(4)); create index i1 on t1(c12); autocommit off; insert into t1 values (1,'11'),(2,'22'); insert into t1 values (3,'33'),(4,'44'); delete from t1 where c11=1; --IMPORTANT STEP. Ctrl-C out of ij. ie do not exit but instead, force a database crash by doing Ctrl-C Now, remove the Collator support for Norway and restart ij again and following reboot of the db should fail connect 'jdbc:derby:c:/dellater/dbTerritory'; The manual steps in ij for test case 2 would be connect 'jdbc:derby:c:/dellater/dbTerritory;create=true;territory=no;collation=TERRITORY_BASED'; create table t1(c11 int, c12 char(4)); insert into t1 values (1,'11'),(2,'22'); exit; --IMPORTANT STEP Remove the Collator support for Norway and restart ij and connect to the database connect 'jdbc:derby:c:/dellater/dbTerritory'; --following SQL will fail because it requires acces to Collator select * from t1; I have not spent the time on Vemund's suggestion about creating and adding a custom Collator and removing it. I will go ahead and enter a new jira entry for exploring custom Collator and then using it to add the 2 test cases mentioned above. In the mean time, I did hand tweaked the Derby code to make sure that the above 2 test cases fail in my client as expected. In both the test cases above, before we restart the ij, I changed DataValueFactoryImpl.verifyCollatorSupport code to always throw an exception that Collator is not found. So, my changes in DataValueFactoryImpl.verifyCollatorSupport would look as follows Locale[] availLocales = Collator.getAvailableLocales(); //Verify that Collator can be instantiated for the given locale. boolean localeFound = false; for (int i=0; i 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 > Fix For: 10.3.2.2, 10.4.0.0, 10.5.0.0 > > 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=. I'm not >
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586933#action_12586933 ] Mamta A. Satoor commented on DERBY-3320: I have added jira entry DERBY-3608 for 2 additional test cases that could be added. > 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 > Fix For: 10.3.2.2, 10.4.0.0, 10.5.0.0 > > 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=. 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.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562434#action_12562434 ] Vemund Østgaard commented on DERBY-3320: I am not sure if there is an easier way to check for Locale support, I used your method when making a patch for the tests to avoid running them when the locale to test with was not available. It has not been committed yet, though. I think maybe that Locale.getAvailableLocales() doesn't necessarily have to return the same list of supported Locales as Collator.getSupportedLocales(), or other locale-dependent classes with the getSupportedLocales() method. So maybe it is important to check what returned by the functionality that will be used, like Collator. Take a look at the javadoc for java.util.spi.LocaleServiceProvider, it seems all the different locale-dependant provider classes are subclasses of this. The second last paragraph says: Locale sensitive factory methods and methods for name retrieval in the java.text and java.util packages invoke service provider methods when needed to support the requested locale. The methods first check whether the Java runtime environment itself supports the requested locale, and use its support if available. Otherwise, they call the getAvailableLocales() methods of installed providers for the appropriate interface to find one that supports the requested locale. If such a provider is found, its other methods are called to obtain the requested object or name. If neither the Java runtime environment itself nor an installed provider supports the requested locale, a fallback locale is constructed by replacing the first of the variant, country, or language strings of the locale that's not an empty string with an empty string, and the lookup process is restarted. In the case that the variant contains one or more '_'s, the fallback locale is constructed by replacing the variant with a new variant which eliminates the last '_' and the part following it. Even if a fallback occurs, methods that return requested objects or name are invoked with the original locale before the fallback.The Java runtime environment must support the root locale for all locale sensitive services in order to guarantee that this process terminates. So, I think you will have to go through the list of supported locales for the functionality that will be used. Maybe that is only Collator? Something to consider is also whether you need an exact match to consider a locale supported for the purpose of the Collator, or if it is enough to get a language match? For instance, if looking for en_GB, is en_US good enough? Maybe if a partial match is found, the DB should be allowed to boot but write a warning about it only finding a partial match? > 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_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=. 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 successf
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566219#action_12566219 ] Daniel John Debrunner commented on DERBY-3320: -- The list of Derby functionality that uses the database locale is (are there any others?) - error messages : not a requirement that the database locale is supported, error messages will default to English. - collation - index order is dependent on the ordering, thus the database locale must be supported for collation. - UPPER/LOWER - in order to have consistent results the database locale must be supported One possible additional case is the conversion of java date time values to DATE/TIME/TIMESTAMP, that though may use the locale of the jvm. > 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_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=. 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.
