[JBoss JIRA] (WFLY-2690) JSP/JSPX tags doesn't work with Wildfly CR1
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2690?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-2690:
--------------------------------------
Do you have a reproducer?
I am pretty sure this is a weld issue, but it should be possible for me to work around it, however it would be easier if you have a ready made reproducer I can test out.
> JSP/JSPX tags doesn't work with Wildfly CR1
> -------------------------------------------
>
> Key: WFLY-2690
> URL: https://issues.jboss.org/browse/WFLY-2690
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Environment: OpenJDK Runtime Environment (fedora-2.4.3.0.fc18-x86_64 u45-b15)
> OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
> Reporter: Otávio Garcia
> Assignee: Stuart Douglas
>
> My app works fine on JBoss AS 7.1. When I migrate to Wildfly 8.0.0 CR1, my JSP tags don't work as expected. My project is a EAR with WAR module.
> When app starts, in the 1st access to page A, tag file is compiled and the page are rendered fine. But when I access another page (B in example), I got this error: org.apache.jasper.JasperException: java.lang.ClassCastException: org.apache.jsp.tag.web.default_tagx cannot be cast to org.apache.jsp.tag.web.default_tagx
> If I restart Wildfly and try to access page B, works fine. But when I access page A, I got the same error.
> My default.tagx is bellow:
> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml" version="2.2">
> <jsp:output doctype-root-element="HTML" doctype-system="about:legacy-compat" omit-xml-declaration="yes" />
> some code
> <jsp:doBody />
> more code
> </jsp:root>
> And the pages are somethink like this:
> <tags:default xmlns:tags="urn:jsptagdir:/WEB-INF/tags" xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml">
> <jsp:output omit-xml-declaration="yes" />
> my code here
> </tags:default>
> I was created a new empty project with two pages and one tagfile. The error don't occurs. But when I add CDI capabilities, the error occurs. There are something in CDI that confuses Jastow?
> As discussed here: https://community.jboss.org/message/850730
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (WFLY-2699) liferay portal does not work
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2699?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-2699:
--------------------------------------
So looking at the code here:
http://grepcode.com/file/repo1.maven.org/maven2/com.liferay.portal/portal...
One possible issue is that setContentLength(long) is not overridden, so if portlet uses this method compression will not work. This seems unlikely though.
Basically we need to figure out how the content length is being set. Undertow will automatically set a content length header if the output stream is closed without being flushed, and the response fits entirely in the buffer, however I can't see how that would be the cause.
> liferay portal does not work
> ----------------------------
>
> Key: WFLY-2699
> URL: https://issues.jboss.org/browse/WFLY-2699
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Michał Zegan
> Assignee: Stuart Douglas
>
> Hello.
> I have commpiled the full wildfly package and set gerrit, jenkins, and the nexus repo manager on it, all works perfectly.
> The problem:
> I tried to deploy liferay on the same instance.
> I did everything and then deployed the webapp.
> The deploy was successful, but it didn't work.
> I have the appserver behind apache reverse proxy, trying to load a page displays error 502 proxy error.
> I checked with telnet what happens by telnetting to the backend appserver and sending a GET request for /.
> The response was incorrect, I got the expected document but without the status line and headers, that makes it clear why apache sait error 502.
> Liferay probably works with jboss as 7 and tomcat/etc, so I think undertow must have something to do with it
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (WFLY-2699) liferay portal does not work
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2699?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-2699:
--------------------------------------
Sounds like it has something to do with the content-length for compression being wrong.
How is compression handled? It is a custom filter in Liferay?
> liferay portal does not work
> ----------------------------
>
> Key: WFLY-2699
> URL: https://issues.jboss.org/browse/WFLY-2699
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Michał Zegan
> Assignee: Stuart Douglas
>
> Hello.
> I have commpiled the full wildfly package and set gerrit, jenkins, and the nexus repo manager on it, all works perfectly.
> The problem:
> I tried to deploy liferay on the same instance.
> I did everything and then deployed the webapp.
> The deploy was successful, but it didn't work.
> I have the appserver behind apache reverse proxy, trying to load a page displays error 502 proxy error.
> I checked with telnet what happens by telnetting to the backend appserver and sending a GET request for /.
> The response was incorrect, I got the expected document but without the status line and headers, that makes it clear why apache sait error 502.
> Liferay probably works with jboss as 7 and tomcat/etc, so I think undertow must have something to do with it
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (WFLY-2688) jsp with empty content prolog gives error
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2688?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-2688:
--------------------------------------
Fixed in upstream Undertow
> jsp with empty content prolog gives error
> -----------------------------------------
>
> Key: WFLY-2688
> URL: https://issues.jboss.org/browse/WFLY-2688
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Reporter: fiorenzo pizza
> Assignee: Stuart Douglas
>
> i f you deploy jsp pages with 1 empty row and after the content, like:
> --------------------
> <%
> response.sendRedirect("first.jsf");
> %>
> ----------------------------------
> the error in the log is:
> ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /index.jsp: java.lang.IllegalStateException: UT010006: Cannot call getWriter(), getOutputStream() already called
> at io.undertow.servlet.spec.HttpServletResponseImpl.getWriter(HttpServletResponseImpl.java:298) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> at org.apache.jasper.runtime.JspWriterImpl.initOut(JspWriterImpl.java:126) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
> at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:119) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
> at org.apache.jasper.runtime.PageContextImpl.release(PageContextImpl.java:188) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
> at org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext(JspFactoryImpl.java:115) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
> at org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:74) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
> at org.apache.jsp.index_jsp._jspService(index_jsp.java:66)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:69) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:366) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:70)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:67) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:164) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:654) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (WFLY-2705) Unicode and Umlaut problems in Wildfly
by Andre Pankraz (JIRA)
[ https://issues.jboss.org/browse/WFLY-2705?page=com.atlassian.jira.plugin.... ]
Andre Pankraz commented on WFLY-2705:
-------------------------------------
Thanks for the hint, the workaround to explitely use the CharacterEncodingFilter and adding the CDI Filter behind this worked.
Strange that it works for JBoss 7.2 and Wildfly with AJAX though.
I hope there is a better solution in the future.
I found some hints to the new attribute <servlet-container ... default-encoding="UTF-8"> but my version (from git yesterday) didn't know about it yet.
Thanks again!
> Unicode and Umlaut problems in Wildfly
> --------------------------------------
>
> Key: WFLY-2705
> URL: https://issues.jboss.org/browse/WFLY-2705
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.0.0.CR1
> Environment: CentOS
> java version "1.7.0_45"
> OpenJDK Runtime Environment (rhel-2.4.3.2.el6_4-x86_64 u45-b15)
> Reporter: Andre Pankraz
> Assignee: Jozef Hartinger
>
> I think I'm doing something wrong if this is really a CR1, but I cannot get UTF working properly on Wildfly. (It works fine in same environment and same settings/code in jboss-as-7.2.0.Final.)
> * If i have an JSF inputText in a form (hence POST)
> * and I enter "TestÜÖÄ"
> * I get "TestÃ?Ã?Ã" as result.
> If I provide a <f:ajax render...> on this field, the ajax rendering creates the proper response, but if I submit the data I always get the wrong encoded result.
> I created a minimalistic web app without any additional libs with just one JSF test page (see below). It works in jboss as 7.2 final but not in Wildfly CR1.
> I have set in the environment:
> -Dsun.jnu.encoding=UTF-8 -Dfile.encoding=UTF-8
> An encoding filter didn't help either.
> May be I'm doing something wrong here, but I have seen quite some other bugs that don't really speak for a "Release-Candidate" so it might really be an issue? Have you really tried to deploy at least 2 or 3 bigger JSF apps onto this new version? Will add some more reports.
> Example page for quick test:
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <f:view encoding="UTF-8" xmlns:f="http://java.sun.com/jsf/core">
> <html lang="de" xmlns="http://www.w3.org/1999/xhtml"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns:ui="http://java.sun.com/jsf/facelets">
> <h:head>
> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
> <title>Test</title>
> </h:head>
> <h:body>
> <h1>Test ÜÄÖ</h1>
> <h:form id="test">
> <h:inputText label="Test: " value="#{test.test}">
> <f:ajax render=":test" />
> </h:inputText>
> AJAX: #{test.test}
> <br />
> <h:commandButton action="#{test.print()}" value="Print" />
> </h:form>
> </h:body>
> </html>
> </f:view>
> package test;
> import javax.enterprise.context.RequestScoped;
> import javax.inject.Named;
> @Named
> @RequestScoped
> public class Test {
> private String test;
> public String getTest() {
> return test;
> }
> public void setTest(String test) {
> this.test = test;
> }
> public String print() {
> System.out.println("TEST: " + getTest());
> return "success";
> }
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (WFLY-2707) Filter.destroy() not called for undeployment
by Andre Pankraz (JIRA)
Andre Pankraz created WFLY-2707:
-----------------------------------
Summary: Filter.destroy() not called for undeployment
Key: WFLY-2707
URL: https://issues.jboss.org/browse/WFLY-2707
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 8.0.0.CR1
Environment: CentOs/OpenJDK 7
Reporter: Andre Pankraz
ServletContextListener.contextDestroyed() is called reliably at undeployment time.
But the destroy() methods of javax.servlet.Filters are never called.
The filter is not explicetely in the web.xml, it's automatically detected and initialized via init() at deployment, but destroy() is never called.
JavaMelody cannot shutdown it's timers because of this:
See last remarks in http://code.google.com/p/javamelody/issues/detail?id=360
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months