Reinhard Poetz pisze: > ServletSource is only available if you use the ServletService Framework > together with Cocoon. So I think that ServletConnection should become > public API too. > > We could offer two types of ServletConnections: > > * RelativeServletConnection that works relative to the current servlet > context > * AbsoluteServletConnection that expects the servlet service name (= the > name of the Spring bean)
I was wondering why ServletConnection can't be clever enough to figure it out if it's passed a relative URI or absolute one? Why we need separate classes? It's not a big deal for me, just curious. > Actually I've already implemented it this way ... > > WDYT? The biggest mystery for me is why I don't see commit messages mentioning this great stuff being checked in into our repository. Keeping this code in a secret is just not fair! ;-) > For me fixing the cache key generation problem is only a positive side > effect of my current work. I need absolute servlet URIs for a special > generator (or maybe a source, don't know yet) whose output depends on > the available servlet services which makes it impossible to define them > as connections beforehand. > > Probably it's very similar to what you call "dynamic connections". Yep, I guess so. I was thinking about dynamic servlet discovery based on some conditions. For example, I would like to see a generator that lets me to list all servlet giving 200 response when they asked for resource "/org.grek.app.skin.provider". This way I could easily list all skins available for my new, shiny application. Is it something similar to your goals? -- Grzegorz Kossakowski
