Grzegorz Kossakowski wrote:
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.
Ok, good to know. What do you mean "not shared"? Does it mean request parameters
of original response are not available?
Note that there
is no servlet://, at least as far as I know.
Yep
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?
Stuff which could be done before mount; "intercepting" request before they drop
into sub sitemap; stuff which can be done after mount if sub-sitemap returns
w/out response; providing "default" handlers.
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.
If it is more self-contained, it becomes less reusable. For example, same error
handling can not be good for all situations. E.g., compare internal error
handling vs external error handling.
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?
For example, to provide isolation between different parts of application(s)... I
imagine portal block might be a heavy user of this. Is it?
or split your application into a few blocks if it makes sense.
This is not really feasible, not for another 2-3 years...
Why?
Today's hardware is too slow for Cocoon + Maven 2... :(
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 first step IMHO should be to make sure core Cocoon 2.1 functionality is
working. Take a look at "Core Samples". Once all of them are working I'd be more
comfortable discussing all other steps.
Vadim
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.
