Issue Details (XML | Word | Printable)

Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Critical Critical
Assignee: Ryan Lubke
Reporter: Ed Burns
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.

Jakarta Shale should work without modification on Glassfish.

Created: 22/Feb/06 07:56 AM   Updated: 25/Nov/10 11:46 PM   Resolved: 16/Mar/06 01:43 PM
Component/s: web_container
Affects Version/s: 9.0pe
Fix Version/s: 9.0pe

Time Tracking:
Not Specified


Operating System: All
Platform: Sun

Issue Links:

Issuezilla Id: 289
Participants: Ed Burns and Ryan Lubke

 Description  « Hide

Jakarta Shale should work without modification on Glassfish.

Ed Burns added a comment - 22/Feb/06 07:56 AM

Reassign to Ryan Lubke.

Ryan Lubke added a comment - 22/Feb/06 08:19 AM

Shale appears to work fine with GlassFish's JSF implementation after:

There is currently an effort by Jeanfrancois to allow MyFaces to run if present
in the web application without the appserver's JSF implementation causing conflicts.

Ryan Lubke added a comment - 16/Mar/06 01:43 PM

The following Shale demo applications run:

  • shale-mailreader
  • shale-sql-browser
  • shale-usecases

The shale-blank application currently doesn't work
without modifications, but Craig has admitted this
is a Shale issue.

  • - the non-jsp Clay examples have a small rendering
    issue in 1.2. I brought the issue up to the shale
    developers and they stated the following:
    Clay has not been refactored to support JSF 1.2.

In JSF 1.1, the JSP "ViewTag" tag handles searching through the rendered
response stream replacing the "com.sun.faces.saveStateFieldMarker" marker
within the HTML form tag with the serialized client state as a hidden input
field. The marker is not standardized under 1.1 and is called "<!--
@@JSF_FORM_STATE_MARKER@@-->" in myfaces.

When using Clay full HTML or XML views, the Clay View handler has this
responsibility since the page doesn't have a JSP "ViewTag" tag.

From what I understand, JSF 1.2 moves this responsibility to the ViewHandler
and the marker name is standardized. JSF 1.2 also handles the interweaving of
non-JSF jsp with JSF component rendered output differently too.

We will have to address this issue when committing to support JSF 1.2.

Thanks for the feedback.
I've performed the GlassFish/JSF integration that resolves a new issue
that popped up with the shale JNDI variable resolve, so we should be good
to go for build 41.