October 2020 - jboss-jira - Jboss List Archives

[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: ------------------------------------------ Your shell scripts are not present > 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)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-13698) NullPointerException due to JSFDependencyProcessor adding null ModuleIdentifer

by Lin Gao (Jira)

[ https://issues.redhat.com/browse/WFLY-13698?page=com.atlassian.jira.plugi... ] Lin Gao updated WFLY-13698: --------------------------- Labels: downstream_dependency (was: ) > NullPointerException due to JSFDependencyProcessor adding null ModuleIdentifer > ------------------------------------------------------------------------------ > > Key: WFLY-13698 > URL: https://issues.redhat.com/browse/WFLY-13698 > Project: WildFly > Issue Type: Bug > Components: JSF > Reporter: Moulali Shikalwadi > Assignee: Moulali Shikalwadi > Priority: Major > Labels: downstream_dependency > > Caused by: java.lang.NullPointerException > at org.jboss.modules.DependencySpec.createModuleDependencySpec(DependencySpec.java:637) [jboss-modules.jar:1.8.9.Final-redhat-00001] > at org.jboss.modules.DependencySpec.createModuleDependencySpec(DependencySpec.java:593) [jboss-modules.jar:1.8.9.Final-redhat-00001] > at org.jboss.as.server.deployment.module.ModuleSpecProcessor.createDependencies(ModuleSpecProcessor.java:346) [wildfly-server-6.0.27.Final-redhat-00001.jar:6.0.27.Final-redhat-00001] > at org.jboss.as.server.deployment.module.ModuleSpecProcessor.createModuleService(ModuleSpecProcessor.java:236) [wildfly-server-6.0.27.Final-redhat-00001.jar:6.0.27.Final-redhat-00001] > at org.jboss.as.server.deployment.module.ModuleSpecProcessor.deployModuleSpec(ModuleSpecProcessor.java:130) [wildfly-server-6.0.27.Final-redhat-00001.jar:6.0.27.Final-redhat-00001] > at org.jboss.as.server.deployment.module.ModuleSpecProcessor.deploy(ModuleSpecProcessor.java:82) [wildfly-server-6.0.27.Final-redhat-00001.jar:6.0.27.Final-redhat-00001] > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:144) [wildfly-server-6.0.27.Final-redhat-00001.jar:6.0.27.Final-redhat-00001] > ... 8 more -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-5670) DMN produce programmatically Swagger/OpenAPI components type info

by Kris Verlaenen (Jira)

[ https://issues.redhat.com/browse/DROOLS-5670?page=com.atlassian.jira.plug... ] Kris Verlaenen updated DROOLS-5670: ----------------------------------- Fix Version/s: (was: 7.46.0.Final) > DMN produce programmatically Swagger/OpenAPI components type info > ----------------------------------------------------------------- > > Key: DROOLS-5670 > URL: https://issues.redhat.com/browse/DROOLS-5670 > Project: Drools > Issue Type: Story > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > Labels: kogito > Fix For: 7.45.0.Final > > > *Motivation*: generating Swagger definitions from annotation proved limiting > *Goals*: generate JSONSchema Component for Swagger/OpenAPI programmatically from the DMN model definition, since this gives fine tuned control would overcome the current limitation from annotation based strategies. > *Impacts*: none --eventually Kogito, Kie7, etc. can make use of this later -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-5670) DMN produce programmatically Swagger/OpenAPI components type info

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-5670?page=com.atlassian.jira.plug... ] Matteo Mortari updated DROOLS-5670: ----------------------------------- Fix Version/s: 7.45.0.Final > DMN produce programmatically Swagger/OpenAPI components type info > ----------------------------------------------------------------- > > Key: DROOLS-5670 > URL: https://issues.redhat.com/browse/DROOLS-5670 > Project: Drools > Issue Type: Story > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > Labels: kogito > Fix For: 7.45.0.Final, 7.46.0.Final > > > *Motivation*: generating Swagger definitions from annotation proved limiting > *Goals*: generate JSONSchema Component for Swagger/OpenAPI programmatically from the DMN model definition, since this gives fine tuned control would overcome the current limitation from annotation based strategies. > *Impacts*: none --eventually Kogito, Kie7, etc. can make use of this later -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-3160) adapt kie upstream reps for Thorntail 2.2 (ex WildFly Swarm)

by Kris Verlaenen (Jira)

[ https://issues.redhat.com/browse/DROOLS-3160?page=com.atlassian.jira.plug... ] Kris Verlaenen updated DROOLS-3160: ----------------------------------- Fix Version/s: (was: 7.45.0.Final) > adapt kie upstream reps for Thorntail 2.2 (ex WildFly Swarm) > ------------------------------------------------------------ > > Key: DROOLS-3160 > URL: https://issues.redhat.com/browse/DROOLS-3160 > Project: Drools > Issue Type: Feature Request > Reporter: Michael Biarnes Kiefer > Assignee: Toni Rikkola > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-5095) [DMN Designer] Investigate performance switching between editor instances

by Kris Verlaenen (Jira)

[ https://issues.redhat.com/browse/DROOLS-5095?page=com.atlassian.jira.plug... ] Kris Verlaenen updated DROOLS-5095: ----------------------------------- Fix Version/s: (was: 7.45.0.Final) > [DMN Designer] Investigate performance switching between editor instances > ------------------------------------------------------------------------- > > Key: DROOLS-5095 > URL: https://issues.redhat.com/browse/DROOLS-5095 > Project: Drools > Issue Type: Task > Components: DMN Editor > Affects Versions: 7.33.0.Final > Reporter: Jozef Marko > Assignee: Guilherme Gomes > Priority: Minor > Labels: drools-tools > Attachments: switch-dmn.webm > > > This JIRA is to investigate the reported performance issue switching between different DMN Designer instances in Business Central. > The issue was noticed by [~jomarko] when testing DROOLS-5058 (although the fix therein should have had *zero* affect on switching). > For more details see the video [^switch-dmn.webm] > h2. Manual acceptance test > - Prepare 5 DMN models in project > - Open all in parallel > - Try to switch between them, keep all opened -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-2254) Automate .proto files rebuild in pom.xml

by Kris Verlaenen (Jira)

[ https://issues.redhat.com/browse/DROOLS-2254?page=com.atlassian.jira.plug... ] Kris Verlaenen updated DROOLS-2254: ----------------------------------- Fix Version/s: (was: 7.45.0.Final) > Automate .proto files rebuild in pom.xml > ---------------------------------------- > > Key: DROOLS-2254 > URL: https://issues.redhat.com/browse/DROOLS-2254 > Project: Drools > Issue Type: Task > Components: tools > Affects Versions: 7.5.0.Final > Reporter: Dmitry Volodin > Assignee: Dmitry Volodin > Priority: Minor > > According to contribution guide, any .proto file or protobuf version changes it's necessary to download protoc utility and regenerate Java classes based on .proto files. > This will add automation for downloading protoc utility and Java classes generation based on Maven Protocol Buffers Plugin. There is no timestamps and other build related info inside generated Java files and no changes will be added on each new build. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (JGRP-2430) GossipRouter: more efficient routing

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2430?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-2430: -------------------------------- There are 2 types of input/output: InputStream/OutputStream (TCP) and ByteBuffer (TCP_NIO2). * InputStream: there is no native way of transferring N bytes from input to outout for 1-1 messages. Ditto for 1-m messages; even if there was, we can't pass the same InputStream transfer to multiple OutputStreams, as reading off of the input stream advances the read pointer * ByteBuffer: here, we can pass the ByteBuffer read from the input to multiple outputs, but - as reading advances the {{position}} of a ByteBuffer, we need to call {{duplicate()}} on the ByteBuffer before passing it to the output. All in all, these are rather modest improvements... > GossipRouter: more efficient routing > ------------------------------------ > > Key: JGRP-2430 > URL: https://issues.redhat.com/browse/JGRP-2430 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.1 > > > GossipRouter supports both NIO (ByteBuffer) and TCP (stream-based) connections. In both cases, however, the entire message is read and then routed to the destination address. > It would be better to only read the cluster name and target address, and then use efficient stream-to-stream (or channel-to-channel) _transfer mechanisms_, which avoids temporary copies of data and the full reading of messages. > Also look into routing of entire message _batches_. > Investigate whether this is possible. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-5670) DMN produce programmatically Swagger/OpenAPI components type info

by Kris Verlaenen (Jira)

[ https://issues.redhat.com/browse/DROOLS-5670?page=com.atlassian.jira.plug... ] Kris Verlaenen updated DROOLS-5670: ----------------------------------- Labels: kogito (was: ) > DMN produce programmatically Swagger/OpenAPI components type info > ----------------------------------------------------------------- > > Key: DROOLS-5670 > URL: https://issues.redhat.com/browse/DROOLS-5670 > Project: Drools > Issue Type: Story > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > Labels: kogito > > *Motivation*: generating Swagger definitions from annotation proved limiting > *Goals*: generate JSONSchema Component for Swagger/OpenAPI programmatically from the DMN model definition, since this gives fine tuned control would overcome the current limitation from annotation based strategies. > *Impacts*: none --eventually Kogito, Kie7, etc. can make use of this later -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-5670) DMN produce programmatically Swagger/OpenAPI components type info

by Kris Verlaenen (Jira)

[ https://issues.redhat.com/browse/DROOLS-5670?page=com.atlassian.jira.plug... ] Kris Verlaenen updated DROOLS-5670: ----------------------------------- Fix Version/s: 7.46.0.Final > DMN produce programmatically Swagger/OpenAPI components type info > ----------------------------------------------------------------- > > Key: DROOLS-5670 > URL: https://issues.redhat.com/browse/DROOLS-5670 > Project: Drools > Issue Type: Story > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > Labels: kogito > Fix For: 7.46.0.Final > > > *Motivation*: generating Swagger definitions from annotation proved limiting > *Goals*: generate JSONSchema Component for Swagger/OpenAPI programmatically from the DMN model definition, since this gives fine tuned control would overcome the current limitation from annotation based strategies. > *Impacts*: none --eventually Kogito, Kie7, etc. can make use of this later -- 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