December 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-10438) Create a domain testsuite test for a missing host-exclude

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-10438?page=com.atlassian.jira.plugin... ] James Perkins resolved WFLY-10438. ---------------------------------- Resolution: Done > Create a domain testsuite test for a missing host-exclude > --------------------------------------------------------- > > Key: WFLY-10438 > URL: https://issues.jboss.org/browse/WFLY-10438 > Project: WildFly > Issue Type: Task > Components: Management, Test Suite > Reporter: Brian Stansberry > Assignee: Yeray Borges > Priority: Major > Labels: domain-mode > Fix For: 15.0.0.Final, 15.0.0.Beta1 > > > We need a simple domain mode smoke test that will fail if a new extension is added without corresponding adjustments to the domain.xml host-exclude resources. > I had a complicated slow approach in mind that I wrote here before; it's stricken out below. > Much simpler approach: > Add a test to testsuite domain that uses a DC running the standard domain.xml. Read from the DC all the extensions. Work through the host-exclude resources. For each host-exclude, take a copy of the set of extensions, remove those listed in the host-exclude and compare the result to a known correct set of extensions for that version. > If we add a new extension and don't host-exclude it, this will fail. This really is all that's needed to avoid completely skipping the host-excludes. > If we add a new host-exclude and don't add the correct set of extensions to the test, the test will fail. This will help ensure the test isn't completely unmaintained. > It doesn't cover people forgetting to add a new legacy version host-exclude when adding the first extension in a new version, but that can be tracked via code review or just being reasonably careful. > Original complicated approach: > -We need a simple test that a slave running the version before the current one can boot and run a minimal server. Basically to catch the need for a fix like WFLY-10396 whenever we add a new extension. > Something like: > Base domain config must be the standard one we ship. It will include all extensions. > Test adds a minimal profile -- bare bones logging subsystem or perhaps no subsystem at all, can only have config that has been legal from the beginning -- and a server group using that profile. The server-group is added to the 'active-server-groups' attribute in the host-exclude resource for the slave's version. > Slave host.xml has 1 server only, and in that server group. > Launch the DC using the current release and the slave using the legacy release. Prove the slave server can start.- -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11052) Set journal-pool-files default value to 10

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-11052?page=com.atlassian.jira.plugin... ] James Perkins updated WFLY-11052: --------------------------------- Fix Version/s: 15.0.0.Final > Set journal-pool-files default value to 10 > ------------------------------------------ > > Key: WFLY-11052 > URL: https://issues.jboss.org/browse/WFLY-11052 > Project: WildFly > Issue Type: Enhancement > Components: JMS > Affects Versions: 14.0.0.Final > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > Priority: Major > Fix For: 15.0.0.Beta1, 15.0.0.Final > > > Update the default value to 10 as -1 creates a warning with Artemis 2.6.x -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9106) Hard-code default values in messaging-activemq subsystem.

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-9106?page=com.atlassian.jira.plugin.... ] James Perkins updated WFLY-9106: -------------------------------- Fix Version/s: 15.0.0.Final > Hard-code default values in messaging-activemq subsystem. > --------------------------------------------------------- > > Key: WFLY-9106 > URL: https://issues.jboss.org/browse/WFLY-9106 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Jeff Mesnil > Assignee: ehsavoie Hugonnet > Priority: Major > Fix For: 15.0.0.Beta1, 15.0.0.Final > > > The messaging-activemq subsystem defines plenty of attributes that maps to Artemis configuration. > Most of these attributes have default values. The default values are taken from Artemis API (ActiveMQClient.*, ActiveMQDefaultConfiguration.*) > This has the advantages that we use the sensible default values provided by Artemis itself. > However there some unintended consequences. When Artemis change one of this default, it also changes the default value of the corresponding WildFly attribute. We have strict rule to handle this (with resource transformers, etc.) but this should not be something by happen by accident. We don't have a mechanism today that catch this kind of issue. Some of this may be caught by transformers tests *if* the resource is actually defined in the transformers configuration (but usually I only add a resource to the transformer when I am explicitly changing its definition). > We should hard-code *all* default values of the messaging-activemq subsystem instead of relying on Artemis API (the actual value will often be the same than the one provided by Artemis though). > This will protect us of Artemis API changes so that we can decide to change a default value when it makes sense separately of Artemis upgrades. > However, we will have to sync with Artemis when they do such changes to figure out if we should do that too or keep the previous value. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11088) Deployment failure if existing HA deployment contains a common EJB class

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-11088?page=com.atlassian.jira.plugin... ] James Perkins updated WFLY-11088: --------------------------------- Fix Version/s: 15.0.0.Final > Deployment failure if existing HA deployment contains a common EJB class > ------------------------------------------------------------------------ > > Key: WFLY-11088 > URL: https://issues.jboss.org/browse/WFLY-11088 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 14.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > Fix For: 15.0.0.Beta1, 15.0.0.Final > > > Currently, the command dispatcher ID uses the bean name. This needs to be qualified using the deployment name. > {noformat}Thrown in org.wildfly.clustering.server.dispatcher.MangedCommandDispatcherFactory.cre>ateCommandDispatcher(Object id, C context) line 98 "jboss.deployment.subunit.\"app2.ear\".\"app2.war\".component.StatefullBean.START" => "java.lang.Ille galArgumentException: WFLYCLSV0017: A command dispatcher for StatefullBean already exists, but with a different command context slave1 | [Server:group1] Caused by: java.lang.IllegalArgumentException: WFLYCLSV0017: A command dispatcher for StatefullBean alrea dy exists, but with a different command context", > slave1 | [Server:group1] "jboss.deployment.subunit.\"app2.ear\".\"app2.war\".component.StatefulBean2.START" => "java.lang.IllegalA rgumentException: WFLYCLSV0017: A command dispatcher for StatefulBean2 already exists, but with a different command context slave1 | [Server:group1] Caused by: java.lang.IllegalArgumentException: WFLYCLSV0017: A command dispatcher for StatefulBean2 already e xists, but with a different command context" > slave1 | [Server:group1] }, > slave1 | [Server:group1] "WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => { > slave1 | [Server:group1] "Services that were unable to start:" => [ slave1 | [Server:group1] "jboss.deployment.subunit.\"app2.ear\".\"app2.war\".moduleDeploymentRuntimeInformationStart", slave1 | [Server:group1] "jboss.deployment.unit.\"app2.ear\".WeldEndInitService", slave1 | [Server:group1] "jboss.undertow.deployment.default-server.default-host./app2" > slave1 | [Server:group1] ], slave1 | [Server:group1] "Services that may be the cause:" => ` > {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9455) WFLYTX0001: Unable to roll back active transaction thrown for EJB bridge transactions

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-9455?page=com.atlassian.jira.plugin.... ] James Perkins updated WFLY-9455: -------------------------------- Fix Version/s: 15.0.0.Final > WFLYTX0001: Unable to roll back active transaction thrown for EJB bridge transactions > ------------------------------------------------------------------------------------- > > Key: WFLY-9455 > URL: https://issues.jboss.org/browse/WFLY-9455 > Project: WildFly > Issue Type: Bug > Components: XTS > Affects Versions: 11.0.0.CR1 > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Major > Fix For: 15.0.0.Beta1, 15.0.0.Final > > > It happens to get exception > {code} > ERROR [org.jboss.as.txn] (default task-12) WFLYTX0003: APPLICATION ERROR: transaction still active in request with status 0 > ERROR [org.jboss.as.txn] (default task-12) WFLYTX0001: Unable to roll back active transaction: javax.transaction.SystemException: WFTXN0032: Rollback not allowed on imported transaction > at org.wildfly.transaction.client.LocalTransaction.rollbackAndDissociate(LocalTransaction.java:100) > at org.wildfly.transaction.client.ContextTransactionManager.rollback(ContextTransactionManager.java:83) > at org.jboss.as.txn.deployment.TransactionRollbackSetupAction.checkTransactionStatus(TransactionRollbackSetupAction.java:137) > at org.jboss.as.txn.deployment.TransactionRollbackSetupAction.teardown(TransactionRollbackSetupAction.java:67) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1510) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > {code} > when using XTS transactions bridged to JTA for EJB handling. This happens on change of integration layer for WFTC in WFLY11. > The integration issues were already discussed as part of the JBTM-2853. > Here I hit a trouble of having log filled with the exception mentioned above. This does not cause a functionality trouble but the log is ugly filled with ERRORs. > The trouble seems to be caused by the fact that transaction is imported on ivocation of WS > https://github.com/wildfly/wildfly/blob/master/webservices/server-integra... > but as it was suspended in the integration code before > https://github.com/jbosstm/narayana/blob/master/txbridge/src/main/java/or... > now the WFTC holds the notion about the transaction even on call of > https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... > and such transaction is tried to be rollback which is forbidden on WFTC for imported ones and thus at least ERROR msg is written to the log. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11065) Usage of static fields from java.lang classes as EL expressions in JSPs doesn't work for servlet 4.0

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-11065?page=com.atlassian.jira.plugin... ] James Perkins updated WFLY-11065: --------------------------------- Fix Version/s: 15.0.0.Final > Usage of static fields from java.lang classes as EL expressions in JSPs doesn't work for servlet 4.0 > ---------------------------------------------------------------------------------------------------- > > Key: WFLY-11065 > URL: https://issues.jboss.org/browse/WFLY-11065 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 14.0.0.Beta2 > Reporter: Jan Stourac > Assignee: Jan Stourac > Priority: Major > Fix For: 15.0.0.Beta1, 15.0.0.Final > > > This seems to be back but this time with Servlet 4.0 only as 3.1 seems to work just fine. Current test is already in [Wildfly testsuite|https://github.com/wildfly/wildfly/blob/master/testsuite/integr...] but it does not cover Servlet 4.0. > Java EE7 (which supports EL 3.0 spec) allows JSPs to use EL expressions like: > {code} > <html> > <body> > foo: --- ${Boolean.TRUE} ---<br> > bar: --- ${Integer.MAX_VALUE} ---<br> > </body> > </html> > {code} > However, the {code}${Boolean.TRUE}{code} and {code}${Integer.MAX_VALUE}{code} in the above example aren't evaluated correctly and instead a blank string is rendered for them. > More details in the linked forum thread https://developer.jboss.org/thread/271825 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10685) Fix org.jboss.metadata.merge package export by multiple jars

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-10685?page=com.atlassian.jira.plugin... ] James Perkins updated WFLY-10685: --------------------------------- Fix Version/s: 15.0.0.Final > Fix org.jboss.metadata.merge package export by multiple jars > ------------------------------------------------------------ > > Key: WFLY-10685 > URL: https://issues.jboss.org/browse/WFLY-10685 > Project: WildFly > Issue Type: Bug > Components: EE > Reporter: Richard Opalka > Assignee: Richard Opalka > Priority: Major > Labels: Java11 > Fix For: 15.0.0.Beta1, 15.0.0.Final > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11085) Upgrade Jboss Metadata to 12.0.0.Final

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-11085?page=com.atlassian.jira.plugin... ] James Perkins updated WFLY-11085: --------------------------------- Fix Version/s: 15.0.0.Final > Upgrade Jboss Metadata to 12.0.0.Final > --------------------------------------- > > Key: WFLY-11085 > URL: https://issues.jboss.org/browse/WFLY-11085 > Project: WildFly > Issue Type: Component Upgrade > Components: EE, EJB, Web (Undertow) > Affects Versions: 14.0.0.Final > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > Priority: Major > Fix For: 15.0.0.Beta1, 15.0.0.Final > > > Upgrade Jboss Metadata to 12.0.0.Final (with the JavaEE 8 schemas and jboss descriptors using them) -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11010) Document 2lc/JTA integration properties and add better detection of ehcache/JTA platform class use

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-11010?page=com.atlassian.jira.plugin... ] James Perkins reopened WFLY-11010: ---------------------------------- > Document 2lc/JTA integration properties and add better detection of ehcache/JTA platform class use > -------------------------------------------------------------------------------------------------- > > Key: WFLY-11010 > URL: https://issues.jboss.org/browse/WFLY-11010 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 14.0.0.Final > Reporter: Scott Marlow > Assignee: Scott Marlow > Priority: Major > Fix For: 15.0.0.Beta1, 15.0.0.Final > > > Document the "wildfly.jpa.regionfactory" and "wildfly.jpa.jtaplatform" properties for Hibernate ORM 5.3+ integration. > Also automatically treat "wildfly.jpa.regionfactory" as false if [ehcache is being used|http://www.ehcache.org/documentation/2.7/integrations/hibernate.html] (e.g. check if the hibernate.cache.region.factory_class value starts with "net.sf.ehcache"). This should help applications that have configured to use Ehcache. > Also automatically treat "wildfly.jpa.jtaplatform" as false if the application sets "hibernate.transaction.jta.platform". This should help applications that have configured the transaction platform class. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11010) Document 2lc/JTA integration properties and add better detection of ehcache/JTA platform class use

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-11010?page=com.atlassian.jira.plugin... ] James Perkins updated WFLY-11010: --------------------------------- Fix Version/s: 15.0.0.Final > Document 2lc/JTA integration properties and add better detection of ehcache/JTA platform class use > -------------------------------------------------------------------------------------------------- > > Key: WFLY-11010 > URL: https://issues.jboss.org/browse/WFLY-11010 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 14.0.0.Final > Reporter: Scott Marlow > Assignee: Scott Marlow > Priority: Major > Fix For: 15.0.0.Beta1, 15.0.0.Final > > > Document the "wildfly.jpa.regionfactory" and "wildfly.jpa.jtaplatform" properties for Hibernate ORM 5.3+ integration. > Also automatically treat "wildfly.jpa.regionfactory" as false if [ehcache is being used|http://www.ehcache.org/documentation/2.7/integrations/hibernate.html] (e.g. check if the hibernate.cache.region.factory_class value starts with "net.sf.ehcache"). This should help applications that have configured to use Ehcache. > Also automatically treat "wildfly.jpa.jtaplatform" as false if the application sets "hibernate.transaction.jta.platform". This should help applications that have configured the transaction platform class. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 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 December 2018