WildFly 10.0.0.Final WFLYDM0021: No java.io.Console available to interact with user

[bmiddleb]

First experience with WildFly and the first task in the Getting Started fails. Not such a good first impression. It sort of begs the question of how well this is tested.

[17:42:37] [/cygdrive/c/dev/newEnv/wildfly-10.0.0.Final/bin] [1245] [master] $ ./add-user.sh

++ dirname ./add-user.sh

+ DIRNAME=.

+ cygwin=false

++ uname

++ grep -i CYGWIN

+ '[' CYGWIN_NT-6.3 ']'

+ cygwin=true

+ true

+ '[' -n '' ']'

+ '[' -n 'C:\Program Files\Java\jre1.8.0_91' ']'

++ cygpath --unix 'C:\Program Files\Java\jre1.8.0_91'

+ JAVA_HOME='/cygdrive/c/Program Files/Java/jre1.8.0_91'

+ '[' -n '' ']'

++ cd ./..

++ pwd

+ RESOLVED_JBOSS_HOME=/cygdrive/c/dev/newEnv/wildfly-10.0.0.Final

+ '[' x = x ']'

+ JBOSS_HOME=/cygdrive/c/dev/newEnv/wildfly-10.0.0.Final

+ export JBOSS_HOME

+ '[' x = x ']'

+ '[' 'x/cygdrive/c/Program Files/Java/jre1.8.0_91' '!=' x ']'

+ JAVA='/cygdrive/c/Program Files/Java/jre1.8.0_91/bin/java'

+ '[' x = x ']'

+ JBOSS_MODULEPATH=/cygdrive/c/dev/newEnv/wildfly-10.0.0.Final/modules

+ true

++ cygpath --path --windows /cygdrive/c/dev/newEnv/wildfly-10.0.0.Final

+ JBOSS_HOME='C:\dev\newEnv\wildfly-10.0.0.Final'

++ cygpath --path --windows '/cygdrive/c/Program Files/Java/jre1.8.0_91'

+ JAVA_HOME='C:\Program Files\Java\jre1.8.0_91'

++ cygpath --path --windows /cygdrive/c/dev/newEnv/wildfly-10.0.0.Final/modules

+ JBOSS_MODULEPATH='C:\dev\newEnv\wildfly-10.0.0.Final\modules'

+ JAVA_OPTS=

+ eval '"/cygdrive/c/Program' 'Files/Java/jre1.8.0_91/bin/java"' -jar '"C:\dev\newEnv\wildfly-10.0.0.Final/jboss-modules.jar"' -mp '"C:\dev\newEnv\wildfly-10.0.0.Final\modules"' org.jboss.as.domain-add-user '"$@"'

++ '/cygdrive/c/Program Files/Java/jre1.8.0_91/bin/java' -jar 'C:\dev\newEnv\wildfly-10.0.0.Final/jboss-modules.jar' -mp 'C:\dev\newEnv\wildfly-10.0.0.Final\modules' org.jboss.as.domain-add-user

Exception in thread "main" java.lang.IllegalStateException: WFLYDM0021: No java.io.Console available to interact with user.

        at org.jboss.as.domain.management.security.adduser.AddUser.<init>(AddUser.java:78)

        at org.jboss.as.domain.management.security.adduser.AddUser.main(AddUser.java:232)

        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

        at java.lang.reflect.Method.invoke(Unknown Source)

        at org.jboss.modules.Module.run(Module.java:329)

        at org.jboss.modules.Main.main(Main.java:507)

This was listed as a bug in 2013.

Any idea how to resolve it?

I don't really want to have to switch to a win console every time I need to run an admin command.

[bmiddleb]

Does anyone from JBoss monitor these forums?

[nickarls]

I have found that it mostly works just fine, I'm not sure what priority running under cygwin has and what statements have been made regarding it. Are you talking about Bug 1027165 – add-user.sh requires console output ? That one talking something about a -s switch. There are several JBoss-employees around here, actually more than in most OS-projects where they have a tendency to disappear after a while as the project matures.

[bmiddleb]

I think there are 3 issues:

1. add-user.sh doesn't work in cygwin
2. the bug you referenced says it is fixed back in 2014, but it isn't
3. if the workaround "-s" is the solution, then the documentation does not contain this key piece of information

The result is

• a lot of developers are going to waste time unnecessarily
• it creates a barrier for adopting WildFly
• it calls into question the stability and quality of WildFly and TF damages your company's credibility when the first action you take in "Getting Started" doesn't work

Given the simple solution of adding the workaround to the documentation, I'm puzzled why JBoss hasn't take care of it. Was this just not a priority for them because they considered cygwin a one-off not worth the effort?

[nickarls]

Well, I can't speak for RedHat but since a search of the forums with the error message reveals that you represent 50% of the people having asked that question, it would suggest that using cygwin is not all that common. ;-)

Also, since I don't think any guarantees of compatibility is given for cygwin, it's a bit unfair to call WF broken if there are issues with said environment. I would suggest opening a JIRA if there isn't one already.

BTW, it was a little unclear if the -s worked or not(?)

[jamezp]

It's actually quite well tested by users on OS X, Linux (various flavors) and Windows. I don't know how many of the Windows users use cygwin. I'm guessing not many. If you file an issue I'm sure this could be fixed.

Do note that Windows users are only a portion of the users of WildFly. Within that portion would be the portion that uses cygwin. Not every environment can be tested especially when tests like this would likely be manual.

--

James R. Perkins

[bmiddleb]

Well, that's a very good point especially since Windows 10 has Linux bash compatibility. Soon, only developers whose companies are too cheap to buy Macs or those who have resisted upgrading to 10 will be using cygwin.

Objections withdrawn.