December 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-283) Investigate Elytron and gssproxy interoperability

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on ELY-283: --------------------------------- Do you have the trace output that immediately precedes the JVM crash? That might help find the offending native code. > Investigate Elytron and gssproxy interoperability > ------------------------------------------------- > > Key: ELY-283 > URL: https://issues.jboss.org/browse/ELY-283 > Project: WildFly Elytron > Issue Type: Task > Components: SASL > Reporter: Peter Skopek > Assignee: Jan Kalina > Fix For: 2.0.0.Alpha1 > > Attachments: openjdk-patch-native-mechs.patch > > > Investigate Elytron and gssproxy interoperability. > https://fedorahosted.org/gss-proxy/ -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFLY-7247) Wildfly 10 JSESSIONIDSSOs not being created

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-7247?page=com.atlassian.jira.plugin.... ] Brian Stansberry reassigned WFLY-7247: -------------------------------------- Assignee: Stuart Douglas (was: Jason Greene) > Wildfly 10 JSESSIONIDSSOs not being created > ------------------------------------------- > > Key: WFLY-7247 > URL: https://issues.jboss.org/browse/WFLY-7247 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Final, 10.1.0.Final > Reporter: M Wardell > Assignee: Stuart Douglas > > Found on wildfly 10.1 and 10.0. With SSO enabled, the server can startup in a state where not all the deployments get the SSO auth mechanism. Possibly caused by a missing dependency between the UndertowDeploymentInfoService and SingleSignOnService, which could be allowing the deployments to start before the SSO auth mechanism is registered in the host service. > Issue in intermittent on startup. After most startups the JESSSIONIDSSO is reliably generated during login. After some startups the JSESSIONIDSSO is never created after login. > Details in the referenced forum thread. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ELY-283) Investigate Elytron and gssproxy interoperability

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on ELY-283: --------------------------------- There are a number of people we can contact. I myself keep an OpenJDK checkout for experiments and research; I recommend that for anyone as it might be possible to narrow the problem down to a specific bug. That said, beyond our own OpenJDK team, the responsible people for GSS in the JDK are to be found on [the OpenJDK security development list|http://mail.openjdk.java.net/mailman/listinfo/security-dev]. > Investigate Elytron and gssproxy interoperability > ------------------------------------------------- > > Key: ELY-283 > URL: https://issues.jboss.org/browse/ELY-283 > Project: WildFly Elytron > Issue Type: Task > Components: SASL > Reporter: Peter Skopek > Assignee: Jan Kalina > Fix For: 2.0.0.Alpha1 > > Attachments: openjdk-patch-native-mechs.patch > > > Investigate Elytron and gssproxy interoperability. > https://fedorahosted.org/gss-proxy/ -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFLY-9277) Wildfly logs warning "WFLYEJB0463: Invalid transaction attribute" for Stateful components with CDI lifecycle methods

by Tomasz Adamski (JIRA)

[ https://issues.jboss.org/browse/WFLY-9277?page=com.atlassian.jira.plugin.... ] Tomasz Adamski closed WFLY-9277. -------------------------------- Resolution: Rejected > Wildfly logs warning "WFLYEJB0463: Invalid transaction attribute" for Stateful components with CDI lifecycle methods > -------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-9277 > URL: https://issues.jboss.org/browse/WFLY-9277 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 11.0.0.CR1 > Environment: WFLY 11.0.0.CR1, JDK8 > Reporter: Bernhard Hablesreiter > Assignee: Tomasz Adamski > Labels: cdi, ejb, transaction > > Wildlfy logs a warning "WFLYEJB0463: Invalid transaction attribute type REQUIRED on SFSB lifecycle method Method postConstruct() of class class com.test.Test, valid types are REQUIRES_NEW and NOT_SUPPORTED. Method will be treated as NOT_SUPPORTED." for @Stateful-components with CDI lifecycle annotations, even if the Class does not define any Transaction-Attributes: > {code:java} > @Named > @SessionScoped > @Stateful > public class Test implements Serializable > { > private static final long serialVersionUID = -2055975290009863989L; > @PostConstruct > private void postConstruct() > {} > } > {code} > The warning is only created when the @PostConstruct-method is on the class itself and not inherited (which does not make any difference). If the class extends another class, which declares a @PostConstruct-method, the warning does not appear. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ELY-929) AuthenticationConfiguration uniqueness enhancements

by Martin Mazanek (JIRA)

[ https://issues.jboss.org/browse/ELY-929?page=com.atlassian.jira.plugin.sy... ] Martin Mazanek reassigned ELY-929: ---------------------------------- Assignee: (was: Martin Mazanek) > AuthenticationConfiguration uniqueness enhancements > --------------------------------------------------- > > Key: ELY-929 > URL: https://issues.jboss.org/browse/ELY-929 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Reporter: David Lloyd > Fix For: 1.2.0.Beta12 > > > Apply some enhancements to AuthenticationConfiguration uniqueness. > * Add admonishing JavaDoc to {{useCallbackHandler}} to point out the importance of per-identity uniqueness of the callback handler > The following also may be possible and useful: > * Modify the {{AuthenticationConfiguration}} process to capture instances for {{Supplier}}-driven components at the time the configuration is used via the {{AuthenticationContextConfigurationClient}} > * Add a variation of {{useCallbackHandler}} which accepts a {{Supplier<CallbackHandler>}}, or a {{Function<T, CallbackHandler}} and a {{T}}, allowing constructor refs to be given -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFLY-9621) Nonintuitive error message when for loop is used inside of if/try/batch constructs

by Erich Duda (JIRA)

[ https://issues.jboss.org/browse/WFLY-9621?page=com.atlassian.jira.plugin.... ] Erich Duda reassigned WFLY-9621: -------------------------------- Assignee: Jean-Francois Denise (was: Jason Greene) > Nonintuitive error message when for loop is used inside of if/try/batch constructs > ---------------------------------------------------------------------------------- > > Key: WFLY-9621 > URL: https://issues.jboss.org/browse/WFLY-9621 > Project: WildFly > Issue Type: Bug > Components: CLI > Affects Versions: 11.0.0.Final > Reporter: Erich Duda > Assignee: Jean-Francois Denise > > CLI enables to use for loop construct for looping over commands or operations. See WFCORE-3236 for details. Because of design limitations of CLI, using of for loop is not supported inside of if, try, for and batch constructs. However if you try to do that, error message is not intuitive in all cases and it is difficult to find out why the code does not work. > Let's see on real examples. > {code:title=Using for inside if} > [standalone@embedded /] if (outcome != success) of /system-property=test:read-resource > [standalone@embedded /] for propName in :read-children-names(child-type=system-property) > [standalone@embedded /] echo $propName > Unrecognized variable propName > {code} > As you can see in the example, when you write aforementioned commands into the CLI, no error is thrown until you use the variable declared in the for construct. Additionally the error message is not saying anything about that using of "for" is not allowed inside of "if". > {code:title=Using for inside try} > [standalone@embedded /] try > [standalone@embedded /] for propName in :read-children-names(child-type=system-property) > [standalone@embedded /] echo $propName > Unrecognized variable propName > {code} > The same applies here as for "if" case. > {code:title=Using for inside batch} > [standalone@embedded /] batch > [standalone@embedded / #] for propName in :read-children-names(child-type=system-property) > The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable). > {code} > In the batch case, the error message is better (it says that command is not available), but still it is not clear why the command is not available. > {code:title=Using for inside for} > [standalone@embedded /] for propName in :read-children-names(child-type=system-property) > [standalone@embedded /] for propName in :read-children-names(child-type=system-property) > for is not allowed while in for block > {code} > Using of nested for loops generates nice error message which clearly explains what is wrong. All other cases should throw similar error. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFLY-9621) Nonintuitive error message when for loop is used inside of if/try/batch constructs

by Erich Duda (JIRA)

Erich Duda created WFLY-9621: -------------------------------- Summary: Nonintuitive error message when for loop is used inside of if/try/batch constructs Key: WFLY-9621 URL: https://issues.jboss.org/browse/WFLY-9621 Project: WildFly Issue Type: Bug Components: CLI Affects Versions: 11.0.0.Final Reporter: Erich Duda Assignee: Jason Greene CLI enables to use for loop construct for looping over commands or operations. See WFCORE-3236 for details. Because of design limitations of CLI, using of for loop is not supported inside of if, try, for and batch constructs. However if you try to do that, error message is not intuitive in all cases and it is difficult to find out why the code does not work. Let's see on real examples. {code:title=Using for inside if} [standalone@embedded /] if (outcome != success) of /system-property=test:read-resource [standalone@embedded /] for propName in :read-children-names(child-type=system-property) [standalone@embedded /] echo $propName Unrecognized variable propName {code} As you can see in the example, when you write aforementioned commands into the CLI, no error is thrown until you use the variable declared in the for construct. Additionally the error message is not saying anything about that using of "for" is not allowed inside of "if". {code:title=Using for inside try} [standalone@embedded /] try [standalone@embedded /] for propName in :read-children-names(child-type=system-property) [standalone@embedded /] echo $propName Unrecognized variable propName {code} The same applies here as for "if" case. {code:title=Using for inside batch} [standalone@embedded /] batch [standalone@embedded / #] for propName in :read-children-names(child-type=system-property) The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable). {code} In the batch case, the error message is better (it says that command is not available), but still it is not clear why the command is not available. {code:title=Using for inside for} [standalone@embedded /] for propName in :read-children-names(child-type=system-property) [standalone@embedded /] for propName in :read-children-names(child-type=system-property) for is not allowed while in for block {code} Using of nested for loops generates nice error message which clearly explains what is wrong. All other cases should throw similar error. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-2192) DMN QName regex problem and assimilated for function drools:kind

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2192?page=com.atlassian.jira.plugi... ] Matteo Mortari reassigned DROOLS-2192: -------------------------------------- Assignee: Matteo Mortari (was: Edson Tirelli) > DMN QName regex problem and assimilated for function drools:kind > ---------------------------------------------------------------- > > Key: DROOLS-2192 > URL: https://issues.jboss.org/browse/DROOLS-2192 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > > DMN QName regex does not match with serialization strategy. > A qname string serialization as > {code:java} > {http://namespace}localPart > {code} > would fail the regex of MarshallingUtils. > Additionally FunctionDefinition could now rely on the additionalAttributes generally available at the level of DMNModelInstrumentedBase (which would also serialize any other type of additional attributes, preserving from any original .dmn file). > Finally, it was noted calling getDecisionResultByName on DMNResultImpl by passing a wrong name would have thrown the stacktrace for wrong use of Optional.get(), instead of returning null as per getDecisionResultById() of the same class. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-2192) DMN QName regex problem and assimilated for function drools:kind

by Matteo Mortari (JIRA)

Matteo Mortari created DROOLS-2192: -------------------------------------- Summary: DMN QName regex problem and assimilated for function drools:kind Key: DROOLS-2192 URL: https://issues.jboss.org/browse/DROOLS-2192 Project: Drools Issue Type: Bug Components: dmn engine Reporter: Matteo Mortari Assignee: Edson Tirelli DMN QName regex does not match with serialization strategy. A qname string serialization as {code:java} {http://namespace}localPart {code} would fail the regex of MarshallingUtils. Additionally FunctionDefinition could now rely on the additionalAttributes generally available at the level of DMNModelInstrumentedBase (which would also serialize any other type of additional attributes, preserving from any original .dmn file). Finally, it was noted calling getDecisionResultByName on DMNResultImpl by passing a wrong name would have thrown the stacktrace for wrong use of Optional.get(), instead of returning null as per getDecisionResultById() of the same class. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-2191) Test SharedSessionParallelTest.testLongRunningRule2 fails randomly on Kie Jenkins

by Tibor Zimányi (JIRA)

Tibor Zimányi created DROOLS-2191: ------------------------------------- Summary: Test SharedSessionParallelTest.testLongRunningRule2 fails randomly on Kie Jenkins Key: DROOLS-2191 URL: https://issues.jboss.org/browse/DROOLS-2191 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.6.0.Final Reporter: Tibor Zimányi Assignee: Tibor Zimányi The mentioned test fails randomly on Kie Jenkins. It must be investigated. https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/drools/281/testRe... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2017