resteasy-users — A general discussion list for the projects end users of RESTEasy.

[Resteasy-users] exception mappers and intercepting them?

[Tom B. <tb...@re...>]

We currently use exception mappers, but I ran across an odd case.  We work as a proxy to other systems, so if we get back a poorly formed response, we have an exception mapper for JAXBUnmarshalException.  The problem is, if somebody sends in (to us) a poorly formatted request, it also hits our mapper (as it's the same exception.)  In this case, we would like the responses to be different.  If the user sends in poorly formatted XML for example, we would return a 400 response.  If we get a bad response from the call we make to the upstream system, then we return a 502 response.  If I put this exception mapper in place, we get all 502s.  Is there a way to differentiate?  Is this a case where I shouldn't deal with the mapper and simply catch this exception from the upstream system and throw a 502?  Thanks in advance!
-Tom

[Resteasy-users] Caused by: org.jboss.modules.ModuleNotFoundException: Module org.jboss.resteasy.skeleton-key:main

[Qaiser M. <for...@gm...>]

Hello Everyone,

I am trying to deploy oauth2 examples on JBoss AS 7.1.0 and JBoss-EAP.6.1
and getting the following error :

Example SSO Auth Server Using a Local Security Domain  FAILURE [2.195s]
[INFO] JAX-RS Database Service Using OAuth Bearer Tokens . SKIPPED
[INFO] Simple Example Secure Application via Valve ....... SKIPPED
[INFO] Simple Example Secure Application via Valve ....... SKIPPED
[INFO] Simple OAuth Client ............................... SKIPPED
[INFO] Simple Client Token Grant Example ................. SKIPPED
[INFO] Resteasy Skeleton Key Examples POM ................ SKIPPED


23:47:54,645 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3)
MSC00001: Failed to start service
jboss.module.service."deployment.auth-server.war".main:
org.jboss.msc.service.StartException in service
jboss.module.service."deployment.auth-server.war".main: Failed to load
module: deployment.auth-server.war:main
    at
org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91)
[jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
    at
org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
[jboss-msc-1.0.2.GA.jar:1.0.2.GA]
    at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
[jboss-msc-1.0.2.GA.jar:1.0.2.GA]
    at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
[classes.jar:1.6.0_65]
    at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
[classes.jar:1.6.0_65]
    at java.lang.Thread.run(Thread.java:695) [classes.jar:1.6.0_65]
Caused by: org.jboss.modules.ModuleNotFoundException: Module
org.jboss.resteasy.skeleton-key:main is not found in local module loader
@153c375 (roots: /Users/qaiser_malik/jboss-as-7.1.1.Final/modules)
    at
org.jboss.modules.LocalModuleLoader.findModule(LocalModuleLoader.java:126)
    at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:275)
    at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:222)
    at
org.jboss.modules.LocalModuleLoader.preloadModule(LocalModuleLoader.java:94)
    at
org.jboss.modules.ModuleLoader.preloadExportedModule(ModuleLoader.java:233)
    at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:246)
    at
org.jboss.as.server.moduleservice.ServiceModuleLoader.preloadModule(ServiceModuleLoader.java:160)
[jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
    at org.jboss.modules.Module.addPaths(Module.java:841)
    at org.jboss.modules.Module.link(Module.java:1181)
    at org.jboss.modules.Module.relinkIfNecessary(Module.java:1207)
    at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:208)
    at
org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:70)
[jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
    ... 5 more

*I did unzip resteasy-jboss-modules-3.0.7.Final and
resteasy-jboss-modules-wf8-3.0.7.Final* in the module directory.

Any help in this matter will be really appreciated.

Thanks

Re: [Resteasy-users] call methods after javax.ws.rs.core.Application initialization

[Weinan Li <l.w...@gm...>]

Why not trying to use embed server, which you can have better control on lifecycle:


http://docs.jboss.org/resteasy/docs/3.0-beta-3/userguide/html_single/#RESTEasy_Embedded_Container









Sent with Unibox



> On Mar 6, 2014, at 10:43 PM, Alexandros Antoniadis <ant...@gm...> wrote:
> 
> 
> I use RestEasy to develop a web application. I have a class that
> extends javax.ws.rs.core.Application and registers the REST services.
> After the creation and (full) initialization of all the services I
> want to execute some methods of these services. These methods may call
> other methods of the service using the REST API.
> 
> 
> The problem is that until the moment that my subclass of
> javax.ws.rs.core.Application is initialized (end of constructor) the
> REST API is not available (calls using REST API block) so it is not
> possible to call the methods after the service initialization. I also,
> tried using org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap
> without success.
> 
> 
> Also, ServletContextListener.contextInitialized seems to be executed
> earlier than the javax.ws.rs.core.Application.init so there are no
> references to the service objects.
> 
> 
> In general, I am looking for a clean way to execute code right after
> the services are available/deployed. Is there any way to be notified
> for such an event?
> 
> 
> Thank you,
> Alex
> 
> 
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries. Built-in WAN optimization and the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> Resteasy-users mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
> 
> 
> 

[Resteasy-users] Adding RestEasy Jars to a local/openshift jboss server

[andrew s. <and...@gm...>]

I've been working with a JBoss AS 7.1.1 Server and trying to use a more
recent version of RestEasy than is included by standard.

Furthermore I've been doing this both on a local JBoss Server and on a
remote OpenShift version.

So far I've been working on the assumption that I need to update the server
with the entire module distribution (circa 6Mb of jars) because of
interdependencies.

Is this in fact true if I'm only using a subset of the API? (shown below)

Updating the local server only needs to be done once, but I'd like to make
the deploy process a little leaner for the remote OpenShift server; I
assume the entire set of jars is checked out of the git repository every
time a deployment is made.

Thanks

Andrew


 <!-- REST -->
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-client</artifactId>
<version>${version.org.jboss.resteasy}</version>
<scope>provided</scope>
</dependency>

<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-jackson-provider</artifactId>
<version>${version.org.jboss.resteasy}</version>
<scope>provided</scope>
</dependency>

<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>jaxrs-api</artifactId>
<version>${version.org.jboss.resteasy}</version>
<scope>provided</scope>
</dependency>

<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-jaxrs</artifactId>
<version>${version.org.jboss.resteasy}</version>
<scope>provided</scope>
</dependency>

[Resteasy-users] Bean Validation, RestEasy 2.3.7, and Jboss 6 (No BeanParam allowed)

[Lukas B. <luk...@gm...>]

The short question:

Does RestEasy 2.3.7 (or Hibernate Validator) have a method like the
following?

  Set<ValidationConstraints> setAndValidate(Object bean, Map<String,
Object> paramMap) ;

I need for the parameters to be converted to their desired types (Long,
Date, etc) and validated.  If successful, the parameters should be set on
the bean.  If not successful, one or more validation constraints should be
included in the return set.


The background:

I'm using JBoss 6 and Resteasy 2.3.7.Final.  I would love to use later
versions of both products, but JBoss 7+ is not an option, and Resteasy 3+
doesn't play nice with JBoss 6.

I'm attempting to parse a multitude of path parameters that are converted
into numbers, enums, dates, etc.  Since I'm forced to utilize JAX-RS 1.1,
and therefore can not use JAX-RS BeanParam annotations, I'm having an
incredibly difficult time creating an object from path params while using
Bean Validation (Hibernate Validation).

(I'm asking this group because it seems as if RestEasy is the mechanism by
which parameters are validated then set using the @PathParam annotations.)

It would be very useful if I could provide all parameter arguments in a map
where the key is the bean property name and the value is the raw String
object provided via a regular expression as such:

  @Path("/my/uri/path/{param:.*/.*/.*}")

I would love any and all suggestions.

[Resteasy-users] How-to questions from a noob

[Willden, J. <jef...@op...>]

I would like to make a web API that can return JSON data but I'm debating whether to make it RESTful or whether to try something more along the lines of an orchestration API. 
Can resteasy make an API that responds with multiple data types in one response?
Does resteasy have the ability to do deep loads and deep saves?

Two Simple "Deep" Scenarios:
If I request a list of users and the groups they each belong to, I don't want the same group sent multiple times with each member, but rather a foreign key that I can use to match up with the groups that each user belongs to. However, if I make one request for users, then another request for the groups that they all belong to, then I've made two round trips when I should only have to make one. Does resteasy have a mechanism for sending data of multiple (related) data types in one response to avoid additional http requests?

Likewise, if I'm saving a new user and the group already exists, I can just save a foreign key to the group. But if the user and the group are both being created with the same http request, I would expect it to first persist the group, obtain the new group's primary key, and then persist the user with a foreign key to the group that was just persisted. Does resteasy address this use case? I can handle the directed object graph so that dependencies get persisted before things that depend upon them. But I'm just wondering if resteasy provides a vehicle for this type of transaction.

I'm under the impression that strict REST defines different URLs for different resources (users and groups), so I understand that resteasy may not address those use cases _by design_. Or perhaps it has another means of reducing or combining requests when obtaining data of different types.

Thanks.

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.

Re: [Resteasy-users] Wrong build order?

[Bill B. <bb...@re...>]

Thanks, i'll fix it tomorrow when I do a 3.0.8 release.

On 4/7/2014 9:32 PM, John D. Ament wrote:
> Hi
>
> Just noticed that in master right now, the code can't compile.  There's
> a new  resteasy-hibernatevalidator-provider module that depends on the
> resteasy-cdi module, however the resteasy-cdi module doesn't come until
> much later in the build.
>
> Likewise, Resteasy CDI doesn't compile because of:
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
> (default-compile) on project resteasy-cdi: Compilation failure:
> Compilation failure:
> [ERROR]
> /c:/resteasy/Resteasy/jaxrs/resteasy-cdi/src/main/java/org/jboss/resteasy/cdi/JaxrsInjectionTarget.java:[16,41]
> cannot find symbol
> [ERROR] symbol:   class GeneralValidatorCDI
> [ERROR] location: package org.jboss.resteasy.spi.validation
> [ERROR]
> /c:/resteasy/Resteasy/jaxrs/resteasy-cdi/src/main/java/org/jboss/resteasy/cdi/JaxrsInjectionTarget.java:[31,12]
> cannot find symbol
> [ERROR] symbol:   class GeneralValidatorCDI
> [ERROR] location: class org.jboss.resteasy.cdi.JaxrsInjectionTarget<T>
> [ERROR]
> /c:/resteasy/Resteasy/jaxrs/resteasy-cdi/src/main/java/org/jboss/resteasy/cdi/JaxrsInjectionTarget.java:[39,23]
> cannot find symbol
> [ERROR] symbol:   class GeneralValidatorCDI
> [ERROR] location: class org.jboss.resteasy.cdi.JaxrsInjectionTarget<T>
> [ERROR]
> /c:/resteasy/Resteasy/jaxrs/resteasy-cdi/src/main/java/org/jboss/resteasy/cdi/JaxrsInjectionTarget.java:[39,90]
> cannot find symbol
> [ERROR] symbol:   class GeneralValidatorCDI
> [ERROR] location: class org.jboss.resteasy.cdi.JaxrsInjectionTarget<T>
> [ERROR]
> /c:/resteasy/Resteasy/jaxrs/resteasy-cdi/src/main/java/org/jboss/resteasy/cdi/JaxrsInjectionTarget.java:[42,57]
> cannot find symbol
> [ERROR] symbol:   class GeneralValidatorCDI
> [ERROR] location: class org.jboss.resteasy.cdi.JaxrsInjectionTarget<T>
>
> Was this on purpose?
>
> John
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
>
>
>
> _______________________________________________
> Resteasy-users mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>

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

[Resteasy-users] Wrong build order?

[John D. A. <joh...@gm...>]

Hi

Just noticed that in master right now, the code can't compile.  There's a
new  resteasy-hibernatevalidator-provider module that depends on the
resteasy-cdi module, however the resteasy-cdi module doesn't come until
much later in the build.

Likewise, Resteasy CDI doesn't compile because of:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
(default-compile) on project resteasy-cdi: Compilation failure: Compilation
failure:
[ERROR]
/c:/resteasy/Resteasy/jaxrs/resteasy-cdi/src/main/java/org/jboss/resteasy/cdi/JaxrsInjectionTarget.java:[16,41]
cannot find symbol
[ERROR] symbol:   class GeneralValidatorCDI
[ERROR] location: package org.jboss.resteasy.spi.validation
[ERROR]
/c:/resteasy/Resteasy/jaxrs/resteasy-cdi/src/main/java/org/jboss/resteasy/cdi/JaxrsInjectionTarget.java:[31,12]
cannot find symbol
[ERROR] symbol:   class GeneralValidatorCDI
[ERROR] location: class org.jboss.resteasy.cdi.JaxrsInjectionTarget<T>
[ERROR]
/c:/resteasy/Resteasy/jaxrs/resteasy-cdi/src/main/java/org/jboss/resteasy/cdi/JaxrsInjectionTarget.java:[39,23]
cannot find symbol
[ERROR] symbol:   class GeneralValidatorCDI
[ERROR] location: class org.jboss.resteasy.cdi.JaxrsInjectionTarget<T>
[ERROR]
/c:/resteasy/Resteasy/jaxrs/resteasy-cdi/src/main/java/org/jboss/resteasy/cdi/JaxrsInjectionTarget.java:[39,90]
cannot find symbol
[ERROR] symbol:   class GeneralValidatorCDI
[ERROR] location: class org.jboss.resteasy.cdi.JaxrsInjectionTarget<T>
[ERROR]
/c:/resteasy/Resteasy/jaxrs/resteasy-cdi/src/main/java/org/jboss/resteasy/cdi/JaxrsInjectionTarget.java:[42,57]
cannot find symbol
[ERROR] symbol:   class GeneralValidatorCDI
[ERROR] location: class org.jboss.resteasy.cdi.JaxrsInjectionTarget<T>

Was this on purpose?

John

Re: [Resteasy-users] Is there a way to prevent a @PathParam from being uri encoded?

[Joseph O. <jo...@en...>]

I think it'd be useful. :)


On Mon, Apr 7, 2014 at 8:31 PM, Scott Stark <ss...@re...> wrote:

> I wouldn't worry about it unless its useful in general as I would rather
> just use what is shipped with the wildfly distribution to simplify set in
> the lab. Like I said, it is a simple workaround to wrap the client proxy in
> another proxy that just overrides this method to build the request uri
> without encoding.
>
> ----- Original Message -----
> From: "Bill Burke" <bb...@re...>
> To: res...@li...
> Sent: Tuesday, April 8, 2014 4:56:37 AM
> Subject: Re: [Resteasy-users] Is there a way to prevent a @PathParam from
> being uri encoded?
>
> No, there's no workaround at the moment.  If you are able to upgrade to
> latest/greatest of Resteasy, I could add something in the 3.0.8 release
> that is tomorrow.
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Resteasy-users mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>



-- 
Joseph B. Ottinger
http://enigmastation.com
*Memento mori.*

Re: [Resteasy-users] Is there a way to prevent a @PathParam from being uri encoded?

[Scott S. <ss...@re...>]

I wouldn't worry about it unless its useful in general as I would rather just use what is shipped with the wildfly distribution to simplify set in the lab. Like I said, it is a simple workaround to wrap the client proxy in another proxy that just overrides this method to build the request uri without encoding.

----- Original Message -----
From: "Bill Burke" <bb...@re...>
To: res...@li...
Sent: Tuesday, April 8, 2014 4:56:37 AM
Subject: Re: [Resteasy-users] Is there a way to prevent a @PathParam from being uri encoded?

No, there's no workaround at the moment.  If you are able to upgrade to 
latest/greatest of Resteasy, I could add something in the 3.0.8 release 
that is tomorrow.

Re: [Resteasy-users] Is there a way to prevent a @PathParam from being uri encoded?

[Bill B. <bb...@re...>]

No, there's no workaround at the moment.  If you are able to upgrade to 
latest/greatest of Resteasy, I could add something in the 3.0.8 release 
that is tomorrow.

On 4/7/2014 7:32 PM, Scott Stark wrote:
>
> I have a client interface with a method like:
>
> public interface INSP {
>     @PUT
>     @Path("/{domain}/subscriptions/{endpoint}{resourcePath}")
>     @Produces("application/json")
>     public String subscribeEndpointResource(@PathParam("domain") String domain,
>                      @PathParam("endpoint") String endpoint,
>                      @PathParam("resourcePath") String resourcePath);
> }
>
> A call like:
>
>     nsp.subscribeEndpointResource("domain", "mbed-ethernet-1DE41", "/303/0/5700");
>
> results in a request with the resourcePath component of the request URI being encoded:
>
> 16:14:55,173 INFO  [org.jboss.devnation.iotbof.ejbs.NSPConnector] (default task-11) mbed-ethernet-1DE41(/303/0/5700)=32.12, observable=true
>
> 16:14:55,174 INFO  [stdout] (default task-11) +++ Request(PUT) to: http://red-hat-summit.cloudapp.net:8080/domain/subscriptions/mbed-ethernet-1DE41%2F303%2F0%2F5700
> 16:14:55,174 INFO  [stdout] (default task-11) --- Headers:
> 16:14:55,174 INFO  [stdout] (default task-11) 	Accept: application/json
> 16:14:55,174 INFO  [stdout] (default task-11) 	Authorization: Basic YWRtaW46c2VjcmV0
> 16:14:55,174 INFO  [stdout] (default task-11) 	Accept-Encoding: gzip, deflate
> 16:14:55,174 INFO  [stdout] (default task-11) --- End Headers:
> 16:14:55,175 INFO  [stdout] (default task-11) null
> 16:14:55,175 INFO  [stdout] (default task-11) --- End Body:
> 16:14:55,209 INFO  [stdout] (default task-11) +++ Response from: http://red-hat-summit.cloudapp.net:8080/domain/subscriptions/mbed-ethernet-1DE41%2F303%2F0%2F5700, status=Method Not Allowed
> 16:14:55,209 INFO  [stdout] (default task-11) --- Headers:
> 16:14:55,209 INFO  [stdout] (default task-11) 	Content-Type: application/octet-stream
> 16:14:55,210 INFO  [stdout] (default task-11) 	Content-Length: 62
> 16:14:55,210 INFO  [stdout] (default task-11) 	Server: NSP/1.11.0-2
> 16:14:55,210 INFO  [stdout] (default task-11) --- End Headers:
> 16:14:55,210 WARN  [org.jboss.devnation.iotbof.ejbs.NSPConnector] (default task-11) Failed to load mbed-ethernet-1DE41/303/0/5700 resource
> : javax.ws.rs.NotAllowedException: HTTP 405 Method Not Allowed
> 	at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.handleErrorStatus(ClientInvocation.java:183) [resteasy-client-3.0.6.Final.jar:]
> 	at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.extractResult(ClientInvocation.java:154) [resteasy-client-3.0.6.Final.jar:]
> 	at org.jboss.resteasy.client.jaxrs.internal.proxy.extractors.BodyEntityExtractor.extractEntity(BodyEntityExtractor.java:58) [resteasy-client-3.0.6.Final.jar:]
> 	at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientInvoker.invoke(ClientInvoker.java:104) [resteasy-client-3.0.6.Final.jar:]
> 	at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientProxy.invoke(ClientProxy.java:62) [resteasy-client-3.0.6.Final.jar:]
> 	at com.sun.proxy.$Proxy71.subscribeEndpointResource(Unknown Source)
> 	at org.jboss.devnation.iotbof.ejbs.NSPConnector.reload(NSPConnector.java:179) [iotbof-ejb.jar:]
>
>
> The server is barfing on this because it is not uri decoding its incoming request uris. I don't have any control over it, so is there a way to prevent the resourcePath from being encoded?
>
> Its easy enough to work around by coding my own subscribeEndpointResource utility method using the rest easy client classes, but it would be nice to simply be able to use the generated
> web target proxy.
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Resteasy-users mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>

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

[Resteasy-users] Is there a way to prevent a @PathParam from being uri encoded?

[Scott S. <ss...@re...>]

I have a client interface with a method like:

public interface INSP {
   @PUT
   @Path("/{domain}/subscriptions/{endpoint}{resourcePath}")
   @Produces("application/json")
   public String subscribeEndpointResource(@PathParam("domain") String domain,
                    @PathParam("endpoint") String endpoint,
                    @PathParam("resourcePath") String resourcePath);
}

A call like:

   nsp.subscribeEndpointResource("domain", "mbed-ethernet-1DE41", "/303/0/5700");

results in a request with the resourcePath component of the request URI being encoded:

16:14:55,173 INFO  [org.jboss.devnation.iotbof.ejbs.NSPConnector] (default task-11) mbed-ethernet-1DE41(/303/0/5700)=32.12, observable=true

16:14:55,174 INFO  [stdout] (default task-11) +++ Request(PUT) to: http://red-hat-summit.cloudapp.net:8080/domain/subscriptions/mbed-ethernet-1DE41%2F303%2F0%2F5700
16:14:55,174 INFO  [stdout] (default task-11) --- Headers:
16:14:55,174 INFO  [stdout] (default task-11) 	Accept: application/json
16:14:55,174 INFO  [stdout] (default task-11) 	Authorization: Basic YWRtaW46c2VjcmV0
16:14:55,174 INFO  [stdout] (default task-11) 	Accept-Encoding: gzip, deflate
16:14:55,174 INFO  [stdout] (default task-11) --- End Headers:
16:14:55,175 INFO  [stdout] (default task-11) null
16:14:55,175 INFO  [stdout] (default task-11) --- End Body:
16:14:55,209 INFO  [stdout] (default task-11) +++ Response from: http://red-hat-summit.cloudapp.net:8080/domain/subscriptions/mbed-ethernet-1DE41%2F303%2F0%2F5700, status=Method Not Allowed
16:14:55,209 INFO  [stdout] (default task-11) --- Headers:
16:14:55,209 INFO  [stdout] (default task-11) 	Content-Type: application/octet-stream
16:14:55,210 INFO  [stdout] (default task-11) 	Content-Length: 62
16:14:55,210 INFO  [stdout] (default task-11) 	Server: NSP/1.11.0-2
16:14:55,210 INFO  [stdout] (default task-11) --- End Headers:
16:14:55,210 WARN  [org.jboss.devnation.iotbof.ejbs.NSPConnector] (default task-11) Failed to load mbed-ethernet-1DE41/303/0/5700 resource
: javax.ws.rs.NotAllowedException: HTTP 405 Method Not Allowed
	at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.handleErrorStatus(ClientInvocation.java:183) [resteasy-client-3.0.6.Final.jar:]
	at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.extractResult(ClientInvocation.java:154) [resteasy-client-3.0.6.Final.jar:]
	at org.jboss.resteasy.client.jaxrs.internal.proxy.extractors.BodyEntityExtractor.extractEntity(BodyEntityExtractor.java:58) [resteasy-client-3.0.6.Final.jar:]
	at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientInvoker.invoke(ClientInvoker.java:104) [resteasy-client-3.0.6.Final.jar:]
	at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientProxy.invoke(ClientProxy.java:62) [resteasy-client-3.0.6.Final.jar:]
	at com.sun.proxy.$Proxy71.subscribeEndpointResource(Unknown Source)
	at org.jboss.devnation.iotbof.ejbs.NSPConnector.reload(NSPConnector.java:179) [iotbof-ejb.jar:]


The server is barfing on this because it is not uri decoding its incoming request uris. I don't have any control over it, so is there a way to prevent the resourcePath from being encoded?

Its easy enough to work around by coding my own subscribeEndpointResource utility method using the rest easy client classes, but it would be nice to simply be able to use the generated
web target proxy.

Re: [Resteasy-users] multiple resource locator for same uri

[Chris B. <cbr...@re...>]

Are you saying this is preferable to pivoting on custom media-types? I 
don't care for the versioned-URI scheme because it puts the same 
resource at multiple URIs and thus the I's are no longer U...

On 04/06/2014 08:58 AM, Bill Burke wrote:
> Resteasy cannot dispatch based on header, but I don't recommend a custom
> header anyways.  The best practice solution is to use URIs i.e.
> /v1.0/api and have your client driven by links.  You should also make
> your apis and media types backward compatible.  Its just good practice
> no matter what type of API, REST, Java, or whatever you're doing.
>
> A custom header can often be removed by proxies.  For CORS requests, you
> also have to write custom code to handle custom headers on the server-side.
>
>
> On 4/6/2014 8:06 AM, Aleš Bregar wrote:
>> Hi,
>>
>> was going through docs on version 2.3.x but couldn't find appropriate
>> answer on may issue.
>>
>> I would like to produce versioned api where uri does not change. The
>> idea is to intercept resource locating before auto match happen and
>> decide which method to invoke based on some custom header (eq.
>> Api.Version=x).
>>
>> I have found that this can also be achieved by using Accept header
>> (where version info may be stated) but I am not truly convinced due I
>> would like to produce plain application/json.
>>
>> Or if my idea with custom header presented above is ok, how the scenario
>> may be produced by using resteasy.
>> PreProcess interceptor seems not right as it intercepts after regex
>> match to method happen.
>>
>> Thank you in advance
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>>
>> _______________________________________________
>> Resteasy-users mailing list
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>>
>

Re: [Resteasy-users] multiple resource locator for same uri

[Bill B. <bb...@re...>]

Resteasy cannot dispatch based on header, but I don't recommend a custom 
header anyways.  The best practice solution is to use URIs i.e. 
/v1.0/api and have your client driven by links.  You should also make 
your apis and media types backward compatible.  Its just good practice 
no matter what type of API, REST, Java, or whatever you're doing.

A custom header can often be removed by proxies.  For CORS requests, you 
also have to write custom code to handle custom headers on the server-side.


On 4/6/2014 8:06 AM, Aleš Bregar wrote:
> Hi,
>
> was going through docs on version 2.3.x but couldn't find appropriate
> answer on may issue.
>
> I would like to produce versioned api where uri does not change. The
> idea is to intercept resource locating before auto match happen and
> decide which method to invoke based on some custom header (eq.
> Api.Version=x).
>
> I have found that this can also be achieved by using Accept header
> (where version info may be stated) but I am not truly convinced due I
> would like to produce plain application/json.
>
> Or if my idea with custom header presented above is ok, how the scenario
> may be produced by using resteasy.
> PreProcess interceptor seems not right as it intercepts after regex
> match to method happen.
>
> Thank you in advance
>
>
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Resteasy-users mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>

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

[Resteasy-users] multiple resource locator for same uri

[Aleš B. <ale...@be...>]

Hi,

was going through docs on version 2.3.x but couldn't find appropriate answer on may issue.

I would like to produce versioned api where uri does not change. The idea is to intercept resource locating before auto match happen and decide which method to invoke based on some custom header (eq. Api.Version=x).

I have found that this can also be achieved by using Accept header (where version info may be stated) but I am not truly convinced due I would like to produce plain application/json.

Or if my idea with custom header presented above is ok, how the scenario may be produced by using resteasy.
PreProcess interceptor seems not right as it intercepts after regex match to method happen.

Thank you in advance

[Resteasy-users] multiple resource locator for same uri

[Aleš B. <ale...@be...>]

Hi,

was going through docs on version 2.3.x but couldn't find appropriate answer on may issue.

I would like to produce versioned api where uri does not change. The idea is to intercept resource locating before auto match happen and decide which method to invoke based on some custom header (eq. Api.Version=x).

I have found that this can also be achieved by using Accept header (where version info may be stated) but I am not truly convinced due I would like to produce plain application/json.

Or if my idea with custom header presented above is ok, how the scenario may be produced by using resteasy.
PreProcess interceptor seems not right as it intercepts after regex match to method happen.

Thank you in advance

Re: [Resteasy-users] @OPTIONS / allowing cross-site scripting

[Rajshekhar A. <ran...@re...>]

Its good to hear it worked for you :).

Thanks

A.P. Rajshekhar

----- Original Message -----
From: "andrew simpson" <and...@gm...>
To: "Rajshekhar AndalaPisharam" <ran...@re...>
Cc: res...@li...
Sent: Friday, April 4, 2014 10:04:29 AM
Subject: Re: [Resteasy-users] @OPTIONS / allowing cross-site scripting

Rajshekhar, thanks for this suggestion, that worked for me.

Here's a pointer to an implementation.

https://gist.github.com/ams10961/9968111

Andrew


On Wed, Apr 2, 2014 at 9:03 AM, Rajshekhar AndalaPisharam <
ran...@re...> wrote:

> Andrew
>
> The best option is to make an exception mapper for
> DefaultOptionsMethodException and add the CORS headers within the
> toResponse method of the mapper. For example:
>
> @Provider
> public class OptionsMethodExceptionMapper implements
> ExceptionMapper<DefaultOptionsMethodException>{
>
>     @Override
>     public Response toResponse(DefaultOptionsMethodException exception) {
>
>        Response.ResponseBuilder builder =Response.ok();
>        //..here add CORS to headers of the builder
>        return  builder.build();
>     }
>
>
> By doing this all your resources will have OPTIONS response with CORS
> headers.
>
> Thanks
>
> A.P. Rajshekhar
> ------------------------------
> From: "andrew simpson" <and...@gm...>
> To: res...@li...
> Sent: Tuesday, April 1, 2014 11:28:45 AM
> Subject: [Resteasy-users] @OPTIONS / allowing cross-site scripting
>
> I've hit a well-known problem with cross site scripting; I'd like to
> develop javascript locally, but using REST services hosted remotely
>
>
> http://stackoverflow.com/questions/14589031/ajax-request-with-jax-rs-resteasy-implementing-cors
>
> I've tried a number of ways of implementing an OPTIONS method that allows
> clients from other origins to collect, but none of them seem to work.  I've
> tried curl to confirm with curl, but don't see the access-control-* headers
> returned; my suspicion is that the @path directives are somehow not
> matching my request.
>
> Does anyone have a pointer to an example which works with a recent version
> of RestEasy (I'm using 3.0.6 and JBoss AS 7.1.1)
>
> Thanks..
>
> Andrew
>
>

Re: [Resteasy-users] @OPTIONS / allowing cross-site scripting

[andrew s. <and...@gm...>]

Rajshekhar, thanks for this suggestion, that worked for me.

Here's a pointer to an implementation.

https://gist.github.com/ams10961/9968111

Andrew


On Wed, Apr 2, 2014 at 9:03 AM, Rajshekhar AndalaPisharam <
ran...@re...> wrote:

> Andrew
>
> The best option is to make an exception mapper for
> DefaultOptionsMethodException and add the CORS headers within the
> toResponse method of the mapper. For example:
>
> @Provider
> public class OptionsMethodExceptionMapper implements
> ExceptionMapper<DefaultOptionsMethodException>{
>
>     @Override
>     public Response toResponse(DefaultOptionsMethodException exception) {
>
>        Response.ResponseBuilder builder =Response.ok();
>        //..here add CORS to headers of the builder
>        return  builder.build();
>     }
>
>
> By doing this all your resources will have OPTIONS response with CORS
> headers.
>
> Thanks
>
> A.P. Rajshekhar
> ------------------------------
> From: "andrew simpson" <and...@gm...>
> To: res...@li...
> Sent: Tuesday, April 1, 2014 11:28:45 AM
> Subject: [Resteasy-users] @OPTIONS / allowing cross-site scripting
>
> I've hit a well-known problem with cross site scripting; I'd like to
> develop javascript locally, but using REST services hosted remotely
>
>
> http://stackoverflow.com/questions/14589031/ajax-request-with-jax-rs-resteasy-implementing-cors
>
> I've tried a number of ways of implementing an OPTIONS method that allows
> clients from other origins to collect, but none of them seem to work.  I've
> tried curl to confirm with curl, but don't see the access-control-* headers
> returned; my suspicion is that the @path directives are somehow not
> matching my request.
>
> Does anyone have a pointer to an example which works with a recent version
> of RestEasy (I'm using 3.0.6 and JBoss AS 7.1.1)
>
> Thanks..
>
> Andrew
>
>

Re: [Resteasy-users] @OPTIONS / allowing cross-site scripting

[Bill B. <bb...@re...>]

In 3.0.7 I implemented a CORS filter:

https://github.com/resteasy/Resteasy/blob/master/jaxrs/resteasy-jaxrs/src/main/java/org/jboss/resteasy/plugins/interceptors/CorsFilter.java


On 4/2/2014 3:03 AM, Rajshekhar AndalaPisharam wrote:
> Andrew
>
> The best option is to make an exception mapper for
> DefaultOptionsMethodException and add the CORS headers within the
> toResponse method of the mapper. For example:
>
> @Provider
> public class OptionsMethodExceptionMapper implements
> ExceptionMapper<DefaultOptionsMethodException>{
>
>      @Override
>      public Response toResponse(DefaultOptionsMethodException exception) {
>
>         Response.ResponseBuilder builder =Response.ok();
>         //..here add CORS to headers of the builder
>         return  builder.build();
>      }
>
>
> By doing this all your resources will have OPTIONS response with CORS
> headers.
>
> Thanks
>
> A.P. Rajshekhar
> ------------------------------------------------------------------------
> From: "andrew simpson" <and...@gm...>
> To: res...@li...
> Sent: Tuesday, April 1, 2014 11:28:45 AM
> Subject: [Resteasy-users] @OPTIONS / allowing cross-site scripting
>
> I've hit a well-known problem with cross site scripting; I'd like to
> develop javascript locally, but using REST services hosted remotely
>
> http://stackoverflow.com/questions/14589031/ajax-request-with-jax-rs-resteasy-implementing-cors
>
> I've tried a number of ways of implementing an OPTIONS method that
> allows clients from other origins to collect, but none of them seem to
> work.  I've tried curl to confirm with curl, but don't see the
> access-control-* headers returned; my suspicion is that the @path
> directives are somehow not matching my request.
>
> Does anyone have a pointer to an example which works with a recent
> version of RestEasy (I'm using 3.0.6 and JBoss AS 7.1.1)
>
> Thanks..
>
> Andrew
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Resteasy-users mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>

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

Re: [Resteasy-users] @OPTIONS / allowing cross-site scripting

[Rajshekhar A. <ran...@re...>]

Andrew 

The best option is to make an exception mapper for DefaultOptionsMethodException and add the CORS headers within the toResponse method of the mapper. For example: 

@Provider 
public class OptionsMethodExceptionMapper implements ExceptionMapper<DefaultOptionsMethodException>{ 

@Override 
public Response toResponse(DefaultOptionsMethodException exception) { 

Response.ResponseBuilder builder =Response.ok(); 
//..here add CORS to headers of the builder 
return builder.build(); 
} 


By doing this all your resources will have OPTIONS response with CORS headers. 

Thanks 

A.P. Rajshekhar 
----- Original Message -----
From: "andrew simpson" <and...@gm...> 
To: res...@li... 
Sent: Tuesday, April 1, 2014 11:28:45 AM 
Subject: [Resteasy-users] @OPTIONS / allowing cross-site scripting 

I've hit a well-known problem with cross site scripting; I'd like to develop javascript locally, but using REST services hosted remotely 

http://stackoverflow.com/questions/14589031/ajax-request-with-jax-rs-resteasy-implementing-cors 

I've tried a number of ways of implementing an OPTIONS method that allows clients from other origins to collect, but none of them seem to work. I've tried curl to confirm with curl, but don't see the access-control-* headers returned; my suspicion is that the @path directives are somehow not matching my request. 

Does anyone have a pointer to an example which works with a recent version of RestEasy (I'm using 3.0.6 and JBoss AS 7.1.1) 

Thanks.. 

Andrew 

Re: [Resteasy-users] RestEasy 3.0.7 and Netty 4

[Bill B. <bb...@re...>]

I added a chunked output stream in 3.0.7.  I guess the stream has bugs. 
  I guess I have to do a 3.0.8 release :)

On 4/1/2014 2:51 PM, John D. Ament wrote:
> Hmmm, so this is your output right?
>
> the data length you're describing is in bytes as well, right?
>
> I know I previously had this working in 3.0.6, could you check if your
> code works in 3.0.6?
>
>
> On Tue, Apr 1, 2014 at 2:40 PM, Cédric Chéneau <ced...@gm...
> <mailto:ced...@gm...>> wrote:
>
>     Hello,
>
>     Just tried to upgrade to RestEasy 3.0.7 on my Netty 4 server, I'm
>     facing problem writing json data with length over 1000.
>
>     After debugging, there seems to be an infinite loop in method
>     ChunkOutputStream.write(...)
>
>     In fact, my json data size is over the maximum length defined in
>     NettyHttpResponse constructor:
>
>     os = new ChunkOutputStream(this, ctx, 1000);
>
>     Perhaps I'm missing something.
>
>     Best regards,
>
>     Cdr35
>
>
>
>
>     ------------------------------------------------------------------------------
>
>     _______________________________________________
>     Resteasy-users mailing list
>     Res...@li...
>     <mailto:Res...@li...>
>     https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Resteasy-users mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>

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

Re: [Resteasy-users] (no subject)

[Marcel O. <mar...@gm...>]

Yes that's probably what I will try to use. I only wonder if there is maybe something out of the box?

> On 01 Apr 2014, at 21:59, William Antônio Siqueira <wil...@gm...> wrote:
> 
> Hello,
> 
> have you thought about using an interceptor?
> 
> --
> William Antônio Siqueira
> Java Support Analyst
> 
> http://fxapps.blogspot.com
> http://www.williamantonio.wordpress.com
> http://williamprogrammer.com
> 
> 
> 2014-04-01 15:35 GMT-03:00 Marcel Overdijk <mar...@gm...>:
>> 
>> 
>> 
>> I have a (Groovy) resteasy resource like:
>> 
>>     @POST
>>     @Consumes(MediaType.APPLICATION_JSON)
>>     @Produces(MediaType.APPLICATION_JSON)
>>     def create(CustomerRequestBody body) {
>>         def customer = new Customer()
>>         bindData(customer, body)
>>         def violations = validate(customer)
>>         if (violations) {
>>             return Response.status(BAD_REQUEST).entity(toJSONArray(violations)).build()
>>         } else {
>>             customer.save()
>>             return Response.status(OK).entity(toJSONObject(customer)).build()
>>         }
>>     }
>> 
>> The resource only accepts json requests.
>> The CustomerRequestBody is a simple POJO (or POGO in my case).
>> 
>> When I post a empty response to the this resource (even with content type set to json) I would expect a 415 unsupported media type.
>> 
>> However the actual is that the request ends up in the resource but the CustomerRequestBody body variable is null.
>> 
>> What is the best way to globally disallow the payload to be empty and return a 415?
>> Note that sending {} to the resource works as expected and the CustomerRequestBody body variable is not empty; only it's properties are empty as expected.
>> 
>> 
>> Cheers,
>> Marcel
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> 
>> _______________________________________________
>> Resteasy-users mailing list
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-users
> 

Re: [Resteasy-users] (no subject)

[William A. S. <wil...@gm...>]

Hello,

have you thought about using an interceptor?

--
*William Antônio Siqueira*
*Java Support Analyst*

*http://fxapps.blogspot.com <http://fxapps.blogspot.com>*
*http://www.williamantonio.wordpress.com
<http://www.williamantonio.wordpress.com>*
*http://williamprogrammer.com <http://williamprogrammer.com>*


2014-04-01 15:35 GMT-03:00 Marcel Overdijk <mar...@gm...>:

>
>
>
> I have a (Groovy) resteasy resource like:
>
>     @POST
>     @Consumes(MediaType.APPLICATION_JSON)
>     @Produces(MediaType.APPLICATION_JSON)
>     def create(CustomerRequestBody body) {
>         def customer = new Customer()
>         bindData(customer, body)
>         def violations = validate(customer)
>         if (violations) {
>             return
> Response.status(BAD_REQUEST).entity(toJSONArray(violations)).build()
>         } else {
>             customer.save()
>             return
> Response.status(OK).entity(toJSONObject(customer)).build()
>         }
>     }
>
> The resource only accepts json requests.
> The CustomerRequestBody is a simple POJO (or POGO in my case).
>
> When I post a empty response to the this resource (even with content type
> set to json) I would expect a 415 unsupported media type.
>
> However the actual is that the request ends up in the resource but the
> CustomerRequestBody body variable is null.
>
> What is the best way to globally disallow the payload to be empty and
> return a 415?
> Note that sending {} to the resource works as expected and the
> CustomerRequestBody body variable is not empty; only it's properties are
> empty as expected.
>
>
> Cheers,
> Marcel
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Resteasy-users mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
>

Re: [Resteasy-users] RestEasy 3.0.7 and Netty 4

[John D. A. <joh...@gm...>]

Hmmm, so this is your output right?

the data length you're describing is in bytes as well, right?

I know I previously had this working in 3.0.6, could you check if your code
works in 3.0.6?


On Tue, Apr 1, 2014 at 2:40 PM, Cédric Chéneau <ced...@gm...>wrote:

> Hello,
>
> Just tried to upgrade to RestEasy 3.0.7 on my Netty 4 server, I'm facing
> problem writing json data with length over 1000.
>
> After debugging, there seems to be an infinite loop in method
> ChunkOutputStream.write(...)
>
> In fact, my json data size is over the maximum length defined in
> NettyHttpResponse constructor:
>
> os = new ChunkOutputStream(this, ctx, 1000);
>
> Perhaps I'm missing something.
>
> Best regards,
>
> Cdr35
>
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Resteasy-users mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
>

[Resteasy-users] RestEasy 3.0.7 and Netty 4

[Cédric C. <ced...@gm...>]

Hello,

Just tried to upgrade to RestEasy 3.0.7 on my Netty 4 server, I'm facing
problem writing json data with length over 1000.

After debugging, there seems to be an infinite loop in method
ChunkOutputStream.write(...)

In fact, my json data size is over the maximum length defined in
NettyHttpResponse constructor:

os = new ChunkOutputStream(this, ctx, 1000);

Perhaps I'm missing something.

Best regards,

Cdr35