[JBoss JIRA] (WFLY-8210) Implicit bean archive ID contains the absolute VFS path of the resource
by Martin Kouba (JIRA)
Martin Kouba created WFLY-8210:
----------------------------------
Summary: Implicit bean archive ID contains the absolute VFS path of the resource
Key: WFLY-8210
URL: https://issues.jboss.org/browse/WFLY-8210
Project: WildFly
Issue Type: Bug
Components: CDI / Weld
Affects Versions: 10.1.0.Final
Reporter: Martin Kouba
Assignee: Stuart Douglas
This does not match the {{org.jboss.weld.bootstrap.spi.BeanDeploymentArchive}} contract. As a result, clustering does not work on Windows machines - see also JBEAP-8451.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8209) JAX-RS Executes resource method even when input validation fails
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-8209?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-8209:
------------------------------------
Assignee: Alessio Soldano (was: Stuart Douglas)
> JAX-RS Executes resource method even when input validation fails
> ----------------------------------------------------------------
>
> Key: WFLY-8209
> URL: https://issues.jboss.org/browse/WFLY-8209
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 10.1.0.Final
> Reporter: John Hovell
> Assignee: Alessio Soldano
>
> I have created an example which is actually a fork of the Wildfly Swarm repo. I could re-create the example:
> https://github.com/jhovell/wildfly-swarm-examples/tree/jaxrs-validation (project in subfolder jaxrs/jaxrs-cdi). The tip of this branch shows it is working in WF 10.0. The commit earlier shows it broken in WF 10.1.
> If a JAX-RS resource is defined as an interface with an implementation that doesn't have a single arg constructor, in WF 10.0 you had to work around the issue in a roundabout way by extending the Application class, using the BeanManager to get the actual bean (not the proxy) and register it with JAX-RS. This seemed to be the only solution as even if you made a bean with a @Produces method on a managed bean, Resteasy still wouldn't know how to construct the bean. You get a fairly generic error that Resteasy can't find a constructor for the implementation (not the interface). See error below.
> Despite being roundabout, this worked. In WF 10.1 the behavior is very surprising in that it executes the resource method even though input validation failed, and then it returns a 400 with a validation message (as expected) but with the nasty side effect that the resource method was executed (and it may have crashed due to null pointers, in which case the user gets 500 instead of 400).
> [pre]
> 2017-02-22 19:26:08,213 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 5) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./: java.lang.RuntimeException: RESTEASY003190: Could not find constructor for class: org.wildfly.swarm.examples.jaxrs.cdi.api.EmployeeController
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.RuntimeException: RESTEASY003190: Could not find constructor for class: org.wildfly.swarm.examples.jaxrs.cdi.api.EmployeeController
> at org.jboss.resteasy.spi.metadata.ResourceBuilder.constructor(ResourceBuilder.java:692)
> at org.jboss.resteasy.plugins.server.resourcefactory.POJOResourceFactory.registered(POJOResourceFactory.java:42)
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:208)
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:194)
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:180)
> [pre]
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8209) JAX-RS Executes resource method even when input validation fails
by John Hovell (JIRA)
John Hovell created WFLY-8209:
---------------------------------
Summary: JAX-RS Executes resource method even when input validation fails
Key: WFLY-8209
URL: https://issues.jboss.org/browse/WFLY-8209
Project: WildFly
Issue Type: Bug
Components: REST
Affects Versions: 10.1.0.Final
Reporter: John Hovell
Assignee: Stuart Douglas
I have created an example which is actually a fork of the Wildfly Swarm repo. I could re-create the example:
https://github.com/jhovell/wildfly-swarm-examples/tree/jaxrs-validation (project in subfolder jaxrs/jaxrs-cdi). The tip of this branch shows it is working in WF 10.0. The commit earlier shows it broken in WF 10.1.
If a JAX-RS resource is defined as an interface with an implementation that doesn't have a single arg constructor, in WF 10.0 you had to work around the issue in a roundabout way by extending the Application class, using the BeanManager to get the actual bean (not the proxy) and register it with JAX-RS. This seemed to be the only solution as even if you made a bean with a @Produces method on a managed bean, Resteasy still wouldn't know how to construct the bean. You get a fairly generic error that Resteasy can't find a constructor for the implementation (not the interface). See error below.
Despite being roundabout, this worked. In WF 10.1 the behavior is very surprising in that it executes the resource method even though input validation failed, and then it returns a 400 with a validation message (as expected) but with the nasty side effect that the resource method was executed (and it may have crashed due to null pointers, in which case the user gets 500 instead of 400).
[pre]
2017-02-22 19:26:08,213 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 5) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./: java.lang.RuntimeException: RESTEASY003190: Could not find constructor for class: org.wildfly.swarm.examples.jaxrs.cdi.api.EmployeeController
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: java.lang.RuntimeException: RESTEASY003190: Could not find constructor for class: org.wildfly.swarm.examples.jaxrs.cdi.api.EmployeeController
at org.jboss.resteasy.spi.metadata.ResourceBuilder.constructor(ResourceBuilder.java:692)
at org.jboss.resteasy.plugins.server.resourcefactory.POJOResourceFactory.registered(POJOResourceFactory.java:42)
at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:208)
at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:194)
at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:180)
[pre]
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8141) CachedConnectionManager add operation accepts no parameters anymore
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-8141?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-8141:
-----------------------------------
Summary: CachedConnectionManager add operation accepts no parameters anymore (was: CachedConnectionManager add operation excepts no parameters anymore)
> CachedConnectionManager add operation accepts no parameters anymore
> -------------------------------------------------------------------
>
> Key: WFLY-8141
> URL: https://issues.jboss.org/browse/WFLY-8141
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, JCA
> Affects Versions: 11.0.0.Alpha1
> Reporter: Tomaz Cerar
> Assignee: Brian Stansberry
> Priority: Critical
>
> Fix for WFLY-2640 broke :add operation for cached-connection-manager
> scipts that do
> {noformat}
> /profile=default-web/subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
> {noformat}
> {noformat}
> /subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
> {noformat}
> now fail with
> {{Operation 'add' does not expect any property.}}
> This breaks our quickstarts
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months