[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 commented on WFCORE-4357:
-------------------------------------
[~ropalka][~jstourac] I've renamed the issue and move it to WFCORE as the change would have to be done in the codebase.
> 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, 10 months
[JBoss JIRA] (DROOLS-3715) Zipkiemodule nullpointerexception
by Łukasz Szmolke (Jira)
[ https://issues.jboss.org/browse/DROOLS-3715?page=com.atlassian.jira.plugi... ]
Łukasz Szmolke commented on DROOLS-3715:
----------------------------------------
Sory, i can't share project code. But it's common multi maven module issue. Each nested maven project with multiple kmodule.xml should not working.
> Zipkiemodule nullpointerexception
> ---------------------------------
>
> Key: DROOLS-3715
> URL: https://issues.jboss.org/browse/DROOLS-3715
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.16.0.Final, 7.17.0.Final
> Reporter: Łukasz Szmolke
> Assignee: Tibor Zimányi
> Priority: Major
>
> o During ZipKieModule loading in “org.drools.compiler.kie.builder.impl.ZipKieModule:142” nullpointerexception is thrown:
>
> urlPath = urlPath.substring( urlPath.lastIndexOf( '!' ) + 1 );
> ArrayList<ZipEntry> entries = new ArrayList<>();
> // read jar file from uber-jar
> InputStream in = this.getClass().getResourceAsStream(urlPath); // nullpointerexception
>
> For example full UrlPath on windows to internal .jar is:
> C:\Users\xbbnv0c\IdeaProjects\ais-data-exchange\data-exchange-app\target\data-exchange-app-1.0.1-SNAPSHOT.jar!\BOOT-INF\lib\data-exchange-brms-1.0.1-SNAPSHOT.jar
> So the result of this first line will be:
> \BOOT-INF\lib\data-exchange-brms-1.0.1-SNAPSHOT.jar
> It will be perfect, but during accessing internal resource file separator should be “/” not “\”. So InputStream in = null.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[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, 10 months
[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, 10 months
[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, 10 months
[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, 10 months
[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, 10 months
[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, 10 months
[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, 10 months
[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, 10 months