Asset service doesn't really need a configuration point here, imo.
You can already make contributions to services that would allow you
to implement this sort of content filtering.
For instance, you could contribute a RequestFilter. Alternatively,
you could contribute a Dispatcher to teh MasterDispatcher service.
Contributions to MasterDispatcher are ordered, so you can contribute
your "AssetBlockerDispatcher" before the asset service, intercept
requests to "forbidden" assets,
and respond appropriately. You could then make your custom
dispatcher (or request filter) configurable in the manner that you
desire.
You don't rewrite any of the asset service, you get your content
filtering, and you can write it as a drop-in module for any new
projects.
Robert
On Jul 26, 2007, at 7/266:18 PM , Daniel Jue wrote:
Thiago, my apologies. You are correct. I would think this is big a
problem if you can't hide important files from users!
Dan
On 7/26/07, Thiago H de Paula Figueiredo <[EMAIL PROTECTED]> wrote:
On Thu, 26 Jul 2007 16:46:37 -0300, Daniel Jue
<[EMAIL PROTECTED]> wrote:
> Hi, Just don't put configuration resources there.
I'm not sure you had understood what I've said.
My hibernate.cfg.xml is in /src/main/resources. So it is copied by
Eclipse/NetBeans/Maven/whatever to my webapp's classpath. And
anything in
the classpath, as far as I can see, is accessible via
<applicatiourl>/assets. As many frameworks expect their configuration
files to be in the classpath, I think we have a little, easy to solve
problem here. :)
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
