ICEsoft.org Forums: ICEfaces, ICEmobile, ICEpdf

Hello,

We are currently evaluating the use of SEAM together with ICEfaces and rely on the use of seperate projects for EAR, WEB and EJB. Thus the use of the seam-gen icefaces version is out of question, cause it implements a complete different build process than supported for us.

However, I managed to build a Seam project ith JBoss Tools that consists of separate projects for the WEB, the EJB and the EAR. I even managed with help of seam-gen generated projects to change this to use ICEfaces. This works as far as I can tell, very well. However, there are two problems.

Despide I added jboss-seam-debug.jar in EAR/lib and WEB-INF/lib, the seam internal debugging page <project>/debug.seam prints the following problem:

Caused by: java.io.FileNotFoundException: /debug.xhtml Not Found in ExternalContext as a Resource

It seems the internally used SeamDebugPhaseListener tries to redirect the call to debug.xhtml to the version in META-INF/ in the jboss-seam-debug.jar. HOWEVER, this does not work, as the following exception (as noted in the subject line occurs):

JSF1053: (Listener: org.jboss.seam.debug.jsf.SeamDebugPhaseListener.beforePhase(), Phase ID: RENDER_RESPONSE 6, View ID: /debug.xhtml) Exception thrown during phase-listener execution: java.lang.IllegalStateException: getOutputStream() has already been called for this response

The stack trace given is as follows:
Code:

 22:12:05,115 WARNING [lifecycle] JSF1053: (Listener: org.jboss.seam.debug.jsf.SeamDebugPhaseListener.beforePhase(), 
 Phase ID: RENDER_RESPONSE 6,  View ID: /debug.xhtml) Exception thrown during phase-listener execution: java.lang.IllegalStateException:
 getOutputStream() has already been called for this response
 22:12:05,115 WARNING [lifecycle] org.apache.catalina.connector.Response.getWriter(Response.java:619)
 org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java:198)
 javax.servlet.ServletResponseWrapper.getWriter(ServletResponseWrapper.java:112)
 org.jboss.seam.debug.jsf.SeamDebugPhaseListener.beforePhase(SeamDebugPhaseListener.java:51)
 com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:214)
 com.sun.faces.lifecycle.Phase.doPhase(Phase.java:96)
 com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
 com.icesoft.faces.webapp.http.core.JsfLifecycleExecutor.apply(JsfLifecycleExecutor.java:19)
 com.icesoft.faces.context.View$2$1.respond(View.java:48)
 com.icesoft.faces.webapp.http.servlet.ServletRequestResponse.respondWith(ServletRequestResponse.java:201)
 com.icesoft.faces.context.View$2.serve(View.java:77)
 com.icesoft.faces.context.View.servePage(View.java:149)
 com.icesoft.faces.webapp.http.core.SingleViewServer.service(SingleViewServer.java:52)
 com.icesoft.faces.webapp.http.common.ServerProxy.service(ServerProxy.java:11)
 com.icesoft.faces.webapp.http.servlet.MainSessionBoundServlet$4.service(MainSessionBoundServlet.java:149)
 com.icesoft.faces.webapp.http.common.standard.PathDispatcherServer.service(PathDispatcherServer.java:24)
 com.icesoft.faces.webapp.http.servlet.BasicAdaptingServlet.service(BasicAdaptingServlet.java:16)
 com.icesoft.faces.webapp.http.servlet.PathDispatcher.service(PathDispatcher.java:23)
 com.icesoft.faces.webapp.http.servlet.SessionDispatcher.service(SessionDispatcher.java:53)
 com.icesoft.faces.webapp.http.servlet.PathDispatcher.service(PathDispatcher.java:23)
 com.icesoft.faces.webapp.http.servlet.MainServlet.service(MainServlet.java:131)
 javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
 org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:60)
 org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
 org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
 org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
 org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
 org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
 org.jboss.seam.web.HotDeployFilter.doFilter(HotDeployFilter.java:53)
 org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
 org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40)
 org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
 org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
 org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
 org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
 org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
 org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
 org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
 org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
 org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
 org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
 org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
 java.lang.Thread.run(Thread.java:637)

If I now take the debug.xhtml file and put it directly in my project, the exception about the double used outputstream still occurs, but the page is rendered successfully and no problems arise.

Can anybody familiar with the way this is handled give a hint what might be wrong.

PS: the exception occurs too for seam-gen generated projects, thus there must be a bug somewhere.

The following environment is used:

JBOSS 5.1 AS
ICEfaces 1.8.2, Build number: 7, Revision: 19321
Seam 2.2.1.CR1

Best regards,

and give me a note if you need additional information.

Best regards,

Heiko

Since seam-gen creates an ant build script, I am assuming that you are using something other than ant for the build (?).

What are you doing when this particular exception is thrown? Is this on the first view of any page (home page? any page in particular which has some kind of action defined for it?

Seam will only redirect to the debug page (debug.xhtml) if there is something wrong with the original page, so it might be a good idea to see why that is the case. Is there some action defined on the debug page?

Hello,

judy.guglielmin wrote:

Since seam-gen creates an ant build script, I am assuming that you are using something other than ant for the build (?).

I've used seam-gen, inspected the generated EAR/WAR structure and included this into a Seam Project as build by the JBoss Tools. Our building is in this stage done via Eclipse and its automatic deployment process. The Seam Web Project consists of four different Eclipse Projects as follows:

Code:

TestProject (this is the dynamic web project)
     WebContents
         WEB-INF
             lib
                 commons-beanutils.jar
                 jboss-seam-debug.jar
                 jboss-seam-excel.jar
                 jboss-seam-flex.jar
                 jboss-seam-ioc.jar
                 jboss-seam-jul.jar
                 jboss-seam-mail.jar
                 jboss-seam-pdf.jar
                 jboss-seam-remoting.jar
                 jboss-seam-rss.jar
                 jboss-seam-ui.jar
 TestProject-ear (obviously the EAR)
     jboss-seam.jar
     lib
         antlr-runtime.jar
         backport-util-concurrent.jar
         commons-beanutils.jar
         commons-digester.jar
         commons-fileupload.jar
         drools-api.jar
         drools-compiler.jar
         drools-core.jar
         icefaces-comps.jar
         icefaces-facelets.jar
         icefaces.jar
         jboss-el.jar
         jboss-seam-remoting.jar
         jbpm-jpdl.jar
         mvel2.jar
 TestProject-ejb (the EJB project holding all EJBs)
 TestProject-test (a Testproject for Unittests)

This structure actually contains RichFaces instead of IceFaces, but I followed this URL http://seamframework.org/Documentation/UsingICEFacesWithJBossToolsGeneratedProjects to make the projects work with IceFaces too.

Seam contains the debug mechanism in a separate jar-file jboss-seam-debug.jar, which is added to the WEB-INF/lib directory of the TestProject (web project). This has not been changed and is generated this way by every Seam Web Project using JBoss Tools and it works when the project uses RichFaces.

judy.guglielmin wrote:

What are you doing when this particular exception is thrown? Is this on the first view of any page (home page? any page in particular which has some kind of action defined for it?

Seam will only redirect to the debug page (debug.xhtml) if there is something wrong with the original page, so it might be a good idea to see why that is the case. Is there some action defined on the debug page?

Sorry for this misunderstanding. Although Seam only redirects to the debug page if something is wrong does not mean you can't call it directly and yourself to get information about current conversations and contexts. This is what I did. If I call the home-page, which redirects to /home.seam and uses /home.xhtml for it, this works completely fine with Icefaces.

The problem arrises, if either an error occurs so seam itself tries to open /debug.seam or if you simply type http://<host>:<port>/debug.seam. This should work, and display the debug information. The debug mechanism is implemented by a faces-config.xml file inside the jboss-seam-debug.jar that implements a phase-listener in the faces life cycle. As normally, a call to /debug.seam would look for a file /debug.xhtml in the root, this phase-listener tries to redirect the output stream to a file debug.xhtml inside the META-INF directory of the debug.jar. Here the problem arrises, as this does not work, cause getOutputStream() has been called already for some reason.

Let me summarize:

Our project setup as provided above does work fine.

When you either directly or indirectly call /debug.seam, this does not work and results in the given exception

The exception is even thrown for a simple seam-gen generated project, not only for our version build uppon JBoss Tools Seam Web Project

If I extract the file debug.xhtml from the seam debug.jar and put it in the root of the web project, everything works fine, though the exception still occurs (it is no longer relevant, as the file is found and the phase listener is not necessary)

Can you retry with removing commons-beanutils from the WEB-INF/lib folder as well as all the jboss-seam modules other than ui and debug?

When you state that

...
The problem arrises, if either an error occurs so seam itself tries to open /debug.seam or if you simply type http://<host>:<port>/debug.seam. This should work, and display the debug information....

Do you not mean you are looking for

http://<host>:<port>/<app-context>/debug.seam

?

judy.guglielmin wrote:

Can you retry with removing commons-beanutils from the WEB-INF/lib folder as well as all the jboss-seam modules other than ui and debug?

I tried this, they are now completely removed from the project, however, this does not make any difference. The exception still occurs as soon as I try to use http://<host>:<port>/<app-context>/debug.seam. Actually this leads to a 'neverending' recursion, as the error of not finding the resource tries to load the error page, and so on.

judy.guglielmin wrote:

When you state that

...
The problem arrises, if either an error occurs so seam itself tries to open /debug.seam or if you simply type http://<host>:<port>/debug.seam. This should work, and display the debug information....

Do you not mean you are looking for
http://<host>:<port>/<app-context>/debug.seam
?

Yes thats correct, this is how I tried it of course. Simply forgot the <app-context>.

I'm not completely sure, but I've read that seam and especially jboss are behaving different under JDK 6 than 5. However I do not have a chance of using JDK 5 as this is not present under Mac OS Snow Leopard (our development systems).

If it helps, I could pack the whole Eclipse packages as the currently do not contain any confidential code and you may have a look yourself.

Best regards,

Heiko

You could open a jira and attach it there with any comments and a link to this forum posting (just leave out the libraries and make a list of them in the comments..

or ..
you could do the same to this forum posting. (in case someone else has some time before I do, to look at it).