Am 25.10.2012 07:55, schrieb Felix Meschberger:> I could imagine we define Permissions that a bundle might require to > register servlets and filters with patterns. From an implementations and > configurations point of view, this is probably a simple solution. The > drawback is, that it requires security to be turned on and the > Conditional Permission Admin Service be deployed.
I like that approach. It's a reasonable requirement (IMHO). If you want to limit registrations to certain namespaces you likely also want to limit other things (like service usage, etc.). > One solution would maybe be to use the shared Http Session as a > proxy session: This session is referred to in the cookie. But the attributes > in the Session are the actual sessions, that are used by the respective > Servlet Context. This would require the Http Service implementation to > actually implement Session management. Ah yes, the cookie issue ... So having session management in the HttpService probably complicates things. Things like session serialization and session inactivity are well implemented by the containers. Having a small proxy session (per HttpContex) sounds like a lighter approach. The container still manages the global, shared session. However, each HttpContext is isolated and can decide by itself if a session should be invalidated before the shared session expires. But overall they are still bound to the lifecycle of the global session. The key under which the HttpContext local sessions are stored in the global session must be the same across different frameworks. Thus, in case the container has sessions stored in a database (memcache, whatever) they can also be accessed by other servers. > Maybe that makes perfect sense and the specification might have > non-normative wording to propose such an implementation in addition to > require Http Sessions to be managed per Servlet Context. > > Does this help ? Yes, thanks a lot! -Gunnar -- Gunnar Wagenknecht [email protected] http://wagenknecht.org/ _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
