I was thinking about this as well. Not protecting certain resources, by extension, may be a very good solution. It's probably easier to implement than my idea, which is to parse CSS files and rewrite URLs.
On 12/25/05, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > I'm writing this message to be sure I haven't misunderstood what the > intentions of the asset service digestion of url strings were/are before I > go breaking them. > > From what I can tell the largest need for protection is that of .class files > because the asset service exposes the inner classloader resources of the > running jvm. This makes sense, but the protection of ALL resources this way > also hurts some other things. > > I'm pondering creating a new hivemind configuration contribution that > defines what types of resources should be protected. This could go the other > way too, where it defines what types of resources ~shouldn't~ be protected, > but the first seems easiest. Initially I'm thinking that only resources > ending in .class file names will be protected. > > This also starts the ball rolling on fixing the other issue we have, which > is the disconnect between the Shell component's js/css includes and those > private assets provided by libraries/components that wish to provide them. I > think that components should be able to auto-include their global resources > into the Shell component somehow. Not sure how yet. It could either be a > default that is allowed, additonally allowing hivemind configuration points > to exclude or disallow all or specific components/libraries from > contributing their global assets. This hints at the IAsset class starting > to have knowledge of types of resources, or at least a configurable string > grouping mechanism. Guess we can figure that one out when we get to it. > > jesse > > -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
