[JBoss JIRA] (WFCORE-4240) CLI, failed interactive enable-ssl commands put the server in reload state
by Jean-Francois Denise (Jira)
Jean-Francois Denise created WFCORE-4240:
--------------------------------------------
Summary: CLI, failed interactive enable-ssl commands put the server in reload state
Key: WFCORE-4240
URL: https://issues.jboss.org/browse/WFCORE-4240
Project: WildFly Core
Issue Type: Bug
Components: CLI
Reporter: Jean-Francois Denise
Assignee: Jean-Francois Denise
In case of not complete config (eg: no management-https, no https-listener), the interactive session will abort. Due to WFCORE-3491 we have some logic to cleanup keystore that would have been created prior a failure occurs.
This removal of the keystore puts the server in reload-state so should be reloaded by the command.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (WFLY-11440) Remove deprecated org.jboss.as.ejb3.component.EJBUtilities class
by Richard Opalka (Jira)
Richard Opalka created WFLY-11440:
-------------------------------------
Summary: Remove deprecated org.jboss.as.ejb3.component.EJBUtilities class
Key: WFLY-11440
URL: https://issues.jboss.org/browse/WFLY-11440
Project: WildFly
Issue Type: Enhancement
Components: EJB
Reporter: Richard Opalka
Assignee: Richard Opalka
Fix For: 15.0.0.CR1
EJBUtilities class have been deprecated long time ago.
It is the only class that implements org.jboss.as.ejb3.inflow.EndpointDeployer interface
and the only class that uses BasicComponentCreateService.deploymentUnit injection.
Once this class is eliminated we can remove deploymentUnit injector
and decrease number of graph dependencies being created when deploying EE apps.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (ELY-1648) FIPS NoSuchAlgorithmException: JKS KeyStore not available when trustmanager SunX509
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/ELY-1648?page=com.atlassian.jira.plugin.s... ]
Martin Choma commented on ELY-1648:
-----------------------------------
CustomCLIExecutor is test utility which wraps cli calls. That's why it occures in logs. But with repdorucer it should be reproducible also without CustomCLIExecutor.
> FIPS NoSuchAlgorithmException: JKS KeyStore not available when trustmanager SunX509
> -----------------------------------------------------------------------------------
>
> Key: ELY-1648
> URL: https://issues.jboss.org/browse/ELY-1648
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Affects Versions: 1.5.5.Final
> Reporter: Martin Choma
> Assignee: Justin Cook
> Priority: Major
> Attachments: java.security, wildfly-config.xml
>
>
> With SunX509 truststore algorithm I can succesfully connect with CLI.
> {code}
> <configuration>
> <authentication-client xmlns="urn:elytron:client:1.1">
> <key-stores>
> <key-store name="truststore" type="PKCS11">
> <key-store-clear-password password="${password}" />
> </key-store>
> </key-stores>
> <ssl-contexts>
> <ssl-context name="client-cli-context">
> <trust-manager algorithm="SunX509" />
> <trust-store key-store-name="truststore" />
> <cipher-suite selector="${cipher.suite.filter}" />
> <protocol names="${protocol}" />
> </ssl-context>
> </ssl-contexts>
> <ssl-context-rules>
> <rule use-ssl-context="client-cli-context" />
> </ssl-context-rules>
> </authentication-client>
> </configuration>
> {code}
> But there is a exception in log
> {code}
> 13:58:27,652 INFO [com.redhat.eap.qe.cli.CustomCLIExecutor] (main) java.security.KeyStoreException: JKS not found
> at java.security.KeyStore.getInstance(KeyStore.java:851)
> at sun.security.util.AnchorCertificates$1.run(AnchorCertificates.java:59)
> at sun.security.util.AnchorCertificates$1.run(AnchorCertificates.java:52)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.security.util.AnchorCertificates.<clinit>(AnchorCertificates.java:52)
> at sun.security.provider.certpath.AlgorithmChecker.checkFingerprint(AlgorithmChecker.java:214)
> at sun.security.provider.certpath.AlgorithmChecker.<init>(AlgorithmChecker.java:164)
> at sun.security.provider.certpath.AlgorithmChecker.<init>(AlgorithmChecker.java:118)
> at sun.security.validator.SimpleValidator.engineValidate(SimpleValidator.java:157)
> at sun.security.validator.Validator.validate(Validator.java:260)
> at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
> at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:281)
> at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:136)
> at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1601)
> at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052)
> at sun.security.ssl.Handshaker$1.run(Handshaker.java:992)
> at sun.security.ssl.Handshaker$1.run(Handshaker.java:989)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1467)
> at org.xnio.ssl.JsseSslConduitEngine.handleHandshake(JsseSslConduitEngine.java:543)
> at org.xnio.ssl.JsseSslConduitEngine.wrap(JsseSslConduitEngine.java:314)
> at org.xnio.ssl.JsseSslConduitEngine.wrap(JsseSslConduitEngine.java:204)
> at org.xnio.ssl.JsseSslStreamSinkConduit.write(JsseSslStreamSinkConduit.java:98)
> at org.xnio.ssl.JsseSslStreamSinkConduit.write(JsseSslStreamSinkConduit.java:72)
> at org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:385)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:372)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:94)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> Caused by: java.security.NoSuchAlgorithmException: JKS KeyStore not available
> at sun.security.jca.GetInstance.getInstance(GetInstance.java:159)
> at java.security.Security.getImpl(Security.java:695)
> at java.security.KeyStore.getInstance(KeyStore.java:848)
> ... 31 more
> {code}
> When I change SunX509 to PKIX exception does not occure anymore.
> Seems exception is thrown by code https://github.com/JetBrains/jdk8u_jdk/blob/master/src/share/classes/sun/...
> AnchorCertificates hardcodes JKS keystore creation. Apparently using PKIX it is avoided.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (ELY-1648) FIPS NoSuchAlgorithmException: JKS KeyStore not available when trustmanager SunX509
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/ELY-1648?page=com.atlassian.jira.plugin.s... ]
Martin Choma updated ELY-1648:
------------------------------
Attachment: wildfly-config.xml
> FIPS NoSuchAlgorithmException: JKS KeyStore not available when trustmanager SunX509
> -----------------------------------------------------------------------------------
>
> Key: ELY-1648
> URL: https://issues.jboss.org/browse/ELY-1648
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Affects Versions: 1.5.5.Final
> Reporter: Martin Choma
> Assignee: Justin Cook
> Priority: Major
> Attachments: java.security, wildfly-config.xml
>
>
> With SunX509 truststore algorithm I can succesfully connect with CLI.
> {code}
> <configuration>
> <authentication-client xmlns="urn:elytron:client:1.1">
> <key-stores>
> <key-store name="truststore" type="PKCS11">
> <key-store-clear-password password="${password}" />
> </key-store>
> </key-stores>
> <ssl-contexts>
> <ssl-context name="client-cli-context">
> <trust-manager algorithm="SunX509" />
> <trust-store key-store-name="truststore" />
> <cipher-suite selector="${cipher.suite.filter}" />
> <protocol names="${protocol}" />
> </ssl-context>
> </ssl-contexts>
> <ssl-context-rules>
> <rule use-ssl-context="client-cli-context" />
> </ssl-context-rules>
> </authentication-client>
> </configuration>
> {code}
> But there is a exception in log
> {code}
> 13:58:27,652 INFO [com.redhat.eap.qe.cli.CustomCLIExecutor] (main) java.security.KeyStoreException: JKS not found
> at java.security.KeyStore.getInstance(KeyStore.java:851)
> at sun.security.util.AnchorCertificates$1.run(AnchorCertificates.java:59)
> at sun.security.util.AnchorCertificates$1.run(AnchorCertificates.java:52)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.security.util.AnchorCertificates.<clinit>(AnchorCertificates.java:52)
> at sun.security.provider.certpath.AlgorithmChecker.checkFingerprint(AlgorithmChecker.java:214)
> at sun.security.provider.certpath.AlgorithmChecker.<init>(AlgorithmChecker.java:164)
> at sun.security.provider.certpath.AlgorithmChecker.<init>(AlgorithmChecker.java:118)
> at sun.security.validator.SimpleValidator.engineValidate(SimpleValidator.java:157)
> at sun.security.validator.Validator.validate(Validator.java:260)
> at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
> at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:281)
> at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:136)
> at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1601)
> at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052)
> at sun.security.ssl.Handshaker$1.run(Handshaker.java:992)
> at sun.security.ssl.Handshaker$1.run(Handshaker.java:989)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1467)
> at org.xnio.ssl.JsseSslConduitEngine.handleHandshake(JsseSslConduitEngine.java:543)
> at org.xnio.ssl.JsseSslConduitEngine.wrap(JsseSslConduitEngine.java:314)
> at org.xnio.ssl.JsseSslConduitEngine.wrap(JsseSslConduitEngine.java:204)
> at org.xnio.ssl.JsseSslStreamSinkConduit.write(JsseSslStreamSinkConduit.java:98)
> at org.xnio.ssl.JsseSslStreamSinkConduit.write(JsseSslStreamSinkConduit.java:72)
> at org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:385)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:372)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:94)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> Caused by: java.security.NoSuchAlgorithmException: JKS KeyStore not available
> at sun.security.jca.GetInstance.getInstance(GetInstance.java:159)
> at java.security.Security.getImpl(Security.java:695)
> at java.security.KeyStore.getInstance(KeyStore.java:848)
> ... 31 more
> {code}
> When I change SunX509 to PKIX exception does not occure anymore.
> Seems exception is thrown by code https://github.com/JetBrains/jdk8u_jdk/blob/master/src/share/classes/sun/...
> AnchorCertificates hardcodes JKS keystore creation. Apparently using PKIX it is avoided.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (DROOLS-3386) [DMN Designer] Font settings available from Boxed Expression editor
by Jozef Marko (Jira)
Jozef Marko created DROOLS-3386:
-----------------------------------
Summary: [DMN Designer] Font settings available from Boxed Expression editor
Key: DROOLS-3386
URL: https://issues.jboss.org/browse/DROOLS-3386
Project: Drools
Issue Type: Bug
Components: DMN Editor
Affects Versions: 7.15.0.Final
Reporter: Jozef Marko
Assignee: Michael Anstis
The font settings are available in the properties panel when Boxed Expression editor is opened, however changed values are not reflected into DRD diagram neither boxed expression grid.
One of solution in top of my head is not to show those font settings when boxed expression editor is opened.
Spotted during DROOLS-3351 review, however I think it is not related.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years