[JBoss JIRA] (WFLY-8983) ReplicatedJournal class - disabled trace logging
by Romain Pelisse (JIRA)
Romain Pelisse created WFLY-8983:
------------------------------------
Summary: ReplicatedJournal class - disabled trace logging
Key: WFLY-8983
URL: https://issues.jboss.org/browse/WFLY-8983
Project: WildFly
Issue Type: Bug
Components: JMS
Reporter: Romain Pelisse
Assignee: Romain Pelisse
Priority: Minor
There is disabled logging of {{ReplicatedJournal}} due to hardcoded value:
{code}
private static final boolean trace = false;
{code}
Every trace log can never be logged:
{code}
if (ReplicatedJournal.trace) {
ReplicatedJournal.trace("Append record id = " + id + " recordType = " + recordType);
}
{code}
This is not ideal for investivatigation purposes.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2997) Intermittent failures in JmxAuditLogFieldsOfLogTestCase
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2997?page=com.atlassian.jira.plugi... ]
Kabir Khan reassigned WFCORE-2997:
----------------------------------
Assignee: Kabir Khan
> Intermittent failures in JmxAuditLogFieldsOfLogTestCase
> -------------------------------------------------------
>
> Key: WFCORE-2997
> URL: https://issues.jboss.org/browse/WFCORE-2997
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Kabir Khan
> Assignee: Kabir Khan
>
> This test fails due to an extra entry now and again for calls to unregisterMBean for ObjectNames of the type "jboss.modules:type=ModuleLoader,name=ServiceModuleLoader-nnn".
> {code}
> java.lang.AssertionError: [{ "type" => "jmx", "r/o" => false, "booting" => false, "version" => "3.0.0.Beta27-SNAPSHOT", "user" => "anonymous", "domainUUID" => undefined, "access" => undefined, "remote-address" => undefined, "method" => "unregisterMBean", "sig" => ["javax.management.ObjectName"], "params" => ["jboss.modules:type=ModuleLoader,name=ServiceModuleLoader-3"]}, { "type" => "jmx", "r/o" => true, "booting" => false, "version" => "3.0.0.Beta27-SNAPSHOT", "user" => "IAmAdmin", "domainUUID" => undefined, "access" => "JMX", "remote-address" => "/0:0:0:0:0:0:0:1", "method" => "queryMBeans", "sig" => [ "javax.management.ObjectName", "javax.management.QueryExp" ], "params" => [ "java.lang:*", undefined ]}] expected:<1> but was:<2> at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:834) at org.junit.Assert.assertEquals(Assert.java:645) at org.jboss.as.test.manualmode.auditlog.AbstractLogFieldsOfLogTestCase.readFile(AbstractLogFieldsOfLogTestCase.java:144) at org.jboss.as.test.manualmode.auditlog.JmxAuditLogFieldsOfLogTestCase.testJmxAuditLoggingFields(JmxAuditLogFieldsOfLogTestCase.java:60)
> {code}
> When the ServiceLoaders are created, these XMBeans are registered and hold a WeakReference to the ServiceLoader, The WeakReference has a reference queue which triggers a Reaper in ModuleLoader. This Reaper is then run when the weak reference is cleared, and results in the call to unregister the mbean which is then logged in the audit log.
> When this happens in not-deterministic and can happen at any time, so the test should strip out these .
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2997) Intermittent failures in JmxAuditLogFieldsOfLogTestCase
by Kabir Khan (JIRA)
Kabir Khan created WFCORE-2997:
----------------------------------
Summary: Intermittent failures in JmxAuditLogFieldsOfLogTestCase
Key: WFCORE-2997
URL: https://issues.jboss.org/browse/WFCORE-2997
Project: WildFly Core
Issue Type: Bug
Reporter: Kabir Khan
This test fails due to an extra entry now and again for calls to unregisterMBean for ObjectNames of the type "jboss.modules:type=ModuleLoader,name=ServiceModuleLoader-nnn".
{code}
java.lang.AssertionError: [{ "type" => "jmx", "r/o" => false, "booting" => false, "version" => "3.0.0.Beta27-SNAPSHOT", "user" => "anonymous", "domainUUID" => undefined, "access" => undefined, "remote-address" => undefined, "method" => "unregisterMBean", "sig" => ["javax.management.ObjectName"], "params" => ["jboss.modules:type=ModuleLoader,name=ServiceModuleLoader-3"]}, { "type" => "jmx", "r/o" => true, "booting" => false, "version" => "3.0.0.Beta27-SNAPSHOT", "user" => "IAmAdmin", "domainUUID" => undefined, "access" => "JMX", "remote-address" => "/0:0:0:0:0:0:0:1", "method" => "queryMBeans", "sig" => [ "javax.management.ObjectName", "javax.management.QueryExp" ], "params" => [ "java.lang:*", undefined ]}] expected:<1> but was:<2> at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:834) at org.junit.Assert.assertEquals(Assert.java:645) at org.jboss.as.test.manualmode.auditlog.AbstractLogFieldsOfLogTestCase.readFile(AbstractLogFieldsOfLogTestCase.java:144) at org.jboss.as.test.manualmode.auditlog.JmxAuditLogFieldsOfLogTestCase.testJmxAuditLoggingFields(JmxAuditLogFieldsOfLogTestCase.java:60)
{code}
When the ServiceLoaders are created, these XMBeans are registered and hold a WeakReference to the ServiceLoader, The WeakReference has a reference queue which triggers a Reaper in ModuleLoader. This Reaper is then run when the weak reference is cleared, and results in the call to unregister the mbean which is then logged in the audit log.
When this happens in not-deterministic and can happen at any time, so the test should strip out these .
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8488) Usage of JGroups JDBC_PING attempts to delete row too late
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-8488?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-8488:
--------------------------------------
[~meetoblivion] The stack trace you posted is a stack trace from mod_cluster, not jgroups, which is known harmless log noise on macOS (tracked as MODCLUSTER-460). I will reject the issue now, you can reopen if you manage to reproduce the issue.
> Usage of JGroups JDBC_PING attempts to delete row too late
> ----------------------------------------------------------
>
> Key: WFLY-8488
> URL: https://issues.jboss.org/browse/WFLY-8488
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Reporter: John Ament
> Assignee: Paul Ferraro
>
> I was recently working on spinning up a Keycloak cluster. We're deployed to AWS, can't leverage UDP and wanted to have a discovery mechanism that was easy to use, so tried out JDBC_PING. While I got the cluster running, when shutting down a node I would receive an exception on the console when attempting to remove the node from the cluster. It attempts to do a delete on the row in the database after the DataSource has been shut down.
> In my setup, I'm pointing JGroups at the same DataSource as Keycloak, I'm not using the properties approach. I can switch to the properties approach, but I would prefer a single pool rather than multiple connections.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8488) Usage of JGroups JDBC_PING attempts to delete row too late
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-8488?page=com.atlassian.jira.plugin.... ]
Radoslav Husar closed WFLY-8488.
--------------------------------
Resolution: Rejected
> Usage of JGroups JDBC_PING attempts to delete row too late
> ----------------------------------------------------------
>
> Key: WFLY-8488
> URL: https://issues.jboss.org/browse/WFLY-8488
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Reporter: John Ament
> Assignee: Paul Ferraro
>
> I was recently working on spinning up a Keycloak cluster. We're deployed to AWS, can't leverage UDP and wanted to have a discovery mechanism that was easy to use, so tried out JDBC_PING. While I got the cluster running, when shutting down a node I would receive an exception on the console when attempting to remove the node from the cluster. It attempts to do a delete on the row in the database after the DataSource has been shut down.
> In my setup, I'm pointing JGroups at the same DataSource as Keycloak, I'm not using the properties approach. I can switch to the properties approach, but I would prefer a single pool rather than multiple connections.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ELY-1255) Elytron client configuration file throws ConfigXMLParseException when credential certificate is used
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1255?page=com.atlassian.jira.plugin.s... ]
Jan Kalina commented on ELY-1255:
---------------------------------
[~pcraveiro] Are you working on this one? If yes, please assign JBEAP-11695 too. (I has started working on it already, but still unsuccesful in fixing - no problem to reassign)
> Elytron client configuration file throws ConfigXMLParseException when credential certificate is used
> ----------------------------------------------------------------------------------------------------
>
> Key: ELY-1255
> URL: https://issues.jboss.org/browse/ELY-1255
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta52
> Reporter: Ondrej Lukas
> Assignee: Pedro Igor
> Priority: Blocker
>
> When Elytron client configuration file includes configuration.authentication-client.authentication-configurations.configuration.credentials.certificate element then ConfigXMLParseException is thrown during parsing of configuration file.
> For following configuration file:
> {code}
> <configuration>
> <authentication-client xmlns="urn:elytron:1.0">
> <authentication-rules>
> <rule use-configuration="default"/>
> </authentication-rules>
> <authentication-configurations>
> <configuration name="default">
> <sasl-mechanism-selector selector="PLAIN"/>
> <credentials>
> <certificate>
> <private-key-pem>
> -----BEGIN ENCRYPTED PRIVATE KEY-----
> MIIFDjBABgkqhkiG9w0BBQ0wMzAbBgkqhkiG9w0BBQwwDgQI/UbK4uSM+lICAggA
> MBQGCCqGSIb3DQMHBAjqSiGAFsiVUwSCBMg1UIOetO6ZNmBehx3pzNVqefIYE6wc
> 5roz1Yz0ZLroq9zFn8kGGe65XlZRD8jO7+pYgglHwII0s05P2YPRx8boHgNvf/de
> cYmPXOuT2W7obUQTRlM0TzJpjP+74cwmxeM0L/mvhRlQKgkHyFzIj3f0lJxlrCS5
> FiN8xM7YuDZ+nZwSil6pF+bCO/V/TAEsuR15eG2UHZuMeFgL9xez7ZPJPKDyeXIo
> deMz2sv63keJ6nIEAxq46+m53HKFcOs3kCCa/M2LQg0uxxA3YyjLiVu8U0k/ox7L
> rQ3XVBA11oBSUM9+vFl9CMW/7do/5niL3JNrz+e1FpG6ViG2MT+3+na7YfN+7ffp
> FUSblMFR9Px00uBfqVHufCzKotNX0VqbEGGCE40i1Tpq5ZWCob4R6/42zW+BctJO
> ZxUeiJJaXAoccvJiZRraicte6OpDMWZXPIKMR+FIc1YXuWYv3BHHhfZKhLm8tuxb
> eSNE8vRR/exfV1z+YoZ0nvwOhpBOK7yQl9iqOy+eQ7e7h85yv15XFX2cOjPgY4bO
> M3wN6H41K5eUock6UYaKLY2qzVlyI0rwV1aYnnrGeA5gHkfAFdPNpxm7+ejUAi2z
> am117gT3NXKCLq0SsV55wjonAcN9ghN8X46tWZIO0chlNpVOHZSUz/NtavOrmZwZ
> UcFajPKvoT3V7t8hGD1Tg1AdChahlIjT5dzDQBaHtJLbz7qPljHuAvvZR/bapTdW
> 97zMxp3zRQbyHqPmu6BFUASgXHnKLY6Cu1a0w+AhVaemWLLVeHMweWlLsLAHxSo4
> qkqIkn8rMr9V92/nVaE6fEnmplnWTI3VY3t0vzI5gztwq7Q0ChlAttgG+BMpYOps
> 4H7dO55iz7hZFdYrZlEXBON6VTfQFhnUPuuJHHBRK1E/GEvoA6whRV7bLSrgvtEW
> 6AgFLgb8FWt9mWvf15PAptcvN/AxHGM2ymPyXqh32a+rvfPjdPgFIaCtEQmuGyoV
> NpEwg+iV7TAnEzQ1u0BcOPKr+dKKrkGzahT1Mj1ZFLG0M2J60Hv4oItMXMwvb7vq
> nnubuLwkI8dWdVgmNXIU415i546VoeRuMXY2F7hLEHUKAahcDy5PnmrEj34IVW0w
> qodBW+MeykUA9O+WndUoLI5bTnsGXNS/vZ17LwwcaGyrj2M8bTkqCMvdx8HXGnJ2
> hNN+INazIbIq7FBcQZfEHH1uJsDKy5Niqk3uKysfByyPzehcY6QxseJgqztIRqLR
> HDeymrgOn5k8HRgA4ePKOQwQe2r2vY+3ExydvL7irHMgD7EaSnUIE8KK1Aq39mQz
> ZVWigJGII05HGk/vOQP4s804hjkyS8X+CNXpMzi/2bgmzKp4aPCS1yyx2m+8eP7B
> Qs5h9YxqUh24HC7EGNkx31M4OuL1h1CmkT7uk9uCOREuRnhxClLvTL1Pu8f8OjbN
> jd2W1c/X7spOsvBg7OMD8aBpxI7qWSSWwIe5dsbNbCCDeHkZpJ4GDqxtLLv4+tEO
> XozNTlPhyF0eURRzrVyEL8C5OaSGLEfo3kFCJdS7eQX2TyttILOV9plP4YaFUw91
> DOZj1vjPVgRJSAr98/UlzE23yGfB1gUG/kUG2+HPgu2jS5TE7Mlsk6Wy5Q+3Ga+b
> wD4=
> -----END ENCRYPTED PRIVATE KEY-----
> </private-key-pem>
> <pem>
> -----BEGIN CERTIFICATE-----
> MIIDWTCCAkGgAwIBAgIEQFuxgzANBgkqhkiG9w0BAQsFADBcMQswCQYDVQQGEwJD
> WjEXMBUGA1UEBxMOQ3plY2ggUmVwdWJsaWMxDzANBgNVBAsTBkVBUCBRRTEQMA4G
> A1UEChMHUmVkIEhhdDERMA8GA1UEAxMIY2xpZW50RG4wIBcNMTcwNjIwMDYxMzU5
> WhgPMjIxNzA1MDMwNjEzNTlaMFwxCzAJBgNVBAYTAkNaMRcwFQYDVQQHEw5DemVj
> aCBSZXB1YmxpYzEPMA0GA1UECxMGRUFQIFFFMRAwDgYDVQQKEwdSZWQgSGF0MREw
> DwYDVQQDEwhjbGllbnREbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
> AJsXwctr7ckEMiLtsyXaFiSaB03F5z5fVzyg89WMxqWMhfRPitDIFBGN8t3/fEML
> s5I3g1dlQDwtVl9AlwHDLfwxFdLZIuDodRr6KzcTrbavDSRczGMCF+ntPo6KBBL1
> /UZLUW5y332bi7Tkc87NYN9zJ+3307fHrxGmCyeF6as7s/+uKJ0gY4JVjS/9XXec
> K8gtlye/AbBZyJhpPiM71aoQy+LecYdSB/cRBQII0XGtsusguCFGnSSA80J79TLP
> THaJG0trarktvORvnmNQz45Atxhpr9shv4xkbNWHR+qAiFO9N1w7uVFZOZUWEb9/
> bQEFlSo0LtMPgLomKGvg8/0CAwEAAaMhMB8wHQYDVR0OBBYEFO01U/yTywCdzOUl
> hZmElDjVVcZXMA0GCSqGSIb3DQEBCwUAA4IBAQAEy+IphU7QjlWgn2kkKI6RAX6p
> LAWGUlbNnfw7V131of9qz9lctRnFWazbuych/i5/oCvBj+0gyf6+PvpsfB7qlZwH
> 3H+jMNNoCrMp5MutLe9SYcfmvYkYGym77K4e8BiuDlfw3whE4B274nD99Y+e9CcY
> FuUx3yepXY9FDo58mE05zLSXhn31uIulnUGbL1iDB1yeCFG/6J7z+AkCBPKzbgFX
> 3UZid9MUn45RDf8BlP6zG+px/cE2XlaZa+0LGSH9vvvVykD18cthsLHe71Q+Y2hC
> vWvHG8wdujBxWg7A+H38x48i0PR6lNTsjEgTZbUgYM/SQtKvX2gNaR3z2YPU
> -----END CERTIFICATE-----
> </pem>
> </certificate>
> </credentials>
> <providers>
> <use-service-loader/>
> </providers>
> </configuration>
> </authentication-configurations>
> </authentication-client>
> </configuration>
> {code}
> following exception is thrown:
> {code}
> org.wildfly.client.config.ConfigXMLParseException: parser must be on START_ELEMENT to read next text
> at file:/path/to/some/wildfly-config.xml:13:89
> at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.lambda$static$0(DefaultAuthenticationContextProvider.java:40)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.<clinit>(DefaultAuthenticationContextProvider.java:36)
> ... 16 more
> Caused by: org.wildfly.client.config.ConfigXMLParseException: parser must be on START_ELEMENT to read next text
> at file:/path/to/some/wildfly-config.xml:13:89
> at com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.getElementText(XMLStreamReaderImpl.java:835)
> at org.wildfly.client.config.BasicXMLStreamReader.getElementText(BasicXMLStreamReader.java:87)
> at org.wildfly.client.config.AbstractDelegatingXMLStreamReader.getElementText(AbstractDelegatingXMLStreamReader.java:80)
> at org.wildfly.client.config.AbstractDelegatingXMLStreamReader.getElementText(AbstractDelegatingXMLStreamReader.java:80)
> at org.wildfly.security.auth.client.ElytronXmlParser.parsePem(ElytronXmlParser.java:1169)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseCertificateType(ElytronXmlParser.java:1116)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseCredentialsType(ElytronXmlParser.java:961)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationConfigurationType(ElytronXmlParser.java:714)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationConfigurationsType(ElytronXmlParser.java:341)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:273)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:185)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:146)
> at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.lambda$static$0(DefaultAuthenticationContextProvider.java:38)
> ... 18 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8731) Unable to inject EJBs into web resources
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-8731?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-8731:
--------------------------------------
If you still think this is a problem then you are going to have to provide a better reproducer, i.e. one that:
- Can be deployed on a clean Wildfly instance with no modification required
- Contains instructions on exactly the steps to take to reproduce the bug
> Unable to inject EJBs into web resources
> ----------------------------------------
>
> Key: WFLY-8731
> URL: https://issues.jboss.org/browse/WFLY-8731
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EJB, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Environment: WildFly 10.0 on Windows 10
> Reporter: Archimedes Trajano
> Assignee: Stuart Douglas
>
> There's an old bug on https://issues.jboss.org/browse/JBAS-8818 that talks about this issue on JBoss, but it still applies on WildFly up until now.
> Their comment was based on just WebListener, but I found it applied to the following as well
> * WebServlet
> * WebService (code first and contract first)
> * JAX-RS paths.
> One other thing to note, converting to @EJB from @Inject created another problem, but I'd rather get @Inject working first.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8731) Unable to inject EJBs into web resources
by Archimedes Trajano (JIRA)
[ https://issues.jboss.org/browse/WFLY-8731?page=com.atlassian.jira.plugin.... ]
Archimedes Trajano resolved WFLY-8731.
--------------------------------------
Resolution: Done
Ok I'll presume that this is resolved for now based on your last comment. However, you had changed the scenario on mine in that you've removed authentication and used a different data source.
> Unable to inject EJBs into web resources
> ----------------------------------------
>
> Key: WFLY-8731
> URL: https://issues.jboss.org/browse/WFLY-8731
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EJB, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Environment: WildFly 10.0 on Windows 10
> Reporter: Archimedes Trajano
> Assignee: Stuart Douglas
>
> There's an old bug on https://issues.jboss.org/browse/JBAS-8818 that talks about this issue on JBoss, but it still applies on WildFly up until now.
> Their comment was based on just WebListener, but I found it applied to the following as well
> * WebServlet
> * WebService (code first and contract first)
> * JAX-RS paths.
> One other thing to note, converting to @EJB from @Inject created another problem, but I'd rather get @Inject working first.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years