Hi Am 11.10.2013 um 12:40 schrieb dan mcweeney:
> Based on the information in SLING-387[0], there is the possibility of > getting into a situation where the selection of the script is difficult > to predict. Basically if you have a resource that has two scripts: > > /path/to/resource/print.esp > /path/to/resource/print.jsp Yes, this is known but extremely esoteric problem. In fact in the years since we built this, we never really had an actualy issue with this. The actual order of resolution, IIRC is the order of finding the scripts. So basically it is the order in which the repository reports the scripts. > > The script resolver choses the "first" one in the list. I'd really like > to get rid of this, slightly nondeterminsitic behavior. The way I see > there are a few options to solve this ( listed in no particular order ): > > 1. Use the service ranking from the avaliable engines to break the tie. > This would require the SlingServletResolver[1] to take a bit more of an > interest in the activation / deactivation of the Script Engines. Right > now it just gets the event and invalidates a cache. It could hold onto > the registered extension and service ranking information and allow it to > make a choice between esp and jsp based on which engine has a higher > ranking. This is not practical and I would vote against it. The SlingScriptResolver might react to such events but that is about all the resolver really cares about script engines. Doing more would IMHO violate separation of concern principles and be impractical. > > 2. Create a "bias" in the resolver servlet to break the tie when it > occurs. Basically, add a new OSGI property to the > SlingServletResolver[1] that will add an extra weight to the script that > has the "biased" script extension. This could also be an order list > instead of just a simple string. That sounds like an option. The default, nevertheless, would be an empty option and thus no particular order. > > 3. Each resource could have a property that would bias it to a > particular script extension, the parent resource in question is > available during the script resolution so, the locality of the change is > small[2]. However, introducting a new property to break these sorts of > ties seems like a really big hammer to fix this issue. Nope, again this breaks separation of concern. The resource type is one indication of resolving a script and the script extension is not part of this indication. In fact the resource and its type are agnostic of any script languages supported. > > Comments / thoughts on approaches would be great, I can even submit my > quick hack ( which was option 2 ) as a starting point if people think > the second option is actually viable. Do you really stumble upon this problem and have to solve it ? IMHO have the same script base name with different extensions in the same location is not very good practice. And neither of the above solutions actually helps the developer finding out, which script actually will be used. So rather that trying to come up with a solution, I suggest, we just discourage such behaviour. So I would be in favor of an option 4 to document this problem but to suggest to prevent it from happening. Regards Felix > > -d > > [0] - https://issues.apache.org/jira/browse/SLING-387 > [1] - > http://svn.apache.org/viewvc/sling/trunk/bundles/servlets/resolver/src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java?view=markup > [2] - > http://svn.apache.org/viewvc/sling/trunk/bundles/servlets/resolver/src/main/java/org/apache/sling/servlets/resolver/internal/helper/AbstractResourceCollector.java?view=markup > >
smime.p7s
Description: S/MIME cryptographic signature
