Details
-
Bug
-
Resolution: Fixed
-
Medium
-
2.5.5
-
None
-
jboss420
-
6
-
Description
I had this problem when I was using osuser.xml, and fixed it by adding the java.naming.referral=follow as a property in the XML. Recently I was made aware that atlassian-user.xml is the replacement for osuser.xml. Strange then, that I cannot set arbitrary properties as I could with osuser.xml, so the solution applied to osuser.xml no longer works. There is no current way to include a new attribute for the environement, such as for the java.naming.referral flag.
I've raised this through support, the advice is to supply -D java.naming.referral=follow through the command line to the application server. This should work, if the InitialContext is created from a combination of system environment and atlassian-user.xml content, but this doesn't appear to be the case (I just tried). I'm open to other suggestions.
My reported environment from jboss startup was:
JAVA_OPTS: -Dprogram.name=runNode2.sh -server -Djavax.net.ssl.trustStore=/etc/ssl/my_keystore.jks -Djavax.net.ssl.trustStorePassword=stuff -Dcom.sun.management.jmxremote -Djava.naming.referral=follow -Xrunjdwp:transport=dt_socket,address=8701,server=y,suspend=n -Djava.awt.headless=true -XX:MaxPermSize=256m -XX:PermSize=256m -Xms128m -Xmx512m -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true
JIRA has this fixed. I'm asking for confluence to support this through atlassian-user.xml, it seems strange that as a 'future' configuration its missing this.
As a result every auth lookup generates a stack, I cannot seem to edit user groups, which is a pretty big problem.
Workaround is to go back to osuser.xml ?