January 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBWEB-281) Inconsistent use of genStringAsCharArray.

by Jeremy Whiting (JIRA)

[ https://issues.jboss.org/browse/JBWEB-281?page=com.atlassian.jira.plugin.... ] Jeremy Whiting resolved JBWEB-281. ---------------------------------- Resolution: Done This was resolved, FishEye was showing misleading information for the 7.3 code branch. > Inconsistent use of genStringAsCharArray. > ----------------------------------------- > > Key: JBWEB-281 > URL: https://issues.jboss.org/browse/JBWEB-281 > Project: JBoss Web > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Tomcat > Affects Versions: JBossWeb-7.2.1.GA > Environment: All environments. > Reporter: Jeremy Whiting > Assignee: Remy Maucherat > Fix For: JBossWeb-7.3.0.GA > > > The JSP configuration property "genStringAsCharArray" is inconsistently named in jbossweb. This means the enabling of the feature for using char array type rather than String in generated Servlet code is not enabled. > This issue has been fixed upstream in the 7.0 branch of Tomcat hosted at Apache. > Can this patch be ported to jbossweb so that the 6.2 version of EAP includes this fix ? -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-373) Kie Maven plugin don't use the project classpath

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-373?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-373: ------------------------------------------------ Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1039676|https://bugzilla.redhat.com/show_bug.cgi?id=1039676] from ON_QA to ASSIGNED > Kie Maven plugin don't use the project classpath > ------------------------------------------------ > > Key: DROOLS-373 > URL: https://issues.jboss.org/browse/DROOLS-373 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.0.1.Final > > > When compiling drls the kie maven plugin uses the plugin classpath instead of the project one. This imply that it is necessary to duplicate the dependencies used by the kie project also inside the plugin declaration, as reported by this email: http://drools.46999.n3.nabble.com/rules-users-Drool-6-0-0-Final-2-questio... -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2498) Logout of secured (ssl) admin console setup redirects to http address

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-2498?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-2498: -------------------------------------- Assignee: Darran Lofthouse (was: Heiko Braun) > Logout of secured (ssl) admin console setup redirects to http address > ---------------------------------------------------------------------- > > Key: WFLY-2498 > URL: https://issues.jboss.org/browse/WFLY-2498 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web Console > Reporter: Chris Dolphy > Assignee: Darran Lofthouse > > Description of problem: > Logging out of an admin console secured with SSL (on port 9443) redirects to http address (e.g. http://localhost:9443/logout?logout) which leads to a Page Not Found error. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2498) Logout of secured (ssl) admin console setup redirects to http address

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-2498?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-2498: ----------------------------------- Component/s: Domain Management > Logout of secured (ssl) admin console setup redirects to http address > ---------------------------------------------------------------------- > > Key: WFLY-2498 > URL: https://issues.jboss.org/browse/WFLY-2498 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management, Web Console > Reporter: Chris Dolphy > Assignee: Darran Lofthouse > > Description of problem: > Logging out of an admin console secured with SSL (on port 9443) redirects to http address (e.g. http://localhost:9443/logout?logout) which leads to a Page Not Found error. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2498) Logout of secured (ssl) admin console setup redirects to http address

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-2498?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-2498: ---------------------------------------- [~heiko.braun] I am going to take ownership of this one for the moment - sounds to be related to the server side of the redirect handling at the moment - I will let you know if there is anything on the console side. > Logout of secured (ssl) admin console setup redirects to http address > ---------------------------------------------------------------------- > > Key: WFLY-2498 > URL: https://issues.jboss.org/browse/WFLY-2498 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web Console > Reporter: Chris Dolphy > Assignee: Heiko Braun > > Description of problem: > Logging out of an admin console secured with SSL (on port 9443) redirects to http address (e.g. http://localhost:9443/logout?logout) which leads to a Page Not Found error. -- 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, 5 months

1
0
0 / 0

[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 reassigned WFLY-2690: ------------------------------------ Assignee: Jozef Hartinger (was: Stuart Douglas) Jozef, any chance that you could have a look at this? Basically this issue is that Jasper creates multiple classes with the same name but different class loaders, and Weld can't really handle it (see the earlier comment about the underlying cause). > 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: Jozef Hartinger > > 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, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-358) KieModule resulting from an incremental compilation cannot be used to update a KieContainer

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-358?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-358: ------------------------------------------------ Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1036096|https://bugzilla.redhat.com/show_bug.cgi?id=1036096] from ON_QA to VERIFIED > KieModule resulting from an incremental compilation cannot be used to update a KieContainer > ------------------------------------------------------------------------------------------- > > Key: DROOLS-358 > URL: https://issues.jboss.org/browse/DROOLS-358 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Mario Fusco > Assignee: Mario Fusco > > Programmatic incremental compilation modifies the existing KieModule in place instead of creating a new one. This makes impossible to upgrade a KieContainer with the kieModulre resulting from the incremental compilation. In fact in this case the new KieModule is identical (same instance) to the old one making the automatic KieModule comparison useless. -- 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, 5 months

1
0
0 / 0

[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

12 years, 5 months

1
0
0 / 0

[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

12 years, 5 months

1
0
0 / 0

[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

12 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2014