Re: [Resteasy-users] Problem using RESTEasy mock framework withexception mapper
Our queue is pretty full at the moment, Log a JIRA and we'll put it on
our Queue.
On 9/3/2012 5:43 PM, Jim Showalter wrote:
The response to this wasn’t exactly overwhelming. One email said the
mock framework is going to be deprecrated, which is fine, but in the
meantime it would be good to find the cause of this.
A few minor changes to show that it’s tied to the exception:
package com.foo;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
@Path(/rest/v1)
public class FooService {
public static boolean BLOW_UP = false;
@GET
@Path(/foo)
@Produces({application/xml})
public Foo doFoo() throws FooValidationException {
if (BLOW_UP) {
throw new FooValidationException(FOO);
}
Foo foo = new Foo();
foo.setName(FOO);
return foo;
}
}
package com.foo;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.UnsupportedEncodingException;
import java.net.URISyntaxException;
import org.jboss.resteasy.core.Dispatcher;
import org.jboss.resteasy.mock.MockDispatcherFactory;
import org.jboss.resteasy.mock.MockHttpRequest;
import org.jboss.resteasy.mock.MockHttpResponse;
import
org.jboss.resteasy.plugins.server.resourcefactory.POJOResourceFactory;
public final class TestFooExceptionMapper {
public static void main(String[] args) throws URISyntaxException,
UnsupportedEncodingException, IOException {
Dispatcher dispatcher = MockDispatcherFactory.createDispatcher();
dispatcher.getRegistry().addResourceFactory(new
POJOResourceFactory(FooService.class));
dispatcher.getProviderFactory().addExceptionMapper(FooExceptionMapper.class);
MockHttpRequest request;
MockHttpResponse response;
System.out.println(Test without exception:);
request = MockHttpRequest.get(/rest/v1/foo);
response = new MockHttpResponse();
dispatcher.invoke(request, response);
System.out.println(new
String(((ByteArrayOutputStream)response.getOutputStream()).toByteArray(),
UTF-8));
System.out.println();
System.out.println(Test with exception:);
request = MockHttpRequest.get(/rest/v1/foo);
response = new MockHttpResponse();
FooService.BLOW_UP = true;
dispatcher.invoke(request, response);
System.out.println(new
String(((ByteArrayOutputStream)response.getOutputStream()).toByteArray(),
UTF-8));
}
}
Test without exception:
?xml version=1.0 encoding=UTF-8
standalone=yes?foonameFOO/name/foo
Test with exception:
Sep 03, 2012 2:34:37 PM org.jboss.resteasy.core.SynchronousDispatcher
SEVERE: Failed executing GET /rest/v1/foo
org.jboss.resteasy.spi.LoggableFailure: Unable to find contextual data
of type: javax.servlet.http.HttpServletRequest
at
org.jboss.resteasy.core.ContextParameterInjector$GenericDelegatingProxy.invoke(ContextParameterInjector.java:56)
at $Proxy18.getHeader(Unknown Source)
at com.foo.FooExceptionMapper.toResponse(FooExceptionMapper.java:50)
at com.foo.FooExceptionMapper.toResponse(FooExceptionMapper.java:1)
at
org.jboss.resteasy.core.SynchronousDispatcher.executeExceptionMapper(SynchronousDispatcher.java:330)
at
org.jboss.resteasy.core.SynchronousDispatcher.unwrapException(SynchronousDispatcher.java:359)
at
org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:348)
at
org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:220)
at
org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:196)
at
org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:551)
at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:513)
at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125)
at com.foo.TestFooExceptionMapper.main(TestFooExceptionMapper.java:35)
At the point where it blows up, it’s trying to get contextual data for
HttpServletRequest.
Why is it doing that when the type of mock request sent in is a subclass
of HttpRequest? Where does it get confused about the appropriate type to
be looking up? This seems like a bug.
I thought about changing our POM to download resteasy-jaxrs-beta1.jar,
which has a MockHttpServletRequest, but then our test configuration
differs from our runtime configuration in too many ways.
*Sent:* Monday, August 27, 2012 9:42 AM
*To:* resteasy-users@lists.sourceforge.net
mailto:resteasy-users@lists.sourceforge.net
*Subject:* [Resteasy-users] Problem using RESTEasy mock framework
withexception mapper
RESTEasy mock framework works fine without exception mapper--request is
received and entity is returned with expected contents.
After registering exception mapper and forcing an exception, call fails
Re: [Resteasy-users] Application subclass without mapping
No, I have:
web-app version=3.0 xmlns=http://java.sun.com/xml/ns/javaee; xmlns:xsi=
http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=
http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd;
module-namejaxrs/module-name
servlet-mapping
servlet-namejavax.ws.rs.core.Application/servlet-name
url-pattern/*/url-pattern
/servlet-mapping
session-config
session-timeout
30
/session-timeout
/session-config
/web-app
including
public class MyApplication extends Application {} //without annotation
this fails because of deployment error: JBAS011233: Please use either
@ApplicationPath or servlet mapping for url path config.
if I remove MyApplication.class from the war, everything works fine.
(GF deploys the same war (including MyApplication) without errors)
The jax-rs documentation 2.3.2 Servlet states in bullet 3 the following:
If the Application subclass is not annotated with @ApplicationPath then
the application MUST
be packaged with a web.xml that specifies a servlet mapping for the added
servlet.
however, the header of these bullets states:
When using the pluggability mechanism the following conditions MUST be
met:
Does this mean if NON of the conditions are met, the pluggability mechanism
should not be activated..?
I think Resteasy and Jersey did interpret it differently ;-)
Regards,
Duncan
On Tue, Sep 4, 2012 at 4:09 PM, Bill Burke bbu...@redhat.com wrote:
SO, you have:
web-app
servlet
servlet-nameResteasy/**servlet-name
servlet-class
org.jboss.resteasy.plugins.**server.servlet.**
HttpServletDispatcher
/servlet-class
init-param
param-namejavax.ws.rs.**Application/param-name
param-valuecom.restfully.**shop.services.**ShoppingApplication/param-**
value
/init-param
/servlet
servlet-mapping
servlet-nameResteasy/**servlet-name
url-pattern/*/url-pattern
/servlet-mapping
/web-app
And it doesn't deploy because a different Application class was found?
On 9/2/2012 6:49 AM, Duncan Bloem wrote:
I want to have web.xml decide which Application class should be
registered.
(GF and JBoss profiles have different web.xml)
I would have expected that the Application sub-class is disregarded,
because there is no annotation and no servlet mapping. JBoss should just
register javax.ws.rs.core.Application when defined in the web.xml, but
deployment fails because of the error of the missing mapping for the
(scanned) sub-class. So, maybe a warning is more appropriate then a
failure.
GF does disregard the sub-class and deploys fine and registers the
javax.ws.rs.core.Application class.
(The use case is that GF requires configuration, while JBoss needs no
configuration)
Regards,
Duncan
On Sat, Sep 1, 2012 at 1:36 PM, Bill Burke bbu...@redhat.com
mailto:bbu...@redhat.com wrote:
I don't understand, you have an Application class not annotated?
*AND*
you have a different application class declared in web.xml?
What do you expect to happen? What does GF 3.1 do? The spec is kinda
vague here.
Originally if you had an Application class without @ApplicationPath,
resteasy would just map it to /*, but, somebody on the AS7 team
changed
the code without telling me and now you get this error...
On 9/1/2012 6:12 AM, Duncan Bloem wrote:
Hello,
When there is a Sub-class of Application on the classpath without
@ApplicationPath annotation nor a servlet-mapping for the
Application
sub-class in web.xml, deployment fails under JBoss AS7 with the
following error:
DeploymentUnitProcessingExcept**ion: JBAS011233: Please use either
@ApplicationPath or servlet mapping for url path config.
at JaxrsIntegrationProcessor.**deploy(line:171)
Just wondering of this is the correct behaviour, because it could
also
just skip this sub-class (because there is no mapping, and e.g. use
javax.ws.rs.core.Application if defined in web.xml).
Like to hear your opinion...
ps, I noticed this behaviour to have the application GF3.1 and AS7
compatible.
Regards,
Duncan
--**--**
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond.
Discussions
will include endpoint security, mobile security and the latest in
malware
threats. http://www.accelacomm.com/jaw/**
sfrnl04242012/114/50122263/http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
__**_
Resteasy-users mailing list
