+1 My experience is that most users should have few or no issues using the list defined by William. In part as we have in the past discouraged the use of other characters and so it should be rare that someone used something outside this list.
Vince Sent from my iPhone > On Mar 1, 2016, at 14:56, William Markito <[email protected]> wrote: > > That would be changed from now on as it's too much open ended and > troublesome to support in other subsystems such as JMX beans... Note that > "-" is still in the list, other symbols would not be allowed like "+" or > "@" - Which are very odd and should be very rare. > > On Tue, Mar 1, 2016 at 2:52 PM, Anilkumar Gingade <[email protected]> > wrote: > >> From the existing javadoc it looks like, application can have any chars in >> region name except the "/". >> >> Changing this one may have implication on existing GemFire customers.... >> >> In the past we had to make changes in OQL to support chars like "+", "-", >> "@"...(since customers used this in their region names)... >> >> -Anil. >> >> >> On Tue, Mar 1, 2016 at 2:44 PM, Udo Kohlmeyer <[email protected]> >> wrote: >> >>> +1 >>> >>>> On 2/03/2016 9:35 am, William Markito wrote: >>>> >>>> Folks, it doesn't look like we have actually finished this thread... >>>> >>>> What do you guys think about the following pattern: >>>> "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz123456-_" ? >>>> >>>> I'm not specifying a regexp to avoid problems with unicode and to keep >> it >>>> only ASCII-only... Stackoveflow has some suggestions like >>>> "^\\p{ASCII}*$" but >>>> I'd be careful and try to keep it strict to the ones specified in the >> list >>>> above. >>>> >>>> Thanks >>>> >>>> >>>> On Thu, Feb 18, 2016 at 11:19 AM, Darrel Schneider < >> [email protected] >>>> wrote: >>>> >>>> The public javadocs on Region#getName say: >>>>> Returns the name of this region. A region's name >>>>> * can be any non-empty String providing it does not >>>>> * contain the name separator, a forward slash (/). >>>>> >>>>> Here is the code from LocalRegion that validates the name: >>>>> static void validateRegionName(String name) >>>>> { >>>>> if (name == null) { >>>>> throw new >> IllegalArgumentException(LocalizedStrings.LocalRegion_NAME_CANNOT_BE_NULL.toLocalizedString()); >>>>> } >>>>> if (name.length() == 0) { >>>>> throw new >> IllegalArgumentException(LocalizedStrings.LocalRegion_NAME_CANNOT_BE_EMPTY.toLocalizedString()); >>>>> } >>>>> if (name.indexOf(SEPARATOR) >= 0) { >>>>> throw new >> IllegalArgumentException(LocalizedStrings.LocalRegion_NAME_CANNOT_CONTAIN_THE_SEPARATOR_0.toLocalizedString(SEPARATOR)); >>>>> } >>>>> } >>>>> >>>>> >>>>> On Thu, Feb 18, 2016 at 11:09 AM, William Markito <[email protected] >>> >>>>> wrote: >>>>> >>>>> I don't think we should allow non-alphanumeric region names... And >>>>> would >>>>> >>>>>> be really nice to have a list or a pattern documenting what's valid. >>>>>> >>>>>> >>>>>> On Thu, Feb 18, 2016 at 11:04 AM Kirk Lund <[email protected]> wrote: >>>>>> >>>>>> I was just looking into a ticket filed because /= was used as the >>>>>> Region >>>>> >>>>>> name and this caused problems in JMX ObjectNames. I have two >> questions: >>>>>> 1) >>>>>> >>>>>>> do we really want /= to be a valid Region name? 2) do we have a >>>>>> complete >>>>> >>>>>> list somewhere of all the non-alphanumeric characters that are usable >>>>>> in >>>>> >>>>>> Region names? >>>>>>> >>>>>>> -Kirk >>>>>>> >>>>>>> -- >>>>>> ~/William > > > > -- > > ~/William
