[JBoss JIRA] (WFLY-6097) Error response handling from bean validation ignores Accept header
by Ron Sigal (Jira)
[ https://issues.jboss.org/browse/WFLY-6097?page=com.atlassian.jira.plugin.... ]
Ron Sigal resolved WFLY-6097.
-----------------------------
Resolution: Out of Date
> 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)
5 years, 10 months
[JBoss JIRA] (WFLY-6097) Error response handling from bean validation ignores Accept header
by Ron Sigal (Jira)
[ https://issues.jboss.org/browse/WFLY-6097?page=com.atlassian.jira.plugin.... ]
Ron Sigal commented on WFLY-6097:
---------------------------------
According to [~gunnar.morling]'s experimentation, this problem was solved by RESTEASY-1264. The solution to RESTEASY-1264 has Fix Version 3.0.15.Final, and Wildfly 10.0.0.Final, the Affects Version in this issue, ships with RESTEasy 3.0.14.Final. I think we can assume, then, that this issue is out of date.
> 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)
5 years, 10 months
[JBoss JIRA] (WFCORE-4359) CommandFormatException: Invalid syntax... when using tab completion
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFCORE-4359?page=com.atlassian.jira.plugi... ]
James Perkins moved JBEAP-16503 to WFCORE-4359:
-----------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-4359 (was: JBEAP-16503)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: CLI
Embedded
(was: CLI)
(was: Embedded)
Affects Version/s: (was: 7.3.0.CD15)
> CommandFormatException: Invalid syntax... when using tab completion
> -------------------------------------------------------------------
>
> Key: WFCORE-4359
> URL: https://issues.jboss.org/browse/WFCORE-4359
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Embedded
> Reporter: Miroslav Novak
> Assignee: James Perkins
> Priority: Major
>
> There is issue when tab completion is used in following malformed command:
> {code}
> [standalone@embedded /] /subsystem=modcluster/proxy=modcluster:add(advertise=false,proxies=mod_cluster-pro14:56:17,909 WARN [org.jboss.as.cli.impl.ValueTypeCompleter] (CLI Terminal Connection (uninterruptable)) Invalid syntax.: org.jboss.as.cli.CommandFormatException: Invalid syntax.
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.ValueTypeCompleter$ValueTypeCallbackHandler.enteredState(ValueTypeCompleter.java:951)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.parsing.StateParser$ParsingContextImpl.enterState(StateParser.java:420)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.ValueTypeCompleter$PropertyListState$1.handle(ValueTypeCompleter.java:1248)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.parsing.StateParser$ParsingContextImpl.enterState(StateParser.java:421)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.ValueTypeCompleter$InitialValueState$1.handle(ValueTypeCompleter.java:1184)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.parsing.StateParser$ParsingContextImpl.parse(StateParser.java:261)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.parsing.StateParser.doParse(StateParser.java:150)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.parsing.StateParser.parseLine(StateParser.java:124)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.parsing.StateParser.parseLine(StateParser.java:117)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.parsing.StateParser.parseLine(StateParser.java:95)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.parsing.StateParser.parseLine(StateParser.java:75)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.parsing.StateParser.parse(StateParser.java:65)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.ValueTypeCompleter.parse(ValueTypeCompleter.java:401)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.ValueTypeCompleter.complete(ValueTypeCompleter.java:381)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.operation.OperationRequestCompleter.completeWithValueCompleter(OperationRequestCompleter.java:413)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.operation.OperationRequestCompleter.completeProperties(OperationRequestCompleter.java:672)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:709)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:90)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.CommandCompleter.complete(CommandCompleter.java:99)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.aesh.CLICompletionHandler.completeLegacyCommands(CLICompletionHandler.java:157)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.aesh.CLICompletionHandler.complete(CLICompletionHandler.java:133)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.CLICommandCompleter.doComplete(CLICommandCompleter.java:132)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.CLICommandCompleter.complete(CLICommandCompleter.java:54)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.aesh.CLICompletionHandler.complete(CLICompletionHandler.java:69)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.aesh.CLICompletionHandler.complete(CLICompletionHandler.java:45)
> at org.aesh//org.aesh.readline.completion.CompletionHandler.createCompletionList(CompletionHandler.java:135)
> at org.aesh//org.aesh.readline.completion.CompletionHandler.complete(CompletionHandler.java:103)
> at org.aesh//org.aesh.readline.action.mappings.Complete.accept(Complete.java:62)
> at org.aesh//org.aesh.readline.Readline$AeshInputProcessor.parse(Readline.java:246)
> at org.aesh//org.aesh.readline.Readline$AeshInputProcessor.access$100(Readline.java:174)
> at org.aesh//org.aesh.readline.Readline.readInput(Readline.java:95)
> at org.aesh//org.aesh.readline.Readline.access$1000(Readline.java:57)
> at org.aesh//org.aesh.readline.Readline$AeshInputProcessor.lambda$start$1(Readline.java:333)
> at org.aesh//org.aesh.terminal.EventDecoder.accept(EventDecoder.java:118)
> at org.aesh//org.aesh.terminal.EventDecoder.accept(EventDecoder.java:31)
> at org.aesh//org.aesh.io.Decoder.write(Decoder.java:133)
> at org.aesh//org.aesh.readline.tty.terminal.TerminalConnection.openBlocking(TerminalConnection.java:216)
> at org.aesh//org.aesh.readline.tty.terminal.TerminalConnection.openBlocking(TerminalConnection.java:203)
> at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.ReadlineConsole$CLITerminalConnection.lambda$null$1(ReadlineConsole.java:178)
> at java.base/java.lang.Thread.run(Thread.java:834)
>
>
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0155: 'listener' may not be null",
> "rolled-back" => true
> }
> {code}
> where attribute {{proxies}} should take a list. Exception should not be thrown.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 10 months
[JBoss JIRA] (LOGMGR-241) Expose the current LogContextSelector from the LogContext
by James Perkins (Jira)
James Perkins created LOGMGR-241:
------------------------------------
Summary: Expose the current LogContextSelector from the LogContext
Key: LOGMGR-241
URL: https://issues.jboss.org/browse/LOGMGR-241
Project: JBoss Log Manager
Issue Type: Enhancement
Components: core
Reporter: James Perkins
Assignee: James Perkins
Fix For: 2.1.7.Final, 2.2.0.Final, 3.0.0.Final
Currently you can set a {{LogContextSelector}} on a {{LogContext}} however there is no way to query the currently set selector. This could be useful in cases where you need to wrap a current selector in a new selector.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 10 months
[JBoss JIRA] (WFLY-1049) Add equivalent @WebContext for JAX-RS?
by Ron Sigal (Jira)
[ https://issues.jboss.org/browse/WFLY-1049?page=com.atlassian.jira.plugin.... ]
Ron Sigal resolved WFLY-1049.
-----------------------------
Resolution: Rejected
> 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)
5 years, 10 months
[JBoss JIRA] (WFLY-1049) Add equivalent @WebContext for JAX-RS?
by Ron Sigal (Jira)
[ https://issues.jboss.org/browse/WFLY-1049?page=com.atlassian.jira.plugin.... ]
Ron Sigal commented on WFLY-1049:
---------------------------------
[~mkopecky], there doesn't seem to be much interest, does there?
[~fernando.rubbo], I'm going to close this issue. If there is still some interest, you (or anyone) can re-open it.
-Ron
> 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)
5 years, 10 months
[JBoss JIRA] (WFLY-11259) Wildfly 11.0.0.Final org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-11259?page=com.atlassian.jira.plugin... ]
Scott Marlow closed WFLY-11259.
-------------------------------
Resolution: Done
> Wildfly 11.0.0.Final org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-11259
> URL: https://issues.jboss.org/browse/WFLY-11259
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 11.0.0.Final
> Reporter: Adam Bialas
> Assignee: Scott Marlow
> Priority: Major
> Fix For: 17.0.0.Beta1
>
>
> I have an ear file which I want to deploy to the Wildfly 11.0.0.Final. In this ear file in the lib folder I have dom4j-2.0.1.jar. One of the sub deployments (war) uses JPA (no dependencies to hibernate, just to javax.javaee-api as compile only). This sub deployment contains of course the persistence.xml file. I see in the logs that when the application server starts and loads this file the following exception is thrown:
> org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> and the application fails to deploy.
> I checked many posts and forums on the net and as far as I understand I must exclude the dom4j provided by the application server so the jar located in the lib folder of ear can be used.
> I created jboss-deployment-structure:
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
> <deployment>
> <exclusions>
> <module name="org.dom4j"/>
> </exclusions>
> </deployment>
> </jboss-deployment-structure>
> Even though I get the same exception so I suppose both jars are loaded and cause problems.
> I checked how class loading works on Wildfly 11.0.0 in comparison to JBoss EAP 7.1. In both cases this class is first loaded from provided 1.6.1 jar. JBoss does not load the newer version. However, Wildfly does and here is the problem.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 10 months
[JBoss JIRA] (WFLY-11259) Wildfly 11.0.0.Final org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-11259?page=com.atlassian.jira.plugin... ]
Scott Marlow updated WFLY-11259:
--------------------------------
Fix Version/s: 17.0.0.Beta1
> Wildfly 11.0.0.Final org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-11259
> URL: https://issues.jboss.org/browse/WFLY-11259
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 11.0.0.Final
> Reporter: Adam Bialas
> Assignee: Scott Marlow
> Priority: Major
> Fix For: 17.0.0.Beta1
>
>
> I have an ear file which I want to deploy to the Wildfly 11.0.0.Final. In this ear file in the lib folder I have dom4j-2.0.1.jar. One of the sub deployments (war) uses JPA (no dependencies to hibernate, just to javax.javaee-api as compile only). This sub deployment contains of course the persistence.xml file. I see in the logs that when the application server starts and loads this file the following exception is thrown:
> org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> and the application fails to deploy.
> I checked many posts and forums on the net and as far as I understand I must exclude the dom4j provided by the application server so the jar located in the lib folder of ear can be used.
> I created jboss-deployment-structure:
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
> <deployment>
> <exclusions>
> <module name="org.dom4j"/>
> </exclusions>
> </deployment>
> </jboss-deployment-structure>
> Even though I get the same exception so I suppose both jars are loaded and cause problems.
> I checked how class loading works on Wildfly 11.0.0 in comparison to JBoss EAP 7.1. In both cases this class is first loaded from provided 1.6.1 jar. JBoss does not load the newer version. However, Wildfly does and here is the problem.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 10 months