[JBoss JIRA] (WFLY-10876) Align jar file provided for MP OpenTracing into right modules
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-10876?page=com.atlassian.jira.plugin... ]
James Perkins commented on WFLY-10876:
--------------------------------------
I still wonder if we should have a {{io.opentracing.*}} modules for each of the opentracing dependencies rather than including them in the {{io.smallrye.opentracing}} module. I'll have to look in more detail about how these dependencies relate though.
> Align jar file provided for MP OpenTracing into right modules
> -------------------------------------------------------------
>
> Key: WFLY-10876
> URL: https://issues.jboss.org/browse/WFLY-10876
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing
> Affects Versions: 14.0.0.Beta2
> Reporter: Jan Stourac
> Assignee: Juraci Paixão Kröhling
> Priority: Critical
>
> With recent addition of MicroProfile OpenTracing implementation we currently have following set of jar files that are in the build to provide various MicroProfile features:
> {code}
> $ find modules | grep smallrye | grep jar$ | xargs ls -hl
> -rw-rw-r--. 1 jstourac jstourac 39K Aug 16 15:13 modules/system/layers/base/io/smallrye/config/main/smallrye-config-1.3.3.jar
> -rw-rw-r--. 1 jstourac jstourac 8.9K Aug 16 15:13 modules/system/layers/base/io/smallrye/health/main/smallrye-health-1.0.2.jar
> -rw-rw-r--. 1 jstourac jstourac 38K Aug 16 15:13 modules/system/layers/base/org/wildfly/extension/microprofile/config-smallrye/main/wildfly-microprofile-config-smallrye-14.0.0.CR1-SNAPSHOT.jar
> -rw-rw-r--. 1 jstourac jstourac 27K Aug 16 15:13 modules/system/layers/base/org/wildfly/extension/microprofile/health-smallrye/main/wildfly-microprofile-health-smallrye-14.0.0.CR1-SNAPSHOT.jar
> -rw-rw-r--. 1 jstourac jstourac 228K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/gson-2.8.2.jar
> -rw-rw-r--. 1 jstourac jstourac 123K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/jaeger-core-0.30.4.jar
> -rw-rw-r--. 1 jstourac jstourac 2.8M Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/jaeger-thrift-0.30.4.jar
> -rw-rw-r--. 1 jstourac jstourac 14K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-api-0.31.0.jar
> -rw-rw-r--. 1 jstourac jstourac 7.5K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-concurrent-0.1.0.jar
> -rw-rw-r--. 1 jstourac jstourac 41K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-jaxrs2-0.1.6.jar
> -rw-rw-r--. 1 jstourac jstourac 11K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-noop-0.31.0.jar
> -rw-rw-r--. 1 jstourac jstourac 7.4K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-tracerresolver-0.1.5.jar
> -rw-rw-r--. 1 jstourac jstourac 7.9K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-util-0.31.0.jar
> -rw-rw-r--. 1 jstourac jstourac 13K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-web-servlet-filter-0.1.0.jar
> -rw-rw-r--. 1 jstourac jstourac 5.4K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/smallrye-opentracing-1.1.1.jar
> -rw-rw-r--. 1 jstourac jstourac 11K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/wildfly-microprofile-opentracing-smallrye-14.0.0.CR1-SNAPSHOT.jar
> {code}
> It looks like the opentracing-smallrye module could be split up into a few separate modules. There at least two motivations:
> # particular implementation into its own module separate from the e.g. microprofile specification
> # because of the way how current patching mechanism works in WildFly, if we leave current {{opentracing-smallrye}} module as is, in case of a one-off patch it would mean to replace all files in the module - currently 3.3MB:
> {code}
> $ du -h modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/
> 3.3M modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/
> {code}
> My proposal how to align the jar files is following:
> # jaeger specific files should go into separate jaeger module
> # {{wildfly-microprofile-opentracing-smallrye-14.0.0.CR1-SNAPSHOT.jar}} should be moved to new {{modules/system/layers/base/org/wildfly/extension/microprofile/opentracing-smallrye}} module so it matches what is done for {{health-smallrye}} and {{config-smallrye}} in extension subdir
> # {{smallrye-opentracing-1.1.1.jar}} should be moved to {{base/io}} as is done for {{config}} and {{health}} - {{modules/system/layers/base/io/smallrye/opentracing/main/smallrye-opentracing-1.1.1.jar}}
> # what about that {{gson-2.8.2.jar}} dependency? Shall it be moved to some more generic place?
> This would give us following structure:
> {code}
> modules/system/layers/base/io/smallrye/config/main/smallrye-config-1.3.3.jar
> modules/system/layers/base/io/smallrye/health/main/smallrye-health-1.0.2.jar
> modules/system/layers/base/io/smallrye/opentracing/main/smallrye-opentracing-1.1.1.jar
> modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-api-0.31.0.jar
> modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-jaxrs2-0.1.6.jar
> modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-concurrent-0.1.0.jar
> modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-web-servlet-filter-0.1.0.jar
> modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-noop-0.31.0.jar
> modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-tracerresolver-0.1.5.jar
> modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-util-0.31.0.jar
> modules/system/layers/base/org/wildfly/extension/microprofile/health-smallrye/main/wildfly-microprofile-health-smallrye-14.0.0.CR1-SNAPSHOT.jar
> modules/system/layers/base/org/wildfly/extension/microprofile/config-smallrye/main/wildfly-microprofile-config-smallrye-14.0.0.CR1-SNAPSHOT.jar
> modules/system/layers/base/org/wildfly/extension/microprofile/opentracing-smallrye/main/wildfly-microprofile-opentracing-smallrye-14.0.0.CR1-SNAPSHOT.jar
> ---- I have no idea how this module for jaeger should be named...
> modules/system/layers/base/org/wildfly/microprofile/jaeger/opentracing-smallrye/main/jaeger-thrift-0.30.4.jar
> modules/system/layers/base/org/wildfly/microprofile/jaeger/opentracing-smallrye/main/jaeger-core-0.30.4.jar
> ---- I have no idea how this module for gson should be named...
> modules/system/layers/base/org/wildfly/gson/main/gson-2.8.2.jar
> {code}
> One additional piece for consideration - maybe we should also split up jar files that are just the microprofile-opentracing specification (api at least I guess) apart from the others in the {{modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/}}
> What do you think?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-4044) Suggested capabilities for logging capabilities return suggestions that may not be available
by James Perkins (JIRA)
James Perkins created WFCORE-4044:
-------------------------------------
Summary: Suggested capabilities for logging capabilities return suggestions that may not be available
Key: WFCORE-4044
URL: https://issues.jboss.org/browse/WFCORE-4044
Project: WildFly Core
Issue Type: Bug
Components: Logging
Reporter: James Perkins
Assignee: James Perkins
The logging subsystem registers capabilities for the base subsystem and each logging profile. However the logging profile name should be considered dynamically unique. Meaning that the {{suggest-capabilities}} should only return results available for the base subsystem or the logging profile. For example if a logging profile exists with a {{pattern-formatter}} of {{PROFILE-PATTERN}} this would be included for suggested formatters on the base subsystem. Likewise the default {{PATTERN}} and {{COLOR-PATTERN}} would be suggested for handlers on the logging profile.
Essentially the {{LoggingProfileNameMapper}} and the {{LoggingProfileCapabilityRecorder}} dynamically add the logging profile name to the capability name. This may be a limitation of capabilities in general, but it's something that needs to be looked at.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (ELY-1639) FIPS PKCS11 Client side: only SunJSSE KeyManagers may be used
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1639?page=com.atlassian.jira.plugin.s... ]
Jan Kalina commented on ELY-1639:
---------------------------------
In the end resolved using FilteringKeyStore which is already used on server-side.
Updated documentation in WFLY-10882
> FIPS PKCS11 Client side: only SunJSSE KeyManagers may be used
> -------------------------------------------------------------
>
> Key: ELY-1639
> URL: https://issues.jboss.org/browse/ELY-1639
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Blocker
> Attachments: cli-wildfly-config.xml
>
>
> Fix of ELY-1622 introduced regression. It is not possible to do 1 way ssl (no key-store-ssl-certificate in wildfly-config.xml) with exception
> {code}
> 14:13:56,143 ERROR [org.jboss.as.cli.impl.CliLauncher] Error processing CLI: org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:330)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:291)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:45)
> at org.jboss.modules.Module.run(Module.java:352)
> at org.jboss.modules.Module.run(Module.java:320)
> at org.jboss.modules.Main.main(Main.java:593)
> Caused by: org.jboss.as.cli.CommandLineException: Failed to resolve host 'localhost'
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1256)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1203)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1198)
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:328)
> ... 5 more
> Caused by: java.io.IOException: Failed to obtain SSLContext
> at org.jboss.as.cli.impl.CLIModelControllerClient.<init>(CLIModelControllerClient.java:156)
> at org.jboss.as.cli.impl.ModelControllerClientFactory$2.getClient(ModelControllerClientFactory.java:85)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1222)
> ... 8 more
> Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE KeyManagers may be used
> at sun.security.ssl.SSLContextImpl.chooseKeyManager(SSLContextImpl.java:149)
> at sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:66)
> at javax.net.ssl.SSLContext.init(SSLContext.java:282)
> at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:372)
> at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:53)
> at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.getSSLContext(AuthenticationContextConfigurationClient.java:221)
> at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.getSSLContext(AuthenticationContextConfigurationClient.java:208)
> at org.jboss.as.cli.impl.CLIModelControllerClient.<init>(CLIModelControllerClient.java:153)
> ... 10 more
> {code}
> It is because after fix Fix of ELY-1622 custom keymanager is used. But it is forbidden by jdk FIPS PKCS11.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10882) FIPS PKCS11 Client side: only SunJSSE KeyManagers may be used
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-10882?page=com.atlassian.jira.plugin... ]
Jan Kalina updated WFLY-10882:
------------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/11539 (was: https://github.com/wildfly-security/wildfly-elytron/pull/1178)
> FIPS PKCS11 Client side: only SunJSSE KeyManagers may be used
> -------------------------------------------------------------
>
> Key: WFLY-10882
> URL: https://issues.jboss.org/browse/WFLY-10882
> Project: WildFly
> Issue Type: Bug
> Components: Documentation
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
>
> Fix of ELY-1622 introduced regression. It is not possible to do 1 way ssl (no key-store-ssl-certificate in wildfly-config.xml) with exception
> {code}
> 14:13:56,143 ERROR [org.jboss.as.cli.impl.CliLauncher] Error processing CLI: org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:330)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:291)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:45)
> at org.jboss.modules.Module.run(Module.java:352)
> at org.jboss.modules.Module.run(Module.java:320)
> at org.jboss.modules.Main.main(Main.java:593)
> Caused by: org.jboss.as.cli.CommandLineException: Failed to resolve host 'localhost'
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1256)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1203)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1198)
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:328)
> ... 5 more
> Caused by: java.io.IOException: Failed to obtain SSLContext
> at org.jboss.as.cli.impl.CLIModelControllerClient.<init>(CLIModelControllerClient.java:156)
> at org.jboss.as.cli.impl.ModelControllerClientFactory$2.getClient(ModelControllerClientFactory.java:85)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1222)
> ... 8 more
> Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE KeyManagers may be used
> at sun.security.ssl.SSLContextImpl.chooseKeyManager(SSLContextImpl.java:149)
> at sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:66)
> at javax.net.ssl.SSLContext.init(SSLContext.java:282)
> at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:372)
> at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:53)
> at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.getSSLContext(AuthenticationContextConfigurationClient.java:221)
> at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.getSSLContext(AuthenticationContextConfigurationClient.java:208)
> at org.jboss.as.cli.impl.CLIModelControllerClient.<init>(CLIModelControllerClient.java:153)
> ... 10 more
> {code}
> It is because after fix Fix of ELY-1622 custom keymanager is used. But it is forbidden by jdk FIPS PKCS11.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10882) FIPS PKCS11 Client side: only SunJSSE KeyManagers may be used
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-10882?page=com.atlassian.jira.plugin... ]
Jan Kalina moved ELY-1649 to WFLY-10882:
----------------------------------------
Project: WildFly (was: WildFly Elytron)
Key: WFLY-10882 (was: ELY-1649)
Component/s: Documentation
(was: SSL)
> FIPS PKCS11 Client side: only SunJSSE KeyManagers may be used
> -------------------------------------------------------------
>
> Key: WFLY-10882
> URL: https://issues.jboss.org/browse/WFLY-10882
> Project: WildFly
> Issue Type: Bug
> Components: Documentation
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
>
> Fix of ELY-1622 introduced regression. It is not possible to do 1 way ssl (no key-store-ssl-certificate in wildfly-config.xml) with exception
> {code}
> 14:13:56,143 ERROR [org.jboss.as.cli.impl.CliLauncher] Error processing CLI: org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:330)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:291)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:45)
> at org.jboss.modules.Module.run(Module.java:352)
> at org.jboss.modules.Module.run(Module.java:320)
> at org.jboss.modules.Main.main(Main.java:593)
> Caused by: org.jboss.as.cli.CommandLineException: Failed to resolve host 'localhost'
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1256)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1203)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1198)
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:328)
> ... 5 more
> Caused by: java.io.IOException: Failed to obtain SSLContext
> at org.jboss.as.cli.impl.CLIModelControllerClient.<init>(CLIModelControllerClient.java:156)
> at org.jboss.as.cli.impl.ModelControllerClientFactory$2.getClient(ModelControllerClientFactory.java:85)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1222)
> ... 8 more
> Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE KeyManagers may be used
> at sun.security.ssl.SSLContextImpl.chooseKeyManager(SSLContextImpl.java:149)
> at sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:66)
> at javax.net.ssl.SSLContext.init(SSLContext.java:282)
> at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:372)
> at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:53)
> at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.getSSLContext(AuthenticationContextConfigurationClient.java:221)
> at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.getSSLContext(AuthenticationContextConfigurationClient.java:208)
> at org.jboss.as.cli.impl.CLIModelControllerClient.<init>(CLIModelControllerClient.java:153)
> ... 10 more
> {code}
> It is because after fix Fix of ELY-1622 custom keymanager is used. But it is forbidden by jdk FIPS PKCS11.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (ELY-1649) FIPS PKCS11 Client side: only SunJSSE KeyManagers may be used
by Jan Kalina (JIRA)
Jan Kalina created ELY-1649:
-------------------------------
Summary: FIPS PKCS11 Client side: only SunJSSE KeyManagers may be used
Key: ELY-1649
URL: https://issues.jboss.org/browse/ELY-1649
Project: WildFly Elytron
Issue Type: Bug
Components: SSL
Reporter: Jan Kalina
Assignee: Jan Kalina
Priority: Blocker
Fix of ELY-1622 introduced regression. It is not possible to do 1 way ssl (no key-store-ssl-certificate in wildfly-config.xml) with exception
{code}
14:13:56,143 ERROR [org.jboss.as.cli.impl.CliLauncher] Error processing CLI: org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:330)
at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:291)
at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:45)
at org.jboss.modules.Module.run(Module.java:352)
at org.jboss.modules.Module.run(Module.java:320)
at org.jboss.modules.Main.main(Main.java:593)
Caused by: org.jboss.as.cli.CommandLineException: Failed to resolve host 'localhost'
at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1256)
at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1203)
at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1198)
at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:328)
... 5 more
Caused by: java.io.IOException: Failed to obtain SSLContext
at org.jboss.as.cli.impl.CLIModelControllerClient.<init>(CLIModelControllerClient.java:156)
at org.jboss.as.cli.impl.ModelControllerClientFactory$2.getClient(ModelControllerClientFactory.java:85)
at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1222)
... 8 more
Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE KeyManagers may be used
at sun.security.ssl.SSLContextImpl.chooseKeyManager(SSLContextImpl.java:149)
at sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:66)
at javax.net.ssl.SSLContext.init(SSLContext.java:282)
at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:372)
at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:53)
at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.getSSLContext(AuthenticationContextConfigurationClient.java:221)
at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.getSSLContext(AuthenticationContextConfigurationClient.java:208)
at org.jboss.as.cli.impl.CLIModelControllerClient.<init>(CLIModelControllerClient.java:153)
... 10 more
{code}
It is because after fix Fix of ELY-1622 custom keymanager is used. But it is forbidden by jdk FIPS PKCS11.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-95) [Artemis 2.x Upgrade] Client is not able to instantiate destinations by names
by Amine Belkoura (JIRA)
[ https://issues.jboss.org/browse/WFWIP-95?page=com.atlassian.jira.plugin.s... ]
Amine Belkoura commented on WFWIP-95:
-------------------------------------
Agree with Miroslav. A lot of our customers do not go through JNDI. They connect to the broker directly and create message consumers. I feel that this should be supported, or it will create a lot of headache.
[~jmesnil]: you mentioned "Application should use JNDI to lookup JMS resources and not use broker-specific library." How about MDBs hosted inside EAP? MDBs can be configured to use JNDI name or straight queue names. Is using queue names without going trough JNDI also not supported in this case? I am not sure what if ActiveMQJMSClient library is used under the cover for that?
> [Artemis 2.x Upgrade] Client is not able to instantiate destinations by names
> -----------------------------------------------------------------------------
>
> Key: WFWIP-95
> URL: https://issues.jboss.org/browse/WFWIP-95
> Project: WildFly WIP
> Issue Type: Bug
> Components: JMS
> Reporter: Martin Styk
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: activemq
>
> Having queue defined as follows
> {code:xml}
> <jms-queue name="InQueue" entries="jms/queue/InQueue java:jboss/exported/jms/queue/InQueue" durable="true"/>
> {code}
> Client is instantiating it directly using its name.
> {code:title=Client}
> HashMap<String, Object> map = new HashMap<String, Object>();
> map.put("host", hostName);
> map.put(TransportConstants.HTTP_UPGRADE_ENABLED_PROP_NAME, true);
> map.put("port", httpPort);
> TransportConfiguration transportConfiguration = new TransportConfiguration(NettyConnectorFactory.class.getName(), map);
> try {
> ConnectionFactory cf = ActiveMQJMSClient.createConnectionFactoryWithoutHA(JMSFactoryType.CF, transportConfiguration);
> Queue orderQueue = ActiveMQJMSClient.createQueue("InQueue");
> connection = cf.createConnection();
> session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
> MessageProducer producer = session.createProducer(orderQueue);
> connection.start();
> ...
> {code}
> Client is not able to send messages to, because {{session.createProducer(orderQueue)}} throws following exception
> {code}
> javax.jms.InvalidDestinationException: Destination InQueue does not exist
> at org.apache.activemq.artemis.jms.client.ActiveMQSession.createProducer(ActiveMQSession.java:326)
> {code}
> This is regression against EAP 7.1.0
> Issue was hit with Artemis 2.5.0 with https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_w... (commit 51dd8102f103ccb0470a3cfc8713d3f9bdb1b65d)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months