DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=38343>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38343 ------- Additional Comments From [EMAIL PROTECTED] 2006-03-08 05:07 ------- (In reply to comment #27) > 1) EventDispatchAction duplicates much (all?) of the dispatching code of > EventActionDispatcher. I understand XYZDispatchAction classes are convienent, > and while I prefer them to be phased out, other people may find them easy to > have pre-built functionality out of the box. That's fine. My only > recommendation here is that EventDispatchAction should use > EventActionDispatcher internally. I think that would be a more organized > approach to code maintenance and still provide the convienence Action > classes you seek. There is a slight difference between implementations that extend DispatchAction and those that use an ActionDispatcher. In the case of DispatchAction implementations the "unspecified" method is a protected method and isn't publically exposed. For Action implementations that use ActionDispatcher, unless the Action is in the same package as the ActionDispatcher, then the "unspecified" needs to be public. The same is also true for the "cancelled" method. For this reason my preference is to not use EventActionDispatcher in the EventDispatchAction - it keeps EventDispatchAction consistent with other DispatchAction flavours. > 2) The JavaDoc reads in regards to not finding a match: "null is returned which > means the unspecified method will be invoked." I believe you have changed the > functionality so null is no longer returned, which means "unspecified" is no > longer invoked. Can you confirm this? > if (defaultMethodName == null || defaultMethodName.length() == 0) { > String message = > messages.getMessage("event.parameter", mapping.getPath()); > LOG.error(message + " " + parameter); > throw new ServletException(message); > } > I think above ^^^ is the issue. Didn't you already modify the base class to > prevent the exception message from exposing the method? Was that the rationale > behind this addition? Yes you have a point here. Its late so I'll look at this tommorrow. The base class was modified to not expose input parameters, but it does display the mapping's parameter. In the case of this flavour though, it seemed wrong to expose the mapping's parameter (and therefore method names), when theres a facility to "obfuscate" the method names. I think I was trying to save having to override the unspecified method - but it looks like I've made a mistake :-( > (3) I am okay with you removing the "impliedSingleDefault" feature. I still > want that for my code base, so I will privately override > EventActionDispatcher. OK good. Thanks for the feedback. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
