0 Replies Latest reply on Sep 6, 2006 5:43 AM by Ralf Torsten Menche

    Avoid changes in JBoss installation directory using symlinks

    Ralf Torsten Menche Newbie


      We want to set up JBoss AS in a multi-user Solaris 10 environment in such a way that no modifications are necessary within the JBoss installation itself. I.e. we do not want to place the users' server configurations in $JBOSS_HOME/server.

      In our opinion there are (at least) three good reasons for this approach:

      1) It keeps a clear separation between the JBoss AS installation and our own applications.

      2) It avoids granting write permissions for the JBoss installation to the users.

      3) It eases the switching between several JBoss releases.

      Our first solution approach replaced the server configuration directories by symbolic links to the actual directories. E.g.:

      ln -s $APP1_HOME/server/app1 $JBOSS_HOME/server/

      This works and allows starting the application as if it were physically in the $JBOSS_HOME/server directory:

      $JBOSS_HOME/bin/run.sh -c app1

      But it still requires write permissions to create the symlinks.

      What we would prefer is having the symlinks going in the opposite direction. Let's call the original JBoss installation directory $JBOSS_INSTALL_HOME.

      ln -s $JBOSS_INSTALL_HOME/bin $APP1_HOME/
      ln -s $JBOSS_INSTALL_HOME/lib $APP1_HOME/
      mkdir $APP1_HOME/server

      The user's application is placed in $APP1_HOME/server and started with ($JBOSS_HOME is now pointing to $APP1_HOME):

      $JBOSS_HOME/bin/run.sh -c app1

      Unfortunately, this does not work as expected. JBoss aborts with a message that it can't find jboss-service.xml:

      Failed to boot JBoss:
      org.jboss.deployment.DeploymentException: url file:$JBOSS_INSTALL_HOME/server/app1/conf/jboss-service.xml could not be opened, does it exist?

      Obviously, JBoss is looking for the file in the physical directory structure ($JBOSS_INSTALL_HOME) and not in the logical structure ($JBOSS_HOME aka $APP1_HOME).

      Does anybody know whether this is a bug or works as designed? It might even be specific to Solaris 10, where there seems to be a similar effect when cd'ing along a symbolic link and then spawning a new ksh. Whereas the parent ksh shows the symlink in the pwd, the child shell shows the physical directory.

      Any help welcome.