Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: V3
    • Fix Version/s: not determined
    • Component/s: installation
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      6,784

      Description

      Batches are common in the UNIX world and had been popular in the DOS world, too.
      But in the Windows world, batches are something administrators don't like: The
      chance is just too high that they break. The reason is that the batch language
      is not well suited for exceptions. Batches are potentially instable. Also when
      running they open that ugly DOS BOX, which nobody wants to see and (worse!)
      could break using CTRL-BREAK (with undeterministic result, depending on the
      currently executed command within the batch). And worse, the batch language
      itself has several differences between the Windows versions...

      On Windows it is typical to have an EXE file. In the Java world it is typical to
      have a JAR file. Both can be supplied with excellent exception handling and can
      optionally run without showing any UI.

      So it would be really great if there would be no batches but EXE or JAR files
      that drive the command line interface. I do not see anything in the batch that
      can be done in a batch but not in a JAR file. Since we are in the Java universe
      let's use Java.

        Activity

        Hide
        mkarg added a comment -

        This is an enhancement but not a bug.

        Show
        mkarg added a comment - This is an enhancement but not a bug.
        Hide
        Bill Shannon added a comment -

        I assume this is a request to have a way to start the server without using
        the asadmin.bat batch file on Windows?

        Presumably when typing commands in a command window it's fine to use the
        asadmin.bat batch file?

        We're unlikely to provide a native asadmin.exe to replace asadmin.bat,
        and the Windows jar file integration makes it unsuitable for command line
        use, although we could consider a jar file to start the default domain.

        Show
        Bill Shannon added a comment - I assume this is a request to have a way to start the server without using the asadmin.bat batch file on Windows? Presumably when typing commands in a command window it's fine to use the asadmin.bat batch file? We're unlikely to provide a native asadmin.exe to replace asadmin.bat, and the Windows jar file integration makes it unsuitable for command line use, although we could consider a jar file to start the default domain.
        Hide
        mkarg added a comment -

        Please check again my original proposal. I wrote that there is no need for a
        batch since all it does can be written in plain old Java. So my proposal
        actually is to replace the platform dependent batches by executable JARs.

        See, Windows people will accept EXE or JAR. If you don't like to provide EXE
        then provide JAR. But don't force them to use Batches. This is just not good
        style in the Windows universe.

        Show
        mkarg added a comment - Please check again my original proposal. I wrote that there is no need for a batch since all it does can be written in plain old Java. So my proposal actually is to replace the platform dependent batches by executable JARs. See, Windows people will accept EXE or JAR. If you don't like to provide EXE then provide JAR. But don't force them to use Batches. This is just not good style in the Windows universe.
        Hide
        janey added a comment -

        Reassign to Bill.

        Show
        janey added a comment - Reassign to Bill.
        Hide
        Byron Nevins added a comment -

        What exactly is the gist of this? What batch file do you want to replace?

        Scripts are directly editable and very very easy for an end-user to modify.
        Java jars are binary and are a much much bigger deal for an end-user to change.

        What if you want to run the java program with -Xmx1024 - how are you going to do
        that? What about the -Xrs option? Without that option GF running as a service
        will stop the moment you logout.

        If asadmin is the complaint – you can run it as a jar right now like so:

        java -jar modules\admin-cli.jar some-command some-arg ...

        ???

        Show
        Byron Nevins added a comment - What exactly is the gist of this? What batch file do you want to replace? Scripts are directly editable and very very easy for an end-user to modify. Java jars are binary and are a much much bigger deal for an end-user to change. What if you want to run the java program with -Xmx1024 - how are you going to do that? What about the -Xrs option? Without that option GF running as a service will stop the moment you logout. If asadmin is the complaint – you can run it as a jar right now like so: java -jar modules\admin-cli.jar some-command some-arg ... ???
        Hide
        Byron Nevins added a comment -

        I just downloaded and installed V3 via the official installer.

        If that is what you are talking about – I agree. The shortcuts are flaky.
        They start up a temporary DOS box that is minimized. I didn't notice so I
        double-clicked twice and ended up with 2 running instances of V3!

        This could be improved. There are ways to run without a visible DOS box I believe.

        Reassigning to installer

        Show
        Byron Nevins added a comment - I just downloaded and installed V3 via the official installer. If that is what you are talking about – I agree. The shortcuts are flaky. They start up a temporary DOS box that is minimized. I didn't notice so I double-clicked twice and ended up with 2 running instances of V3! This could be improved. There are ways to run without a visible DOS box I believe. Reassigning to installer
        Hide
        Byron Nevins added a comment -

        .

        Show
        Byron Nevins added a comment - .
        Hide
        mkarg added a comment -

        One must understand that each platform has its standards for how things have to
        work like. On UNIX, this is using batches for configuration, installation,
        startup und daemon control. On Windows it it not. On Windows, Microsoft is
        providing different binary APIs for that. So a program that likes to get
        accepted by Windows users, or even more wants to apply for a "Windows Logo"
        certification, must not use batches for anything but instead utilize that
        different APIs.

        The reason is that using the APIs much better integrates the application into
        the overall Windows environment. It does "feel" like Windows when using their
        style, while it feels "strange" to see a script run. Also using their style
        provides MUCH improved stability. For example, their service API is unparallel
        and gives Windows much better control of a service's current state than any
        script on UNIX will give on daemons. Windows knows exactly in what state a
        service really is, whether it is shutting down actually or asks for more time
        while doing that and so on. Batches cannot provide this information. But it is
        not only about services, it is much more about stability in general.

        Microsoft clearly defines that configuration information is to be stored in the
        registry. So if you like to configure RAM or other options, this must be stored
        in registry. It gets there using a GUI, and the program will pick it from there
        using a binary API. The customer shall never fumble around with editing
        scripts. Why? Because he likely will break the script by incident.

        To sum up, Windows has a completely different design regarding the complete
        life cycle control of a service. Batches are far beyond what Windows wants and
        feels to Windows users like "stone age applications", but not
        like "professional services provided by people that understand makes a program
        a REAL windows program".

        Show
        mkarg added a comment - One must understand that each platform has its standards for how things have to work like. On UNIX, this is using batches for configuration, installation, startup und daemon control. On Windows it it not. On Windows, Microsoft is providing different binary APIs for that. So a program that likes to get accepted by Windows users, or even more wants to apply for a "Windows Logo" certification, must not use batches for anything but instead utilize that different APIs. The reason is that using the APIs much better integrates the application into the overall Windows environment. It does "feel" like Windows when using their style, while it feels "strange" to see a script run. Also using their style provides MUCH improved stability. For example, their service API is unparallel and gives Windows much better control of a service's current state than any script on UNIX will give on daemons. Windows knows exactly in what state a service really is, whether it is shutting down actually or asks for more time while doing that and so on. Batches cannot provide this information. But it is not only about services, it is much more about stability in general. Microsoft clearly defines that configuration information is to be stored in the registry. So if you like to configure RAM or other options, this must be stored in registry. It gets there using a GUI, and the program will pick it from there using a binary API. The customer shall never fumble around with editing scripts. Why? Because he likely will break the script by incident. To sum up, Windows has a completely different design regarding the complete life cycle control of a service. Batches are far beyond what Windows wants and feels to Windows users like "stone age applications", but not like "professional services provided by people that understand makes a program a REAL windows program".
        Hide
        Bill Shannon added a comment -

        Really reassign.

        If there's a way we can write a Java program that avoids bringing up a
        Command window, we should consider that.

        If the only solution is to write native Windows code, we should close
        this bug.

        Show
        Bill Shannon added a comment - Really reassign. If there's a way we can write a Java program that avoids bringing up a Command window, we should consider that. If the only solution is to write native Windows code, we should close this bug.
        Hide
        mkarg added a comment -

        To make it more clear: It's less a problem that window is shown (native Windows
        applications also shows windows, hence the name of the operating system ),
        but more a problem of using batches. Batches are likely to break. Why not
        writing a simple executable JAR file containing a main-class entry which pulls
        configuration from registry using Preferences API? That would be 100% pure Java
        AND would fulfil the constraint that configuration must not be found in
        batches. It would be more accepted by Windows users from their point of view,
        and it would be able to run on ANY operating system, while a batch obviously
        will only run on some.

        Show
        mkarg added a comment - To make it more clear: It's less a problem that window is shown (native Windows applications also shows windows, hence the name of the operating system ), but more a problem of using batches. Batches are likely to break. Why not writing a simple executable JAR file containing a main-class entry which pulls configuration from registry using Preferences API? That would be 100% pure Java AND would fulfil the constraint that configuration must not be found in batches. It would be more accepted by Windows users from their point of view, and it would be able to run on ANY operating system, while a batch obviously will only run on some.
        Hide
        Byron Nevins added a comment -

        I'm starting to get a little bit lost. The discussion is too abstract. What
        specifically are you talking about? Is it that "asadmin.bat" even exists? Or
        is it that the installer provides these clunky little scripts that start and
        stop the server?

        In the former case, we are providing a service to users. Asadmin is a **command
        line tool**. It is supposed to be used in a "DOS box". We provide a fully
        featured GUI as well – the Admin GUI normally found at localhost:4848. Asadmin
        allows you to easily do things like run JDK6 for V3 and run JDK5 for other
        things, etc.

        This is analogous to what Microsoft does. E.g. managing Services
        GUI: "Rt-Click My Computer/Manage/Services&Applications/Services"
        Command Line: sc

        You can run "asadmin" easily without a batch file. Simply run it like so – no
        batch involved:

        C:\Users\bnevins>java -jar e:\glassfishv3\glassfish\modules\admin-cli.jar
        start-domain
        Waiting for DAS to start .............
        Started domain: domain1
        Domain location: E:\glassfishv3\glassfish\domains\domain1
        Log file: E:\glassfishv3\glassfish\domains\domain1\logs\server.log
        Admin port for the domain: 4848
        Command start-domain executed successfully.

        Show
        Byron Nevins added a comment - I'm starting to get a little bit lost. The discussion is too abstract. What specifically are you talking about? Is it that "asadmin.bat" even exists? Or is it that the installer provides these clunky little scripts that start and stop the server? In the former case, we are providing a service to users. Asadmin is a **command line tool**. It is supposed to be used in a "DOS box". We provide a fully featured GUI as well – the Admin GUI normally found at localhost:4848. Asadmin allows you to easily do things like run JDK6 for V3 and run JDK5 for other things, etc. This is analogous to what Microsoft does. E.g. managing Services GUI: "Rt-Click My Computer/Manage/Services&Applications/Services" Command Line: sc You can run "asadmin" easily without a batch file. Simply run it like so – no batch involved: C:\Users\bnevins>java -jar e:\glassfishv3\glassfish\modules\admin-cli.jar start-domain Waiting for DAS to start ............. Started domain: domain1 Domain location: E:\glassfishv3\glassfish\domains\domain1 Log file: E:\glassfishv3\glassfish\domains\domain1\logs\server.log Admin port for the domain: 4848 Command start-domain executed successfully.
        Hide
        Byron Nevins added a comment -

        Here is a link that describes how to run a script with no window...

        http://tinyurl.com/6bbe3d

        Show
        Byron Nevins added a comment - Here is a link that describes how to run a script with no window... http://tinyurl.com/6bbe3d
        Hide
        mkarg added a comment -

        It is ok to have CLI tools, but this is not about the form of tool but about
        the form of implementation: Batch files vs. standalone binaries.

        It's not about one particular batch file, it is about using batch files at all.
        Most distracting is applient.bat and asadmin.bat being batch files, but
        certainly every other batch falls into the same category.

        I never said that microsoft does not use CLI tools or batches on their own, but
        that it is uncommon. The fact that microsoft provides one doesn't make it more
        common tot he average Windows user or administrator, and doesn't change their
        own logo criteria.

        The main problem is that a batch can break. The fact that it showns a DOS box
        is just an unwanted (and correctable) side effect.

        And: There is a big difference between a real Windows service and wrapping
        something behaving LIKE a service (read the Windows service API to get an
        understanding of the difference – GF just supports SOME of the needed events,
        while Windows users expect ALL to be supported). Lots of threads in this forum
        are based solely on the fact that GF does not work like a "real" service, but
        just comes with a service that controls GF. That problems will be gone as soon
        as you understand that you must not somehow wrap Java to make it look like
        Windows, but that you must start do DESIGN FOR Windows to make people happy.
        That IS possible in Java, and it does not necessarily break compatibility with
        other platforms. But you need to learn how to do it and you then must do it.
        Otherwise it will always feal like a "impurity" on Windows.

        We lost several customers since they where unhappy with the "strange" felling
        of GF, actually, and all we ask for is just to get rid of batches in the first
        place. Is that so non-understandable?

        Show
        mkarg added a comment - It is ok to have CLI tools, but this is not about the form of tool but about the form of implementation: Batch files vs. standalone binaries. It's not about one particular batch file, it is about using batch files at all. Most distracting is applient.bat and asadmin.bat being batch files, but certainly every other batch falls into the same category. I never said that microsoft does not use CLI tools or batches on their own, but that it is uncommon. The fact that microsoft provides one doesn't make it more common tot he average Windows user or administrator, and doesn't change their own logo criteria. The main problem is that a batch can break. The fact that it showns a DOS box is just an unwanted (and correctable) side effect. And: There is a big difference between a real Windows service and wrapping something behaving LIKE a service (read the Windows service API to get an understanding of the difference – GF just supports SOME of the needed events, while Windows users expect ALL to be supported). Lots of threads in this forum are based solely on the fact that GF does not work like a "real" service, but just comes with a service that controls GF. That problems will be gone as soon as you understand that you must not somehow wrap Java to make it look like Windows, but that you must start do DESIGN FOR Windows to make people happy. That IS possible in Java, and it does not necessarily break compatibility with other platforms. But you need to learn how to do it and you then must do it. Otherwise it will always feal like a "impurity" on Windows. We lost several customers since they where unhappy with the "strange" felling of GF, actually, and all we ask for is just to get rid of batches in the first place. Is that so non-understandable?
        Hide
        scatari added a comment -

        Instead of java.exe, javaw.exe can be used to suppress the command window @startup time. javaw.exe
        uses WinMain() as the entry point.

        Show
        scatari added a comment - Instead of java.exe, javaw.exe can be used to suppress the command window @startup time. javaw.exe uses WinMain() as the entry point.
        Hide
        Tom Mueller added a comment -

        Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

        Show
        Tom Mueller added a comment - Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

          People

          • Assignee:
            scatari
            Reporter:
            mkarg
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: