On 9/9/05, Rick Reumann <[EMAIL PROTECTED]> wrote: > > Craig McClanahan wrote the following on 9/9/2005 12:18 PM: > > > For Shale in particular, the "application controller" part of Shale is > > implemented as a Commons Chain chain (similar in spirit to what's going > on > > with Struts 1.3's request processor), so you can also implement a check > like > > this as one of the commands that gets executed on every request. To set > up > > such commands, simply configure a chain named "preprocess" in catalog > > "shale" and it will get executed for you on every request. > > Is there a particular example that demonstrates this in the shale > examples. I see the chain-config.xml listed so would the set up for our > apps just need to .. > > 1) Include shale jars > > 2) create chain-config.xml > > <catalogs> > > <!-- Define preprocessing command chain for Shale to execute --> > <catalog name="shale"> > <!-- Disallow direct access to JSP and JSFP resources --> > <chain name="preprocess"> > <command > className="org.apache.shale.application.ContextRelativePathFilter" > > includes="\S*\.faces,\S*\.html,\S*\.gif,\S*\.jpg,/index\.jsp" > excludes="\S*\.jsp,\S*\.jspf"/> > </chain> > </catalog> > > ... > </catalogs>
The code above is quoted from the Shale "use cases" example, and illustrates how you can disallow direct access to a JSP page. 3) we would provide a ContextRelativePathFilter class (Is this just a > standard class implementing Filter?) "Use the source, Luke" :-) No, it doesn't implement javax.servlet.Filter ... it implements org.apache.commons.chain.Command. This is a Shale-specific *alternative* to using servlet filters. Another dumb question since I'm new to using this chain of command set > up... If I wanted other Filters to fire in the preprocess based on other > include/exclude pattern matching, would I just include another command > right beneath (using this example above) the ContextRelativePathFilter > command? Yes ... the commands are fired the order they are configured in the chain. If so, does the chain break as soon as the first pattern match > is found and that filter executes or does it continue to try to match > the patterns in other commands? Chain "breakage" is triggered by a command that returns true instead of false from its execute() method. If you do this, the normal JSF processing for the request will not happen, so you had better have completed the response yourself. In the particular case of this filter, there are two possible outcomes: * Don't break the chain -- calls the accept() method from AbstractRegExpFilter, which does nothing by default, then return false so that the chain will continue. * Break the chain -- calls the reject() method from AbstractRegExpFilter, which sends an HTTP "forbidden" message by default, then return true so that the chain will stop. If you decide to break the chain, that means the normal JSF lifecycle won't happen ... so it is up to you to complete the HTTP response instead. If you were using servlet filters to implement this functionality, you would accomplish the same thing by simply *not* calling chain.doFilter() to pass the request on. Thanks > > > -- > Rick Craig
