Jetspeed 2
  1. Jetspeed 2
  2. JS2-364

Check for deploying Portlet Apps with same name as portal

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 2.0-M4
    • Fix Version/s: 2.0-FINAL
    • Component/s: Deployment
    • Labels:
      None

      Description

      If you have a Jetspeed portal with the context /jetspeed, and you drop in a portlet application into the deploy directory with the name /jetspeed, then Jetspeed will blindly install the portlet app over itself.

      This bug occurs with all portal names.

      We need to check for this exception, and disallow this special case.

        Activity

        Hide
        Ate Douma added a comment -

        It turns out to be rather difficult to "know" under which context the portal is running when you're not invoked from a servlet request.
        As the DeployPortletAppEventListener is running in its own thread, and can invoke a deployment when not one request has been send of to the portal,
        this becomes very difficult to handle automatically.
        And then, what if the war contains a context.xml (Tomcat) redefining its context? Should we start checking that too?
        And finally, a user can also accidentally drop a war directly in the (Tomcat) webapps folder, certainly leading to disaster.

        In short, I don't think this can really be handled/fixed 100%.
        Furthermore, in my opinion, this is a user error which hardly will ever occur and certainly not twice by the same user for sure

        So, I'm going to classify this issue as "Won't Fix" for now.
        If anyone thinks differently, then just reopen it again.

        Show
        Ate Douma added a comment - It turns out to be rather difficult to "know" under which context the portal is running when you're not invoked from a servlet request. As the DeployPortletAppEventListener is running in its own thread, and can invoke a deployment when not one request has been send of to the portal, this becomes very difficult to handle automatically. And then, what if the war contains a context.xml (Tomcat) redefining its context? Should we start checking that too? And finally, a user can also accidentally drop a war directly in the (Tomcat) webapps folder, certainly leading to disaster. In short, I don't think this can really be handled/fixed 100%. Furthermore, in my opinion, this is a user error which hardly will ever occur and certainly not twice by the same user for sure So, I'm going to classify this issue as "Won't Fix" for now. If anyone thinks differently, then just reopen it again.

          People

          • Assignee:
            Ate Douma
            Reporter:
            David Sean Taylor
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development