[JBoss JIRA] (DROOLS-5375) Implement GeneratePMMLModelMojo inside kie-maven-plugin
by Gabriele Cardosi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5375?page=com.atlassian.jira.plug... ]
Gabriele Cardosi updated DROOLS-5375:
-------------------------------------
Description:
GeneratePMMLModelMojo has been implemented as part of https://issues.redhat.com/browse/DROOLS-5258 and it is currently present inside
https://github.com/gitgabrio/droolsjbpm-integration/tree/DROOLS-5258 branch.
-Thing to fix:-
-currently the plugin works if the source project is correctly layed down (i.e. every pmml file in its own package and kmodule.xml manually written out).-
-A way is needed so that user put all pmml files inside resources/PMMLResources and the model is correctly compiled.-
-It is needed to have a pre-compile phase (before any compilation) where-
-1) resources are moved to expected "resource" subfolder-
-2) kmodule.xml is generated-
-This must happen before invocation of kie build.--
Fixed by DROOLS-5367
was:
GeneratePMMLModelMojo has been implemented as part of https://issues.redhat.com/browse/DROOLS-5258 and it is currently present inside
https://github.com/gitgabrio/droolsjbpm-integration/tree/DROOLS-5258 branch.
-Thing to fix:-
currently the plugin works if the source project is correctly layed down (i.e. every pmml file in its own package and kmodule.xml manually written out).
A way is needed so that user put all pmml files inside resources/PMMLResources and the model is correctly compiled.
It is needed to have a pre-compile phase (before any compilation) where
1) resources are moved to expected "resource" subfolder
2) kmodule.xml is generated
This must happen before invocation of kie build.-
> Implement GeneratePMMLModelMojo inside kie-maven-plugin
> --------------------------------------------------------
>
> Key: DROOLS-5375
> URL: https://issues.redhat.com/browse/DROOLS-5375
> Project: Drools
> Issue Type: Task
> Reporter: Gabriele Cardosi
> Assignee: Gabriele Cardosi
> Priority: Major
> Labels: TrustyAI
>
> GeneratePMMLModelMojo has been implemented as part of https://issues.redhat.com/browse/DROOLS-5258 and it is currently present inside
> https://github.com/gitgabrio/droolsjbpm-integration/tree/DROOLS-5258 branch.
> -Thing to fix:-
> -currently the plugin works if the source project is correctly layed down (i.e. every pmml file in its own package and kmodule.xml manually written out).-
> -A way is needed so that user put all pmml files inside resources/PMMLResources and the model is correctly compiled.-
> -It is needed to have a pre-compile phase (before any compilation) where-
> -1) resources are moved to expected "resource" subfolder-
> -2) kmodule.xml is generated-
> -This must happen before invocation of kie build.--
> Fixed by DROOLS-5367
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (DROOLS-5375) Implement GeneratePMMLModelMojo inside kie-maven-plugin
by Gabriele Cardosi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5375?page=com.atlassian.jira.plug... ]
Gabriele Cardosi updated DROOLS-5375:
-------------------------------------
Description:
GeneratePMMLModelMojo has been implemented as part of https://issues.redhat.com/browse/DROOLS-5258 and it is currently present inside
https://github.com/gitgabrio/droolsjbpm-integration/tree/DROOLS-5258 branch.
-Thing to fix:-
currently the plugin works if the source project is correctly layed down (i.e. every pmml file in its own package and kmodule.xml manually written out).
A way is needed so that user put all pmml files inside resources/PMMLResources and the model is correctly compiled.
It is needed to have a pre-compile phase (before any compilation) where
1) resources are moved to expected "resource" subfolder
2) kmodule.xml is generated
This must happen before invocation of kie build.-
was:
GeneratePMMLModelMojo has been implemented as part of https://issues.redhat.com/browse/DROOLS-5258 and it is currently present inside
https://github.com/gitgabrio/droolsjbpm-integration/tree/DROOLS-5258 branch.
-Thing to fix:
currently the plugin works if the source project is correctly layed down (i.e. every pmml file in its own package and kmodule.xml manually written out).
A way is needed so that user put all pmml files inside resources/PMMLResources and the model is correctly compiled.
It is needed to have a pre-compile phase (before any compilation) where
1) resources are moved to expected "resource" subfolder
2) kmodule.xml is generated
This must happen before invocation of kie build.-
> Implement GeneratePMMLModelMojo inside kie-maven-plugin
> --------------------------------------------------------
>
> Key: DROOLS-5375
> URL: https://issues.redhat.com/browse/DROOLS-5375
> Project: Drools
> Issue Type: Task
> Reporter: Gabriele Cardosi
> Assignee: Gabriele Cardosi
> Priority: Major
> Labels: TrustyAI
>
> GeneratePMMLModelMojo has been implemented as part of https://issues.redhat.com/browse/DROOLS-5258 and it is currently present inside
> https://github.com/gitgabrio/droolsjbpm-integration/tree/DROOLS-5258 branch.
> -Thing to fix:-
> currently the plugin works if the source project is correctly layed down (i.e. every pmml file in its own package and kmodule.xml manually written out).
> A way is needed so that user put all pmml files inside resources/PMMLResources and the model is correctly compiled.
> It is needed to have a pre-compile phase (before any compilation) where
> 1) resources are moved to expected "resource" subfolder
> 2) kmodule.xml is generated
> This must happen before invocation of kie build.-
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (DROOLS-5375) Implement GeneratePMMLModelMojo inside kie-maven-plugin
by Gabriele Cardosi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5375?page=com.atlassian.jira.plug... ]
Gabriele Cardosi updated DROOLS-5375:
-------------------------------------
Description:
GeneratePMMLModelMojo has been implemented as part of https://issues.redhat.com/browse/DROOLS-5258 and it is currently present inside
https://github.com/gitgabrio/droolsjbpm-integration/tree/DROOLS-5258 branch.
-Thing to fix:
currently the plugin works if the source project is correctly layed down (i.e. every pmml file in its own package and kmodule.xml manually written out).
A way is needed so that user put all pmml files inside resources/PMMLResources and the model is correctly compiled.
It is needed to have a pre-compile phase (before any compilation) where
1) resources are moved to expected "resource" subfolder
2) kmodule.xml is generated
This must happen before invocation of kie build.-
was:
GeneratePMMLModelMojo has been implemented as part of https://issues.redhat.com/browse/DROOLS-5258 and it is currently present inside
https://github.com/gitgabrio/droolsjbpm-integration/tree/DROOLS-5258 branch.
Thing to fix:
currently the plugin works if the source project is correctly layed down (i.e. every pmml file in its own package and kmodule.xml manually written out).
A way is needed so that user put all pmml files inside resources/PMMLResources and the model is correctly compiled.
It is needed to have a pre-compile phase (before any compilation) where
1) resources are moved to expected "resource" subfolder
2) kmodule.xml is generated
This must happen before invocation of kie build.
> Implement GeneratePMMLModelMojo inside kie-maven-plugin
> --------------------------------------------------------
>
> Key: DROOLS-5375
> URL: https://issues.redhat.com/browse/DROOLS-5375
> Project: Drools
> Issue Type: Task
> Reporter: Gabriele Cardosi
> Assignee: Gabriele Cardosi
> Priority: Major
> Labels: TrustyAI
>
> GeneratePMMLModelMojo has been implemented as part of https://issues.redhat.com/browse/DROOLS-5258 and it is currently present inside
> https://github.com/gitgabrio/droolsjbpm-integration/tree/DROOLS-5258 branch.
> -Thing to fix:
> currently the plugin works if the source project is correctly layed down (i.e. every pmml file in its own package and kmodule.xml manually written out).
> A way is needed so that user put all pmml files inside resources/PMMLResources and the model is correctly compiled.
> It is needed to have a pre-compile phase (before any compilation) where
> 1) resources are moved to expected "resource" subfolder
> 2) kmodule.xml is generated
> This must happen before invocation of kie build.-
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (WFLY-13902) Bootable JAR/Galleon - HTTP 500 is returned by some RESTEasy tests
by Fabio Burzigotti (Jira)
Fabio Burzigotti created WFLY-13902:
---------------------------------------
Summary: Bootable JAR/Galleon - HTTP 500 is returned by some RESTEasy tests
Key: WFLY-13902
URL: https://issues.redhat.com/browse/WFLY-13902
Project: WildFly
Issue Type: Task
Components: Build System
Affects Versions: 21.0.0.Beta1
Reporter: Fabio Burzigotti
Assignee: Jean Francois Denise
I set the component to {{Build System}} because this only happens with Bootable JAR and - as [~jdenise] noticed - it's related with Galleon.
This is about some tests in the RESTEasy TS which has been adapted to execute against bootable JARs through a specific profile [1].
The tests are running successfully with WildFly 20.0.1.Final (the {{ejb}} layer needs to be removed for this experiment to be run [2]) but fail against 21.0.0.Beta1, so it is a regression.
Also, the tests are passing when the TS is executed against a distributed WildFly version, and only fail when the server is packaged via the {{wildfly-jar-maven-plugin}}.
There are 108 tests failing but htis JIRA focuses on those failing because of the following error:
{code}
RESTEASY002005: Failed executing POST /all/a/z: org.jboss.resteasy.core.NoMessageBodyWriterFoundFailure: Could not find MessageBodyWriter for response object of type: org.jboss.resteasy.test.validation.resource.ValidationFoo of media type: application/xml;charset=UTF-8
{code}
hence I guess serialization issues when the request accept header is not {{application/json}}, e.g. {{org.jboss.resteasy.test.validation.ValidationTest}}
*Steps to reproduce*:
1. clone https://github.com/fabiobrz/Resteasy/tree/bootable-jar-support
2. build RESTEasy:
{code}
$ mvn install -Dmaven.test.skip=true -Dmaven.repo.local=/home/my-local-repo
{code}
3. run the test against WF 21.0.0.Beta1:
{code}
cd testsuite
{code}
{code}
mvn clean verify -am -pl integration-tests -Dmaven.repo.local=/home/my-local-repo -Dserver.version=21.0.0.Beta1 -Dtest=org.jboss.resteasy.test.validation.ValidationTest
{code}
The test should *pass*
4. run the test against WF 21.0.0.Beta1 with bootable JAR:
{code}
mvn clean verify -am -pl integration-tests -Dmaven.repo.local=/home/my-local-repo -Dserver.version=21.0.0.Beta1 -Dtest=org.jboss.resteasy.test.validation.ValidationTest -Ddisable.microprofile.tests -Dserver.home=foo -Dts.bootable
{code}
The test should *fail*
5. run the test against WF 20.0.1.Final with bootable JAR:
{code}
mvn clean verify -am -pl integration-tests -Dmaven.repo.local=/home/my-local-repo -Dserver.version=20.0.1.Final -Dtest=org.jboss.resteasy.test.validation.ValidationTest -Ddisable.microprofile.tests -Dserver.home=foo -Dts.bootable
{code}
The test should *pass*
[1]
https://github.com/resteasy/Resteasy/pull/2526/files#diff-8c7ea03eb619e46...
[2]
https://github.com/resteasy/Resteasy/pull/2526/files#diff-8c7ea03eb619e46...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (WFLY-13898) Bootable JAR/Galleon - HTTP 500 is returned by some RESTEasy tests
by Fabio Burzigotti (Jira)
[ https://issues.redhat.com/browse/WFLY-13898?page=com.atlassian.jira.plugi... ]
Fabio Burzigotti commented on WFLY-13898:
-----------------------------------------
BTW [~jfdenise] - I can see several more tests failing due to missing modules, e.g.: {{org.jboss.resteasy.resteasy-rxjava2}}, {{org.bouncycastle}}. By any chance are those failures related to the same chained dependencies issue that you explained?
> Bootable JAR/Galleon - HTTP 500 is returned by some RESTEasy tests
> ------------------------------------------------------------------
>
> Key: WFLY-13898
> URL: https://issues.redhat.com/browse/WFLY-13898
> Project: WildFly
> Issue Type: Task
> Components: Build System
> Affects Versions: 21.0.0.Beta1
> Reporter: Fabio Burzigotti
> Assignee: Jean Francois Denise
> Priority: Blocker
>
> I set the component to {{Build System}} because this only happens with Bootable JAR and - as [~jdenise] noticed - it's related with Galleon.
> This is about some tests in the RESTEasy TS which has been adapted to execute against bootable JARs through a specific profile [1].
> The tests are running successfully with WildFly 20.0.1.Final (the {{ejb}} layer needs to be removed for this experiment to be run [2]) but fail against 21.0.0.Beta1, so it is a regression.
> Also, the tests are passing when the TS is executed against a distributed WildFly version, and only fail when the server is packaged via the {{wildfly-jar-maven-plugin}}.
> There are 108 tests failing but htis JIRA focuses on those failing because of the following error:
> {code}
> RESTEASY002005: Failed executing POST /all/a/z: org.jboss.resteasy.core.NoMessageBodyWriterFoundFailure: Could not find MessageBodyWriter for response object of type: org.jboss.resteasy.test.validation.resource.ValidationFoo of media type: application/xml;charset=UTF-8
> {code}
> hence I guess serialization issues when the request accept header is not {{application/json}}, e.g. {{org.jboss.resteasy.test.validation.ValidationTest}}
> *Steps to reproduce*:
> 1. clone https://github.com/fabiobrz/Resteasy/tree/bootable-jar-support
> 2. build RESTEasy:
> {code}
> $ mvn install -Dmaven.test.skip=true -Dmaven.repo.local=/home/my-local-repo
> {code}
> 3. run the test against WF 21.0.0.Beta1:
> {code}
> cd testsuite
> {code}
> {code}
> mvn clean verify -am -pl integration-tests -Dmaven.repo.local=/home/my-local-repo -Dserver.version=21.0.0.Beta1 -Dtest=org.jboss.resteasy.test.validation.ValidationTest
> {code}
> The test should *pass*
> 4. run the test against WF 21.0.0.Beta1 with bootable JAR:
> {code}
> mvn clean verify -am -pl integration-tests -Dmaven.repo.local=/home/my-local-repo -Dserver.version=21.0.0.Beta1 -Dtest=org.jboss.resteasy.test.validation.ValidationTest -Ddisable.microprofile.tests -Dserver.home=foo -Dts.bootable
> {code}
> The test should *fail*
> 5. run the test against WF 20.0.1.Final with bootable JAR:
> {code}
> mvn clean verify -am -pl integration-tests -Dmaven.repo.local=/home/my-local-repo -Dserver.version=20.0.1.Final -Dtest=org.jboss.resteasy.test.validation.ValidationTest -Ddisable.microprofile.tests -Dserver.home=foo -Dts.bootable
> {code}
> The test should *pass*
> [1]
> https://github.com/resteasy/Resteasy/pull/2526/files#diff-8c7ea03eb619e46...
> [2]
> https://github.com/resteasy/Resteasy/pull/2526/files#diff-8c7ea03eb619e46...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (JGRP-2501) Jgroup view not stabilized after upgrading from 3.4.3 to 4.0.10
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2501?page=com.atlassian.jira.plugin... ]
Bela Ban closed JGRP-2501.
--------------------------
Resolution: Rejected
Answered on the mailing list
> Jgroup view not stabilized after upgrading from 3.4.3 to 4.0.10
> ---------------------------------------------------------------
>
> Key: JGRP-2501
> URL: https://issues.redhat.com/browse/JGRP-2501
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.10
> Reporter: Ajay Sharma
> Assignee: Bela Ban
> Priority: Major
>
> Hi
> we have 15 node cluster after upgrading Jgroup from 3.4.3 to 4.0.10, system is unstable and keep getting below logs
> 2020-09-03 11:47:30.317 WARN org.jgroups.protocols.pbcast.GMS - vmc0198-27827: not member of view [vmc0208-48939|123]; discarding it
> 2020-09-03 11:47:32.316 WARN org.jgroups.protocols.pbcast.GMS - vmc0198-27827: failed to create view from delta-view; dropping view: java.lang.IllegalStateException: the view-id of the delta view ([vmc0208-48939|123]) doesn't match the current view-id ([vmc0208-48939|122]); discarding delta view [vmc0208-48939|124], ref-view=[vmc0208-48939|123], joined=[vmc0198-5504]
> 2020-09-03 11:47:32.323 WARN org.jgroups.protocols.pbcast.GMS - vmc0198-27827: not member of view [vmc0208-48939|124]; discarding it.
> 2020-09-03 11:49:07.160 WARN org.jgroups.protocols.pbcast.NAKACK2 - JGRP000011: vmc0198-63871: dropped message batch from non-member vmc0201-28703 (view=MergeView::[vmc0208-48939|140] (24) [ ***REMOVING MACHINE NAME AND PORT ***] ])
> 2020-09-03 11:49:07.160 WARN org.jgroups.protocols.pbcast.NAKACK2 - JGRP000011: vmc0198-23411: dropped message batch from non-member vmc0201-28703 (view=[***REMOVING MACHINE NAME AND PORT FOR CLEAR VIEW ***] .])
> 2020-09-05 16:16:07.380 DEBUG org.jgroups.protocols.FD_ALL - haven't received a heartbeat from vmc0201-55458 for 12541 ms, adding it to suspect list
> 2020-09-05 16:16:07.535 DEBUG org.jgroups.protocols.FD_SOCK - vmc0198-24881: failed connecting to vmc0204-45403: connect timed out
> 2020-09-05 16:16:07.536 DEBUG org.jgroups.protocols.FD_SOCK - vmc0198-24881: broadcasting suspect(vmc0204-45403)
> 2020-09-05 16:16:07.536 DEBUG org.jgroups.protocols.FD_SOCK - vmc0198-24881: pingable_mbrs=[***REMOVING MACHINE NAME AND PORT ***], ping_dest=vmc0204-54485
> 2020-09-05 16:16:08.513 DEBUG org.jgroups.protocols.pbcast.GMS - vmc0198-52842: installing view [ ***REMOVING MACHINE NAME AND PORT FOR CLEAR VIEW *** ]
> 2020-09-05 16:16:08.513 DEBUG org.jgroups.protocols.pbcast.GMS - vmc0198-24881: installing view [vmc0200-30543|2672] (184) [ ***REMOVING MACHINE NAME AND PORT FOR CLEAR VIEW *** ]
> ===================================
> To isolate the issue we have created a small program both in Jgroup 3.4.3 and Jgroups 4.0.10
> Both applications take IP addresses and the number of channels as arguments. We have run both applications in the following matrix and collected view data and timings.
> Below are the stats:
> Number of members (number of nodes x number of channels) Jgroups 3.4.3 Jgroup 4.0.10
> 225 (15x15) Simultaneous start 25 - 30 seconds* 15 minutes**
> 225 (15x15) Rolling start (view after 15th node start) 20 seconds* 10 minutes**
> 196 (14x14) Simultaneous start 25 seconds* 4 minutes**
> 169 (13x13) Simultaneous start 30 - 31 seconds* 7 minutes**
> 144 (12x12) Simultaneous start 27 seconds* 5 minutes**
> 121 (11x11) Simultaneous start 22 seconds* 2 minutes**
> 100 (10x10) Simultaneous start 20 seconds* 5 minutes**
> ...
> ...
> 9 to 49 channels (3x3) to (7x7) almost immediate* almost immediate*
> Note: Even after taking 15 minutes, views are not stable its keeps fluctuating.
> =======
> Below are my protocols used with properties:
> Protocol[] protocolStack={
> new UDP().setValue("bind_addr",InetAddress.getByName(myBindAddress)).setValue("mcast_port", 10600).setValue("bind_port", 10601)
> .setValue("port_range", 100).setValue("diagnostics_bind_interfaces", parInterfaceList).setValue("diagnostics_port", 10599),
> new PING(),
> new MERGE3(),
> new FD_SOCK().setValue("bind_addr", InetAddress.getByName(myBindAddress)),
> new FD_ALL().setValue("timeout", 12000).setValue("interval", 3000),
> new VERIFY_SUSPECT().setValue("bind_addr", InetAddress.getByName(myBindAddress)),
> new BARRIER(),
> new NAKACK2(),
> new UNICAST3(),
> new STABLE(),
> new GMS().setValue("print_local_addr", true),
> new UFC(),
> new MFC(),
> new FRAG2()};
> However, we tried to update below few properties value but no luck
> thread_pool_max_threads = 200 in UDP()
> Default values of FD_ALL()
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (WFLY-13898) Bootable JAR/Galleon - HTTP 500 is returned by some RESTEasy tests
by Fabio Burzigotti (Jira)
[ https://issues.redhat.com/browse/WFLY-13898?page=com.atlassian.jira.plugi... ]
Fabio Burzigotti commented on WFLY-13898:
-----------------------------------------
Thanks [~jdenise]! Please add a link to it once you have it filed.
> Bootable JAR/Galleon - HTTP 500 is returned by some RESTEasy tests
> ------------------------------------------------------------------
>
> Key: WFLY-13898
> URL: https://issues.redhat.com/browse/WFLY-13898
> Project: WildFly
> Issue Type: Task
> Components: Build System
> Affects Versions: 21.0.0.Beta1
> Reporter: Fabio Burzigotti
> Assignee: Jean Francois Denise
> Priority: Blocker
>
> I set the component to {{Build System}} because this only happens with Bootable JAR and - as [~jdenise] noticed - it's related with Galleon.
> This is about some tests in the RESTEasy TS which has been adapted to execute against bootable JARs through a specific profile [1].
> The tests are running successfully with WildFly 20.0.1.Final (the {{ejb}} layer needs to be removed for this experiment to be run [2]) but fail against 21.0.0.Beta1, so it is a regression.
> Also, the tests are passing when the TS is executed against a distributed WildFly version, and only fail when the server is packaged via the {{wildfly-jar-maven-plugin}}.
> There are 108 tests failing but htis JIRA focuses on those failing because of the following error:
> {code}
> RESTEASY002005: Failed executing POST /all/a/z: org.jboss.resteasy.core.NoMessageBodyWriterFoundFailure: Could not find MessageBodyWriter for response object of type: org.jboss.resteasy.test.validation.resource.ValidationFoo of media type: application/xml;charset=UTF-8
> {code}
> hence I guess serialization issues when the request accept header is not {{application/json}}, e.g. {{org.jboss.resteasy.test.validation.ValidationTest}}
> *Steps to reproduce*:
> 1. clone https://github.com/fabiobrz/Resteasy/tree/bootable-jar-support
> 2. build RESTEasy:
> {code}
> $ mvn install -Dmaven.test.skip=true -Dmaven.repo.local=/home/my-local-repo
> {code}
> 3. run the test against WF 21.0.0.Beta1:
> {code}
> cd testsuite
> {code}
> {code}
> mvn clean verify -am -pl integration-tests -Dmaven.repo.local=/home/my-local-repo -Dserver.version=21.0.0.Beta1 -Dtest=org.jboss.resteasy.test.validation.ValidationTest
> {code}
> The test should *pass*
> 4. run the test against WF 21.0.0.Beta1 with bootable JAR:
> {code}
> mvn clean verify -am -pl integration-tests -Dmaven.repo.local=/home/my-local-repo -Dserver.version=21.0.0.Beta1 -Dtest=org.jboss.resteasy.test.validation.ValidationTest -Ddisable.microprofile.tests -Dserver.home=foo -Dts.bootable
> {code}
> The test should *fail*
> 5. run the test against WF 20.0.1.Final with bootable JAR:
> {code}
> mvn clean verify -am -pl integration-tests -Dmaven.repo.local=/home/my-local-repo -Dserver.version=20.0.1.Final -Dtest=org.jboss.resteasy.test.validation.ValidationTest -Ddisable.microprofile.tests -Dserver.home=foo -Dts.bootable
> {code}
> The test should *pass*
> [1]
> https://github.com/resteasy/Resteasy/pull/2526/files#diff-8c7ea03eb619e46...
> [2]
> https://github.com/resteasy/Resteasy/pull/2526/files#diff-8c7ea03eb619e46...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years