Community
Participate
Working Groups
When a third-party plug-in provides the package javax.servlet.jsp.el at version 2.1 or greater, WPE preview is broken (empty pane, LinkageError in log). This is because WPE preview uses org.apache.commons.el, provided by the platform as an Orbit bundle (v1.0.0), which has a constraint of "[2.0,2.1)" (2.0 or greater, but less than 2.1). Spring IDE does just this. If it manages to load javax.servlet.jsp.el.VariableResolver (v2.1) before the use of org.apache.commons.el, the org.apache.commons.el bundle refuses to use the v2.1 class and a LinkageError occurs. That is, Spring IDE disallows the platform-provided apache commons EL Orbit bundle to be used. This is not exactly the same issue as bug 222675, but there are similarities, so it's worth browsing the discussion there. We resolved that bug by using Import-Package instead of Require-Bundle. Here, we don't have the same liberty, though, since our bundles are currently ok with whatever version they get; it is the org.apache.commons.el Orbit bundle which is refusing to work with Spring's (or other's) JSP 2.1. In Galileo, the Orbit bundle supplied with the platform IS NOT prevented from working with JSP 2.1, and WPE preview works fine even with Spring IDE present. We need a two-pronged approach: 1) We need to find a better solution that is not so fragile and liabel to break as long as there are such Orbit issues - we need to stop using org.apache.commons.el, if at all possible. 2) We need to provide an extension point and interface that allows an adopter to plug-in their own EL resolver, and only use our (hopefully new) solution as a fall-back in cases where no adopter has supplied a resolver.
See Bug 317133 for the patch. Bug 317133 is an Orbit issue, the patch there only modifies JSF Tools to circumvent the issue and does nothing to correct the Orbit issue. We need to use that patch to correct this issue.
Created attachment 177271 [details] Patch as attached to previously-mentioned Orbit bug; copied here for completeness.
The patch will break the WPE preview feature. We will work on a solution in the next release.
Created attachment 190945 [details] Patch removed dependency that causes issues The patch provides an extension point that allows a third-party to plug in an EL resolver (such that it can be more advanced than the simple default we have always had), and provides a simple default resolver that does what the one-and-only built-in resolver always did. While performing the same function, the simple default resolver no longer has the dependency that causes issues when plug-ins not using javax.servlet.jsp and org.apache.commons.el as provided by the platform (such as Spring IDE plug-ins) are introduced.
Post-M6 exception.
I've no idea if this is the right technical solution, but I know it needs to be solved, so I'm assuming you've gotten the right technical support/review you need and I'm marking as approved. And not sure if (directly) related, but it appears the versions of javax.servlet and javax.servlet.jsp will be incremented soon in Orbit, and I'd assume would be in some versions of our "stack". See bug 339966 and bug 339967. Just another case where our "IDE" needs to be independent of "runtime" levels. Thanks very much.
Thanks, David. We needed to remove our dependency on the platform-provided (Orbit) EL library (and its dependencies, such as Apache Commons EL), since we are then easily broken by other products that choose to not use the same version of this library. (In our case, it was Spring IDE that brought a newer version with it and broke our preview functionality.) There is some discussion in bug 317133 (originally logged against the JSF Tools project, but reassigned to Orbit) with more specifics, but I don't think there's a core issue that can be fixed for all users in all cases. We can only manage our own "stack" - adopters and even end users are, of course, free to build their own. Fix submitted at 2011/03/16 10:26AM PDT.
