[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)
3 years, 6 months
[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)
3 years, 6 months
[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)
3 years, 6 months
[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)
3 years, 6 months
[Red Hat JIRA] (WFLY-13949) JNDI lookup for JMS Queue failing
by Emmanuel Hugonnet (Jira)
[ https://issues.redhat.com/browse/WFLY-13949?page=com.atlassian.jira.plugi... ]
Emmanuel Hugonnet commented on WFLY-13949:
------------------------------------------
Then the reproducer code is 'wrong' as it never target the DLQ queue
> 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
>
>
> 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)
3 years, 6 months
[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're mixing use cases from the forum activity. The use case in the JIRA does not involve me creating a Queue called test1. It uses the predefined DLQ Queue that comes with the distribution. The only modification to the distro in the JIRA is to define a user with users.sh, and that's probably not necessary since the test case does not create a Connection which would require authentication. The point of this is that the JIRA case uses an unmodifed standalone-full.xml, as shipped (adding the user only affects the user files outside of standalone-full.xml).
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
>
>
> 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)
3 years, 6 months
[Red Hat JIRA] (DROOLS-5026) Remove blinkinking in Test Tools pannel
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-5026?page=com.atlassian.jira.plug... ]
Yeser Amer updated DROOLS-5026:
-------------------------------
Sprint: 2020 Week 43-45 (from Okt 19)
> Remove blinkinking in Test Tools pannel
> ---------------------------------------
>
> Key: DROOLS-5026
> URL: https://issues.redhat.com/browse/DROOLS-5026
> Project: Drools
> Issue Type: Enhancement
> Components: Scenario Simulation and Testing
> Affects Versions: 7.30.0.Final
> Reporter: Anna Dupliak
> Assignee: Yeser Amer
> Priority: Minor
> Labels: drools-tools
> Fix For: 7.46.0.Final
>
> Attachments: Screencast from 02-07-2020.webm
>
>
> Change Test Tools behavior to stop blinking every time when
> focus in *Grid* are moving through *Header*.
> Now if you move focus in *Grid* particularly for *Header*
> rows (by using keyboard arrows keys) then Test Tools icon blinks.
> That is not happening with values in the Grid.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 6 months