[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 edited comment on WFLY-13949 at 10/14/20 9:44 AM:
--------------------------------------------------------------------
Your JNDI name is incorrect, you should be using (note the removed /) :
{code:java}
/subsystem=messaging-activemq/server=default/jms-queue=test1/:add(entries=["java:jboss/exported/jms/queue/test1"]){code}
was (Author: ehugonnet):
Your JNDI name is incorrect, you should be using :
{code:java}
/subsystem=messaging-activemq/server=default/jms-queue=test1/:add(entries=["java:jboss/exported/jms/queue/test1"]) {code}
> 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 Emmanuel Hugonnet (Jira)
[ https://issues.redhat.com/browse/WFLY-13949?page=com.atlassian.jira.plugi... ]
Emmanuel Hugonnet commented on WFLY-13949:
------------------------------------------
Your JNDI name is incorrect, you should be using :
{code:java}
/subsystem=messaging-activemq/server=default/jms-queue=test1/:add(entries=["java:jboss/exported/jms/queue/test1"]) {code}
> 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 Emmanuel Hugonnet (Jira)
[ https://issues.redhat.com/browse/WFLY-13949?page=com.atlassian.jira.plugi... ]
Emmanuel Hugonnet edited comment on WFLY-13949 at 10/14/20 9:30 AM:
--------------------------------------------------------------------
Found the shell scripts under src/main/resources
was (Author: ehugonnet):
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)
3 years, 6 months
[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 resolved JGRP-2430.
----------------------------
Resolution: Done
> 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)
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:
------------------------------------------
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)
3 years, 6 months
[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)
3 years, 6 months
[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)
3 years, 6 months
[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)
3 years, 6 months