March 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-4357) Support new MSC Service API for deployment dependency

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-4357?page=com.atlassian.jira.plugi... ] Jeff Mesnil moved WFLY-11810 to WFCORE-4357: -------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-4357 (was: WFLY-11810) Component/s: Management (was: MSC) Affects Version/s: (was: 16.0.0.Final) > Support new MSC Service API for deployment dependency > ----------------------------------------------------- > > Key: WFCORE-4357 > URL: https://issues.jboss.org/browse/WFCORE-4357 > Project: WildFly Core > Issue Type: Bug > Components: Management > Reporter: Jan Stourac > Assignee: Jeff Mesnil > Priority: Major > > When org.jboss.as.server.deployment.DeploymentPhaseContextImpl#addDeploymentDependency is used, it is expecting the service to be old-API org.jboss.msc.service.Service and use its getValue() method. > This needs to be fixed so that using new MSC Service API works too. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11810) Support new MSC Service API for deployment dependency

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFLY-11810?page=com.atlassian.jira.plugin... ] Jeff Mesnil updated WFLY-11810: ------------------------------- Description: When org.jboss.as.server.deployment.DeploymentPhaseContextImpl#addDeploymentDependency is used, it is expecting the service to be old-API org.jboss.msc.service.Service and use its getValue() method. This needs to be fixed so that using new MSC Service API works too. was: I have no necessary insight regarding to the code but based on the discussion in WFLY-11603 ([comment|https://issues.jboss.org/browse/WFLY-11603?focusedCommentId=13687...]) it is not possible to use 'org.jboss.msc.Service' API to properly install service and deprecated 'org.jboss.msc.service.Service' API has to be used instead. It is necessary to fix the behavior of the new API so when we switch to it, we don't introduce the issue described and fixed in WFLY-11603 again. As it was an intermittent NPE, there is a risk that during the simple switch from deprecated API the introduced issue is not caught right-away but after some time... > Support new MSC Service API for deployment dependency > ----------------------------------------------------- > > Key: WFLY-11810 > URL: https://issues.jboss.org/browse/WFLY-11810 > Project: WildFly > Issue Type: Bug > Components: MSC > Reporter: Jan Stourac > Assignee: Jeff Mesnil > Priority: Major > > When org.jboss.as.server.deployment.DeploymentPhaseContextImpl#addDeploymentDependency is used, it is expecting the service to be old-API org.jboss.msc.service.Service and use its getValue() method. > This needs to be fixed so that using new MSC Service API works too. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11810) Support new MSC Service API for deployment dependency

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFLY-11810?page=com.atlassian.jira.plugin... ] Jeff Mesnil updated WFLY-11810: ------------------------------- Summary: Support new MSC Service API for deployment dependency (was: Fix 'org.jboss.msc.Service' API to enable proper service installation) > Support new MSC Service API for deployment dependency > ----------------------------------------------------- > > Key: WFLY-11810 > URL: https://issues.jboss.org/browse/WFLY-11810 > Project: WildFly > Issue Type: Bug > Components: MSC > Affects Versions: 16.0.0.Final > Reporter: Jan Stourac > Assignee: Jeff Mesnil > Priority: Major > > I have no necessary insight regarding to the code but based on the discussion in WFLY-11603 ([comment|https://issues.jboss.org/browse/WFLY-11603?focusedCommentId=13687...]) it is not possible to use 'org.jboss.msc.Service' API to properly install service and deprecated 'org.jboss.msc.service.Service' API has to be used instead. > It is necessary to fix the behavior of the new API so when we switch to it, we don't introduce the issue described and fixed in WFLY-11603 again. As it was an intermittent NPE, there is a risk that during the simple switch from deprecated API the introduced issue is not caught right-away but after some time... -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11810) Fix 'org.jboss.msc.Service' API to enable proper service installation

by Richard Opalka (Jira)

[ https://issues.jboss.org/browse/WFLY-11810?page=com.atlassian.jira.plugin... ] Richard Opalka commented on WFLY-11810: --------------------------------------- This is not MSC API problem [~jstourac]. org.jboss.msc.service.Service.getValue() method is deprecated: https://github.com/wildfly/wildfly/pull/12012/files#diff-6de66bee9c455ef4... If you need to use this method you either: a) didn't migrate your MSC services properly b) or there are still some internal WildFly APIs that are still using legacy MSC API and thus your code cannot be migrated to new MSC APIs yet Migration of WildFly code base to use new MSC API is a long process and it will take some time to get there. > Fix 'org.jboss.msc.Service' API to enable proper service installation > --------------------------------------------------------------------- > > Key: WFLY-11810 > URL: https://issues.jboss.org/browse/WFLY-11810 > Project: WildFly > Issue Type: Bug > Components: MSC > Affects Versions: 16.0.0.Final > Reporter: Jan Stourac > Assignee: Jeff Mesnil > Priority: Major > > I have no necessary insight regarding to the code but based on the discussion in WFLY-11603 ([comment|https://issues.jboss.org/browse/WFLY-11603?focusedCommentId=13687...]) it is not possible to use 'org.jboss.msc.Service' API to properly install service and deprecated 'org.jboss.msc.service.Service' API has to be used instead. > It is necessary to fix the behavior of the new API so when we switch to it, we don't introduce the issue described and fixed in WFLY-11603 again. As it was an intermittent NPE, there is a risk that during the simple switch from deprecated API the introduced issue is not caught right-away but after some time... -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5885) jconsole.sh should fail fast if JBOSS_HOME is incorrect instead of starting the console with an incorrecdt classpath

by Marek Kopecký (Jira)

[ https://issues.jboss.org/browse/WFLY-5885?page=com.atlassian.jira.plugin.... ] Marek Kopecký updated WFLY-5885: -------------------------------- Affects Version/s: 16.0.0.Final > jconsole.sh should fail fast if JBOSS_HOME is incorrect instead of starting the console with an incorrecdt classpath > -------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-5885 > URL: https://issues.jboss.org/browse/WFLY-5885 > Project: WildFly > Issue Type: Enhancement > Components: JMX, Scripts > Affects Versions: 16.0.0.Final > Reporter: Cosmin Stroe > Priority: Minor > > If {{$JBOSS_HOME}} is incorrectly set, we get a vague WARNING message when the script starts, but jconsole is run and shows the GUI window. This is misleading, because jconsole won't have the correct classpath and won't be able to connect to Wildfly, leading to an ambiguous "Cannot connect" error. > {{jconsole.sh}} should fail fast if it cannot find the {{jboss-cli-client.jar}} and avoid this entire confusion. > --- > Steps to reproduce: > # export JBOSS_HOME=/no/existing/path > # ./standalone.sh -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5885) jconsole.sh should fail fast if JBOSS_HOME is incorrect instead of starting the console with an incorrecdt classpath

by Marek Kopecký (Jira)

[ https://issues.jboss.org/browse/WFLY-5885?page=com.atlassian.jira.plugin.... ] Marek Kopecký updated WFLY-5885: -------------------------------- Description: If {{$JBOSS_HOME}} is incorrectly set, we get a vague WARNING message when the script starts, but jconsole is run and shows the GUI window. This is misleading, because jconsole won't have the correct classpath and won't be able to connect to Wildfly, leading to an ambiguous "Cannot connect" error. {{jconsole.sh}} should fail fast if it cannot find the {{jboss-cli-client.jar}} and avoid this entire confusion. --- Steps to reproduce: # export JBOSS_HOME=/no/existing/path # ./standalone.sh was: If {{$JBOSS_HOME}} is incorrectly set, we get a vague WARNING message when the script starts, but jconsole is run and shows the GUI window. This is misleading, because jconsole won't have the correct classpath and won't be able to connect to Wildfly, leading to an ambiguous "Cannot connect" error. {{jconsole.sh}} should fail fast if it cannot find the {{jboss-cli-client.jar}} and avoid this entire confusion. > jconsole.sh should fail fast if JBOSS_HOME is incorrect instead of starting the console with an incorrecdt classpath > -------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-5885 > URL: https://issues.jboss.org/browse/WFLY-5885 > Project: WildFly > Issue Type: Enhancement > Components: JMX, Scripts > Reporter: Cosmin Stroe > Priority: Minor > > If {{$JBOSS_HOME}} is incorrectly set, we get a vague WARNING message when the script starts, but jconsole is run and shows the GUI window. This is misleading, because jconsole won't have the correct classpath and won't be able to connect to Wildfly, leading to an ambiguous "Cannot connect" error. > {{jconsole.sh}} should fail fast if it cannot find the {{jboss-cli-client.jar}} and avoid this entire confusion. > --- > Steps to reproduce: > # export JBOSS_HOME=/no/existing/path > # ./standalone.sh -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6097) Error response handling from bean validation ignores Accept header

by Marek Kopecký (Jira)

[ https://issues.jboss.org/browse/WFLY-6097?page=com.atlassian.jira.plugin.... ] Marek Kopecký reassigned WFLY-6097: ----------------------------------- Assignee: Ron Sigal (was: Weinan Li) > Error response handling from bean validation ignores Accept header > ------------------------------------------------------------------ > > Key: WFLY-6097 > URL: https://issues.jboss.org/browse/WFLY-6097 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 10.0.0.Final > Environment: Mac OS X El Captain > java version "1.8.0_66" > Java(TM) SE Runtime Environment (build 1.8.0_66-b17) > Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode) > Reporter: Renann Prado > Assignee: Ron Sigal > Priority: Major > Attachments: delivery-optimization-ear-1.0.Final.ear > > > Basically I have a very simple application that has request validation in the REST endpoints. > According to the documentation of RESTEasy, I should get a JSON error response if I put "application/json" in Accept header in the request. > https://docs.jboss.org/resteasy/docs/3.0.13.Final/userguide/html/Validati... > The mentioned feature worked just fine in Wildfly 9.0.2.Final. Now, however, it doesn't. > I have tried to upgrade the dependencies in the pom.xml to use dependencies from Wildfly 10.0.0.Final, but still no luck. Though the attached application deploys just fine in Wildfly 9.0.2.Final and Wildfly 10.0.0.Final. > In WF 9.0.2.Final I used to get the below error *JSON* > {code:json} > { > "exception": null, > "fieldViolations": [], > "propertyViolations": [], > "classViolations": [], > "parameterViolations": [{ > "constraintType": "PARAMETER", > "path": "registerLogisticsNetwork.arg0.name", > "message": "may not be null", > "value": "" > }], > "returnValueViolations": [] > } > {code} > In WF 10.0.0.Final I get this: > {code} > [PARAMETER] > [registerLogisticsNetwork.arg0.name] > [may not be null] > [] > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6097) Error response handling from bean validation ignores Accept header

by Marek Kopecký (Jira)

[ https://issues.jboss.org/browse/WFLY-6097?page=com.atlassian.jira.plugin.... ] Marek Kopecký commented on WFLY-6097: ------------------------------------- [~ron_sigal] Simple reproducer not provided after 3 years (see [this comment|https://issues.jboss.org/browse/WFLY-6097?focusedCommentId=131586...]). RESTEASY-1264 is closed. Can you please close this jira? > Error response handling from bean validation ignores Accept header > ------------------------------------------------------------------ > > Key: WFLY-6097 > URL: https://issues.jboss.org/browse/WFLY-6097 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 10.0.0.Final > Environment: Mac OS X El Captain > java version "1.8.0_66" > Java(TM) SE Runtime Environment (build 1.8.0_66-b17) > Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode) > Reporter: Renann Prado > Assignee: Weinan Li > Priority: Major > Attachments: delivery-optimization-ear-1.0.Final.ear > > > Basically I have a very simple application that has request validation in the REST endpoints. > According to the documentation of RESTEasy, I should get a JSON error response if I put "application/json" in Accept header in the request. > https://docs.jboss.org/resteasy/docs/3.0.13.Final/userguide/html/Validati... > The mentioned feature worked just fine in Wildfly 9.0.2.Final. Now, however, it doesn't. > I have tried to upgrade the dependencies in the pom.xml to use dependencies from Wildfly 10.0.0.Final, but still no luck. Though the attached application deploys just fine in Wildfly 9.0.2.Final and Wildfly 10.0.0.Final. > In WF 9.0.2.Final I used to get the below error *JSON* > {code:json} > { > "exception": null, > "fieldViolations": [], > "propertyViolations": [], > "classViolations": [], > "parameterViolations": [{ > "constraintType": "PARAMETER", > "path": "registerLogisticsNetwork.arg0.name", > "message": "may not be null", > "value": "" > }], > "returnValueViolations": [] > } > {code} > In WF 10.0.0.Final I get this: > {code} > [PARAMETER] > [registerLogisticsNetwork.arg0.name] > [may not be null] > [] > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11697) WS integration with WildFly Elytron - AuthenticationClient for Authentication / SSL

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-11697?page=com.atlassian.jira.plugin... ] Darran Lofthouse updated WFLY-11697: ------------------------------------ Summary: WS integration with WildFly Elytron - AuthenticationClient for Authentication / SSL (was: WS and Rest integration with WildFly Elytron - AuthenticationClient for Authentication / SSL) > WS integration with WildFly Elytron - AuthenticationClient for Authentication / SSL > ----------------------------------------------------------------------------------- > > Key: WFLY-11697 > URL: https://issues.jboss.org/browse/WFLY-11697 > Project: WildFly > Issue Type: Feature Request > Components: REST, Security, Web Services > Affects Versions: 16.0.0.Final > Reporter: Diana Vilkolakova > Assignee: Diana Vilkolakova > Priority: Major > > This feature request is about making use of authentication configuration on the client side of the WS / REST deployment. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11810) Fix 'org.jboss.msc.Service' API to enable proper service installation

by Jan Stourac (Jira)

[ https://issues.jboss.org/browse/WFLY-11810?page=com.atlassian.jira.plugin... ] Jan Stourac commented on WFLY-11810: ------------------------------------ I want to mention also WFLY-11387 here, although based on the provided fix, that was probably a different issue with different root-cause to what this issue is aimed at. So just for a reference... > Fix 'org.jboss.msc.Service' API to enable proper service installation > --------------------------------------------------------------------- > > Key: WFLY-11810 > URL: https://issues.jboss.org/browse/WFLY-11810 > Project: WildFly > Issue Type: Bug > Components: MSC > Affects Versions: 16.0.0.Final > Reporter: Jan Stourac > Assignee: Jeff Mesnil > Priority: Major > > I have no necessary insight regarding to the code but based on the discussion in WFLY-11603 ([comment|https://issues.jboss.org/browse/WFLY-11603?focusedCommentId=13687...]) it is not possible to use 'org.jboss.msc.Service' API to properly install service and deprecated 'org.jboss.msc.service.Service' API has to be used instead. > It is necessary to fix the behavior of the new API so when we switch to it, we don't introduce the issue described and fixed in WFLY-11603 again. As it was an intermittent NPE, there is a risk that during the simple switch from deprecated API the introduced issue is not caught right-away but after some time... -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

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 March 2019