April 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-777) Variable length argument lists lose arguments in MVEL

by Myroslava Dzikovska (JIRA)

Myroslava Dzikovska created DROOLS-777: ------------------------------------------ Summary: Variable length argument lists lose arguments in MVEL Key: DROOLS-777 URL: https://issues.jboss.org/browse/DROOLS-777 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 6.1.0.Final Environment: RHEL 6, OpenJDK Runtime Environment (rhel-2.5.5.1.el6_6-x86_64 u79-b14) Reporter: Myroslava Dzikovska Assignee: Mario Fusco When I use a method with variable number of arguments (e.g., String... args) in MVEL, the first one is passed on, and the others are discarded, leading to confusing and difficult to debug bugs. It should either support this, or report a compilation error. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-114) jboss-logging OSGi bundle requiring optional packages

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/JBLOGGING-114?page=com.atlassian.jira.plu... ] Brett Meyer updated JBLOGGING-114: ---------------------------------- Summary: jboss-logging OSGi bundle requiring optional packages (was: jboss-logging's OSGi metadata is somehow wrong) > jboss-logging OSGi bundle requiring optional packages > ----------------------------------------------------- > > Key: JBLOGGING-114 > URL: https://issues.jboss.org/browse/JBLOGGING-114 > Project: JBoss Logging > Issue Type: Bug > Reporter: Steve Ebersole > Assignee: James Perkins > > Apparently jboss-logging places a non-optional dependency on log4j: > {noformat} > [22:04] <sebersole> dmlloyd: if you are around... > [22:04] <sebersole> we are having trouble with hibernate-osgi because of jboss-logging jar > [22:04] <sebersole> it essentially requires log4j > [22:05] <sebersole> [22:03] <brmeyer> their manifest has resolution:=optional for every org.apache.log4j package *except* for .message > [22:05] <sebersole> tbh, thats all just gibberish to me. he might as well be speaking chinese > [22:06] <sebersole> but when we try to deploy into karaf, we do get errors installing our features because the jboss-logging bundle fails to start because log4j isnt installed > [22:06] <sebersole> it works when we install log4j first as well > [22:06] <sebersole> even though we are not using log4j > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBEE-160) jboss-transaction-api OSGi bundle requiring optional packages

by Brett Meyer (JIRA)

Brett Meyer created JBEE-160: -------------------------------- Summary: jboss-transaction-api OSGi bundle requiring optional packages Key: JBEE-160 URL: https://issues.jboss.org/browse/JBEE-160 Project: JBoss JavaEE Spec APIs Issue Type: Bug Reporter: Brett Meyer Assignee: Shelly McGowan The jboss-transaction-api_1.2_spec OSGi bundle requires the 'javax.enterprise.context'. Instead, that should be optional, right? cdi-api shouldn't be required to simply use jta. Thanks! -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-114) jboss-logging's OSGi metadata is somehow wrong

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/JBLOGGING-114?page=com.atlassian.jira.plu... ] Brett Meyer commented on JBLOGGING-114: --------------------------------------- Nope, that's it. For this specific one, jboss-logging simply needs to make org.apache.logging.log4j.message optional in the manifest, I believe. > jboss-logging's OSGi metadata is somehow wrong > ---------------------------------------------- > > Key: JBLOGGING-114 > URL: https://issues.jboss.org/browse/JBLOGGING-114 > Project: JBoss Logging > Issue Type: Bug > Reporter: Steve Ebersole > Assignee: James Perkins > > Apparently jboss-logging places a non-optional dependency on log4j: > {noformat} > [22:04] <sebersole> dmlloyd: if you are around... > [22:04] <sebersole> we are having trouble with hibernate-osgi because of jboss-logging jar > [22:04] <sebersole> it essentially requires log4j > [22:05] <sebersole> [22:03] <brmeyer> their manifest has resolution:=optional for every org.apache.log4j package *except* for .message > [22:05] <sebersole> tbh, thats all just gibberish to me. he might as well be speaking chinese > [22:06] <sebersole> but when we try to deploy into karaf, we do get errors installing our features because the jboss-logging bundle fails to start because log4j isnt installed > [22:06] <sebersole> it works when we install log4j first as well > [22:06] <sebersole> even though we are not using log4j > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4468) Remove JGroups subsystem transformers for version < 1.2.0

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-4468?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-4468: ------------------------------- Fix Version/s: 9.0.0.CR1 > Remove JGroups subsystem transformers for version < 1.2.0 > --------------------------------------------------------- > > Key: WFLY-4468 > URL: https://issues.jboss.org/browse/WFLY-4468 > Project: WildFly > Issue Type: Sub-task > Components: Clustering > Affects Versions: 9.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 9.0.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4571) Merge the wildfly BOMs into a single BOM

by Paul Gier (JIRA)

[ https://issues.jboss.org/browse/WFLY-4571?page=com.atlassian.jira.plugin.... ] Paul Gier commented on WFLY-4571: --------------------------------- The imported dependencies should still only affect the versions of dependencies that the user has already added to their pom. But I agree it kind of makes sense to keep these separate. I'll update the PR. > Merge the wildfly BOMs into a single BOM > ---------------------------------------- > > Key: WFLY-4571 > URL: https://issues.jboss.org/browse/WFLY-4571 > Project: WildFly > Issue Type: Enhancement > Reporter: Paul Gier > Assignee: Paul Gier > > We had some discussion on the jbossdeveloper list [1] about merging the current wildfly/eap boms into a single one instead of a separate bom for each use case. > The only problematic BOM might be the hibernate3 bom because this includes dependencies which conflict with the hibernate 4 bom. So the hibernate 3 bom will probably need to remain separate. > [1]http://lists.jboss.org/pipermail/jbossdeveloper/2015-April/000347.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-775) Performance degradation with objects with many properties in working memory.

by Federico Bertola (JIRA)

[ https://issues.jboss.org/browse/DROOLS-775?page=com.atlassian.jira.plugin... ] Federico Bertola updated DROOLS-775: ------------------------------------ Steps to Reproduce: Unzip the attached project. For using drools5: {{mvn test -Dtest=org.acme.test.drools5.DroolsPerformance -Pdrools5}} For using drools6: {{mvn test -Dtest=org.acme.test.drools6.DroolsPerformance -Pdrools6}} was: Unzip the attached project. For using drools5: {{mvn test -Pdrools5}} For using drools6: {{mvn test -Pdrools6}} > Performance degradation with objects with many properties in working memory. > ---------------------------------------------------------------------------- > > Key: DROOLS-775 > URL: https://issues.jboss.org/browse/DROOLS-775 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.0.0.Final, 6.1.0.Final, 6.2.0.Final > Environment: Ubuntu 14.10 x64, jdk 8 > Reporter: Federico Bertola > Assignee: Mario Fusco > Labels: regression > Attachments: drools-test.zip, drools-test_new.zip > > > I experience some major performance degradation while migrating from drools 5.0.1 to 6.x. I'm inserting objects with many properties into the working memory and firing some very basic rules which will match against a very small subset of those properties. I expected that the older version of Drools, which uses pure reflection, to be somewhat slower than the newer, which uses some clever ASM optimization., but this is not the case. I've also noticed that if the required properties are scattered across multiple level of hierarchy, the performance issue will aggravate. > For example, after 100k iterations: > droosl 5.0.1 > -- Meters ---------------------------------------------------------------------- > org.acme.test.drools5.DroolsPerformance.analized > count = 100000 > mean rate = 549.27 events/second > ... > drools 6.2.0.Final > -- Meters ---------------------------------------------------------------------- > org.acme.test.drools6.DroolsPerformance.analized > count = 100000 > mean rate = 198.58 events/second > ... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-775) Performance degradation with objects with many properties in working memory.

by Federico Bertola (JIRA)

[ https://issues.jboss.org/browse/DROOLS-775?page=com.atlassian.jira.plugin... ] Federico Bertola commented on DROOLS-775: ----------------------------------------- As per request, I removed the code that generate new methods bytecode. > Performance degradation with objects with many properties in working memory. > ---------------------------------------------------------------------------- > > Key: DROOLS-775 > URL: https://issues.jboss.org/browse/DROOLS-775 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.0.0.Final, 6.1.0.Final, 6.2.0.Final > Environment: Ubuntu 14.10 x64, jdk 8 > Reporter: Federico Bertola > Assignee: Mario Fusco > Labels: regression > Attachments: drools-test.zip, drools-test_new.zip > > > I experience some major performance degradation while migrating from drools 5.0.1 to 6.x. I'm inserting objects with many properties into the working memory and firing some very basic rules which will match against a very small subset of those properties. I expected that the older version of Drools, which uses pure reflection, to be somewhat slower than the newer, which uses some clever ASM optimization., but this is not the case. I've also noticed that if the required properties are scattered across multiple level of hierarchy, the performance issue will aggravate. > For example, after 100k iterations: > droosl 5.0.1 > -- Meters ---------------------------------------------------------------------- > org.acme.test.drools5.DroolsPerformance.analized > count = 100000 > mean rate = 549.27 events/second > ... > drools 6.2.0.Final > -- Meters ---------------------------------------------------------------------- > org.acme.test.drools6.DroolsPerformance.analized > count = 100000 > mean rate = 198.58 events/second > ... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-775) Performance degradation with objects with many properties in working memory.

by Federico Bertola (JIRA)

[ https://issues.jboss.org/browse/DROOLS-775?page=com.atlassian.jira.plugin... ] Federico Bertola updated DROOLS-775: ------------------------------------ Attachment: drools-test_new.zip > Performance degradation with objects with many properties in working memory. > ---------------------------------------------------------------------------- > > Key: DROOLS-775 > URL: https://issues.jboss.org/browse/DROOLS-775 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.0.0.Final, 6.1.0.Final, 6.2.0.Final > Environment: Ubuntu 14.10 x64, jdk 8 > Reporter: Federico Bertola > Assignee: Mario Fusco > Labels: regression > Attachments: drools-test.zip, drools-test_new.zip > > > I experience some major performance degradation while migrating from drools 5.0.1 to 6.x. I'm inserting objects with many properties into the working memory and firing some very basic rules which will match against a very small subset of those properties. I expected that the older version of Drools, which uses pure reflection, to be somewhat slower than the newer, which uses some clever ASM optimization., but this is not the case. I've also noticed that if the required properties are scattered across multiple level of hierarchy, the performance issue will aggravate. > For example, after 100k iterations: > droosl 5.0.1 > -- Meters ---------------------------------------------------------------------- > org.acme.test.drools5.DroolsPerformance.analized > count = 100000 > mean rate = 549.27 events/second > ... > drools 6.2.0.Final > -- Meters ---------------------------------------------------------------------- > org.acme.test.drools6.DroolsPerformance.analized > count = 100000 > mean rate = 198.58 events/second > ... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-114) jboss-logging's OSGi metadata is somehow wrong

by Steve Ebersole (JIRA)

[ https://issues.jboss.org/browse/JBLOGGING-114?page=com.atlassian.jira.plu... ] Steve Ebersole commented on JBLOGGING-114: ------------------------------------------ I will have more information today. Brett is helping me debug the Karaf issues. JBoss Logging is not the only one. Quite a few WIldFly jars have problems. The plan is to follow up with an email to wildfly-dev regarding all of them. The others I know for sure are all the wildfly "spec" jars (aside from JPA, of course :). Moving to the geronimo jars fix the issues there. Anyway, will keep you updated. Thanks! > jboss-logging's OSGi metadata is somehow wrong > ---------------------------------------------- > > Key: JBLOGGING-114 > URL: https://issues.jboss.org/browse/JBLOGGING-114 > Project: JBoss Logging > Issue Type: Bug > Reporter: Steve Ebersole > Assignee: James Perkins > > Apparently jboss-logging places a non-optional dependency on log4j: > {noformat} > [22:04] <sebersole> dmlloyd: if you are around... > [22:04] <sebersole> we are having trouble with hibernate-osgi because of jboss-logging jar > [22:04] <sebersole> it essentially requires log4j > [22:05] <sebersole> [22:03] <brmeyer> their manifest has resolution:=optional for every org.apache.log4j package *except* for .message > [22:05] <sebersole> tbh, thats all just gibberish to me. he might as well be speaking chinese > [22:06] <sebersole> but when we try to deploy into karaf, we do get errors installing our features because the jboss-logging bundle fails to start because log4j isnt installed > [22:06] <sebersole> it works when we install log4j first as well > [22:06] <sebersole> even though we are not using log4j > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2015