[JBoss JIRA] (WFLY-5912) "Test Connection" feature from the Datasources configuration UI with a Postgres DS inadvertently registers the DS
by Danilo Cominotti Marques (JIRA)
[ https://issues.jboss.org/browse/WFLY-5912?page=com.atlassian.jira.plugin.... ]
Danilo Cominotti Marques updated WFLY-5912:
-------------------------------------------
Description:
After adding the postgresql-9.4-1201.jdbc41 driver/module to WildFly and configuring a datasource in the web console, when I click on "Test connection" instead of finishing the configuration, a success message appears along with a "Reload server now" message because the datasource has inadvertently been registered already; and when the server is reloaded, I can't see the newly registered datasource in the web console. Below is the console log I get when I try to actually finalize the same datasource configuration after having but tested its connection and reloaded the server as per the web console messages:
22:41:08,708 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-7) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "datasources"),
("data-source" => "CominottiDS")
]): org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.data-source.CominottiDS is already registered
at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235)
at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768)
at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:2129)
at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.firstRuntimeStep(AbstractDataSourceAdd.java:185)
at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.performRuntime(AbstractDataSourceAdd.java:106)
at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:212)
at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:95)
at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
was:
After adding the postgresql-9.4-1201.jdbc41 driver/module to WildFly and configuring a datasource in the web console, when I click on "Test connection" instead of finishing the configuration, a success message appears along with a "Reload server now" message because the datasource has inadvertently been registered already; and when the server is reloaded, I can't see the newly registered datasource in the web console. Below is the console log I get when I try to actually finalize the same datasource configuration after having but tested its connection and reloaded the server as per the web console messages:
{{22:41:08,708 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-7) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "datasources"),
("data-source" => "CominottiDS")
]): org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.data-source.CominottiDS is already registered
at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235)
at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768)
at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:2129)
at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.firstRuntimeStep(AbstractDataSourceAdd.java:185)
at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.performRuntime(AbstractDataSourceAdd.java:106)
at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:212)
at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:95)
at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)}}
> "Test Connection" feature from the Datasources configuration UI with a Postgres DS inadvertently registers the DS
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5912
> URL: https://issues.jboss.org/browse/WFLY-5912
> Project: WildFly
> Issue Type: Bug
> Components: Server, Web Console
> Affects Versions: 10.0.0.CR5
> Reporter: Danilo Cominotti Marques
> Assignee: Jason Greene
>
> After adding the postgresql-9.4-1201.jdbc41 driver/module to WildFly and configuring a datasource in the web console, when I click on "Test connection" instead of finishing the configuration, a success message appears along with a "Reload server now" message because the datasource has inadvertently been registered already; and when the server is reloaded, I can't see the newly registered datasource in the web console. Below is the console log I get when I try to actually finalize the same datasource configuration after having but tested its connection and reloaded the server as per the web console messages:
> 22:41:08,708 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-7) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "datasources"),
> ("data-source" => "CominottiDS")
> ]): org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.data-source.CominottiDS is already registered
> at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
> at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235)
> at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768)
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
> at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
> at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:2129)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.firstRuntimeStep(AbstractDataSourceAdd.java:185)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.performRuntime(AbstractDataSourceAdd.java:106)
> at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:212)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
> at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
> at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:95)
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (WFLY-5758) Getting [Management resource '[(\"subsystem\" => \"undertow\")]' not found] when removing ressources from Undertow
by Montpa Pasteur (JIRA)
[ https://issues.jboss.org/browse/WFLY-5758?page=com.atlassian.jira.plugin.... ]
Montpa Pasteur commented on WFLY-5758:
--------------------------------------
I haven't tried it yet, but is there any chance to have this fix for Wildfly 8.2.1 ?
Thanks.
> Getting [Management resource '[(\"subsystem\" => \"undertow\")]' not found] when removing ressources from Undertow
> ------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5758
> URL: https://issues.jboss.org/browse/WFLY-5758
> Project: WildFly
> Issue Type: Bug
> Components: CLI
> Affects Versions: 8.x.x TBD
> Environment: Wildfly 8.2.1 on SUSE Linux 11.1 and Solaris 11
> Reporter: Montpa Pasteur
> Assignee: Alexey Loubyansky
> Priority: Minor
>
> When trying remove more that one resource from Undertow using the CLI, I am getting this message: *[Management resource '[(\"subsystem\" => \"undertow\")]' not found*]
> This doesn't happen all time, it looks like random. Adding a sleep between the CLI command helps some time.
> I get this problem when trying to remove http request header configuration and when trying to remove static ressource serving configuration(location, file handler, filter ..)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (JGRP-1985) Message: make initial size of headers configurable
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1985?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1985:
--------------------------------
Hmm, by default we have the following headers
* Transport: {{UDP}}, {{TCP}} or {{TCP_NIO2}}
* Reliable retransmission and ordering protocol: either {{NAKACK2}} or {{UNICAST3}}
* RequestCorrelator for RPCs
That's 3 headers most of the time. Which other headers did you see? {{FRAG2}}?
Just out of curiosity, I'll change the default to 4 anyway.
> Message: make initial size of headers configurable
> --------------------------------------------------
>
> Key: JGRP-1985
> URL: https://issues.jboss.org/browse/JGRP-1985
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> By default a message creates a {{Headers}} instance of 3. This is usually enough (transport, either {{NAKACK2}} or {{UNICAST3}}, and possibly fragmentation). However, if a message needs 4 or more headers, there's a resize which is an additional copy of 2 small arrays.
> Goal: make the initial headers size configurable.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JGRP-1985) Message: make initial size of headers configurable
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1985?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1985 at 12/24/15 5:27 AM:
----------------------------------------------------------
Hmm, by default we have the following headers
* Transport: {{UDP}}, {{TCP}} or {{TCP_NIO2}}
* Reliable retransmission and ordering protocol: either {{NAKACK2}} or {{UNICAST3}}
* RequestCorrelator for RPCs
That's 3 headers most of the time. Which other headers did you see? {{FRAG2}}, {{FORK}}?
Just out of curiosity, I'll change the default to 4 anyway.
was (Author: belaban):
Hmm, by default we have the following headers
* Transport: {{UDP}}, {{TCP}} or {{TCP_NIO2}}
* Reliable retransmission and ordering protocol: either {{NAKACK2}} or {{UNICAST3}}
* RequestCorrelator for RPCs
That's 3 headers most of the time. Which other headers did you see? {{FRAG2}}?
Just out of curiosity, I'll change the default to 4 anyway.
> Message: make initial size of headers configurable
> --------------------------------------------------
>
> Key: JGRP-1985
> URL: https://issues.jboss.org/browse/JGRP-1985
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> By default a message creates a {{Headers}} instance of 3. This is usually enough (transport, either {{NAKACK2}} or {{UNICAST3}}, and possibly fragmentation). However, if a message needs 4 or more headers, there's a resize which is an additional copy of 2 small arrays.
> Goal: make the initial headers size configurable.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JGRP-1999) TCP_NIO2: single selector slows down writes and reads
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1999?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1999.
----------------------------
Resolution: Done
> TCP_NIO2: single selector slows down writes and reads
> -----------------------------------------------------
>
> Key: JGRP-1999
> URL: https://issues.jboss.org/browse/JGRP-1999
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> TCP_NIO2 has a single selector which looks like this:
> {noformat}
> x=select()
> if(read) -> read data from connection x, de-serialize data, pass to thread pool
> if(write) -> write data pending on connection x
> {noformat}
> This means that any operation (read,write) delays other operations. It seems that especially the de-serialization done in reads delays other reads and writes.
> A quick test showed that having a reader thread per connection (so that reads don't delay other reads or writes) improved perf from 15'000 reqs/sec to 22'000.
> The idea is to have a reader thread in {{NioConnection}} which reads and de-serializes as many messages as possible. When no more messages are ready to be read, it blocks for a max wait time and then terminates unless more messages are ready. This means that idle connections will have no threads allocated.
> Investigate: we might possibly also null the pre-allocated buffer when a thread terminates, reducing memory usage even more.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JGRP-1999) TCP_NIO2: single selector slows down writes and reads
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1999?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1999:
--------------------------------
{{OP_READ}} is unregistered on each {{receive()}}, and re-registered when the reader thread is done reading msgs. Quick perf test (UPerf, 4 nodes) showed perf of *~24'000 RPCs/sec/node*, which is equivalent to {{TCP}}.
> TCP_NIO2: single selector slows down writes and reads
> -----------------------------------------------------
>
> Key: JGRP-1999
> URL: https://issues.jboss.org/browse/JGRP-1999
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> TCP_NIO2 has a single selector which looks like this:
> {noformat}
> x=select()
> if(read) -> read data from connection x, de-serialize data, pass to thread pool
> if(write) -> write data pending on connection x
> {noformat}
> This means that any operation (read,write) delays other operations. It seems that especially the de-serialization done in reads delays other reads and writes.
> A quick test showed that having a reader thread per connection (so that reads don't delay other reads or writes) improved perf from 15'000 reqs/sec to 22'000.
> The idea is to have a reader thread in {{NioConnection}} which reads and de-serializes as many messages as possible. When no more messages are ready to be read, it blocks for a max wait time and then terminates unless more messages are ready. This means that idle connections will have no threads allocated.
> Investigate: we might possibly also null the pre-allocated buffer when a thread terminates, reducing memory usage even more.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1015) Wrong MvelConstraint compilation with Unicode class name and the same name property
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1015?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration updated DROOLS-1015:
--------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1294048
Bugzilla Update: Perform
> Wrong MvelConstraint compilation with Unicode class name and the same name property
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-1015
> URL: https://issues.jboss.org/browse/DROOLS-1015
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Mario Fusco
>
> If a fact has a property of Unicode class name (e.g. 住所) and the property name is the same (住所), constraint is not correctly compiled by MVEL. Internally, AbstractParser.createPropertyToken() misunderstands the property as a class name literal.
> {code:java}
> public class I18nPerson implements Serializable {
> private 住所 住所; // "address" in Japanese
> public 住所 get住所() {
> return 住所;
> }
> ....
> {code}
> {noformat}
> when
> p : I18nPerson( 住所 != null )
> {noformat}
> This constraint is always evaluated to "true".
> Essentially, this is not only a problem of Unicode. We can reproduce the issue by a capitalized property name.
> {code:java}
> public class Person implements Serializable {
> private Address address;
> public Address getAddress() {
> return address;
> }
> ....
> {code}
> {noformat}
> when
> p : I18nPerson( Address != null )
> {noformat}
> Of course we should use lower case letters here from JavaBeans point of view so we don't hit this issue with English usually. But some languages like Japanese cannot express "lower case/upper case" so result in this issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1015) Wrong MvelConstraint compilation with Unicode class name and the same name property
by Toshiya Kobayashi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1015?page=com.atlassian.jira.plugi... ]
Toshiya Kobayashi updated DROOLS-1015:
--------------------------------------
Git Pull Request: https://github.com/droolsjbpm/drools/pull/592
> Wrong MvelConstraint compilation with Unicode class name and the same name property
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-1015
> URL: https://issues.jboss.org/browse/DROOLS-1015
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Mario Fusco
>
> If a fact has a property of Unicode class name (e.g. 住所) and the property name is the same (住所), constraint is not correctly compiled by MVEL. Internally, AbstractParser.createPropertyToken() misunderstands the property as a class name literal.
> {code:java}
> public class I18nPerson implements Serializable {
> private 住所 住所; // "address" in Japanese
> public 住所 get住所() {
> return 住所;
> }
> ....
> {code}
> {noformat}
> when
> p : I18nPerson( 住所 != null )
> {noformat}
> This constraint is always evaluated to "true".
> Essentially, this is not only a problem of Unicode. We can reproduce the issue by a capitalized property name.
> {code:java}
> public class Person implements Serializable {
> private Address address;
> public Address getAddress() {
> return address;
> }
> ....
> {code}
> {noformat}
> when
> p : I18nPerson( Address != null )
> {noformat}
> Of course we should use lower case letters here from JavaBeans point of view so we don't hit this issue with English usually. But some languages like Japanese cannot express "lower case/upper case" so result in this issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1015) Wrong MvelConstraint compilation with Unicode class name and the same name property
by Toshiya Kobayashi (JIRA)
Toshiya Kobayashi created DROOLS-1015:
-----------------------------------------
Summary: Wrong MvelConstraint compilation with Unicode class name and the same name property
Key: DROOLS-1015
URL: https://issues.jboss.org/browse/DROOLS-1015
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.3.0.Final
Reporter: Toshiya Kobayashi
Assignee: Mario Fusco
If a fact has a property of Unicode class name (e.g. 住所) and the property name is the same (住所), constraint is not correctly compiled by MVEL. Internally, AbstractParser.createPropertyToken() misunderstands the property as a class name literal.
{code:java}
public class I18nPerson implements Serializable {
private 住所 住所; // "address" in Japanese
public 住所 get住所() {
return 住所;
}
....
{code}
{noformat}
when
p : I18nPerson( 住所 != null )
{noformat}
This constraint is always evaluated to "true".
Essentially, this is not only a problem of Unicode. We can reproduce the issue by a capitalized property name.
{code:java}
public class Person implements Serializable {
private Address address;
public Address getAddress() {
return address;
}
....
{code}
{noformat}
when
p : I18nPerson( Address != null )
{noformat}
Of course we should use lower case letters here from JavaBeans point of view so we don't hit this issue with English usually. But some languages like Japanese cannot express "lower case/upper case" so result in this issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years