May 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8827) Upgrade JBoss EJB Client to 4.0.0.Beta30

by David Lloyd (JIRA)

David Lloyd created WFLY-8827: --------------------------------- Summary: Upgrade JBoss EJB Client to 4.0.0.Beta30 Key: WFLY-8827 URL: https://issues.jboss.org/browse/WFLY-8827 Project: WildFly Issue Type: Component Upgrade Reporter: David Lloyd Assignee: David Lloyd Fix For: 11.0.0.Beta1 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2840) Upgrade Aesh to 0.66.17 from 0.66.16

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2840?page=com.atlassian.jira.plugi... ] Chao Wang reassigned WFCORE-2840: --------------------------------- Assignee: Chao Wang (was: Petr Sakař) > Upgrade Aesh to 0.66.17 from 0.66.16 > ------------------------------------ > > Key: WFCORE-2840 > URL: https://issues.jboss.org/browse/WFCORE-2840 > Project: WildFly Core > Issue Type: Component Upgrade > Components: CLI > Reporter: Chao Wang > Assignee: Chao Wang > > Upgrade AESH to 0.66.17 from 0.66.16 to fix JBEAP-10903 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-124) Ability to provide exception producer

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-124?page=com.atlassian.jira.plugi... ] David Lloyd commented on LOGTOOL-124: ------------------------------------- Nice! > Ability to provide exception producer > ------------------------------------- > > Key: LOGTOOL-124 > URL: https://issues.jboss.org/browse/LOGTOOL-124 > Project: Log Tool > Issue Type: Feature Request > Reporter: David Lloyd > Assignee: James Perkins > Priority: Minor > Fix For: 2.1.0.Alpha3 > > > Sometimes you must use the same exception message for many different types of exception. It would be nice if you could give a parameter which can produce an exception, like this: > {code} > public interface MyLogs { > // ... > @Message(id = 1234, "The operation failed due to %s") > <T extends Throwable> T operationFailed(@Producer Function<String, T> fn, String thing); > } > {code} > And later at usage: > {code} > // ... > throw MyLogs.log.operationFailed(IOException::new, "thingy"); > {code} > A valid function parameter must return a type which is equal or assignable to the return type, and is assignable to Throwable. Other than that, it can be treated the same as as if you were dealing with a constructor class that has exactly one constructor, using the same matching/inference logic, meaning you could also accept BiFunction which accepts two arguments. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-124) Ability to provide exception producer

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-124?page=com.atlassian.jira.plugi... ] James Perkins commented on LOGTOOL-124: --------------------------------------- Excellent. It looks like I've got it generating the correct source then. I just need to finish up the validation portion. > Ability to provide exception producer > ------------------------------------- > > Key: LOGTOOL-124 > URL: https://issues.jboss.org/browse/LOGTOOL-124 > Project: Log Tool > Issue Type: Feature Request > Reporter: David Lloyd > Assignee: James Perkins > Priority: Minor > Fix For: 2.1.0.Alpha3 > > > Sometimes you must use the same exception message for many different types of exception. It would be nice if you could give a parameter which can produce an exception, like this: > {code} > public interface MyLogs { > // ... > @Message(id = 1234, "The operation failed due to %s") > <T extends Throwable> T operationFailed(@Producer Function<String, T> fn, String thing); > } > {code} > And later at usage: > {code} > // ... > throw MyLogs.log.operationFailed(IOException::new, "thingy"); > {code} > A valid function parameter must return a type which is equal or assignable to the return type, and is assignable to Throwable. Other than that, it can be treated the same as as if you were dealing with a constructor class that has exactly one constructor, using the same matching/inference logic, meaning you could also accept BiFunction which accepts two arguments. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-124) Ability to provide exception producer

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-124?page=com.atlassian.jira.plugi... ] David Lloyd commented on LOGTOOL-124: ------------------------------------- Yes that sounds correct. > Ability to provide exception producer > ------------------------------------- > > Key: LOGTOOL-124 > URL: https://issues.jboss.org/browse/LOGTOOL-124 > Project: Log Tool > Issue Type: Feature Request > Reporter: David Lloyd > Assignee: James Perkins > Priority: Minor > Fix For: 2.1.0.Alpha3 > > > Sometimes you must use the same exception message for many different types of exception. It would be nice if you could give a parameter which can produce an exception, like this: > {code} > public interface MyLogs { > // ... > @Message(id = 1234, "The operation failed due to %s") > <T extends Throwable> T operationFailed(@Producer Function<String, T> fn, String thing); > } > {code} > And later at usage: > {code} > // ... > throw MyLogs.log.operationFailed(IOException::new, "thingy"); > {code} > A valid function parameter must return a type which is equal or assignable to the return type, and is assignable to Throwable. Other than that, it can be treated the same as as if you were dealing with a constructor class that has exactly one constructor, using the same matching/inference logic, meaning you could also accept BiFunction which accepts two arguments. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-124) Ability to provide exception producer

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-124?page=com.atlassian.jira.plugi... ] James Perkins commented on LOGTOOL-124: --------------------------------------- Just to confirm. For a {{Function}} the signature must resolve to {{java.util.function.Function<String, Throwable>}} where {{String}} is the message. For a {{BiFunction}} the signature must resolve to {{java.util.function.BiFunction<String, Throwable, Throwable}} where the {{String}} is the message and the first {{Throwable}} is the cause. Does that sound correct? Example of the current output for a function: {code:java|title=Interface} @Message("The operation failed due to %s") <T extends Throwable> T operationFailed(@Producer Function<String, T> function, String op); {code} {code:java|title=Generated} private static final String operationFailed = "The operation failed due to %s"; protected String operationFailed$str() { return operationFailed; } @Override public final <T extends Throwable> T operationFailed(final java.util.function.Function<String, T> function, final String op) { final T result = function.apply(String.format(getLoggingLocale(), operationFailed$str(), op)); final StackTraceElement[] st = result.getStackTrace(); result.setStackTrace(Arrays.copyOfRange(st, 1, st.length)); return result; } {code} > Ability to provide exception producer > ------------------------------------- > > Key: LOGTOOL-124 > URL: https://issues.jboss.org/browse/LOGTOOL-124 > Project: Log Tool > Issue Type: Feature Request > Reporter: David Lloyd > Assignee: James Perkins > Priority: Minor > Fix For: 2.1.0.Alpha3 > > > Sometimes you must use the same exception message for many different types of exception. It would be nice if you could give a parameter which can produce an exception, like this: > {code} > public interface MyLogs { > // ... > @Message(id = 1234, "The operation failed due to %s") > <T extends Throwable> T operationFailed(@Producer Function<String, T> fn, String thing); > } > {code} > And later at usage: > {code} > // ... > throw MyLogs.log.operationFailed(IOException::new, "thingy"); > {code} > A valid function parameter must return a type which is equal or assignable to the return type, and is assignable to Throwable. Other than that, it can be treated the same as as if you were dealing with a constructor class that has exactly one constructor, using the same matching/inference logic, meaning you could also accept BiFunction which accepts two arguments. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1190) Capture Subject into AuthenticationConfiguration

by David Lloyd (JIRA)

David Lloyd created ELY-1190: -------------------------------- Summary: Capture Subject into AuthenticationConfiguration Key: ELY-1190 URL: https://issues.jboss.org/browse/ELY-1190 Project: WildFly Elytron Issue Type: Enhancement Components: API / SPI, Authentication Client, SASL Reporter: David Lloyd Assignee: David Lloyd Fix For: 1.1.0.Beta47 When an AuthenticationConfiguration is captured, it represents the identity being authenticated. Some mechanisms require a Subject to be established in order to retrieve the identity and credentials to use. The combination of these two facts implies that the AuthenticationConfiguration must encapsulate the Subject that was present at the time the configuration is realized by the ACCC. This Subject in turn must be propagated to the SASL authentication client (and later, possibly SSLContext to support KRB mechanisms). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8469) upgrade to JSF 2.3

by Erick de Oliveira Leal (JIRA)

[ https://issues.jboss.org/browse/WFLY-8469?page=com.atlassian.jira.plugin.... ] Erick de Oliveira Leal closed WFLY-8469. ---------------------------------------- Resolution: Duplicate Issue duplicate of https://issues.jboss.org/browse/WFLY-6462 > upgrade to JSF 2.3 > ------------------ > > Key: WFLY-8469 > URL: https://issues.jboss.org/browse/WFLY-8469 > Project: WildFly > Issue Type: Component Upgrade > Components: JSF > Affects Versions: 11.0.0.Alpha1 > Reporter: Erick de Oliveira Leal > Assignee: Farah Juma > Priority: Minor > > JSF 2.3 is out http://arjan-tijms.omnifaces.org/2017/03/jsf-23-released.html -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1576) Intermittently Rule getting executed Twice while using Agenda Groups and Order

by Siyad Theyparambil Mohammed (JIRA)

Siyad Theyparambil Mohammed created DROOLS-1576: --------------------------------------------------- Summary: Intermittently Rule getting executed Twice while using Agenda Groups and Order Key: DROOLS-1576 URL: https://issues.jboss.org/browse/DROOLS-1576 Project: Drools Issue Type: Bug Reporter: Siyad Theyparambil Mohammed Assignee: Edson Tirelli Attachments: CreateDedCharges-Rule.txt, CreateFLATFeeCharges-Rule.txt, CreatePSRLCreditCharges-Rule.txt, CreateRPERFeeCharges-Rule.txt, First Execution Result.txt, Second Execution Result.txt Hi, We have 4 rules which are divided into 2 agenda groups ||Rule||Agenda Group|| |CreateRPERFeeCharges|createcharges| |CreateFLATFeeCharges|createcharges| |CreateDedCharges|createcharges| |CreatePSRLCreditCharges|postrule| Focus is set on the agenda group in the following order, 1. postrule 2. createcharges The Rule “CreatePSRLCreditCharges” has named consequences. Based on the accumulated Charge amount we want one of the two consequence to be executed. If you notice the “First Execution Result.txt” this rule was executed twice once for the “IF” and second for “ELSE” but during the second trigger of the rule execution it fired the rule only once with the same data. Could you please look/check and let us know if we have an issue with the rule or is this a bug in drools? We have attached the all the 4 drls and the results of the 2 execution that was triggered. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-124) Ability to provide exception producer

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-124?page=com.atlassian.jira.plugi... ] James Perkins commented on LOGTOOL-124: --------------------------------------- Good point. Annotation it is. > Ability to provide exception producer > ------------------------------------- > > Key: LOGTOOL-124 > URL: https://issues.jboss.org/browse/LOGTOOL-124 > Project: Log Tool > Issue Type: Feature Request > Reporter: David Lloyd > Assignee: James Perkins > Priority: Minor > Fix For: 2.1.0.Alpha3 > > > Sometimes you must use the same exception message for many different types of exception. It would be nice if you could give a parameter which can produce an exception, like this: > {code} > public interface MyLogs { > // ... > @Message(id = 1234, "The operation failed due to %s") > <T extends Throwable> T operationFailed(@Producer Function<String, T> fn, String thing); > } > {code} > And later at usage: > {code} > // ... > throw MyLogs.log.operationFailed(IOException::new, "thingy"); > {code} > A valid function parameter must return a type which is equal or assignable to the return type, and is assignable to Throwable. Other than that, it can be treated the same as as if you were dealing with a constructor class that has exactly one constructor, using the same matching/inference logic, meaning you could also accept BiFunction which accepts two arguments. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 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 May 2017