December 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2336) Remove ModelController.createClient

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2336?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-2336: ------------------------------------------ It's fairly likely I'll defer this to WF 13 (presumably WF Core 5) as the deprecation is still fairly recent in terms of .Final code. > Remove ModelController.createClient > ----------------------------------- > > Key: WFCORE-2336 > URL: https://issues.jboss.org/browse/WFCORE-2336 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 4.0.0.Alpha6 > > > Follow up on WFCORE-1507 by removing ModelController.createClient and any use of it. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3465) Eliminate uses of ModelNode.resolve()

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3465?page=com.atlassian.jira.plugi... ] Brian Stansberry moved WFLY-9623 to WFCORE-3465: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-3465 (was: WFLY-9623) Component/s: Domain Management (was: Domain Management) > Eliminate uses of ModelNode.resolve() > ------------------------------------- > > Key: WFCORE-3465 > URL: https://issues.jboss.org/browse/WFCORE-3465 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > Code inspection shows there are 23 uses of ModelNode.resolve() in WildFly's own code base, 12 in production code and 11 in test code. We should eliminate these, as WildFly's expression resolution is more complex than the ModelNode.resolve() contract, including vault support for which its' hard to imagine us wanting support in DMR itself. So these uses should switch to resolution from the OperationContext or, if that's not feasible, e.g. in test code, use something like ExpressionResolver.TEST_RESOLVER. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9622) Eliminate uses of ModelNode.resolve()

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-9622: -------------------------------------- Summary: Eliminate uses of ModelNode.resolve() Key: WFLY-9622 URL: https://issues.jboss.org/browse/WFLY-9622 Project: WildFly Issue Type: Task Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Code inspection shows there are 23 uses of ModelNode.resolve() in WildFly's own code base, 12 in production code and 11 in test code. We should eliminate these, as WildFly's expression resolution is more complex than the ModelNode.resolve() contract, including vault support for which its' hard to imagine us wanting support in DMR itself. So these uses should switch to resolution from the OperationContext or, if that's not feasible, e.g. in test code, use something like ExpressionResolver.TEST_RESOLVER. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9623) Eliminate uses of ModelNode.resolve()

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-9623: -------------------------------------- Summary: Eliminate uses of ModelNode.resolve() Key: WFLY-9623 URL: https://issues.jboss.org/browse/WFLY-9623 Project: WildFly Issue Type: Task Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Code inspection shows there are 23 uses of ModelNode.resolve() in WildFly's own code base, 12 in production code and 11 in test code. We should eliminate these, as WildFly's expression resolution is more complex than the ModelNode.resolve() contract, including vault support for which its' hard to imagine us wanting support in DMR itself. So these uses should switch to resolution from the OperationContext or, if that's not feasible, e.g. in test code, use something like ExpressionResolver.TEST_RESOLVER. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

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: --------------------------------- 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, 4 months

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, 4 months

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, 4 months

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, 4 months

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, 4 months

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, 4 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 December 2017