[JBoss JIRA] (WFLY-12558) Intermittent failures in TCPSyslogAuditLogTestCase
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-12558?page=com.atlassian.jira.plugin... ]
James Perkins commented on WFLY-12558:
--------------------------------------
My guess is the test syslog server has not been started by the time the message is sent. I've personally never really liked any of these syslog tests, but there are quite a few now. Others seem to occasionally fail as well. I do wonder if we should invest some time and write our own mock syslog server.
Anyway for the fix I'm not sure setting the reconnect attempts would work. Failed messages aren't re-logged so it would likely take a loop of some sort until the message is found.
> Intermittent failures in TCPSyslogAuditLogTestCase
> --------------------------------------------------
>
> Key: WFLY-12558
> URL: https://issues.jboss.org/browse/WFLY-12558
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Brian Stansberry
> Assignee: Darran Lofthouse
> Priority: Major
>
> 5 tests in TCPSyslogAuditLogTestCase are frequently failing since late August:
> https://ci.wildfly.org/project.html?projectId=WF_PullRequest&buildTypeId=...
> Initial failure has this in the server log:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("syslog-audit-log" => "TCPSyslogAuditLogTestCase")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.security-event-listener.TCPSyslogAuditLogTestCase" => "WFLYELY00004: Unable to start the service.
> Caused by: java.io.IOException: ELY12001: The maximum reconnect attempts value of 0 was reached. The syslog endpoint will be shutdown."}}
> {code}
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 10 months
[JBoss JIRA] (WFLY-6892) Access logging for EJBs
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-6892?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-6892:
-----------------------------------
Fix Version/s: 19.0.0.Beta1
(was: 18.0.0.Final)
> Access logging for EJBs
> -----------------------
>
> Key: WFLY-6892
> URL: https://issues.jboss.org/browse/WFLY-6892
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Affects Versions: 10.0.0.Final
> Reporter: Brad Maxwell
> Assignee: Cheng Fang
> Priority: Major
> Labels: affects-model, affects_elytron
> Fix For: 19.0.0.Beta1
>
>
> Access logging for EJB requests similar to Web access logging would be very useful.
> Possibly something like:
> {code}
> [date-time] [host/IP of caller] [EJB Name] [EJB Method] [invocation id] Request Received ...
> [date-time] [host/IP of caller] [EJB Name] [EJB Method] invocation id] Starting Invocation ...
> [date-time] [host/IP of caller] [EJB Name] [EJB Method] invocation id] Finished Invocation ...
> {code}
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 10 months
[JBoss JIRA] (WFLY-8136) Allow JAX-RS annotations in CDI @Stereotype
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-8136?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-8136:
-----------------------------------
Fix Version/s: 19.0.0.Beta1
(was: 18.0.0.Final)
> Allow JAX-RS annotations in CDI @Stereotype
> -------------------------------------------
>
> Key: WFLY-8136
> URL: https://issues.jboss.org/browse/WFLY-8136
> Project: WildFly
> Issue Type: Feature Request
> Components: CDI / Weld, REST
> Affects Versions: 9.0.1.Final, 15.0.0.Final
> Environment: Windows 7, JDK 1.8.0_60
> Reporter: Andreas Klemp
> Assignee: Martin Stefanko
> Priority: Major
> Fix For: 19.0.0.Beta1
>
>
> A simple JAX-RS REST service can be annotated with @Produces to define the resulting mime-type. However, it is not working anymore, when the annotation is moved to a stereotype. The default application/octet-stream is used.
> {code}
> @Stereotype
> @Produces(MediaType.APPLICATION_JSON)
> @Target(ElementType.TYPE)
> @Retention(RetentionPolicy.RUNTIME)
> public @interface RestService {
> }
> @Path("/some")
> @RestService
> public class SomeRestService {
> @GET
> @Path("/")
> public Response getSome() {
> return Response.ok().entity("{\"x\" : 42, \"y\" : \"foo\"}").build();
> }
> }
> {code}
> Using the following dependencies in Gradle project.
> {noformat}
> providedCompile(
> [group: 'javax.enterprise', name: 'cdi-api', version: '1.2'],
> [group: 'org.jboss.spec.javax.ws.rs', name: 'jboss-jaxrs-api_2.0_spec', version: '1.0.0.Final'],
> [group: 'com.fasterxml.jackson.core', name: 'jackson-databind', version: '2.7.4']
> )
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 10 months
[JBoss JIRA] (WFLY-11214) Periodic recovery does not recover XAResource after jvm crash when agroal subsystem is used
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11214?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-11214:
------------------------------------
Fix Version/s: (was: 18.0.0.Final)
> Periodic recovery does not recover XAResource after jvm crash when agroal subsystem is used
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-11214
> URL: https://issues.jboss.org/browse/WFLY-11214
> Project: WildFly
> Issue Type: Bug
> Components: Agroal, Transactions
> Reporter: Ivan Straka
> Assignee: Luis Barreiro
> Priority: Critical
> Attachments: JPACrashRecoveryTestCase_commitHaltSecond_jta_server.log, JPACrashRecoveryTestCase_commitHaltSecond_jts_server.log
>
>
> Scenario:
> Halts server at commit phase ...
> # enlist TestXA resource
> # enlist XA resource
> # prepare TestXA resource
> # prepare XA resource
> # commit Test XA resource
> # JVM crash
> # recovery started
> # commit XA resource
> Periodic recovery does not recover xa resource. It looks like agroal subsystem does not register xa resource to xa recovery module.
> Test outcome:
> {code:java}
> Running org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 109.002 sec <<< FAILURE! - in org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase
> commitHaltSecond(org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase) Time elapsed: 102.976 sec <<< FAILURE!
> java.lang.AssertionError: Incorrect data in database after crash recovery. expected:<2> but was:<1>
> 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.jbossts.crashrec.test.JPABaseCrashRecoveryTestCase.checkAfterTestExecution(JPABaseCrashRecoveryTestCase.java:150)
> at org.jboss.as.test.jbossts.crashrec.test.TestBaseCrashRecovery.commitHaltTest(TestBaseCrashRecovery.java:485)
> at org.jboss.as.test.jbossts.crashrec.test.TestBaseCrashRecovery.commitHaltSecond(TestBaseCrashRecovery.java:418)
> at org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase.commitHaltSecond(JPACrashRecoveryTestCase.java:76)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 10 months
[JBoss JIRA] (WFLY-11943) Statistics of REST endpoints
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11943?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-11943:
------------------------------------
Fix Version/s: 19.0.0.Beta1
(was: 18.0.0.Final)
> Statistics of REST endpoints
> ----------------------------
>
> Key: WFLY-11943
> URL: https://issues.jboss.org/browse/WFLY-11943
> Project: WildFly
> Issue Type: Feature Request
> Components: REST
> Affects Versions: 17.0.0.Final
> Reporter: r searls
> Assignee: r searls
> Priority: Major
> Labels: affects-model
> Fix For: 19.0.0.Beta1
>
>
> Provide statistics on REST endpoints in the jaxrs subsystem.
> CLI support "read-resource" operation for jax-rs subsystem in deployment:
> /deployment=jaxrs-eap.war/subsystem=jaxrs:read-resource
> Statistics should be added to results of this operation in this RFE.
> There needs to be option to enable or disable collecting of these statistics, because collecting of statistics does probably some performance drop.
> The change of statistic settings should not require server reload or restart.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 10 months