Problem:
- WebSphere can serve the pages as exported from the
EAR file. A problem occurs when pages are edited. When using AAT, files in
the base path seem to have the ^M, put on one line. So very long JSP or
HTML files in the base path become difficult to edit, if they can be
opened at all (due to a line is too long error). It is as if the program
attempts to convert the CRLF (Carriage Return Line Feed), but removes the
wrong character for all files but doesn't recurse through the directory
path.
- The functional problem is that manual interventions
to edit HTML, JSP, or XML files are not always possible, as most AIX
editors do not handle the ^M properly in all situations (as with UTF-8 XML
files). A new EAR file is required to fix files within an application or
the file need to be processed through a utility that properly handles the
CRLF conversions. Most multi-platform products do some sort of handling
for CRLF conversion (e.g. CMVC, Websphere Studio). Prior to J2EE,
Websphere Studio would handle this when publishing HTML, JSP, and XML
files.
Solution (defect against WSAD
component):
No changes to publishing support to accommodate
changing End Of Line (EOD) characters. WSAD has improved EOL handling for
editors for V5, so that for HTML, JSP, and XML files, the user can specify
if the EOL should be "left alone", converted to LF, or converted to CRLF.
But this is for only when customer does an edit, not when they
publish.
|