March 2019 - jboss-jira - Jboss List Archives

[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)

7 years, 2 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)

7 years, 2 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)

7 years, 2 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)

7 years, 2 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)

7 years, 2 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)

7 years, 2 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)

7 years, 2 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 reassigned WFLY-11810: ---------------------------------- Assignee: Jeff Mesnil > 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)

7 years, 2 months

1
0
0 / 0

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

by Jan Stourac (Jira)

Jan Stourac created WFLY-11810: ---------------------------------- Summary: 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 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)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1049) Add equivalent @WebContext for JAX-RS?

by Marek Kopecký (Jira)

[ https://issues.jboss.org/browse/WFLY-1049?page=com.atlassian.jira.plugin.... ] Marek Kopecký commented on WFLY-1049: ------------------------------------- [~ron_sigal]: There is no activity for ~6 years. What is your plan with this feature request? Reject? > Add equivalent @WebContext for JAX-RS? > -------------------------------------- > > Key: WFLY-1049 > URL: https://issues.jboss.org/browse/WFLY-1049 > Project: WildFly > Issue Type: Feature Request > Components: REST > Reporter: Fernando Rubbo > Priority: Major > Labels: BASIC_AUTH, FORM_AUTH, JAX-RS, > > Currently, in our application we use @WebContext to set a different contextRoot for JAX-WS. For example: > > {code:java} > @Stateless > @SecurityDomain("test2") > @WebService(name = "HelloSoap", portName = "HelloSoapPort", serviceName = "HelloSoap", targetNamespace = "http://com.test") > @WebContext(contextRoot = "/ws", urlPattern = "/HelloSoap", secureWSDLAccess = false, authMethod = "BASIC", transportGuarantee = "NONE") > public class HelloSoap { ... } > {code} > We would like to have an equivalent annotation for JAX-RS? It is required whenever a web app uses FORM_AUTH and there exists web services (JAX-WS and JAX-RS), inside of the same package, using as BASIC_AUTH. > > Thankyou in advance, > Fernando Rubbo -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 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 March 2019