| Summary: | Document use of Virgo Snaps | ||
|---|---|---|---|
| Product: | [RT] Virgo | Reporter: | Chris Frost <eclipse> |
| Component: | documentation | Assignee: | Chris Frost <eclipse> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | dmitry |
| Version: | 3.0.0.M05 | ||
| Target Milestone: | 3.0.0.RC1 | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
| Bug Depends on: | 350865 | ||
| Bug Blocks: | |||
|
Description
Chris Frost
Dmitry, could you look over this ruff table of contents and see if there is anything you think I missed. I think documentation should go into some detail on how request is routed by the SnapFilter. Mention that only single level urls are supported currently. That is /foo/bar is not supported for the snap context prefix. Should also caution against tunneling into host servlet context, request attributes, session attributes as it might cause CCE or other worrisome issues with class-space consistency and versioning (host imports v=1.0.0 and snap 1.1.0 of some support package - and that class sits in the some sort of scope). In my mind snap should be as independent from host as possible and any communication between two (if required) should go through service registry. Host is mostly just an invisible pane around the snap vs. a root_web_app context (in spring terms). Docbook project added in the snaps repo and integrated to the build. Done and pushed to master |