glassfish
  1. glassfish
  2. GLASSFISH-15293

Cannot deploy MDB to remote server at 3.1

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Incomplete
    • Affects Version/s: 3.1_b33
    • Fix Version/s: None
    • Component/s: deployment
    • Labels:
      None

      Description

      I am trying to run the Java EE Tutorial JMS example sendremote, described in http://download.oracle.com/javaee/6/tutorial/doc/bnchx.html and available by checking out the examples from http://javaeetutorial.java.net. This example deploys a message-driven bean on two different GlassFish servers. This example has worked in previous versions of GlassFish up through 3.0.1.

      I have a connection factory that has the AddressList property set to the name of the remote system.

      I am using GlassFish 3.1 promoted b33.

      Previously, in addition to creating the connection factory, I had to change the name of the default JMS host from localhost to either 0.0.0.0 or the name of the remote system (this was new with GF v3). Do I have to do something else now?

      Now when I try to deploy the bean to the remote server I get an error 403:

      deploy:
      [exec] HTTP connection failed with code 403, message: Forbidden
      [exec] Command deploy failed.

      Does the remote server now have some sort of security setting that I need to change? Or is this a bug?

      This tutorial example must work on GF 3.1.

        Activity

        Hide
        Tim Quinn added a comment -

        Kim,

        A security requirement imposed on 3.1 prohibits us from allowing remote access to the DAS out of the box. You can run asadmin from the same host as the DAS to avoid this restriction.

        Or, you can

        1. Start the domain.
        2. Run

        asadmin enable-secure-admin

        3. Restart the domain.

        Then you can use asadmin remotely.

        I will close this as incomplete. If you encounter further problems when you either run locally or enable-secure-admin and run remotely, please re-open the issue.

        Show
        Tim Quinn added a comment - Kim, A security requirement imposed on 3.1 prohibits us from allowing remote access to the DAS out of the box. You can run asadmin from the same host as the DAS to avoid this restriction. Or, you can 1. Start the domain. 2. Run asadmin enable-secure-admin 3. Restart the domain. Then you can use asadmin remotely. I will close this as incomplete. If you encounter further problems when you either run locally or enable-secure-admin and run remotely, please re-open the issue.
        Hide
        Kim Haase added a comment -

        Thank you, Tim! That worked for deployment – one more instruction to add to the tutorial.

        I'm getting a weird error running appclient, though. I have not tried to run it on Windows before, only Solaris. I will look through acc issues and see if this is a known one.

        ...
        [exec] _JAVACMD=D:\jdk1.6.0_22\bin\java.exe
        [exec] _USE_CLASSPATH=yes
        [exec] 'javaCmd' is not recognized as an internal or external command,
        [exec] operable program or batch file.
        [exec] Result: 1

        Show
        Kim Haase added a comment - Thank you, Tim! That worked for deployment – one more instruction to add to the tutorial. I'm getting a weird error running appclient, though. I have not tried to run it on Windows before, only Solaris. I will look through acc issues and see if this is a known one. ... [exec] _JAVACMD=D:\jdk1.6.0_22\bin\java.exe [exec] _USE_CLASSPATH=yes [exec] 'javaCmd' is not recognized as an internal or external command, [exec] operable program or batch file. [exec] Result: 1
        Hide
        Tim Quinn added a comment -

        Hi, Kim.

        That javaCmd error is a bug (15259) in the Windows appclient script. I've already fixed it and checked in the fix. It should be in the nightly builds since Dec. 18.

        Show
        Tim Quinn added a comment - Hi, Kim. That javaCmd error is a bug (15259) in the Windows appclient script. I've already fixed it and checked in the fix. It should be in the nightly builds since Dec. 18.
        Hide
        Kim Haase added a comment -

        Thank you, Tim!

        With the 12/21 b34 the remote deployment worked, AND the client ran fine as well.

        Show
        Kim Haase added a comment - Thank you, Tim! With the 12/21 b34 the remote deployment worked, AND the client ran fine as well.

          People

          • Assignee:
            Hong Zhang
            Reporter:
            Kim Haase
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: