[JBoss JIRA] (WFLY-2690) JSP/JSPX tags doesn't work with Wildfly CR1
by Matus Zamborsky (JIRA)
[ https://issues.jboss.org/browse/WFLY-2690?page=com.atlassian.jira.plugin.... ]
Matus Zamborsky commented on WFLY-2690:
---------------------------------------
Hello,
I have one (will upload it shortly). It really is a problem of weld. I went a little bit deeper and even find the problem. The problem is in
[org.jboss.weld.annotated.slim.AnnotatedTypeIdentifier | https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/wel...]. Deep down it is used as a key in caching Annotated types and as you can see from sources of this class, it uses only className (and other attributes) to distinguish between classes. But Wildfly uses different class loaders for every JSP (and included tags).
The problem manifests as casting exception from class A1 to class A2 (where A1 and A2 have the same class name but are loaded with different classloaders).
I rewrote AnnotatedTypeIdentifier so it uses the class object instead of className and it looks promising (no exceptions). But I am not a weld developer, and don't really know if it wont have any other consequences.
> 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
10 years, 4 months
[JBoss JIRA] (DROOLS-350) Incremental compilation is not correctly synchronized
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-350?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-350:
------------------------------------------------
Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1033612|https://bugzilla.redhat.com/show_bug.cgi?id=1033612] from ON_QA to VERIFIED
> Incremental compilation is not correctly synchronized
> -----------------------------------------------------
>
> Key: DROOLS-350
> URL: https://issues.jboss.org/browse/DROOLS-350
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.0.1.Final
>
>
> Incremental compilation is not correctly synchronized and then a kiesession can fire when the underlying rule base is in an inconsistent state. The test case below shows the problem
> {code}
> @Test(timeout = 10000)
> public void testIncrementalCompilationSynchronization() throws Exception {
> final KieServices kieServices = KieServices.Factory.get();
> ReleaseId releaseId = kieServices.newReleaseId("org.kie.test", "sync-scanner-test", "1.0.0");
> createAndDeployJar( kieServices, releaseId, createDRL("rule0") );
> final KieContainer kieContainer = kieServices.newKieContainer(releaseId);
> KieSession kieSession = kieContainer.newKieSession();
> List<String> list = new ArrayList<String>();
> kieSession.setGlobal("list", list);
> kieSession.fireAllRules();
> kieSession.dispose();
> assertEquals(1, list.size());
> Thread t = new Thread(new Runnable() {
> @Override
> public void run() {
> for (int i = 1; i < 10; i++) {
> ReleaseId releaseId = kieServices.newReleaseId("org.kie.test", "sync-scanner-test", "1.0." + i);
> createAndDeployJar( kieServices, releaseId, createDRL("rule" + i) );
> kieContainer.updateToVersion(releaseId);
> }
> }
> });
> t.setDaemon(true);
> t.start();
> while (true) {
> kieSession = kieContainer.newKieSession();
> list = new ArrayList<String>();
> kieSession.setGlobal("list", list);
> kieSession.fireAllRules();
> kieSession.dispose();
> assertEquals(1, list.size());
> if (list.get(0).equals("rule9")) {
> break;
> }
> }
> }
> private String createDRL(String ruleName) {
> return "package org.kie.test\n" +
> "global java.util.List list\n" +
> "rule " + ruleName + "\n" +
> "when\n" +
> "then\n" +
> "list.add( drools.getRule().getName() );\n" +
> "end\n";
> }
> {code}
--
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
10 years, 4 months
[JBoss JIRA] (WFLY-2705) Unicode and Umlaut problems in Wildfly
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2705?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-2705:
--------------------------------------
default-encoding should be working in CR1. What config where you using?
> 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
10 years, 4 months
[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
10 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
10 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
10 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
10 years, 4 months