[jira] Created: (COCOON-2239) Add support for servlet protocol in flow's sendPage
Add support for servlet protocol in flow's sendPage --- Key: COCOON-2239 URL: https://issues.apache.org/jira/browse/COCOON-2239 Project: Cocoon Issue Type: Task Components: - Components: Sitemap, - Flowscript Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Assignee: Grzegorz Kossakowski The idea of this task is introduce support for servlet: protocol in sendPage calls. Current behaviour is that if one called sendPage(some/path) it will get translated into redirection to cocoon:/some/path so any custom protocol is disallowed in sendPage calls. I would like to introduce support for sendPage(servlet:/some/path) calls that explicitly make use of servlet: protocol. In such case, processing should be redirected to ServletSource and SSF machinery. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (COCOON-2239) Add support for servlet protocol in flow's sendPage
Grzegorz Kossakowski (JIRA) pisze: Add support for servlet protocol in flow's sendPage --- Key: COCOON-2239 URL: https://issues.apache.org/jira/browse/COCOON-2239 Project: Cocoon Issue Type: Task Components: - Components: Sitemap, - Flowscript Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Assignee: Grzegorz Kossakowski The idea of this task is introduce support for servlet: protocol in sendPage calls. Current behaviour is that if one called sendPage(some/path) it will get translated into redirection to cocoon:/some/path so any custom protocol is disallowed in sendPage calls. I would like to introduce support for sendPage(servlet:/some/path) calls that explicitly make use of servlet: protocol. In such case, processing should be redirected to ServletSource and SSF machinery. As description of this issue states I want to introduce support for servlet: protocol in flow's sendPage function so people can use it instead of cocoon: protocol that is enforced by hard-coded functionality in AbstractInterpreter class. If nobody objects I'll start adding support for this feature tomorrow. One important note: This support won't introduce any hard dependency on SSF neither in Cocoon's core nor in flow implementations. -- Grzegorz Kossakowski