[JBoss JIRA] (DROOLS-5108) KieHelper.build is very slow on Drools 6.4.0.Final
by Ravi M (Jira)
Ravi M created DROOLS-5108:
------------------------------
Summary: KieHelper.build is very slow on Drools 6.4.0.Final
Key: DROOLS-5108
URL: https://issues.redhat.com/browse/DROOLS-5108
Project: Drools
Issue Type: Bug
Components: core engine
Reporter: Ravi M
Assignee: Mario Fusco
Tried build with 230 rules, it is taking nearly 10 seconds
{code:java}
org.kie.internal.utils.KieHelper kieHelper = new org.kie.internal.utils.KieHelper();
kieHelper.setClassLoader(this.getClass().getClassLoader());
kieHelper.addContent( drlContent, ResourceType.DRL );
Results res = kieHelper.verify();
if ( res.hasMessages( Message.Level.ERROR ) ) {
throw new DroolsCompilationException("Exception while compiling rule ");
}
if ( kbConf == null ) {
kbConf = KieServices.Factory.get().newKieBaseConfiguration();
}
kbConf.setOption( EqualityBehaviorOption.EQUALITY );
KieBase kieBase = kieHelper.build( kbConf );
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (WFLY-13152) WFLYEJB0094: EJB 3.1 FR 5.4.2 MessageDrivenBean does not implement 1 interface nor specifies message listener interface
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13152?page=com.atlassian.jira.plugi... ]
Cheng Fang commented on WFLY-13152:
-----------------------------------
My proposal is to modify [MessageDrivenComponentDescriptionFactory|https://github.com/wildfly/wildf...] to search the super class {{ClassInfo}} in parent module, after failing to find it in the current module. As we've already got a non-null {{superClassDotName}}, so the super class must exist somewhere. Doing nothing after failing to find super class {{ClassInfo}} in current module is not right. I'll try it out and send the PR if it works.
> WFLYEJB0094: EJB 3.1 FR 5.4.2 MessageDrivenBean does not implement 1 interface nor specifies message listener interface
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13152
> URL: https://issues.redhat.com/browse/WFLY-13152
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 17.0.1.Final
> Reporter: Rhuan Rocha
> Assignee: Cheng Fang
> Priority: Major
> Attachments: lib.zip, samplemdbear.zip
>
>
> The MDB does not works when it extends a superclass that comes from an external JAR and this super class implements the MessageListener. It generates this exception:
> {code:java}
> WFLYEJB0094: EJB 3.1 FR 5.4.2 MessageDrivenBean com.exemple.MyMDB does not implement 1 interface nor specifies message listener interface
> {code}
> These are what I have noted:
> * It only happens in a EAR project. In a WAR project it works fine.
> * It only happens when the abstract class come from an external JAR
> * If the sub class implements directly the MessageListener or if the messageListenerInterface is defined in the annotation it works fine.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (DROOLS-5107) A rule always fires with executable model for a constraint which has extra parentheses
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5107?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi updated DROOLS-5107:
--------------------------------------
Sprint: 2020 Week 07-09 (from Feb 10)
> A rule always fires with executable model for a constraint which has extra parentheses
> --------------------------------------------------------------------------------------
>
> Key: DROOLS-5107
> URL: https://issues.redhat.com/browse/DROOLS-5107
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.33.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> When you have a constraint with extra parentheses,
> {noformat}
> $p : Person((age > 30))
> {noformat}
> executable-model generates a pattern without a constraint expr method so it always fires.
> {code:java}
> public static org.drools.model.Rule rule_R() {
> final org.drools.model.Variable<org.drools.modelcompiler.domain.Person> var_$p = D.declarationOf(org.drools.modelcompiler.domain.Person.class, DomainClassesMetadataFBDA1ED637C8B60C741C0BDB502EB8F0.org_drools_modelcompiler_domain_Person_Metadata_INSTANCE, "$p");
> org.drools.model.Rule rule = D.rule("R").build(D.pattern(var_$p),
> D.execute(() -> {
> {
> }
> }));
> return rule;
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (DROOLS-5107) A rule always fires with executable model for a constraint which has extra parentheses
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5107?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi reassigned DROOLS-5107:
-----------------------------------------
Assignee: Toshiya Kobayashi (was: Luca Molteni)
> A rule always fires with executable model for a constraint which has extra parentheses
> --------------------------------------------------------------------------------------
>
> Key: DROOLS-5107
> URL: https://issues.redhat.com/browse/DROOLS-5107
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.33.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> When you have a constraint with extra parentheses,
> {noformat}
> $p : Person((age > 30))
> {noformat}
> executable-model generates a pattern without a constraint expr method so it always fires.
> {code:java}
> public static org.drools.model.Rule rule_R() {
> final org.drools.model.Variable<org.drools.modelcompiler.domain.Person> var_$p = D.declarationOf(org.drools.modelcompiler.domain.Person.class, DomainClassesMetadataFBDA1ED637C8B60C741C0BDB502EB8F0.org_drools_modelcompiler_domain_Person_Metadata_INSTANCE, "$p");
> org.drools.model.Rule rule = D.rule("R").build(D.pattern(var_$p),
> D.execute(() -> {
> {
> }
> }));
> return rule;
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (DROOLS-5107) A rule always fires with executable model for a constraint which has extra parentheses
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5107?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi updated DROOLS-5107:
--------------------------------------
Story Points: 3
> A rule always fires with executable model for a constraint which has extra parentheses
> --------------------------------------------------------------------------------------
>
> Key: DROOLS-5107
> URL: https://issues.redhat.com/browse/DROOLS-5107
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.33.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> When you have a constraint with extra parentheses,
> {noformat}
> $p : Person((age > 30))
> {noformat}
> executable-model generates a pattern without a constraint expr method so it always fires.
> {code:java}
> public static org.drools.model.Rule rule_R() {
> final org.drools.model.Variable<org.drools.modelcompiler.domain.Person> var_$p = D.declarationOf(org.drools.modelcompiler.domain.Person.class, DomainClassesMetadataFBDA1ED637C8B60C741C0BDB502EB8F0.org_drools_modelcompiler_domain_Person_Metadata_INSTANCE, "$p");
> org.drools.model.Rule rule = D.rule("R").build(D.pattern(var_$p),
> D.execute(() -> {
> {
> }
> }));
> return rule;
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (DROOLS-5107) A rule always fires with executable model for a constraint which has extra parentheses
by Toshiya Kobayashi (Jira)
Toshiya Kobayashi created DROOLS-5107:
-----------------------------------------
Summary: A rule always fires with executable model for a constraint which has extra parentheses
Key: DROOLS-5107
URL: https://issues.redhat.com/browse/DROOLS-5107
Project: Drools
Issue Type: Bug
Components: executable model
Affects Versions: 7.33.0.Final
Reporter: Toshiya Kobayashi
Assignee: Luca Molteni
When you have a constraint with extra parentheses,
{noformat}
$p : Person((age > 30))
{noformat}
executable-model generates pattern without constraint expr method so it always fires.
{code:java}
public static org.drools.model.Rule rule_R() {
final org.drools.model.Variable<org.drools.modelcompiler.domain.Person> var_$p = D.declarationOf(org.drools.modelcompiler.domain.Person.class, DomainClassesMetadataFBDA1ED637C8B60C741C0BDB502EB8F0.org_drools_modelcompiler_domain_Person_Metadata_INSTANCE, "$p");
org.drools.model.Rule rule = D.rule("R").build(D.pattern(var_$p),
D.execute(() -> {
{
}
}));
return rule;
}
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (DROOLS-5107) A rule always fires with executable model for a constraint which has extra parentheses
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5107?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi updated DROOLS-5107:
--------------------------------------
Description:
When you have a constraint with extra parentheses,
{noformat}
$p : Person((age > 30))
{noformat}
executable-model generates a pattern without a constraint expr method so it always fires.
{code:java}
public static org.drools.model.Rule rule_R() {
final org.drools.model.Variable<org.drools.modelcompiler.domain.Person> var_$p = D.declarationOf(org.drools.modelcompiler.domain.Person.class, DomainClassesMetadataFBDA1ED637C8B60C741C0BDB502EB8F0.org_drools_modelcompiler_domain_Person_Metadata_INSTANCE, "$p");
org.drools.model.Rule rule = D.rule("R").build(D.pattern(var_$p),
D.execute(() -> {
{
}
}));
return rule;
}
{code}
was:
When you have a constraint with extra parentheses,
{noformat}
$p : Person((age > 30))
{noformat}
executable-model generates pattern without constraint expr method so it always fires.
{code:java}
public static org.drools.model.Rule rule_R() {
final org.drools.model.Variable<org.drools.modelcompiler.domain.Person> var_$p = D.declarationOf(org.drools.modelcompiler.domain.Person.class, DomainClassesMetadataFBDA1ED637C8B60C741C0BDB502EB8F0.org_drools_modelcompiler_domain_Person_Metadata_INSTANCE, "$p");
org.drools.model.Rule rule = D.rule("R").build(D.pattern(var_$p),
D.execute(() -> {
{
}
}));
return rule;
}
{code}
> A rule always fires with executable model for a constraint which has extra parentheses
> --------------------------------------------------------------------------------------
>
> Key: DROOLS-5107
> URL: https://issues.redhat.com/browse/DROOLS-5107
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.33.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Luca Molteni
> Priority: Major
>
> When you have a constraint with extra parentheses,
> {noformat}
> $p : Person((age > 30))
> {noformat}
> executable-model generates a pattern without a constraint expr method so it always fires.
> {code:java}
> public static org.drools.model.Rule rule_R() {
> final org.drools.model.Variable<org.drools.modelcompiler.domain.Person> var_$p = D.declarationOf(org.drools.modelcompiler.domain.Person.class, DomainClassesMetadataFBDA1ED637C8B60C741C0BDB502EB8F0.org_drools_modelcompiler_domain_Person_Metadata_INSTANCE, "$p");
> org.drools.model.Rule rule = D.rule("R").build(D.pattern(var_$p),
> D.execute(() -> {
> {
> }
> }));
> return rule;
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (WFLY-13152) WFLYEJB0094: EJB 3.1 FR 5.4.2 MessageDrivenBean does not implement 1 interface nor specifies message listener interface
by Rhuan Rocha (Jira)
[ https://issues.redhat.com/browse/WFLY-13152?page=com.atlassian.jira.plugi... ]
Rhuan Rocha edited comment on WFLY-13152 at 2/25/20 11:38 AM:
--------------------------------------------------------------
[~cfang] About the WAR, I have packaged the application via Maven and I have used the external jar in both.
{color:#403294}MessageDrivenComponentDescriptionFactory does check for the interface implemented by the super class of the bean class, but when the super class is not in the current module, the ClassInfo is not found in the current CompositeIndex:{color}
I agreed. I have made tests in my local environment and I have noted it has many CompositeIndex instance and looks like it creates one instance per module. When the code search by interface information it is searching in a wrong instance. I have seen one of these instance has the correct information. I could not find the local in code that it select the CompositeIndex instance.
was (Author: rhn-support-rhsilva):
[~cfang] About the WAR, I have packaged the application via Maven and I have used the external jar in both.
{color:#DE350B}MessageDrivenComponentDescriptionFactory does check for the interface implemented by the super class of the bean class, but when the super class is not in the current module, the ClassInfo is not found in the current CompositeIndex:{color}
I agreed. I have made tests in my local environment and I have noted it has many CompositeIndex instance and looks like it creates one instance per module. When the code search by interface information it is searching in a wrong instance. I have seen one of these instance has the correct information. I could not find the local in code that it select the CompositeIndex instance.
> WFLYEJB0094: EJB 3.1 FR 5.4.2 MessageDrivenBean does not implement 1 interface nor specifies message listener interface
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13152
> URL: https://issues.redhat.com/browse/WFLY-13152
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 17.0.1.Final
> Reporter: Rhuan Rocha
> Assignee: Cheng Fang
> Priority: Major
> Attachments: lib.zip, samplemdbear.zip
>
>
> The MDB does not works when it extends a superclass that comes from an external JAR and this super class implements the MessageListener. It generates this exception:
> {code:java}
> WFLYEJB0094: EJB 3.1 FR 5.4.2 MessageDrivenBean com.exemple.MyMDB does not implement 1 interface nor specifies message listener interface
> {code}
> These are what I have noted:
> * It only happens in a EAR project. In a WAR project it works fine.
> * It only happens when the abstract class come from an external JAR
> * If the sub class implements directly the MessageListener or if the messageListenerInterface is defined in the annotation it works fine.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (WFLY-13152) WFLYEJB0094: EJB 3.1 FR 5.4.2 MessageDrivenBean does not implement 1 interface nor specifies message listener interface
by Rhuan Rocha (Jira)
[ https://issues.redhat.com/browse/WFLY-13152?page=com.atlassian.jira.plugi... ]
Rhuan Rocha commented on WFLY-13152:
------------------------------------
[~cfang] About the WAR, I have packaged the application via Maven and I have used the external jar in both.
{color:#DE350B}MessageDrivenComponentDescriptionFactory does check for the interface implemented by the super class of the bean class, but when the super class is not in the current module, the ClassInfo is not found in the current CompositeIndex:{color}
I agreed. I have made tests in my local environment and I have noted it has many CompositeIndex instance and looks like it creates one instance per module. When the code search by interface information it is searching in a wrong instance. I have seen one of these instance has the correct information. I could not find the local in code that it select the CompositeIndex instance.
> WFLYEJB0094: EJB 3.1 FR 5.4.2 MessageDrivenBean does not implement 1 interface nor specifies message listener interface
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13152
> URL: https://issues.redhat.com/browse/WFLY-13152
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 17.0.1.Final
> Reporter: Rhuan Rocha
> Assignee: Cheng Fang
> Priority: Major
> Attachments: lib.zip, samplemdbear.zip
>
>
> The MDB does not works when it extends a superclass that comes from an external JAR and this super class implements the MessageListener. It generates this exception:
> {code:java}
> WFLYEJB0094: EJB 3.1 FR 5.4.2 MessageDrivenBean com.exemple.MyMDB does not implement 1 interface nor specifies message listener interface
> {code}
> These are what I have noted:
> * It only happens in a EAR project. In a WAR project it works fine.
> * It only happens when the abstract class come from an external JAR
> * If the sub class implements directly the MessageListener or if the messageListenerInterface is defined in the annotation it works fine.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (WFLY-13127) NPE in OpenApiAnnotationScanner when OpenTracing TCK war is deployed
by Ken Finnigan (Jira)
[ https://issues.redhat.com/browse/WFLY-13127?page=com.atlassian.jira.plugi... ]
Ken Finnigan commented on WFLY-13127:
-------------------------------------
[~pferraro] it's available -> https://repo1.maven.org/maven2/io/smallrye/smallrye-open-api/1.1.21/
> NPE in OpenApiAnnotationScanner when OpenTracing TCK war is deployed
> --------------------------------------------------------------------
>
> Key: WFLY-13127
> URL: https://issues.redhat.com/browse/WFLY-13127
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenAPI, MP OpenTracing
> Affects Versions: 19.0.0.Beta2
> Reporter: Brian Stansberry
> Assignee: Paul Ferraro
> Priority: Blocker
> Fix For: 19.0.0.Beta3, 20.0.0.Beta1
>
>
> I tried running the microprofile-tck/opentracing tests against a config that included the OpenAPI subsystem. It failed with an NPE:
> {code}
> 2020-02-18 16:36:53,302 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location /Users/bstansberry/dev/wildfly/wildfly/testsuite/integration/microprofile-tck/opentracing/target/wildfly/standalone/data/content/85/48e223eb8bfcd73f66458e14a0bbc425998a70/content
> 2020-02-18 16:36:53,313 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0027: Starting deployment of "opentracing.war" (runtime-name: "opentracing.war")
> 2020-02-18 16:36:54,020 INFO [org.jboss.weld.deployer] (MSC service thread 1-7) WFLYWELD0003: Processing weld deployment opentracing.war
> 2020-02-18 16:36:54,114 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-7) HV000001: Hibernate Validator 6.0.18.Final
> 2020-02-18 16:36:54,330 INFO [org.jboss.weld.Version] (MSC service thread 1-8) WELD-000900: 3.1.3 (Final)
> 2020-02-18 16:36:54,576 INFO [io.smallrye.metrics] (MSC service thread 1-5) MicroProfile: Metrics activated (SmallRye Metrics version: 2.4.0)
> 2020-02-18 16:36:54,992 WARN [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0101: Duplicate servlet mapping /rest/* found
> 2020-02-18 16:36:55,173 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service org.wildfly.undertow.host.default-server.default-host./openapi: org.jboss.msc.service.StartException in service org.wildfly.undertow.host.default-server.default-host./openapi: java.lang.NullPointerException
> at org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:66)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.createResponseFromJaxRsMethod(OpenApiAnnotationScanner.java:934)
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsMethod(OpenApiAnnotationScanner.java:688)
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.lambda$processJaxRsResourceClass$0(OpenApiAnnotationScanner.java:422)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1556)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsResourceClass(OpenApiAnnotationScanner.java:420)
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.scan(OpenApiAnnotationScanner.java:221)
> at io.smallrye.openapi.runtime.OpenApiProcessor.modelFromAnnotations(OpenApiProcessor.java:72)
> at org.wildfly.extension.microprofile.openapi.deployment.OpenAPIModelServiceConfigurator.get(OpenAPIModelServiceConfigurator.java:173)
> at org.wildfly.extension.microprofile.openapi.deployment.OpenAPIModelServiceConfigurator.get(OpenAPIModelServiceConfigurator.java:94)
> at org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:63)
> ... 8 more
> {code}
> I hit this when working on WFLY-13099. I was using a standalone.xml variant equivalent to what Galleon would generate using the cloud-server, h2-default-datasource, microprofile-fault-tolerance, microprofile-jwt and microprofile-openapi layers. It wasn't a slimmed server though.
> OpenApiAnnotationScanner L934 seems to assume 'schema' will not be null. But the 'SchemaFactory.typeToSchema' method seems like it's written such that returning null is a possibility; e.g. L362 in the final 'else' block is doing a null check on the 'schema' var whose value is ultimately returned. (I don't see how else the NPE would happen other than SchemaFactory.typeToSchema returning null.)
>
> I put Critical severity on this because I don't know anything about opentracing.war; i.e. whether it's written in a way that would be a real corner case for OpenAPI. I'm being conservative and assigning a high priority.
> [~ehugonnet] FYI.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months