[JBoss JIRA] (DROOLS-3356) Add support to simple java types as Data Object in the right panel
by Klara Kufova (Jira)
[ https://issues.jboss.org/browse/DROOLS-3356?page=com.atlassian.jira.plugi... ]
Klara Kufova updated DROOLS-3356:
---------------------------------
Attachment: screencast-02-01-19-1.webm
> Add support to simple java types as Data Object in the right panel
> ------------------------------------------------------------------
>
> Key: DROOLS-3356
> URL: https://issues.jboss.org/browse/DROOLS-3356
> Project: Drools
> Issue Type: Story
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Gabriele Cardosi
> Priority: Major
> Labels: ScenarioSimulation
> Attachments: screencast-02-01-19-1.webm, screencast-17-12-18-2.webm, screencast-17-12-18.webm
>
>
> As user I want to use simple java types (`String`, `int` etc) as data object.
> Behavior differences for DMN:
> header can't be editable
> FactIdentifier must be equals to name (=factAlias)
> there can be only one instance of a given type at all, regardless if in "GIVEN" or "EXPECT"
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (WFLY-11505) XercesUsageInWebServiceTestCase fails with security manager on IBM Java 8
by Ondrej Kotek (Jira)
[ https://issues.jboss.org/browse/WFLY-11505?page=com.atlassian.jira.plugin... ]
Ondrej Kotek updated WFLY-11505:
--------------------------------
Environment: IBM Java 8, build 8.0.5.25 or 8.0.5.26 (was: IBM Java 8, build 8.0.5.25)
> XercesUsageInWebServiceTestCase fails with security manager on IBM Java 8
> -------------------------------------------------------------------------
>
> Key: WFLY-11505
> URL: https://issues.jboss.org/browse/WFLY-11505
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite, Web Services
> Affects Versions: 16.0.0.Beta1
> Environment: IBM Java 8, build 8.0.5.25 or 8.0.5.26
> Reporter: Ondrej Kotek
> Assignee: Bartosz Baranowski
> Priority: Major
>
> {{org.jboss.as.test.integration.xerces.ws.unit.XercesUsageInWebServiceTestCase#testXercesUsageInWebService}} fails with security manager on IBM Java 8 due to missing permissions:
> {noformat}
> SEVERE [org.apache.cxf.frontend.WSDLGetInterceptor] (default task-3) WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessClassInPackage.org.apache.xerces.impl.xs.identity")" in code source "(vfs:/content/xerces-webservice-webapp.war/WEB-INF/lib/xercesImpl.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.xerces-webservice-webapp.war" from Service Module Loader"): java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessClassInPackage.org.apache.xerces.impl.xs.identity")" in code source "(vfs:/content/xerces-webservice-webapp.war/WEB-INF/lib/xercesImpl.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.xerces-webservice-webapp.war" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:294)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:191)
> at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1655)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPackageAccess(WildFlySecurityManager.java:490)
> at java.lang.J9VMInternals$2.run(J9VMInternals.java:268)
> at java.security.AccessController.doPrivileged(AccessController.java:673)
> at java.lang.J9VMInternals.checkPackageAccess(J9VMInternals.java:263)
> at java.lang.ClassLoader.defineClassImpl(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:379)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:1734)
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:424)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:519)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:339)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:126)
> at org.jboss.modules.Module.loadModuleClass(Module.java:731)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:247)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> at org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder(Unknown Source)
> at com.ibm.wsdl.xml.WSDLWriterImpl.getDocument(WSDLWriterImpl.java:1013)
> at com.ibm.wsdl.xml.WSDLWriterImpl.getDocument(WSDLWriterImpl.java:1043)
> at org.apache.cxf.frontend.WSDLGetUtils.writeWSDLDocument(WSDLGetUtils.java:705)
> at org.apache.cxf.frontend.WSDLGetUtils.getDocument(WSDLGetUtils.java:151)
> at org.apache.cxf.frontend.WSDLGetInterceptor.getDocument(WSDLGetInterceptor.java:129)
> at org.apache.cxf.frontend.WSDLGetInterceptor.handleMessage(WSDLGetInterceptor.java:77)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267)
> at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:110)
> at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:134)
> at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:301)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:225)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:686)
> at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136)
> at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$825.000000005C9627C0.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$826.000000005C962DB0.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$826.000000005C962DB0.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$826.000000005C962DB0.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$826.000000005C962DB0.call(Unknown Source)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110)
> at java.security.AccessController.doPrivileged(AccessController.java:703)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:812)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (DROOLS-1781) Investigate possible replacement of findbugs-maven-plugin with spotbugs-maven-plugin
by Radovan Synek (Jira)
[ https://issues.jboss.org/browse/DROOLS-1781?page=com.atlassian.jira.plugi... ]
Radovan Synek commented on DROOLS-1781:
---------------------------------------
[~ge0ffrey] no problem with that. We might just exclude it from the CI build in the future to save some time - as the builds are getting longer over time.
> Investigate possible replacement of findbugs-maven-plugin with spotbugs-maven-plugin
> ------------------------------------------------------------------------------------
>
> Key: DROOLS-1781
> URL: https://issues.jboss.org/browse/DROOLS-1781
> Project: Drools
> Issue Type: Task
> Components: build
> Affects Versions: 7.4.1.Final
> Reporter: Petr Široký
> Assignee: Michael Biarnes Kiefer
> Priority: Major
> Labels: java9
>
> SpotBugs is a successor of FingBugs and as such uses different groupId + artifactId for maven plugin. It should also be compatible with Java 9 (at least in the latest versions). We need to investigate it the switch is painless and if so, do it. Otherwise we need to figure out what the blockers are and slowly start to fix them as FindBugs itself won't bet any more updates it seems and so won't be Java 9 compatible.
> *How to migrate*
> * Replace
> {code}
> <groupId>org.codehaus.mojo</groupId>
> <artifactId>findbugs-maven-plugin</artifactId>
> {code}
> by
> {code}
> <groupId>com.github.spotbugs</groupId>
> <artifactId>spotbugs-maven-plugin</artifactId>
> {code}
> * Look for all "findbugs" and replace it by "spotbugs"
> ** Except for anything related to the findbugs annotations dependency that some dependencies drag in or exclude. Leave that one alone!
> ** For example, change findbugs-check -> spotbugs-check, ...
> * Merge this PR if it hasn't been merged already: https://github.com/kiegroup/optaplanner-wb/pull/320
> * Then you only need to adjust the following repo's: build-boostrap, drools, optaplanner and kie-wb-distributions.
> ** See https://github.com/search?q=org%3Akiegroup+findbugs-maven-plugin&type=Code
> ** Ignore contributed experiments, that repo is dead
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (WFLY-11550) Provide ability to suspend and resume the set of servers managed by a specific host controller
by Yeray Borges (Jira)
[ https://issues.jboss.org/browse/WFLY-11550?page=com.atlassian.jira.plugin... ]
Yeray Borges moved WFCORE-4264 to WFLY-11550:
---------------------------------------------
Project: WildFly (was: WildFly Core)
Key: WFLY-11550 (was: WFCORE-4264)
Component/s: Documentation
(was: CLI)
(was: Management)
> Provide ability to suspend and resume the set of servers managed by a specific host controller
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-11550
> URL: https://issues.jboss.org/browse/WFLY-11550
> Project: WildFly
> Issue Type: Feature Request
> Components: Documentation
> Reporter: Yeray Borges
> Assignee: Yeray Borges
> Priority: Major
>
> In WildFly 10 we introduced the server suspend/resume and graceful shutdown feature. This feature allows the server to complete the active requests normally, without accepting any new requests. A timeout value specifies how long the suspend or shutdown operation waits for active request to complete.
> However, there are no specific operations to suspend/resume and shutdown gracefully all servers managed by a specific host controller. These operations can be applied only at server-group or whole domain level. The goal of this issue is to facilitate these tasks to the administrators.
> Additionally, the timeout attribute for all of those lifecycle operations will be renamed to suspend-timeout to avoid the confusion of this value with timeout applied to the entire operation. The suspend-timeout attribute has a meaning only for the timeout applied to suspend the servers.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (WFCORE-1427) Provide ability to suspend and resume the set of servers managed by a specific host controller
by Yeray Borges (Jira)
[ https://issues.jboss.org/browse/WFCORE-1427?page=com.atlassian.jira.plugi... ]
Yeray Borges updated WFCORE-1427:
---------------------------------
Description:
In WildFly 10 we introduced the server suspend/resume and graceful shutdown feature. This feature allows the server to complete the active requests normally, without accepting any new requests. A timeout value specifies how long the suspend or shutdown operation waits for active request to complete.
However, there are no specific operations to suspend/resume and shutdown gracefully all servers managed by a specific host controller. These operations can be applied only at server-group or whole domain level. The goal of this issue is to facilitate these tasks to the administrators.
Additionally, the timeout attribute for all of those lifecycle operations will be renamed to suspend-timeout to avoid the confusion of this value with timeout applied to the entire operation. The suspend-timeout attribute has a meaning only for the timeout applied to suspend the servers.
was:
So instead of
{code}
:suspend(20)
:reload
{code}
It's just
{code}
:reload(20)
{code}
The high level 'reload' command in the CLI should take a --timeout param as well.
If doing the graceful suspend as part of server side ":reload" handling proves problematic (I haven't looked into it at all before filing this) then a simpler alternative is to only go with the --timeout param on the CLI reload command, and have the CLI implement the graceful behavior internally by first calling :suspend and then :reload. Web console could do the same thing.
> Provide ability to suspend and resume the set of servers managed by a specific host controller
> ----------------------------------------------------------------------------------------------
>
> Key: WFCORE-1427
> URL: https://issues.jboss.org/browse/WFCORE-1427
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI, Management
> Reporter: Brian Stansberry
> Assignee: Yeray Borges
> Priority: Major
>
> In WildFly 10 we introduced the server suspend/resume and graceful shutdown feature. This feature allows the server to complete the active requests normally, without accepting any new requests. A timeout value specifies how long the suspend or shutdown operation waits for active request to complete.
> However, there are no specific operations to suspend/resume and shutdown gracefully all servers managed by a specific host controller. These operations can be applied only at server-group or whole domain level. The goal of this issue is to facilitate these tasks to the administrators.
> Additionally, the timeout attribute for all of those lifecycle operations will be renamed to suspend-timeout to avoid the confusion of this value with timeout applied to the entire operation. The suspend-timeout attribute has a meaning only for the timeout applied to suspend the servers.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (WFCORE-4264) Provide ability to suspend and resume the set of servers managed by a specific host controller
by Yeray Borges (Jira)
Yeray Borges created WFCORE-4264:
------------------------------------
Summary: Provide ability to suspend and resume the set of servers managed by a specific host controller
Key: WFCORE-4264
URL: https://issues.jboss.org/browse/WFCORE-4264
Project: WildFly Core
Issue Type: Feature Request
Components: CLI, Management
Reporter: Yeray Borges
Assignee: Yeray Borges
In WildFly 10 we introduced the server suspend/resume and graceful shutdown feature. This feature allows the server to complete the active requests normally, without accepting any new requests. A timeout value specifies how long the suspend or shutdown operation waits for active request to complete.
However, there are no specific operations to suspend/resume and shutdown gracefully all servers managed by a specific host controller. These operations can be applied only at server-group or whole domain level. The goal of this issue is to facilitate these tasks to the administrators.
Additionally, the timeout attribute for all of those lifecycle operations will be renamed to suspend-timeout to avoid the confusion of this value with timeout applied to the entire operation. The suspend-timeout attribute has a meaning only for the timeout applied to suspend the servers.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (WFLY-11372) Latest DB2 11.1 JDBC driver requires additional IBM JDK system dependency
by Lin Gao (Jira)
[ https://issues.jboss.org/browse/WFLY-11372?page=com.atlassian.jira.plugin... ]
Lin Gao reassigned WFLY-11372:
------------------------------
Assignee: Lin Gao (was: Stefano Maestri)
> Latest DB2 11.1 JDBC driver requires additional IBM JDK system dependency
> -------------------------------------------------------------------------
>
> Key: WFLY-11372
> URL: https://issues.jboss.org/browse/WFLY-11372
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading, JCA
> Affects Versions: 14.0.0.Final, 15.0.0.Beta1
> Environment: IBM DB2 11.1 JDBC driver (version 4.24.92)
> IBM JDK 8:
> {noformat}
> $ java -version
> java version "1.8.0_181"
> Java(TM) SE Runtime Environment (build 8.0.5.22 - pxa6480sr5fp22-20180919_01(SR5 FP22))
> IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20180915_397057 (JIT enabled, AOT enabled)
> OpenJ9 - 6c152c2
> OMR - 15647c3
> IBM - d734883)
> JCL - 20180821_01 based on Oracle jdk8u181-b12
> {noformat}
> Reporter: Martin Simka
> Assignee: Lin Gao
> Priority: Critical
>
> Running on IBM JDK 8 latest DB2 11.1 JDBC driver (version 4.24.92) fails to connect to database with error:
> {noformat}
> Caused by: java.lang.NoClassDefFoundError: com/ibm/dataaccess/ByteArrayUnmarshaller
> at com.ibm.db2.jcc.a.j.h(j.java:21)
> at com.ibm.db2.jcc.a.i.g(i.java:151)
> at com.ibm.db2.jcc.a.i.b(i.java:76)
> at com.ibm.db2.jcc.t4.y.q(y.java:1373)
> at com.ibm.db2.jcc.t4.z.c(z.java:4792)
> at com.ibm.db2.jcc.t4.z.b(z.java:4740)
> at com.ibm.db2.jcc.t4.z.a(z.java:4726)
> at com.ibm.db2.jcc.t4.z.l(z.java:547)
> at com.ibm.db2.jcc.t4.z.d(z.java:153)
> at com.ibm.db2.jcc.t4.b.k(b.java:1442)
> at com.ibm.db2.jcc.t4.b.b(b.java:1354)
> at com.ibm.db2.jcc.t4.b.a(b.java:6687)
> at com.ibm.db2.jcc.t4.b.b(b.java:888)
> ... 244 more
> {noformat}
> It doesn't matter whether driver is installed as module or deployed to deployments folder.
> DB2 11.1 driver versions
> || Driver version|| status ||
> | 4.21.29 | OK |
> | 4.22.29 | OK |
> | 4.23.42 | Fail |
> | 4.24.92 | Fail |
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (WFLY-11504) Some hibernate tests fail with security on IBM Java 8: HHH000142
by Ondrej Kotek (Jira)
[ https://issues.jboss.org/browse/WFLY-11504?page=com.atlassian.jira.plugin... ]
Ondrej Kotek updated WFLY-11504:
--------------------------------
Environment: IBM Java 8, build 8.0.5.25 (was: IBM Java 8)
> Some hibernate tests fail with security on IBM Java 8: HHH000142
> ----------------------------------------------------------------
>
> Key: WFLY-11504
> URL: https://issues.jboss.org/browse/WFLY-11504
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate, Test Suite
> Affects Versions: 16.0.0.Beta1
> Environment: IBM Java 8, build 8.0.5.25
> Reporter: Ondrej Kotek
> Assignee: Scott Marlow
> Priority: Major
> Attachments: org.jboss.as.test.integration.jpa.hibernate.entitytest.EntityTestCase-output.txt
>
>
> Seven hibernate tests fail with security on IBM Java 8, for example:
> {noformat}
> org.hibernate.HibernateException: HHH000142: Bytecode enhancement failed: org.jboss.as.test.integration.jpa.hibernate.Employee
> {noformat}
> Affected test cases:
> * {{org.jboss.as.test.integration.jpa.hibernate.entitytest.EntityTestCase}}
> * {{org.jboss.as.test.integration.jpa.hibernate.envers.AuditJoinTableoverOnetoManyJoinColumnTest}}
> * {{org.jboss.as.test.integration.jpa.hibernate.envers.basicenverstest.BasicEnversTestCase}}
> * {{org.jboss.as.test.integration.jpa.hibernate.envers.basicselectiveenverstest.BasicSelectiveEnversTestCase}}
> * {{org.jboss.as.test.integration.jpa.hibernate.envers.implementvalidityauditstrategytest.ImplementValidityAuditStrategyTestCase}}
> * {{org.jboss.as.test.integration.jpa.hibernate.envers.validityauditstrategyoninheritancetest.ValidityAuditStrategyonInheritanceTestCase}}
> * {{org.jboss.as.test.integration.jpa.hibernate.sessionfactorytest.SessionFactoryTestCase}}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (DROOLS-3465) [DMN Designer] ContextGrid and DecisionTableGrid selectFirstCell() regression
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-3465?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-3465:
-----------------------------------
Tester: Jozef Marko
Labels: drools-tools (was: )
> [DMN Designer] ContextGrid and DecisionTableGrid selectFirstCell() regression
> -----------------------------------------------------------------------------
>
> Key: DROOLS-3465
> URL: https://issues.jboss.org/browse/DROOLS-3465
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.15.0.Final
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
>
> (Programmatic) selection of the "first cell" in both the {{ContextGrid}} and {{DecisionTableGrid}} has regressed. Selection should ignore the "row number" column however changes adding explicit "Row number columns" for the foregoing grids that do not extend {{RowNumberColumn}} have caused the expected behaviour to break.
> h2. Acceptance criteria
> # Create new Decision
> # Set expression to either {{Context}} or {{DecisionTable}}
> # The whole row should not be selected, only one cell.
> # Check other expression types.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months