November 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-651) Bindings do not cache actual values

by Marc Dzaebel (JIRA)

[ https://issues.jboss.org/browse/DROOLS-651?page=com.atlassian.jira.plugin... ] Marc Dzaebel edited comment on DROOLS-651 at 11/21/14 4:35 AM: --------------------------------------------------------------- I agree with your analysis. The user could even cache himself or use the workaround above, so there is no urgent need for a new feature. There are certainly more important ideas than optional cache and (if I'm the first) the need seems to be seldom (so reject is ok). The workaround might be valuable in the documentation too. Thanks to Davide, Mark and Mario Best regards, Marc was (Author: mdzaebel): I agree with your analysis. The user could even cache himself or use the workaround above, so there is no urgent need for a new feature. There are certainly more important ideas than optional cache and (if I'm the first) the need seems to be seldom (so reject is ok). The workaround might be valuable in the documentation too. Thanks to the Davide, Mark and Mario Best regards, Marc > Bindings do not cache actual values > ----------------------------------- > > Key: DROOLS-651 > URL: https://issues.jboss.org/browse/DROOLS-651 > Project: Drools > Issue Type: Enhancement > Affects Versions: 6.2.0.Beta3 > Environment: Win7, Drools 6.2.0 Beta3 (probably all Drools versions) > Reporter: Marc Dzaebel > Assignee: Mario Fusco > Priority: Minor > > Create sample Drools project, add following method to the Message class: > {noformat} public List<String> list() { > System.out.println("Call!"); > return Arrays.asList("one", "two"); > } {noformat} > sample.drl: > {noformat} > package com.sample > import com.sample.DroolsTest.Message; > import java.util.List; > import java.util.ArrayList; > > rule "" > when m : Message(L : list(), L.size>0) > then System.out.println("L:"+L); > end > {noformat} > Running the project will result in the following output: > {noformat} > Call! > Call! > L:[one, two] > {noformat} > So _list()_ is called *two* times (duplicate). This may be due to the replacement of "L" with _list()_ in the second constraint. This is ok for simple +getters+ as here HotSpot optimizes this away. However, long running methods will produce unnecessary overhead, especially if further constraints on "L" are added (which I verified produce additional calls to list()). So at least methods with one or more arguments should be saved in temporary variables that should be used in further constraints. A fix of this problem will certainly accelerate Drools performance on similar patterns. If this is not feasible, at least a comment should be added to the documentation. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1067) Integrate JGroups with core AS security infrastructure

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/WFLY-1067?page=com.atlassian.jira.plugin.... ] Bela Ban commented on WFLY-1067: -------------------------------- Not sure if this is an option but since David mentioned TSL / SSL: the socket factory JGroups uses to create sockets when TCP is used as transport is pluggable, so it could be replaced with an SSL/TLS impl. > Integrate JGroups with core AS security infrastructure > ------------------------------------------------------ > > Key: WFLY-1067 > URL: https://issues.jboss.org/browse/WFLY-1067 > Project: WildFly > Issue Type: Feature Request > Components: Clustering, Security > Reporter: Brian Stansberry > Assignee: Richard Achmatowicz > > Container task for better integrating JGroups security with overall AS security. The basic concept is the various security aware aspects of JGroups will expose an SPI, and the AS can create implementations of those SPIs that integrate with the AS security realms. The AS JGroups subsystem will inject the implementation into the JGroups runtime components. > Subtasks are for the various aspects. These can be done separately but a common overall design should be created to ensure a consistent approach is taken. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-271) The description of the default scanner attribute "scan-enabled" is incorrect.

by Emmanuel Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-271?page=com.atlassian.jira.plugin... ] Emmanuel Hugonnet updated WFCORE-271: ------------------------------------- Description: Description of problem: The description of the 'scan-enabled' attribute states "Flag indicating that all scanning (including initial scanning at startup) should be disabled." The default value of this attribute is "true", therefore I believe the description is incorrect. I propose that the description be changed to: "Flag indicating if all scanning (including initial scanning at startup) is enabled." > The description of the default scanner attribute "scan-enabled" is incorrect. > ------------------------------------------------------------------------------- > > Key: WFCORE-271 > URL: https://issues.jboss.org/browse/WFCORE-271 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha13 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Minor > > Description of problem: The description of the 'scan-enabled' attribute states "Flag indicating that all scanning (including initial scanning at startup) should be disabled." The default value of this attribute is "true", therefore I believe the description is incorrect. > I propose that the description be changed to: "Flag indicating if all scanning (including initial scanning at startup) is enabled." -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-271) The description of the default scanner attribute "scan-enabled" is incorrect.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-271?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated WFCORE-271: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1162982 > The description of the default scanner attribute "scan-enabled" is incorrect. > ------------------------------------------------------------------------------- > > Key: WFCORE-271 > URL: https://issues.jboss.org/browse/WFCORE-271 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha13 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Minor > > Description of problem: The description of the 'scan-enabled' attribute states "Flag indicating that all scanning (including initial scanning at startup) should be disabled." The default value of this attribute is "true", therefore I believe the description is incorrect. > I propose that the description be changed to: "Flag indicating if all scanning (including initial scanning at startup) is enabled." -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-271) The description of the default scanner attribute "scan-enabled" is incorrect.

by Emmanuel Hugonnet (JIRA)

Emmanuel Hugonnet created WFCORE-271: ---------------------------------------- Summary: The description of the default scanner attribute "scan-enabled" is incorrect. Key: WFCORE-271 URL: https://issues.jboss.org/browse/WFCORE-271 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 1.0.0.Alpha13 Reporter: Emmanuel Hugonnet Assignee: Emmanuel Hugonnet Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4079) Wildfly does not consider methods with no method-intf element when resolving transaction attributes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4079?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4079: ----------------------------------------------- Jan Martiska <jmartisk(a)redhat.com> changed the Status of [bug 1164060|https://bugzilla.redhat.com/show_bug.cgi?id=1164060] from ON_QA to VERIFIED > Wildfly does not consider methods with no method-intf element when resolving transaction attributes > --------------------------------------------------------------------------------------------------- > > Key: WFLY-4079 > URL: https://issues.jboss.org/browse/WFLY-4079 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > > If there is a method without a method-intf the ejb-jar.xml it will not be considered when determining the transaction attribute. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-651) Bindings do not cache actual values

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-651?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-651. -------------------------------- Resolution: Rejected > Bindings do not cache actual values > ----------------------------------- > > Key: DROOLS-651 > URL: https://issues.jboss.org/browse/DROOLS-651 > Project: Drools > Issue Type: Enhancement > Affects Versions: 6.2.0.Beta3 > Environment: Win7, Drools 6.2.0 Beta3 (probably all Drools versions) > Reporter: Marc Dzaebel > Assignee: Mario Fusco > Priority: Minor > > Create sample Drools project, add following method to the Message class: > {noformat} public List<String> list() { > System.out.println("Call!"); > return Arrays.asList("one", "two"); > } {noformat} > sample.drl: > {noformat} > package com.sample > import com.sample.DroolsTest.Message; > import java.util.List; > import java.util.ArrayList; > > rule "" > when m : Message(L : list(), L.size>0) > then System.out.println("L:"+L); > end > {noformat} > Running the project will result in the following output: > {noformat} > Call! > Call! > L:[one, two] > {noformat} > So _list()_ is called *two* times (duplicate). This may be due to the replacement of "L" with _list()_ in the second constraint. This is ok for simple +getters+ as here HotSpot optimizes this away. However, long running methods will produce unnecessary overhead, especially if further constraints on "L" are added (which I verified produce additional calls to list()). So at least methods with one or more arguments should be saved in temporary variables that should be used in further constraints. A fix of this problem will certainly accelerate Drools performance on similar patterns. If this is not feasible, at least a comment should be added to the documentation. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-178) ContentRepositoryImpl should not call File.deleteOnExit

by Emmanuel Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-178?page=com.atlassian.jira.plugin... ] Emmanuel Hugonnet updated WFCORE-178: ------------------------------------- Fix Version/s: 1.0.0.Alpha14 > ContentRepositoryImpl should not call File.deleteOnExit > ------------------------------------------------------- > > Key: WFCORE-178 > URL: https://issues.jboss.org/browse/WFCORE-178 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Emmanuel Hugonnet > Fix For: 1.0.0.Alpha14 > > > ContentRepositoryImpl.removeContent calls File.deleteOnExit if it can't delete the content or parent dirs. This is very wrong: > 1) The grandparent dir may have other children completed unrelated to the item being removed. > 2) The content in question may have been restored before process exit. For example, a deployment is undeployed, and then a while later the same bits are uploaded again. > 3) File.deleteOnExit is a small memory leak. This one's relatively minor. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-178) ContentRepositoryImpl should not call File.deleteOnExit

by Emmanuel Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-178?page=com.atlassian.jira.plugin... ] Emmanuel Hugonnet resolved WFCORE-178. -------------------------------------- Resolution: Done > ContentRepositoryImpl should not call File.deleteOnExit > ------------------------------------------------------- > > Key: WFCORE-178 > URL: https://issues.jboss.org/browse/WFCORE-178 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Emmanuel Hugonnet > Fix For: 1.0.0.Alpha14 > > > ContentRepositoryImpl.removeContent calls File.deleteOnExit if it can't delete the content or parent dirs. This is very wrong: > 1) The grandparent dir may have other children completed unrelated to the item being removed. > 2) The content in question may have been restored before process exit. For example, a deployment is undeployed, and then a while later the same bits are uploaded again. > 3) File.deleteOnExit is a small memory leak. This one's relatively minor. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-178) ContentRepositoryImpl should not call File.deleteOnExit

by Emmanuel Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-178?page=com.atlassian.jira.plugin... ] Emmanuel Hugonnet reopened WFCORE-178: -------------------------------------- > ContentRepositoryImpl should not call File.deleteOnExit > ------------------------------------------------------- > > Key: WFCORE-178 > URL: https://issues.jboss.org/browse/WFCORE-178 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Emmanuel Hugonnet > > ContentRepositoryImpl.removeContent calls File.deleteOnExit if it can't delete the content or parent dirs. This is very wrong: > 1) The grandparent dir may have other children completed unrelated to the item being removed. > 2) The content in question may have been restored before process exit. For example, a deployment is undeployed, and then a while later the same bits are uploaded again. > 3) File.deleteOnExit is a small memory leak. This one's relatively minor. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2014