Can we generalize this somehow? The following sounds a little bit dangerous/strange/fragile, but I would assume that if a taglib is deployed in a bundle, it is safe to assume it does not use any internals and therefore just works with the current setup.
However, as in this case, the taglib is provided by the environment and does nasty things like casting to implementations etc. So, we could use the original jsp factory whenever a tag is used which is coming from the env whereas we use the sling jsp factory whenever the taglib is deployed as a plain bundle. To make this decision more robust, we could make a configuration for which taglibs, the original jsp factory should be set before calling into the taglib. Regards Carsten Justin Edelson wrote > I've managed to fix the cross-context c:import problem described here: > http://sling.markmail.org/thread/zux7mejcuvegidoe > > In short, the fix is to include an implementation of JSTL in the JSP > bundle and slightly modify the import tag implementation to reset the > JspFactory to the original default before doing a cross-context > include. > > Overall patch is here: http://codereview.appspot.com/4442079. This is > using the current trunk version of JSTL from Tomcat. It doesn't appear > Tomcat has formerly released JSTL version 1.2. > > The specific changes I made are here: > http://codereview.appspot.com/4442079/patch/1/29 (search for Sling > Custom). > > At present, this *has* to be fixed in the JSP Scripting bundle because > going back to the original JspFactory uses an internal class > (JspRuntimeContext; see > http://codereview.appspot.com/4442079/patch/1/20). Although adding the > whole JSTL library to the JSP scripting bundle is a bit extreme, I > think it is more sensible than exporting the JspRuntimeContext class. > > WDYT? > > Justin > -- Carsten Ziegeler [email protected]
