Re: [Resteasy-users] Application subclass without mapping

2012-09-04 Thread Bill Burke
Change "javax.ws.rs.core.Application" to "javax.ws.rs.Application". 
That is the correct way to do it.  (Still might not work).

On 9/4/2012 12:22 PM, Duncan Bloem wrote:
> No, I have:
>
> 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";>
>  jaxrs
>  
>  javax.ws.rs.core.Application
>  /*
>  
>  
>  
>  30
>  
>  
> 
>
> 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  > wrote:
>
> SO, you have:
>
> 
>  
>  Resteasy
>  
>
> org.jboss.resteasy.plugins.__server.servlet.__HttpServletDispatcher
>  
>  
>  javax.ws.rs
> .__Application
>
> 
> com.restfully.__shop.services.__ShoppingApplication
>  
>  
>
>  
>  Resteasy
>  /*
>  
>
> 
>
> 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  
> >> 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  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
>   >
>

Re: [Resteasy-users] Application subclass without mapping

2012-09-04 Thread Duncan Bloem
No, I have:

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";>
jaxrs

javax.ws.rs.core.Application
/*



30




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  wrote:

> SO, you have:
>
> 
> 
> Resteasy
> 
> org.jboss.resteasy.plugins.**server.servlet.**
> HttpServletDispatcher
> 
> 
> javax.ws.rs.**Application
>
> com.restfully.**shop.services.**ShoppingApplication value>
> 
> 
>
> 
> Resteasy
> /*
> 
>
> 
>
> 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 > > 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  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/
>>  >
>>  >
>>  >
>>  > __**_
>>  > Resteasy-users mailing list
>>  > 
>> Resteasy-users@lists.**sourceforge.net
>> 
>> > >
>>
>>  > 
>> https://lists.sourceforge.net/**lists/listinfo/resteasy-users

Re: [Resteasy-users] Problem using RESTEasy mock framework withexception mapper

2012-09-04 Thread Bill Burke
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:
>  standalone="yes"?>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
> 
> *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

Re: [Resteasy-users] Application subclass without mapping

2012-09-04 Thread Bill Burke
SO, you have:


 
 Resteasy
 
 org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher
 
 
 javax.ws.rs.Application
 
com.restfully.shop.services.ShoppingApplication
 
 

 
 Resteasy
 /*
 



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  > 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  for the
> Application
>  > sub-class in web.xml, deployment fails under JBoss AS7 with the
>  > following error:
>  > DeploymentUnitProcessingException: 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/
>  >
>  >
>  >
>  > ___
>  > Resteasy-users mailing list
>  > Resteasy-users@lists.sourceforge.net
> 
>  > https://lists.sourceforge.net/lists/listinfo/resteasy-users
>  >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> 
> --
> 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/
> ___
> Resteasy-users mailing list
> Resteasy-users@lists.sourceforge.net
> 
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

--
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/
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users


[Resteasy-users] 'Unable to find contextual data of type: javax.servlet.ServletContext'

2012-09-04 Thread Peter Courcoux
Hi,

I have resteasy deployed in jboss as7.1.1 and, on startup, am getting an 
org.jboss.resteasy.spi.LoggableFailure with the above message.

I would guess that this is a configuration or missing library error, but if 
someone could explain what the error means and point me in the right direction 
to fix it I would much appreciate it.

Many thanks,

Peter
--
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/___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users