I posted an alternate version: http://codereview.appspot.com/4423069
This version creates a new method in org.apache.sling.scripting.jsp.util.TagUtil called doWithOriginalJspFactory which enables other tags to execute some bit of logic using the original JspFactory. It still internalizes the JSTL implementation (which still requires modification in the c:import tag implementation to execute this method, but now it would be possible to move the JSTL implementation to a new bundle. WDYT? On Tue, Apr 26, 2011 at 8:55 AM, Justin Edelson <[email protected]> wrote: > But the taglib isn't exported by the environment - the taglib in this case is > the Jakarta (now Tomcat) JSTL implementation, repackaged into an OSGi bundle > and shipped as part of our commercial product. > > The 'nasty' bits are in the Java code generated by the WebLogic JSP compiler. > Arguably, this is a bug in WebLogic, but I doubt Oracle is going to change > this anytime soon. So I'm suggesting we accommodate their implementation. > > The decision to use the original JspFactory or the Sling JspFactory has to be > done inside the tag logic, not around it as you're suggesting - in this case, > we only want to use the original if the context attribute is pointing to > another context. If it is an internal import, the Sling factory is fine. > > Justin > > On Apr 26, 2011, at 5:41 AM, Carsten Ziegeler <[email protected]> wrote: > >> 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] >
