[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [virgo-dev] [snaps] what's next?
- From: Glyn Normington <gnormington@xxxxxxxxxx>
- Date: Thu, 22 Jul 2010 07:54:02 -0700
- Accept-language: en-US
- Acceptlanguage: en-US
- Delivered-to: firstname.lastname@example.org
- Thread-index: AcsprbnuXeHCZr3HR06eMQqeTLJbSg==
- Thread-topic: [virgo-dev] [snaps] what's next?
I don't have any strong opinions, but I've drawn together the list of relevant SpringSource JIRAs  for anyone who wants to read them and I've added a pointer to this thread to those issues which were raised by users (rather than SpringSource engineers).
On 22 Jul 2010, at 15:18, Dmitry Sklyut wrote:
I wonder what else can be done with spans? What was left in the SpringSource jira with regards to slices? Should any of that stuff be examined for inclusion?
>From my view point, there are few things that I would like to have:
1. Well known strategy for including/excluding servlet context/session/request attributes.
For example, we ran into an issue with both host and snap as Spring MVC apps. Both would try to add their SpringMVC attributes to the servlet context/request attributes. Things like bellow:
public static final String HANDLER_EXECUTION_CHAIN_ATTRIBUTE = DispatcherServlet.class.getName() + ".HANDLER";
public static final String WEB_APPLICATION_CONTEXT_ATTRIBUTE = DispatcherServlet.class.getName() + ".CONTEXT";
public static final String LOCALE_RESOLVER_ATTRIBUTE = DispatcherServlet.class.getName() + ".LOCALE_RESOLVER";
public static final String THEME_RESOLVER_ATTRIBUTE = DispatcherServlet.class.getName() + ".THEME_RESOLVER";
public static final String THEME_SOURCE_ATTRIBUTE = DispatcherServlet.class.getName() + ".THEME_SOURCE";
I fairly sure other frameworks make assumptions based on some conventions.
2. Allowing snaps placing stuff in a session to be visible to host. That is sharing session space between host and snap(s)
3. Lock down semantics of request path handling/parsing. This is kind of related to https://issuetracker.springsource.com/browse/DMS-2311.
All of these ideas will need some research. For example - do snaps allow placing of stuff in servlet context/session if host does not have visibility into types? Should it be an error or a warning?
URL/path handling will need to define very clear semantics. Should snaps always treat snap as an independent web-app and decorate request in a way that consistent with a snap as a web module?
Are there any other wishes and ideas that users have?