webwork的一个缺陷

webwork使用快半年了，感觉比较遗憾，虽然其框架设计方面以及功能性相对struts来说有一定的优势，但是有很多地方都有致命性的问题（现在还为我已经上线的系统担忧），其中主要有：
1、采用ognl为对象封装页面的数据时会出现运行一段时间后，会出现致命异常，导致异常发生后的无法再封装页面的数据（虽然频率很低）
2、还有以前已经提出的问题（压力测试异常）。
今天和同事定位一个奇怪问题:
<action name="testaction" class="com.xx.xx.AssignAction">
<result name="success" type="redirect">
<param name="location">
/xx/xx.jsp?${returnurl}
</param>
</result>
</action>

其在对应参数传递页面的查询值，结果如果有":"的值时对应的url调转就有问题
看了一下原码：
发现webwork是这样处理的，有点惊讶：
如果对应url中有":"号，webwork就认为是一个原始请求，直接就redirect到对应的配置url，否则webwork就会从当前应用的名称和命名空间封装出请求。
感觉webwork对是否是原始请求的判断不太严谨。

个人对webwork整体还是比较欣赏的，但对一个开发框架来说，稳定，健壮是最重要的，如果一个框架功能再多，结构再好，老是出问题的话就不好了，呵呵。

提出上述问题只是希望以后的版本能够更好，大家用的时候避免上述问题，
顺便和大家交流使用中的问题，达到资源共享。

你不编码就传啊...

我觉得大部分可能是基础知识储备不足造成的

我们公司一些比较"新"的人的"怪异问题"也很多的,而且造成的"怪异问题"也很多

webwork肯定会有一些问题,但是关键在于我们的态度...想解决就得仔细研究研究

ognl竟然还有这种问题？楼主可查过原因？

第二个问题楼主的url中咋会出现“:”这么奇怪的符号？

为什么不能有呢？用户想输入什么就是什么

从规范上看，":"的确是属于常规字符。楼主传":"号也无可厚非。

本人从事j2ee开发四年了，从事千万级项目已经有四五个，自问还不是新人，呵呵。
关于第二个问题楼主的url中咋会出现“:”这么奇怪的符号？
是同事采用get方式处理查询参数
如test.action?date=2004-09-12 12:45
一楼的提出的方式我们都考虑过，但建议你看看webwork的实现机制再说。
webwork本身实现时认为开发者的处理的url不应该是已经编码的。

protected void doExecute(String finalLocation, ActionInvocation invocation) throws Exception {
        HttpServletRequest request = ServletActionContext.getRequest();
        HttpServletResponse response = ServletActionContext.getResponse();

        if (isPathUrl(finalLocation)) {
            if (!finalLocation.startsWith("/")) {
                String actionPath = request.getServletPath();
                String namespace = ServletDispatcher.getNamespaceFromServletPath(actionPath);

                if ((namespace != null) && (namespace.length() > 0)) {
                    finalLocation = namespace + "/" + finalLocation;
                } else {
                    finalLocation = "/" + finalLocation;
                }
            }

            // if the URL's are relative to the servlet context, append the servlet context path
            if (prependServletContext && (request.getContextPath() != null) && (request.getContextPath().length() > 0)) {
                finalLocation = request.getContextPath() + finalLocation;
            }

            finalLocation = response.encodeRedirectURL(finalLocation);
        }

        if (log.isDebugEnabled()) {
            log.debug("Redirecting to finalLocation " + finalLocation);
        }

        response.sendRedirect(finalLocation);
    }

    private static boolean isPathUrl(String url) {
        // filter out "http:", "https:", "mailto:", "file:", "ftp:"
        // since the only valid places for : in URL's is before the path specification
        // either before the port, or after the protocol
        return (url.indexOf(':') == -1);
    }

Agree



任何通过get方式传递的参数都应该考虑用URL Encoding，尤其是当产生的URL不可预知时。

ww2.1.x还有一个很大的缺陷，Exception的处理
在ServletDispachter.serviceAction里面，把Exception拦下来，interceptor就无法处理了

不错！我们正为这个事情头疼呢！而且一旦出错，系统只能重新部署。
请问兄台是如何解决此问题的？

程序都出错了，你还要硬往下执行，有意思吗？