Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[virgo-dev] [snaps] what's next?

Hi All,

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?

Regards,

Dmitry

Back to the top