September 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3228) WorkerServerDefinition should not be registered on an HC

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-3228: ---------------------------------------- Summary: WorkerServerDefinition should not be registered on an HC Key: WFCORE-3228 URL: https://issues.jboss.org/browse/WFCORE-3228 Project: WildFly Core Issue Type: Bug Components: IO Affects Versions: 3.0.1.Final Reporter: Brian Stansberry Assignee: David Lloyd Title says it all. I think removing this isn't an incompatible change because these are runtime-only synthetic resources where WorkerResourceDefinition.WorkerResource will never produce a child resource against which an operation can be targeted. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9288) EJB session auto-creation is not working

by David Lloyd (JIRA)

David Lloyd created WFLY-9288: --------------------------------- Summary: EJB session auto-creation is not working Key: WFLY-9288 URL: https://issues.jboss.org/browse/WFLY-9288 Project: WildFly Issue Type: Bug Components: EJB Reporter: David Lloyd In {{org.jboss.as.ejb3.remote.AssociationImpl#receiveInvocationRequest}}, when the EJB component is being looked up, two things need to happen which are not happening: * The incoming locator should be examined; if it is a stateful locator and the physical EJB is stateless, then {{Request#writeNotStateful()}} should be called and processing should be aborted. * If the incoming locator is a stateless locator and the physical EJB is stateful, then {{component#createSessionRemote()}} should be called and the resultant session ID should be set using {{Request#convertToStateful()}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9287) ReferencingDeploymentsHandler is doing runtime work in Stage.MODEL

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-9287?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-9287: ----------------------------------- Component/s: Web (Undertow) > ReferencingDeploymentsHandler is doing runtime work in Stage.MODEL > ------------------------------------------------------------------ > > Key: WFLY-9287 > URL: https://issues.jboss.org/browse/WFLY-9287 > Project: WildFly > Issue Type: Bug > Components: EJB, Web (Undertow) > Affects Versions: 11.0.0.CR1 > Reporter: Brian Stansberry > > The handler is reading services in Stage.MODEL. It should add a RUNTIME step, being careful that it's running on a non-admin-only-server (check OperationContext.isDefaultRequiresRuntime()). > This applies to the variant in ejb3 and the one in undertow. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9287) ReferencingDeploymentsHandler is doing runtime work in Stage.MODEL

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-9287?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-9287: ----------------------------------- Description: The handler is reading services in Stage.MODEL. It should add a RUNTIME step, being careful that it's running on a non-admin-only-server (check OperationContext.isDefaultRequiresRuntime()). This applies to the variant in ejb3 and the one in undertow. was:The handler is reading services in Stage.MODEL. It should add a RUNTIME step, being careful that it's running on a non-admin-only-server (check OperationContext.isDefaultRequiresRuntime()). > ReferencingDeploymentsHandler is doing runtime work in Stage.MODEL > ------------------------------------------------------------------ > > Key: WFLY-9287 > URL: https://issues.jboss.org/browse/WFLY-9287 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 11.0.0.CR1 > Reporter: Brian Stansberry > > The handler is reading services in Stage.MODEL. It should add a RUNTIME step, being careful that it's running on a non-admin-only-server (check OperationContext.isDefaultRequiresRuntime()). > This applies to the variant in ejb3 and the one in undertow. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1353) AuthenticationConfiguration#kerberosSecurityFactory is redundant

by David Lloyd (JIRA)

David Lloyd created ELY-1353: -------------------------------- Summary: AuthenticationConfiguration#kerberosSecurityFactory is redundant Key: ELY-1353 URL: https://issues.jboss.org/browse/ELY-1353 Project: WildFly Elytron Issue Type: Bug Components: Authentication Client Reporter: David Lloyd There's no point to having a special/separate kerberosSecurityFactory on AuthenticationConfiguration. The callback handling code path for this would work exactly the same if the Kerberos credential were instead stored on the regular CredentialSource in the configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9287) ReferencingDeploymentsHandler is doing runtime work in Stage.MODEL

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-9287?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-9287: ---------------------------------------- I'm bumping this to Major as this op is registered on a DC profile resource, and it will fail if executed there, as it's calling context.getRequiredService(serviceName) for a service that won't be installed. > ReferencingDeploymentsHandler is doing runtime work in Stage.MODEL > ------------------------------------------------------------------ > > Key: WFLY-9287 > URL: https://issues.jboss.org/browse/WFLY-9287 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 11.0.0.CR1 > Reporter: Brian Stansberry > > The handler is reading services in Stage.MODEL. It should add a RUNTIME step, being careful that it's running on a non-admin-only-server (check OperationContext.isDefaultRequiresRuntime()). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9287) ReferencingDeploymentsHandler is doing runtime work in Stage.MODEL

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-9287?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-9287: ----------------------------------- Priority: Major (was: Minor) > ReferencingDeploymentsHandler is doing runtime work in Stage.MODEL > ------------------------------------------------------------------ > > Key: WFLY-9287 > URL: https://issues.jboss.org/browse/WFLY-9287 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 11.0.0.CR1 > Reporter: Brian Stansberry > > The handler is reading services in Stage.MODEL. It should add a RUNTIME step, being careful that it's running on a non-admin-only-server (check OperationContext.isDefaultRequiresRuntime()). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9287) ReferencingDeploymentsHandler is doing runtime work in Stage.MODEL

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-9287: -------------------------------------- Summary: ReferencingDeploymentsHandler is doing runtime work in Stage.MODEL Key: WFLY-9287 URL: https://issues.jboss.org/browse/WFLY-9287 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 11.0.0.CR1 Reporter: Brian Stansberry Priority: Minor The handler is reading services in Stage.MODEL. It should add a RUNTIME step, being careful that it's running on a non-admin-only-server (check OperationContext.isDefaultRequiresRuntime()). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3217) Relax the WFCORE-2849 requirement

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3217?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3217: ------------------------------------- Description: WFCORE-2849 fails ops against domain profile resources if the OSH tries to register a Stage.RUNTIME step. But we are still hitting cases where we have OSHs that try to do this (see WFLY-9281). Since those OSHs have worked for years without this causing major trouble, failing the op seems excessive. Instead I would like to log -a WARN- an INFO, and have the problematic 'addStep' call simply return without adding the step. Perhaps this could be a DEBUG, but really if an OSH is doing this it is a bug and I'd like to not hide that. A WARN OTOH seems too high, as this likely does not harm the end user and there is nothing they can do about it other than not invoking the op. was: WFCORE-2849 fails ops against domain profile resources if the OSH tries to register a Stage.RUNTIME step. But we are still hitting cases where we have OSHs that try to do this (see WFLY-9281). Since those OSHs have worked for years without this causing major trouble, failing the op seems excessive. Instead I would like to log -a WARN- an INFO, and have the problematic 'addStep' call simply return without adding the step. Perhaps this could be a DEBUG, but really if an OSH is doing this it is a bug and I'd like to not hide that. A WARN OTOH seems to high, as this likely does not harm the end user and there is nothing they can do about it other than not invoking the op. > Relax the WFCORE-2849 requirement > --------------------------------- > > Key: WFCORE-3217 > URL: https://issues.jboss.org/browse/WFCORE-3217 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Affects Versions: 3.0.0.Final, 3.0.1.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Blocker > Fix For: 4.0.0.Alpha1, 3.0.2.Final > > > WFCORE-2849 fails ops against domain profile resources if the OSH tries to register a Stage.RUNTIME step. But we are still hitting cases where we have OSHs that try to do this (see WFLY-9281). Since those OSHs have worked for years without this causing major trouble, failing the op seems excessive. > Instead I would like to log -a WARN- an INFO, and have the problematic 'addStep' call simply return without adding the step. > Perhaps this could be a DEBUG, but really if an OSH is doing this it is a bug and I'd like to not hide that. A WARN OTOH seems too high, as this likely does not harm the end user and there is nothing they can do about it other than not invoking the op. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3217) Relax the WFCORE-2849 requirement

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3217?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3217: ------------------------------------- Description: WFCORE-2849 fails ops against domain profile resources if the OSH tries to register a Stage.RUNTIME step. But we are still hitting cases where we have OSHs that try to do this (see WFLY-9281). Since those OSHs have worked for years without this causing major trouble, failing the op seems excessive. Instead I would like to log -a WARN- an INFO, and have the problematic 'addStep' call simply return without adding the step. Perhaps this could be a DEBUG, but really if an OSH is doing this it is a bug and I'd like to not hide that. A WARN OTOH seems to high, as this likely does not harm the end user and there is nothing they can do about it other than not invoking the op. was: WFCORE-2849 fails ops against domain profile resources if the OSH tries to register a Stage.RUNTIME step. But we are still hitting cases where we have OSHs that try to do this (see WFLY-9281). Since those OSHs have worked for years without this causing major trouble, failing the op seems excessive. Instead I would like to log a WARN, and have the problematic 'addStep' call simply return without adding the step. Perhaps this could be a DEBUG, but really if an OSH is doing this it is a bug and I'd like to not hide that. > Relax the WFCORE-2849 requirement > --------------------------------- > > Key: WFCORE-3217 > URL: https://issues.jboss.org/browse/WFCORE-3217 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Affects Versions: 3.0.0.Final, 3.0.1.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Blocker > Fix For: 4.0.0.Alpha1, 3.0.2.Final > > > WFCORE-2849 fails ops against domain profile resources if the OSH tries to register a Stage.RUNTIME step. But we are still hitting cases where we have OSHs that try to do this (see WFLY-9281). Since those OSHs have worked for years without this causing major trouble, failing the op seems excessive. > Instead I would like to log -a WARN- an INFO, and have the problematic 'addStep' call simply return without adding the step. > Perhaps this could be a DEBUG, but really if an OSH is doing this it is a bug and I'd like to not hide that. A WARN OTOH seems to high, as this likely does not harm the end user and there is nothing they can do about it other than not invoking the op. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 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 September 2017