[JBoss JIRA] (WFLY-12798) Using Smallrye HealthChecks in RequestScoped Beans
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFLY-12798?page=com.atlassian.jira.plugin... ]
Jeff Mesnil commented on WFLY-12798:
------------------------------------
WildFly 18 updates its MP Health integration to use managed CDI Beans (in https://issues.jboss.org/browse/WFLY-12557).
However the HTTP endpoint that provide the health check is not setup to work with CDI and there is no @RequestScoped context support active.
The workaround you propose is fine to use another context.
I also need to check the feasibility of supporting the @RequestScoped context on WildFly HTTP management endpoints.
> Using Smallrye HealthChecks in RequestScoped Beans
> --------------------------------------------------
>
> Key: WFLY-12798
> URL: https://issues.jboss.org/browse/WFLY-12798
> Project: WildFly
> Issue Type: Bug
> Components: MP Health
> Affects Versions: 18.0.0.Final
> Reporter: Florian Sailer
> Assignee: Jeff Mesnil
> Priority: Major
>
> 2019-11-15 15:26:11,717 ERROR [org.wildfly.extension.microprofile.health.smallrye] (management I/O-1) Error processing Health Checks: org.jboss.weld.contexts.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped
> at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:647)
> at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:89)
> at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:164)
> at org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
> at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:87)
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:131)
> at at.arz.bpe.boundary.PingCheck$Proxy$_$$_WeldClientProxy.call(Unknown Source)
> at org.wildfly.extension.microprofile.health.HealthReporter.jsonObject(HealthReporter.java:120)
> at org.wildfly.extension.microprofile.health.HealthReporter.fillCheck(HealthReporter.java:107)
> at org.wildfly.extension.microprofile.health.HealthReporter.processChecks(HealthReporter.java:96)
> at org.wildfly.extension.microprofile.health.HealthReporter.getHealth(HealthReporter.java:79)
> at org.wildfly.extension.microprofile.health.HealthReporter.getHealth(HealthReporter.java:60)
> at org.wildfly.extension.microprofile.health.HealthContextService$HealthCheckHandler.handleRequest(HealthContextService.java:100)
> at org.jboss.as.domain.http.server.security.RealmReadinessHandler.handleRequest(RealmReadinessHandler.java:51)
> at org.jboss.as.domain.http.server.security.ServerErrorReadinessHandler.handleRequest(ServerErrorReadinessHandler.java:35)
> at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:91)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:211)
> at io.undertow.server.handlers.cache.CacheHandler.handleRequest(CacheHandler.java:92)
> at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:78)
> at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
> at org.jboss.as.domain.http.server.ManagementHttpRequestHandler.handleRequest(ManagementHttpRequestHandler.java:57)
> at org.jboss.as.domain.http.server.cors.CorsHttpHandler.handleRequest(CorsHttpHandler.java:75)
> at org.jboss.as.domain.http.server.ManagementHttpServer$UpgradeFixHandler.handleRequest(ManagementHttpServer.java:666)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:376)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:255)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:162)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:100)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:57)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:132)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:479)
> MP-Health Spec doesnt enforce a scope and it worked with wildfly 17.0.0.1-Final.
> https://github.com/eclipse/microprofile-health/issues/109
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (WFLY-12461) Can't use smallrye-health without weld extension
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFLY-12461?page=com.atlassian.jira.plugin... ]
Jeff Mesnil commented on WFLY-12461:
------------------------------------
Since the commit you mentioned, smallrye-health was updated to require CDI to inject the health checks.
WildFly followed that changes and required the Weld extension so that WildFly can consume health checks probes that uses CDI.
>From WildFly perspective, CDI is now required to use MicroProfile Health and the Weld integration is not optional.
I'm not sure what to suggest to fix your issue but there are 2 options:
* add a RFE to smallrye-health to make CDI optional again. I'm not sure it'd be accepted though as CDI is a 1st class citizen in MicroProfile and its use in smallrye-health is valid
* Fix the integration of Weld in org.apache.cxf.jaxrs.
> Can't use smallrye-health without weld extension
> ------------------------------------------------
>
> Key: WFLY-12461
> URL: https://issues.jboss.org/browse/WFLY-12461
> Project: WildFly
> Issue Type: Bug
> Components: MP Health
> Affects Versions: 17.0.1.Final
> Reporter: Florian Sailer
> Assignee: Jeff Mesnil
> Priority: Major
>
> Since this commit in the smallrye implementation it was possible to use smallrye without CDI.
> https://github.com/smallrye/smallrye-health/commit/a6a7812877d74d2c3f5b29...
> I'm trying to migrate from Wildfly 15.0.1-Final to 17.0.1-Final, where the smallrye-health extension unfortunately needs weld to startup. It's not possbible for me to activate weld on my sever, because there are some problems using the org.apache.cxf.jaxrs framework with weld.
> I am getting the following exception while starting:
> 14:16:04,960 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/subsystem=microprofile-health-smallrye' are not available:
> org.wildfly.weld; There are no known registration points which can provide this capability.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (WFWIP-160) Fix throughput and response time differences between TLS 1.2 and TLS 1.3
by Jan Stourac (Jira)
[ https://issues.jboss.org/browse/WFWIP-160?page=com.atlassian.jira.plugin.... ]
Jan Stourac commented on WFWIP-160:
-----------------------------------
Hi [~ropalka], I used simple standalone.sh with JDK11, like this:
{code}
$ JAVA_HOME=/path/to/java/openjdk-11.0.x <EAP_HOME>/bin/standalone.sh
{code}
I've also updated the reproduction steps section to explicitly include this part.
> Fix throughput and response time differences between TLS 1.2 and TLS 1.3
> ------------------------------------------------------------------------
>
> Key: WFWIP-160
> URL: https://issues.jboss.org/browse/WFWIP-160
> Project: WildFly WIP
> Issue Type: Task
> Components: Web (Undertow)
> Reporter: Farah Juma
> Assignee: Richard Opalka
> Priority: Blocker
> Attachments: jstourac-report.zip, results-tlsv12.zip, results-tlsv13.zip
>
>
> Performance with TLS 1.3 on WildFly appears to be worse than with TLS 1.2. In particular, throughput is much lower (roughly three times lower) and response time is much higher (roughly three times higher), which is not supposed to be the case. The underlying issue seems to be in Undertow or XNIO, that is the code that actually gets invoked during the TLS handshake process. Looking at CPU time, there is significantly more time being spent in [io.undertow.protocols.ssl.SslConduit$5.run()|https://github.com/undertow-...] with TLS 1.3 than with TLS 1.2.
> Steps to reproduce (taken from EAP7-1022):
> 1. Build WildFly using the following feature branches or download a QE build of WildFly [here|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/undertow-...]:
> https://github.com/fjuma/wildfly-elytron/tree/ELY-1706
> https://github.com/fjuma/wildfly-core/tree/WFCORE-4172 (Update the Elytron version in the pom.xml file to use the version built in the previous step)
> https://github.com/fjuma/wildfly/tree/WFCORE-4172 (Update the Core version in the pom.xml file to use the version built in the previous step)
> 2. Download and unzip JMeter from https://jmeter.apache.org/download_jmeter.cgi
> 3. Download attached test plan [TLSv1.3.jmx|https://issues.jboss.org/secure/attachment/12449098/12449098_...]
> 4. Start server with JDK11 and configure with TLSv1.3:
> {code}
> $ JAVA_HOME=/path/to/java/openjdk-11.0.2 <EAP_HOME>/bin/standalone.sh
> $ <EAP_HOME>/bin/jboss-cli.sh -c
> /subsystem=elytron/key-store=tls13:add(path=keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
> /subsystem=elytron/key-store=tls13:generate-key-pair(alias=localhost,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=localhost")
> /subsystem=elytron/key-store=tls13:store()
> /subsystem=elytron/key-manager=tls13:add(key-store=tls13,credential-reference={clear-text=secret})
> /subsystem=elytron/server-ssl-context=tls13:add(key-manager=tls13,protocols=["TLSv1.3"])
> batch
> /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
> /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=tls13)
> run-batch
> reload
> {code}
> 5. Start jmeter with JDK 11 and downloaded test plan
> {code}
> export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv13.log -o results-tlsv13
> {code}
> 6. Set server to use TLSv1.2
> {code}
> /subsystem=elytron/server-ssl-context=tls13:write-attribute(name=protocols,value=["TLSv1.2"])
> reload
> {code}
> 7. Repeat same for TLSv1.2
> {code}
> export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv12.log -o results-tlsv12
> {code}
> 8. Compare results (there will be an index.html file in the results-tlsv12 and results-tlsv13 directories)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (WFWIP-160) Fix throughput and response time differences between TLS 1.2 and TLS 1.3
by Jan Stourac (Jira)
[ https://issues.jboss.org/browse/WFWIP-160?page=com.atlassian.jira.plugin.... ]
Jan Stourac updated WFWIP-160:
------------------------------
Description:
Performance with TLS 1.3 on WildFly appears to be worse than with TLS 1.2. In particular, throughput is much lower (roughly three times lower) and response time is much higher (roughly three times higher), which is not supposed to be the case. The underlying issue seems to be in Undertow or XNIO, that is the code that actually gets invoked during the TLS handshake process. Looking at CPU time, there is significantly more time being spent in [io.undertow.protocols.ssl.SslConduit$5.run()|https://github.com/undertow-...] with TLS 1.3 than with TLS 1.2.
Steps to reproduce (taken from EAP7-1022):
1. Build WildFly using the following feature branches or download a QE build of WildFly [here|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/undertow-...]:
https://github.com/fjuma/wildfly-elytron/tree/ELY-1706
https://github.com/fjuma/wildfly-core/tree/WFCORE-4172 (Update the Elytron version in the pom.xml file to use the version built in the previous step)
https://github.com/fjuma/wildfly/tree/WFCORE-4172 (Update the Core version in the pom.xml file to use the version built in the previous step)
2. Download and unzip JMeter from https://jmeter.apache.org/download_jmeter.cgi
3. Download attached test plan [TLSv1.3.jmx|https://issues.jboss.org/secure/attachment/12449098/12449098_...]
4. Start server with JDK11 and configure with TLSv1.3:
{code}
$ JAVA_HOME=/path/to/java/openjdk-11.0.2 <EAP_HOME>/bin/standalone.sh
$ <EAP_HOME>/bin/jboss-cli.sh -c
/subsystem=elytron/key-store=tls13:add(path=keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
/subsystem=elytron/key-store=tls13:generate-key-pair(alias=localhost,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=localhost")
/subsystem=elytron/key-store=tls13:store()
/subsystem=elytron/key-manager=tls13:add(key-store=tls13,credential-reference={clear-text=secret})
/subsystem=elytron/server-ssl-context=tls13:add(key-manager=tls13,protocols=["TLSv1.3"])
batch
/subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=tls13)
run-batch
reload
{code}
5. Start jmeter with JDK 11 and downloaded test plan
{code}
export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv13.log -o results-tlsv13
{code}
6. Set server to use TLSv1.2
{code}
/subsystem=elytron/server-ssl-context=tls13:write-attribute(name=protocols,value=["TLSv1.2"])
reload
{code}
7. Repeat same for TLSv1.2
{code}
export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv12.log -o results-tlsv12
{code}
8. Compare results (there will be an index.html file in the results-tlsv12 and results-tlsv13 directories)
was:
Performance with TLS 1.3 on WildFly appears to be worse than with TLS 1.2. In particular, throughput is much lower (roughly three times lower) and response time is much higher (roughly three times higher), which is not supposed to be the case. The underlying issue seems to be in Undertow or XNIO, that is the code that actually gets invoked during the TLS handshake process. Looking at CPU time, there is significantly more time being spent in [io.undertow.protocols.ssl.SslConduit$5.run()|https://github.com/undertow-...] with TLS 1.3 than with TLS 1.2.
Steps to reproduce (taken from EAP7-1022):
1. Build WildFly using the following feature branches or download a QE build of WildFly [here|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/undertow-...]:
https://github.com/fjuma/wildfly-elytron/tree/ELY-1706
https://github.com/fjuma/wildfly-core/tree/WFCORE-4172 (Update the Elytron version in the pom.xml file to use the version built in the previous step)
https://github.com/fjuma/wildfly/tree/WFCORE-4172 (Update the Core version in the pom.xml file to use the version built in the previous step)
2. Download and unzip JMeter from https://jmeter.apache.org/download_jmeter.cgi
3. Download attached test plan [TLSv1.3.jmx|https://issues.jboss.org/secure/attachment/12449098/12449098_...]
4. Configure and start server with TLSv1.3 and JDK 11:
{code}
connect
/subsystem=elytron/key-store=tls13:add(path=keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
/subsystem=elytron/key-store=tls13:generate-key-pair(alias=localhost,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=localhost")
/subsystem=elytron/key-store=tls13:store()
/subsystem=elytron/key-manager=tls13:add(key-store=tls13,credential-reference={clear-text=secret})
/subsystem=elytron/server-ssl-context=tls13:add(key-manager=tls13,protocols=["TLSv1.3"])
batch
/subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=tls13)
run-batch
reload
{code}
5. Start jmeter with JDK 11 and downloaded test plan
{code}
export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv13.log -o results-tlsv13
{code}
6. Set server to use TLSv1.2
{code}
/subsystem=elytron/server-ssl-context=tls13:write-attribute(name=protocols,value=["TLSv1.2"])
reload
{code}
7. Repeat same for TLSv1.2
{code}
export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv12.log -o results-tlsv12
{code}
8. Compare results (there will be an index.html file in the results-tlsv12 and results-tlsv13 directories)
> Fix throughput and response time differences between TLS 1.2 and TLS 1.3
> ------------------------------------------------------------------------
>
> Key: WFWIP-160
> URL: https://issues.jboss.org/browse/WFWIP-160
> Project: WildFly WIP
> Issue Type: Task
> Components: Web (Undertow)
> Reporter: Farah Juma
> Assignee: Richard Opalka
> Priority: Blocker
> Attachments: jstourac-report.zip, results-tlsv12.zip, results-tlsv13.zip
>
>
> Performance with TLS 1.3 on WildFly appears to be worse than with TLS 1.2. In particular, throughput is much lower (roughly three times lower) and response time is much higher (roughly three times higher), which is not supposed to be the case. The underlying issue seems to be in Undertow or XNIO, that is the code that actually gets invoked during the TLS handshake process. Looking at CPU time, there is significantly more time being spent in [io.undertow.protocols.ssl.SslConduit$5.run()|https://github.com/undertow-...] with TLS 1.3 than with TLS 1.2.
> Steps to reproduce (taken from EAP7-1022):
> 1. Build WildFly using the following feature branches or download a QE build of WildFly [here|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/undertow-...]:
> https://github.com/fjuma/wildfly-elytron/tree/ELY-1706
> https://github.com/fjuma/wildfly-core/tree/WFCORE-4172 (Update the Elytron version in the pom.xml file to use the version built in the previous step)
> https://github.com/fjuma/wildfly/tree/WFCORE-4172 (Update the Core version in the pom.xml file to use the version built in the previous step)
> 2. Download and unzip JMeter from https://jmeter.apache.org/download_jmeter.cgi
> 3. Download attached test plan [TLSv1.3.jmx|https://issues.jboss.org/secure/attachment/12449098/12449098_...]
> 4. Start server with JDK11 and configure with TLSv1.3:
> {code}
> $ JAVA_HOME=/path/to/java/openjdk-11.0.2 <EAP_HOME>/bin/standalone.sh
> $ <EAP_HOME>/bin/jboss-cli.sh -c
> /subsystem=elytron/key-store=tls13:add(path=keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
> /subsystem=elytron/key-store=tls13:generate-key-pair(alias=localhost,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=localhost")
> /subsystem=elytron/key-store=tls13:store()
> /subsystem=elytron/key-manager=tls13:add(key-store=tls13,credential-reference={clear-text=secret})
> /subsystem=elytron/server-ssl-context=tls13:add(key-manager=tls13,protocols=["TLSv1.3"])
> batch
> /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
> /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=tls13)
> run-batch
> reload
> {code}
> 5. Start jmeter with JDK 11 and downloaded test plan
> {code}
> export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv13.log -o results-tlsv13
> {code}
> 6. Set server to use TLSv1.2
> {code}
> /subsystem=elytron/server-ssl-context=tls13:write-attribute(name=protocols,value=["TLSv1.2"])
> reload
> {code}
> 7. Repeat same for TLSv1.2
> {code}
> export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv12.log -o results-tlsv12
> {code}
> 8. Compare results (there will be an index.html file in the results-tlsv12 and results-tlsv13 directories)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (WFLY-12802) Quickstart for MP Config
by Martin Stefanko (Jira)
Martin Stefanko created WFLY-12802:
--------------------------------------
Summary: Quickstart for MP Config
Key: WFLY-12802
URL: https://issues.jboss.org/browse/WFLY-12802
Project: WildFly
Issue Type: Task
Components: MP Config, Quickstarts
Affects Versions: 18.0.1.Final
Reporter: Martin Stefanko
Assignee: Martin Stefanko
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (DROOLS-4750) DrlParser fails to parse str[endsWith] operator
by Alberto Fanjul Alonso (Jira)
[ https://issues.jboss.org/browse/DROOLS-4750?page=com.atlassian.jira.plugi... ]
Alberto Fanjul Alonso edited comment on DROOLS-4750 at 11/18/19 3:42 AM:
-------------------------------------------------------------------------
Hi [~mfusco] I didn't describe the case correctly. parsing drl rules is failing for me in current and old version of drools. I see a comment where it is supposed to work in 5.4.0 but I cannot test that . After move to 6.0.0 reproducer start to fail as codebase changed.
Trying to parse a Rule with DrlParser, normally it works,
{code:java}
package com.pulse.mainruleset
rule rule1
when
s : String( )
then
insert (s);
end
{code}
but if you add a rule with str operator (str[endsWith] or similar) it fails.
{code:java}
package com.pulse.mainruleset
rule rule2
when
s : String( this str[endsWith] "MAN" )
then
insert (s);
end
{code}
After you run a test that builds a KieModule like `_04_buildNoStrWith` test on that reproducer DrlParser starts to work with those operators, you can see on `_05_parseStrWith` test that is run after that.
I can imagine that KieModule build do some kind of preprocessing of drl rules, and after that DrlParser do not fail.
I suppose is related with launching or enabling `StringConditionInspector` but cannot see how.
So this bug tries to setup the minimal steps to make DrlParser to parse correctly any existing drl rule.
was (Author: afanjula):
Hi [~mfusco] I didn't describe the case correctly. parsing drl rules is failing for me in current and old version of drools. I see a comment where it is supposed to work in 5.4.0 but I cannot test that . After move to 6.0.0 reproducer start to fail as codebase changed.
Trying to parse a Rule with DrlParser, normally it works,
{code:java}
package com.amadeus.pulse.mainruleset
rule rule1
when
s : String( )
then
insert (s);
end
{code}
but if you add a rule with str operator (str[endsWith] or similar) it fails.
{code:java}
package com.amadeus.pulse.mainruleset
rule rule2
when
s : String( this str[endsWith] "MAN" )
then
insert (s);
end
{code}
After you run a test that builds a KieModule like `_04_buildNoStrWith` test on that reproducer DrlParser starts to work with those operators, you can see on `_05_parseStrWith` test that is run after that.
I can imagine that KieModule build do some kind of preprocessing of drl rules, and after that DrlParser do not fail.
I suppose is related with launching or enabling `StringConditionInspector` but cannot see how.
So this bug tries to setup the minimal steps to make DrlParser to parse correctly any existing drl rule.
> DrlParser fails to parse str[endsWith] operator
> -----------------------------------------------
>
> Key: DROOLS-4750
> URL: https://issues.jboss.org/browse/DROOLS-4750
> Project: Drools
> Issue Type: Bug
> Reporter: Alberto Fanjul Alonso
> Assignee: Mario Fusco
> Priority: Major
> Attachments: reproducer.zip
>
>
> In documentation
> https://docs.jboss.org/drools/release/7.23.0.Final/drools-docs/html_singl...
> operator str[endsWith] is supposed to be supported, it it is not working.
> Fails with:
> {code:java}
> java.lang.Exception: Rule contains errors![[5,19]: [ERR 102] Line 5:19 mismatched input 'str' in rule "pnr first name end with"]
> at com.amadeus.mdw.bzr.drools_reproducer.StrWithFailOnFirstCompilationErrorReproducerTest.parse(StrWithFailOnFirstCompilationErrorReproducerTest.java:58)
> at com.amadeus.mdw.bzr.drools_reproducer.StrWithFailOnFirstCompilationErrorReproducerTest._03_parseStrWith(StrWithFailOnFirstCompilationErrorReproducerTest.java:74)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (DROOLS-4750) DrlParser fails to parse str[endsWith] operator
by Alberto Fanjul Alonso (Jira)
[ https://issues.jboss.org/browse/DROOLS-4750?page=com.atlassian.jira.plugi... ]
Alberto Fanjul Alonso updated DROOLS-4750:
------------------------------------------
Description:
In documentation
https://docs.jboss.org/drools/release/7.23.0.Final/drools-docs/html_singl...
operator str[endsWith] is supposed to be supported, it it is not working.
Fails with:
{code:java}
java.lang.Exception: Rule contains errors![[5,19]: [ERR 102] Line 5:19 mismatched input 'str' in rule "pnr first name end with"]
at com.mdw.bzr.drools_reproducer.StrWithFailOnFirstCompilationErrorReproducerTest.parse(StrWithFailOnFirstCompilationErrorReproducerTest.java:58)
at com.mdw.bzr.drools_reproducer.StrWithFailOnFirstCompilationErrorReproducerTest._03_parseStrWith(StrWithFailOnFirstCompilationErrorReproducerTest.java:74)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
{code}
was:
In documentation
https://docs.jboss.org/drools/release/7.23.0.Final/drools-docs/html_singl...
operator str[endsWith] is supposed to be supported, it it is not working.
Fails with:
{code:java}
java.lang.Exception: Rule contains errors![[5,19]: [ERR 102] Line 5:19 mismatched input 'str' in rule "pnr first name end with"]
at com.amadeus.mdw.bzr.drools_reproducer.StrWithFailOnFirstCompilationErrorReproducerTest.parse(StrWithFailOnFirstCompilationErrorReproducerTest.java:58)
at com.amadeus.mdw.bzr.drools_reproducer.StrWithFailOnFirstCompilationErrorReproducerTest._03_parseStrWith(StrWithFailOnFirstCompilationErrorReproducerTest.java:74)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
{code}
> DrlParser fails to parse str[endsWith] operator
> -----------------------------------------------
>
> Key: DROOLS-4750
> URL: https://issues.jboss.org/browse/DROOLS-4750
> Project: Drools
> Issue Type: Bug
> Reporter: Alberto Fanjul Alonso
> Assignee: Mario Fusco
> Priority: Major
> Attachments: reproducer.zip
>
>
> In documentation
> https://docs.jboss.org/drools/release/7.23.0.Final/drools-docs/html_singl...
> operator str[endsWith] is supposed to be supported, it it is not working.
> Fails with:
> {code:java}
> java.lang.Exception: Rule contains errors![[5,19]: [ERR 102] Line 5:19 mismatched input 'str' in rule "pnr first name end with"]
> at com.mdw.bzr.drools_reproducer.StrWithFailOnFirstCompilationErrorReproducerTest.parse(StrWithFailOnFirstCompilationErrorReproducerTest.java:58)
> at com.mdw.bzr.drools_reproducer.StrWithFailOnFirstCompilationErrorReproducerTest._03_parseStrWith(StrWithFailOnFirstCompilationErrorReproducerTest.java:74)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months