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
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.
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.
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.
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.
-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
