Topics

Internal Turnout names

Bob Jacobsen
 

JMRI 4.15.7 is throwing errors with a panel file that a user had working fine in JMRI 4.16. The relevant parts are below. The cause is that the panel file defines and uses internal turnouts with system names of IT5 and IT005 which are intended to be (and _always_ _have_ _been_) separate, but JMRI 4.16.7 thinks should be the same.

I know we discussed this, but apparently it wasn’t resolved the way I remembered. I thought we’d agreed that those should remain separate, and that there’d been a code update for that. Apparently my memory is getting worse.

Did we actually decide they _shouldn’t_ be separate?

If not, if the new behavior is wrong and the old behavior is right, I’ll just fix this. But I wanted to check first that I hadn’t misunderstood some newly-emerged consensus.

Bob

[java] 2019-11-22 07:12:22,358 managers.AbstractManager ERROR - systemName is already registered. Current system name: IT005. New system name: IT5 [AWT-EventQueue-0]
[java] 2019-11-22 07:12:22,360 configurexml.ErrorHandler ERROR - Unexpected error (Exception) while load(/Users/jake/Library/Containers/com.apple.mail/Data/Library/Mail%20Downloads/00B6EBF9-B4DF-47CF-BD53-BA128E515B85/Bondale%2020191101%200903%20L2.xml) in adaptor of type jmri.jmrix.internal.configurexml.InternalTurnoutManagerXml Exception: jmri.NamedBean$DuplicateSystemNameException: systemName is already registered. Current system name: IT005. New system name: IT5
[java] See http://jmri.org/help/en/package/jmri/configurexml/ErrorHandler.shtml for possibly more information. [AWT-EventQueue-0]
[java] jmri.NamedBean$DuplicateSystemNameException: systemName is already registered. Current system name: IT005. New system name: IT5
[java] at jmri.managers.AbstractManager.register(AbstractManager.java:235)
[java] at jmri.managers.AbstractTurnoutManager.newTurnout(AbstractTurnoutManager.java:124)
[java] at jmri.managers.ProxyTurnoutManager.makeBean(ProxyTurnoutManager.java:50)
[java] at jmri.managers.ProxyTurnoutManager.makeBean(ProxyTurnoutManager.java:18)
[java] at jmri.managers.AbstractProxyManager.newNamedBean(AbstractProxyManager.java:320)
[java] at jmri.managers.ProxyTurnoutManager.newTurnout(ProxyTurnoutManager.java:114)
[java] at jmri.managers.configurexml.AbstractTurnoutManagerConfigXML.loadTurnouts(AbstractTurnoutManagerConfigXML.java:223)
[java] at jmri.jmrix.internal.configurexml.InternalTurnoutManagerXml.load(InternalTurnoutManagerXml.java:35)
[java] at jmri.configurexml.ConfigXmlManager.loadOnSwingThread(ConfigXmlManager.java:658)



[java] 2019-11-22 07:12:36,208 managers.AbstractManager ERROR - systemName is already registered. Current system name: IT005. New system name: IT5 [AWT-EventQueue-0]
[java] 2019-11-22 07:12:36,209 nfigurexml.SingleTurnoutSignalHeadXml WARN - Failed to provide Turnout "IT5" in loadTurnout [AWT-EventQueue-0]
[java] 2019-11-22 07:12:36,210 configurexml.ErrorHandler ERROR - Unexpected error (Exception) while load(/Users/jake/Library/Containers/com.apple.mail/Data/Library/Mail%20Downloads/00B6EBF9-B4DF-47CF-BD53-BA128E515B85/Bondale%2020191101%200903%20L2.xml) in adaptor of type jmri.managers.configurexml.AbstractSignalHeadManagerXml Exception: java.lang.NullPointerException
[java] See http://jmri.org/help/en/package/jmri/configurexml/ErrorHandler.shtml for possibly more information. [AWT-EventQueue-0]
[java] java.lang.NullPointerException
[java] at jmri.implementation.SingleTurnoutSignalHead.initialize(SingleTurnoutSignalHead.java:73)
[java] at jmri.implementation.SingleTurnoutSignalHead.<init>(SingleTurnoutSignalHead.java:42)
[java] at jmri.implementation.configurexml.SingleTurnoutSignalHeadXml.load(SingleTurnoutSignalHeadXml.java:108)
[java] at jmri.managers.configurexml.AbstractNamedBeanManagerConfigXML.loadInAdapter(AbstractNamedBeanManagerConfigXML.java:439)
[java] at jmri.managers.configurexml.AbstractSignalHeadManagerXml.loadSignalHeads(AbstractSignalHeadManagerXml.java:121)
[java] at jmri.managers.configurexml.AbstractSignalHeadManagerXml.load(AbstractSignalHeadManagerXml.java:98)
[java] at jmri.configurexml.ConfigXmlManager.loadOnSwingThread(ConfigXmlManager.java:658)
[java] at jmri.configurexml.ConfigXmlManager.lambda$load$1(ConfigXmlManager.java:580)
[java] at jmri.util.ThreadingUtil.runOnGUIwithReturn(ThreadingUtil.java:148)
[java] at jmri.configurexml.ConfigXmlManager.load(ConfigXmlManager.java:578)



--
Bob Jacobsen
@BobJacobsen

danielb987
 

This is due to PR #7278, Don't register a bean that already is in the manager.

PR #7655 fixes this for internal turnouts, lights and sensors.
There may be more beans that needs this fix. PR #7379 fixed this for Memory.

https://github.com/JMRI/JMRI/pull/7655

Daniel

2019-11-22 16:20 skrev Bob Jacobsen:

JMRI 4.15.7 is throwing errors with a panel file that a user had
working fine in JMRI 4.16. The relevant parts are below. The cause
is that the panel file defines and uses internal turnouts with system
names of IT5 and IT005 which are intended to be (and _always_ _have_
_been_) separate, but JMRI 4.16.7 thinks should be the same.
I know we discussed this, but apparently it wasn’t resolved the way I
remembered. I thought we’d agreed that those should remain separate,
and that there’d been a code update for that. Apparently my memory is
getting worse.
Did we actually decide they _shouldn’t_ be separate?
If not, if the new behavior is wrong and the old behavior is right,
I’ll just fix this. But I wanted to check first that I hadn’t
misunderstood some newly-emerged consensus.
Bob
[java] 2019-11-22 07:12:22,358 managers.AbstractManager
ERROR - systemName is already registered. Current system name:
IT005. New system name: IT5 [AWT-EventQueue-0]
[java] 2019-11-22 07:12:22,360 configurexml.ErrorHandler
ERROR - Unexpected error (Exception) while
load(/Users/jake/Library/Containers/com.apple.mail/Data/Library/Mail%20Downloads/00B6EBF9-B4DF-47CF-BD53-BA128E515B85/Bondale%2020191101%200903%20L2.xml)
in adaptor of type
jmri.jmrix.internal.configurexml.InternalTurnoutManagerXml Exception:
jmri.NamedBean$DuplicateSystemNameException: systemName is already
registered. Current system name: IT005. New system name: IT5
[java] See
http://jmri.org/help/en/package/jmri/configurexml/ErrorHandler.shtml
for possibly more information. [AWT-EventQueue-0]
[java] jmri.NamedBean$DuplicateSystemNameException: systemName is
already registered. Current system name: IT005. New system name: IT5
[java] at jmri.managers.AbstractManager.register(AbstractManager.java:235)
[java] at
jmri.managers.AbstractTurnoutManager.newTurnout(AbstractTurnoutManager.java:124)
[java] at
jmri.managers.ProxyTurnoutManager.makeBean(ProxyTurnoutManager.java:50)
[java] at
jmri.managers.ProxyTurnoutManager.makeBean(ProxyTurnoutManager.java:18)
[java] at
jmri.managers.AbstractProxyManager.newNamedBean(AbstractProxyManager.java:320)
[java] at
jmri.managers.ProxyTurnoutManager.newTurnout(ProxyTurnoutManager.java:114)
[java] at
jmri.managers.configurexml.AbstractTurnoutManagerConfigXML.loadTurnouts(AbstractTurnoutManagerConfigXML.java:223)
[java] at
jmri.jmrix.internal.configurexml.InternalTurnoutManagerXml.load(InternalTurnoutManagerXml.java:35)
[java] at
jmri.configurexml.ConfigXmlManager.loadOnSwingThread(ConfigXmlManager.java:658)

[java] 2019-11-22 07:12:36,208 managers.AbstractManager
ERROR - systemName is already registered. Current system name:
IT005. New system name: IT5 [AWT-EventQueue-0]
[java] 2019-11-22 07:12:36,209
nfigurexml.SingleTurnoutSignalHeadXml WARN - Failed to provide
Turnout "IT5" in loadTurnout [AWT-EventQueue-0]
[java] 2019-11-22 07:12:36,210 configurexml.ErrorHandler
ERROR - Unexpected error (Exception) while
load(/Users/jake/Library/Containers/com.apple.mail/Data/Library/Mail%20Downloads/00B6EBF9-B4DF-47CF-BD53-BA128E515B85/Bondale%2020191101%200903%20L2.xml)
in adaptor of type
jmri.managers.configurexml.AbstractSignalHeadManagerXml Exception:
java.lang.NullPointerException
[java] See
http://jmri.org/help/en/package/jmri/configurexml/ErrorHandler.shtml
for possibly more information. [AWT-EventQueue-0]
[java] java.lang.NullPointerException
[java] at
jmri.implementation.SingleTurnoutSignalHead.initialize(SingleTurnoutSignalHead.java:73)
[java] at
jmri.implementation.SingleTurnoutSignalHead.<init>(SingleTurnoutSignalHead.java:42)
[java] at
jmri.implementation.configurexml.SingleTurnoutSignalHeadXml.load(SingleTurnoutSignalHeadXml.java:108)
[java] at
jmri.managers.configurexml.AbstractNamedBeanManagerConfigXML.loadInAdapter(AbstractNamedBeanManagerConfigXML.java:439)
[java] at
jmri.managers.configurexml.AbstractSignalHeadManagerXml.loadSignalHeads(AbstractSignalHeadManagerXml.java:121)
[java] at
jmri.managers.configurexml.AbstractSignalHeadManagerXml.load(AbstractSignalHeadManagerXml.java:98)
[java] at
jmri.configurexml.ConfigXmlManager.loadOnSwingThread(ConfigXmlManager.java:658)
[java] at
jmri.configurexml.ConfigXmlManager.lambda$load$1(ConfigXmlManager.java:580)
[java] at
jmri.util.ThreadingUtil.runOnGUIwithReturn(ThreadingUtil.java:148)
[java] at
jmri.configurexml.ConfigXmlManager.load(ConfigXmlManager.java:578)
--
Bob Jacobsen
@BobJacobsen

Bob Jacobsen
 

Daniel, thanks for working on PRs for this.

But the more I look at it, the more I’m confused. Perhaps my memory really is going, but I thought we’d agreed to _remove_ all the “normalize name to correct user input errors” code so that people would enter names and we’d use them.

Do I have that wrong and we decided to keep it?

Bob

On Nov 22, 2019, at 8:50 AM, danielb987 <db123@...> wrote:

This is due to PR #7278, Don't register a bean that already is in the manager.

PR #7655 fixes this for internal turnouts, lights and sensors.
There may be more beans that needs this fix. PR #7379 fixed this for Memory.

https://github.com/JMRI/JMRI/pull/7655

Daniel

2019-11-22 16:20 skrev Bob Jacobsen:
JMRI 4.15.7 is throwing errors with a panel file that a user had
working fine in JMRI 4.16. The relevant parts are below. The cause
is that the panel file defines and uses internal turnouts with system
names of IT5 and IT005 which are intended to be (and _always_ _have_
_been_) separate, but JMRI 4.16.7 thinks should be the same.
I know we discussed this, but apparently it wasn’t resolved the way I
remembered. I thought we’d agreed that those should remain separate,
and that there’d been a code update for that. Apparently my memory is
getting worse.
Did we actually decide they _shouldn’t_ be separate?
If not, if the new behavior is wrong and the old behavior is right,
I’ll just fix this. But I wanted to check first that I hadn’t
misunderstood some newly-emerged consensus.
Bob
[java] 2019-11-22 07:12:22,358 managers.AbstractManager
ERROR - systemName is already registered. Current system name:
IT005. New system name: IT5 [AWT-EventQueue-0]
[java] 2019-11-22 07:12:22,360 configurexml.ErrorHandler
ERROR - Unexpected error (Exception) while
load(/Users/jake/Library/Containers/com.apple.mail/Data/Library/Mail%20Downloads/00B6EBF9-B4DF-47CF-BD53-BA128E515B85/Bondale%2020191101%200903%20L2.xml)
in adaptor of type
jmri.jmrix.internal.configurexml.InternalTurnoutManagerXml Exception:
jmri.NamedBean$DuplicateSystemNameException: systemName is already
registered. Current system name: IT005. New system name: IT5
[java] See
http://jmri.org/help/en/package/jmri/configurexml/ErrorHandler.shtml
for possibly more information. [AWT-EventQueue-0]
[java] jmri.NamedBean$DuplicateSystemNameException: systemName is
already registered. Current system name: IT005. New system name: IT5
[java] at jmri.managers.AbstractManager.register(AbstractManager.java:235)
[java] at
jmri.managers.AbstractTurnoutManager.newTurnout(AbstractTurnoutManager.java:124)
[java] at
jmri.managers.ProxyTurnoutManager.makeBean(ProxyTurnoutManager.java:50)
[java] at
jmri.managers.ProxyTurnoutManager.makeBean(ProxyTurnoutManager.java:18)
[java] at
jmri.managers.AbstractProxyManager.newNamedBean(AbstractProxyManager.java:320)
[java] at
jmri.managers.ProxyTurnoutManager.newTurnout(ProxyTurnoutManager.java:114)
[java] at
jmri.managers.configurexml.AbstractTurnoutManagerConfigXML.loadTurnouts(AbstractTurnoutManagerConfigXML.java:223)
[java] at
jmri.jmrix.internal.configurexml.InternalTurnoutManagerXml.load(InternalTurnoutManagerXml.java:35)
[java] at
jmri.configurexml.ConfigXmlManager.loadOnSwingThread(ConfigXmlManager.java:658)

[java] 2019-11-22 07:12:36,208 managers.AbstractManager
ERROR - systemName is already registered. Current system name:
IT005. New system name: IT5 [AWT-EventQueue-0]
[java] 2019-11-22 07:12:36,209
nfigurexml.SingleTurnoutSignalHeadXml WARN - Failed to provide
Turnout "IT5" in loadTurnout [AWT-EventQueue-0]
[java] 2019-11-22 07:12:36,210 configurexml.ErrorHandler
ERROR - Unexpected error (Exception) while
load(/Users/jake/Library/Containers/com.apple.mail/Data/Library/Mail%20Downloads/00B6EBF9-B4DF-47CF-BD53-BA128E515B85/Bondale%2020191101%200903%20L2.xml)
in adaptor of type
jmri.managers.configurexml.AbstractSignalHeadManagerXml Exception:
java.lang.NullPointerException
[java] See
http://jmri.org/help/en/package/jmri/configurexml/ErrorHandler.shtml
for possibly more information. [AWT-EventQueue-0]
[java] java.lang.NullPointerException
[java] at
jmri.implementation.SingleTurnoutSignalHead.initialize(SingleTurnoutSignalHead.java:73)
[java] at
jmri.implementation.SingleTurnoutSignalHead.<init>(SingleTurnoutSignalHead.java:42)
[java] at
jmri.implementation.configurexml.SingleTurnoutSignalHeadXml.load(SingleTurnoutSignalHeadXml.java:108)
[java] at
jmri.managers.configurexml.AbstractNamedBeanManagerConfigXML.loadInAdapter(AbstractNamedBeanManagerConfigXML.java:439)
[java] at
jmri.managers.configurexml.AbstractSignalHeadManagerXml.loadSignalHeads(AbstractSignalHeadManagerXml.java:121)
[java] at
jmri.managers.configurexml.AbstractSignalHeadManagerXml.load(AbstractSignalHeadManagerXml.java:98)
[java] at
jmri.configurexml.ConfigXmlManager.loadOnSwingThread(ConfigXmlManager.java:658)
[java] at
jmri.configurexml.ConfigXmlManager.lambda$load$1(ConfigXmlManager.java:580)
[java] at
jmri.util.ThreadingUtil.runOnGUIwithReturn(ThreadingUtil.java:148)
[java] at
jmri.configurexml.ConfigXmlManager.load(ConfigXmlManager.java:578)
--
Bob Jacobsen
@BobJacobsen

--
Bob Jacobsen
@BobJacobsen

danielb987
 

JMRI 4.16 looked like it worked, but it didn't. The problem is that AbstractManager stores the beans in the variable _beans which is a TreeSet with a NamedBeanComparator as comparator and in the map _tsys which uses the system name as the key.

If you add the beans IT1 and IT01 to the manager in 4.16, you will have both the beans in _tsys but only one of them in _beans. So you have a bug here.

The PR #7278 ensures that the variables _beans and _tsys have the same beans. If a bean cannot be added to _beans, it will not be added to _tsys either.

So this is not about validation of input. It's about consistency between _tsys and _beans in AbstractManager.

Daniel

2019-11-22 19:10 skrev Bob Jacobsen:

Daniel, thanks for working on PRs for this.
But the more I look at it, the more I’m confused. Perhaps my memory
really is going, but I thought we’d agreed to _remove_ all the
“normalize name to correct user input errors” code so that people
would enter names and we’d use them.
Do I have that wrong and we decided to keep it?
Bob

On Nov 22, 2019, at 8:50 AM, danielb987 <db123@...> wrote:
This is due to PR #7278, Don't register a bean that already is in the manager.
PR #7655 fixes this for internal turnouts, lights and sensors.
There may be more beans that needs this fix. PR #7379 fixed this for Memory.
https://github.com/JMRI/JMRI/pull/7655
Daniel
2019-11-22 16:20 skrev Bob Jacobsen:
JMRI 4.15.7 is throwing errors with a panel file that a user had
working fine in JMRI 4.16. The relevant parts are below. The cause
is that the panel file defines and uses internal turnouts with system
names of IT5 and IT005 which are intended to be (and _always_ _have_
_been_) separate, but JMRI 4.16.7 thinks should be the same.
I know we discussed this, but apparently it wasn’t resolved the way I
remembered. I thought we’d agreed that those should remain separate,
and that there’d been a code update for that. Apparently my memory is
getting worse.
Did we actually decide they _shouldn’t_ be separate?
If not, if the new behavior is wrong and the old behavior is right,
I’ll just fix this. But I wanted to check first that I hadn’t
misunderstood some newly-emerged consensus.
Bob
[java] 2019-11-22 07:12:22,358 managers.AbstractManager
ERROR - systemName is already registered. Current system name:
IT005. New system name: IT5 [AWT-EventQueue-0]
[java] 2019-11-22 07:12:22,360 configurexml.ErrorHandler
ERROR - Unexpected error (Exception) while
load(/Users/jake/Library/Containers/com.apple.mail/Data/Library/Mail%20Downloads/00B6EBF9-B4DF-47CF-BD53-BA128E515B85/Bondale%2020191101%200903%20L2.xml)
in adaptor of type
jmri.jmrix.internal.configurexml.InternalTurnoutManagerXml Exception:
jmri.NamedBean$DuplicateSystemNameException: systemName is already
registered. Current system name: IT005. New system name: IT5
[java] See
http://jmri.org/help/en/package/jmri/configurexml/ErrorHandler.shtml
for possibly more information. [AWT-EventQueue-0]
[java] jmri.NamedBean$DuplicateSystemNameException: systemName is
already registered. Current system name: IT005. New system name: IT5
[java] at jmri.managers.AbstractManager.register(AbstractManager.java:235)
[java] at
jmri.managers.AbstractTurnoutManager.newTurnout(AbstractTurnoutManager.java:124)
[java] at
jmri.managers.ProxyTurnoutManager.makeBean(ProxyTurnoutManager.java:50)
[java] at
jmri.managers.ProxyTurnoutManager.makeBean(ProxyTurnoutManager.java:18)
[java] at
jmri.managers.AbstractProxyManager.newNamedBean(AbstractProxyManager.java:320)
[java] at
jmri.managers.ProxyTurnoutManager.newTurnout(ProxyTurnoutManager.java:114)
[java] at
jmri.managers.configurexml.AbstractTurnoutManagerConfigXML.loadTurnouts(AbstractTurnoutManagerConfigXML.java:223)
[java] at
jmri.jmrix.internal.configurexml.InternalTurnoutManagerXml.load(InternalTurnoutManagerXml.java:35)
[java] at
jmri.configurexml.ConfigXmlManager.loadOnSwingThread(ConfigXmlManager.java:658)

[java] 2019-11-22 07:12:36,208 managers.AbstractManager
ERROR - systemName is already registered. Current system name:
IT005. New system name: IT5 [AWT-EventQueue-0]
[java] 2019-11-22 07:12:36,209
nfigurexml.SingleTurnoutSignalHeadXml WARN - Failed to provide
Turnout "IT5" in loadTurnout [AWT-EventQueue-0]
[java] 2019-11-22 07:12:36,210 configurexml.ErrorHandler
ERROR - Unexpected error (Exception) while
load(/Users/jake/Library/Containers/com.apple.mail/Data/Library/Mail%20Downloads/00B6EBF9-B4DF-47CF-BD53-BA128E515B85/Bondale%2020191101%200903%20L2.xml)
in adaptor of type
jmri.managers.configurexml.AbstractSignalHeadManagerXml Exception:
java.lang.NullPointerException
[java] See
http://jmri.org/help/en/package/jmri/configurexml/ErrorHandler.shtml
for possibly more information. [AWT-EventQueue-0]
[java] java.lang.NullPointerException
[java] at
jmri.implementation.SingleTurnoutSignalHead.initialize(SingleTurnoutSignalHead.java:73)
[java] at
jmri.implementation.SingleTurnoutSignalHead.<init>(SingleTurnoutSignalHead.java:42)
[java] at
jmri.implementation.configurexml.SingleTurnoutSignalHeadXml.load(SingleTurnoutSignalHeadXml.java:108)
[java] at
jmri.managers.configurexml.AbstractNamedBeanManagerConfigXML.loadInAdapter(AbstractNamedBeanManagerConfigXML.java:439)
[java] at
jmri.managers.configurexml.AbstractSignalHeadManagerXml.loadSignalHeads(AbstractSignalHeadManagerXml.java:121)
[java] at
jmri.managers.configurexml.AbstractSignalHeadManagerXml.load(AbstractSignalHeadManagerXml.java:98)
[java] at
jmri.configurexml.ConfigXmlManager.loadOnSwingThread(ConfigXmlManager.java:658)
[java] at
jmri.configurexml.ConfigXmlManager.lambda$load$1(ConfigXmlManager.java:580)
[java] at
jmri.util.ThreadingUtil.runOnGUIwithReturn(ThreadingUtil.java:148)
[java] at
jmri.configurexml.ConfigXmlManager.load(ConfigXmlManager.java:578)
--
Bob Jacobsen
@BobJacobsen
--
Bob Jacobsen
@BobJacobsen

Ken Cameron
 

My memory of that behavior is system specific. Meaning for say NCE NT005 or
NT5 would be the same. But for something like Internal, yes IT5 and IT005
are completely different things. That's how I remember the discussion.
Somebody had found at least one other system that would see them as
different too, but I don't recall the other system.

I think the intended solution was the default would have been putting them
together as one item but known systems that would not were being given the
right method to consider them different. I recall it also went into how they
would sort too.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.org
www.syracusemodelrr.org

Bob Jacobsen
 

I agree that 4.16 looked like it worked but didn’t. I disagree on what was wrong: There never should have been an issue with _tsys and _beans in the first place.

The real cause of the problem was the effort to “clean up” input by users so that e.g. trailing spaces, extra zeros, and similar things would be “automatically corrected”. This effort failed because the advocates for it didn’t do the work to make it complete and correct. That led to lots of inconsistent behavior.

So the decision was made to remove that clean-up code. But apparently some vestigial parts were overlooked during that removal.

_That’s_ the problem, because that Bad Idea led to code that would e.g. change IT005 to IT5. _That_ _change_ wasn’t done completely and everywhere, and it caused problems. We should have removed that code, so that JMRI would again assume that if a user entered IT005 then that’s what the user meant to enter.

So the thing to be done now is to hunt down the remaining places that are changing user-entered names and remove them.

Bob


On Nov 22, 2019, at 10:29 AM, danielb987 <db123@...> wrote:

JMRI 4.16 looked like it worked, but it didn't. The problem is that AbstractManager stores the beans in the variable _beans which is a TreeSet with a NamedBeanComparator as comparator and in the map _tsys which uses the system name as the key.

If you add the beans IT1 and IT01 to the manager in 4.16, you will have both the beans in _tsys but only one of them in _beans. So you have a bug here.

The PR #7278 ensures that the variables _beans and _tsys have the same beans. If a bean cannot be added to _beans, it will not be added to _tsys either.

So this is not about validation of input. It's about consistency between _tsys and _beans in AbstractManager.

Daniel

2019-11-22 19:10 skrev Bob Jacobsen:
Daniel, thanks for working on PRs for this.
But the more I look at it, the more I’m confused. Perhaps my memory
really is going, but I thought we’d agreed to _remove_ all the
“normalize name to correct user input errors” code so that people
would enter names and we’d use them.
Do I have that wrong and we decided to keep it?
Bob
On Nov 22, 2019, at 8:50 AM, danielb987 <db123@...> wrote:
This is due to PR #7278, Don't register a bean that already is in the manager.
PR #7655 fixes this for internal turnouts, lights and sensors.
There may be more beans that needs this fix. PR #7379 fixed this for Memory.
https://github.com/JMRI/JMRI/pull/7655
Daniel
2019-11-22 16:20 skrev Bob Jacobsen:
JMRI 4.15.7 is throwing errors with a panel file that a user had
working fine in JMRI 4.16. The relevant parts are below. The cause
is that the panel file defines and uses internal turnouts with system
names of IT5 and IT005 which are intended to be (and _always_ _have_
_been_) separate, but JMRI 4.16.7 thinks should be the same.
I know we discussed this, but apparently it wasn’t resolved the way I
remembered. I thought we’d agreed that those should remain separate,
and that there’d been a code update for that. Apparently my memory is
getting worse.
Did we actually decide they _shouldn’t_ be separate?
If not, if the new behavior is wrong and the old behavior is right,
I’ll just fix this. But I wanted to check first that I hadn’t
misunderstood some newly-emerged consensus.
Bob
[java] 2019-11-22 07:12:22,358 managers.AbstractManager
ERROR - systemName is already registered. Current system name:
IT005. New system name: IT5 [AWT-EventQueue-0]
[java] 2019-11-22 07:12:22,360 configurexml.ErrorHandler
ERROR - Unexpected error (Exception) while
load(/Users/jake/Library/Containers/com.apple.mail/Data/Library/Mail%20Downloads/00B6EBF9-B4DF-47CF-BD53-BA128E515B85/Bondale%2020191101%200903%20L2.xml)
in adaptor of type
jmri.jmrix.internal.configurexml.InternalTurnoutManagerXml Exception:
jmri.NamedBean$DuplicateSystemNameException: systemName is already
registered. Current system name: IT005. New system name: IT5
[java] See
http://jmri.org/help/en/package/jmri/configurexml/ErrorHandler.shtml
for possibly more information. [AWT-EventQueue-0]
[java] jmri.NamedBean$DuplicateSystemNameException: systemName is
already registered. Current system name: IT005. New system name: IT5
[java] at jmri.managers.AbstractManager.register(AbstractManager.java:235)
[java] at
jmri.managers.AbstractTurnoutManager.newTurnout(AbstractTurnoutManager.java:124)
[java] at
jmri.managers.ProxyTurnoutManager.makeBean(ProxyTurnoutManager.java:50)
[java] at
jmri.managers.ProxyTurnoutManager.makeBean(ProxyTurnoutManager.java:18)
[java] at
jmri.managers.AbstractProxyManager.newNamedBean(AbstractProxyManager.java:320)
[java] at
jmri.managers.ProxyTurnoutManager.newTurnout(ProxyTurnoutManager.java:114)
[java] at
jmri.managers.configurexml.AbstractTurnoutManagerConfigXML.loadTurnouts(AbstractTurnoutManagerConfigXML.java:223)
[java] at
jmri.jmrix.internal.configurexml.InternalTurnoutManagerXml.load(InternalTurnoutManagerXml.java:35)
[java] at
jmri.configurexml.ConfigXmlManager.loadOnSwingThread(ConfigXmlManager.java:658)

[java] 2019-11-22 07:12:36,208 managers.AbstractManager
ERROR - systemName is already registered. Current system name:
IT005. New system name: IT5 [AWT-EventQueue-0]
[java] 2019-11-22 07:12:36,209
nfigurexml.SingleTurnoutSignalHeadXml WARN - Failed to provide
Turnout "IT5" in loadTurnout [AWT-EventQueue-0]
[java] 2019-11-22 07:12:36,210 configurexml.ErrorHandler
ERROR - Unexpected error (Exception) while
load(/Users/jake/Library/Containers/com.apple.mail/Data/Library/Mail%20Downloads/00B6EBF9-B4DF-47CF-BD53-BA128E515B85/Bondale%2020191101%200903%20L2.xml)
in adaptor of type
jmri.managers.configurexml.AbstractSignalHeadManagerXml Exception:
java.lang.NullPointerException
[java] See
http://jmri.org/help/en/package/jmri/configurexml/ErrorHandler.shtml
for possibly more information. [AWT-EventQueue-0]
[java] java.lang.NullPointerException
[java] at
jmri.implementation.SingleTurnoutSignalHead.initialize(SingleTurnoutSignalHead.java:73)
[java] at
jmri.implementation.SingleTurnoutSignalHead.<init>(SingleTurnoutSignalHead.java:42)
[java] at
jmri.implementation.configurexml.SingleTurnoutSignalHeadXml.load(SingleTurnoutSignalHeadXml.java:108)
[java] at
jmri.managers.configurexml.AbstractNamedBeanManagerConfigXML.loadInAdapter(AbstractNamedBeanManagerConfigXML.java:439)
[java] at
jmri.managers.configurexml.AbstractSignalHeadManagerXml.loadSignalHeads(AbstractSignalHeadManagerXml.java:121)
[java] at
jmri.managers.configurexml.AbstractSignalHeadManagerXml.load(AbstractSignalHeadManagerXml.java:98)
[java] at
jmri.configurexml.ConfigXmlManager.loadOnSwingThread(ConfigXmlManager.java:658)
[java] at
jmri.configurexml.ConfigXmlManager.lambda$load$1(ConfigXmlManager.java:580)
[java] at
jmri.util.ThreadingUtil.runOnGUIwithReturn(ThreadingUtil.java:148)
[java] at
jmri.configurexml.ConfigXmlManager.load(ConfigXmlManager.java:578)
--
Bob Jacobsen
@BobJacobsen
--
Bob Jacobsen
@BobJacobsen

--
Bob Jacobsen
@BobJacobsen

danielb987
 

If you want LT1 and LT0001 be different, it's very easy to fix:

AbstractNamedBean.compareSystemNameSuffix() uses an AlphanumComparator for comparision between two NamedBeans. If you replace AlphanumComparator with String.compareTo(), the problem is solved. See AbstractNamedBean, line 415.

But I understood the discussion as LT1 should be equal to LT001 since they are equal on the LocoNet.

If AbstractNamedBean.compareSystemNameSuffix() is changed to String.compareTo(), then PR #7379 and probably PR #7278 should be reverted.

Daniel

2019-11-23 01:12 skrev Bob Jacobsen:

I agree that 4.16 looked like it worked but didn’t. I disagree on what
was wrong: There never should have been an issue with _tsys and
_beans in the first place.
The real cause of the problem was the effort to “clean up” input by
users so that e.g. trailing spaces, extra zeros, and similar things
would be “automatically corrected”. This effort failed because the
advocates for it didn’t do the work to make it complete and correct.
That led to lots of inconsistent behavior.
So the decision was made to remove that clean-up code. But apparently
some vestigial parts were overlooked during that removal.
_That’s_ the problem, because that Bad Idea led to code that would
e.g. change IT005 to IT5. _That_ _change_ wasn’t done completely and
everywhere, and it caused problems. We should have removed that code,
so that JMRI would again assume that if a user entered IT005 then
that’s what the user meant to enter.
So the thing to be done now is to hunt down the remaining places that
are changing user-entered names and remove them.
Bob

On Nov 22, 2019, at 10:29 AM, danielb987 <db123@...> wrote:
JMRI 4.16 looked like it worked, but it didn't. The problem is that AbstractManager stores the beans in the variable _beans which is a TreeSet with a NamedBeanComparator as comparator and in the map _tsys which uses the system name as the key.
If you add the beans IT1 and IT01 to the manager in 4.16, you will have both the beans in _tsys but only one of them in _beans. So you have a bug here.
The PR #7278 ensures that the variables _beans and _tsys have the same beans. If a bean cannot be added to _beans, it will not be added to _tsys either.
So this is not about validation of input. It's about consistency between _tsys and _beans in AbstractManager.
Daniel
2019-11-22 19:10 skrev Bob Jacobsen:
Daniel, thanks for working on PRs for this.
But the more I look at it, the more I’m confused. Perhaps my memory
really is going, but I thought we’d agreed to _remove_ all the
“normalize name to correct user input errors” code so that people
would enter names and we’d use them.
Do I have that wrong and we decided to keep it?
Bob
On Nov 22, 2019, at 8:50 AM, danielb987 <db123@...> wrote:
This is due to PR #7278, Don't register a bean that already is in the manager.
PR #7655 fixes this for internal turnouts, lights and sensors.
There may be more beans that needs this fix. PR #7379 fixed this for Memory.
https://github.com/JMRI/JMRI/pull/7655
Daniel
2019-11-22 16:20 skrev Bob Jacobsen:
JMRI 4.15.7 is throwing errors with a panel file that a user had
working fine in JMRI 4.16. The relevant parts are below. The cause
is that the panel file defines and uses internal turnouts with system
names of IT5 and IT005 which are intended to be (and _always_ _have_
_been_) separate, but JMRI 4.16.7 thinks should be the same.
I know we discussed this, but apparently it wasn’t resolved the way I
remembered. I thought we’d agreed that those should remain separate,
and that there’d been a code update for that. Apparently my memory is
getting worse.
Did we actually decide they _shouldn’t_ be separate?
If not, if the new behavior is wrong and the old behavior is right,
I’ll just fix this. But I wanted to check first that I hadn’t
misunderstood some newly-emerged consensus.
Bob
[java] 2019-11-22 07:12:22,358 managers.AbstractManager
ERROR - systemName is already registered. Current system name:
IT005. New system name: IT5 [AWT-EventQueue-0]
[java] 2019-11-22 07:12:22,360 configurexml.ErrorHandler
ERROR - Unexpected error (Exception) while
load(/Users/jake/Library/Containers/com.apple.mail/Data/Library/Mail%20Downloads/00B6EBF9-B4DF-47CF-BD53-BA128E515B85/Bondale%2020191101%200903%20L2.xml)
in adaptor of type
jmri.jmrix.internal.configurexml.InternalTurnoutManagerXml Exception:
jmri.NamedBean$DuplicateSystemNameException: systemName is already
registered. Current system name: IT005. New system name: IT5
[java] See
http://jmri.org/help/en/package/jmri/configurexml/ErrorHandler.shtml
for possibly more information. [AWT-EventQueue-0]
[java] jmri.NamedBean$DuplicateSystemNameException: systemName is
already registered. Current system name: IT005. New system name: IT5
[java] at jmri.managers.AbstractManager.register(AbstractManager.java:235)
[java] at
jmri.managers.AbstractTurnoutManager.newTurnout(AbstractTurnoutManager.java:124)
[java] at
jmri.managers.ProxyTurnoutManager.makeBean(ProxyTurnoutManager.java:50)
[java] at
jmri.managers.ProxyTurnoutManager.makeBean(ProxyTurnoutManager.java:18)
[java] at
jmri.managers.AbstractProxyManager.newNamedBean(AbstractProxyManager.java:320)
[java] at
jmri.managers.ProxyTurnoutManager.newTurnout(ProxyTurnoutManager.java:114)
[java] at
jmri.managers.configurexml.AbstractTurnoutManagerConfigXML.loadTurnouts(AbstractTurnoutManagerConfigXML.java:223)
[java] at
jmri.jmrix.internal.configurexml.InternalTurnoutManagerXml.load(InternalTurnoutManagerXml.java:35)
[java] at
jmri.configurexml.ConfigXmlManager.loadOnSwingThread(ConfigXmlManager.java:658)

[java] 2019-11-22 07:12:36,208 managers.AbstractManager
ERROR - systemName is already registered. Current system name:
IT005. New system name: IT5 [AWT-EventQueue-0]
[java] 2019-11-22 07:12:36,209
nfigurexml.SingleTurnoutSignalHeadXml WARN - Failed to provide
Turnout "IT5" in loadTurnout [AWT-EventQueue-0]
[java] 2019-11-22 07:12:36,210 configurexml.ErrorHandler
ERROR - Unexpected error (Exception) while
load(/Users/jake/Library/Containers/com.apple.mail/Data/Library/Mail%20Downloads/00B6EBF9-B4DF-47CF-BD53-BA128E515B85/Bondale%2020191101%200903%20L2.xml)
in adaptor of type
jmri.managers.configurexml.AbstractSignalHeadManagerXml Exception:
java.lang.NullPointerException
[java] See
http://jmri.org/help/en/package/jmri/configurexml/ErrorHandler.shtml
for possibly more information. [AWT-EventQueue-0]
[java] java.lang.NullPointerException
[java] at
jmri.implementation.SingleTurnoutSignalHead.initialize(SingleTurnoutSignalHead.java:73)
[java] at
jmri.implementation.SingleTurnoutSignalHead.<init>(SingleTurnoutSignalHead.java:42)
[java] at
jmri.implementation.configurexml.SingleTurnoutSignalHeadXml.load(SingleTurnoutSignalHeadXml.java:108)
[java] at
jmri.managers.configurexml.AbstractNamedBeanManagerConfigXML.loadInAdapter(AbstractNamedBeanManagerConfigXML.java:439)
[java] at
jmri.managers.configurexml.AbstractSignalHeadManagerXml.loadSignalHeads(AbstractSignalHeadManagerXml.java:121)
[java] at
jmri.managers.configurexml.AbstractSignalHeadManagerXml.load(AbstractSignalHeadManagerXml.java:98)
[java] at
jmri.configurexml.ConfigXmlManager.loadOnSwingThread(ConfigXmlManager.java:658)
[java] at
jmri.configurexml.ConfigXmlManager.lambda$load$1(ConfigXmlManager.java:580)
[java] at
jmri.util.ThreadingUtil.runOnGUIwithReturn(ThreadingUtil.java:148)
[java] at
jmri.configurexml.ConfigXmlManager.load(ConfigXmlManager.java:578)
--
Bob Jacobsen
@BobJacobsen
--
Bob Jacobsen
@BobJacobsen
--
Bob Jacobsen
@BobJacobsen

Randall Wood
 

Assuming “L” is a LocoNet system, LT0005 and LT5 must be the same.
Assuming “I” is an Internal system, IT0005 and IT5 must be different.

I think it would be better for the Internal behavior to be the default, with the LocoNet, or other systems that are purely numeric, overriding that, since the Internal behavior is the desired behavior absent system-specific requirements.

Randall

On Nov 22, 2019, at 20:11, danielb987 <db123@...> wrote:

If you want LT1 and LT0001 be different, it's very easy to fix:

AbstractNamedBean.compareSystemNameSuffix() uses an AlphanumComparator for comparision between two NamedBeans. If you replace AlphanumComparator with String.compareTo(), the problem is solved. See AbstractNamedBean, line 415.

But I understood the discussion as LT1 should be equal to LT001 since they are equal on the LocoNet.

If AbstractNamedBean.compareSystemNameSuffix() is changed to String.compareTo(), then PR #7379 and probably PR #7278 should be reverted.

Daniel

2019-11-23 01:12 skrev Bob Jacobsen:
I agree that 4.16 looked like it worked but didn’t. I disagree on what
was wrong: There never should have been an issue with _tsys and
_beans in the first place.
The real cause of the problem was the effort to “clean up” input by
users so that e.g. trailing spaces, extra zeros, and similar things
would be “automatically corrected”. This effort failed because the
advocates for it didn’t do the work to make it complete and correct.
That led to lots of inconsistent behavior.
So the decision was made to remove that clean-up code. But apparently
some vestigial parts were overlooked during that removal.
_That’s_ the problem, because that Bad Idea led to code that would
e.g. change IT005 to IT5. _That_ _change_ wasn’t done completely and
everywhere, and it caused problems. We should have removed that code,
so that JMRI would again assume that if a user entered IT005 then
that’s what the user meant to enter.
So the thing to be done now is to hunt down the remaining places that
are changing user-entered names and remove them.
Bob
On Nov 22, 2019, at 10:29 AM, danielb987 <db123@...> wrote:
JMRI 4.16 looked like it worked, but it didn't. The problem is that AbstractManager stores the beans in the variable _beans which is a TreeSet with a NamedBeanComparator as comparator and in the map _tsys which uses the system name as the key.
If you add the beans IT1 and IT01 to the manager in 4.16, you will have both the beans in _tsys but only one of them in _beans. So you have a bug here.
The PR #7278 ensures that the variables _beans and _tsys have the same beans. If a bean cannot be added to _beans, it will not be added to _tsys either.
So this is not about validation of input. It's about consistency between _tsys and _beans in AbstractManager.
Daniel
2019-11-22 19:10 skrev Bob Jacobsen:
Daniel, thanks for working on PRs for this.
But the more I look at it, the more I’m confused. Perhaps my memory
really is going, but I thought we’d agreed to _remove_ all the
“normalize name to correct user input errors” code so that people
would enter names and we’d use them.
Do I have that wrong and we decided to keep it?
Bob
On Nov 22, 2019, at 8:50 AM, danielb987 <db123@...> wrote:
This is due to PR #7278, Don't register a bean that already is in the manager.
PR #7655 fixes this for internal turnouts, lights and sensors.
There may be more beans that needs this fix. PR #7379 fixed this for Memory.
https://github.com/JMRI/JMRI/pull/7655
Daniel
2019-11-22 16:20 skrev Bob Jacobsen:
JMRI 4.15.7 is throwing errors with a panel file that a user had
working fine in JMRI 4.16. The relevant parts are below. The cause
is that the panel file defines and uses internal turnouts with system
names of IT5 and IT005 which are intended to be (and _always_ _have_
_been_) separate, but JMRI 4.16.7 thinks should be the same.
I know we discussed this, but apparently it wasn’t resolved the way I
remembered. I thought we’d agreed that those should remain separate,
and that there’d been a code update for that. Apparently my memory is
getting worse.
Did we actually decide they _shouldn’t_ be separate?
If not, if the new behavior is wrong and the old behavior is right,
I’ll just fix this. But I wanted to check first that I hadn’t
misunderstood some newly-emerged consensus.
Bob
[java] 2019-11-22 07:12:22,358 managers.AbstractManager
ERROR - systemName is already registered. Current system name:
IT005. New system name: IT5 [AWT-EventQueue-0]
[java] 2019-11-22 07:12:22,360 configurexml.ErrorHandler
ERROR - Unexpected error (Exception) while
load(/Users/jake/Library/Containers/com.apple.mail/Data/Library/Mail%20Downloads/00B6EBF9-B4DF-47CF-BD53-BA128E515B85/Bondale%2020191101%200903%20L2.xml)
in adaptor of type
jmri.jmrix.internal.configurexml.InternalTurnoutManagerXml Exception:
jmri.NamedBean$DuplicateSystemNameException: systemName is already
registered. Current system name: IT005. New system name: IT5
[java] See
http://jmri.org/help/en/package/jmri/configurexml/ErrorHandler.shtml
for possibly more information. [AWT-EventQueue-0]
[java] jmri.NamedBean$DuplicateSystemNameException: systemName is
already registered. Current system name: IT005. New system name: IT5
[java] at jmri.managers.AbstractManager.register(AbstractManager.java:235)
[java] at
jmri.managers.AbstractTurnoutManager.newTurnout(AbstractTurnoutManager.java:124)
[java] at
jmri.managers.ProxyTurnoutManager.makeBean(ProxyTurnoutManager.java:50)
[java] at
jmri.managers.ProxyTurnoutManager.makeBean(ProxyTurnoutManager.java:18)
[java] at
jmri.managers.AbstractProxyManager.newNamedBean(AbstractProxyManager.java:320)
[java] at
jmri.managers.ProxyTurnoutManager.newTurnout(ProxyTurnoutManager.java:114)
[java] at
jmri.managers.configurexml.AbstractTurnoutManagerConfigXML.loadTurnouts(AbstractTurnoutManagerConfigXML.java:223)
[java] at
jmri.jmrix.internal.configurexml.InternalTurnoutManagerXml.load(InternalTurnoutManagerXml.java:35)
[java] at
jmri.configurexml.ConfigXmlManager.loadOnSwingThread(ConfigXmlManager.java:658)

[java] 2019-11-22 07:12:36,208 managers.AbstractManager
ERROR - systemName is already registered. Current system name:
IT005. New system name: IT5 [AWT-EventQueue-0]
[java] 2019-11-22 07:12:36,209
nfigurexml.SingleTurnoutSignalHeadXml WARN - Failed to provide
Turnout "IT5" in loadTurnout [AWT-EventQueue-0]
[java] 2019-11-22 07:12:36,210 configurexml.ErrorHandler
ERROR - Unexpected error (Exception) while
load(/Users/jake/Library/Containers/com.apple.mail/Data/Library/Mail%20Downloads/00B6EBF9-B4DF-47CF-BD53-BA128E515B85/Bondale%2020191101%200903%20L2.xml)
in adaptor of type
jmri.managers.configurexml.AbstractSignalHeadManagerXml Exception:
java.lang.NullPointerException
[java] See
http://jmri.org/help/en/package/jmri/configurexml/ErrorHandler.shtml
for possibly more information. [AWT-EventQueue-0]
[java] java.lang.NullPointerException
[java] at
jmri.implementation.SingleTurnoutSignalHead.initialize(SingleTurnoutSignalHead.java:73)
[java] at
jmri.implementation.SingleTurnoutSignalHead.<init>(SingleTurnoutSignalHead.java:42)
[java] at
jmri.implementation.configurexml.SingleTurnoutSignalHeadXml.load(SingleTurnoutSignalHeadXml.java:108)
[java] at
jmri.managers.configurexml.AbstractNamedBeanManagerConfigXML.loadInAdapter(AbstractNamedBeanManagerConfigXML.java:439)
[java] at
jmri.managers.configurexml.AbstractSignalHeadManagerXml.loadSignalHeads(AbstractSignalHeadManagerXml.java:121)
[java] at
jmri.managers.configurexml.AbstractSignalHeadManagerXml.load(AbstractSignalHeadManagerXml.java:98)
[java] at
jmri.configurexml.ConfigXmlManager.loadOnSwingThread(ConfigXmlManager.java:658)
[java] at
jmri.configurexml.ConfigXmlManager.lambda$load$1(ConfigXmlManager.java:580)
[java] at
jmri.util.ThreadingUtil.runOnGUIwithReturn(ThreadingUtil.java:148)
[java] at
jmri.configurexml.ConfigXmlManager.load(ConfigXmlManager.java:578)
--
Bob Jacobsen
@BobJacobsen
--
Bob Jacobsen
@BobJacobsen
--
Bob Jacobsen
@BobJacobsen

Ken Cameron
 

I would concur with what Daniel said, for some systems the conversion is
needed, others it should not.

Example: for LocoNet to have both a LT5 and LT005 would not work because
decoding the LocoNet traffic would only match one of them, LT5. I would not
expect the code to try against every defined entry to find other
representations by padding zeros as this example would require.

Now to support Bob's view, should the system accept LT005 for creation when
it internally, meaning on the LocoNet, would never see it that way but only
see a LT5? I would say that silently translating LT005 to LT5 on entry is
wrong and it should reject the LT005.

The examples of Internal is different. It doesn't have a physical connection
with rules outside JMRI. So there, accepting both IT5 and IT005 as two
different beans would make sense, particularly since the part past the IT
can be any set of alphanumeric characters.

I think this is pointing to the issue in some of the systems: is it allowing
you to create names that it shouldn't allow? The rules will depend on the
system in question. That is what we are uncovering.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.org
www.syracusemodelrr.org

George Warner
 

AbstractNamedBean should use the default behavior… (String.compareTo()) and the subclasses that don't allow the leading zeros override the comparator to use AlphanumComparator.
(Can that be done?)

The question then is how do you compare the names between those that do and those that don't? Answer: It doesn't matter since they'll be sorted by their prefixes (which have to be different).

I'd prefer that all the table views not revert to non-alphanumeric order. That always irritated me to no end. "LT11" does NOT come before "LT2"… ;-)

Randall Wood
 

The conversion should *not* be happening at all, ever. What should be happening is that an IllegalArgumentException should be thrown if an illegal name is used.

(This is a correction on my earlier statement.)

So LT0005 (LocoNet) should be rejected, while LT5 should be accepted. Both IT0005 (Internal) and IT5 should be accepted and be treated as different turnouts.

The SystemNameValidator can be attached to text boxes and the NamedBeanComboBox used for ComboBoxes that allow system names to be input since they will use the system’s rules for creating valid system names and displaying why names have been rejected.

Randall

On Nov 23, 2019, at 11:10, George Warner via Groups.Io <geowar1@...> wrote:

AbstractNamedBean should use the default behavior… (String.compareTo()) and the subclasses that don't allow the leading zeros override the comparator to use AlphanumComparator.
(Can that be done?)

The question then is how do you compare the names between those that do and those that don't? Answer: It doesn't matter since they'll be sorted by their prefixes (which have to be different).

I'd prefer that all the table views not revert to non-alphanumeric order. That always irritated me to no end. "LT11" does NOT come before "LT2"… ;-)