[JBoss JIRA] (WFLY-7133) Automatically define resource adapter for deployed RARs
by Thönnes Thönnes (JIRA)
[ https://issues.jboss.org/browse/WFLY-7133?page=com.atlassian.jira.plugin.... ]
Thönnes Thönnes commented on WFLY-7133:
---------------------------------------
[~ggam], in the documentation I also read that automatic configuration can be done:
{quote}
Automatic activation of resource adapter archives
A resource adapter archive can be automatically activated with a configuration by including an META-INF/ironjacamar.xml in the archive.
The schema can be found at http://docs.jboss.org/ironjacamar/schema/ironjacamar_1_0.xsd
{quote}
This works fine for me. But with regard to a list of available resource adapter to get an overview and to fine tune configuration -- I completely agree with you.
But then the ticket title is misleading.
> Automatically define resource adapter for deployed RARs
> -------------------------------------------------------
>
> Key: WFLY-7133
> URL: https://issues.jboss.org/browse/WFLY-7133
> Project: WildFly
> Issue Type: Feature Request
> Components: JCA
> Affects Versions: 10.1.0.Final
> Reporter: Guillermo González de Agüero
> Assignee: Jesper Pedersen
>
> Deploying a RAR file enables the resource adapter for the server, but in order to configure it, you must manually add it to the Resource Adapters subsystem. This is error prone (you can put in invalid "archive name" for the resource adapter and it doesn't complaint) and little user friendly.
> From a user perspective and from what can be read from the documentation (https://docs.jboss.org/author/display/WFLY10/Resource+adapters), it seems like the resource adapter is not enabled unless you explicitly define it.
> It would be very simpler if RA deployments would be detected and registered as it's done for deployed JDBC drivers.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFCORE-644) jboss-cli needs to support using PKCS11 (including FIPS mode) keystores/truststores
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-644?page=com.atlassian.jira.plugin... ]
Darran Lofthouse commented on WFCORE-644:
-----------------------------------------
[~aloubyansky] FYI I have taken this one as the Elytron changes make Elytron client configuration usable within the CLI and there we can perform advanced SSL configuration to cover this kind of scenario.
> jboss-cli needs to support using PKCS11 (including FIPS mode) keystores/truststores
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-644
> URL: https://issues.jboss.org/browse/WFCORE-644
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Derek Horton
> Assignee: Darran Lofthouse
>
> The cli's SSL configuration should be expanded to support using PKCS11 keystores/truststores. Currently it does not appear to be possible to configure the keystore/truststore type in the jboss-cli.xml file.
> This is problematic when the JVM is running in FIPS mode.
> The cli throws the following exception on startup:
> $ ./bin/jboss-cli.sh
> org.jboss.as.cli.CliInitializationException: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used
> at org.jboss.as.cli.impl.CommandContextImpl.initSSLContext(CommandContextImpl.java:541)
> at org.jboss.as.cli.impl.CommandContextImpl.<init>(CommandContextImpl.java:291)
> at org.jboss.as.cli.impl.CommandContextFactoryImpl.newCommandContext(CommandContextFactoryImpl.java:76)
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:294)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:277)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.modules.Module.run(Module.java:312)
> at org.jboss.modules.Main.main(Main.java:460)
> Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used
> at sun.security.ssl.SSLContextImpl.chooseTrustManager(SSLContextImpl.java:126)
> at sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:89)
> at javax.net.ssl.SSLContext.init(SSLContext.java:283)
> at org.jboss.as.cli.impl.CommandContextImpl.initSSLContext(CommandContextImpl.java:537)
> ... 11 more
> It is possible to workaround the issue by setting the javax.net.ssl.keyStore / javax.net.ssl.trustStore system properties in the bin/jboss-cli.sh file:
> JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.trustStore=NONE -Djavax.net.ssl.trustStoreType=PKCS11"
> JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.keyStore=NONE -Djavax.net.ssl.keyStoreType=PKCS11 -Djavax.net.ssl.keyStorePassword=imapassword"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFCORE-644) jboss-cli needs to support using PKCS11 (including FIPS mode) keystores/truststores
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-644?page=com.atlassian.jira.plugin... ]
Darran Lofthouse reassigned WFCORE-644:
---------------------------------------
Assignee: Darran Lofthouse (was: Alexey Loubyansky)
> jboss-cli needs to support using PKCS11 (including FIPS mode) keystores/truststores
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-644
> URL: https://issues.jboss.org/browse/WFCORE-644
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Derek Horton
> Assignee: Darran Lofthouse
>
> The cli's SSL configuration should be expanded to support using PKCS11 keystores/truststores. Currently it does not appear to be possible to configure the keystore/truststore type in the jboss-cli.xml file.
> This is problematic when the JVM is running in FIPS mode.
> The cli throws the following exception on startup:
> $ ./bin/jboss-cli.sh
> org.jboss.as.cli.CliInitializationException: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used
> at org.jboss.as.cli.impl.CommandContextImpl.initSSLContext(CommandContextImpl.java:541)
> at org.jboss.as.cli.impl.CommandContextImpl.<init>(CommandContextImpl.java:291)
> at org.jboss.as.cli.impl.CommandContextFactoryImpl.newCommandContext(CommandContextFactoryImpl.java:76)
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:294)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:277)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.modules.Module.run(Module.java:312)
> at org.jboss.modules.Main.main(Main.java:460)
> Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used
> at sun.security.ssl.SSLContextImpl.chooseTrustManager(SSLContextImpl.java:126)
> at sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:89)
> at javax.net.ssl.SSLContext.init(SSLContext.java:283)
> at org.jboss.as.cli.impl.CommandContextImpl.initSSLContext(CommandContextImpl.java:537)
> ... 11 more
> It is possible to workaround the issue by setting the javax.net.ssl.keyStore / javax.net.ssl.trustStore system properties in the bin/jboss-cli.sh file:
> JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.trustStore=NONE -Djavax.net.ssl.trustStoreType=PKCS11"
> JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.keyStore=NONE -Djavax.net.ssl.keyStoreType=PKCS11 -Djavax.net.ssl.keyStorePassword=imapassword"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFCORE-1774) Use core-service=capability-registry to provide tab completion suggestions for model reference attributes
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1774?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise updated WFCORE-1774:
-----------------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1825
> Use core-service=capability-registry to provide tab completion suggestions for model reference attributes
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1774
> URL: https://issues.jboss.org/browse/WFCORE-1774
> Project: WildFly Core
> Issue Type: Enhancement
> Components: CLI
> Reporter: Brian Stansberry
> Assignee: Jean-Francois Denise
>
> A "model reference" attribute is one whose value points to some other aspect of the model, e.g. "socket-binding" => "http". With the capability and requirement function we are rolling out in the server[1] we have the ability for clients to understand what values are valid for the reference. This should be used in CLI tab completion.
> [~claudio4j] has utitlized this for UI suggestions in HAL so he or Harald can be a resource for the exact algorithm that has worked best. Here's the basics though:
> 1) This applies to attributes or operation params where the read-resource-description or read-operation-description includes a "capability-reference" field. The value of the field shows the static portion of the capability name. For example an attribute that's used for a socket binding name would show "org.wildfly.network.socket-binding".
> 2) The [/host=*]/core-service=capability resource shows information about what capabilities are available on the system. This includes 2 attributes "capabilities" and "possible-capabilities". The former shows the specific capabilities that are actually present; i.e. the resources that provide the capability are part of the configuration. The latter shows capabilities that could be present, given the installed extensions, if the relevant resources were added.
> That resource includes two operations "get-capability" and "get-provider-points" that can show more details about what resources provide a capability:
> {code}
> [standalone@embedded core-service=capability-registry] :get-provider-points(name=org.wildfly.network.socket-binding)
> {
> "outcome" => "success",
> "result" => ["/socket-binding-group=*/socket-binding=*"]
> }
> {code}
> That tells you that capabilities of type org.wildfly.network.socket-binding are registered by resources using address pattern /socket-binding-group=*/socket-binding=*
> 3) With that information the CLI can see what resources actually exist on the system and use the value portion of the final element of their address as the suggestion list for tab completion.
> HAL may be doing something slightly different from what I describe; they have concrete experience.
> It may be possible for the API exposed by core-service=capability-registry to be enhanced to make this easier. If you want something, please don't hesitate to ask Tomaz Cerar or myself.
> [1] https://docs.jboss.org/author/display/WFLY/Working+with+WildFly+Capabilities
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFCORE-1619) Bad artifact resolution in wildfly-logging module
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1619?page=com.atlassian.jira.plugi... ]
Tomaz Cerar closed WFCORE-1619.
-------------------------------
Fix Version/s: 3.0.0.Alpha8
Resolution: Out of Date
I cannot reproduce this. If you can reproduce it with recent code, please reopen it.
> Bad artifact resolution in wildfly-logging module
> -------------------------------------------------
>
> Key: WFCORE-1619
> URL: https://issues.jboss.org/browse/WFCORE-1619
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging, Test Suite
> Reporter: Carlo de Wolf
> Assignee: Tomaz Cerar
> Priority: Minor
> Fix For: 3.0.0.Alpha8
>
>
> The test doesn't use project artifact resolution, but global artifact resolution. While the project hasn't been published yet.
> {noformat}
> Tests run: 14, Failures: 0, Errors: 6, Skipped: 3, Time elapsed: 21.024 sec <<< FAILURE! - in org.jboss.as.logging.LoggingSubsystemTestCase
> testTransformersEAP620(org.jboss.as.logging.LoggingSubsystemTestCase) Time elapsed: 8.508 sec <<< ERROR!
> java.lang.RuntimeException: org.eclipse.aether.resolution.ArtifactResolutionException: Could not find artifact org.wildfly.core:wildfly-subsystem-test-framework:jar:2.1.6.Final-redhat-SNAPSHOT in product-repository (https://maven.repository.redhat.com/nexus/content/groups/product-techprev...)
> at org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:39)
> at org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:355)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67)
> at org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:581)
> at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:249)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:520)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:421)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:246)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:223)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:294)
> at org.jboss.as.model.test.MavenUtil.createMavenGavURL(MavenUtil.java:138)
> at org.jboss.as.model.test.ChildFirstClassLoaderBuilder.addMavenResourceURL(ChildFirstClassLoaderBuilder.java:197)
> at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.install(SubsystemTestDelegate.java:839)
> at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.access$700(SubsystemTestDelegate.java:724)
> at org.jboss.as.subsystem.test.SubsystemTestDelegate$KernelServicesBuilderImpl.build(SubsystemTestDelegate.java:691)
> at org.jboss.as.logging.LoggingSubsystemTestCase.testEapTransformer(LoggingSubsystemTestCase.java:281)
> at org.jboss.as.logging.LoggingSubsystemTestCase.testTransformersEAP620(LoggingSubsystemTestCase.java:130)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7208) Integration with transactions during the graceful shutdown
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/WFLY-7208?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated WFLY-7208:
----------------------------------
Description: During the graceful shutdown Web Services subsystem should consult XTS subsystem whether the requests should be rejected or not. Transaction subsystem would check for availability of WS-AT or WS-BA transaction and return the outcome. (was: During the graceful shutdown EJB subsystem should consult Transactions subsystem whether the requests should be rejected or not. Transaction subsystem would check for availability of JTA or JTS transaction and return the outcome.)
> Integration with transactions during the graceful shutdown
> ----------------------------------------------------------
>
> Key: WFLY-7208
> URL: https://issues.jboss.org/browse/WFLY-7208
> Project: WildFly
> Issue Type: Feature Request
> Components: Web Services
> Reporter: Gytis Trikleris
> Priority: Critical
> Fix For: 11.0.0.Alpha1
>
>
> During the graceful shutdown Web Services subsystem should consult XTS subsystem whether the requests should be rejected or not. Transaction subsystem would check for availability of WS-AT or WS-BA transaction and return the outcome.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7208) Integration with transactions during the graceful shutdown
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/WFLY-7208?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris commented on WFLY-7208:
---------------------------------------
Relevant transactions JIRA issue hasn't reached the design phase, so there is no possible SPI interface. However, because of the issue being critical and time for release running shorter, I'm raising this issue now in case you need to do any analysis in your part.
> Integration with transactions during the graceful shutdown
> ----------------------------------------------------------
>
> Key: WFLY-7208
> URL: https://issues.jboss.org/browse/WFLY-7208
> Project: WildFly
> Issue Type: Feature Request
> Components: Web Services
> Reporter: Gytis Trikleris
> Priority: Critical
> Fix For: 11.0.0.Alpha1
>
>
> During the graceful shutdown Web Services subsystem should consult XTS subsystem whether the requests should be rejected or not. Transaction subsystem would check for availability of WS-AT or WS-BA transaction and return the outcome.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7208) Integration with transactions during the graceful shutdown
by Gytis Trikleris (JIRA)
Gytis Trikleris created WFLY-7208:
-------------------------------------
Summary: Integration with transactions during the graceful shutdown
Key: WFLY-7208
URL: https://issues.jboss.org/browse/WFLY-7208
Project: WildFly
Issue Type: Feature Request
Components: EJB
Reporter: Gytis Trikleris
Priority: Critical
Fix For: 11.0.0.Alpha1
During the graceful shutdown EJB subsystem should consult Transactions subsystem whether the requests should be rejected or not. Transaction subsystem would check for availability of JTA or JTS transaction and return the outcome.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months