portletspec3
  1. portletspec3
  2. PORTLETSPEC3-8

Errata: Clarify inconsistencies regarding getting and setting parameters

    Details

      Description

      Reading the spec document on parameters and comparing it with the javadoc on
      "get...Parameter..." and "set...Parameter..." calls on various Response, Request, and
      URL classes, it seems to me that there are a number of inconsistencies that should
      be addressed, for example:

      1. Is a parameter allowed to have a value of null?
      2. Under which cases (if any) should setting a parameter to a value of null remove the parameter?
      3. In which cases exactly are public parameters get and set?
      4. In which cases are public render parameters set or updated?
      5. In which cases are public render parameters removed?
      6. Should the "getParameterMap" methods always return an immutable map?
      7. probably more that I haven't noticed yet ...

      To #6 -

      The javadoc for PortletRequest.getParameterMap states:
      -------------------------
          Returns:
              an immutable Map containing parameter names as keys and parameter values as map 
              values, or an empty Map if no parameters exist. 
              The keys in the parameter map are of type String. 
              The values in the parameter map are of type String array (String[]).
      -------------------------
      
      While the javadoc for BaseURL.getParameterMap states:
      -------------------------
      Returns:
          Map containing parameter names as keys and parameter values as map 
          values, or an empty Map if no parameters exist. 
          The keys in the parameter map are of type String. 
          The values in the parameter map are of type String array (String[]).
      -------------------------
      

      Shouldn't the returned Map values be consistently immutable?

      If not, and if we want to be able to update the actual parameters by updating the
      Map returned by BaseURL.getParameterMap, it needs to be described clearly.

        Activity

        Hide
        Neil Griffin added a comment -

        Regarding #1 - #5, I would recommend creating separate issues.

        Regarding #6, I checked the Liferay and Pluto source code, and neither return an immutable map. It is possible that portlet developers have been calling BaseURL.getParameterMap().put(name, value) in order to set values, and changing to an immutable map would cause legacy applications to be non-backward-compatible.

        Show
        Neil Griffin added a comment - Regarding #1 - #5, I would recommend creating separate issues. Regarding #6, I checked the Liferay and Pluto source code, and neither return an immutable map. It is possible that portlet developers have been calling BaseURL.getParameterMap().put(name, value) in order to set values, and changing to an immutable map would cause legacy applications to be non-backward-compatible.
        Hide
        msnicklous added a comment -

        We discussed this issue, made some progress, but also identified areas where more work is needed.

        A new issue will be opened to look at the following points in more detail:

        • Under which cases (if any) should setting a parameter to a value of null remove the parameter?
        • In which cases are public render parameters removed?

        The following points were cleared up:

        • Should the "getParameterMap" methods always return an immutable map?
          • No, that would break existing code
          • No action necessary

        The following point needs to be examined in more detail:

        • Is a parameter allowed to have a value of null?
          • No, a parameter may not have a null value
          • This may need clarification in the javadoc / spec - need to have a look
        • In which cases are public render parameters set or updated?
        Show
        msnicklous added a comment - We discussed this issue, made some progress, but also identified areas where more work is needed. A new issue will be opened to look at the following points in more detail: Under which cases (if any) should setting a parameter to a value of null remove the parameter? In which cases are public render parameters removed? The following points were cleared up: Should the "getParameterMap" methods always return an immutable map? No, that would break existing code No action necessary The following point needs to be examined in more detail: Is a parameter allowed to have a value of null? No, a parameter may not have a null value This may need clarification in the javadoc / spec - need to have a look In which cases are public render parameters set or updated?
        Hide
        Neil Griffin added a comment - - edited

        For the following questions:

        Under which cases (if any) should setting a parameter to a value of null remove the parameter?

        In which cases are public render parameters removed?

        See: PORTLETSPEC3-25

        Show
        Neil Griffin added a comment - - edited For the following questions: Under which cases (if any) should setting a parameter to a value of null remove the parameter? In which cases are public render parameters removed? See: PORTLETSPEC3-25
        Show
        Neil Griffin added a comment - Test Portlet for this issue: https://github.com/ngriffin7a/portletbox/tree/master/issues/PORTLETSPEC3-8-portlet
        Hide
        mfreedma added a comment -

        On your statement:

        "The following points were cleared up:

        Should the "getParameterMap" methods always return an immutable map?
        No, that would break existing code
        No action necessary"

        I agree that map returned is mutable. I disagree if we/the developer expects that manipulating this Map directly impacts the BaseURL. Rather we/developer should manipulate this Map and the call baseURL.setParameters(Map). Right?

        Show
        mfreedma added a comment - On your statement: "The following points were cleared up: Should the "getParameterMap" methods always return an immutable map? No, that would break existing code No action necessary" I agree that map returned is mutable. I disagree if we/the developer expects that manipulating this Map directly impacts the BaseURL. Rather we/developer should manipulate this Map and the call baseURL.setParameters(Map). Right?
        Hide
        Neil Griffin added a comment - - edited

        @Mike: It looks like Scott has fortified the PORTLETSPEC3-8 test portlet with a test for this.

        There are two new buttons:

        • Button with label "actionURL.setParameters() before" (test 12)
        • Button with label "actionURL.setParameters() after" (test 13)

        On Pluto, clicking on these buttons does not affect the toString() value of the ActionURL that is rendered in the subsequent portal page. I think that this confirms your statement:

        I disagree if we/the developer expects that manipulating this Map directly impacts the BaseURL.

        On Liferay, clicking on these buttons does indeed affect the toString() value. Because of this, my preference would be that interpretation be left to the implementation, rather than tighten-up the Spec requirement.

        I'd be interested to know what happens in other implementations.

        Show
        Neil Griffin added a comment - - edited @Mike: It looks like Scott has fortified the PORTLETSPEC3-8 test portlet with a test for this. There are two new buttons: Button with label "actionURL.setParameters() before" (test 12) Button with label "actionURL.setParameters() after" (test 13) On Pluto, clicking on these buttons does not affect the toString() value of the ActionURL that is rendered in the subsequent portal page. I think that this confirms your statement: I disagree if we/the developer expects that manipulating this Map directly impacts the BaseURL. On Liferay, clicking on these buttons does indeed affect the toString() value. Because of this, my preference would be that interpretation be left to the implementation, rather than tighten-up the Spec requirement. I'd be interested to know what happens in other implementations.
        Hide
        msnicklous added a comment -

        I believe the only remaining open point here is whether an an update to the map returned by one of the get parameter map functions should directly cause an update to the actual underlying parameters. In other words, should the following code actually change the parameters:

        String[] values = { "Fred", "Wilma", "Pebbles" };
        actionResponse.getRenderParameterMap().put("privateRenderParameter3", values);
        

        My take would be that by itself no, it should not. The correct code should be:

        String[] values = { "Fred", "Wilma", "Pebbles" };
        Map<String, String[]> parmMap = actionResponse.getRenderParameterMap();
        parmMap.put("privateRenderParameter3", values);
        actionResponse.setRenderParameters(parmMap);
        

        I would suggest the following change for the getRenderParameter map method and corresponding updates for the getParameterMap method on BaseURL:

        Map<String,String[]> getRenderParameterMap()
        
        Returns a Map of the parameters currently set on this portlet URL via the setParameter or setParameters methods.
        
        Contents of this map may be modified, but modifying the map does not directly affect the render parameters. In order to set the
        parameters to the values in the modified map, the setRenderParameters(Map) with the modified map as a parameter must be used.
        
        The keys in the returned map are of type String, and the values are of type String array (String[]).
        
        If no parameters exist this method returns an empty Map.
        
        Returns:
            Map containing parameter names as keys and parameter values as map values, or an empty Map if no parameters exist. The keys in the parameter map are of type String. The values in the parameter map are of type String array (String[]).
        
        Show
        msnicklous added a comment - I believe the only remaining open point here is whether an an update to the map returned by one of the get parameter map functions should directly cause an update to the actual underlying parameters. In other words, should the following code actually change the parameters: String[] values = { "Fred", "Wilma", "Pebbles" }; actionResponse.getRenderParameterMap().put("privateRenderParameter3", values); My take would be that by itself no, it should not. The correct code should be: String[] values = { "Fred", "Wilma", "Pebbles" }; Map<String, String[]> parmMap = actionResponse.getRenderParameterMap(); parmMap.put("privateRenderParameter3", values); actionResponse.setRenderParameters(parmMap); I would suggest the following change for the getRenderParameter map method and corresponding updates for the getParameterMap method on BaseURL: Map<String,String[]> getRenderParameterMap() Returns a Map of the parameters currently set on this portlet URL via the setParameter or setParameters methods. Contents of this map may be modified, but modifying the map does not directly affect the render parameters. In order to set the parameters to the values in the modified map, the setRenderParameters(Map) with the modified map as a parameter must be used. The keys in the returned map are of type String, and the values are of type String array (String[]). If no parameters exist this method returns an empty Map. Returns: Map containing parameter names as keys and parameter values as map values, or an empty Map if no parameters exist. The keys in the parameter map are of type String. The values in the parameter map are of type String array (String[]).
        Hide
        Neil Griffin added a comment -

        Regarding the following sentence:

        Contents of this map may be modified, but modifying the map does not directly affect the render parameters. In order to set the parameters to the values in the modified map, the setRenderParameters(Map) with the modified map as a parameter must be used.

        Using the "Set Parms direct Map #1" (case 4) and "Set Parms direct Map#2" (case 5) buttons, I found that modifying the following code will indeed cause the underlying map to be changed on Liferay Portal:

        actionResponse.getRenderParameterMap().put("privateRenderParameter3", values);

        It is possible that portlet developers have been calling getRenderParameterMap().put(name, value) in order to set values, and changing to an immutable map would cause legacy applications to be non-backward-compatible.

        Because of this, my vote would be that interpretation be left to the implementation, rather than tighten-up the Spec requirement. Therefore I would recommend changing part of the sentence to the following:

        "modifying the map is implementation dependent and therefore may or may not directly affect the render parameters. In order to guarantee that the modified map affects the render parameters, the setRenderParameters(Map) with the modified map as a parameter must be used."

        Show
        Neil Griffin added a comment - Regarding the following sentence: Contents of this map may be modified, but modifying the map does not directly affect the render parameters. In order to set the parameters to the values in the modified map, the setRenderParameters(Map) with the modified map as a parameter must be used. Using the "Set Parms direct Map #1" (case 4) and "Set Parms direct Map#2" (case 5) buttons, I found that modifying the following code will indeed cause the underlying map to be changed on Liferay Portal : actionResponse.getRenderParameterMap().put( "privateRenderParameter3" , values); It is possible that portlet developers have been calling getRenderParameterMap().put(name, value) in order to set values, and changing to an immutable map would cause legacy applications to be non-backward-compatible. Because of this, my vote would be that interpretation be left to the implementation, rather than tighten-up the Spec requirement. Therefore I would recommend changing part of the sentence to the following: "modifying the map is implementation dependent and therefore may or may not directly affect the render parameters. In order to guarantee that the modified map affects the render parameters, the setRenderParameters(Map) with the modified map as a parameter must be used."
        Hide
        msnicklous added a comment -

        Note that Pluto does not allow the parameters to be changed through the map directly. The map obtained from getRenderParameterMap() can be updated,
        but the updates are ignored without the setParameters() call. So Pluto behaves according to the proposed change.

        WebSphere allows a parameter update directly through the map ... sometimes. Namely, if the map is initially empty, it cannot be updated. If a private parameter has been set previously
        so that the map is non-empty, a direct parameter update through the map will be allowed. This seems to me to be an "accident of implementation".

        It would be good if we could understand how other implementations work and see if we can come to a conclusion on this.

        Show
        msnicklous added a comment - Note that Pluto does not allow the parameters to be changed through the map directly. The map obtained from getRenderParameterMap() can be updated, but the updates are ignored without the setParameters() call. So Pluto behaves according to the proposed change. WebSphere allows a parameter update directly through the map ... sometimes. Namely, if the map is initially empty, it cannot be updated. If a private parameter has been set previously so that the map is non-empty, a direct parameter update through the map will be allowed. This seems to me to be an "accident of implementation". It would be good if we could understand how other implementations work and see if we can come to a conclusion on this.
        Hide
        msnicklous added a comment -

        Neil,

        I see that I was working on an stale copy of the Jira issue when I made my update, and I hadn't seen your update. Thanks for posting how Liferay works in this area.
        It might indeed be best to leave that point as an implementation detail.

        Show
        msnicklous added a comment - Neil, I see that I was working on an stale copy of the Jira issue when I made my update, and I hadn't seen your update. Thanks for posting how Liferay works in this area. It might indeed be best to leave that point as an implementation detail.
        Hide
        andre.hagemeier added a comment -

        Neil,
        "Regarding #6, I checked the Liferay and Pluto source code, and neither return an immutable map. It is possible that portlet developers have been calling BaseURL.getParameterMap().put(name, value) in order to set values, and changing to an immutable map would cause legacy applications to be non-backward-compatible."

        I have seen this being done, and I have done it personally. E.g. I implemented a preprocessor to pass url parameters as PRP to Portlets under certain circumstances. So restricting this point would break existing implementations.

        In addition, Scott,:
        "String[] values =

        { "Fred", "Wilma", "Pebbles" };
        actionResponse.getRenderParameterMap().put("privateRenderParameter3", values);
        My take would be that by itself no, it should not. The correct code should be:

        String[] values = { "Fred", "Wilma", "Pebbles" }

        ;
        Map<String, String[]> parmMap = actionResponse.getRenderParameterMap();
        parmMap.put("privateRenderParameter3", values);
        actionResponse.setRenderParameters(parmMap);"

        With that, you would enforce immutable maps. Although I would favor the second approach as well, making the first one impossible would break existing code. Since the first approach cannot be deprecated (as you would have to deprecate a method from java.util.Map), sth like this could be done:

        public class DeprecatedMutableMap<String, String[]> extends HashMap<String, String[]> {
        @Override
        public boolean put(String name, String[] values)

        { logger.warn("calling the put method on this map instance is deprecated. Better use ..."); return super.put(name, values); }

        }

        Just a rough idea. But that would be highly vendor specific, so it actually would not have to be related to the JSR. The JSR would only have to specify, that setting the render parameter directly should not be possible (and if it is already, it should at least be deprecated).

        Show
        andre.hagemeier added a comment - Neil, "Regarding #6, I checked the Liferay and Pluto source code, and neither return an immutable map. It is possible that portlet developers have been calling BaseURL.getParameterMap().put(name, value) in order to set values, and changing to an immutable map would cause legacy applications to be non-backward-compatible." I have seen this being done, and I have done it personally. E.g. I implemented a preprocessor to pass url parameters as PRP to Portlets under certain circumstances. So restricting this point would break existing implementations. In addition, Scott,: "String[] values = { "Fred", "Wilma", "Pebbles" }; actionResponse.getRenderParameterMap().put("privateRenderParameter3", values); My take would be that by itself no, it should not. The correct code should be: String[] values = { "Fred", "Wilma", "Pebbles" } ; Map<String, String[]> parmMap = actionResponse.getRenderParameterMap(); parmMap.put("privateRenderParameter3", values); actionResponse.setRenderParameters(parmMap);" With that, you would enforce immutable maps. Although I would favor the second approach as well, making the first one impossible would break existing code. Since the first approach cannot be deprecated (as you would have to deprecate a method from java.util.Map), sth like this could be done: public class DeprecatedMutableMap<String, String[]> extends HashMap<String, String[]> { @Override public boolean put(String name, String[] values) { logger.warn("calling the put method on this map instance is deprecated. Better use ..."); return super.put(name, values); } } Just a rough idea. But that would be highly vendor specific, so it actually would not have to be related to the JSR. The JSR would only have to specify, that setting the render parameter directly should not be possible (and if it is already, it should at least be deprecated).
        Hide
        msnicklous added a comment - - edited

        I gave this more thought, and I think we have to work our way through the ideas and specify this, one way or the other. I don't think we can leave it as an implementation detail.

        With the portlet title issue, where we said if the title is not specified in the portlet descriptor, it's up to the implementation to determine the title,
        it wasn't critical, because the implementation could decide to leave it empty, just call the portlet "Bob", or do something maybe more sensible. It wouldn't
        break the portlet.

        However, leaving the map issue up to the implementation will result in a real incompatibility, where a portlet written to assume that changing the map changes the parameters would
        not work on a portlet container that does not support that (for example, it wouldn't work on the current reference implementation).

        I understand the point about the map on many implementations currently being mutable and directly effecting a change in the parameters. However, if we leave the map like this, we run into other issues.

        Earlier we agreed on certain rules for the portlet parameters: A parameter may not have a null value, but it can have the empty string as a value. Setting a public
        render parameter to null does not remove the public render parameter; the removePublicRenderParameter() method must be used to remove it. Not including a public render parameter
        in the map passed to setRenderParameters() does not mean that the public render parameter is removed.

        If we stick with these rules (and I believe we should), then the map returned by getParameters() or getRenderParameters() would have to enforce these rules as well.
        It looks to me like this would lead to a custom map implementation in any case.

        I do not believe we could just say, "well, we have these rules about parameters, but if you get a map through getRenderParameters() you can do whatever the map happens to allow."

        And would we really want to say that setting a parameter within the map to null would remove it? That would be .... ugly in imho. But that might be just my personal feeling of aesthetics.

        In light of this, I thought it would be cleaner to force the map to be passed to setParameters() and setRenderParameters() in order for the new values to take effect. the setParameters() call could then enforce the parameter rules.

        Andre - I don't think the proposal above would mean that the map is immutable. The map could still be changed. It would just no
        longer directly effect a change in the actual parameters - this is the way it currently works on Pluto.

        Show
        msnicklous added a comment - - edited I gave this more thought, and I think we have to work our way through the ideas and specify this, one way or the other. I don't think we can leave it as an implementation detail. With the portlet title issue, where we said if the title is not specified in the portlet descriptor, it's up to the implementation to determine the title, it wasn't critical, because the implementation could decide to leave it empty, just call the portlet "Bob", or do something maybe more sensible. It wouldn't break the portlet. However, leaving the map issue up to the implementation will result in a real incompatibility, where a portlet written to assume that changing the map changes the parameters would not work on a portlet container that does not support that (for example, it wouldn't work on the current reference implementation). I understand the point about the map on many implementations currently being mutable and directly effecting a change in the parameters. However, if we leave the map like this, we run into other issues. Earlier we agreed on certain rules for the portlet parameters: A parameter may not have a null value, but it can have the empty string as a value. Setting a public render parameter to null does not remove the public render parameter; the removePublicRenderParameter() method must be used to remove it. Not including a public render parameter in the map passed to setRenderParameters() does not mean that the public render parameter is removed. If we stick with these rules (and I believe we should), then the map returned by getParameters() or getRenderParameters() would have to enforce these rules as well. It looks to me like this would lead to a custom map implementation in any case. I do not believe we could just say, "well, we have these rules about parameters, but if you get a map through getRenderParameters() you can do whatever the map happens to allow." And would we really want to say that setting a parameter within the map to null would remove it? That would be .... ugly in imho. But that might be just my personal feeling of aesthetics. In light of this, I thought it would be cleaner to force the map to be passed to setParameters() and setRenderParameters() in order for the new values to take effect. the setParameters() call could then enforce the parameter rules. Andre - I don't think the proposal above would mean that the map is immutable. The map could still be changed. It would just no longer directly effect a change in the actual parameters - this is the way it currently works on Pluto.
        Hide
        andre.hagemeier added a comment - - edited

        Scott,
        i think whether this map is immutable or not depends on the point of view. I assume your point of view is:
        The map is not immutable since you can actually change its values, and once you set this map with setRenderParameters(), it will take effect.

        My point of view:
        The map is immutable, because i cannot change the values of the parameters of this specific map (or at least is has no effect). I need create a new map or use the same map to re-initiate the values of the backed map.

        With your example:

        params.java
        String[] values = { "Fred", "Wilma", "Pebbles" };
        actionResponse.getRenderParameterMap().put("privateRenderParameter3", values);
        // this way, you could directly change the values of the prp map. You will not receive a clone, but the real backed map, so any change to this map is directly reflected in the request
        
        String[] values = { "Fred", "Wilma", "Pebbles" };
        Map<String, String[]> parmMap = actionResponse.getRenderParameterMap();
        parmMap.put("privateRenderParameter3", values);
        actionResponse.setRenderParameters(parmMap);"
        // most likely you will receive a clone of the internal map here. otherwise you would not have to call setRenderParameters, but could just use the first approach.
        // the setRenderParameters method would then iterate over the paramMap and put its names and values to the internal map of the request
        
        //this is basically the same, as if I created a totally new map and copied all existing values. //There is just no reference to the map instance
        String[] values = { "Fred", "Wilma", "Pebbles" };
        Map<String, String[]> parmMap = new HashMap<String, String[]>();
        copy(actionResponse.getRenderParameterMap(), parmMap);
        parmMap.put("privateRenderParameter3", values);
        actionResponse.setRenderParameters(parmMap);"
        

        To me, the second approach is immutable, because changing the returned map has no effect. Only, if I use the returned map and set it using setRenderParameters, the change will take effect. But that would happen due to the fact, that all names and values are copied to the internal map of the request.

        The only thing, I want to make sure, is that existing implementations still work. Since the methods mentioned don't exist in portlet2.0, i assume, that the old ones will be deprecated, but still be available. And with that getParameterMap needs to return a mutable map, so that
        request.getParameterMap().put(x,y) will still work, even if it Eclipse will show a warning, because getParameterMap may be deprecated.

        Apart from that, as I said, I agree, that the second way would be the more accurate.

        Show
        andre.hagemeier added a comment - - edited Scott, i think whether this map is immutable or not depends on the point of view. I assume your point of view is: The map is not immutable since you can actually change its values, and once you set this map with setRenderParameters(), it will take effect. My point of view: The map is immutable, because i cannot change the values of the parameters of this specific map (or at least is has no effect). I need create a new map or use the same map to re-initiate the values of the backed map. With your example: params.java String [] values = { "Fred" , "Wilma" , "Pebbles" }; actionResponse.getRenderParameterMap().put( "privateRenderParameter3" , values); // this way, you could directly change the values of the prp map. You will not receive a clone, but the real backed map, so any change to this map is directly reflected in the request String [] values = { "Fred" , "Wilma" , "Pebbles" }; Map< String , String []> parmMap = actionResponse.getRenderParameterMap(); parmMap.put( "privateRenderParameter3" , values); actionResponse.setRenderParameters(parmMap);" // most likely you will receive a clone of the internal map here. otherwise you would not have to call setRenderParameters, but could just use the first approach. // the setRenderParameters method would then iterate over the paramMap and put its names and values to the internal map of the request // this is basically the same, as if I created a totally new map and copied all existing values. //There is just no reference to the map instance String [] values = { "Fred" , "Wilma" , "Pebbles" }; Map< String , String []> parmMap = new HashMap< String , String []>(); copy(actionResponse.getRenderParameterMap(), parmMap); parmMap.put( "privateRenderParameter3" , values); actionResponse.setRenderParameters(parmMap);" To me, the second approach is immutable, because changing the returned map has no effect. Only, if I use the returned map and set it using setRenderParameters, the change will take effect. But that would happen due to the fact, that all names and values are copied to the internal map of the request. The only thing, I want to make sure, is that existing implementations still work. Since the methods mentioned don't exist in portlet2.0, i assume, that the old ones will be deprecated, but still be available. And with that getParameterMap needs to return a mutable map, so that request.getParameterMap().put(x,y) will still work, even if it Eclipse will show a warning, because getParameterMap may be deprecated. Apart from that, as I said, I agree, that the second way would be the more accurate.
        Hide
        msnicklous added a comment -

        Andre, sorry, don't really follow you. All methods listed currently exist. In fact, the code in the examples is copy/pasted from test portlets that were run with
        varying degrees of success against several portal implementations. Nothing would be deprecated.

        I don't think we should make assumptions about the internal implementation of a portlet container. We just need to describe external behavior.

        Show
        msnicklous added a comment - Andre, sorry, don't really follow you. All methods listed currently exist. In fact, the code in the examples is copy/pasted from test portlets that were run with varying degrees of success against several portal implementations. Nothing would be deprecated. I don't think we should make assumptions about the internal implementation of a portlet container. We just need to describe external behavior.
        Hide
        andre.hagemeier added a comment -

        Sorry Scott, I guess I mixed up some things here.
        The only question to me is, what to do with the spec and the implementations. I think the implementations cannot be forced to return immutable maps.
        So two possibilities would be left:

        • allow mutable maps in the spec
        • deprecate mutable maps in 362 (but still allow them for backward compatibility) and make immutable ones the default. Therefore, a subclassing approach could be used like above stated.

        Anyway, this issue needs to be documented properly, to make clear why there is a problem at all.

        Show
        andre.hagemeier added a comment - Sorry Scott, I guess I mixed up some things here. The only question to me is, what to do with the spec and the implementations. I think the implementations cannot be forced to return immutable maps. So two possibilities would be left: allow mutable maps in the spec deprecate mutable maps in 362 (but still allow them for backward compatibility) and make immutable ones the default. Therefore, a subclassing approach could be used like above stated. Anyway, this issue needs to be documented properly, to make clear why there is a problem at all.
        Hide
        Neil Griffin added a comment -

        @Scott: I received feedback from my colleagues, and the unanimous response was to have StateAwareResponse.getRenderParameterMap() return an immutable map. This would make the API more clear that the only way to set parameters (with a Map) would be to call StateAwareResponse.setRenderParameters(java.util.Map).

        Show
        Neil Griffin added a comment - @Scott: I received feedback from my colleagues, and the unanimous response was to have StateAwareResponse.getRenderParameterMap() return an immutable map. This would make the API more clear that the only way to set parameters (with a Map) would be to call StateAwareResponse.setRenderParameters(java.util.Map) .
        Hide
        msnicklous added a comment -

        implemented updates for descriptions of BaseURL.getParameterMap() and StateAwareResponse.getRenderParameterMap().

        Show
        msnicklous added a comment - implemented updates for descriptions of BaseURL.getParameterMap() and StateAwareResponse.getRenderParameterMap().

          People

          • Assignee:
            msnicklous
            Reporter:
            msnicklous
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: