glassfish
  1. glassfish
  2. GLASSFISH-2918

launch link in web app ignore virtual server

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 9.1pe
    • Fix Version/s: 9.1pe
    • Component/s: web_container
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      2,918

      Description

      Currently if a web app is deployed only to a specific virtual server, the launch
      link for that web app still uses the DAS in forming the launch link for PE.
      The current semantic for VS in deployment is such that if no virtual server is
      specified, then it means the deployment applies to ALL VS.
      If VS is specified, it will only deploy to the specified VS.
      So, if you create a VS, and then deploy only to this new VS, the launch link
      still uses the host name in forming the URL, thus, it won't work. user gets a
      404 error.

      Besides fixing the launch link, we should also show the VS in the application
      edit screen for PE. otherwise, user has no idea which VS this app is deployed to.

      1. domain.xml
        23 kB
        cchidamb
      2. hosts
        0.3 kB
        cchidamb

        Activity

        Hide
        Anissa Lam added a comment -

        assign to ken

        Show
        Anissa Lam added a comment - assign to ken
        Hide
        cchidamb added a comment -

        Assigning this to myself

        Show
        cchidamb added a comment - Assigning this to myself
        Hide
        cchidamb added a comment -

        I've started working on it.

        Show
        cchidamb added a comment - I've started working on it.
        Hide
        cchidamb added a comment -

        I looked at our code, and looks like we're doing the correct thing here. Which
        ever VS the app is deployed on, we're using the associated http-listener port
        for that VS. Only thing is, we're using the actual hostname instead of the
        virtual host defined by the user. In theory this should never return 404, since
        we're using the actual hostname with correct port number.

        There is a possibility if we fix this issue using virtual host instead of actual
        host, 404 might return, if proper mapping of virtual host is not defined. My
        recommendation is, it's safe to leave the launch link as is, and just fix this
        by showing the virtual servers field in the edit page.

        If you've really seen 404, I want to know your test case, bcz I couldn't
        reproduce this in my test case.

        Show
        cchidamb added a comment - I looked at our code, and looks like we're doing the correct thing here. Which ever VS the app is deployed on, we're using the associated http-listener port for that VS. Only thing is, we're using the actual hostname instead of the virtual host defined by the user. In theory this should never return 404, since we're using the actual hostname with correct port number. There is a possibility if we fix this issue using virtual host instead of actual host, 404 might return, if proper mapping of virtual host is not defined. My recommendation is, it's safe to leave the launch link as is, and just fix this by showing the virtual servers field in the edit page. If you've really seen 404, I want to know your test case, bcz I couldn't reproduce this in my test case.
        Hide
        Anissa Lam added a comment -

        Its true that i didn't have the proper mapping of the virtual host. Thats' why
        when i do http://myVS:8080/myApp i get the 404 error.

        I do have a question for Jan and Kedar:
        If i create a Virtual Server, myVS, and deploy the webapp to this VS ONLY,

        going to http://localhost:8080/myApp should it work or not ??

        If it is not suppose to work, then we need to use the VS name in constructing
        the launch link if the app is deployed to some specific VS. And its the user's
        responsibility to setup the proper mapping.

        thx

        Show
        Anissa Lam added a comment - Its true that i didn't have the proper mapping of the virtual host. Thats' why when i do http://myVS:8080/myApp i get the 404 error. I do have a question for Jan and Kedar: If i create a Virtual Server, myVS, and deploy the webapp to this VS ONLY, going to http://localhost:8080/myApp should it work or not ?? If it is not suppose to work, then we need to use the VS name in constructing the launch link if the app is deployed to some specific VS. And its the user's responsibility to setup the proper mapping. thx
        Hide
        cchidamb added a comment -

        It depends on the http-listener associated for the VS you've created. If the
        http-listener port number is XXXX, and the created VS's listener's port # is
        XXXX then http://<HOSTNAME>:XXXX/ctxtroot should work.

        Show
        cchidamb added a comment - It depends on the http-listener associated for the VS you've created. If the http-listener port number is XXXX, and the created VS's listener's port # is XXXX then http://<HOSTNAME>:XXXX/ctxtroot should work.
        Hide
        cchidamb added a comment -

        I agree the right thing to do might be to use VS name, but the app seems to be
        working for other hostnames too, not just VS name.

        Jan,
        Is this the correct behavior?

        Show
        cchidamb added a comment - I agree the right thing to do might be to use VS name, but the app seems to be working for other hostnames too, not just VS name. Jan, Is this the correct behavior?
        Hide
        jluehe added a comment -

        If a webapp has been deployed to multiple virtual servers, there should be one
        launch link for each deployment.

        For example, consider the scenario where webapp "myweb.war" has been deployed to
        virtual servers "host1", "host2", and "host3", and where "host1" and "host2" are
        associated with http-listener-A, listening on port 1234, while "host3" is
        associated with http-listener-B, listening on port 5678.

        When launching "myweb.war" from admin gui, the admin gui should produce these links:

        http://<host1>:1234/myweb
        http://<host2>:1234/myweb
        http://<host3>:5678/myweb

        To answer your other question: If you deploy "myweb.war" to virtual server
        "myvs" only, it will be available on this virtual server only. Assuming that
        "myvs" is associated with an http listener listening on port 1234,

        telnet localhost 1234
        GET /myweb/ HTTP/1.1
        Host: myvs

        will return the requested resource (in this case, a welcome page or dir
        listing), whereas

        telnet localhost 1234
        GET /myweb/ HTTP/1.1
        Host: localhost

        will result in a 404 response.

        Show
        jluehe added a comment - If a webapp has been deployed to multiple virtual servers, there should be one launch link for each deployment. For example, consider the scenario where webapp "myweb.war" has been deployed to virtual servers "host1", "host2", and "host3", and where "host1" and "host2" are associated with http-listener-A, listening on port 1234, while "host3" is associated with http-listener-B, listening on port 5678. When launching "myweb.war" from admin gui, the admin gui should produce these links: http://<host1>:1234/myweb http://<host2>:1234/myweb http://<host3>:5678/myweb To answer your other question: If you deploy "myweb.war" to virtual server "myvs" only, it will be available on this virtual server only. Assuming that "myvs" is associated with an http listener listening on port 1234, telnet localhost 1234 GET /myweb/ HTTP/1.1 Host: myvs will return the requested resource (in this case, a welcome page or dir listing), whereas telnet localhost 1234 GET /myweb/ HTTP/1.1 Host: localhost will result in a 404 response.
        Hide
        cchidamb added a comment -

        Then how come if an app is deployed on myVS, and the associated listener's port
        is XXXX. The app seems to be working on hostname:port/ctxroot

        Classic example running in production is appserver.sfbay.sun.com, you can also
        access this app through wikihome.sfbay.sun.com/appserver

        /appserver is deployed to appserver.sfbay.sun.com VS only.

        Show
        cchidamb added a comment - Then how come if an app is deployed on myVS, and the associated listener's port is XXXX. The app seems to be working on hostname:port/ctxroot Classic example running in production is appserver.sfbay.sun.com, you can also access this app through wikihome.sfbay.sun.com/appserver /appserver is deployed to appserver.sfbay.sun.com VS only.
        Hide
        jluehe added a comment -

        Building on the previous example:

        If you deploy "myweb.war" to virtual server "myvs" only, it will be available on
        this virtual server only. However, if "myvs" is associated with http-listener-x
        listening on port xxxx, and has also beeen declared as the
        default-virtual-server of http-listener-x, any requests with an "unknown" host
        name received on port xxxx will be mapped to "myvs", which would explain what
        you are seeing.

        Show
        jluehe added a comment - Building on the previous example: If you deploy "myweb.war" to virtual server "myvs" only, it will be available on this virtual server only. However, if "myvs" is associated with http-listener-x listening on port xxxx, and has also beeen declared as the default-virtual-server of http-listener-x, any requests with an "unknown" host name received on port xxxx will be mapped to "myvs", which would explain what you are seeing.
        Hide
        Anissa Lam added a comment -

        For cluster profile, the Launch link takes user to a 2nd page where we listed
        the launch link for each target.
        I guess we should do the same thing for developer profile now, ie have a 2nd page.
        If <virtual-server> is empty, we will use the hostname, and if VS list is not
        empty, we will list out each using the VS name and the port it listens to.

        But this list will be very long for cluster profile if the app is deployed to
        mutliple targets and specific VS for that target. I think thats the way it
        should be though.

        Show
        Anissa Lam added a comment - For cluster profile, the Launch link takes user to a 2nd page where we listed the launch link for each target. I guess we should do the same thing for developer profile now, ie have a 2nd page. If <virtual-server> is empty, we will use the hostname, and if VS list is not empty, we will list out each using the VS name and the port it listens to. But this list will be very long for cluster profile if the app is deployed to mutliple targets and specific VS for that target. I think thats the way it should be though.
        Hide
        cchidamb added a comment -

        Jan,
        Thank You for your explanation, Yes. This answers, I should not make VS X as the
        default VS for listener X. Then my app works only on VS:<X's port>, not for any
        other hostnames.

        Show
        cchidamb added a comment - Jan, Thank You for your explanation, Yes. This answers, I should not make VS X as the default VS for listener X. Then my app works only on VS:<X's port>, not for any other hostnames.
        Hide
        Anissa Lam added a comment -

        I also notice that currently in the deployment page, we have a text box for VS.
        This should not be there for cluster profile.
        For Cluster profile, user selects the target they want to deploy to, and the VS
        is different for each target. We allow them to change the VS after deployment
        by going to the manage VS page. For deployment this text box should be removed
        in cluster profile.

        For developer profile, it will be best if we can replace this text box by a
        multi-select list. This prevents user error and easier to use.
        The list should contain "" as the first item. Either don't select anything in
        this list or pre-select this "" as default.

        thx

        Show
        Anissa Lam added a comment - I also notice that currently in the deployment page, we have a text box for VS. This should not be there for cluster profile. For Cluster profile, user selects the target they want to deploy to, and the VS is different for each target. We allow them to change the VS after deployment by going to the manage VS page. For deployment this text box should be removed in cluster profile. For developer profile, it will be best if we can replace this text box by a multi-select list. This prevents user error and easier to use. The list should contain "" as the first item. Either don't select anything in this list or pre-select this "" as default. thx
        Hide
        km added a comment -

        Hi Anissa, I am not sure. Shouldn't Virtual Servers be available in addition to
        targets? A target is a domain, instance, or cluster as far as deployment is
        concerned and denotes a JVM in this case. A virtual server is where this
        application is "loaded". So, I'd think being able to specify virtual servers is
        required regardless of profile.

        In all the profiles (developer/cluster/enterprise/foo/bar/...), it would be nice
        to be able to select from a list of available virtual servers. We should always
        exclude the VS:__asadmin (which is available only on DAS, anyway), from the list.

        Also, it would be better if we do this only for pure web apps. Agreed,
        enterprise apps might have web apps, but enterprise apps do not have this
        facility. All the web-apps "bundled" into an enterprise app is available in
        default virtual server only, I believe. (Right, Jan?)

        Show
        km added a comment - Hi Anissa, I am not sure. Shouldn't Virtual Servers be available in addition to targets? A target is a domain, instance, or cluster as far as deployment is concerned and denotes a JVM in this case. A virtual server is where this application is "loaded". So, I'd think being able to specify virtual servers is required regardless of profile. In all the profiles (developer/cluster/enterprise/foo/bar/...), it would be nice to be able to select from a list of available virtual servers. We should always exclude the VS:__asadmin (which is available only on DAS, anyway), from the list. Also, it would be better if we do this only for pure web apps. Agreed, enterprise apps might have web apps, but enterprise apps do not have this facility. All the web-apps "bundled" into an enterprise app is available in default virtual server only, I believe. (Right, Jan?)
        Hide
        jluehe added a comment -

        webapps bundled inside an .ear file are available on the virtual servers to
        which the .ear has been deployed. This is not any different from standalone webapps.

        Show
        jluehe added a comment - webapps bundled inside an .ear file are available on the virtual servers to which the .ear has been deployed. This is not any different from standalone webapps.
        Hide
        cchidamb added a comment -

        Kedar,
        To answer your question, VS association to apps/webapps are availabe even in
        cluster profile, only difference is, VS references can be configured as post
        deploy, not during deployment. The UI will look so cluttered if we try to do
        this during deployment in cluster profile, bcz deployment is single screen now.
        We can think of having a wizard flow for cluster profile VS references for
        future releases.

        Jan,
        Yes, GUI don't differentiate between enterprise, or webapps as far as VS
        references are concerned.

        Show
        cchidamb added a comment - Kedar, To answer your question, VS association to apps/webapps are availabe even in cluster profile, only difference is, VS references can be configured as post deploy, not during deployment. The UI will look so cluttered if we try to do this during deployment in cluster profile, bcz deployment is single screen now. We can think of having a wizard flow for cluster profile VS references for future releases. Jan, Yes, GUI don't differentiate between enterprise, or webapps as far as VS references are concerned.
        Hide
        gfbugbridge added a comment -

        <BT6559570>

        Show
        gfbugbridge added a comment - <BT6559570>
        Hide
        cchidamb added a comment -

        Created an attachment (id=974)
        domain.xml

        Show
        cchidamb added a comment - Created an attachment (id=974) domain.xml
        Hide
        cchidamb added a comment -

        Created an attachment (id=975)
        hosts file

        Show
        cchidamb added a comment - Created an attachment (id=975) hosts file
        Hide
        cchidamb added a comment -

        Jan,
        You might have seen the emails I, and Sankar sent to you. I'm assigning this
        issue to you for now. If you think there is something wrong either in my
        /etc/hosts file, or domain.xml, pls let me know. I'm attaching my /etc/hosts,
        and domain.xml with this, please look at the app hello associated to VS
        testapp.com in domain.xml. I tried changing <http-listener acceptor-threads="1"
        address="127.0.1.2" to address="0.0.0.0", still getting 404. telnet with host
        header testapp.com returns 404 as well.

        Show
        cchidamb added a comment - Jan, You might have seen the emails I, and Sankar sent to you. I'm assigning this issue to you for now. If you think there is something wrong either in my /etc/hosts file, or domain.xml, pls let me know. I'm attaching my /etc/hosts, and domain.xml with this, please look at the app hello associated to VS testapp.com in domain.xml. I tried changing <http-listener acceptor-threads="1" address="127.0.1.2" to address="0.0.0.0", still getting 404. telnet with host header testapp.com returns 404 as well.
        Hide
        jluehe added a comment -

        Your domain.xml contains these virtual-server entries:

        <virtual-server hosts="vshost" id="newvs"
        log-file="$

        {com.sun.aas.instanceRoot}/logs/server.log" state="on">
        ...
        </virtual-server>
        <virtual-server hosts="127.0.1.2" id="testapp.com"
        log-file="${com.sun.aas.instanceRoot}

        /logs/server.log" state="on">
        ...
        </virtual-server>

        Notice how neither entry specifies any http-listeners attribute. This
        means that none of the HTTP listeners know anything about the virtual
        servers you added (since your virtual servers are also not referenced
        as the default-virtual-server from any of the HTTP listeners).

        In this case, a 404 is expected.

        Show
        jluehe added a comment - Your domain.xml contains these virtual-server entries: <virtual-server hosts="vshost" id="newvs" log-file="$ {com.sun.aas.instanceRoot}/logs/server.log" state="on"> ... </virtual-server> <virtual-server hosts="127.0.1.2" id="testapp.com" log-file="${com.sun.aas.instanceRoot} /logs/server.log" state="on"> ... </virtual-server> Notice how neither entry specifies any http-listeners attribute. This means that none of the HTTP listeners know anything about the virtual servers you added (since your virtual servers are also not referenced as the default-virtual-server from any of the HTTP listeners). In this case, a 404 is expected.
        Hide
        cchidamb added a comment -

        http-listeners is not a required attribute for VS. The description in DTD for
        http-listeners attribute in VS says, it is required only if the VS is not a
        default VS, but the check is not enforced strictly during VS creation, meaning
        you can create a VS without any listeners specified (which is not a default VS
        also, bcz we're creating it for the first time), then associate it to a deployed
        app. Now when you hit the app, it's going to return 404. I would say we should
        make it available on all listeners if the none is specified.

        Anyway I discussed with Anissa, there are two issues here, one is the launch
        link, and another is using listbox for VS configuration during deployment. This
        issue is addressed, and I've some questions to be answered in launch link. I'll
        mark this issue as fixed, and open another issue specific to launch link.

        Show
        cchidamb added a comment - http-listeners is not a required attribute for VS. The description in DTD for http-listeners attribute in VS says, it is required only if the VS is not a default VS, but the check is not enforced strictly during VS creation, meaning you can create a VS without any listeners specified (which is not a default VS also, bcz we're creating it for the first time), then associate it to a deployed app. Now when you hit the app, it's going to return 404. I would say we should make it available on all listeners if the none is specified. Anyway I discussed with Anissa, there are two issues here, one is the launch link, and another is using listbox for VS configuration during deployment. This issue is addressed, and I've some questions to be answered in launch link. I'll mark this issue as fixed, and open another issue specific to launch link.

          People

          • Assignee:
            cchidamb
            Reporter:
            Anissa Lam
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: