Peter Johnson wrote:Mark, welcome to Java Ranch!
Here is what I would do.
First, I would ascertain that the user made the exact same changes I made - check the web.xml, jboss-web.xml file, and make sure no changes in login-config.xml.
Peter Johnson wrote:Second, I would have them temporarily run JBoss AS from a command line (not as a service). If this works (login to jmx-console works), then there is some issue with the service configuration or the user under which the service is running. Perhaps if you turn on file access logging in Windows for the conf direcotory and its subdirectories then you might see something in the Windows security logs. Another possibility is to use Process Monitor from sysinternals and monitor what it see for file access.
Peter Johnson wrote:If none of this yields any help, I would get the JBoss AS source and add some debugging code to security/src/main/org/jboss/security/auth/spi/UsersRolesLoginModule.java, specifically to print out what it thought it was opening.
[rant]This problem illustrates one of my pet peeves which is Java developers failing to tell you exactly what data they were using when something failed. Having UsersRolesLoginModule include the full path name for the file in question as part of the error message would have made debugging this issue much simpler.[/rant]
Digging through the source (I'm looking at 4.0.5, hope that 4.0.1 is not that different), there is a utility class that takes two properties file names - a default and a given one, so it appears that the error message for the IOException is based on the default file, whcih is users.properties. But I noticed that if you turn on trace logging the Util class will tell you which file it is attempting to open. So add this to server/xxx/conf/log4j.xml:
You should then see which properties files are loaded, and the users and roles loaded.