[Red Hat JIRA] (DROOLS-5898) Make PMML-generated classes serializable
by Gabriele Cardosi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5898?page=com.atlassian.jira.plug... ]
Gabriele Cardosi updated DROOLS-5898:
-------------------------------------
Parent: DROOLS-5859
Issue Type: Sub-task (was: Bug)
QEStatus: (was: ToDo)
> Make PMML-generated classes serializable
> ----------------------------------------
>
> Key: DROOLS-5898
> URL: https://issues.redhat.com/browse/DROOLS-5898
> Project: Drools
> Issue Type: Sub-task
> Reporter: Gabriele Cardosi
> Assignee: Gabriele Cardosi
> Priority: Major
> Labels: TrustyAI
>
> Currently generated PMML classes are not serializable, and some exception may arise
> e.g.:
> {code:java}
> 16:48:34,544 ERROR [org.guvnor.common.services.backend.exceptions.ExceptionUtilities] (default task-8) Exception thrown: java.io.NotSerializableException: categoricalvariablesregression.CategoricalVariablesRegression: java.lang.RuntimeException: java.io.NotSerializableException: categoricalvariablesregression.CategoricalVariablesRegression
> at deployment.business-central.war//org.drools.core.util.ClassUtils.deepClone(ClassUtils.java:761)
> at deployment.business-central.war//org.drools.core.definitions.impl.KnowledgePackageImpl.deepCloneIfAlreadyInUse(KnowledgePackageImpl.java:814)
> at deployment.business-central.war//org.drools.core.definitions.impl.KnowledgePackageImpl.deepCloneIfAlreadyInUse(KnowledgePackageImpl.java:69)
> at deployment.business-central.war//org.drools.core.impl.KnowledgeBaseImpl.addPackages(KnowledgeBaseImpl.java:723)
> at deployment.business-central.war//org.drools.compiler.kie.builder.impl.AbstractKieModule.createKieBase(AbstractKieModule.java:221)
> at deployment.business-central.war//org.drools.compiler.kie.builder.impl.KieContainerImpl.createKieBase(KieContainerImpl.java:470)
> at deployment.business-central.war//org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:438)
> at deployment.business-central.war//org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:419)
> at deployment.business-central.war//org.drools.scenariosimulation.backend.util.DMNSimulationUtils.extractDMNRuntime(DMNSimulationUtils.java:43)
> {code}
> Generated classes must be serializable
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (DROOLS-5898) Make PMML-generated classes serializable
by Gabriele Cardosi (Jira)
Gabriele Cardosi created DROOLS-5898:
----------------------------------------
Summary: Make PMML-generated classes serializable
Key: DROOLS-5898
URL: https://issues.redhat.com/browse/DROOLS-5898
Project: Drools
Issue Type: Bug
Reporter: Gabriele Cardosi
Assignee: Gabriele Cardosi
Currently generated PMML classes are not serializable, and some exception may arise
e.g.:
{code:java}
16:48:34,544 ERROR [org.guvnor.common.services.backend.exceptions.ExceptionUtilities] (default task-8) Exception thrown: java.io.NotSerializableException: categoricalvariablesregression.CategoricalVariablesRegression: java.lang.RuntimeException: java.io.NotSerializableException: categoricalvariablesregression.CategoricalVariablesRegression
at deployment.business-central.war//org.drools.core.util.ClassUtils.deepClone(ClassUtils.java:761)
at deployment.business-central.war//org.drools.core.definitions.impl.KnowledgePackageImpl.deepCloneIfAlreadyInUse(KnowledgePackageImpl.java:814)
at deployment.business-central.war//org.drools.core.definitions.impl.KnowledgePackageImpl.deepCloneIfAlreadyInUse(KnowledgePackageImpl.java:69)
at deployment.business-central.war//org.drools.core.impl.KnowledgeBaseImpl.addPackages(KnowledgeBaseImpl.java:723)
at deployment.business-central.war//org.drools.compiler.kie.builder.impl.AbstractKieModule.createKieBase(AbstractKieModule.java:221)
at deployment.business-central.war//org.drools.compiler.kie.builder.impl.KieContainerImpl.createKieBase(KieContainerImpl.java:470)
at deployment.business-central.war//org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:438)
at deployment.business-central.war//org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:419)
at deployment.business-central.war//org.drools.scenariosimulation.backend.util.DMNSimulationUtils.extractDMNRuntime(DMNSimulationUtils.java:43)
{code}
Generated classes must be serializable
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFWIP-367) WildFly can stuck for a while when trying to connect an unavailable Kafka socket and is terminated
by Jan Stourac (Jira)
Jan Stourac created WFWIP-367:
---------------------------------
Summary: WildFly can stuck for a while when trying to connect an unavailable Kafka socket and is terminated
Key: WFWIP-367
URL: https://issues.redhat.com/browse/WFWIP-367
Project: WildFly WIP
Issue Type: Bug
Reporter: Jan Stourac
Assignee: Kabir Khan
Attachments: helloworld-sources.jar, helloworld.war
It looks WildFly can stuck for a while with the newly introduced MP Reactive Messaging implementation. If one deploy a deployment that utilizes 'smallrye-kafka' connector it then repeatedly tries to connect against Kafka instance. If that instance is not available on configured socket, then undeploy operation of the app stucks for a while. Similar thing happens for shutdown operation of the server via regular 'ctrl+C' signal.
Based on the discussion, this may be an issue that needs to be addressed on SmallRye side as there may be some timeout reached before Kafka connector stops listening.
From user point of view - both these operations are not 'graceful' as such - in both cases user expects that undeploy and shutdown should be performed immediately. Thinking about it, I think that even in case of a graceful shutdown, since these are just an attempts for a connection, there is still no need to linger with server shutdown.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFLY-14199) OnOffOpenTracingTestCase leaves the server in a bad state
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFLY-14199?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFLY-14199:
--------------------------------------
The issue with stop not being invoked in RESTEasy seems to be from the {{HttpServlet.destroy()}} not being invoked. Maybe that should be invoked on failed deployments. However maybe for spec reasons that doesn't happen.
When looking at RESTEasy I didn't see an obvious way to ensure {{ResteasyDeployment.stop()}} was invoked as it's an instance on a {{HttpServletDispatcher}}. I will talk with [~ron_sigal] about this.
> OnOffOpenTracingTestCase leaves the server in a bad state
> ---------------------------------------------------------
>
> Key: WFLY-14199
> URL: https://issues.redhat.com/browse/WFLY-14199
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing, Test Suite
> Affects Versions: 22.0.0.Alpha1
> Reporter: Emmanuel Hugonnet
> Assignee: Emmanuel Hugonnet
> Priority: Major
>
> {color:#333333}OnOffOpenTracingTestCase{color} will leave the server in such a state that SimpleRestClientTestCase will fail. Removing and adding the opentracing subsystem to check that it doesn't work once removed shoudl be reevaluated.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFLY-14219) Utilize JBoss Modules version 1.9 in module descriptors
by Richard Opalka (Jira)
[ https://issues.redhat.com/browse/WFLY-14219?page=com.atlassian.jira.plugi... ]
Richard Opalka updated WFLY-14219:
----------------------------------
Summary: Utilize JBoss Modules version 1.9 in module descriptors (was: Utilize JBoss Modules version 1.8 in module descriptors)
> Utilize JBoss Modules version 1.9 in module descriptors
> -------------------------------------------------------
>
> Key: WFLY-14219
> URL: https://issues.redhat.com/browse/WFLY-14219
> Project: WildFly
> Issue Type: Task
> Components: Server
> Affects Versions: 22.0.0.Alpha1
> Reporter: Boris Unckel
> Assignee: Brian Stansberry
> Priority: Major
> Attachments: 2020-12-13_wildfly-22.0.0.Beta1-SNAPSHOT_modules_15_16_17.txt
>
>
> There are still modules which use 1.5, 1.6 or 1.7 and do not need that. The idea is to run jdeps on each artifact of a modul, add the relevant java.* and jdk.* modules to the dependencies of the module and upgrade to version 1.8. In a first change only none-jdk modules and none which depend on system dependency.
> List in 2020-12-13_wildfly-22.0.0.Beta1-SNAPSHOT_modules_15_16_17.txt
> Changes in a first set of modules in WildFly-Core [WFCORE-5229|https://issues.redhat.com/browse/WFCORE-5229] integration tests were successful.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFCORE-5229) Utilize JBoss Modules version 1.9 in module descriptors
by Richard Opalka (Jira)
[ https://issues.redhat.com/browse/WFCORE-5229?page=com.atlassian.jira.plug... ]
Richard Opalka updated WFCORE-5229:
-----------------------------------
Summary: Utilize JBoss Modules version 1.9 in module descriptors (was: Utilize JBoss Modules version 1.8 in module descriptors)
> Utilize JBoss Modules version 1.9 in module descriptors
> -------------------------------------------------------
>
> Key: WFCORE-5229
> URL: https://issues.redhat.com/browse/WFCORE-5229
> Project: WildFly Core
> Issue Type: Task
> Components: Modules
> Affects Versions: 14.0.0.Beta4
> Reporter: Boris Unckel
> Assignee: Richard Opalka
> Priority: Major
> Attachments: 2020-12-12_wfcorejdep_14.0.0.Beta5-SNAPSHOT.7z
>
>
> There are still modules which use 1.6 or 1.7 and do not need that. The idea is to run jdeps on each artifact of a modul, add the relevant java.* modules to the dependencies of the module and upgrade to version 1.8. In a first only none-jdk modules and none which depend on system dependency.
> Full list:
> ./system/layers/base/sun/scripting/main/module.xml:<module xmlns="urn:jboss:module:1.6" name="sun.scripting">
> ./system/layers/base/sun/jdk/main/module.xml:<module xmlns="urn:jboss:module:1.6" name="sun.jdk">
> ./system/layers/base/ibm/jdk/main/module.xml:<module xmlns="urn:jboss:module:1.6" name="ibm.jdk">
> ./system/layers/base/io/undertow/core/main/module.xml:<module xmlns="urn:jboss:module:1.6" name="io.undertow.core">
> ./system/layers/base/org/apache/log4j/main/module.xml:<module xmlns="urn:jboss:module:1.6" name="org.apache.log4j">
> ./system/layers/base/org/apache/commons/logging/main/module.xml:<module xmlns="urn:jboss:module:1.6" name="org.apache.commons.logging">
> ./system/layers/base/org/fusesource/jansi/main/module.xml:<module xmlns="urn:jboss:module:1.6" name="org.fusesource.jansi">
> ./system/layers/base/org/slf4j/main/module.xml:<module xmlns="urn:jboss:module:1.6" name="org.slf4j">
> ./system/layers/base/org/slf4j/impl/main/module.xml:<module xmlns="urn:jboss:module:1.6" name="org.slf4j.impl">
> ./system/layers/base/org/jboss/stdio/main/module.xml:<module xmlns="urn:jboss:module:1.6" name="org.jboss.stdio">
> ./system/layers/base/org/jboss/jandex/main/module.xml:<module xmlns="urn:jboss:module:1.6" name="org.jboss.jandex">
> ./system/layers/base/org/jboss/vfs/main/module.xml:<module xmlns="urn:jboss:module:1.6" name="org.jboss.vfs">
> ./system/layers/base/org/jboss/staxmapper/main/module.xml:<module xmlns="urn:jboss:module:1.6" name="org.jboss.staxmapper">
> ./system/layers/base/org/jboss/as/domain-http-error-context/main/module.xml:<module xmlns="urn:jboss:module:1.6" name="org.jboss.as.domain-http-error-context">
> ./system/layers/base/org/jboss/as/core-security-api/main/module.xml:<module xmlns="urn:jboss:module:1.6" name="org.jboss.as.core-security-api">
> ./system/layers/base/org/jboss/as/version/main/module.xml:<module xmlns="urn:jboss:module:1.6" name="org.jboss.as.version">
> ./system/layers/base/org/jboss/as/domain-add-user/main/module.xml:<module xmlns="urn:jboss:module:1.6" name="org.jboss.as.domain-add-user">
> ./system/layers/base/org/jboss/as/management-client-content/main/module.xml:<module xmlns="urn:jboss:module:1.6" name="org.jboss.as.management-client-content">
> ./system/layers/base/org/jboss/as/deployment-repository/main/module.xml:<module xmlns="urn:jboss:module:1.6" name="org.jboss.as.deployment-repository">
> ./system/layers/base/org/jboss/as/threads/main/module.xml:<module xmlns="urn:jboss:module:1.6" name="org.jboss.as.threads">
> ./system/layers/base/org/jboss/as/patching/cli/main/module.xml:<module xmlns="urn:jboss:module:1.6" name="org.jboss.as.patching.cli">
> ./system/layers/base/org/jboss/as/controller-client/main/module.xml:<module xmlns="urn:jboss:module:1.6" name="org.jboss.as.controller-client">
> ./system/layers/base/org/jboss/as/standalone/main/module.xml:<module xmlns="urn:jboss:module:1.6" name="org.jboss.as.standalone">
> ./system/layers/base/org/jboss/logging/jul-to-slf4j-stub/main/module.xml:<module xmlns="urn:jboss:module:1.6" name="org.jboss.logging.jul-to-slf4j-stub">
> ./system/layers/base/org/jboss/logging/main/module.xml:<module xmlns="urn:jboss:module:1.6" name="org.jboss.logging">
> ./system/layers/base/org/jboss/invocation/main/module.xml:<module xmlns="urn:jboss:module:1.6" name="org.jboss.invocation">
> ./system/layers/base/org/jboss/dmr/main/module.xml:<module xmlns="urn:jboss:module:1.6" name="org.jboss.dmr">
> ./system/layers/base/org/wildfly/embedded/main/module.xml:<module xmlns="urn:jboss:module:1.6" name="org.wildfly.embedded">
> ./system/layers/base/org/wildfly/extension/core-management-client/main/module.xml:<module xmlns="urn:jboss:module:1.6" name="org.wildfly.extension.core-management-client">
> ./system/layers/base/org/wildfly/security/manager/main/module.xml:<module xmlns="urn:jboss:module:1.6" name="org.wildfly.security.manager">
> ./system/layers/base/org/wildfly/security/elytron/main/module.xml:<module xmlns="urn:jboss:module:1.6" name="org.wildfly.security.elytron">
> ./system/layers/base/org/jboss/logging/commons/logging/main/module.xml:<module xmlns="urn:jboss:module:1.7" name="org.jboss.logging.commons.logging">
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (JBJCA-1415) LocalManagedConnectionFactory: switch to datasource module during connection creation
by Tomasz Adamski (Jira)
[ https://issues.redhat.com/browse/JBJCA-1415?page=com.atlassian.jira.plugi... ]
Tomasz Adamski updated JBJCA-1415:
----------------------------------
Description: During diagnosis of EAPSUP-312 it was found out that connections in pool are being created using various classloaders, depending on the way the connections is created. This was shown to lead to errors in Kerberos scenarios. I believe that, for the sake of consistency, we should switch to driver module during connection creation. (was: During diagnosis of EAPSUP-312 it was found out that connections in pool are being created using various classloaders, depending on the way the connections is created. I believe that, for the sake of consistency, we should switch to driver module during connection creation.)
> LocalManagedConnectionFactory: switch to datasource module during connection creation
> -------------------------------------------------------------------------------------
>
> Key: JBJCA-1415
> URL: https://issues.redhat.com/browse/JBJCA-1415
> Project: IronJacamar
> Issue Type: Bug
> Reporter: Tomasz Adamski
> Assignee: Tomasz Adamski
> Priority: Major
>
> During diagnosis of EAPSUP-312 it was found out that connections in pool are being created using various classloaders, depending on the way the connections is created. This was shown to lead to errors in Kerberos scenarios. I believe that, for the sake of consistency, we should switch to driver module during connection creation.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (JBJCA-1415) LocalManagedConnectionFactory: switch to datasource module during connection creation
by Tomasz Adamski (Jira)
[ https://issues.redhat.com/browse/JBJCA-1415?page=com.atlassian.jira.plugi... ]
Tomasz Adamski updated JBJCA-1415:
----------------------------------
Description: During diagnosis of EAPSUP-312 it was found out that connections in pool are being created using various classloaders, depending on the way the connections is created. I believe that, for the sake of consistency, we should switch to driver module during connection creation.
> LocalManagedConnectionFactory: switch to datasource module during connection creation
> -------------------------------------------------------------------------------------
>
> Key: JBJCA-1415
> URL: https://issues.redhat.com/browse/JBJCA-1415
> Project: IronJacamar
> Issue Type: Bug
> Reporter: Tomasz Adamski
> Assignee: Tomasz Adamski
> Priority: Major
>
> During diagnosis of EAPSUP-312 it was found out that connections in pool are being created using various classloaders, depending on the way the connections is created. I believe that, for the sake of consistency, we should switch to driver module during connection creation.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months