January 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-2272) [DMN Editor] Move Editor controls inline

by Michael Anstis (JIRA)

Michael Anstis created DROOLS-2272: -------------------------------------- Summary: [DMN Editor] Move Editor controls inline Key: DROOLS-2272 URL: https://issues.jboss.org/browse/DROOLS-2272 Project: Drools Issue Type: Feature Request Components: DMN Editor Affects Versions: 7.5.0.Final Reporter: Michael Anstis Assignee: Michael Anstis Expression Editors have a row of controls to add row, column, change Hit Policy etc. These all need moving "inline" into the editor itself. The content of the new context menu will be driven by the cell in the Expression grid that was (single) clicked. Double click continues to edit the cell. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-132) Support low-metaspace bundles/classes

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-132?page=com.atlassian.jira.plugi... ] David Lloyd commented on LOGTOOL-132: ------------------------------------- I don't think we'll see a huge drop in performance in the single-logger case: you're still reading the same number of bytes out of the zip file. The biggest question in my mind is, how do we cache the set of strings so they can be shared across instances? Having a single-entry cache that has a locale+string array would probably be good enough. We don't change locales often (well, ever, really) but if we do, I'd expect that it's OK to take a perf hit in that case. > Support low-metaspace bundles/classes > ------------------------------------- > > Key: LOGTOOL-132 > URL: https://issues.jboss.org/browse/LOGTOOL-132 > Project: Log Tool > Issue Type: Enhancement > Reporter: David Lloyd > Priority: Critical > > Metaspace is at a premium in the application server environment, and the number one consumer is presently generated log classes. > Introduce a leaner variation on generated classes with the following requirements: > * The generated class must be {{final}} > * The generated class must contain no message strings > * The generated class must accept both a {{Logger}} and a {{Locale}}, and load its resources from a file based on that information > * The usage of Java 8's locale lookup functionality should be considered, to support language tags etc.; a helper utility could be introduced into {{jboss-logging}} for this > Here are some implementation ideas: > * Option 1: The resource files contain only messages, one per line, loaded directly into a {{String[]}} instance field in the implementation class; each logging method uses a hard-coded array index to access its message > ** A key advantage is that the implementation class is very small, and consumes very little metaspace; also, it is fast, requiring only an array lookup to acquire the string > ** A disadvantage is, any change to the message set invalidates all the locale files, which must then be regenerated > ** Also, each locale file must contain all messages, unless a fallback mechanism is used (e.g. an empty line signifies that the string should come from the parent locale) > * Option 2: The resource files contain key-value pairs, with the key being equal to the method name > ** Advantage: the file is not invalidated if a key is added, and sub-locales can inherit more easily from parent locales > ** Disadvantage: the added overhead of mapping lines to methods (for example, using a switch statement to map method names to fixed indexes, or loading the messages into a hash table e.g. {{HashMap}}) will fill metaspace or impact performance, or both -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-132) Support low-metaspace bundles/classes

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-132?page=com.atlassian.jira.plugi... ] James Perkins commented on LOGTOOL-132: --------------------------------------- I'll see what making the class final does (I'll have to read what Andrew wrote about it again too). On my preliminary test, not having a final test but loading properties for translations, the metaspace size for the classes decreases about 11%, but the total metaspace size increased by about 1%. I'll test making it final and see what the difference is. I've not tested performance at all yet, but I'll definitely test that too. I do have no doubt there will be a performance impact, but hopefully we can keep it at a minimum. One option *might* be we have a flag which will generate the original implementation for performance or lookups if metaspace is the concern. > Support low-metaspace bundles/classes > ------------------------------------- > > Key: LOGTOOL-132 > URL: https://issues.jboss.org/browse/LOGTOOL-132 > Project: Log Tool > Issue Type: Enhancement > Reporter: David Lloyd > Priority: Critical > > Metaspace is at a premium in the application server environment, and the number one consumer is presently generated log classes. > Introduce a leaner variation on generated classes with the following requirements: > * The generated class must be {{final}} > * The generated class must contain no message strings > * The generated class must accept both a {{Logger}} and a {{Locale}}, and load its resources from a file based on that information > * The usage of Java 8's locale lookup functionality should be considered, to support language tags etc.; a helper utility could be introduced into {{jboss-logging}} for this > Here are some implementation ideas: > * Option 1: The resource files contain only messages, one per line, loaded directly into a {{String[]}} instance field in the implementation class; each logging method uses a hard-coded array index to access its message > ** A key advantage is that the implementation class is very small, and consumes very little metaspace; also, it is fast, requiring only an array lookup to acquire the string > ** A disadvantage is, any change to the message set invalidates all the locale files, which must then be regenerated > ** Also, each locale file must contain all messages, unless a fallback mechanism is used (e.g. an empty line signifies that the string should come from the parent locale) > * Option 2: The resource files contain key-value pairs, with the key being equal to the method name > ** Advantage: the file is not invalidated if a key is added, and sub-locales can inherit more easily from parent locales > ** Disadvantage: the added overhead of mapping lines to methods (for example, using a switch statement to map method names to fixed indexes, or loading the messages into a hash table e.g. {{HashMap}}) will fill metaspace or impact performance, or both -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2270) [DMN Editor] Replace 'Return to DRG' button with Link

by Michael Anstis (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2270?page=com.atlassian.jira.plugi... ] Michael Anstis updated DROOLS-2270: ----------------------------------- Summary: [DMN Editor] Replace 'Return to DRG' button with Link (was: [DMN Editor] Replace "Return to DRG" button with Link) > [DMN Editor] Replace 'Return to DRG' button with Link > ----------------------------------------------------- > > Key: DROOLS-2270 > URL: https://issues.jboss.org/browse/DROOLS-2270 > Project: Drools > Issue Type: Feature Request > Components: DMN Editor > Affects Versions: 7.5.0.Final > Reporter: Michael Anstis > Assignee: Michael Anstis > > The "Return to DRG" button should be replaced with a "<< Back to XXX" link. > XXX should be the name of the DRG from whence the User came. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1495) Stack overflow in WildFlySecurityManager#checkPermission(Permission, AccessControlContext)

by David Lloyd (JIRA)

David Lloyd created ELY-1495: -------------------------------- Summary: Stack overflow in WildFlySecurityManager#checkPermission(Permission, AccessControlContext) Key: ELY-1495 URL: https://issues.jboss.org/browse/ELY-1495 Project: WildFly Elytron Issue Type: Bug Components: Security Manager Affects Versions: 1.2.0.Beta11 Reporter: David Lloyd Assignee: David Lloyd Priority: Blocker Fix For: 1.2.0.Beta12 Maybe use Unsafe instead. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3542) Elytron JDBC realm password mapping is not consistent with underlying implementation

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3542?page=com.atlassian.jira.plugi... ] David Lloyd updated WFCORE-3542: -------------------------------- Forum Reference: https://developer.jboss.org/message/979730#979730 > Elytron JDBC realm password mapping is not consistent with underlying implementation > ------------------------------------------------------------------------------------ > > Key: WFCORE-3542 > URL: https://issues.jboss.org/browse/WFCORE-3542 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: David Lloyd > Assignee: Darran Lofthouse > Fix For: 4.0.0.Alpha7 > > > There is no way to configure the JDBC realm to use modular crypt in WildFly, even though the underlying realm does support it. > The problem is that the {{salt-index}} and {{itereration-count-index}} attributes should be optional, and if they not given, a value of {{-1}} should be passed to the mapper. By omitting both of these values, the database column values will then be recognized as modular-crypt strings. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3542) Elytron JDBC realm password mapping is not consistent with underlying implementation

by David Lloyd (JIRA)

David Lloyd created WFCORE-3542: ----------------------------------- Summary: Elytron JDBC realm password mapping is not consistent with underlying implementation Key: WFCORE-3542 URL: https://issues.jboss.org/browse/WFCORE-3542 Project: WildFly Core Issue Type: Bug Components: Security Reporter: David Lloyd Assignee: Darran Lofthouse Fix For: 4.0.0.Alpha7 There is no way to configure the JDBC realm to use modular crypt in WildFly, even though the underlying realm does support it. The problem is that the {{salt-index}} and {{itereration-count-index}} attributes should be optional, and if they not given, a value of {{-1}} should be passed to the mapper. By omitting both of these values, the database column values will then be recognized as modular-crypt strings. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2271) Retrieve all rules associated to a ruleflow-group

by Edson Tirelli (JIRA)

Edson Tirelli created DROOLS-2271: ------------------------------------- Summary: Retrieve all rules associated to a ruleflow-group Key: DROOLS-2271 URL: https://issues.jboss.org/browse/DROOLS-2271 Project: Drools Issue Type: Enhancement Components: core engine Affects Versions: 7.5.0.Final Reporter: Richard Bourner Assignee: Mario Fusco Priority: Minor It would be very useful to be able to retrieve the list of all business rules associated to a ruleflow-group when editing a ruleflow (ie process) and clicking a RuleTask. Maybe another way to do it would be via a search using metadata (such as ruleflow-group). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2269) Retrieve all rules associated to a ruleflow-group

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2269?page=com.atlassian.jira.plugi... ] Edson Tirelli commented on DROOLS-2269: --------------------------------------- There are two sides to this requirement. One is in core, to which [~mfusco] can take a look, but the other one is in the workbench. I will clone the ticket for that. > Retrieve all rules associated to a ruleflow-group > ------------------------------------------------- > > Key: DROOLS-2269 > URL: https://issues.jboss.org/browse/DROOLS-2269 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 7.5.0.Final > Reporter: Richard Bourner > Assignee: Mario Fusco > Priority: Minor > > It would be very useful to be able to retrieve the list of all business rules associated to a ruleflow-group when editing a ruleflow (ie process) and clicking a RuleTask. > Maybe another way to do it would be via a search using metadata (such as ruleflow-group). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2269) Retrieve all rules associated to a ruleflow-group

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2269?page=com.atlassian.jira.plugi... ] Edson Tirelli updated DROOLS-2269: ---------------------------------- Component/s: core engine > Retrieve all rules associated to a ruleflow-group > ------------------------------------------------- > > Key: DROOLS-2269 > URL: https://issues.jboss.org/browse/DROOLS-2269 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 7.5.0.Final > Reporter: Richard Bourner > Assignee: Edson Tirelli > Priority: Minor > > It would be very useful to be able to retrieve the list of all business rules associated to a ruleflow-group when editing a ruleflow (ie process) and clicking a RuleTask. > Maybe another way to do it would be via a search using metadata (such as ruleflow-group). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

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 January 2018