Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: XML Configuration
    • Labels:
      None

      Description

      Bill requested reloadable configuration(s)

        Activity

        Hide
        matt baldree added a comment -

        What is the real issue here? What really needs to be dynamic? What is the use case that drives this change? Is it the ability to change the view mapping?

        Checking for the view change and then dumping the view cache and reloading would be pretty easy. But, if we need to make all properties dynamic this would be more involved. So, I'm questioning exactly what we need here.

        Show
        matt baldree added a comment - What is the real issue here? What really needs to be dynamic? What is the use case that drives this change? Is it the ability to change the view mapping? Checking for the view change and then dumping the view cache and reloading would be pretty easy. But, if we need to make all properties dynamic this would be more involved. So, I'm questioning exactly what we need here.
        Hide
        matt baldree added a comment -

        I'm pretty sure I can accomplish this by reloading all configurations. Lets just hold on here and see if I can .

        Show
        matt baldree added a comment - I'm pretty sure I can accomplish this by reloading all configurations. Lets just hold on here and see if I can .
        Hide
        matt baldree added a comment -

        This feature will be tabled for now. After looking into it further, I don't see the need for the configurations to be dynamic. If you feel different please comment accordingly.

        Show
        matt baldree added a comment - This feature will be tabled for now. After looking into it further, I don't see the need for the configurations to be dynamic. If you feel different please comment accordingly.
        Hide
        Aapo Laakkonen added a comment -

        > What is the use case that drives this change?
        > Is it the ability to change the view mapping?

        For me it's just that. And not only change but adding new mappings without restarting the server. And as you say:

        "Checking for the view change and then dumping the view cache and reloading would be pretty easy."

        So why do you not want to do just that? I hate to restart my server everytime I need to add a new mapping or change the existing. It's slow and involves more steps than should be needed (e.g. ssh connection to the server - stop container - start container - exit) instead of just clicking one link that does the whole job as it is implemented in Struts' default reload.do action (it loads all the mappings and all the properties files).

        Show
        Aapo Laakkonen added a comment - > What is the use case that drives this change? > Is it the ability to change the view mapping? For me it's just that. And not only change but adding new mappings without restarting the server. And as you say: "Checking for the view change and then dumping the view cache and reloading would be pretty easy." So why do you not want to do just that? I hate to restart my server everytime I need to add a new mapping or change the existing. It's slow and involves more steps than should be needed (e.g. ssh connection to the server - stop container - start container - exit) instead of just clicking one link that does the whole job as it is implemented in Struts' default reload.do action (it loads all the mappings and all the properties files).
        Hide
        Rickard ?berg added a comment -

        The configuration is pluggable, so just write your own configuration that is more dynamic I guess. Shouldn't be that hard. I don't think this need to be done within WebWork itself. As for updates, most servers these days support hot deployment which should take care of that.

        Show
        Rickard ?berg added a comment - The configuration is pluggable, so just write your own configuration that is more dynamic I guess. Shouldn't be that hard. I don't think this need to be done within WebWork itself. As for updates, most servers these days support hot deployment which should take care of that.
        Hide
        Maurice C. Parker added a comment -

        I agree with Rickard. Even Tomcat 4 and up can support hot deployment. On Tomcat, just by copying the configuration information into your webapp will fire a redeployment. I'm closing this issue.

        Show
        Maurice C. Parker added a comment - I agree with Rickard. Even Tomcat 4 and up can support hot deployment. On Tomcat, just by copying the configuration information into your webapp will fire a redeployment. I'm closing this issue.

          People

          • Assignee:
            matt baldree
            Reporter:
            matt baldree
          • Votes:
            2 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development