I'm ready to commit this, but I guess I will wait until Don cuts the new build. This is how it works:
1. Static content lookup was refactored to DefaultStaticContentLoader which implements StaticContentLoader. 2. DefaultStaticContentLoader does everything FilterDipatcher did before, but it also searches for resources inside a folder called "static". So users don't have to call the folder "struts". New folders can be added passing parameters to FilterDispatcher, like before, but the urls have to starts with "/static" so we have some way to identify them. 3. New extension point added "struts.staticContentLoader" to provide a custom loader So the 2 uses cases are: 1. User wants to add a new resource called "test.js" to her plugin. She adds this file under "/static/test.js" and builds the url like: <s:url value="/static/test.js" ..> 2. User wants to add a new resource called "test.js" to her plugin under folder "/super_folder/test.js". She adds a parameter to the filter: <filter-class>org.apache.struts2.dispatcher.FilterDispatcher</filter-class> <init-param> <param-name>pathPrefixes</param-name> <param-value>/super_folder</param-value> </init-param> and builds the url like: <s:url value="/static/test.js" ..> musachy On Wed, Apr 30, 2008 at 10:35 PM, Jeromy Evans <[EMAIL PROTECTED]> wrote: > Musachy Barroso wrote: > > > I am refactoring that out of FilterDispatcher so it becomes another > > extension point. > > > > musachy > > > > > > > +1 > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "Hey you! Would you help me to carry the stone?" Pink Floyd --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]