[JBoss JIRA] (DROOLS-1392) Boolean cells in decision tables are not correctly formatted with Apache POI 3.15
by Mario Fusco (JIRA)
Mario Fusco created DROOLS-1392:
-----------------------------------
Summary: Boolean cells in decision tables are not correctly formatted with Apache POI 3.15
Key: DROOLS-1392
URL: https://issues.jboss.org/browse/DROOLS-1392
Project: Drools
Issue Type: Bug
Reporter: Mario Fusco
Assignee: Mario Fusco
Using Apache POI 3.15 cells of type Boolean are formatted as "TRUE" or "FALSE" instead of "true" or "false" and this leads to generate an invalid drl that will raise compilation errors like the following
{code}
Rule Compilation error : [Rule name='Spreadsheet Example_11']
rule_table/Rule_Spreadsheet_Example_11413427566.java (7:503) : FALSE cannot be resolved to a variable
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (DROOLS-599) kjar archertype
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-599?page=com.atlassian.jira.plugin... ]
Matteo Mortari commented on DROOLS-599:
---------------------------------------
Hi [~mbiarnes] , in reference to my previous comment above, and now discussing with [~mfusco] , we would like to highlight the availability of the Kie Archetype to end users.
However, [since this archetype was first proposed|https://github.com/droolsjbpm/droolsjbpm-knowledge/pull/74/files...], now [License file-headers are attached to all files|https://github.com/droolsjbpm/droolsjbpm-knowledge/commit/7172a50c4...]; with the actual consequence that once you use the archetype, as a user, your files are containing the Red Hat file-header license; and I believe this could be very confusing for the end-users, and also I believe is wrong.
My proposal is to remove License file-headers, at least from all files which are serving as a template-generation.
I have two question, please?
# Do you agree with me reverting your change?
# Did you notice the License file-headers are missing thanks to some automatic tool? Is there a way to manage exclusion, either in the tool or by adding a special header to the file itself?
Thank you in advance for your feedback.
> kjar archertype
> ---------------
>
> Key: DROOLS-599
> URL: https://issues.jboss.org/browse/DROOLS-599
> Project: Drools
> Issue Type: Feature Request
> Affects Versions: 6.1.0.Final
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
> Fix For: 6.2.0.CR1
>
>
> I'm opening this JIRA as I will later open PR related to https://groups.google.com/d/msg/drools-development/uO17-kC4mvc/aBRunEcZ_b4J
> The version of the archetype defaults for non-CEP, non-Eclipse plugin in pom. There are property which user can change default value to have CEP, and Eclipse plug-in.
> For reference,
> * Set-up the new project's pom:
> ** Change Java version to 1.6 or greater, by including the maven-compiler-plugin
> ** Add Drools dependencies
> ** Change JUnit dependencies to version 4
> ** Add kie-maven-plugin
> ** [option] Add plug-in org.eclipse.m2e/lifecycle-mapping settings, to avoid Eclipse ERROR at the pom.xml line defining the kie-maven-plugin
> ** Set packaging to 'kjar'
> * ( ALT + F5 in betweens )
> * Creation of an initial .drl file in src/main/resources
> * Creation of minimal kmodule.xml in src/main/resources/META-INF directory
> * Create a simple JUnit test for:
> ** Creation of KieBase [option ->] with STREAM option for CEP features
> ** Creation of KieSession [option ->] with pseudo-clock
> ** [option: Advance] / Insert / Fire template
> ** ... and other verification/output patterns
> * Include SLF4J and LOG4J binding for logging, including a log4j.properties file in src/test/resources
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7841) ManagedScheduledExecutorService could not find EntityManager produced by CDI producer. No active context.
by Tibor Digana (JIRA)
[ https://issues.jboss.org/browse/WFLY-7841?page=com.atlassian.jira.plugin.... ]
Tibor Digana commented on WFLY-7841:
------------------------------------
I have created a project in my public repository.
https://github.com/Tibor17/issue-7841
> ManagedScheduledExecutorService could not find EntityManager produced by CDI producer. No active context.
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7841
> URL: https://issues.jboss.org/browse/WFLY-7841
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Reporter: Tibor Digana
> Assignee: Stuart Douglas
>
> The problem is that _EntityManager_ does not have managed delegate within a job executed by _ManagedScheduledExecutorService#scheduleAtFixedRate()_.
> The _EntityManager_ is produced by CDI producer and entire web application is able to work with injected _EntityManager_ except for the jobs.
> I tried to schedule executing the job in two ways and both finished with same issue (No managed context in _EntityManager_) :
> * _@ApplicationScoped_ job instance was passed to executor from caller.
> * The job was changed to _RequestScoped_ and _ContextProxy#createContextualProxy()_ created the Job bean instance and then I called _scheduleAtFixedRate(job, 5, 60, SECONDS)_
> It looks to me that _javax.enterprise.concurrent_ has a different _BeanManager_ and therefore has no notion about my CDI Producer of _EntityManager_. The producer is regular producer of _EntityManager_ in JavaEE.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7841) ManagedScheduledExecutorService could not find EntityManager produced by CDI producer. No active context.
by Tibor Digana (JIRA)
[ https://issues.jboss.org/browse/WFLY-7841?page=com.atlassian.jira.plugin.... ]
Tibor Digana updated WFLY-7841:
-------------------------------
Affects Version/s: 10.1.0.Final
> ManagedScheduledExecutorService could not find EntityManager produced by CDI producer. No active context.
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7841
> URL: https://issues.jboss.org/browse/WFLY-7841
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Reporter: Tibor Digana
> Assignee: Stuart Douglas
>
> The problem is that _EntityManager_ does not have managed delegate within a job executed by _ManagedScheduledExecutorService#scheduleAtFixedRate()_.
> The _EntityManager_ is produced by CDI producer and entire web application is able to work with injected _EntityManager_ except for the jobs.
> I tried to schedule executing the job in two ways and both finished with same issue (No managed context in _EntityManager_) :
> * _@ApplicationScoped_ job instance was passed to executor from caller.
> * The job was changed to _RequestScoped_ and _ContextProxy#createContextualProxy()_ created the Job bean instance and then I called _scheduleAtFixedRate(job, 5, 60, SECONDS)_
> It looks to me that _javax.enterprise.concurrent_ has a different _BeanManager_ and therefore has no notion about my CDI Producer of _EntityManager_. The producer is regular producer of _EntityManager_ in JavaEE.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (DROOLS-1391) Investigate why jcr2vfs migration tool needs gwt-user dependency
by Petr Široký (JIRA)
Petr Široký created DROOLS-1391:
-----------------------------------
Summary: Investigate why jcr2vfs migration tool needs gwt-user dependency
Key: DROOLS-1391
URL: https://issues.jboss.org/browse/DROOLS-1391
Project: Drools
Issue Type: Task
Reporter: Petr Široký
Assignee: Petr Široký
After the upgrade of JPA (2.0 -> 2.1) and Hibernate (4.x -> 5.x), the jcr2vfs-importer tests started to fail with {{WELD-ENV-000015: Unable to load annotation: jsinterop.annotations.JsType}}. This class is in {{gwt-user}} jar, so adding that "fixes" the issue. However, gwt-user is a huge library (~16MiB) and ideally should not be needed. We need to investigate if there is a way to get rid of it.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (ELY-856) Elytron ldap-realm does not support principal to group mapping (memberOf)
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-856?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina edited comment on ELY-856 at 1/2/17 10:42 AM:
---------------------------------------------------------
-This issue is similar to ELY-794 - it would be solved, if we could use any LDAP attribute as wildcard in filter of attribute mapping.-
*Edit:* Ok, we doesn't - as we cannot address entry by DN using filter, special attribute sounds more appropriate - for example:
{code:xml}
<attribute reference="memberOf" from="cn" to="rolesDn" role-recursion="2"/>
{code}
(will take entries given by memberOf of user attribute, puts its cn to rolesDn, repeat for entries given by memberOf of group attribute)
was (Author: honza889):
This issue is similar to ELY-794 - it would be solved, if we could use any LDAP attribute (or identity attribute) as wildcard in filter of attribute mapping.
(But we would need to be able to address entity of attribute by DN!)
> Elytron ldap-realm does not support principal to group mapping (memberOf)
> -------------------------------------------------------------------------
>
> Key: ELY-856
> URL: https://issues.jboss.org/browse/ELY-856
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.1.0.Beta16
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
>
> Elytron ldap-realm is not able to work with LDAP which uses principal to group mapping. It seems that there is currently no way how to configure principal to group mapping in application server.
> Simplified example:
> {code}
> dn: uid=TestUserOne,ou=users,dc=principal-to-group,dc=example,dc=org
> objectClass: groupMember
> memberOf: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org
> memberOf: uid=Slashy/Group,ou=groups,dc=principal-to-group,dc=example,dc=org
> dn: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org
> objectClass: groupMember
> objectClass: group
> memberOf: uid=GroupFive,ou=subgroups,ou=groups,dc=principal-to-group,dc=example,dc=org
> {code}
> Example for reproducing: (by olukas)
> Role {{SomeRole}} is currently not able to be assigned to user {{someUser}} when following ldif is used. In this case principal to group mapping is provided by attribute {{description}}, but in can be provided by any attribute (e.g. memberOf). User {{thisUserIsNotUsed}} is used only for simpler reproduction of issue.
> {code}
> dn: ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: People
> dn: uid=someUser,ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> uid: someUser
> cn: some User
> sn: User
> userPassword: Password
> description: cn=SomeRole,ou=Roles,dc=jboss,dc=org
> dn: uid=thisUserIsNotUsed,ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> uid: thisUserIsNotUsed
> cn: this User Is Not Used
> sn: this User Is Not Used
> userPassword: Password
> dn: ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: Roles
> dn: cn=SomeRole,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: SomeRole
> member: uid=thisUserIsNotUsed,ou=People,dc=jboss,dc=org
> {code}
> Mentioned ldif works with legacy security solution.
> This missing feature can cause that migration from legacy security solution will not be possible -> we request blocker.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (ELY-856) Elytron ldap-realm does not support principal to group mapping (memberOf)
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-856?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-856:
---------------------------
Description:
Elytron ldap-realm is not able to work with LDAP which uses principal to group mapping. It seems that there is currently no way how to configure principal to group mapping in application server.
Simplified example:
{code}
dn: uid=TestUserOne,ou=users,dc=principal-to-group,dc=example,dc=org
objectClass: groupMember
memberOf: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org
memberOf: uid=Slashy/Group,ou=groups,dc=principal-to-group,dc=example,dc=org
dn: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org
objectClass: groupMember
objectClass: group
memberOf: uid=GroupFive,ou=subgroups,ou=groups,dc=principal-to-group,dc=example,dc=org
{code}
Example for reproducing: (by olukas)
Role {{SomeRole}} is currently not able to be assigned to user {{someUser}} when following ldif is used. In this case principal to group mapping is provided by attribute {{description}}, but in can be provided by any attribute (e.g. memberOf). User {{thisUserIsNotUsed}} is used only for simpler reproduction of issue.
{code}
dn: ou=People,dc=jboss,dc=org
objectclass: top
objectclass: organizationalUnit
ou: People
dn: uid=someUser,ou=People,dc=jboss,dc=org
objectclass: top
objectclass: person
objectclass: inetOrgPerson
uid: someUser
cn: some User
sn: User
userPassword: Password
description: cn=SomeRole,ou=Roles,dc=jboss,dc=org
dn: uid=thisUserIsNotUsed,ou=People,dc=jboss,dc=org
objectclass: top
objectclass: person
objectclass: inetOrgPerson
uid: thisUserIsNotUsed
cn: this User Is Not Used
sn: this User Is Not Used
userPassword: Password
dn: ou=Roles,dc=jboss,dc=org
objectclass: top
objectclass: organizationalUnit
ou: Roles
dn: cn=SomeRole,ou=Roles,dc=jboss,dc=org
objectclass: top
objectclass: groupOfNames
cn: SomeRole
member: uid=thisUserIsNotUsed,ou=People,dc=jboss,dc=org
{code}
Mentioned ldif works with legacy security solution.
This missing feature can cause that migration from legacy security solution will not be possible -> we request blocker.
was:
Elytron ldap-realm is not able to work with LDAP which uses principal to group mapping. It seems that there is currently no way how to configure principal to group mapping in application server.
Example:
Role {{SomeRole}} is currently not able to be assigned to user {{someUser}} when following ldif is used. In this case principal to group mapping is provided by attribute {{description}}, but in can be provided by any attribute (e.g. memberOf). User {{thisUserIsNotUsed}} is used only for simpler reproduction of issue.
{code}
dn: ou=People,dc=jboss,dc=org
objectclass: top
objectclass: organizationalUnit
ou: People
dn: uid=someUser,ou=People,dc=jboss,dc=org
objectclass: top
objectclass: person
objectclass: inetOrgPerson
uid: someUser
cn: some User
sn: User
userPassword: Password
description: cn=SomeRole,ou=Roles,dc=jboss,dc=org
dn: uid=thisUserIsNotUsed,ou=People,dc=jboss,dc=org
objectclass: top
objectclass: person
objectclass: inetOrgPerson
uid: thisUserIsNotUsed
cn: this User Is Not Used
sn: this User Is Not Used
userPassword: Password
dn: ou=Roles,dc=jboss,dc=org
objectclass: top
objectclass: organizationalUnit
ou: Roles
dn: cn=SomeRole,ou=Roles,dc=jboss,dc=org
objectclass: top
objectclass: groupOfNames
cn: SomeRole
member: uid=thisUserIsNotUsed,ou=People,dc=jboss,dc=org
{code}
Mentioned ldif works with legacy security solution.
This missing feature can cause that migration from legacy security solution will not be possible -> we request blocker.
> Elytron ldap-realm does not support principal to group mapping (memberOf)
> -------------------------------------------------------------------------
>
> Key: ELY-856
> URL: https://issues.jboss.org/browse/ELY-856
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.1.0.Beta16
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
>
> Elytron ldap-realm is not able to work with LDAP which uses principal to group mapping. It seems that there is currently no way how to configure principal to group mapping in application server.
> Simplified example:
> {code}
> dn: uid=TestUserOne,ou=users,dc=principal-to-group,dc=example,dc=org
> objectClass: groupMember
> memberOf: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org
> memberOf: uid=Slashy/Group,ou=groups,dc=principal-to-group,dc=example,dc=org
> dn: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org
> objectClass: groupMember
> objectClass: group
> memberOf: uid=GroupFive,ou=subgroups,ou=groups,dc=principal-to-group,dc=example,dc=org
> {code}
> Example for reproducing: (by olukas)
> Role {{SomeRole}} is currently not able to be assigned to user {{someUser}} when following ldif is used. In this case principal to group mapping is provided by attribute {{description}}, but in can be provided by any attribute (e.g. memberOf). User {{thisUserIsNotUsed}} is used only for simpler reproduction of issue.
> {code}
> dn: ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: People
> dn: uid=someUser,ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> uid: someUser
> cn: some User
> sn: User
> userPassword: Password
> description: cn=SomeRole,ou=Roles,dc=jboss,dc=org
> dn: uid=thisUserIsNotUsed,ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> uid: thisUserIsNotUsed
> cn: this User Is Not Used
> sn: this User Is Not Used
> userPassword: Password
> dn: ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: Roles
> dn: cn=SomeRole,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: SomeRole
> member: uid=thisUserIsNotUsed,ou=People,dc=jboss,dc=org
> {code}
> Mentioned ldif works with legacy security solution.
> This missing feature can cause that migration from legacy security solution will not be possible -> we request blocker.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (DROOLS-1387) PHREAK is slower than ReteOO with accumulate and exists
by Tibor Zimányi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1387?page=com.atlassian.jira.plugi... ]
Tibor Zimányi commented on DROOLS-1387:
---------------------------------------
I think I can confirm this. I created the "same" benchmarks in kie-benchmarks using JMH (I used DRLs and fact inserts from [~tkobayashi]'s reproducer). I put it in my separate branch, which you can find here [1]. Please *DO NOT MERGE* it into upstream, because it contains changes in pom.xml's and other benchmarks that contain references to APIs available only in 7.x. I will create separate PR for upstream/master when needed. [~tkobayashi] could you please check my benchmarks if I migrated them correctly? My results when I ran the benchmarks locally on my computer are here [2] .
[1] https://github.com/baldimir/kie-benchmarks/tree/DROOLS-1387
[2] http://pastebin.com/dsAMv5x3
> PHREAK is slower than ReteOO with accumulate and exists
> -------------------------------------------------------
>
> Key: DROOLS-1387
> URL: https://issues.jboss.org/browse/DROOLS-1387
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 6.5.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Mario Fusco
> Labels: support
> Attachments: brms-perf-comarison.zip
>
>
> PHREAK is slower than ReteOO in case of:
> 1. with accumulate
> 2. with exists
> Attached test case brms-perf-comarison.zip contains 4 tests to compare the performance:
> ReteOO_Accumulate vs Phreak_Accumulate
> -> ReteOO is 30% faster than PHREAK in average
> ReteOO_Exists vs Phreak_Exists
> -> ReteOO is 30% faster than PHREAK in average
> You can run the test with
> {noformat}
> mvn -P BRMS640GA clean test
> {noformat}
> The example output:
> {noformat}
> Running org.mk300.brms.perf.Phreak_Accumulate
> 2016-12-27 16:51:40,280 INFO (main) [RuleBase] ##################### RuleBase start
> 2016-12-27 16:51:42,322 INFO (main) [KieRepositoryImpl] KieModule was added: MemoryKieModule[releaseId=org.default:artifact:1.0.0-SNAPSHOT]
> 2016-12-27 16:51:42,519 INFO (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 0 tx/sec
> 2016-12-27 16:51:43,529 INFO (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 29,020 tx/sec
> 2016-12-27 16:51:44,533 INFO (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 159,216 tx/sec
> 2016-12-27 16:51:45,539 INFO (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 203,391 tx/sec
> 2016-12-27 16:51:46,539 INFO (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 202,453 tx/sec
> 2016-12-27 16:51:47,553 INFO (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 204,160 tx/sec
> 2016-12-27 16:51:48,555 INFO (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 199,914 tx/sec
> 2016-12-27 16:51:49,556 INFO (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 193,496 tx/sec
> 2016-12-27 16:51:50,557 INFO (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 200,377 tx/sec
> 2016-12-27 16:51:51,557 INFO (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 202,060 tx/sec
> 2016-12-27 16:51:52,522 INFO (main) [RuleBase] ##################### disposeAll end
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.394 sec - in org.mk300.brms.perf.Phreak_Accumulate
> Running org.mk300.brms.perf.Phreak_Exists
> 2016-12-27 16:51:52,860 INFO (main) [RuleBase] ##################### RuleBase start
> 2016-12-27 16:51:54,521 INFO (main) [KieRepositoryImpl] KieModule was added: MemoryKieModule[releaseId=org.default:artifact:1.0.0-SNAPSHOT]
> 2016-12-27 16:51:54,716 INFO (pool-1-thread-1) [PerfCounter] Phreak_Exists : 0 tx/sec
> 2016-12-27 16:51:55,737 INFO (pool-1-thread-1) [PerfCounter] Phreak_Exists : 72,411 tx/sec
> 2016-12-27 16:51:56,737 INFO (pool-1-thread-1) [PerfCounter] Phreak_Exists : 257,065 tx/sec
> 2016-12-27 16:51:57,741 INFO (pool-1-thread-1) [PerfCounter] Phreak_Exists : 292,136 tx/sec
> 2016-12-27 16:51:58,746 INFO (pool-1-thread-1) [PerfCounter] Phreak_Exists : 283,862 tx/sec
> 2016-12-27 16:51:59,753 INFO (pool-1-thread-1) [PerfCounter] Phreak_Exists : 285,201 tx/sec
> 2016-12-27 16:52:00,753 INFO (pool-1-thread-1) [PerfCounter] Phreak_Exists : 290,762 tx/sec
> 2016-12-27 16:52:01,760 INFO (pool-1-thread-1) [PerfCounter] Phreak_Exists : 291,661 tx/sec
> 2016-12-27 16:52:02,760 INFO (pool-1-thread-1) [PerfCounter] Phreak_Exists : 296,011 tx/sec
> 2016-12-27 16:52:03,767 INFO (pool-1-thread-1) [PerfCounter] Phreak_Exists : 296,844 tx/sec
> 2016-12-27 16:52:04,719 INFO (main) [RuleBase] ##################### disposeAll end
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.004 sec - in org.mk300.brms.perf.Phreak_Exists
> Running org.mk300.brms.perf.ReteOO_Accumulate
> 2016-12-27 16:52:05,068 INFO (main) [RuleBase] ##################### RuleBase start
> 2016-12-27 16:52:07,139 INFO (main) [KieRepositoryImpl] KieModule was added: MemoryKieModule[releaseId=org.default:artifact:1.0.0-SNAPSHOT]
> 2016-12-27 16:52:07,349 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 0 tx/sec
> 2016-12-27 16:52:08,368 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 50,996 tx/sec
> 2016-12-27 16:52:09,380 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 217,269 tx/sec
> 2016-12-27 16:52:10,391 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 252,807 tx/sec
> 2016-12-27 16:52:11,453 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 245,798 tx/sec
> 2016-12-27 16:52:12,457 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 225,747 tx/sec
> 2016-12-27 16:52:13,458 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 254,959 tx/sec
> 2016-12-27 16:52:14,487 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 249,093 tx/sec
> 2016-12-27 16:52:15,496 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 237,899 tx/sec
> 2016-12-27 16:52:16,517 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 237,790 tx/sec
> 2016-12-27 16:52:17,375 INFO (main) [RuleBase] ##################### disposeAll end
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.455 sec - in org.mk300.brms.perf.ReteOO_Accumulate
> Running org.mk300.brms.perf.ReteOO_Exists
> 2016-12-27 16:52:17,751 INFO (main) [RuleBase] ##################### RuleBase start
> 2016-12-27 16:52:19,431 INFO (main) [KieRepositoryImpl] KieModule was added: MemoryKieModule[releaseId=org.default:artifact:1.0.0-SNAPSHOT]
> 2016-12-27 16:52:19,643 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 0 tx/sec
> 2016-12-27 16:52:20,656 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 99,934 tx/sec
> 2016-12-27 16:52:21,679 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 308,091 tx/sec
> 2016-12-27 16:52:22,700 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 331,749 tx/sec
> 2016-12-27 16:52:23,721 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 351,276 tx/sec
> 2016-12-27 16:52:24,721 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 351,285 tx/sec
> 2016-12-27 16:52:25,732 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 349,222 tx/sec
> 2016-12-27 16:52:26,746 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 339,559 tx/sec
> 2016-12-27 16:52:27,754 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 328,000 tx/sec
> 2016-12-27 16:52:28,756 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 328,937 tx/sec
> 2016-12-27 16:52:29,647 INFO (main) [RuleBase] ##################### disposeAll end
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.056 sec - in org.mk300.brms.perf.ReteOO_Exists
> {noformat}
> NOTE: These tests run in different JVMs (reuseForks = false in pom.xml) so the order of test execution doesn't affect the performance.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2122) [Deployment overlay] Missing possiblity to print overlay mapping
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2122?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise updated WFCORE-2122:
-----------------------------------------
Summary: [Deployment overlay] Missing possiblity to print overlay mapping (was: [Deployment overlay] Missing possiblity do print overlay mapping)
> [Deployment overlay] Missing possiblity to print overlay mapping
> ----------------------------------------------------------------
>
> Key: WFCORE-2122
> URL: https://issues.jboss.org/browse/WFCORE-2122
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
> Labels: UserExperience
>
> Problem
> I don't see any possibility to print mapping specified by argument --content in existing overlays.
> Proposed solution
> Provide such functionality. I see 2 levels of granularity
> 1. Display mapping in overlay only
> 2. Display real mapping in specific deployment (not all deployment has to have all files defined by overlay)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months