[JBoss JIRA] (ELY-1862) Fix infinite loop in SecurityEventVisitor#handleSyslogAuditEvent
by Farah Juma (Jira)
Farah Juma created ELY-1862:
-------------------------------
Summary: Fix infinite loop in SecurityEventVisitor#handleSyslogAuditEvent
Key: ELY-1862
URL: https://issues.jboss.org/browse/ELY-1862
Project: WildFly Elytron
Issue Type: Bug
Reporter: Farah Juma
Assignee: Farah Juma
Fix For: 1.10.0.CR6
Found during QE's coverity scan:
{code}
*** CID 1485949: SpotBugs: Correctness (FB.IL_INFINITE_RECURSIVE_LOOP)
/auth/server/base/src/main/java/org/wildfly/security/auth/server/event/SecurityEventVisitor.java:
129 in org.wildfly.security.auth.server.event.SecurityEventVisitor.handleSyslogAuditEvent(org.wildfly.security.auth.server.event.SyslogAuditEvent,
java.lang.Object)()
123 *
124 * @param event the security event
125 * @param param the visitor parameter
126 * @return the visitor return value
127 */
128 public R handleSyslogAuditEvent(final SyslogAuditEvent
event, final P param) {
>>> CID 1485949: SpotBugs: Correctness (FB.IL_INFINITE_RECURSIVE_LOOP)
>>> There is an apparent infinite recursive loop.
129 return handleSyslogAuditEvent(event, param);
130 }
131
{code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFWIP-181) Access logging for EJBs: no logs produced
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFWIP-181?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFWIP-181:
-------------------------------------
Looking at the current branch only the subsystem parsing and model have been written. The actual logging doesn't look like it's been implemented.
> Access logging for EJBs: no logs produced
> -----------------------------------------
>
> Key: WFWIP-181
> URL: https://issues.jboss.org/browse/WFWIP-181
> Project: WildFly WIP
> Issue Type: Bug
> Components: Logging
> Reporter: Tommasso Borgato
> Assignee: James Perkins
> Priority: Blocker
>
> File {{standalone-full.xml}} can be configured via cli but it does not have the desired effect of producing logs;
> As specified in the RFE, the server is reloaded after changes;
> We verified that with the following:
> {noformat}
> <access-log>
> <file-handler name="file1" path="ejb-access.log" relative-to="jboss.server.log.dir">
> <formatter name="p1"/>
> </file-handler>
> <formatter>
> <pattern-formatter name="p1" pattern="date time ip client ejb method event server thread"/>
> </formatter>
> </access-log>
> {noformat}
> or
> {noformat}
> <access-log>
> <file-handler name="file1" path="ejb-access.log" relative-to="jboss.server.log.dir">
> <formatter name="p1"/>
> </file-handler>
> <formatter>
> <json-formatter name="p1" pattern="date time ip client ejb method event server thread"/>
> </formatter>
> </access-log>
> {noformat}
> : no file {{standalone/log/ejb-access.log}} is produced;
> {noformat}
> <access-log>
> <server-log-handler name="server1">
> <formatter name="p1"/>
> </server-log-handler>
> <formatter>
> <pattern-formatter name="p1" pattern="date time ip client ejb method event server thread"/>
> </formatter>
> </access-log>
> {noformat}
> or
> {noformat}
> <access-log>
> <server-log-handler name="server1">
> <formatter name="p1"/>
> </server-log-handler>
> <formatter>
> <json-formatter name="p1" pattern="date time ip client ejb method event server thread"/>
> </formatter>
> </access-log>
> {noformat}
> : no logs in {{standalone/log/server.log}};
> {noformat}
> <access-log>
> <console-handler name="console1">
> <formatter name="p1"/>
> </console-handler>
> <formatter>
> <pattern-formatter name="p1" pattern="date time ip client ejb method event server thread"/>
> </formatter>
> </access-log>
> {noformat}
> : no logs in console;
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFLY-12063) ClassFormatError on JDK13
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-12063?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-12063:
-----------------------------------------
[~smarlow] [~gbadner]
Is there any benefit in a WF PR upgrading just Byte Buddy and not Hibernate? Or do we know Hibernate changes are required? I wouldn't want to *merge* such a PR, unless you say it's ok, but if we have it we can see how CI treats it, how JDK 13 treats it etc.
> ClassFormatError on JDK13
> -------------------------
>
> Key: WFLY-12063
> URL: https://issues.jboss.org/browse/WFLY-12063
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Reporter: Richard Opalka
> Assignee: Scott Marlow
> Priority: Critical
> Labels: blocker-WF18
> Attachments: server.log, test.log
>
>
> The following commit https://github.com/wildfly/wildfly/commit/b6d141b06404a4c23ead1d04d6e26fc... introduced JDK13 regression in WildFly.
> Affected tests are:
> ---
> [ERROR] Errors:
> [ERROR] MultiplePuTestCase.org.jboss.as.test.integration.jpa.basic.multiplepersistenceunittest.MultiplePuTestCase » Deployment
> [ERROR] EntityListenersTestCase.org.jboss.as.test.integration.jpa.entitylistener.EntityListenersTestCase » Deployment
> [ERROR] EPCPropagationTestCase.org.jboss.as.test.integration.jpa.epcpropagation.EPCPropagationTestCase » Deployment
> [ERROR] AuditJoinTableoverBidirectionalTest.org.jboss.as.test.integration.jpa.hibernate.envers.AuditJoinTableoverBidirectionalTest » Deployment
> [ERROR] AuditJoinTableoverOnetoManyJoinColumnTest.org.jboss.as.test.integration.jpa.hibernate.envers.AuditJoinTableoverOnetoManyJoinColumnTest » Deployment
> [ERROR] ManagementTestCase.getEntityInsertCountAttribute:98 » Deployment Cannot deploy...
> [ERROR] JPA2LCTestCase.org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase » Deployment
> [ERROR] JpaStatisticsTestCase.org.jboss.as.test.integration.jpa.secondlevelcache.JpaStatisticsTestCase » Deployment
> [ERROR] TransactionTestCase.org.jboss.as.test.integration.jpa.transaction.TransactionTestCase » Deployment
> [INFO]
> [ERROR] Tests run: 1553, Failures: 0, Errors: 9, Skipped: 14
> ---
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFLY-12429) MockitoException in InfinispanBeanTestCase on latest JDK13
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-12429?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-12429:
-----------------------------------------
[~ropalka] Can you apply some label to these JDK 13 issues so it's easy to query them? Thanks.
> MockitoException in InfinispanBeanTestCase on latest JDK13
> ----------------------------------------------------------
>
> Key: WFLY-12429
> URL: https://issues.jboss.org/browse/WFLY-12429
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: Richard Opalka
> Assignee: Paul Ferraro
> Priority: Major
> Fix For: 18.0.0.Beta1
>
>
> [INFO] Running org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanTestCase
> [ERROR] Tests run: 7, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.929 s <<< FAILURE! - in org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanTestCase
> [ERROR] isExpired(org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanTestCase) Time elapsed: 0.027 s <<< ERROR!
> org.mockito.exceptions.base.MockitoException:
> Cannot call abstract real method on java object!
> Calling real methods is only possible when mocking non abstract method.
> //correct example:
> when(mockOfConcreteClass.nonAbstractMethod()).thenCallRealMethod();
> at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanTestCase.isExpired(InfinispanBeanTestCase.java:104)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
> at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (DROOLS-4395) [DMN Designer] Validation fails for included PMML model
by Matteo Mortari (Jira)
[ https://issues.jboss.org/browse/DROOLS-4395?page=com.atlassian.jira.plugi... ]
Matteo Mortari reassigned DROOLS-4395:
--------------------------------------
Assignee: Guilherme Gomes (was: Matteo Mortari)
> [DMN Designer] Validation fails for included PMML model
> -------------------------------------------------------
>
> Key: DROOLS-4395
> URL: https://issues.jboss.org/browse/DROOLS-4395
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.25.0.Final
> Reporter: Jozef Marko
> Assignee: Guilherme Gomes
> Priority: Critical
> Labels: drools-tools
> Attachments: Screenshot from 2019-08-08 16-02-49.png, cannot-reproduce.gif, error.log, test_tree_with_surrogate.pmml, uUAGNUxc.dmn
>
>
> There is an issue when user imports a PMML model into a DMN model. Then saving/validation of the DMN throws an error.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months