Hi, Ian Boston schrieb: > > On 8 Oct 2009, at 11:35, Felix Meschberger wrote: > >> Hi, >> >> Ian Boston schrieb: >>> Hi, >>> While looking at making it possible to bind more than one >>> ResourceProvider to a URL see [1], I noticed that the >>> ResourceProviderEntry appeared to be a very active area of code with a >>> lot of recursion, especially when you actually start to deploy a >>> reasonable number of servlets. This lead me to think that it should be >>> possible to convert the loops into lookups and speed it up. I thought it >>> was simple, a week later I now know its not so simple. >> >> Yes, because the providers are organized in a tree of >> ResourceProviderEntry instances where each entry acts as a node and has >> a list of child entries. >> >> Each Entry has a prefix, which is a partial path. >> >> To find a matching child entry, the list has to be scanned for an entry >> whose prefix matches. >> >> If the prefix would be just names (or labels) instead of partial paths, >> we could build a map of child entries indexed by name and then just walk >> down the tree by indexing into the map. >> >> To do this we would have to create a lot of intermediate entries .... >> >> Now, you can say that the price to pay is the memory consumption of the >> "empty" entries and splitting the path to walk down the tree. But you >> gain faster access (may well be true) and have simpler access -- in fact >> it would probably also simplify the synthetic resource case in the >> getResource(ResourceResolver, String, String) method. > > yes, that is what I thought. > >> >>> >>> Since the whole concept of binding ResourceProviders is probably going >>> to be highly contentious [2] since its intended to allow virtualization >>> of the mapping between URLs and jcr URI's I haven't committed anything. >>> I have put the patch set (which is not completely working ) up [3] at >>> codereview. >>> >>> I have a question before I spend more time. >>> >>> Am I wasting my time ? >> >> The question is, where are you heading ? >> >> At the moment looking at your patch I cannot understand what the >> ResourceProviderEntry2 is all about .... > > > Its the re-implementation of ResourceProviderEntry converting from a > recurse and test to a map of maps based lookup. > > I have left ResourceProviderEntry for reference. > >> >> Are you just adding support to add more than one ResourceProvider to a >> ResourceProviderEntry -- which would kind of solve the issue of >> registration collision. > > yes, this is included in the refactor, but could have been done to the > original > >> >> Or do you want to refactor the ResourceProviderEntry tree ? >> >> Both are ok for me... > > yes both. > >> >>> >>> (Obviously if I am not, I will clean the patch set up and make it work, >>> I believe it may also fix some issues with Servlet Registration) >> >> which ? the ones with servlet path collisions ? > > yes, servlet path collision, I need to check that de-registration really > works. > > *but* > > with 2 servlets registered to the same path I haven't worked out the > order in which they should be used, probably part of the sort order > thats required.
speaking of two servlets at the same path: these are OSGi services and OSGi services as per the spec have a defined ranking: "When registering a service object, a bundle may optionally specify a service.ranking number as one of the service object’s properties. If multiple qualifying service interfaces exist, a service with the highest SERVICE_RANKING number, or when equal to the lowest SERVICE_ID, determines which service object is returned by the Framework." OSGi Core, 5.2.5, Service Properties So, I would assume that we should order according to the serivce.ranking and service.id properties of the registered servlet -- we might pass on these two propreties from the servlet service registration to the ServletResourceProvider registration (though property renaming esp. for the service.id would be required) to order the same named servlets. Regards Felix > >> >> Regards >> Felix >> >>> Ian >>> >>> 1 http://markmail.org/thread/jeh4a7z4i6skkfci >>> 2 http://markmail.org/thread/roumyelolpciboci >>> 3 http://codereview.appspot.com/124094 >>> > >
