October 2020 - jboss-jira - Jboss List Archives

[Red Hat JIRA] (WFLY-13519) Infinispan module attribute needs to support multiple values

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13519?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-13519: ---------------------------------- Fix Version/s: 22.0.0.Beta1 > Infinispan module attribute needs to support multiple values > ------------------------------------------------------------ > > Key: WFLY-13519 > URL: https://issues.redhat.com/browse/WFLY-13519 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 20.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > Fix For: 22.0.0.Beta1 > > > The cache-container and remote-cache-container resources in the Infinispan subsystem have a module attribute that is used to dynamically load externalizers used to configure marshalling for capabilities associated with these resources. > Additionally, this attribute is also used to load Infinispan modules (e.g query, multimap, hibernate, etc.). > Several users have had issues with configuring the marshalling of a custom cache because the module to which their cache container is associated does not know about their module. Users wanting to a specific Infinispan module has a similar issue. > Currently, the only way to load marshalling configuration from multiple modules is through the use of module dependencies (using services="import"). This causes lots of unnatural service dependencies, which complicates the ability to build fine grained galleon layers. > In order to support the use of multiple modules for a given cache-container, and also to support marshalling for multiple modules, we need to allow these resources to be associated with a list of modules, instead of a single module. > Thus, the "module" will need to be replaced by "modules", where the former becomes an alias for the latter, with some translation logic to convert multiple values to a single value. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-13965) Resource-level capability constraints are not enforced

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13965?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-13965: ---------------------------------- Fix Version/s: 21.0.1.Final 22.0.0.Beta1 > Resource-level capability constraints are not enforced > ------------------------------------------------------ > > Key: WFLY-13965 > URL: https://issues.redhat.com/browse/WFLY-13965 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 21.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Critical > Fix For: 21.0.1.Final, 22.0.0.Beta1 > > > For example, a replicated-cache has a capability constraint on a JGroups transport. However, the following operation does not fail, even though a /subsystem=infinispan/cache-container=server/transport=jgroups resource was not defined: > {noformat} > [standalone@embedded /] /subsystem=infinispan/cache-container=server/replicated-cache=foo:add() > ResourceCapabilityReference.addCapabilityRequirements(/subsystem=infinispan/cache-container=server/replicated-cache=foo, null,[] > {"outcome" => "success"} > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-13939) Upgrade SmallRye Metrics to 2.4.4

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13939?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-13939: ---------------------------------- Affects Version/s: 21.0.0.Final > Upgrade SmallRye Metrics to 2.4.4 > --------------------------------- > > Key: WFLY-13939 > URL: https://issues.redhat.com/browse/WFLY-13939 > Project: WildFly > Issue Type: Component Upgrade > Components: MP Metrics > Affects Versions: 21.0.0.Beta1, 21.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > Fix For: 22.0.0.Beta1 > > > Relases > https://github.com/smallrye/smallrye-metrics/releases/tag/2.4.4 > https://github.com/smallrye/smallrye-metrics/releases/tag/2.4.3 > Changelog > https://github.com/smallrye/smallrye-metrics/compare/2.4.3...2.4.4 > https://github.com/smallrye/smallrye-metrics/compare/2.4.2...2.4.3 > Notable changes > https://github.com/smallrye/smallrye-metrics/commit/b7c7313738e05cf48a2b5... potential NPE > https://github.com/smallrye/smallrye-metrics/commit/6c9a6f33eb9fed9952e5c... new API module -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-13936) Upgrade smallrye-fault-tolerance to 4.3.1

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13936?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-13936: ---------------------------------- Affects Version/s: 21.0.0.Final > Upgrade smallrye-fault-tolerance to 4.3.1 > ----------------------------------------- > > Key: WFLY-13936 > URL: https://issues.redhat.com/browse/WFLY-13936 > Project: WildFly > Issue Type: Component Upgrade > Components: MP Fault Tolerance > Affects Versions: 21.0.0.Beta1, 21.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > Fix For: 22.0.0.Beta1 > > > Brings in new API module. > Release notes: > https://github.com/smallrye/smallrye-fault-tolerance/releases/tag/4.3.1 > Changes: > https://github.com/smallrye/smallrye-fault-tolerance/compare/4.3.0...4.3.1 > Notable changes: > Fixes: > https://github.com/smallrye/smallrye-fault-tolerance/commit/0e85a1ee4c689... > https://github.com/smallrye/smallrye-fault-tolerance/commit/28b2c26fc031a... > Improvements: > https://github.com/smallrye/smallrye-fault-tolerance/commit/af4ca42825c79... > https://github.com/smallrye/smallrye-fault-tolerance/commit/4b5081ba807ea... > "Breaking changes" > https://github.com/smallrye/smallrye-fault-tolerance/commit/e195d42b01f60... - this now requires a new module and new module dependency on 'smallrye-metrics-api' > Deprecations: > https://github.com/smallrye/smallrye-fault-tolerance/commit/b03f9d90d22b0... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (JBLOGGING-145) Create an API to query information about the backing log manager

by James Perkins (Jira)

James Perkins created JBLOGGING-145: --------------------------------------- Summary: Create an API to query information about the backing log manager Key: JBLOGGING-145 URL: https://issues.redhat.com/browse/JBLOGGING-145 Project: JBoss Logging Issue Type: Feature Request Reporter: James Perkins Assignee: James Perkins Some useful items to query will be things like: * The Logger names * The loggers themselves * The handlers/appenders * The currently set level -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-13970) jpa ScannerTests.testGetBytesFromInputStream failed intermittently

by Cheng Fang (Jira)

Cheng Fang created WFLY-13970: --------------------------------- Summary: jpa ScannerTests.testGetBytesFromInputStream failed intermittently Key: WFLY-13970 URL: https://issues.redhat.com/browse/WFLY-13970 Project: WildFly Issue Type: Bug Components: JPA / Hibernate Reporter: Cheng Fang Assignee: Scott Marlow When building WildFly, the test {{org.jboss.as.jpa.hibernate5.scan.ScannerTests#testGetBytesFromInputStream}} failed intermittently at line 147 when comparing the old perf time to the new one: {code} assertTrue(oldTime > newTime); {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-13970) jpa ScannerTests.testGetBytesFromInputStream failed intermittently

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFLY-13970?page=com.atlassian.jira.plugi... ] Cheng Fang updated WFLY-13970: ------------------------------ Affects Version/s: 21.0.0.Final > jpa ScannerTests.testGetBytesFromInputStream failed intermittently > ------------------------------------------------------------------ > > Key: WFLY-13970 > URL: https://issues.redhat.com/browse/WFLY-13970 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 21.0.0.Final > Reporter: Cheng Fang > Assignee: Scott Marlow > Priority: Major > > When building WildFly, the test {{org.jboss.as.jpa.hibernate5.scan.ScannerTests#testGetBytesFromInputStream}} failed intermittently at line 147 when comparing the old perf time to the new one: > {code} > assertTrue(oldTime > newTime); > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-13691) Ajax call causes exception: Target Unreachable, 'null' returned null

by erick leal (Jira)

[ https://issues.redhat.com/browse/WFLY-13691?page=com.atlassian.jira.plugi... ] erick leal commented on WFLY-13691: ----------------------------------- [~fjuma] and [~soul2zimate] I reduced the code to a pure JSF example. It runs well on wildfly 13 (JSF 2.2) but fails in wildfly 21. You can see the code here: https://github.com/eclipse-ee4j/mojarra/issues/4734 > Ajax call causes exception: Target Unreachable, 'null' returned null > -------------------------------------------------------------------- > > Key: WFLY-13691 > URL: https://issues.redhat.com/browse/WFLY-13691 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 20.0.1.Final > Reporter: erick leal > Priority: Major > > I still have a problem with JSF 2.3 related to ViewParam, I tested it with WildFly 20.0.1 and the bug is still there. I tried to reduce the code, but I was only able to simulate the error using PrimeFaces. The code is in the repository [https://github.com/erickdeoliveiraleal/primefaces-test/tree/v... > Note that Wildfly already incorporated all the fixes recently done by [@soul2zimate|https://github.com/soul2zimate] > When you click on button the second time a exception happens, this is not the case when using mojarra 2.2, myfaces 2.2 or myfaces 2.3 > XHTML: > > {code:java} > <f:metadata> <f:viewParam id="id" name="id" value="#{testView.testClass.id}" /> </f:metadata> <h:form> <p:commandButton update="@form" /> <p:dataTable var="m" selectionMode="single" selection="#{testView.testClass}" rowKey="#{m.id}" value="#{testView.testClasses}"> </p:dataTable> </h:form>{code} > beans > {code:java} > import java.io.Serializable; import java.util.List; import javax.annotation.PostConstruct; import javax.faces.view.ViewScoped; import javax.inject.Named; @Named @ViewScoped public class TestView implements Serializable { private TestClass testClass; private List<TestClass> testClasses; @PostConstruct public void init() { testClass = new TestClass(); } public TestClass getTestClass() { return testClass; } public void setTestClass(TestClass testClass) { this.testClass = testClass; } public List<TestClass> getTestClasses() { return testClasses; } public void setTestClasses(List<TestClass> testClasses) { this.testClasses = testClasses; } }{code} > model > {code:java} > public class TestClass { Integer id; public Integer getId() { return id; } public void setId(Integer id) { this.id = id; } }{code} > You also need to set in web.xml the following param > {code:java} > <context-param> <param-name>javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL</param-name> <param-value>true</param-value> </context-param>{code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-13949) JNDI lookup for JMS Queue failing

by Francis Griffin (Jira)

[ https://issues.redhat.com/browse/WFLY-13949?page=com.atlassian.jira.plugi... ] Francis Griffin commented on WFLY-13949: ---------------------------------------- Hi Emmanuel, You are absolutely right, I attached the wrong file. Here's the correct one.[^dpsrTest.tgz] Thanks, Frank > JNDI lookup for JMS Queue failing > --------------------------------- > > Key: WFLY-13949 > URL: https://issues.redhat.com/browse/WFLY-13949 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 20.0.1.Final > Reporter: Francis Griffin > Assignee: Emmanuel Hugonnet > Priority: Major > Attachments: dpsrTest.tgz, dpsrTest.tgz > > > I have a JMS app which has been running successfully under WF10 for some years. I'm trying to migrate to WF20, but getting an error trying to look up the JMS Queue. The JDK is OpenJDK 11. > I've tried to make the reproducible case as simple as possible. The server is unpacked from the downloaded tar.gz, and is not modified except to add a guest user for JMS (which is not needed for the reproducible case, since we never actually create a Connection). The queue is the DLQ queue defined in the distribution. > The error is a NameNotFoundException: > Exception in thread "main" javax.naming.NameNotFoundException: jms/queue -- service jboss.naming.context.java.jboss.exported.jms.queue > at org.jboss.as.naming@20.0.1.Final//org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106) > at org.jboss.as.naming@20.0.1.Final//org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207) > at org.jboss.as.naming@20.0.1.Final//org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193) > at org.jboss.as.naming@20.0.1.Final//org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189) > at org.wildfly.naming-client@1.0.13.Final//org.wildfly.naming.client.remote.RemoteServerTransport.handleLookup(RemoteServerTransport.java:203) > at org.wildfly.naming-client@1.0.13.Final//org.wildfly.naming.client.remote.RemoteServerTransport$1.handleMessage(RemoteServerTransport.java:123) > at org.jboss.remoting@5.0.18.Final//org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430) > at org.jboss.remoting@5.0.18.Final//org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:991) > at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) > at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) > at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) > at java.base/java.lang.Thread.run(Thread.java:834) > No matter what queue name I use, the lookup is failing on the string jms/queue rather than the expected jms/queue/DLQ. > I fully expect that this is some stupid error on my part, something I'm looking at and just not seeing, because I know of others (albeit using Windows) who are using 20.0.1.Final for the full app without issue. But I can't for the life of me see what it is. > Tha actual full application looks up a ConnectionFactory of "jms/RemoteConnectionFactory" and creates Connections and Sessions before looking up the Queue name. The lookup for the factory name works perfectly, as does the other stuff, but the lookup for the Queue name gets the same NameNotFoundException shown above. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-13949) JNDI lookup for JMS Queue failing

by Francis Griffin (Jira)

[ https://issues.redhat.com/browse/WFLY-13949?page=com.atlassian.jira.plugi... ] Francis Griffin updated WFLY-13949: ----------------------------------- Attachment: dpsrTest.tgz > JNDI lookup for JMS Queue failing > --------------------------------- > > Key: WFLY-13949 > URL: https://issues.redhat.com/browse/WFLY-13949 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 20.0.1.Final > Reporter: Francis Griffin > Assignee: Emmanuel Hugonnet > Priority: Major > Attachments: dpsrTest.tgz, dpsrTest.tgz > > > I have a JMS app which has been running successfully under WF10 for some years. I'm trying to migrate to WF20, but getting an error trying to look up the JMS Queue. The JDK is OpenJDK 11. > I've tried to make the reproducible case as simple as possible. The server is unpacked from the downloaded tar.gz, and is not modified except to add a guest user for JMS (which is not needed for the reproducible case, since we never actually create a Connection). The queue is the DLQ queue defined in the distribution. > The error is a NameNotFoundException: > Exception in thread "main" javax.naming.NameNotFoundException: jms/queue -- service jboss.naming.context.java.jboss.exported.jms.queue > at org.jboss.as.naming@20.0.1.Final//org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106) > at org.jboss.as.naming@20.0.1.Final//org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207) > at org.jboss.as.naming@20.0.1.Final//org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193) > at org.jboss.as.naming@20.0.1.Final//org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189) > at org.wildfly.naming-client@1.0.13.Final//org.wildfly.naming.client.remote.RemoteServerTransport.handleLookup(RemoteServerTransport.java:203) > at org.wildfly.naming-client@1.0.13.Final//org.wildfly.naming.client.remote.RemoteServerTransport$1.handleMessage(RemoteServerTransport.java:123) > at org.jboss.remoting@5.0.18.Final//org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430) > at org.jboss.remoting@5.0.18.Final//org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:991) > at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) > at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) > at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) > at java.base/java.lang.Thread.run(Thread.java:834) > No matter what queue name I use, the lookup is failing on the string jms/queue rather than the expected jms/queue/DLQ. > I fully expect that this is some stupid error on my part, something I'm looking at and just not seeing, because I know of others (albeit using Windows) who are using 20.0.1.Final for the full app without issue. But I can't for the life of me see what it is. > Tha actual full application looks up a ConnectionFactory of "jms/RemoteConnectionFactory" and creates Connections and Sessions before looking up the Queue name. The lookup for the factory name works perfectly, as does the other stuff, but the lookup for the Queue name gets the same NameNotFoundException shown above. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 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 October 2020