February 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3570) Undertow 2.0.0.Beta1

by Stuart Douglas (JIRA)

Stuart Douglas created WFCORE-3570: -------------------------------------- Summary: Undertow 2.0.0.Beta1 Key: WFCORE-3570 URL: https://issues.jboss.org/browse/WFCORE-3570 Project: WildFly Core Issue Type: Component Upgrade Reporter: Stuart Douglas -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3570) Undertow 2.0.0.Beta1

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3570?page=com.atlassian.jira.plugi... ] Stuart Douglas reassigned WFCORE-3570: -------------------------------------- Assignee: Stuart Douglas > Undertow 2.0.0.Beta1 > -------------------- > > Key: WFCORE-3570 > URL: https://issues.jboss.org/browse/WFCORE-3570 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Stuart Douglas > Assignee: Stuart Douglas > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWEB-214) More than one JSESSIONID cookie headers set in JBoss Web

by richard groote (JIRA)

[ https://issues.jboss.org/browse/JBWEB-214?page=com.atlassian.jira.plugin.... ] richard groote commented on JBWEB-214: -------------------------------------- I have a question about the status of this issue. In the rfc6265 the below is stated, so it would be nice if the server should not response with multiple session id. In our situation we do not invalidate the session our self. In our situation we're calling a secure page and than the response contains two SetCookie headers. The cause of the problem is the session-config in the web.xml defines that the cookie is secure but the call we make in the browser is http. The next call is a post to the j_security_check and this one will fail with message "session timeout during the login process". The browser (FireFox and Chrome) are not responding to (correctly) to the Set-Cookie in the first request so therefore a incorrect session is send with the j_security_check. It would be nice if the server will response only with one Set-Cookie --- RFC6265 --- Servers SHOULD NOT include more than one Set-Cookie header field in the same response with the same cookie-name. (See Section 5.2 for how user agents handle this case.) > More than one JSESSIONID cookie headers set in JBoss Web > -------------------------------------------------------- > > Key: JBWEB-214 > URL: https://issues.jboss.org/browse/JBWEB-214 > Project: JBoss Web > Issue Type: Bug > Components: Tomcat > Affects Versions: JBossWeb-2.1.11.GA > Reporter: Eiichi Nagai > Assignee: Remy Maucherat > > More than one JSESSIONID cookie headers set if execute following JSP. > <% > session.invalidate(); > session = request.getSession(); > session.invalidate(); > session = request.getSession(); > %> > This issue has been reported from Bug 49158[1] in tomcat. > [1] Bug 49158 - More than one JSESSIONID cookie headers set > https://issues.apache.org/bugzilla/show_bug.cgi?id=49158 > http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalin... > http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalin... > I guess that same fix is required in JBoss Web. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3545) Composed keys don't have to be recognized by CLI

by Erich Duda (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3545?page=com.atlassian.jira.plugi... ] Erich Duda reassigned WFCORE-3545: ---------------------------------- Assignee: Jean-Francois Denise (was: Erich Duda) > Composed keys don't have to be recognized by CLI > ------------------------------------------------ > > Key: WFCORE-3545 > URL: https://issues.jboss.org/browse/WFCORE-3545 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 4.0.0.Alpha6 > Reporter: Erich Duda > Assignee: Jean-Francois Denise > > Some keys like key down are composed from multiple characters. Normally when the key down is pushed, 3 characters are written into stdin. These 3 characters are read by InputStream::read operation at once and then decoded to the Key.DOWN constant. > However there is no guarantee that InputStream::read operation returns all the 3 characters at once. It can return only first character and then remaining two. This actually happens in one test on Solaris and HPUX, where stdin is emulated by PipedInputStream. > If the aforementioned situation happens, pushing of key down is decoded as pushing of two maybe three keys - ESC and some other key(s). > The issue has low priority, because this behavior wasn't observed in real terminal with real input. It affects only testing. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3545) Composed keys don't have to be recognized by CLI

by Erich Duda (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3545?page=com.atlassian.jira.plugi... ] Erich Duda reassigned WFCORE-3545: ---------------------------------- Assignee: Erich Duda (was: Jean-Francois Denise) > Composed keys don't have to be recognized by CLI > ------------------------------------------------ > > Key: WFCORE-3545 > URL: https://issues.jboss.org/browse/WFCORE-3545 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 4.0.0.Alpha6 > Reporter: Erich Duda > Assignee: Erich Duda > > Some keys like key down are composed from multiple characters. Normally when the key down is pushed, 3 characters are written into stdin. These 3 characters are read by InputStream::read operation at once and then decoded to the Key.DOWN constant. > However there is no guarantee that InputStream::read operation returns all the 3 characters at once. It can return only first character and then remaining two. This actually happens in one test on Solaris and HPUX, where stdin is emulated by PipedInputStream. > If the aforementioned situation happens, pushing of key down is decoded as pushing of two maybe three keys - ESC and some other key(s). > The issue has low priority, because this behavior wasn't observed in real terminal with real input. It affects only testing. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3545) Composed keys don't have to be recognized by CLI

by Erich Duda (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3545?page=com.atlassian.jira.plugi... ] Erich Duda closed WFCORE-3545. ------------------------------ Resolution: Done > Composed keys don't have to be recognized by CLI > ------------------------------------------------ > > Key: WFCORE-3545 > URL: https://issues.jboss.org/browse/WFCORE-3545 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 4.0.0.Alpha6 > Reporter: Erich Duda > Assignee: Jean-Francois Denise > > Some keys like key down are composed from multiple characters. Normally when the key down is pushed, 3 characters are written into stdin. These 3 characters are read by InputStream::read operation at once and then decoded to the Key.DOWN constant. > However there is no guarantee that InputStream::read operation returns all the 3 characters at once. It can return only first character and then remaining two. This actually happens in one test on Solaris and HPUX, where stdin is emulated by PipedInputStream. > If the aforementioned situation happens, pushing of key down is decoded as pushing of two maybe three keys - ESC and some other key(s). > The issue has low priority, because this behavior wasn't observed in real terminal with real input. It affects only testing. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3545) Composed keys don't have to be recognized by CLI

by Erich Duda (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3545?page=com.atlassian.jira.plugi... ] Erich Duda reopened WFCORE-3545: -------------------------------- > Composed keys don't have to be recognized by CLI > ------------------------------------------------ > > Key: WFCORE-3545 > URL: https://issues.jboss.org/browse/WFCORE-3545 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 4.0.0.Alpha6 > Reporter: Erich Duda > Assignee: Jean-Francois Denise > > Some keys like key down are composed from multiple characters. Normally when the key down is pushed, 3 characters are written into stdin. These 3 characters are read by InputStream::read operation at once and then decoded to the Key.DOWN constant. > However there is no guarantee that InputStream::read operation returns all the 3 characters at once. It can return only first character and then remaining two. This actually happens in one test on Solaris and HPUX, where stdin is emulated by PipedInputStream. > If the aforementioned situation happens, pushing of key down is decoded as pushing of two maybe three keys - ESC and some other key(s). > The issue has low priority, because this behavior wasn't observed in real terminal with real input. It affects only testing. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3545) Composed keys don't have to be recognized by CLI

by Erich Duda (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3545?page=com.atlassian.jira.plugi... ] Erich Duda commented on WFCORE-3545: ------------------------------------ This issue has wrong state. It should have status NEW. I will correct it. > Composed keys don't have to be recognized by CLI > ------------------------------------------------ > > Key: WFCORE-3545 > URL: https://issues.jboss.org/browse/WFCORE-3545 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 4.0.0.Alpha6 > Reporter: Erich Duda > Assignee: Jean-Francois Denise > > Some keys like key down are composed from multiple characters. Normally when the key down is pushed, 3 characters are written into stdin. These 3 characters are read by InputStream::read operation at once and then decoded to the Key.DOWN constant. > However there is no guarantee that InputStream::read operation returns all the 3 characters at once. It can return only first character and then remaining two. This actually happens in one test on Solaris and HPUX, where stdin is emulated by PipedInputStream. > If the aforementioned situation happens, pushing of key down is decoded as pushing of two maybe three keys - ESC and some other key(s). > The issue has low priority, because this behavior wasn't observed in real terminal with real input. It affects only testing. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3545) Composed keys don't have to be recognized by CLI

by Marek Kopecký (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3545?page=com.atlassian.jira.plugi... ] Marek Kopecký commented on WFCORE-3545: --------------------------------------- Test for down key is [here|https://github.com/wildfly/wildfly-core/blob/master/testsuite/standa...], needs to be uncommented after this issue will be fixed. > Composed keys don't have to be recognized by CLI > ------------------------------------------------ > > Key: WFCORE-3545 > URL: https://issues.jboss.org/browse/WFCORE-3545 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 4.0.0.Alpha6 > Reporter: Erich Duda > Assignee: Jean-Francois Denise > > Some keys like key down are composed from multiple characters. Normally when the key down is pushed, 3 characters are written into stdin. These 3 characters are read by InputStream::read operation at once and then decoded to the Key.DOWN constant. > However there is no guarantee that InputStream::read operation returns all the 3 characters at once. It can return only first character and then remaining two. This actually happens in one test on Solaris and HPUX, where stdin is emulated by PipedInputStream. > If the aforementioned situation happens, pushing of key down is decoded as pushing of two maybe three keys - ESC and some other key(s). > The issue has low priority, because this behavior wasn't observed in real terminal with real input. It affects only testing. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2288) Guided Rule Editor: Not possible to reopen FROM ACCUMULATE

by Toni Rikkola (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2288?page=com.atlassian.jira.plugi... ] Toni Rikkola updated DROOLS-2288: --------------------------------- Description: Create the rule in the image and when you reopen the rule an error about "FROM ACCUMULATE" appears. !GuidedComplex.png|thumbnail! > Guided Rule Editor: Not possible to reopen FROM ACCUMULATE > ---------------------------------------------------------- > > Key: DROOLS-2288 > URL: https://issues.jboss.org/browse/DROOLS-2288 > Project: Drools > Issue Type: Bug > Components: Guided Rule Editor > Reporter: Toni Rikkola > Assignee: Michael Anstis > Attachments: GuidedComplex.png > > > Create the rule in the image and when you reopen the rule an error about "FROM ACCUMULATE" appears. > !GuidedComplex.png|thumbnail! -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2018