Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 317133

Summary:

Third-party plug-in providing javax.servlet.jsp.el version 2.1 or greater breaks WPE preview

Product:

[Tools] Orbit

Reporter:

Ian Trimble <ian.trimble>

Component:

bundles

Assignee:

David Williams <david_williams>

Status:

RESOLVED WONTFIX

QA Contact:

Severity:

major

Priority:

CC:

david_williams, hmalphettes, raghunathan.srinivasan

Version:

unspecified

Keywords:

info

Target Milestone:

---

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
Removes dependency on commons.el	none
Updated docs.	none

Description Ian Trimble

2010-06-16 20:33:01 EDT

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.

Comment 1 David Williams

2010-06-17 01:09:10 EDT

so this is an orbit bug?

Comment 2 Raghunathan Srinivasan

2010-06-17 01:30:56 EDT

Yes, the Orbit bundle in Helios for org.apache.commons.el is more restrictive compared to Galileo.

Comment 3 David Williams

2010-06-17 01:41:33 EDT

Thanks ... I've investigated some and see the history for this change is documented in bug 301263.  I've only skimmed it tonight ... not sure if there's any useful "how to solve" information there ... just wanted to cross reference.

Comment 4 Cameron Bateman

2010-08-19 14:41:13 EDT

Created attachment 177037 [details]
Removes dependency on commons.el

Comment 5 Cameron Bateman

2010-08-19 14:58:21 EDT

Created attachment 177038 [details]
Updated docs.

Comment 6 Raghunathan Srinivasan

2010-08-24 14:15:04 EDT

Please review this issue for the Indigo release.

Comment 7 David Williams

2010-08-24 16:12:56 EDT

What do you mean by review? Do you have a recommendation on how to fix in Orbit? Is that what the "update docs" are for? (even though in your code, right?) Or did you mean to get advice on how clients such as yourself should handle. (Sorry, I've just skim read the issues, and patches, so sorry if its obvious to others). 
 
Or, have I misunderstood? 

I am assigning to Simon for now. But adding Hugues Malphettes to CC in case he's a better owner?

Comment 8 Hugues Malphettes

2010-08-24 16:32:38 EDT

As Raghu mentioned in comment 2, the org.apache.commons.el is more restrictive for helios than galileo.

Simon pro-actively made it more restrictive to make sure that the new javax.servlet.jsp 2.1 that I maintain in orbit will not be picked up by existing plugins.

Comment 9 David Williams

2010-11-02 21:55:49 EDT

So ... is there anything for us in Orbit to do here? Or is this just a case where we broke some adopters, but there's no good fix that solves all uses/needs ... or is there something we should do for Indigo? 

If nothing to do, let's mark it as 'info' and resolve as won't fix?

Comment 10 David Williams

2010-12-03 10:51:37 EST

Since no comments, will mark as "won't fix". 

Seems there should be a lesson to learn, here, but not sure what it is. I guess it'd be something like "don't make pre-req ranges more restrictive from one release to another ... at least, be aware this is a compatibility breaker, at least in some cases". I'm not sure we can easily revert, at this point, without risking other breakages? 

If I have misunderstood, and someone wants to suggest a concrete fix, please say so .... and then I'll assign back to Simon :) for his evaluation.