Geronimo
  1. Geronimo
  2. GERONIMO-3599

Unable to create new JMS Resource group through console in IE7

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.1, 2.1.4
    • Fix Version/s: 2.1.5, 2.2
    • Component/s: console
    • Security Level: public (Regular issues)
    • Labels:
      None
    • Environment:

      WIN XP

      Description

      I am not able to create a new JMS Resouce group through console. I am getting cannot display the page error after entering the Q name and physical name and then pressing next.
      The following is the url
      http://localhost:8080/console/portal/services/services_jms/_ps_services_jms_row1_col1_p1/normal/_pm_services_jms_row1_col1_p1/view/_ac_services_jms_row1_col1_p1/AC/_st_services_jms_row1_col1_p1/normal/_md_services_jms_row1_col1_p1/view/_pid/services_jms_row1_col1_p1
      The problem only comes with Internet Explorer 7.

      Best Regards,
      Anish Pathadan

        Activity

        Hide
        Rex Wang added a comment -

        closing it.

        Show
        Rex Wang added a comment - closing it.
        Hide
        Ivan added a comment -

        Commit changes to trunk at revision: 776955, 2.1.5 snapshot at revision: 776959
        I ommit the changes of changing the cache size, for it is only needed while the session timeout and the long url occurs at the same time, it maybe very rarely, and I am not sure whether it would broke other components.

        Show
        Ivan added a comment - Commit changes to trunk at revision: 776955, 2.1.5 snapshot at revision: 776959 I ommit the changes of changing the cache size, for it is only needed while the session timeout and the long url occurs at the same time, it maybe very rarely, and I am not sure whether it would broke other components.
        Hide
        Ivan added a comment -

        This issue has been existed for long time, and currently I could not see that MS will solve this issue in the new IE version,
        The only disadvantage for the latest solution is that once the filter is active for long url, the back button of the browser will not work. But comparing to the error page, I guess that it should be acceptable.
        If no objection, I will commit the latest patch !

        Show
        Ivan added a comment - This issue has been existed for long time, and currently I could not see that MS will solve this issue in the new IE version, The only disadvantage for the latest solution is that once the filter is active for long url, the back button of the browser will not work. But comparing to the error page, I guess that it should be acceptable. If no objection, I will commit the latest patch !
        Hide
        Shawn Jiang added a comment -

        The patch might need be reworked:

        1, Move the filter to the console-filter since we have a console-filter component now.

        2, Check jetty setting to see if there's similar <attribute name="maxSavePostSize">-1</attribute> needs to be added.

        Show
        Shawn Jiang added a comment - The patch might need be reworked: 1, Move the filter to the console-filter since we have a console-filter component now. 2, Check jetty setting to see if there's similar <attribute name="maxSavePostSize">-1</attribute> needs to be added.
        Hide
        Shawn Jiang added a comment -

        I believe that's because G2.2 has a little bit smaller url length than that of G2.1 so that only this specific problem can't be reproduced in G2.2 if the jms resource name are not long enough.

        Unfortunately, when I give the jms resource with long enough name to make the url of G2.2 exceed 2048, this problem happens again.

        I don't see any drawback with the patch so that I suggest to apply the patch to resolve this problem entirely.

        Show
        Shawn Jiang added a comment - I believe that's because G2.2 has a little bit smaller url length than that of G2.1 so that only this specific problem can't be reproduced in G2.2 if the jms resource name are not long enough. Unfortunately, when I give the jms resource with long enough name to make the url of G2.2 exceed 2048, this problem happens again. I don't see any drawback with the patch so that I suggest to apply the patch to resolve this problem entirely.
        Hide
        Donald Woods added a comment -

        Shawn, if you can't recreate it anymore, then close it as "can't reproduce." Thanks for looking at it.

        Show
        Donald Woods added a comment - Shawn, if you can't recreate it anymore, then close it as "can't reproduce." Thanks for looking at it.
        Hide
        Shawn Jiang added a comment -

        Can't recreate this problem in G2.2. It's strange because the patch didn't get applied in trunk.

        BTW. it's still existing in G2.1.4 release and G2.1.5 snapshot.

        Show
        Shawn Jiang added a comment - Can't recreate this problem in G2.2. It's strange because the patch didn't get applied in trunk. BTW. it's still existing in G2.1.4 release and G2.1.5 snapshot.
        Hide
        Ivan added a comment -

        Another patch of a better solution provided by Jack, it has the same strategy with the previous one, but a temporary form is used to post the long url, in this way, it almost acts the same behavior as on the non-IE browsers.
        One extra modification is that the property of maxSavePostSize should be set as -1 for tomcat connector.

        Show
        Ivan added a comment - Another patch of a better solution provided by Jack, it has the same strategy with the previous one, but a temporary form is used to post the long url, in this way, it almost acts the same behavior as on the non-IE browsers. One extra modification is that the property of maxSavePostSize should be set as -1 for tomcat connector.
        Hide
        Ivan added a comment -

        I have updated some codes in the patch, it will detect whether the client's browser is IE, if not, it will skip the url cache operation.
        Currently solution is if it find Pluto invoke the redirect method, and the length of the url is more than 2048, it will cache the url in the server side, and add a cache tag in the url, while the browser's next request comes to the server, if a cache tag is found, it will retrieve the cache url and rebuild the request object.
        Thanks !

        Show
        Ivan added a comment - I have updated some codes in the patch, it will detect whether the client's browser is IE, if not, it will skip the url cache operation. Currently solution is if it find Pluto invoke the redirect method, and the length of the url is more than 2048, it will cache the url in the server side, and add a cache tag in the url, while the browser's next request comes to the server, if a cache tag is found, it will retrieve the cache url and rebuild the request object. Thanks !
        Hide
        Ivan added a comment -

        Thanks, Donald, I re-created the patch !

        Show
        Ivan added a comment - Thanks, Donald, I re-created the patch !
        Hide
        Donald Woods added a comment -

        Ivan, please make sure the editor you are using does not reformat existing files when you edit them (any reformatting should be submitted in a separate patch, so it will be easier to review your proposed changes.). Also, your editor should be configured to use 4 spaces instead of real tabs.
        Please take a look at the following Coding Standards page -
        http://cwiki.apache.org/confluence/display/GMOxDEV/Coding+standards
        and how to setup Eclipse -
        http://cwiki.apache.org/GMOxDEV/developing-geronimo-in-eclipse.html

        Show
        Donald Woods added a comment - Ivan, please make sure the editor you are using does not reformat existing files when you edit them (any reformatting should be submitted in a separate patch, so it will be easier to review your proposed changes.). Also, your editor should be configured to use 4 spaces instead of real tabs. Please take a look at the following Coding Standards page - http://cwiki.apache.org/confluence/display/GMOxDEV/Coding+standards and how to setup Eclipse - http://cwiki.apache.org/GMOxDEV/developing-geronimo-in-eclipse.html
        Hide
        Ivan added a comment -

        I am trying to test it in more scenarioes, currently it is a preview version, thanks for any comment

        Show
        Ivan added a comment - I am trying to test it in more scenarioes, currently it is a preview version, thanks for any comment
        Hide
        Ivan added a comment -

        Thanks YunFeng !
        While I trying to write some codes for it, I find the current issue is caused by another reason, it seems that pluto will redirect the client to a new url while it finishes the action process, and the redirect url is usually very long, it will caused IE corrupted.
        The scenario I mentioned in the last comment will not cause this issue, for the action url is usually not very long. But the view / max / min buttons of the portlet have a high chance to go into the long issue. I guess that we may encounter it in the near future.
        I try to provide a patch, the solution is to create a wrapper of the request and response object. So far, it maybe not very mature, but it could show that the solution works. If needed, I will continue to work on it.
        Thanks !

        Show
        Ivan added a comment - Thanks YunFeng ! While I trying to write some codes for it, I find the current issue is caused by another reason, it seems that pluto will redirect the client to a new url while it finishes the action process, and the redirect url is usually very long, it will caused IE corrupted. The scenario I mentioned in the last comment will not cause this issue, for the action url is usually not very long. But the view / max / min buttons of the portlet have a high chance to go into the long issue. I guess that we may encounter it in the near future. I try to provide a patch, the solution is to create a wrapper of the request and response object. So far, it maybe not very mature, but it could show that the solution works. If needed, I will continue to work on it. Thanks !
        Hide
        YunFeng Ma added a comment -

        Hi Ivan,
        The actionURL is needed by Pluto. Could you demonstrate your solution and attach the workable codes? Thanks a lot.

        Show
        YunFeng Ma added a comment - Hi Ivan, The actionURL is needed by Pluto. Could you demonstrate your solution and attach the workable codes? Thanks a lot.
        Hide
        Ivan added a comment -

        Usually, the long url is generated by <portlet:actionURL/>, a common scenario is that :
        <form name="<portlet:namespace/>JMSForm" action="<portlet:actionURL/>" method="POST">
        </form>
        I have a suggestion, maybe it would solve it for ever.
        On the client side, we could put the url generated by <portlet:actionURL/> as a hidden element, like below, so that the url in the browser is always like "http://localhost:8080/console/portal"
        <form name="<portlet:namespace/>JMSForm" action="/console/portal" method="POST">
        <input type="hidden" value="<portlet:actionURL/>" name="hiddenUrl"/>
        </form>
        On the server side, we add a filter to /console/portal, in the filter, we could build a customized requestwrapper and override some methods in it, so that for Pluto, it does the process as usual.

        For the scenario below, we could change it to form submit if needed
        <a href="<portlet:actionURL portletMode="view">
        <portlet:param name="mode" value="list-before" />
        </portlet:actionURL>"><fmt:message key="jmswizard.common.cancel"/></a>
        Another point that need to pay attention is that if the form submit is uploading file, for it, we should be care.
        I am not sure whether I miss something or make a mistake , thanks for any comment !

        Show
        Ivan added a comment - Usually, the long url is generated by <portlet:actionURL/>, a common scenario is that : <form name="<portlet:namespace/>JMSForm" action="<portlet:actionURL/>" method="POST"> </form> I have a suggestion, maybe it would solve it for ever. On the client side, we could put the url generated by <portlet:actionURL/> as a hidden element, like below, so that the url in the browser is always like "http://localhost:8080/console/portal" <form name="<portlet:namespace/>JMSForm" action="/console/portal" method="POST"> <input type="hidden" value="<portlet:actionURL/>" name="hiddenUrl"/> </form> On the server side, we add a filter to /console/portal, in the filter, we could build a customized requestwrapper and override some methods in it, so that for Pluto, it does the process as usual. For the scenario below, we could change it to form submit if needed <a href="<portlet:actionURL portletMode="view"> <portlet:param name="mode" value="list-before" /> </portlet:actionURL>"><fmt:message key="jmswizard.common.cancel"/></a> Another point that need to pay attention is that if the form submit is uploading file, for it, we should be care. I am not sure whether I miss something or make a mistake , thanks for any comment !
        Hide
        Joe Bohn added a comment -

        move fix version to 2.1.3 from 2.1.2

        Show
        Joe Bohn added a comment - move fix version to 2.1.3 from 2.1.2
        Hide
        Joseph Leong added a comment -

        Continually working on this hoping to contribute for release. Have been trying to convert everything over to sessions. A little frustrating, taking some time converting to storing in session as well as recalling data from a session. Also, trying to figure out and figuring out where the lose ends are.

        -Joseph Leong

        Show
        Joseph Leong added a comment - Continually working on this hoping to contribute for release. Have been trying to convert everything over to sessions. A little frustrating, taking some time converting to storing in session as well as recalling data from a session. Also, trying to figure out and figuring out where the lose ends are. -Joseph Leong
        Hide
        Donald Woods added a comment -

        Not sure if this helps you any -

        http://support.microsoft.com/kb/208427

        Microsoft Internet Explorer has a maximum uniform resource locator (URL) length of 2,083 characters.
        However, the POST method is not limited by the size of the URL for submitting name/value pairs. These pairs are transferred in the header and not in the URL.

        Show
        Donald Woods added a comment - Not sure if this helps you any - http://support.microsoft.com/kb/208427 Microsoft Internet Explorer has a maximum uniform resource locator (URL) length of 2,083 characters. However, the POST method is not limited by the size of the URL for submitting name/value pairs. These pairs are transferred in the header and not in the URL.
        Hide
        Joseph Leong added a comment -

        So it seems even if we just shorten the var argument length, if the user increases their input enough - we still will run into this issue? It seems also with the way pluto works and the response it send back might be so big that reducing my var arguments by a few char may still greatly fall short of resolving the 2084 limit. Does anyone have any comments/ideas about if i approached passing the information through a portlet session? Would that resolve the url issue by keeping information server side?

        Show
        Joseph Leong added a comment - So it seems even if we just shorten the var argument length, if the user increases their input enough - we still will run into this issue? It seems also with the way pluto works and the response it send back might be so big that reducing my var arguments by a few char may still greatly fall short of resolving the 2084 limit. Does anyone have any comments/ideas about if i approached passing the information through a portlet session? Would that resolve the url issue by keeping information server side?
        Hide
        Joseph Leong added a comment -

        Trying to go through and recreate the same URL error. I'm not able to recreate the error with the similar URL pattern in 2.1, but still coming upon an error with the page not loading. It seems i am able to create one item, but anything afterwards will results in an error.

        Procedure as follow:

        Branch 2.0
        1)Create a new JMS Resource Group->For ActiveMQ
        2)Fill in Resource Group Name
        3)Add Connection Factory->Fill in Connection Factory Name
        4)Add Another Connection Factory
        [Error Url] http://localhost:8080/console/portal/services/services_jms/_ac_services_jms_row1_col1_p1/AC/_ps_services_jms_row1_col1_p1/normal/_pid/services_jms_row1_col1_p1/_pm_services_jms_row1_col1_p1/view/_md_services_jms_row1_col1_p1/view/_st_services_jms_row1_col1_p1/normal

        Branch 2.1
        1)Create a new JMS Resource Group->For ActiveMQ
        2)Fill in Resource Group Name
        3)Add Connection Factory->Fill in Connection Factory Name
        4)Add Another Connection Factory
        [Error Url]
        http://localhost:8080/console/portal//Services/JMS%20Resources/__ac0x3activemq0x2JMSWizard!1082939780%7C0/__pm0x3activemq0x2JMSWizard!1082939780%7C0_view

        Show
        Joseph Leong added a comment - Trying to go through and recreate the same URL error. I'm not able to recreate the error with the similar URL pattern in 2.1, but still coming upon an error with the page not loading. It seems i am able to create one item, but anything afterwards will results in an error. Procedure as follow: Branch 2.0 1)Create a new JMS Resource Group->For ActiveMQ 2)Fill in Resource Group Name 3)Add Connection Factory->Fill in Connection Factory Name 4)Add Another Connection Factory [Error Url] http://localhost:8080/console/portal/services/services_jms/_ac_services_jms_row1_col1_p1/AC/_ps_services_jms_row1_col1_p1/normal/_pid/services_jms_row1_col1_p1/_pm_services_jms_row1_col1_p1/view/_md_services_jms_row1_col1_p1/view/_st_services_jms_row1_col1_p1/normal Branch 2.1 1)Create a new JMS Resource Group->For ActiveMQ 2)Fill in Resource Group Name 3)Add Connection Factory->Fill in Connection Factory Name 4)Add Another Connection Factory [Error Url] http://localhost:8080/console/portal//Services/JMS%20Resources/__ac0x3activemq0x2JMSWizard!1082939780%7C0/__pm0x3activemq0x2JMSWizard!1082939780%7C0_view
        Hide
        Joseph Leong added a comment -

        Continuing progress on this now, put it on the side for a little bit. I think to keep the post length below 2084 i'll go through and reduce the parameter names and see if that will keep it below 2084. If not, maybe i'll try passing it through portletsessions.

        -Joseph Leong

        Show
        Joseph Leong added a comment - Continuing progress on this now, put it on the side for a little bit. I think to keep the post length below 2084 i'll go through and reduce the parameter names and see if that will keep it below 2084. If not, maybe i'll try passing it through portletsessions. -Joseph Leong
        Hide
        Kevan Miller added a comment -

        Are we making any progress on this problem?

        Agreed the problem must be the POST length. As I attempt to create a destination, the post length has grown to 2083, but the create of the destination fails...

        Show
        Kevan Miller added a comment - Are we making any progress on this problem? Agreed the problem must be the POST length. As I attempt to create a destination, the post length has grown to 2083, but the create of the destination fails...
        Hide
        Joseph Leong added a comment -

        Working on splitting the options between a few different pages to reduce post data seems to be a better solution.

        Show
        Joseph Leong added a comment - Working on splitting the options between a few different pages to reduce post data seems to be a better solution.
        Hide
        Joseph Leong added a comment -

        The problem may be in the long POST.

        According to Microsoft KB, IE4 through 7 have URL limitations of 2,084 while other browsers Firefox, Safari, Opera accept URL lengths above 65,536.
        Currently looking at implementing a general compression scheme to reduce the length of the URL, but weighing the possibility of whether the reduction ratio would provide any significant results.

        Show
        Joseph Leong added a comment - The problem may be in the long POST. According to Microsoft KB, IE4 through 7 have URL limitations of 2,084 while other browsers Firefox, Safari, Opera accept URL lengths above 65,536. Currently looking at implementing a general compression scheme to reduce the length of the URL, but weighing the possibility of whether the reduction ratio would provide any significant results.

          People

          • Assignee:
            Ivan
            Reporter:
            Anish Pathadan
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development