|
Mantis - Resin
|
|||||
| Viewing Issue Advanced Details | |||||
|
|
|||||
| ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
| 872 | minor | always | 01-17-06 13:38 | 01-24-06 14:43 | |
|
|
|||||
| Reporter: | ferg | Platform: | |||
| Assigned To: | OS: | ||||
| Priority: | urgent | OS Version: | |||
| Status: | closed | Product Version: | |||
| Product Build: | Resolution: | fixed | |||
| Projection: | none | ||||
| ETA: | none | Fixed in Version: | 3.0.18 | ||
|
|
|||||
| Summary: | 0000872: jspx compilation problems | ||||
| Description: |
(rep by Bill Au) This problem exits in 3.0.17 as well. I have come up with a simpler example/test case for this problem. I am enclosing my test case which consists of two jspx (helloworld.jspx and fetch-common.jspx). I have tried compiling the jspx in three different ways: 1) JspPrecompileListener. Access to helloworld.jspx works. The generated java code is attached as _helloworld__jspx.java.JspPrecompileListener. 2) JspCompiler. Access to helloworld.jspx works. The generated java code is attached as _helloworld__jspx.java.JspCompiler. 3) I removed all the generated .java, .class, and .smap files ant then access helloworld.jxps, causing the page to be compiled at real time. The output response is not correct. The generated java code is attached as _helloworld__jspx.java.realtime. The good response output (helloworld.out.good) and bad response output (helloworld.out.bad) are also attached. In the bad output, the embedded <c:set> from the included jspx wasn't being compiled to its executable implementation. It is just literally included in the final output. We have also seen cases where the URL being assigned to the variable set by <c:set> is not correct (a non-well-formed error). I think this later case is what I add reported last Friday. |
||||
| Steps To Reproduce: | |||||
| Additional Information: | |||||
| Relationships | |||||
| Attached Files: | |||||
| Notes | |||||
|
|
|||||
|
|
||||
|
|
|||||
|
|
||||