glassfish
  1. glassfish
  2. GLASSFISH-13518

asadmin deploy won't come back when mistakenly specifying dir name

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.1
    • Fix Version/s: future release
    • Component/s: deployment
    • Labels:
      None
    • Environment:

      Operating System: Windows XP
      Platform: All

    • Issuezilla Id:
      13,518

      Description

      I accidentally passed a directory name instead of a file name to asadmin deploy.
      The hard disk's been grinding for 10 minutes but the command is not coming back.
      Also no messages in server.log. GF is being very unforgiving..

      D:\GFv3.1\glassfish-3.1-b21-09_17_2010\glassfishv3>bin\asadmin deploy \

        Activity

        Hide
        Hong Zhang added a comment -

        I have provided this feedback to the doc team and now the latest 3.1 man page (not published officially yet) has reflected this change.

        I am not sure how easy it is to decide what directories and the depth that we should scan by default: libraries could be at random places and referenced through manifest, class files could be located in a deep directory layout. I am going to mark this issue as an enhancement now and see if there is anything we can do in the future release.

        Show
        Hong Zhang added a comment - I have provided this feedback to the doc team and now the latest 3.1 man page (not published officially yet) has reflected this change. I am not sure how easy it is to decide what directories and the depth that we should scan by default: libraries could be at random places and referenced through manifest, class files could be located in a deep directory layout. I am going to mark this issue as an enhancement now and see if there is anything we can do in the future release.
        Hide
        Hong Zhang added a comment -

        scrubbing issues

        Show
        Hong Zhang added a comment - scrubbing issues
        Hide
        Dies Koper added a comment -

        Could you close it after addressing the issues I brought up?

        1. The man page is wrong. Closing this issue won't fix it.

        2. I understand you want to merge 'deploydir' into the 'deploy' command and
        therefore need to scan library jars. But scanning all subdirectories without
        warning can be very annoying. I think it's better to add a '--recursive' option
        and let the user explicitly express their wish to go into all subdirectories
        when they want it to. Default (no option) would be to only check the specified
        dir (or relevant dirs, like ./WEB-INF/lib, etc.)

        Show
        Dies Koper added a comment - Could you close it after addressing the issues I brought up? 1. The man page is wrong. Closing this issue won't fix it. 2. I understand you want to merge 'deploydir' into the 'deploy' command and therefore need to scan library jars. But scanning all subdirectories without warning can be very annoying. I think it's better to add a '--recursive' option and let the user explicitly express their wish to go into all subdirectories when they want it to. Default (no option) would be to only check the specified dir (or relevant dirs, like ./WEB-INF/lib, etc.)
        Hide
        Hong Zhang added a comment -

        dies: Are you ok for me to close this issue? As I said in my previous comments,
        we do need to go to the sub directories to process sub modules and scan library
        jars to scan for annotations.

        Show
        Hong Zhang added a comment - dies: Are you ok for me to close this issue? As I said in my previous comments, we do need to go to the sub directories to process sub modules and scan library jars to scan for annotations.
        Hide
        Hong Zhang added a comment -

        If the man page says it can only take a file, it needs to be updated to say
        take both file and directory. The deploydir command is deprecated and the
        deploy command is the one that should be used for both file and directory.
        About going into sub directories: yes, the logic does go to the sub directories
        to scan for component annotations. For ear case, the sub modules are in the sub
        directories. And the component jars could be come in the form of a library jar
        too, for example in WEB-INF/lib for ejb in war case.

        Show
        Hong Zhang added a comment - If the man page says it can only take a file, it needs to be updated to say take both file and directory. The deploydir command is deprecated and the deploy command is the one that should be used for both file and directory. About going into sub directories: yes, the logic does go to the sub directories to scan for component annotations. For ear case, the sub modules are in the sub directories. And the component jars could be come in the form of a library jar too, for example in WEB-INF/lib for ejb in war case.
        Hide
        Dies Koper added a comment -

        I've never accidentally packaged the whole root directory and tried deploying it
        but I have confirmed that with an empty sub-directory it comes back quickly.

        So I'm not sure what is the root issue here.
        The man pages say the operand is a file, not a directory, so if the man pages
        are correct it could just check whether a file or directory was specified and
        return an error immediately.

        If the man pages are wrong, and it is supposed to traverse all subdirectories
        searching for applications, then that's an issue by itself. Most Unix but also
        Windows commands don't recursively go into each subdirectory unless some
        recursive option has been explicitly specified. GF should operate the same.

        In my case I tried to specify an application by using tab completion (and who
        doesn't) and it picked a directory instead (note that on Windows it picks the
        first match and you can cycle through the candidates by pressing tab again).
        When this happened to me I didn't actually deploy '\' but still the
        sub-directory that was picked had enough files for asadmin to become unresponsive.

        Show
        Dies Koper added a comment - I've never accidentally packaged the whole root directory and tried deploying it but I have confirmed that with an empty sub-directory it comes back quickly. So I'm not sure what is the root issue here. The man pages say the operand is a file, not a directory, so if the man pages are correct it could just check whether a file or directory was specified and return an error immediately. If the man pages are wrong, and it is supposed to traverse all subdirectories searching for applications, then that's an issue by itself. Most Unix but also Windows commands don't recursively go into each subdirectory unless some recursive option has been explicitly specified. GF should operate the same. In my case I tried to specify an application by using tab completion (and who doesn't) and it picked a directory instead (note that on Windows it picks the first match and you can cycle through the candidates by pressing tab again). When this happened to me I didn't actually deploy '\' but still the sub-directory that was picked had enough files for asadmin to become unresponsive.
        Hide
        Hong Zhang added a comment -

        Dies: it's not so much of archive vs directory which makes the disk grinding,
        it's more of the directory got passed in is the root path "\"!. So it's trying
        to scan the whole root directory to see if it finds a JavaEE component jar
        through annotation scanning. If you package the whole root directory into a
        giant jar file, it will take just as much time.

        Try to pass a small sub directory with not many files in it, and see how much
        time before it returns.

        Show
        Hong Zhang added a comment - Dies: it's not so much of archive vs directory which makes the disk grinding, it's more of the directory got passed in is the root path "\"!. So it's trying to scan the whole root directory to see if it finds a JavaEE component jar through annotation scanning. If you package the whole root directory into a giant jar file, it will take just as much time. Try to pass a small sub directory with not many files in it, and see how much time before it returns.

          People

          • Assignee:
            Hong Zhang
            Reporter:
            Dies Koper
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: