Vadim Gritsenko pisze: > Grzegorz Kossakowski wrote: >> Vadim Gritsenko pisze: >> >> servlet: + map:mount combo is bad idea either because contexts would >> not be resolved correctly. I >> mean: if use URL like "servlet:/something" in mounted sitemap Cocoon >> resolve it using base sitemap. > > Ok but what about "servlet://something"? In other words, are there any > differences between "cocoon://" (note double slash) and "servlet:/"?
None apart from the fact that the environment is not shared when servlet:/ is used. Note that there is no servlet://, at least as far as I know. >> Of course we could fix that quite easily but the question is why to do >> that? > > Personally I can live without "cocoon:/" (single slash), so I'm fine if > it goes away. > > >> Instead of using servlet: protocol + map:mount you should just create >> several separate >> SitemapServlet beans mounted at different paths > > But this would not provide same functionality as <map:mount>. It would > not give same sitemap procession logic, would not give same error > handling capabilities, and would not have same container hierarchy. What do you mean by "sitemap procession logic" exactly? When it comes to error handling capabilities - agreed, this is a serious functionality loss. On the other hand, I would like to have sitemap more self-contained not relying on their position in sitemap hierarchy. In order to avoid bloating sitemaps by the same error-handling constructs you could use a shared block that would handle errors. Other sitemaps would delegate error handling by using postable source. Why do you need a container hierarchy? I'm just wondering if there is a really, really good use case for container hierarchy. Could you give examples? >> or split your application into a few blocks if it makes sense. > > This is not really feasible, not for another 2-3 years... Why? >> Anyway, general thought that servlet: protocol + creation of several >> SitemapServlet beans offer >> similar functionality to cocoon: protocol + map:mount is right. > > Hm I don't think I agree. Not a problem for now as I'm happy to continue discussion as long as there are a new arguments being revealed. Anyway, I really think we should not stop the evolution. I wonder how many people share my feelings that we badly need to cut some of the crappy code of our core if we want to move on. The first step to do this is deprecate, the second is to provide good replacements and Servlet Service Framework is a good *candidate* IMHO. The third step would to remove that code in the end but it's not going to happen in the month. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
