You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2026/02/15 07:33:44 UTC
Antlr replacement: status
Hi!
4 months ago, I started to replace all the LDAP API antlr generated
parses (there were 7 of them).
Today, I just committed the replacement of the ACIItem parser. It speeds
up the parsing of an ACI by a x3 factor, removed all the synchronized
sections, fixed some wrong tests, and removed 13 classes.
This move was necessary as the antlr parser we were using (2.7.7) wasn't
usable with Java 21+.
The last parser to be removed is the DN parser. A big piece of work.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org
Re: Antlr replacement: status
Posted by Brian Demers <br...@gmail.com>.
Thanks!
I think this confirms my suspicion that a phone number should be modeled as
a String (with a validated format).
On Tue, Feb 17, 2026 at 11:59 AM Emmanuel Lecharny <el...@gmail.com>
wrote:
> Hi Brian,
>
> you are using antlr V4 which has no issue with Java 21.
>
>
> Regarding the TelephoneNumber filter, we have already such a piece of code
> in Apache LDAP API. It's based on a regexp:
>
> private static final String DEFAULT_REGEXP = "^ *[+]? *((\\([0-9-
> ,;/#*]+\\))|[0-9- ,;/#*]+)+$";
>
> ...
>
> // We will use a regexp to check the TelephoneNumber.
>
> boolean result;
>
> // Not sure this is 100% necessary...
>
> synchronized ( defaultPattern )
>
> {
>
> result = defaultPattern.matcher( strValue ).matches();
>
> }
>
> if ( LOG.isDebugEnabled() )
>
> {
>
> if ( result )
>
> {
>
> LOG.debug( I18n.msg( I18n.MSG_13701_SYNTAX_VALID, value ) );
>
> }
>
> else
>
> {
>
> LOG.debug( I18n.err( I18n.ERR_13210_SYNTAX_INVALID, value ) );
>
> }
>
> }
>
> return result;
>
> I'm pretty sure it's similar (except the 'tel:' at the beginning). I'll
> check.
>
> So regarding your questions:
>
> 1. In LDAP API , are phone numbers modeled into individual parts? or treated as just a string?
>
> they are treated as a String.
>
> 2. If not has this been something anyone has ever ask for?
>
>
> Basically, there is a ITU recommendation for the telephone number syntax:
>
> /**
>
> * A SyntaxChecker which verifies that a value is a TelephoneNumber
> according to ITU
>
> * recommendation E.123 (which is quite vague ...).
>
> * <p>
>
> * A valid Telephone number respects more or less this syntax :
>
> *
>
> * <pre>
>
> * " *[+]? *((\([0-9- ,;/#*]+\))|[0-9- ,;/#*]+)+"
>
> * </pre>
>
> *
>
> * If needed, and to allow more syntaxes, a list of regexps has been added
>
> * which can be initialized to other values
>
> *
>
> * @author <a href="mailto:dev@directory.apache.org">Apache Directory
> Project</a>
>
> */
>
> As said in the header, it's 'vague', so we have added a way for those who
> would like to use another
>
> regexp to inject it into the syntax checker...
>
> Hope it helps.
>
>
> On 2/17/26 17:45, Brian Demers wrote:
>
> Awesome!
>
> SCIMple has a couple of ANTLR parsers:
> 1. Filters (e.g. a query)
> 2. Phone numbers.
> https://github.com/apache/directory-scimple/tree/develop/scim-spec/scim-spec-schema/src/main/antlr4/org/apache/directory/scim/spec
>
> IMHO, the phone number object is more complex than necessary. IMHO, this
> _could_ just be a string with some basic validation
> (IdPs will likely have additional requirements/validation as well)
>
> From the SCIM spec:
>
> Service providers SHOULD canonicalize the value according to [RFC3966]
>
> format, when appropriate.
>
> This may be an area that _might_ benefit for some consistency between
> Directory projects.
>
> After a quick search it looks like LDAP API, is just doing some basic
> validation:https://github.com/apache/directory-ldap-api/blob/69965740b68e10367816697ac3548beb528e255d/ldap/model/src/main/java/org/apache/directory/api/ldap/model/schema/syntaxCheckers/FacsimileTelephoneNumberSyntaxChecker.java#L57
>
> Questions:
> 1. In LDAP API , are phone numbers modeled into individual parts? or
> treated as just a string?
> 2. If not has this been something anyone has ever ask for?
>
> IMHO, it's a cool feature, but I'm not sure if it is worth the
> burden/complexity in SCIMple. (This is logic that could be moved into an
> implementing project).
>
> Thoughts?
>
> On Sun, Feb 15, 2026 at 2:33 AM Emmanuel Lecharny <el...@gmail.com> <el...@gmail.com>
> wrote:
>
>
> Hi!
>
> 4 months ago, I started to replace all the LDAP API antlr generated
> parses (there were 7 of them).
>
> Today, I just committed the replacement of the ACIItem parser. It speeds
> up the parsing of an ACI by a x3 factor, removed all the synchronized
> sections, fixed some wrong tests, and removed 13 classes.
>
> This move was necessary as the antlr parser we were using (2.7.7) wasn't
> usable with Java 21+.
>
>
> The last parser to be removed is the DN parser. A big piece of work.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
> For additional commands, e-mail: dev-help@directory.apache.org
>
>
Re: Antlr replacement: status
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi Brian,
you are using antlr V4 which has no issue with Java 21.
Regarding the TelephoneNumber filter, we have already such a piece of
code in Apache LDAP API. It's based on a regexp:
privatestaticfinalStringDEFAULT_REGEXP= "^ *[+]? *((\\([0-9-
,;/#*]+\\))|[0-9- ,;/#*]+)+$";
...
// We will use a regexpto check the TelephoneNumber.
booleanresult;
// Not sure this is 100% necessary...
synchronized( defaultPattern)
{
result= defaultPattern.matcher( strValue).matches();
}
if( LOG.isDebugEnabled() )
{
if( result)
{
LOG.debug( I18n.msg( I18n.MSG_13701_SYNTAX_VALID, value) );
}
else
{
LOG.debug( I18n.err( I18n.ERR_13210_SYNTAX_INVALID, value) );
}
}
returnresult;
I'm pretty sure it's similar (except the 'tel:' at the beginning). I'll
check.
So regarding your questions:
1. In LDAP API , are phone numbers modeled into individual parts? or treated as just a string?
they are treated as a String.
2. If not has this been something anyone has ever ask for?
Basically, there is a ITU recommendation for the telephone number syntax:
/**
* A SyntaxChecker which verifies that a value is a TelephoneNumber
according to ITU
* recommendation E.123 (which is quite vague ...).
* <p>
* A valid Telephone number respects more or less this syntax :
*
* <pre>
* " *[+]? *((\([0-9-,;/#*]+\))|[0-9-,;/#*]+)+"
* </pre>
*
* If needed, and to allow more syntaxes, a list of regexpshas been added
* which can be initialized to other values
*
* @author<a href="mailto:dev@directory.apache.org">Apache Directory
Project</a>
*/
As said in the header, it's 'vague', so we have added a way for those
who would like to use another
regexp to inject it into the syntax checker...
Hope it helps.
On 2/17/26 17:45, Brian Demers wrote:
> Awesome!
>
> SCIMple has a couple of ANTLR parsers:
> 1. Filters (e.g. a query)
> 2. Phone numbers.
>
> https://github.com/apache/directory-scimple/tree/develop/scim-spec/scim-spec-schema/src/main/antlr4/org/apache/directory/scim/spec
>
> IMHO, the phone number object is more complex than necessary. IMHO, this
> _could_ just be a string with some basic validation
> (IdPs will likely have additional requirements/validation as well)
>
> From the SCIM spec:
>> Service providers SHOULD canonicalize the value according to [RFC3966]
> format, when appropriate.
>
> This may be an area that _might_ benefit for some consistency between
> Directory projects.
>
> After a quick search it looks like LDAP API, is just doing some basic
> validation:
> https://github.com/apache/directory-ldap-api/blob/69965740b68e10367816697ac3548beb528e255d/ldap/model/src/main/java/org/apache/directory/api/ldap/model/schema/syntaxCheckers/FacsimileTelephoneNumberSyntaxChecker.java#L57
>
> Questions:
> 1. In LDAP API , are phone numbers modeled into individual parts? or
> treated as just a string?
> 2. If not has this been something anyone has ever ask for?
>
> IMHO, it's a cool feature, but I'm not sure if it is worth the
> burden/complexity in SCIMple. (This is logic that could be moved into an
> implementing project).
>
> Thoughts?
>
> On Sun, Feb 15, 2026 at 2:33 AM Emmanuel Lecharny<el...@gmail.com>
> wrote:
>
>> Hi!
>>
>> 4 months ago, I started to replace all the LDAP API antlr generated
>> parses (there were 7 of them).
>>
>> Today, I just committed the replacement of the ACIItem parser. It speeds
>> up the parsing of an ACI by a x3 factor, removed all the synchronized
>> sections, fixed some wrong tests, and removed 13 classes.
>>
>> This move was necessary as the antlr parser we were using (2.7.7) wasn't
>> usable with Java 21+.
>>
>>
>> The last parser to be removed is the DN parser. A big piece of work.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:dev-unsubscribe@directory.apache.org
>> For additional commands, e-mail:dev-help@directory.apache.org
>>
>>
Re: Antlr replacement: status
Posted by Brian Demers <br...@gmail.com>.
Awesome!
SCIMple has a couple of ANTLR parsers:
1. Filters (e.g. a query)
2. Phone numbers.
https://github.com/apache/directory-scimple/tree/develop/scim-spec/scim-spec-schema/src/main/antlr4/org/apache/directory/scim/spec
IMHO, the phone number object is more complex than necessary. IMHO, this
_could_ just be a string with some basic validation
(IdPs will likely have additional requirements/validation as well)
From the SCIM spec:
> Service providers SHOULD canonicalize the value according to [RFC3966]
format, when appropriate.
This may be an area that _might_ benefit for some consistency between
Directory projects.
After a quick search it looks like LDAP API, is just doing some basic
validation:
https://github.com/apache/directory-ldap-api/blob/69965740b68e10367816697ac3548beb528e255d/ldap/model/src/main/java/org/apache/directory/api/ldap/model/schema/syntaxCheckers/FacsimileTelephoneNumberSyntaxChecker.java#L57
Questions:
1. In LDAP API , are phone numbers modeled into individual parts? or
treated as just a string?
2. If not has this been something anyone has ever ask for?
IMHO, it's a cool feature, but I'm not sure if it is worth the
burden/complexity in SCIMple. (This is logic that could be moved into an
implementing project).
Thoughts?
On Sun, Feb 15, 2026 at 2:33 AM Emmanuel Lecharny <el...@gmail.com>
wrote:
> Hi!
>
> 4 months ago, I started to replace all the LDAP API antlr generated
> parses (there were 7 of them).
>
> Today, I just committed the replacement of the ACIItem parser. It speeds
> up the parsing of an ACI by a x3 factor, removed all the synchronized
> sections, fixed some wrong tests, and removed 13 classes.
>
> This move was necessary as the antlr parser we were using (2.7.7) wasn't
> usable with Java 21+.
>
>
> The last parser to be removed is the DN parser. A big piece of work.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
> For additional commands, e-mail: dev-help@directory.apache.org
>
>