The core issue is that JSP compiler does not use classloaders during
compilation. So there is lack of fidelity between jsp compilation and
jsp runtime.
Sahoo
On Tuesday 14 February 2012 02:53 AM, Dhiru Pandey wrote:
> It appears that the issue was erroneously marked "Fix Version/s: 3.1". Unfortunately there is little information in the activity stream to indicate who and when that was done. I suspect something happened in data migration when we transitioned over from Issuetracker (CollabNet based java.net) to Jira (Kenai based java.net) back in 2010.
>
> Class loader hierarchy has gone thru a major change from GlassFish v2 to GlassFish v3 which may be a source of your problem.
>
> In any case, It would be great if you could provide us more details on this issue so that we can try to provide a solution to this. Can I please request you for the following:
> - Attach a small test case to this issue that exhibits the problem
> - Add some code sample on the strategy that was used with "tomcat and jetty we worked it around by creating a jsp servlet per plugin with properly set classloader" which failed on GlassFish 3.
>
> Apologies for the erroneous data on this issue --- I'll fix that
> -Dhiru
>
> On 2/13/12 11:32 AM, Noah White wrote:
>> Hi Folks,
>>
>> I am running into a problem using Jetbrain's TeamCity web application under GF 3.1. It works fine under GF2. Glassfish bug http://java.net/jira/browse/GLASSFISH-11791 is referenced as the issue. This bug was filed back in April of '10 and was marked "Fix Version/s: 3.1" yet the bug is also still OPEN. 3.1 has obviously shipped. Has this bug dropped into a black hole? Thanks,
>>
>> -Noah
>>