Hey All - It seems to me that the proposed API is a result of two more fundamental deficiencies:
1. The servlet spec is lame and does not state that ServletContext implementations must ensure thread-safe access to attributes. 2. ServletContext implementations are lame and have not switched from Hashtable to ConcurrentHashMap. I think that the solution to #1 is to seek a clarification to the spec, since it is clearly bogus that the spec is not clear on this point. Note that the spec has already been updated to be more clear about concurrent access to HttpSession attributes, see the last couple of paragraphs of: http://jcp.org/aboutJava/communityprocess/maintenance/jsr154/servlet-2.5_MR6.html It doesn't seem like that big of a stretch to get a similar clarification for ServletContext - I suspect that the spec is already generally interpreted to imply that the ServletContext provides thread-safe access. Stating this explicitly in the spec does not seem controversial (well, not to me at least). Regarding #2... seems like moving over to ConcurrentHashMap is a no-brainer for servlet implementations which are still stuck on Hashtable. If we are able to satisfy our requirements by going down this route, I would prefer this over adding a somewhat-redundant API to Trinidad (ie. would prefer fixing the underlying problems so that we can use the Application map directly rather than adding a new parallel API.) Andy On Jan 28, 2008 7:56 PM, Gabrielle Crawford <[EMAIL PROTECTED]> wrote: > Hi, > > In case anyone filtered away the [jira] message..... > > I'd like to add the method described below to the requestContext. > > Comments? Objections? > > Thanks, > > Gab > > -------- Original Message -------- > > add method to get an application scoped concurrentMap to RequestContext > ----------------------------------------------------------------------- > > Key: TRINIDAD-926 > URL: https://issues.apache.org/jira/browse/TRINIDAD-926 > Project: MyFaces Trinidad > Issue Type: Improvement > Affects Versions: 1.2.5-core, 1.0.5-core > Reporter: Gabrielle Crawford > Assignee: Gabrielle Crawford > Priority: Minor > > > This started with Trin Issue 891 > https://issues.apache.org/jira/browse/TRINIDAD-891 > > To avoid the locking in the class loader we'd like to store a map of > name->class per app. However the external context app map calls through to > the ServletContext. The Servlet specification doesn't specify whether the > ServletContext performs any locking on the ServletContext attributes and the > ServletContext doesn't expose the necessary methods for efficient concurrent > access (essentially the operations exposed on ConcurrentMap) necessary to > work efficiently in many cases even if the ServletContext didn't need to > perform locking on reads. The result is that the ExternalContext's > ApplicationMap can't implement ConcurrentMap. > > We'd like to add a method to the RequestContext to get an application scoped > concurrent map. This would not call through to the servlet context. The api > proposed is this: > > > /** > * Gets a per application concurrent map. There is no synchronization > * with ServletContext attributes. > */ > public abstract ConcurrentMap<String, Object> > getApplicationScopedConcurrentMap(); > > > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > >
