February 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9748) Support new method-level "@Priority" annotation

by David Lloyd (JIRA)

David Lloyd created WFLY-9748: --------------------------------- Summary: Support new method-level "@Priority" annotation Key: WFLY-9748 URL: https://issues.jboss.org/browse/WFLY-9748 Project: WildFly Issue Type: Enhancement Components: CDI / Weld, EE, EJB Reporter: David Lloyd Priority: Critical Fix For: 12.0.0.Alpha1 The {{@Priority}} annotation in Common Annotations 1.3 has gained a METHOD applicability level. We must ensure that our interceptor metadata processing picks up these annotations. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-9748) Support new method-level "@Priority" annotation

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-9748?page=com.atlassian.jira.plugin.... ] David Lloyd updated WFLY-9748: ------------------------------ Labels: JavaEE8 (was: ) > Support new method-level "@Priority" annotation > ----------------------------------------------- > > Key: WFLY-9748 > URL: https://issues.jboss.org/browse/WFLY-9748 > Project: WildFly > Issue Type: Enhancement > Components: CDI / Weld, EE, EJB > Reporter: David Lloyd > Priority: Critical > Labels: JavaEE8 > Fix For: 12.0.0.Alpha1 > > > The {{@Priority}} annotation in Common Annotations 1.3 has gained a METHOD applicability level. We must ensure that our interceptor metadata processing picks up these annotations. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6463) Common Annotations 1.3 Support

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6463?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-6463: ----------------------------------- component tagged under jboss-annotations-api_1.3_spec-1.0.0.Final and released to maven > Common Annotations 1.3 Support > ------------------------------ > > Key: WFLY-6463 > URL: https://issues.jboss.org/browse/WFLY-6463 > Project: WildFly > Issue Type: Sub-task > Components: EE > Reporter: David Lloyd > Assignee: Tomaz Cerar > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-9282) UserTransaction should be lazy to allow node selection (loadbalancing) even if the invocations stick to one node

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-9282?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-9282: ----------------------------------- Per discussions, this may be fully resolved already. Let's see if we can close this out. > UserTransaction should be lazy to allow node selection (loadbalancing) even if the invocations stick to one node > ---------------------------------------------------------------------------------------------------------------- > > Key: WFLY-9282 > URL: https://issues.jboss.org/browse/WFLY-9282 > Project: WildFly > Issue Type: Enhancement > Components: EJB > Environment: Remote client EJB invocation > Reporter: Wolf-Dieter Fink > Assignee: David Lloyd > > It should be possible to lookup a UserTransaction from a node or a cluster and call .begin() with starting the Transaction lazy until the first EJB invocation. > The invocation will implicit begin the transaction and all invocation are sticky to that node. > This is to spread the load across several server instances if there is no running transaction but keep the transaction sticky to the first selected node. > It prevents from a strong affinity to one instance via URI affinity or the necessity to define the node for the UserTransaction upfront. > The sticiness is because of issues with persistence like JPA as here the server is not really 'stateless' as the session of EntityManager can decide to not flush the changed data to the underlying database which can cause issues if the transaction will continued on a different instance if the client invoke EJB's multiple times. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6463) Common Annotations 1.3 Support

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6463?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-6463: --------------------------------- Assignee: Tomaz Cerar > Common Annotations 1.3 Support > ------------------------------ > > Key: WFLY-6463 > URL: https://issues.jboss.org/browse/WFLY-6463 > Project: WildFly > Issue Type: Sub-task > Components: EE > Reporter: David Lloyd > Assignee: Tomaz Cerar > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6463) Common Annotations 1.3 Support

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-6463?page=com.atlassian.jira.plugin.... ] David Lloyd reopened WFLY-6463: ------------------------------- > Common Annotations 1.3 Support > ------------------------------ > > Key: WFLY-6463 > URL: https://issues.jboss.org/browse/WFLY-6463 > Project: WildFly > Issue Type: Sub-task > Components: EE > Reporter: David Lloyd > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6463) Common Annotations 1.3 Support

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-6463?page=com.atlassian.jira.plugin.... ] David Lloyd updated WFLY-6463: ------------------------------ Comment: was deleted (was: Dropped.) > Common Annotations 1.3 Support > ------------------------------ > > Key: WFLY-6463 > URL: https://issues.jboss.org/browse/WFLY-6463 > Project: WildFly > Issue Type: Sub-task > Components: EE > Reporter: David Lloyd > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[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, 1 month

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, 1 month

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, 1 month

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