December 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-1695) Web Console: Principal/Role indication in footer

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-1695?page=com.atlassian.jira.plugin.... ] Kabir Khan updated WFLY-1695: ----------------------------- Fix Version/s: 9.0.0.Final > Web Console: Principal/Role indication in footer > ------------------------------------------------ > > Key: WFLY-1695 > URL: https://issues.jboss.org/browse/WFLY-1695 > Project: WildFly > Issue Type: Feature Request > Components: Web Console > Reporter: Heiko Braun > Assignee: Heiko Braun > Fix For: 9.0.0.Final > > > it should be possible to see the current principal and the active role in the console footer -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4313) Clean-up tests which use Kerberos in the WildFly testsuite

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4313?page=com.atlassian.jira.plugin.... ] Kabir Khan updated WFLY-4313: ----------------------------- Fix Version/s: 9.0.0.Final > Clean-up tests which use Kerberos in the WildFly testsuite > ---------------------------------------------------------- > > Key: WFLY-4313 > URL: https://issues.jboss.org/browse/WFLY-4313 > Project: WildFly > Issue Type: Enhancement > Components: Test Suite > Reporter: Josef Cacek > Assignee: Josef Cacek > Fix For: 9.0.0.Final > > > Clean up Kerberos tests and add an unified logic for skipping Kerberos test configurations which proved to be unstable/buggy. By a configuration here is meant combination of Java vendor, version and IP stack. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-2180) Thread threads pools inherit security context of submitting threads

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-2180?page=com.atlassian.jira.plugin.... ] Kabir Khan updated WFLY-2180: ----------------------------- Fix Version/s: 9.0.0.Final > Thread threads pools inherit security context of submitting threads > ------------------------------------------------------------------- > > Key: WFLY-2180 > URL: https://issues.jboss.org/browse/WFLY-2180 > Project: WildFly > Issue Type: Bug > Components: EE, EJB, Server, Web (Undertow) > Affects Versions: 8.0.0.Alpha4 > Reporter: Stuart Douglas > Assignee: David Lloyd > Fix For: 9.0.0.Final > > > Some thread pool implementation will immediately create a new thread if work is submitted and there is not enough threads available to handle it. This newly created thread will inherit the access control context of the thread that is submitting the work, which essentially means that thread pool threads have a random access control context. > This is the root cause of UNDERTOW-102, and likely other security manager related failures as well. > I think that the best way to fix this is in the thread pool itself, as it should create the thread in a privileged block. We obviously cannot do this for JDK thread pools however. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4190) Provide a Willdfly banner instead of JBossAS7 for Kitchensink quickstarts

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4190?page=com.atlassian.jira.plugin.... ] Kabir Khan updated WFLY-4190: ----------------------------- Fix Version/s: 9.0.0.Final > Provide a Willdfly banner instead of JBossAS7 for Kitchensink quickstarts > -------------------------------------------------------------------------- > > Key: WFLY-4190 > URL: https://issues.jboss.org/browse/WFLY-4190 > Project: WildFly > Issue Type: Enhancement > Reporter: Rafael Benevides > Assignee: Rafael Benevides > Labels: quickstart, quickstarts > Fix For: 9.0.0.Final > > Attachments: wildfly_400x130.jpg > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3404) Major performance degradation from JBoss 7.1 to Wildfly 8.0.0-Final.

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-3404?page=com.atlassian.jira.plugin.... ] Kabir Khan updated WFLY-3404: ----------------------------- Fix Version/s: 9.0.0.Final > Major performance degradation from JBoss 7.1 to Wildfly 8.0.0-Final. > -------------------------------------------------------------------- > > Key: WFLY-3404 > URL: https://issues.jboss.org/browse/WFLY-3404 > Project: WildFly > Issue Type: Bug > Affects Versions: 8.0.0.Final > Reporter: Timothy Heider > Assignee: Jason Greene > Fix For: 9.0.0.Final > > > I have deployed my application to Wildfly 8.0.0 Final and it is almost unusable now. We have rolled back to JBoss 7.1 (same application WARs) and it works fine. > Specifically what seems to be slow is our SOAP web services are taking up to 8 to 10 seconds to respond. We have user concurrency of probably 10-30 users at once hitting these services every 10 seconds or so. > On JBoss 7.1 these services all respond sub-second. The database is totally unburdened and the server is 90% idle all the time. > We have one service endpoint that is a Comet queue wait call. Probably 10 users are waiting on that. Did something change between JBoss 7 and Wildfly 8 that might cause that to not work now? (e.g. too small a thread pool that blocks until the 10 second comet call breaks on a timeout?) > We will try 8.1.0CR2 but I wanted to report we're investigating this and see if you can help us. Thanks! -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4173) Server side EJB Handler not compression response

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4173?page=com.atlassian.jira.plugin.... ] Kabir Khan updated WFLY-4173: ----------------------------- Fix Version/s: 9.0.0.Final > Server side EJB Handler not compression response > ------------------------------------------------ > > Key: WFLY-4173 > URL: https://issues.jboss.org/browse/WFLY-4173 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.0.Alpha1 > Reporter: Brad Maxwell > Assignee: Tomas Hofman > Fix For: 9.0.0.Final > > > When compression is enabled for request/response, the jboss-ejb-client is sending a compressed request, but the application server is responding with an uncompressed response. > On the server enabling TRACE on org.jboss.as.ejb3, we can see the server receives a compressed request > TRACE [org.jboss.as.ejb3] (default task-5) Got message with header 0x1b on channel Channel ID 56b01772 (inbound) of Remoting connection TRACE [org.jboss.as.ejb3.invocation] (default task-5) Received a compressed message stream > Client side, Enabling TRACE on the client side for org.jboss.ejb.client we see it is 0x5 where it should be 0x1b > TRACE org.jboss.ejb.client.remoting.ChannelAssociation - Received message with header 0x5 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-1921) Cancel operation is ignored when flushing JMS destination metrics in the management console

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-1921?page=com.atlassian.jira.plugin.... ] Kabir Khan updated WFLY-1921: ----------------------------- Fix Version/s: 9.0.0.Final > Cancel operation is ignored when flushing JMS destination metrics in the management console > ------------------------------------------------------------------------------------------- > > Key: WFLY-1921 > URL: https://issues.jboss.org/browse/WFLY-1921 > Project: WildFly > Issue Type: Bug > Components: Web Console > Reporter: Osamu Nagano > Assignee: Harald Pehl > Fix For: 9.0.0.Final > > > When you push "Flush" button on JMS Destinations runtime tab (both of queues and topics), a confirmation dialog box brings up. "Cancel" button in the dialog box is always ignored and destination flushing is inevitably executed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4031) Wildfly Quickstarts using old namespaces for beans.xml, faces-config.xml and persistence.xml

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4031?page=com.atlassian.jira.plugin.... ] Kabir Khan updated WFLY-4031: ----------------------------- Fix Version/s: 9.0.0.Final > Wildfly Quickstarts using old namespaces for beans.xml, faces-config.xml and persistence.xml > -------------------------------------------------------------------------------------------- > > Key: WFLY-4031 > URL: https://issues.jboss.org/browse/WFLY-4031 > Project: WildFly > Issue Type: Bug > Reporter: Rafael Benevides > Assignee: Rafael Benevides > Priority: Minor > Labels: quickstarts, > Fix For: 9.0.0.Final > > > All Wildfly quickstarts have the wrong XML namespaces for the following files. > ./src/main/webapp/WEB-INF/beans.xml > ./src/main/webapp/WEB-INF/faces-config.xml > beans.xml and faces-config.xml are using java.sun.com-style namespaces instead of xmlns.jcp.org-style namespaces. > This affects the wildfly archetypes as well -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-1946) Severe error on deploy of ear: "Unable to obtain CDI 1.1 utilities for Mojarra"

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-1946?page=com.atlassian.jira.plugin.... ] Kabir Khan updated WFLY-1946: ----------------------------- Fix Version/s: 9.0.0.Final > Severe error on deploy of ear: "Unable to obtain CDI 1.1 utilities for Mojarra" > ------------------------------------------------------------------------------- > > Key: WFLY-1946 > URL: https://issues.jboss.org/browse/WFLY-1946 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, JSF > Affects Versions: 8.0.0.Beta1 > Reporter: Frank Langelage > Assignee: Stan Silvert > Fix For: 9.0.0.Final > > Attachments: Jira-WFLY-1946.tar > > > Deploy of test.ear shows a severe error: > 00:23:21,917 INFO [org.jboss.as.server.deployment#start] JBAS015876: Starting deployment of "test.ear" (runtime-name: "test.ear") > 00:23:21,941 INFO [org.jboss.as.server.deployment#start] JBAS015876: Starting deployment of "null" (runtime-name: "web.war") > 00:23:21,942 INFO [org.jboss.as.server.deployment#start] JBAS015876: Starting deployment of "null" (runtime-name: "ejb.jar") > 00:23:22,080 INFO [org.jboss.weld.deployer#deploy] JBAS016002: Processing weld deployment test.ear > 00:23:22,121 INFO [org.jboss.weld.deployer#deploy] JBAS016002: Processing weld deployment ejb.jar > 00:23:22,141 INFO [org.jboss.weld.deployer#deploy] JBAS016002: Processing weld deployment web.war > 00:23:22,157 INFO [org.jboss.weld.deployer#deploy] JBAS016005: Starting Services for CDI deployment: test.ear > 00:23:22,192 INFO [org.jboss.weld.deployer#start] JBAS016008: Starting weld service for deployment test.ear > 00:23:22,734 SEVERE [javax.enterprise.resource.webcontainer.jsf.flow#afterBeanDiscovery] Unable to obtain CDI 1.1 utilities for Mojarra > 00:23:22,753 SEVERE [javax.enterprise.resource.webcontainer.jsf.application.view#afterBeanDiscovery] Unable to obtain CDI 1.1 utilities for Mojarra > 00:23:23,099 INFO [test.web.Startup#contextInitialized] contextInitialized > 00:23:23,405 INFO [org.wildfly.extension.undertow#registerDeployment] JBAS018210: Register web context: /intern/web > 00:23:23,465 INFO [org.jboss.as.server#handleResult] JBAS018559: Deployed "test.ear" (runtime-name : "test.ear") > Although everything seems to be fine. App works without errors. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-1765) JDBC object store does not change LOG_STORE_TYPE attribute

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-1765?page=com.atlassian.jira.plugin.... ] Kabir Khan updated WFLY-1765: ----------------------------- Fix Version/s: 9.0.0.Final > JDBC object store does not change LOG_STORE_TYPE attribute > ---------------------------------------------------------- > > Key: WFLY-1765 > URL: https://issues.jboss.org/browse/WFLY-1765 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 8.0.0.Alpha3 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Fix For: 9.0.0.Final > > > The transaction subsystem when set up to JDBC object store should keep a note about it in log-store-type attribute as HornetQ object store does. It seems not to be consistent when one object store does this, but others do not. -- 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 December 2017