[JBoss JIRA] (WFLY-5966) Validate requirement for modules previously exported by javax.ejb.api
by Yeray Borges Santana (Jira)
[ https://issues.redhat.com/browse/WFLY-5966?page=com.atlassian.jira.plugin... ]
Yeray Borges Santana commented on WFLY-5966:
--------------------------------------------
I've reviewed the previously exported dependencies of {{javaee.api}} module:
{code:xml}
<module name="javax.xml.rpc.api" export="true"/>
<module name="org.omg.api" export="true"/>
{code}
The first one is the Java API for XML-Based RPC (JAX-RPC), which is an optional specification for Jakarta EE, but we will keep it in.
The second one includes support for interoperability using CORBA. My understanding is this is also optional now, but anyway we will keep it in the {{javaee.api}} module.
WFCORE-4621 will remove the no longer needed comments that suggested the review of these modules on {{javaee.api}}
> Validate requirement for modules previously exported by javax.ejb.api
> ---------------------------------------------------------------------
>
> Key: WFLY-5966
> URL: https://issues.redhat.com/browse/WFLY-5966
> Project: WildFly
> Issue Type: Task
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Yeray Borges Santana
> Priority: Major
> Fix For: 18.0.0.Beta1, 18.0.0.Final
>
>
> The WFLY-5922 fix removed the exporting of a number of modules from javax.ejb.api. That introduced some problems with modules that depended on those exported packages no longer having visibility to needed classes, so to prevent problems I blindly added a commit to the module.xml for each module that depended upon javax.ejb.api to add a dependency set like this:
> {code}
> <!-- TODO validate the need for these and remove if not needed.
> Prior to WFLY-5922 they were exported by javax.ejb.api. -->
> <module name="javax.api"/>
> <module name="javax.transaction.api"/>
> <module name="javax.xml.rpc.api"/>
> <module name="javax.rmi.api"/>
> <module name="org.omg.api"/>
> {code}
> If a module already had a dep on one of those, it's not in the block.
> This task is to check each of these modules and replace that block with normal dependency declarations for any that are truly needed.
> Affected modules:
> -feature-pack/src/main/resources/modules/system/layers/base/javax/management/j2ee/api/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/ejb3/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jsr77/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/webservices/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/weld/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/xts/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb-client/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb3/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/iiop-client/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/appclient/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/ejb/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/compensations/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/rts/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/txframework/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/weld/core/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ws/common/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/xts/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/rts/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/spi/main/module.xml-
> feature-pack/src/main/resources/modules/system/layers/base/javaee/api/main/module.xml
> The following modules were indirectly affected via their dependency on javaee.api, which in turn exports javax.ejb.api:
> -feature-pack/src/main/resources/modules/system/layers/base/org/jberet/jberet-core/main/module.xml-
> -jsf/multi-jsf-installer/src/main/resources/mojarra-impl-module.xml-
> -jsf/multi-jsf-installer/src/main/resources/myfaces-impl-module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/com/sun/jsf-impl/main/module.xml-
> -jsf/subsystem/src/test/resources/modules/com/sun/jsf-impl/main/module.xml-
> -jsf/subsystem/src/test/resources/modules/com/sun/jsf-impl/myfaces/module.xml-
> -jsf/subsystem/src/test/resources/modules2/com/sun/jsf-impl/myfaces2/module.xml-
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (DROOLS-5113) Allow kie-benchmark Drools compilation benchmark to run with 10000 rules on Java 8
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-5113?page=com.atlassian.jira.plug... ]
Luca Molteni updated DROOLS-5113:
---------------------------------
Summary: Allow kie-benchmark Drools compilation benchmark to run with 10000 rules on Java 8 (was: Do not compile exec model classes in RAM)
> Allow kie-benchmark Drools compilation benchmark to run with 10000 rules on Java 8
> ----------------------------------------------------------------------------------
>
> Key: DROOLS-5113
> URL: https://issues.redhat.com/browse/DROOLS-5113
> Project: Drools
> Issue Type: Enhancement
> Components: executable model
> Reporter: Luca Molteni
> Assignee: Luca Molteni
> Priority: Major
>
> Currently executable model classes are compiled in RAM
> at org.drools.compiler.commons.jci.compilers.AbstractJavaCompiler.compile(AbstractJavaCompiler.java:49)
> at org.drools.modelcompiler.builder.CanonicalModelKieProject.writeProjectOutput(CanonicalModelKieProject.java:81)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:285)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:247)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:204)
> This kie-benchmark fails when running with 10000 rules with the exec model and the lambda externalization activated
> mvn clean install -DskipTests=true && java -jar ./target/drools-benchmarks.jar -jvmArgs "-Xms10000m -Xmx10000m -Ddrools.externaliseCanonicalModelLambda=true -XX:+UseG1GC -XX:MetaspaceSize=1000m -XX:MaxMetaspaceSize=1000m -XX:+PrintGCDetails -Xloggc:/tmp/g1-dedup-metaspace4-maxpause.log" -foe true -rf csv -rff results.csv org.drools.benchmarks.turtle.buildtime.BuildKieBaseFromContainerBenchmark
> Probably we could start bringing the benchmark code into Drools so that we can debug it with idea (in JMH you can't) with the OpenJDK source code attached
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (DROOLS-5113) Do not compile exec model classes in RAM
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-5113?page=com.atlassian.jira.plug... ]
Luca Molteni updated DROOLS-5113:
---------------------------------
Sprint: 2020 Week 10-12 (from Mar 2)
> Do not compile exec model classes in RAM
> ----------------------------------------
>
> Key: DROOLS-5113
> URL: https://issues.redhat.com/browse/DROOLS-5113
> Project: Drools
> Issue Type: Enhancement
> Components: executable model
> Reporter: Luca Molteni
> Assignee: Luca Molteni
> Priority: Major
>
> Currently executable model classes are compiled in RAM
> at org.drools.compiler.commons.jci.compilers.AbstractJavaCompiler.compile(AbstractJavaCompiler.java:49)
> at org.drools.modelcompiler.builder.CanonicalModelKieProject.writeProjectOutput(CanonicalModelKieProject.java:81)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:285)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:247)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:204)
> This kie-benchmark fails when running with 10000 rules with the exec model and the lambda externalization activated
> mvn clean install -DskipTests=true && java -jar ./target/drools-benchmarks.jar -jvmArgs "-Xms10000m -Xmx10000m -Ddrools.externaliseCanonicalModelLambda=true -XX:+UseG1GC -XX:MetaspaceSize=1000m -XX:MaxMetaspaceSize=1000m -XX:+PrintGCDetails -Xloggc:/tmp/g1-dedup-metaspace4-maxpause.log" -foe true -rf csv -rff results.csv org.drools.benchmarks.turtle.buildtime.BuildKieBaseFromContainerBenchmark
> Probably we could start bringing the benchmark code into Drools so that we can debug it with idea (in JMH you can't) with the OpenJDK source code attached
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFCORE-4621) Create a service to install a dynamic 'wildflyee.api' module
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFCORE-4621?page=com.atlassian.jira.plug... ]
Brian Stansberry commented on WFCORE-4621:
------------------------------------------
[~yersan] Per [1] passive+ pulls in optional dependencies but if there is some subtlety due to how packages are created for JBoss Modules modules, then that is fine, a static module can work. TBH since filing this I've sometimes felt what Galleon was doing wasn't matching what I expected for passive+ (i.e. it provisioned less than I expected, which was good) so probably what you describe is why that was the case.
As long as what you suggest works it is fine. And yes if a user slims the server but their app depends on an API they slimmed away, that is an error on their part.
[1] https://docs.wildfly.org/galleon/#_feature_pack_original_effective_packag...
> Create a service to install a dynamic 'wildflyee.api' module
> ------------------------------------------------------------
>
> Key: WFCORE-4621
> URL: https://issues.redhat.com/browse/WFCORE-4621
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Yeray Borges Santana
> Priority: Minor
>
> Follow up on WFCORE-4612 by removing the list of detailed optional dependencies added there and instead have a service that installs a dynamic 'wildflyee.api' module that optional depends on all those. Then ExternalModuleDependencySpecService would add a dependency on that 'wildflyee.api' module.
> Then the next step is the javaee.api module in full WildFly would become an alias to wildflyee.api.
> The benefit to this is the content set for this 'ee.api' convenience module
> a) gets set in one place (vs the two places that WFCORE-4612 introduces)
> b) is defined in core, which makes some sense as core utilizes the module for the ExternalModuleDependencySpecService use case.
> c) External uses of 'javaee.api' can benefit from the WFCORE-4612 improvement; i.e. if they have slimmed the server such that some APIs are not present, javaee.api can still be used. They just can't be using any APIs that they slimmed away.
> A downside is maintaining an 'ee.api' modules is not a great fit for core.
> The reason to use a dynamic module is a static module would be visible to Galleon, and with the standard passive+[1] provisioning scheme we use that would lead to Galleon provisioning the packages for all the EE APIs, regardless of whether the server config required them.
> [1] https://docs.wildfly.org/galleon/#_effective_package_set
> This is somewhat me brainstorming, so needs harder thought.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (DROOLS-5119) Workbench int value turns into 0.0 in drl
by Bhala Hadkar (Jira)
[ https://issues.redhat.com/browse/DROOLS-5119?page=com.atlassian.jira.plug... ]
Bhala Hadkar commented on DROOLS-5119:
--------------------------------------
Yes it is a BigDecimal
public class Order {
private BigDecimal originalQuantity;
> Workbench int value turns into 0.0 in drl
> -----------------------------------------
>
> Key: DROOLS-5119
> URL: https://issues.redhat.com/browse/DROOLS-5119
> Project: Drools
> Issue Type: Bug
> Components: Examples (Workbench)
> Affects Versions: 7.34.0.Final
> Reporter: Bhala Hadkar
> Assignee: Michael Anstis
> Priority: Major
> Attachments: Workbench-Guided-Rule.png, drools.png
>
>
> When I set up a Guided rule on Workbench having a comparison condition on one of the domain field of type int then the int value entered through literal text disappears and turns into 0.0B.
> For e.g. if you look at this Guided Rule screenshot the literal value 100 turned into 0.0.
> !Workbench-Guided-Rule.png|thumbnail!
> Also in the drools the value becomes 0.0B.
> !drools.png|thumbnail!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (DROOLS-5119) Workbench int value turns into 0.0 in drl
by Michael Anstis (Jira)
[ https://issues.redhat.com/browse/DROOLS-5119?page=com.atlassian.jira.plug... ]
Michael Anstis commented on DROOLS-5119:
----------------------------------------
Can you provide your Java class too?
If a number has {{B}} appended it is usually because you have MVEL dialect and a {{BigDecimal}}.
> Workbench int value turns into 0.0 in drl
> -----------------------------------------
>
> Key: DROOLS-5119
> URL: https://issues.redhat.com/browse/DROOLS-5119
> Project: Drools
> Issue Type: Bug
> Components: Examples (Workbench)
> Affects Versions: 7.34.0.Final
> Reporter: Bhala Hadkar
> Assignee: Michael Anstis
> Priority: Major
> Attachments: Workbench-Guided-Rule.png, drools.png
>
>
> When I set up a Guided rule on Workbench having a comparison condition on one of the domain field of type int then the int value entered through literal text disappears and turns into 0.0B.
> For e.g. if you look at this Guided Rule screenshot the literal value 100 turned into 0.0.
> !Workbench-Guided-Rule.png|thumbnail!
> Also in the drools the value becomes 0.0B.
> !drools.png|thumbnail!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months